Client dynamic life time on Access Tokens

[vaspop]

Is your feature request related to a problem?

I am trying to figure out a way to configure access token life time per client basis. That is client x and y can have totally separate life times on their access tokens.

Describe the solution you'd like

Today i cant see this being supported other than overriding the default handler pipeline with a custom step that modifies the expiration claim.

Could this solution lead to any issues? Any thoughts on if some kind of interface or other be provided that injects between where that option is used today?(PrepareAccessTokenPrincipal?)

The main issue with above custom solution that i can see is just from a pure maintenance point of view for if/when the pipeline changes.

[kevinchalet]

The events model approach is perfectly fine, but you can also define the expiration lifetimes per-client/user/session directly from your authorization controller using the dedicated extensions: https://stackoverflow.com/questions/42442109/is-there-a-way-to-have-different-ticket-expiry-lengths-in-openiddict

That said, we could certainly support per-client lifetimes using the Requirements stuff we already use to enforce PKCE.

[Gillardo]

Is "per clientid" lifetimes available?

[vaspop]

Is "per clientid" lifetimes available?

@Gillardo it is by the example method @kevinchalet links in his comment above. Thats basically how we ended up solving per client id lifetimes.

[Gillardo]

Is "per clientid" lifetimes available?

@Gillardo it is by the example method @kevinchalet links in his comment above. Thats basically how we ended up solving per client id lifetimes.

As in changing them via the principal? So there isnt a way to "configure" it, we need to override it in the authorizationController?

Thats fine, just making sure there isnt a "config" way

[kevinchalet]

As in changing them via the principal? So there isnt a way to "configure" it, we need to override it in the authorizationController?

If by "configuring", you mean assigning a static value to a particular client, then yes, it's not currently supported OOTB. As @vaspop said, OpenIddict offers a code-based approach that allows you to dynamically set the token lifetimes depending on the client, on the user or anything else. In that case, the lifetimes are stored in the authorization codes/refresh tokens as special claims so they apply to the entire chain of tokens (but you can override them at any point in your /token action the same exact way).

It's way more powerful than a static config, but if there's a real demand for this feature, I don't mind adding it in a future version.

[BerndHaidan]

It's way more powerful than a static config, but if there's a real demand for this feature, I don't mind adding it in a future version.

It would be relay nice to have the token lifetimes in the client configuration. We also have the need for different lifetimes, dependent on the client (SPA, mobile, machine to machine). What we currently do, is to put the different lifetimes to our own configuration. But to have lifetimes at a glance with the other parts of the client config would be a benefit.

[fairking]

I don't understand the purpose of refresh tokens. In case of SPA they stored in browser along with access tokens. It does not make sense. So if access token is stolen then the refresh token is stolen as well.