Native Application workflow
dplummer opened this issue · comments
Hi,
We're looking to get oauth2-provider working for a native application:
http://tools.ietf.org/id/draft-ietf-oauth-v2-27.html#rfc.section.9
This is mentioned very vaguely in draft 10 but in later drafts they mention that the server can communicate the oauth token back through seting a cookie such as auth_token:
https://developers.google.com/accounts/docs/MobileApps
We figure in order to implement this we would need to have the option on OAuth2::Model::Client to either force there to be a redirect_uri (as it works right now) OR a bool flag for use_cookie or native.
We're going to fork the project to get the job done for us but wanted your input on how we could do this so it could get merged back in as a feature. If you've been considering adding other Client Profiles, let us know about those considerations so our implementation of Native Application can jive with it.
Can you show me where in the spec (draft 10) it mentions that cookies are a valid transport mechanism for the server to issue access tokens?
There are already several ways you can build native applications using this library. You can use the password grant type with the user's username and password, you can invent an assertion and use the assertion grant type, you can embed a web view that hosts the provider login page and listen for a redirect -- we have actually used to the latter two in our applications.
Our current policy is that this library strictly implements draft 10, as completely as it can, which allows for many types of applications. Indeed even very recent drafts don't offer anything fundamentally different in terms of semantics and capabilities. We don't want a mix of different drafts' features, since it then because very hard to reason about what it should do with various inputs.
In draft 10, under section "1.4.3. Native Application":
Utilize the end-user authorization endpoint as described in Section 3 by using an embedded user-agent. The client obtains the response by directly communicating with the embedded user-agent.
It doesn't spell out cookies explicitly, though later drafts just mention cookies as an example.
We're planning on embedding a web view in the native app, viewing the provider login page and listening for the cookie. I wasn't aware you could listen for a redirect.
That section clearly states that an application may use an external or embedded user agent "as described in Section 3", which precisely describes how the authorization endpoint works and makes no mention of cookies as valid response type.
The section also describes numerous ways you can implement this without using cookies. For example, the Songkick iPhone app embeds a WebView and listens for a URL change to its redirect URI, which is a localhost IP address. I don't know much about mobile platforms, but I would expect that any user agent that exposes raw HTTP responses or the cookie jar (both of which are inadvisable) would also let you read the current URL.
If you want to use cookies, you can take the spec's suggestion of having your redirect URI be to a server that you control, that exposes the code or token as a cookie.
I forgot to mention: one reason I would avoid cookies is because OAuth is stateless: its job is to issue an application with a token, not to grant a session to a user agent. While these might not seem that different, the cookie approach grants additional capabilities to the provider.
For example if the user visits another site that uses the same provider, the user agent automatically transmits the OAuth cookie, and the provider can automatically identify you. This lets the site implicitly identify you and log you in. This is what Facebook does and I consider it an abuse of trust.
How are you getting on with this? Do you have any further thoughts/questions, or can I close the issue?
Although we implemented cookie-based tokens, we decided to scrap that in favor of the redirect uri as you stated. Thanks for chatting with us about it.
Great, thanks for closing. Getting closer to getting a proper gem release done, finally!