You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Client Credentials Grants' Access tokens not respecting Access Token Lifespan and being bound to SSO Session Max#44282
This might be very well on purpose, but I'd like to have some feedback as of why this is like this:
When creating a client with service account enabled, I'd expect to be able to allow for longer Access token longevity to the tokens created by such client, but they seem to be anyway bound to SSO Session Max even though they are not related to the SSO process nor are they user sessions in this case?
There are a bunch of use cases that could benefit from this, why enforce SSO Session Max for access tokens for machine connectivity for example?
Is this intended? I've tried multiple options but none seem to be able to escape SSO Session max, and it seems very much by design. What's the intention in this case?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This might be very well on purpose, but I'd like to have some feedback as of why this is like this:
When creating a client with service account enabled, I'd expect to be able to allow for longer Access token longevity to the tokens created by such client, but they seem to be anyway bound to
SSO Session Maxeven though they are not related to the SSO process nor are they user sessions in this case?There are a bunch of use cases that could benefit from this, why enforce
SSO Session Maxfor access tokens for machine connectivity for example?Is this intended? I've tried multiple options but none seem to be able to escape
SSO Session max, and it seems very much by design. What's the intention in this case?All reactions