Open jmcarp opened 7 years ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/140101513
The labels on this github issue will be updated when the story is started.
Bumping to join notifications.
@fhanik mentioned that this work is already underway. @fhanik and @sreetummidi: do you have an estimate of when this might be ready?
@jmcarp We added support for token uniqueness where in only refresh token can be outstanding per user and client combination. Please check UAA 3.12.0
@sreetummidi I've asked this to be opened so we could have a discussion about compliance needs, which are currently more than we offer with refresh token uniqueness
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/141143981
The labels on this github issue will be updated when the story is started.
@fhanik @sreetummidi How can we continue this discussion / move this feature request forward?
Our ask as outlined above is still what we are looking for, has their been any thoughts on your side about expanding your token limits beyond refresh tokens?
@fhanik @sreetummidi Could we please get some type of formal response to this issue?
We're happy to try to figure this out and submit a PR, but would like some sort of confirmation that there hasn't been movement internally on your side, or that something like this would be welcome.
@jmcarp @LinuxBozo We will add this support in the upcoming version of UAA.
👍
@jmcarp UAA supports two token formats JWT and Opaque. Are you referring to limiting the Access Tokens or Refresh Tokens per User and Client combination?
Also, I think this feature makes sense when tokens are stateful as in they are revocable because we store the state in the UAA DB
@jmcarp We can't get started on this story if we don't have a clarification. I am leaning towards only limiting the number of outstanding refresh tokens. Access tokens will be restricted only when the token format is opaque.
Yes, what we're looking for is a global restriction on the number of refresh tokens regardless of user/client combo.
sounds good
@sreetummidi would you consider also number of tokens limit for client credentials flow as well. We are looking for limited number of tokens clients (one time use OAuth client) or limited TTL clients (deleted after expiration). That might be related to OAuth Dynamic Client Registration Protocol: https://tools.ietf.org/html/rfc7591 Thoughts?
Is this something that should be configured on the client? Or on the zone?
I would configure it on a client, not zone
Seeing this is still tagged scheduled
: Any idea when we might see it?
Is there any update on this?
Is there an update here? This has been 📆 for a while now, and implementation would close a compliance concern we're addressing.
Is there any way to log or track number of currently active tokens, or the IPs they're associated with? The ability to flag anomalous behavior here would be a compensating control.
:wave: to all the old homies who got notified by this ancient thread ✌️
I see there is bigger interesst on this topic. Currently UAA only has 1 or infinit.... so something like n inbetween is useful.
Could someone from the watchers list propose a PR ?
I hope everyone had a good 2021! How do things look for getting this addressed in 2021?
Also to quote @cnelson:
👋 to all the old homies who got notified by this ancient thread ✌️
@pburkholder If you would provide a PR then this would be a good starting point .
I know that this is a compliant issue, where all the bigger orgs should have interesst to have it @torsten-sap FYI
In order to comply with https://web.nvd.nist.gov/view/800-53/Rev4/control?controlName=AC-10, we would like to be able to control the maximum number of active tokens per user per client, such that old tokens are automatically invalidated when the limit is exceeded. An example interface might look like this:
From slack:
cc @rememberlenny @cnelson @mogul