I wrote a blog post about OAuth 2.0 AS server discovery from just the resource server.
https://www.tuxed.net/fkooman/blog/as_discovery.html
What do you guys think? Is this helpful for remoteStorage spec as well? Does this need to pushed towards IETF as well?
If I understand this correctly, it would allow a remoteStorage webfinger record to omit the auth URL key and get it from a failed first request to the storage then.
I’m not sure it provides very much value to only omit the one key with the drawback of having to parse the information from requests later on (as opposed to caching it immediately, so that the connect and wireclient parts only fulfill their respective concerns in a client implementation).
In general, I think it might be a useful addition to https://tools.ietf.org/html/rfc6750#section-3. Pretty easy to test in the wild without hurting anyone, of course. We’d be willing to add it to 5apps Storage 401s, if it helps you with real-world testing.
In the case of remoteStorage it is less useful than the general case. For remoteStorage you need to do webfinger anyway, so you may as well take it from there.
For the general case you may or may not also need to discover the token endpoint (authorization code profile) and you may not know which scope is required to perform a certain operation.
If all you know is the resource server URL then this proposal makes more sense. For example for the Indieweb you may advertise the “micropub” endpoint on your homepage, but they you don’t need to advertise the authorization endpoint, the token endpoint and the required scope for that particular call.
I guess you are right, for remoteStorage it makes less sense to implement this as there is only an authorization endpoint and you know the required scope beforehand.
It could potentially still provide some benefit in the context of making remoteStorage services interoperable on the wider Web.
I like the idea of the storage itself being as much of a standard HTTP service as possible. We could thus also add the scope to storage 401s (either use :rw by default or actually use :r for GETs and rw for PUTs and DELETEs) in addition to the AS details.
I just also ran into this problem while writing a desktop RS app. Currently I make the user provide the OAuth path, but I’d be interested in how the Javascript library magically detects the correct path.
It is language independent. If the library is able to read the fields from the WWW-Authenticate header, which it should anyway to detect the error returned from the OAuth server (e.g. when the user does not authorize the client) so it should be quite easy to implement that.
I see, thanks. This is what I couldn’t find in the example OAuth flow in the RS spec.
EDIT: Nevermind, further up in the WebFinger section, the OAuth endpoint is also exposed.