Navigation Menu

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

Allow clients to always exchange authorization codes at the token endpoint #58

aaronpk opened this issue Sep 26, 2020 · 6 comments


Copy link

aaronpk commented Sep 26, 2020

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
@aaronpk aaronpk modified the milestone: Sep 26, 2020
Copy link

manton commented Sep 26, 2020

Sounds good to me.

Copy link

Seems reasonable!

Copy link

Zegnat commented Sep 26, 2020

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?

Copy link

Zegnat commented Oct 4, 2020

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.

Copy link
Member Author

aaronpk commented Aug 28, 2021

  • 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.

aaronpk added a commit that referenced this issue Aug 28, 2021
related to the discussion in #62 and #58
Copy link

dshanske commented Mar 5, 2022

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

@dshanske dshanske closed this as completed Mar 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

5 participants