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
Right now credential rotation while using Doorkeeper seems a little cumbersome. From my POV, there are currently 2 major approaches that can be taken:
Only the secret is rotated. This approach seems more elegant, but the major drawback here is that client applications cannot authenticate until they have updated their credentials in the code.
The entire OAuth application is rotated. This allows for a grace period during which time new credentials can be added/tested while the old credentials remain active. However, this method is not without consequences. Assuming we do not purge all tokens during the rotation, if the client wants to revoke a token during the transition period, they may end up attempting to revoke a token created by a different OAuth application (not allowed). Also if anyone is using the oauth_application_id or uid for metrics they have to take this transition into account.
My suggestion/feature request here would be to add additional support for approach 1. Perhaps we could have an "old_secret" field that remains active for a period of time after the secret field is updated. Thoughts?
The text was updated successfully, but these errors were encountered:
Right now credential rotation while using Doorkeeper seems a little cumbersome. From my POV, there are currently 2 major approaches that can be taken:
My suggestion/feature request here would be to add additional support for approach 1. Perhaps we could have an "old_secret" field that remains active for a period of time after the secret field is updated. Thoughts?
The text was updated successfully, but these errors were encountered: