-
Notifications
You must be signed in to change notification settings - Fork 7
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
Adopt Expiration and Refresh Tokens into the Spec #81
Comments
Proposed language of amendment.
|
Don't you mean |
Section 5.3.3 (Access Token Response) would be the best place to add the references to the We should add a new section (possibly 5.5) talking about refreshing access tokens. See also #89. The token introspection response should be discussed as part of adopting RFC7662 #33 |
|
That's what I read. So we need expires_in. I'd like an absolute time, but I'll convert. |
Wrote #90, a rough draft adding in the response parameters and adding a section summarizing Refresh Tokens. |
This has been merged now. |
Proposing the adoption of refresh tokens and expiration as recommended but not mandatory into the spec.
Simply speaking, the token would return when issued an expires_in parameter, and when verified an exp parameter to indicate the timestamp of expiry, adopting the parameter from the token introspection endpoint spec.
Refresh tokens, again, would be optional, and dictated per appropriate OAuth2 prior art.
The text was updated successfully, but these errors were encountered: