[Feature Request] Make it possible to configure token life times per client

[jbaron-gingco]

Currently, token life times can be configured per grant type - in our application, this is basically the same "globally". This is not sufficient for some use cases:

• Some clients should get a long living access token using the client credentials grant - one example would be the AzureAD SCIM implementation. They can only handle fixed tokens, or Microsoft AzureAD Graph tokens (I know... but Microsoft).
• Some clients should get refresh tokens with different life times - because the refresh token life time basically defines the allowed non-usage time for the client without reauthorization. Some clients have potentially long non-usage times (e.g. mobile apps), others almost none (e.g. cronjobs).

Behaviour idea:

• The token lifetimes per grant become the default token lifetimes for that grant.
• Each client MAY configure both token lifetimes separately, per grant type. If this is done, those lifetimes override the token lifetimes from the grant type.

[jbaron-gingco]

Pull request for a first attempt: https://github.com/thephpleague/oauth2-server/pull/1259

[Sephster]

By default we provide a bearer token response. The benefit of these token types is that you don't need to look up a DB to check the validity of the token. The downside is there isn't anyway to revoke them as you've noted. For this reason, the access tokens in the library should always be relatively short lived.

It is possible to write your own token response but you'd still have the issue of either holding the client based expiration token logic in the custom response class (which isn't ideal) or just adding methods to your client entity implementation to support this feature.

I was initially quite keen to add this into the library but I think we probably shouldn't. If you want this feature it should be relatively easy to extend your implementation to support it. If we added this we would be going against most other OAuth 2 Server libs which set these values globally. I'm unsure why this would be but I'm hesitant to go against convention and suspect that it might be because the customisation of access tokens per client could make it more likely that a dev would make an implementation mistake or make it more likely someone would set a long lived access token, not realising the implications when using bearer token responses.

For the reasons above I think we shouldn't implement this in the library. However, if you can find solid examples where this has been done in other libs (closest I could find was Azure's implementation) then I'd be happy to revisit this.