Refresh Tokens

[dshanske]

Tried to add in refresh tokens and expiration.

[omz13]

I'm not sure if this is mentioned elsewhere, in the section 'Refreshing an Access Token' perhaps mention that a refresh can be requested anytime at the discretion of the client; i.e. it does have to wait for an access code to expire before using its refresh token to request a new one.

[dshanske]

Good idea...I was trying to summarize the refresh flow and need to cite other sources for guidance. But that one I think should be included

[omz13]

The phrase "or to obtain additional tokens" is a bit misleading... better as "or to obtain a new token" (because when refreshing you get a new token and the old one has its active state removed).

[jamietanna]

❓ if omitted, OAuth2 clients would expect this to not expire:

expires_in (recommended) If the access token expires, the server should reply with the duration of time the access token is granted for.

(via)

[dshanske]

Correct, but that's the definition of expires_in from OAuth2.

[aaronpk]

I would remove the "If omitted" clause. That really only makes sense when there are API docs for the service you can refer to. Technically it would still be true in IndieAuth, but there are basically no cases where it would happen so there's no need to call it out. IndieAuth is still extending OAuth so someone can refer to the original OAuth text if they really want to learn this.

[jamietanna]

Suggested change

<p>If valid and authorized, the authorization server issues an access token as noted in <a href="#access-token-response">Access Token Response</a>. If an authorization server chooses to issue a new refresh token, then the refresh token scope MUST be identical to the one included by the client in the request.</p>

<p>If valid and authorized, the authorization server issues an access token, and optionally a fresh refresh token, as noted in <a href="#access-token-response">Access Token Response</a>. If an authorization server chooses to issue a new refresh token, then the refresh token scope MUST be identical to the one included by the client in the request. If an authorization server chooses to issue a new refresh token, then the previously used refresh token is expected to no longer be valid.</p>

[dshanske]

That's not actually required in OAuth2, do we want to require it here? It's certainly recommended.

[aaronpk]

I would say "optionally a new refresh token"

You could copy the language from OAuth 2.1 around this which includes the recommendation of this refresh token rotation which actually came from the Security BCP

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-03#section-4.3.2

[jamietanna]

Few comments, but looking good 🙌

[jamietanna]

Also, should we be adding this to the CHANGES section, too?

[dshanske]

Re the CHANGES section, that would be after we merge these, we'd add it.

[reiterate-app]

My comments on #94 (comment) also apply here. The grant_type parameter by itself is insufficient for an endpoint to determine what action to take in response to a POST request at the token endpoint.

[dshanske]

@jamietanna In your implementation, you send client_id, which isn't in my PR.

[dshanske]

Noting my description doesn't talk about client authentication, which is used in Oauth2's refresh, and needs discussion.

[jamietanna]

Hmm, yes client_id is only required if client authentication is required, which we won't be doing for public (IndieAuth) clients.

I'll check if my server supports not sending it but agreed that can be optional 👍🏽

[dshanske]

Hmm, yes client_id is only required if client authentication is required, which we won't be doing for public (IndieAuth) clients.

I'll check if my server supports not sending it but agreed that can be optional 👍🏽

I was thinking about this. It can be used to check to see if the client matches the original, but if you have a compromised refresh token, you probably have the client ID it came from.

[aaronpk]

The client_id parameter is required to be sent to the token endpoint if there is no client authentication. This is true both in OAuth 2.0 and 2.1:

• OAuth 2.0 Section 3.2.1
• OAuth 2.1 Section 3.2.2

The motivation for sending it in 2.0 is out of date, but it is still required and still can benefit the authorization server, such as being able to search a smaller index by first adding the client_id to the DB lookup. But you are correct that it doesn't add any additional security protection of the refresh token.

[dshanske]

@aaronpk @jamietanna I think I updated everything requested.

[jamietanna]

Minor improvement, but LGTM otherwise - great stuff 👏

[dshanske]

Check to see if PR explicitly says that profile information is to be returned in flow.

[jamietanna]

indentation is mismatched from other elements above/below

[jamietanna]

Indentation aside, LGTM!