AccessTokenVerifier can throw undocumented exceptions

[Sovietaced]

:information_source: If you have a question, please post it on the Okta Developer Forum instead. Issues in this repository are reserved for bug reports and feature requests only.

I'm submitting a

• [x] bug report
• [ ] feature request

Background info

In some rare cases I am seeing an IllegalArgumentException being thrown from the AccessTokenVerifier#decode. According to the documentation it should throw a JwtVerificationException when parsing or validation errors occur.

It appears that the try/catch around the code that parses the JWT does not adequately handle all of the exceptions advertised by the JWT parser: https://github.com/okta/okta-jwt-verifier-java/blob/master/impl/src/main/java/com/okta/jwt/impl/jjwt/TokenVerifierSupport.java#L63-L71

Expected behavior

A JwtVerificationException should be thrown.

What went wrong?

java.lang.IllegalArgumentException: A signing key must be specified if the specified JWT is digitally signed.
    at io.jsonwebtoken.lang.Assert.notNull(Assert.java:82)
    at io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:357)
    at io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:513)
    at com.okta.jwt.impl.jjwt.TokenVerifierSupport.decode(TokenVerifierSupport.java:61)
    at com.okta.jwt.impl.jjwt.JjwtAccessTokenVerifier.decode(JjwtAccessTokenVerifier.java:45)
... 

Steps to reproduce

I'm not sure what the content of the JWT is unfortunately but this happens very rarely.

Library Version

  // okta
  implementation 'com.okta.jwt:okta-jwt-verifier:0.4.0'
  implementation 'com.okta.jwt:okta-jwt-verifier-impl:0.4.0'

[Sovietaced]

Happy to file a pull request for this by the way.

[bdemers]

Hey @Sovietaced!

When this happens can you grab the JWT you are trying to validate? That should help narrow down the problem

[Sovietaced]

When this happens can you grab the JWT you are trying to validate? That should help narrow down the problem

I can try to grab the JWT. We typically don't log it but I can change that.

[she43]

I was about to raise this an issue. @bdemers I noticed this today when the signing keys are rotated. How will this library know that the signing key is rotated and Use RemoteJwksSigningKeyResolver?

Can you please let jus know what is the cache duration and the frequency of requests to remote jwks uri?

Also, please confirm if the backend calls from UI can validate id token and access token using this library or should the backend just validate signature?

[bdemers]

There are a few questions in here, so I'll try to answer all of them, but there is a healthy dose of "it depends"

First, if possible your backend should handle authentication(e.g. redirect to login), then your frontend simply uses cookies to deal with the user's session. This isn't a one size fits all solution, but when possible, it's usually the best option. If your frontend handles authentication (which sounds like what you are doing), and ends up with an access token, you treat your REST API as an OAuth "Resource Server". Your frontend sets a header: Authentication: Bearer <access_token>, (NOT the id token) and your REST API can validate this token in one of two different ways:

1.) Remotely (per OAuth spec) 2.) locally (using a JWT)

NOTE: The fact that Okta's access tokens are JWTs is an implementation detail (a common one, as a lot of other vendors, do this as well).

This post is Spring specific, but it talks about this topic in a more general sense as well.

I bring this up because when using a JWT, there is always the possibility of stale tokens (from the above post):

The biggest downside to validating a token locally is that your token is, by definition, stale. It is a snapshot of the moment in time when your identity provider (IdP) created the token. The further away you get from that moment, the more likely that token is no longer valid: it could have been revoked, the user could have logged out, or the application that created the token disabled.

That said, back to the answers. This lib uses a very simplistic cache, (a map in memory), keys are cached until another request is made to the "keys" endpoint. Requests are only made to the keys endpoint when unknown kid claims are found. There is some discussion about this in #30, so that might be the best place to continue this thread.

[ethanmills]

@bdemers the headline here is still an issue (the method throws undocumented java.lang.IllegalArgumentException and com.okta.commons.http.HttpException). I'd also suggest checking the exp of the token before verifying the signature; we're seeing issues trying to fetch keys that have been rotated away for tokens older than 3 months. Either way, if the key isn't present or the token is expired, I'd expect this method to throw a documented exception.

[bdemers]

@ethanmills any content inside the JWT bod cannot be trusted until the signature is validated.

[ethanmills]

Is there a concern about malicious content, or just false information? I think you have to decode the payload to get the issuer before you can fetch the keys anyway, so rejecting early (never accepting) based on an exp in the past seems safe?

[bdemers]

@ethanmills The issuer is known in advance in advance when configuring the library, so the library already knows where to get the keys from.

What you are suggesting was a common vulnerability in JWT libraries early on. It would be like asking someone who handed you counterfeit money to validate it. Similarly, this is why the jku claim should not be used: https://www.rfc-editor.org/rfc/rfc7515#section-4.1.2 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-07#section-3.10

The high level is a JWT library MUST be configured with the issuer (more specifically, the key information) before a JWT is parsed. The JWT signature is validated (with existing the key information) The body is parsed The claims are validated

[ethanmills]

Thanks for the reply @bdemers . I appreciate what you're getting at, but think that it doesn't quite cover the whole picture. Consider the case where a resource server trusts tokens issued by two different issuers. The flow then looks like

1. library is configured with set of trusted issuers
2. issuer is retrieved from token - rejected if not in set
3. keys retrieved from jwks url published in well-known configuration by trusted issuer
4. JWT signature validated
5. claims validated

That's the flow followed by e.g. https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/oauth2/server/resource/authentication/JwtIssuerAuthenticationManagerResolver.html