-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add client_secret_expires_at to OAuth Applications #30317
base: main
Are you sure you want to change the base?
Add client_secret_expires_at to OAuth Applications #30317
Conversation
@@ -27,6 +27,8 @@ | |||
client_id: token.application.uid | |||
) | |||
) | |||
|
|||
expect(body_as_json[:client_secret_expires_at]).to_not be_present |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm undecided as to if this value should or should not be returned here.
This pull request has merge conflicts that must be resolved before it can be merged. |
…y with expiring applications
917cac0
to
9544ee5
Compare
This pull request has resolved merge conflicts and is ready for review. |
What would be the process for an application whose secret is expired? What about when it's about to expire? |
Currently we're just being clear that applications do not expire. If we choose to support expiry (which may not be necessary with URI based client_id's), then we'd need to define a process around that, e.g., an i don't recall the spec specify what to do about expiration |
This allows us to support future
client_secret
expiry, whilst also advertising that clients do not currently expire automatically. This is inspired by Auth0's Open Dynamic Client Registration documentation.— OAuth 2.0 Dynamic Registration, RFC 7591, Section 3.2.1
This PR requires #30316 to be merged, since the OAuth Application vacuuming currently does not have any predictable expiration properties. So if we leave OAuth Application vacuuming in as currently existing, the value of
0
would not be correct, since the client could be vacuumed at any point in time after 1 day.This allows Application developers to prepare and be adaptive to when we may introduce client_secret expiry in the future, such that they can know when their application would expire. (Supporting this would require a database migration to add a column to the oauth_applications table for expiry).