Consolidate authentication/authorization sections because they are actually the same

[aaronpk]

The "authentication" flow can be thought of as actually authorizing the release of the user's profile information, or authorizing their login verification. In any case, the only difference actually needed between the two flows is the presence of the access token. This also means response_type=code is the only response type needed, which is consistent with OAuth.

A request with no scope could be interpreted as a login request and no access token issued.

In both cases, the user's me URL would be returned, along with potentially profile information as described in #41

[fluffy-critter]

On the one hand, I think this is a good change, but on the other hand, this complicates things for authentication-only consumers (e.g. Authl). Will there be a reasonable mechanism for a thing to fail and then switch to making a code request instead? The immediately obvious approach would be to request response_type=code with no scope but I'm not sure if that will work with existing IndieAuth implementations, either.

Could the spec be reworded such that it says that response_type=id is considered equivalent to response_type=code with no scope, and then further require that no token be issued in either case?

[aaronpk]

I suspect most implementations actually never did response_type=id since that was a relatively late addition. I think most of them just omit scope.

[fluffy-critter]

Ah, good to know. In that case, do you recommend that on Authl I just switch to code now? I haven't knowingly run into any trouble with endpoints not supporting id, but I also haven't been looking for that.

[Zegnat]

I suspect most implementations actually never did response_type=id since that was a relatively late addition.

Selfauth is pretty strict with it. If you provide scopes alongside id it throws an error and does not go through with the request, same if you forget to send scopes alongside code. It defaults to id, so if you are sending scopes and no response_type the request will never get through.

That said, I think it only does this because there was an interest in staying close to the specification. I am all for consolidating and getting rid of this extra decision (for the sender) and checking (for the receiver)!

[aaronpk]

This was discussed at the IndieAuth Popup Session, and the outcome of the discussion was:

• General agreement
• Since this requires making technically a breaking change (always using response_type=code), add a compatibility note that some old clients may be including response_type=id and how to handle that
• In practice, people were ignoring response_type anyway
• Authorization servers do want to be able to show a different UI to users depending on whether an access token will be issued (e.g. authorization vs authentication), but that can still be done by looking at the scopes requested