Token Lifetimes and Security in OAuth 2.0: Note clarification on long lived tokens and Service to Service communication

[dbfr3qs]

Hi there, firstly thanks for the fantastic overview on all things OAuth2 tokens - I've really enjoyed reading it so far.

I've been struggling to make sense of the note under Service to Service communications when discussing the use of long lived access tokens and would like to seek clarification.

To quote the entire passage:

In certain system-to-system communications where services need to interact with each other in a highly trusted environment (e.g., within the same enterprise or data center), long-lived tokens can reduce the need for frequent authentication and authorization exchanges. This makes service communication more efficient.

Use case: Within microservice architectures in secure internal networks, long-lived tokens can facilitate inter-service communication without requiring frequent re-authentication.

Note: This use can also be solved by using short-lived tokens that leverage client_secret_jwt or private_key_jwt as defined in the OpenID Connect Core specification.

The note is what confuses me and I think I may be missing something fundamental. As far as the client type in use, are we discussing client credential clients (that is my assumption when talking about service to service communication)? If so, how does using shorter lived tokens with those specific authentication methods solve this particular use case? Clients could use those authentication methods and still make use of longer lived tokens.

Apologies if this is obvious but I'm genuinely unable to figure it out.

[hlflanagan]

Great question! I reached out to the person who helped me with that section. Their response:

Long-lived tokens reduce the need for the client to use the client_credentials flow to obtain a new token. So, if using the client_credentials flow with short-lived tokens, the application would need to make a lot of client_credential token issuance calls.

In the case of using something like private_key_jwt, the client doesn’t need to make any call to the AS to obtain an “access token”. It can just issue a JSON based access token signed by the private key and the receiving service can validate the token as being issued by the correct requesting client. This then allows that issued access token to be short lived. So you get the benefit of short-lived tokens without the need for lots of trips to the AS to obtain an access token.

This nuance is one of the things that makes machine-to-machine requests interesting and is specifically the space that SPIFFE is trying to enhance with its standardization efforts. Maybe a better note would be to point to SPIFFE rather than client_secret_jwt and private_key_jwt.

client_secret_jwt really only works in a scenario where all requests are routed through a central distribution point, which is probably not very common.

Even within a more secure environment, zero-trust principles would not encourage the use of long-lived tokens, especially if there are no sender-constrained constraints.

[dbfr3qs]

Thanks for getting back to me and for answering my question!

In the case of using something like private_key_jwt, the client doesn’t need to make any call to the AS to obtain an “access token”. It can just issue a JSON based access token signed by the private key and the receiving service can validate the token as being issued by the correct requesting client. This then allows that issued access token to be short lived. So you get the benefit of short-lived tokens without the need for lots of trips to the AS to obtain an access token.

That sort of sounds like some sort of token self issuing... is there a relevant standard somewhere (or a relevant portion of the referenced OIDC core spec) that describes this that might be better to reference? When I first read this, I looked at OIDC core via the reference and all I could find that was relevant appears to describe private_key_jwt and client_secret_jwt under Client Authentication as authentication methods used to authenticate clients with the AS (complete with an example request to the /token endpoint).

I'm just thinking how we could make that nuance clearer/less confusing but I'm also curious to learn more regarding the self issuing.