search

indigo-iam / iam

INDIGO Identity and Access Management Service
https://indigo-iam.github.io/
Other
102 stars 43 forks source link

enhanced refresh token config #799

Open stlammel opened 3 months ago

stlammel commented 3 months ago

CMS plans to use HashiCorp Vault to securely stores long-lifetime credentials. Refresh-tokens from IAM would be stored in the vault. To avoid re-authorization after the refresh-token lifetime expires, we like to refresh the refresh-token before their expiration (once they fall below the maximum expected job queuing plus execution time). We don't want to refresh the refresh-token on each access-token request to limit IAM operation. (There could be many access-tokens acquired from a refresh-token.) We like to ask for a new refresh-token config option that auto-rotates/refreshes a refresh-token when the remaining lifetime drops below a minimum. (In addition to the current auto-rotate/refresh on access-token request.) It would be also nice to have a refresh-token config option to explicitly allow refresh-token lifetimes beyond the lifetime of the initial refresh-token. (The current maximum refresh-token lifetime would still apply to each refresh-token.) Thanks,

msalle commented 2 months ago

I'd say for service accounts this is ok, since you can in any case revoke the RT. For end-users we probably would want the user to prove they're still around periodically. The RT lifetime can be used to enforce that, but it could be another timescale too. These type of considerations are currently also being discussed in the AARC-TREE project and the Token-Trust-and-Traceability-Working-Group.

stlammel commented 2 months ago

If the account that authorized the refresh-token is disabled, i would expect all associated tokens to become invalid. The operation to make refresh-tokens auto-rotate/refresh when they falls below a min lifetime i would limit to admins.

msalle commented 2 months ago

That sounds reasonable. The question is whether it's not really the same as having (configurable) a non-expiring RT (i.e. RT with infinite lifetime) for those use-cases? The latter would probably be a lot easier to implement?

stlammel commented 2 months ago

Our thinking is that a 30-day refresh token with a special mechanism for renewal would be a bit more secure than an infinite-lifetime refresh token and also more in line with the refresh token recommendations. Infinite-lifetime refresh token is currently supported by IAM, i.e. would require no change (other than to admin restrict). Thanks,

msalle commented 2 months ago

It would protect for certain scenarios but also introduce new weaknesses. In general, using non-standard mechanisms (automatically refreshing in the background) is making it harder to follow what is going on and not a good idea from a security perspective. In any case for services, the client credentials flow (RFC6749 Section-4.4) would be suitable, it's simpler and standards compliant? For users I would generally not like either automatic renewal nor infinite lifetime RTs, for the former there should ideally still be a longest user-does-not-need-to-be-present time I'd say.

stlammel commented 2 months ago

I think you misunderstand, it's not a refresh in the background, non-standard mechanism, etc.m simply a different trigger for the existing auto-rotate. Thanks,

msalle commented 2 months ago

True, I'm probably discussing a slightly different issue than what you described so perhaps this is more for the TTT WG. I'm thinking about the allowing of renewal beyond the initial RT time, which can be implemented and restricted (or not) in many different ways. Perhaps it should just be clearly defined how the mechanism is working. But that is then probably for Indigo IAM.