Subject: Re: [OAUTH-WG] OAuth mobile flow

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 03 Apr 2013 11:18:27 +0300

Hi Shane, All,

The info below (and the links shared by others) is useful, thanks,
I have a single question really which hopefully won't be off-topic,
On 25/03/13 14:55, Shane B Weeden wrote:
> 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.

Why do you refer to the "resource owner password credentials flow" with 
a public client id ?

I see that the resource owner does indeed authenticate and then 
authorizes a given mobile client application, but effectively it is an 
authorization code flow 'minus' the redirect from the confidential 
client (which the mobile app is not in this case), so the RO simply 
directly invokes on the authorization endpoint, omitting an otherwise 
required "redirect_uri" - which in itself is not a RO password 
credentials flow.

As a side note I guess I also start appreciating how does a token 
endpoint can 'authenticate' a public client like 'mobileClient' without 
it also offering a password/etc, the assumption is that the code 
obtained earlier must've been provided to the mobile application 
securely, so effectively it is the (public) client_id + the grant 
(whatever it is, securely obtained by the client) that the token 
endpoint works with:
I'm not sure yet if it can affect the common processing path in the 
token endpoint or not, probably not, because the public client must've 
been marked as such during the registration, so the token endpoint can 
accept a client_id only (without any credentials like password), as far 
as the authentication is concerned

Thanks, Sergey

>
> 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
> On 25/03/13 00:54, Shane B Weeden wrote:
>> 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
>
> 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: Shane B Weeden <[email-masked]>
Date: Wed, 3 Apr 2013 19:04:48 +1000

The latest demo application I have actually has two modes of registration -
the one that I show in the video is indeed the authorization code flow with
manual delivery of the code however there is another registration panel
which allows the resource owner to type in their U/P and then it does
indeed use the resource owner password credentials flow with a public
client id. The reason I chose that rather than simple client_credentials
flow is that only the resource owner password credentials flow (and azn
code) issues a refresh token which is central to the pattern.

The rest of your discussion about public clients and the token endpoint
authentication is accurate - it is essential that the resource owner
securely deliver the authorization code to the client - this is really what
is identifying that instance of the client. This is written up reasonably
well in the threat model doc.

Cheers,
Shane.

From:	Sergey Beryozkin <[email-masked]>
To:	Shane B Weeden/Australia/IBM@IBMAU
Cc:	[email-masked]
Date:	03/04/2013 06:23 PM
Subject:	Re: [OAUTH-WG] OAuth mobile flow

Hi Shane, All,

Thanks, Sergey