I’m currently implementing a Python client for remoteStorage and intend to use it in a desktop app. This leads to the following question: Besides implicit-grant, are there any other flows the server has to support?
I’m asking because currently I let the server redirect to a URL like this:
Implicit grant is currently the only supported OAuth flow, although there were conversations in the past about potentially adding password or pin flow to that.
I’m not sure what happens on e.g. 5apps when using a URL like that, but in general a server needs to be able to show its users proper client IDs, which are usually the hostname of the redirect URI. So for native apps it would probably make sense to use something like desktop.myfancyapp.com for the URI and client id. This is of course not a problem with your solutoin itself or with the spec, but in how server implementors choose to display authorizations and if they implement something like customizable app names etc. in the OAuth dialog.
5apps redirects properly and authentication works fine. However, if I try to launch the application from 5apps’ application listing, I get a Internal Server Error
I don’t understand why servers need to extract a client ID from the URI. I think I already provide the server with one using the client_id parameter (which is shown just fine in the application listing).
As said, I don’t think that’s a good idea, because this could result in a scenario where a compromised desktop.myfancyapp.com could be used to intercept access tokens. In the case of a browser-based application this risk already exists, but it can be avoided with desktop ones.
I’d have to search, too. Most of it was likely on IRC and in person, though. So it’s a bit difficult to find specific conversation logs. I remember talking about it at IndieWebCamp Germany with @michielbdejong and others for example.