-
Notifications
You must be signed in to change notification settings - Fork 7
-
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
Allow the 'me' parameter to authorization endpoints to be omitted? #19
Comments
Thanks for the writeup! This is a really good point. The 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 I'm inclined to make a change to the spec that says clients SHOULD include the |
In order to continue the OAuth compatibility, this would also mean that the code exchange (token request) step would need to work without the 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 |
Oh, whoops, you're right - the token endpoint also takes a It'd be easy enough to allow servers to work without Ideally, though, OAuth compatibility would be possible for "aggregate" servers like IndieAuth.com as well, since that would enable pure OAuth 2.0 consumers to trivially support all IndieAuth identities by configuring just one set of endpoints. It sounds like that mightn't be possible, though, since you obviously can't use per-user endpoints in such a situation. 🤔 |
Such multi-user services would be possible as long as all people who choose to use one as their authorization endpoint also use a token endpoint from the same service. Because if you have tight coupling between the authorization and token endpoints it is already known against which endpoint it needs to check. So where an authorization endpoint could be made so it I am not a huge fan of |
An alternative possibility would be to prescribe the format of IndieAuth access codes, as part of the standard. For instance, we could prefix the usual arbitrary implementation-specific access code blob with the expected It's certainly a messy approach, though, and one might question whether OAuth client compatibility is worth adding this complexity to IndieAuth. Additionally, making a change like this now would introduce potential incompatibility: a token endpoint that knows it can pull information out of the access code might still receive an access code from an authorization endpoint that doesn't embed information in the prescribed format, for instance. Still, prescribing a format for access codes might not be quite as unreasonable as it seems: after all, client IDs are also treated as opaque in pure OAuth 2.0, whereas in IndieAuth they have a prescribed and meaningful format. |
tl;dr The more I think about it, the more I think this parameter enables a use case that isn't really necessary. The Full details below. The different use cases that are all supported right now: Integrated Micropub/Token/Authorization EndpointsThis is the simplest case in terms of architecture, but the most amount of work for a developer. In this case, someone writes all three parts of the system. Since they are part of the same system, the mechanism by which the token endpoint validates authorization codes does not need to be standardized, it's all internal. Both my website and the Wordpress IndieAuth plugin fall under this case. Authorization Endpoint Service, Built-In Token and Micropub EndpointsIn this case, someone is building a CMS that includes a Micropub endpoint as well as a token endpoint. However, they want to speed up their development, so they use an authorization endpoint service such as indieauth.com. The client sends the auth code to the token endpoint, and since the token endpoint is part of the CMS, it already knows the only place it can go to validate the auth code is the authorization endpoint service that it's configured to use. Therefore there is no need for the Authorization Endpoint and Token Endpoint ServiceSpecifically this case is where a service provides both an authorization endpoint and token endpoint. This is the quickest path to building a Micropub endpoint, since all you need to do is build out the Micropub endpoint itself, and when any requests come in with a token, the endpoint goes and checks whether the token is valid by testing it against the token endpoint service. This is a very common case with peoples' individual websites, as it offloads the development and maintenance of the security bits to a service. I provide these as a service at indieauth.com and tokens.indieauth.com. The interesting thing though is that when a single service provides both, there is also no need for the Separate Authorization Endpoint and Token Endpoint ServicesThe only case where the The thing I'm realizing though is that this is really quite an edge case, and one that I don't think is actually very important. Typically someone who is building a Micropub endpoint themselves will first start by using an authorization/token endpoint service, and there is no benefit to them if those are two separate services. In fact it's probably easier if they are just part of the same system since it's less moving parts to think about at this stage. Later, that person can decide they want to take over issuing tokens, but still don't want to build out the UI of an authorization service. At this point, they fall under the second use case above. They build out a token endpoint into their software, and since they're using the authorization endpoint service they know where to verify authorization codes. On the other end of the spectrum, you have people who build the whole thing out themselves, like my website and the Wordpress plugin. In these cases the The particular situation that the |
Here's a quick survey of current implementations of token endpoints: Integrated Micropub/Token/Authorization Endpoints
Authorization Endpoint Service, Built-In Token and Micropub Endpoints
Authorization Endpoint and Token Endpoint Service
Standalone Token Endpoint Service
|
Discovery might be one of the most involved parts of the specification, so I am not too surprised people aren’t using Although I like how the two endpoints are uncoupled, it seems like the spec might be able to drop (P.S. Mintoken does full auth endpoint discovery and it would be trivial to use it as a standalone service, the whitelist exists only because I don’t think everyone selfhosting Mintoken wants to automatically be providing it as a service to the entire world.) |
If we drop the |
Hi I saw this issue come up in irc and just wanted to add some extra data since I just finished adding a token endpoint to dobrado. I currently check that the I also check |
Been a while, but I'd like to close the loop on this! I reviewed the discussion here and came to the same conclusion again. I'd be curious to hear how any new IndieAuth implementations in the last year land on this thread too. If you're looking at this for the first time, the tl;dr of the suggestion is:
|
There are very few token endpoints that are fully separate from authorization endpoints still. The few that exist (like Mintoken) should not be blockers on this, IMO. I am definitely 👍 on dropping Should it really be a |
Something like this would help encourage me to go with a multi-user approach for my site (more so so I can use it for more business-y reasons). Koype uses the (Originally published at: https://v2.jacky.wtf/post/619ceae3-38ca-4e9d-b223-c038abc9d0c3) |
I have now updated Mintoken to take a |
I'm making an IndieAuth plugin for ProcessWire. Like the WordPress plugin, it verifies |
I think I misunderstood this topic back in that earlier survey of different implementations. Micro.blog does require My question is about @aaronpk's comment:
Is that still true? It seems like you could still have a single endpoint for multiple users, if the server knew which user a token was for. I'd rather not change my IndieAuth endpoints, so want to make sure I understand this. |
It is still true if we are talking about truly separate token endpoints, like tokens.indieauth.com or a public hosted version of Mintoken. These token endpoints need a way of knowing where they can go to verify a If your token endpoint is integrated with the authorization endpoint in some other way. Like both having access to the same database, or just being part of the same software in general, you probably do not need this. The token endpoint can just check the The fact that most implementations already share back-end infrastructure is why #44 is up for consideration too. It may not make sense to try and specify all the steps that are neccessary for a token endpoint to check things against the authorization endpoint, when implementation chose to take a back road instead of the overhead of extra HTTP calls. |
@Zegnat Thanks for the clarification! That makes sense. Micro.blog does handle both parts of IndieAuth so it doesn't sound like it will be an issue for me. |
This was discussed at the IndieAuth Popup Session, and the outcome of the discussion was:
|
I seem to have misremembered something about our discussion during the call, or thought we were talking about specifically dropping the |
That is what was confusing me on the call. I'm in favor of dropping |
I should expand on this since I guess "much bigger change" is open to debate. For the authorization request, I currently check that Dropping
As I write this out, I'm leaning toward that 2nd option and no longer relying on |
Okay, I reviewed this again, this time not at the end of a long day, and I see what happened. This issue started out as a discussion about dropping So, I still agree with my initial comment from earlier: #19 (comment)
How does this affect existing services?
So in some cases the There is precedent for this in OpenID Connect as well. There is a parameter called
I would like to propose that we make the |
This sounds great. Thanks @aaronpk. |
One similar thing to this issue is that technically the user doesn't need to enter their full profile URL in the client, they only need to enter enough to discover their authorization endpoint. This provides an interesting optimization of the UX that an application can do. The application can ask the user to enter the "server name" or "domain name" of their website rather than their full URL. For micro.blog the user can enter just This also matches the user model of Mastodon more closely, where users typically don't think of their full Mastodon profile URL as their identifier, but they know their username and server name. The user can enter the server name such as |
Would that in turn mean that the If that is a case we expect authorization endpoint to take consideration of, |
Well the client still needs to return a fully qualified URL such as I do agree that |
Not in favour of a rename, no. But the Authorization Request step currently describes |
Yes I'd like to change the wording there to suggest that it is a hint, and that it may not be the user's full URL. |
Interesting. I'll update Micro.blog to support this. I could imagine someone accidentally entering Does this cause any problems for the spec requirement that the |
Mmm. I think that is right. The returned |
Actually this is a good question. It's meant to be an exact match, so But that's the other reason clients "should" provide the Without the |
In that case, I don't think I'll support the user entering |
So summing up, is the following the change proposal for
This sounds like it would be backwards compatible with current IndieAuth, clearing up the confusion around what to do with |
I added this text as well as some additional clarifications in this commit |
Looks fine to me! I really think that other than the few clarifying lines this issue does not take much to close out :) |
This has been added to the spec! https://indieauth.spec.indieweb.org/#authorization-request |
IndieAuth, being an extension of OAuth 2.0, is almost compatible with "pure" OAuth 2.0 clients. Assuming that unrecognised parameters are ignored on both ends, the only discrepancy is that under IndieAuth, the initial request to the user's authorization endpoint requires an additional
me=https://some.url.here/
query parameter.This parameter is valuable as a convenience for some kinds of authorization endpoint. In particular, if the parameter were not used, authenticating using IndieAuth.com would involve entering your domain twice: once into the site you're really authenticating with, and once again when you get to IndieAuth.com. Clearly this workflow is more annoying, but it is no less secure.
While true IndieAuth clients should always include
me
for compatibility with multiple-user endpoints like IndieAuth.com, allowing IndieAuth servers to work without this parameter is viable - the correctme
value can be determined from session data on the server itself - and allows vanilla OAuth 2.0 clients to interface with the server directly.For example, the advanced HTTP client applications Postman and Paw both support OAuth 2.0 authorisation, but not IndieAuth authorisation. When configured with an IndieAuth site's authorization and token endpoints, both apps almost work, save for the missing
me
parameter. Here's how I configured each app for my site:If the server allows
me
to be omitted, then both apps can smoothly perform the OAuth dance and receive a valid token, perfect for testing the site's various other endpoints. :)Additionally, many OAuth client libraries use a three-step approach to achieve both authorisation and authentication: the standard authorization and token endpoints, followed by an "info" endpoint to discover the authorised user's identity. IndieAuth quite easily supports this flow too: the token endpoint can trivially also be used as an info endpoint. So allowing the omission of
me
would also enable these libraries to authenticate with IndieAuth-enabled servers.To sum up: in order to improve compatibility with OAuth 2.0 clients, I think the IndieAuth standard should clarify that the purpose of the initial
me
parameter is convenience, not security, and that servers are allowed to make it optional if desired.The text was updated successfully, but these errors were encountered: