Consider dropping me from the GET request that contains the code

[aaronpk]

The client should have already established a session or used the state to store things. Removing it from the request will make sure people don't accidentally think this is trusted information at this stage.

[aaronpk]

This would also apply to the IndieAuth spec redirect described here https://indieweb.org/authorization-endpoint#Redirect_to_web_application

[snarfed]

hmm. oauth-dropins is stateless and re-fetches me in this GET to rediscover the auth endpoint to use to validate the code and get a token. what should it do instead? store and reuse the site's auth endpoint in the session or state?

[Zegnat]

Duplicate of #85? Also see Inklings-io/selfauth#10.

Removing it from the request will make sure people don’t accidentally think this is trusted information at this stage.

This is a good reason. For a login (identification, response_type=id) request you really should be making sure code verification happens against the same endpoint, I feel. If the code request is allowed to overwrite where you go looking for the endpoint for verification that might get you into trouble.

Also note that the returned me value is invalid if it isn’t on the same domain as the previously queried URL. So any implementation needs to store the domain already. @snarfed how did you solve this in oauth-dropins?

[sknebel]

It removes the ability of the endpoint to normalize the URL (e.g. http->https, or other redirects), but I'm not sure if that's actually a thing in current implementations. Other than that no reason to keep it.

[aaronpk]

oauth-dropins is stateless and re-fetches me in this GET to rediscover the auth endpoint to use to validate the code and get a token. what should it do instead? store and reuse the site's auth endpoint in the session or state?

@snarfed clients should be using the state parameter to avoid CSRF attacks anyway, and this is a perfect place to store session data if you want to avoid server-side session storage. Relying on the me parameter to re-discover the endpoint actually opens up an attack where someone can swap the me parameter and get the client to send the code to the attacker's server.

It removes the ability of the endpoint to normalize the URL (e.g. http->https, or other redirects), but I'm not sure if that's actually a thing in current implementations. Other than that no reason to keep it.

The response from either a code verification or token exchange includes the final me value, so there is still a chance to normalize the value. (Of course the client should not allow a domain to claim a me value on a different domain, but that's a different issue)

[sknebel]

The response from either a code verification or token exchange includes the final me value, so there is still a chance to normalize the value. (Of course the client should not allow a domain to claim a me value on a different domain, but that's a different issue)

Right. Then I agree, no reason to have the parameter in the callback

[aaronpk]

Duplicate of #85