-
Notifications
You must be signed in to change notification settings - Fork 7
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
Consolidate authentication/authorization sections because they are actually the same #42
Comments
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 Could the spec be reworded such that it says that |
I suspect most implementations actually never did |
Ah, good to know. In that case, do you recommend that on Authl I just switch to |
Selfauth is pretty strict with it. If you provide scopes alongside 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)! |
This was discussed at the IndieAuth Popup Session, and the outcome of the discussion was:
|
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 #41The text was updated successfully, but these errors were encountered: