Skip to content
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

Closed
dshanske opened this issue Jul 5, 2021 · 7 comments
Closed

Adopt Expiration and Refresh Tokens into the Spec #81

dshanske opened this issue Jul 5, 2021 · 7 comments

Comments

@dshanske
Copy link
Member

dshanske commented Jul 5, 2021

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.

@dshanske
Copy link
Member Author

dshanske commented Jul 5, 2021

Proposed language of amendment.

  • 5.3.5 - Expiration - Issuing access tokens with a limited lifespan is RECOMMENDED. In cases where this is true, the expires_in property documented in OAuth 2.0 [RFC6749] Section 5.1 SHOULD be returned.
  • 6.2 add in notation of - expiration (optional) - Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token will expire. The absence is this property indicates this is a non-expiring token.
  • 5.2.1 - add in - refresh_token (optional) - a token which can be used to obtain new access tokens using the same authorization grant as outlined in Section 5.5.
  • 5.5 Refresh Tokens - Use of short-lived access tokens and the offering of refresh tokens is RECOMMENDED as outlined in [RFC6749] Section 6.
@omz13
Copy link

omz13 commented Aug 28, 2021

  • 6.2 add in notation of - expiration (optional) - Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token will expire. The absence is this property indicates this is a non-expiring token.

Don't you mean expires_at (not expiration) which is the absolute (epoch time) version of the relative expires_in (seconds)?

@aaronpk
Copy link
Member

aaronpk commented Aug 28, 2021

Section 5.3.3 (Access Token Response) would be the best place to add the references to the expires_in and refresh_token properties.

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

@aaronpk
Copy link
Member

aaronpk commented Aug 28, 2021

Don't you mean expires_at (not expiration) which is the absolute (epoch time) version of the relative expires_in (seconds)?

expires_at isn't a thing really. OAuth has expires_in for the access token response, and exp in the token introspection response.

@dshanske
Copy link
Member Author

That's what I read. So we need expires_in. I'd like an absolute time, but I'll convert.

@dshanske
Copy link
Member Author

Wrote #90, a rough draft adding in the response parameters and adding a section summarizing Refresh Tokens.

@dshanske
Copy link
Member Author

dshanske commented Mar 5, 2022

This has been merged now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants