Ability to change tokens lifespans on the fly

[randaalex]

Currently, lifespans have static behavior (getter just read value from config)
But I would like to have different lifespans per client (for example).

So it would be more comfortable to have something like handler.GetAccessTokenLifespan(ctx, request) instead of handler.AccessTokenLifespan

[mitar]

I think you can do that. You just have to manually set the claim on the token. Config ones is used only if claim for expiration does not yet exist.

[randaalex]

@mitar yes, it will work for access token. but my proposal about all tokens (refresh, auth, id)

[mitar]

I didn't get that from the original issue description. But I think you can do the same for other tokens as well? For ID for sure, auth is not a token but a code. For refresh I am not sure.

[aeneasr]

What's your use case? Access tokens have typically static expiry times because you get refresh tokens, which you can use to refresh access tokens.

[randaalex]

@mitar sorry for ambiguity
@aeneasr I need ability to have different refresh-tokens TTLs per client

[mitar]

See also: #211

I do think we need better documentation here how to do few common things.

[aeneasr]

I think client-specific TTL is ok. What we need to figure out is how to prevent clients from defining their own refresh token TTL, which should be only allowed for server administrators because it is considered server configuration.

[mitar]

What we need to figure out is how to prevent clients from defining their own refresh token TTL,

Even if it is less than what server/admin configured?

[aeneasr]

Even if it is less than what server/admin configured?

In that case I think it would be ok!

[github-actions]

I am marking this issue as stale as it has not received any engagement from the community or maintainers in over half a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• open a new issue with updated details and a plan on resolving the issue.

We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors.

Thank you for your understanding and to anyone who participated in the issue! 🙏✌️

If you feel strongly about this issues and have ideas on resolving it, please comment. Otherwise it will be closed in 30 days!