Comments (10)
@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
from okta-jwt-verifier-java.
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
- library is configured with set of trusted issuers
- issuer is retrieved from token - rejected if not in set
- keys retrieved from jwks url published in well-known configuration by trusted issuer
- JWT signature validated
- 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
from okta-jwt-verifier-java.
Happy to file a pull request for this by the way.
from okta-jwt-verifier-java.
Hey @Sovietaced!
When this happens can you grab the JWT you are trying to validate? That should help narrow down the problem
from okta-jwt-verifier-java.
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.
from okta-jwt-verifier-java.
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?
from okta-jwt-verifier-java.
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.
from okta-jwt-verifier-java.
@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.
from okta-jwt-verifier-java.
@ethanmills any content inside the JWT bod cannot be trusted until the signature is validated.
from okta-jwt-verifier-java.
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?
from okta-jwt-verifier-java.
Related Issues (20)
- Feature Request : Method for introspect token. HOT 2
- Allow specifying a java.time.Clock to better write unit tests. HOT 3
- Publish new library version HOT 2
- NoClassDefFoundError after upgrade HOT 5
- com.okta.jwt.JwtVerificationException: Failed to parse token HOT 14
- Issuer verification failed (Okta + Ktor + SwaggerUI) HOT 1
- Access Token Verifier Builder fails to initialize HOT 7
- Failed to parse token HOT 3
- HTTP request to issuer URL exposes system information
- Provide a function in AccessTokenVerifier that loads JWKS signing keys HOT 2
- java.lang.IllegalArgumentException: A signing key must be specified if the specified JWT is digitally signed. HOT 3
- NoClassDefFoundError after upgrade HOT 5
- Please consider publishing the com.okta.jwt.it testing classes with the okta-jwt-verifier-integration-tests jar.
- No `interface com.okta.jwt.AccessTokenVerifier$Builder` implementation found on the classpath. Have you remembered to include the okta-jwt-verifier-impl.jar in your runtime classpath HOT 4
- Support for org authorization servers HOT 4
- this is not working with reactive webflux restapi HOT 6
- java.lang.NoSuchMethodError: 'io.jsonwebtoken.JwtParserBuilder io.jsonwebtoken.Jwts.parserBuilder()' HOT 6
- Convert integration tests to java HOT 3
- Feature Request: Stronger typing in Jwt Claims HOT 5
- Async API HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
đ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. đđđ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google â¤ī¸ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from okta-jwt-verifier-java.