3

My resource server exposes an API that expects JWT access tokens obtained using OpenID Connect.

So far the validation in the resource server side consisted on using the Realm public key to validate the JWT access token signature and check some other parameters suchs as expiration time.

Since the access token is a JWT, I already have information about the user (sub, role claims etc). So I wouldn't need to invoke the introspection endpoint to get it.

However the introspection endpoint also anwers with the active state of a token. Does it make sense to use it as another step in the JWT access token validation process? Is it really necessary or should I consider it valid just checking the signature and the other claims?

Is the tradeoff of the added latency to invoke just another endpoint to validate worth it?

1
  • "My resource server exposes an API that expects JWT access tokens obtained using OpenID Connect.": The intended audience of the access token obtained using OpenID Connect is the UserInfo endpoint (i.e. the authorization server). If you are not the authorization server, you should treat it as an opaque token. Maybe you want to say: "My resource server exposes an API that expects JWT access tokens obtained using OAuth 2.0." ?
    – ysdx
    Commented Jun 16, 2023 at 6:52

1 Answer 1

2

It depends on your threat model and the implementation of the Authorization Server. The principal reason to check with Authorization Server is to know if the access token has or has not been revoked. From oAuth token revocation spec (RFC 7009):

OAuth 2.0 allows deployment flexibility with respect to the style of access tokens. The access tokens may be self-contained so that a resource server needs no further interaction with an authorization server issuing these tokens to perform an authorization decision of the client requesting access to a protected resource. A system design may, however, instead use access tokens that are handles referring to authorization data stored at the authorization server. This consequently requires a resource server to issue a request to the respective authorization server to retrieve the content of the access token every time a client presents an access token.

While these are not the only options, they illustrate the implications for revocation. In the latter case, the authorization server is able to revoke an access token previously issued to a client when the resource server relays a received access token. In the former case, some (currently non-standardized) backend interaction between the authorization server and the resource server may be used when immediate access token revocation is desired. Another design alternative is to issue short-lived access tokens, which can be refreshed at any time using the corresponding refresh tokens. This allows the authorization server to impose a limit on the time revoked when access tokens are in use.

Which approach of token revocation is chosen will depend on the overall system design and on the application service provider's risk analysis. The cost of revocation in terms of required state and communication overhead is ultimately the result of the desired security properties.

Translation: if you're worried about token revocation, you should contact Authorization Server. The Introspection endpoint is the standard way of doing so.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .