Would it be possible to open a bit more the JWT implementation ?

[julien-leclercq]

Hello!

I am in a multiple frontend applications + API + Auth0 for authenticating all those setup. Basically what I would like to do is to enable my API to inspect the bearer tokens that a frontend is using for authentication (which are JWTs generated by Auth0).

I ended up using the jsonwebtoken crate, which is fine but I feel like I am reimplementing what is already well done in your library (Fetching JWKs and verifying a JWT).

Do you have any inputs on how I could do otherwise ?

[ramosbugs]

Hey @julien-leclercq,

Do you know if Auth0 is following the new-ish RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens? If so, it should be pretty straightforward to implement the desired functionality within this crate, similar to how UserInfoJsonWebToken is implemented. This would only make sense if Auth0 is using the same keys as in its OIDC metadata to sign the bearer tokens, though. That spec also allows for separate OAuth2-specific metadata, which I don't want to add to this crate.

I'd prefer not to expand the public API enough that this crate becomes a general-purpose JWT library, but some sort of general-purpose interface that validates JWT signatures against an OIDC provider's JWK set could make sense. Beyond simply verifying the signature, checking fields like aud are specific enough to each use case that some sort of RFC would need to be applicable in order for the functionality to live within this crate.

[julien-leclercq]

You mean following the spec ? why would they do that? The jwt payload looks like this.

{
  "iss": "https://**REDACTED**.us.auth0.com/",
  "sub": "auth0|**REDACTED**",
  "aud": [
    "**REDACTED",
    "**REDACTED**"
  ],
  "iat": 1698947883,
  "exp": 1699034283,
  "azp": "**REDACTED**",
  "scope": "openid profile"
}

[julien-leclercq]

Beyond simply verifying the signature, checking fields like aud are specific enough to each use case that some sort of RFC would need to be applicable in order for the functionality to live within this crate.

I totally understand your point, but it feels a bit wrong to me what I am doing at the moment. My current process is to

• instanciate an openidconnect provider metadata struct with CoreProviderMetadata::discover_async
• serialize the found jwkset and deserialize it into a jsonwebtoken::jwk::JwkSet
• pack an openidconnect::Client, the jwkset, an ad-hoc client (related to #136), the auth0 domain and the audience into a struct I'll pass to my handlers
• use openidconnect for pretty much everything internally but have this thing using jsonwebtoken for access token validation

[ramosbugs]

I think the right answer here would be a separate Auth0-specific crate built on top of this one that hides those implementation details. Even if it would be convenient to have as part of this crate, OpenID Connect considers access tokens to be opaque, and treating them as JWTs is pretty vendor-specific.

If someone can point to an IETF or OpenID Foundation spec that defines the required functionality, I'll consider adding it to this crate. Otherwise, I don't think there's much to be done.

• serialize the found jwkset and deserialize it into a jsonwebtoken::jwk::JwkSet

I'd be open to implementing From<JsonWebKeySet> for jsonwebtoken::jwk::JwkSet (or TryFrom if fallible) behind a non-default feature flag to at least avoid the extra serde roundtrip.

[julien-leclercq]

I'd be open to implementing From for jsonwebtoken::jwk::JwkSet (or TryFrom if fallible) behind a non-default feature flag to at least avoid the extra serde roundtrip.

Yep keeping using jsonwebtoken but in a definitely nicer way would be acceptable. I could implement the feature flag if you want me to.

[ramosbugs]

Sure, I'd welcome a PR to do that