Subject: [OAUTH-WG] OAuth mobile flow

From: Security Developer <[email-masked]>
Date: Mon, 25 Mar 2013 00:47:49 +0500

Hi,

Can any body please help in describing the OAuth flow for mobile
applications?

Thanks for your time.

---

From: Shane B Weeden <[email-masked]>
Date: Mon, 25 Mar 2013 07:54:32 +1000

There are several options. I've developed a few based on azn code flow with
custom "delivery" of the code, and also resource owner password credentials
flow with a public client id (although I personally don't like the idea of
ever presenting my real credentials to the phone but business owners seem
to still want to do that).

These might give you an idea:
https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_oauth_application_demonstration
https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood
http://www.youtube.com/watch?v=cLLrZMt_hII

Regards,
Shane.

From:	Security Developer <[email-masked]>
To:	[email-masked]
Date:	25/03/2013 05:52 AM
Subject:	[OAUTH-WG] OAuth mobile flow
Sent by:	[email-masked]

Hi,

Thanks for your time._______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 25 Mar 2013 10:56:09 +0300

Hi Shane
> http://www.youtube.com/watch?v=cLLrZMt_hII

This is interesting, thank you.
I'm just wondering, how does you application decide that the access 
token is to be returned effectively out of band (which reminds me of the 
'oob' redirect uri from OAuth 1.0).

Looks like the client_id being equal to "mobileClient" (in your demo) is 
a hint.

If yes, then would you (and others) see any benefit in actually 
attempting to get an 'oob' redirect_uri value standardized ? (sorry if 
this was already raised earlier).

I can see how I can get a generic framework for supporting writing 
OAuth2 applications returning the code directly to the browser even 
without having 'oob' redirect uri - example, one can configure the 
authorization endpoint to recognize that a particular client_id requires 
an out of band delivery of the access token, etc.

FYI, I like the device code flow you linked to though appreciate the 
simplicity of returning the token to the browser in demos, etc...

Cheers, Sergey

>
> Regards,
> Shane.
>
>
>
> From:	Security Developer<[email-masked]>
> To:	[email-masked]
> _______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Mon, 25 Mar 2013 05:51:49 -0600

This little presentation from last year talks about OAuth & mobile. In a
nutshell, it discusses using the authorization code grant and a redirect
uri with a custom scheme.

http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices

---

From: Shane B Weeden <[email-masked]>
Date: Mon, 25 Mar 2013 21:55:54 +1000

What I did in my OAuth 2.0 server environment was allow a client to
self-register without a redirect URI. If they do that, then use the azncode
flow, the azncode is displayed on the screen and the resource owner figures
out for themselves how to get it to the client. Quite similar in principal
to oob in OAuth 1.0 as you suggested.  And yes - you can even try that
pattern out for yourself on my demo OAuth server. Take a read of
https://www-304.ibm.com/connections/blogs/sweeden/entry/oauth_demonstration_environment
 for details on how to get yourself a client_id. I do some custom stuff for
mobileClient - like shrink the authorization code to six lowercase chars
and reduce it's lifetime to 60 seconds so it can be more easily typed into
a phone keyboard, but ultimately that's just config.

In my demos you saw two options for delivery - type it in, or scan it in
via QR. Obviously there are several security and operational considerations
to think about, but ultimately provided the resource owner does securely
deliver the code to the client it's fundamentally ok. You can get more
elaborate than that for mobile scenarios - for example you can use a web
view of the mobile application itself to interact with the resource owner
then send the azncode back via a push notification service. This has rouge
app / password phishing implications that I don't like and is no better
from a security perspective than doing resource owner password credentials
flow with a public client id, but again it's still a possibility.

Regards,
Shane.

From:	Sergey Beryozkin <[email-masked]>
To:	[email-masked]
Date:	25/03/2013 06:01 PM
Subject:	Re: [OAUTH-WG] OAuth mobile flow
Sent by:	[email-masked]

Hi Shane

Cheers, Sergey

---

From: Justin Richer <[email-masked]>
Date: Mon, 25 Mar 2013 11:30:39 -0400

This approach is what we've implemented in a few places, most notably on 
the hReader iOS app (code is in some branch or fork of 
https://github.com/projecthreader/hReader, I'm told it's going to be 
pulled into that main branch soon though). Here we pre-register the 
hReader app with a single redirect URI of hreader://oauth (or something 
along those lines) and use that as the callback. We also use the system 
browser as opposed to embedding a web form view, as there are several 
potential security and usability problems when using an embedded browser 
that range from loss of session management to the embedded browser 
leaking the credentials to the client app (which is exactly what OAuth 
is trying to avoid, after all).

  -- Justin

On 03/25/2013 07:51 AM, Brian Campbell wrote:
> This little presentation from last year talks about OAuth & mobile. In 
> a nutshell, it discusses using the authorization code grant and a 
> redirect uri with a custom scheme.
>
> On Sun, Mar 24, 2013 at 1:47 PM, Security Developer 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     [email-masked] <mailto:[email-masked]>