docs: clarify expiration behaviour in Maskinporten /token endpoint #455
Conversation
Clarified the current behavior of the exp parameter in the input JWT.
| | scope | A list of scopes the access_token is bound to. | | ||
| | token_type | Type of token. Only bearer supported. | `Bearer`| | ||
| | exp | Expire - Timestamp when this token should not be trusted any more. | | ||
| | exp | Expire - Timestamp when this token should not be trusted any more. **Note: This is not respected by the auth server. The configured expiration time on the client decides the expiration of the token.** | |
There was a problem hiding this comment.
Maybe say something like maximum value is 7200, regardless of what is configured in auth server?
There was a problem hiding this comment.
Maximum value of this parameter 180 seconds. Anything more than that and you will get a 400 error.
The actual maximum value that you get from the server is 7200 seconds. It is decided in the client configuration.
It is difficult to explain this odd behaviour in a way that makes sense.
braaar
changed the title
|
@braaar I'm afraid I don't fully understand this PR. This is called a JWT grant, and that one is documented on a different page: https://docs.digdir.no/docs/Maskinporten/maskinporten_protocol_jwtgrant.html There is to my knowledge no explicit or implicit standardized relation between the allowable lifetime of a request and the lifetime of the respons (token). In fact, https://datatracker.ietf.org/doc/html/rfc7523#section-3 says "Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. Which is what we do. |
3 participants
Clarify the current behaviour of the exp parameter in the input JWT. After some tinkering I have concluded that this is the current behaviour.
I could submit this as a bug issue, but I don't know if the auth server itself has a public repository.
If I set
expto anything more than 180 seconds I get a 400 error, even if the client allows for longer lived tokens.