Questions about supported OAuth features

[untitaker]

Hello,

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:

data:text/html,<script>document.write(location.hash)</script>

and tell the user to copypaste the site content back into my app. Hosting an actual redirect endpoint on an actual server seems like an unnecessary security risk, should the server get hacked.

[raucao]

@untitaker

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?

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.

@untitaker

I’m asking because currently I let the server redirect to a URL like this:

data:text/html,<script>document.write(location.hash)</script>

and tell the user to copypaste the site content back into my app. Hosting an actual redirect endpoint on an actual server seems like an unnecessary security risk, should the server get hacked.

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.

[untitaker]

@raucao

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

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).

@raucao

So for native apps it would probably make sense to use something like desktop.myfancyapp.com for the URI and client id

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.

[untitaker]

@raucao

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 couldn’t find such discussions at all. Could you provide a link?

[raucao]

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.