bicycle |
44 min
|
7.3 miles
|
bicycle |
Thanks for the writeup!
This is a really good point. The me
parameter in the request is really more of a hint, since the authorization server will ultimately return the final me
value at the end of the flow. The client just has to verify that it's on the same domain that was used to discover the authorization endpoint.
I implemented an IndieAuth server into my website quite a while ago, so I checked the code there. It turns out I had some code that verified the me
parameter was in the request, but it actually completely ignores that value after that. Since my site is a single-user site, it's always going to return https://aaronparecki.com/
as the profile URL at the end.
I'm inclined to make a change to the spec that says clients SHOULD include the me
in the authorization request, but that the authorization server should not require the parameter. I do like that it helps IndieAuth be more in line with OAuth 2.0.
In order to continue the OAuth compatibility, this would also mean that the code exchange (token request) step would need to work without the me
parameter as well.
This breaks the ability to use a shared token endpoint between users, since the token endpoint wouldn't know how to verify the authorization code without the me
URL at that point. The workaround for shared token endpoints is to have a per-user token endpoint URL, like tokens.indieauth.com/user.example.com/token
kind of like how I have per-user webmention endpoints on webmention.io. I'm not sure I'm super happy about this though.