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<sberyoz...@gmail.com>
To: oauth@ietf.org
Date: 25/03/2013 06:01 PM
Subject: Re: [OAUTH-WG] OAuth mobile flow
Sent by: oauth-boun...@ietf.org
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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
