Allow clients to always exchange authorization codes at the token endpoint

[aaronpk]

One of the last deviations from OAuth 2.0 is that currently the spec requires clients to send the authorization code back to the authorization endpoint for the "login" flow when the client doesn't expect an access token back. In OAuth 2.0, the authorization code is always exchanged at the token endpoint.

The reason for this behavior in IndieAuth was prior to the changes in #42 and #44, this allowed the authorization endpoint to be the only one that needed to be aware of user's URLs, and token endpoints could be standalone. The token endpoint could turn around and go verify the authorization code at the authorization endpoint.

I would like to suggest that the spec allows clients to be more like standard OAuth clients where they can always exchange the authorization code at the token endpoint, whether or not they expect an access token in the response or just the user's profile URL.

This wouldn't actually be a major change for current IndieAuth servers, since it's very likely that some of them already support this behavior at the token endpoint. It just means that the token endpoint would not throw an error if the authorization code had no scopes granted.

The proposed change would mean:

• If the client is not expecting an access token, the client can exchange the authorization code at either the token endpoint or authorization endpoint (ensuring backwards compatibility, otherwise it would be better to drop the exchange from the authorization endpoint)
• Token endpoints need to be aware that they should not issue an access token if no scope was requested, only returning the user's profile URL and profile info instead
• If someone is building an implementation that doesn't deal with access tokens at all, (i.e. is just used to log in to things), they can still build only an authorization endpoint and leave out the token endpoint completely

[manton]

Sounds good to me.

[martymcguire]

Seems reasonable!

[Zegnat]

Sounds fine to me.

What would this mean for the spec? If the token endpoint can now handle all types of code exchanges, would this shorten 5.3? I am always for a shorter specification as it makes it less likely things are forgotten or left unimplemented.

If the exchange with the authorization endpoint is kept for backwards compatibility reasons, should we discourage new clients of making that request at all? Possibly gearing up to deprecating that request entirely for a future IndieAuth update?

[Zegnat]

Token endpoints need to be aware that they should not issue an access token if no scope or only profile scopes are issued [...]

Emphasis by me. When I was writing up #62 and rereading this issue, I realised that this does not seem to be in the current spec. Per the code exchange step in 5.3.3. a token endpoint should not return a token only if no scopes were granted. profile is still a valid scope value.

We should clarify how access tokens and the different profile scopes are related. More thoughts in #62.

[aaronpk]

• Clarify access token response to make it explicit that any successful request to the token endpoint must result in an access token being returned, even if that access token has only the profile scope.
• Clarify here what to do if the authorization code does not have any scope, which is to return an error response.
• Clarify scope in request section, don't prevent IndieAuth servers from assuming a default scope, and clients should only be redeeming authorization codes with no scope at the authorization endpoint not the token endpoint.

[dshanske]

I believe this is addressed with the latest refresh. We can reopen if not.