Parse unverified JWT

[pblazej]

Enables "caching token source" on the client without 3rd party dependencies.

[pblazej]

@1egoman I'm thinking of removing JWTKit dependency in Swift, what else do you need for JS - something like:

    pub fn with_unverified_options(
        token: &str, 
        validate_exp: bool,
        validate_nbf: bool,
        leeway: Option<Duration>,
    ) -> Result<Self, AccessTokenError>

[1egoman]

@pblazej I think the unverified_token function you have exposed would work for an eventual javascript implementation. In addition, it would be good to pass Claims through the ffi layer as a type that can be used by client implementations as well. I don't think there's a need to control conditional exp / nbf validation in javascript, and IMO a leeway type parameter should be standardized across all sdks for validation and shouldn't be something some of them set in a special way.

As an unrelated FYI, I actually implemented some quite similar logic here but I like the way you did it here better, so I'll just use this interface instead once this one is merged.

[1egoman]

IMO, it would be good to have a 2 other tests:

• Try parse a token that was valid in the past but no longer is valid, and make sure it fails
• Try to parse a token which will become valid in the future and make sure it fails

[pblazej]

I actually implemented some quite similar logic

Yeah, I realized after a while it must be duplicated 😃

• Exposing Claims

Yes, I struggled a bit with custom types there, but may be worth doing

• What I don't like about this impl?

Is that exp/nbf is baked into the initialization, so you cannot inspect an expired token from the cache, not sure if that's minor or not.

I'll update this PR in spare time 👍 If the token source goes merged first, feel free to close it/use it somehow.

[pblazej]

What I wanted to replace in Swift is:
https://github.com/livekit/client-sdk-swift/blob/63258bdfa74482841826472d502e1a549d6e238e/Sources/LiveKit/Token/CachingTokenSource.swift#L152
https://github.com/livekit/client-sdk-swift/blob/main/Sources/LiveKit/Token/JWT.swift

[ladvoc]

LGTM ✅

[ladvoc]

question: Not specific to this PR, but in Swift, symbols will be imported in the global namespace, right? If so, we might consider using a standardized naming scheme for exported symbols from each module. For example, in this module we would have token_claims_from_unverified (this method), token_verify, and token_generate—everything is prefixed with "token" so it is clear which module it comes from.

[pblazej]

yep I wanted to ask that in Notion actually, it's not possible to create something like Claims.myNewMethod at all?

[1egoman]

^ I've only played around with the python bindings, but at least with those I was able to export a class as an "object" with static methods (I think I had to mark them technically as "alternate constructors") and that seemed to work. But maybe the swift bindings are different.

[pblazej]

I applied the token_ prefix, I don't think we can do more about namespaces (am I wrong?)

[pblazej]

I managed to replace the Swift JWT logic: https://github.com/livekit/client-sdk-swift/pull/822/files

The only (async) question is shall we expose these objects like Claims directly from the FFI or strive to wrap (which I personally hate 👿).

[pblazej]

I'm merging that into the main uniffi thing (to avoid rebasing), shouldn't be harmful. Please adjust if needed.