Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

["Phil Hunt (IDM)" <[e-mail]>]

What is concerning is that many are using resource owner flow so the client app can capture the uid/password under the assumption that the client needs to control the branding experience much has been done in silo approaches of the past. 

Adding to the confusion I note that many of the cloud provider site docs do not clearly distinguish mobile apps from web apps. Mobile app developers arw reading docs and telling me that oracle, google, and azure require the mobile app to register for an openid client id. 

Near as I can tell it is confusion over the difference between authz and authN. 

Phil

> On Jan 27, 2017, at 5:23 PM, [e-mail] wrote:
> 
> It sounds like you are currently doing something like the OAuth resource owner flow.
>  
> Is there a Authorization server currently associated with your resource server?
>  
> If so you can change the OAuth flow you are using to the code one as described in App Auth.
>  
> You still need to authenticate the users at your server using the current  username and password or via OpenID Connect to Google.
>  
> This is a two step process.  If you try to combine them by trying to make your NA the connect client you may save a step in the short term but will regret it in the long term when you decide to add another identity provider like Microsoft etc.
>  
>  
> OAuth from the NA to your server to authorize the native app, and your server to Google via Connect to Authenticate the user.
>  
> Regards
> John B.
>  
>  
>  
>  
> Sent from Mail for Windows 10
>  
> From: Dario Teixeira
> Sent: January 27, 2017 9:16 AM
> To: John Bradley
> Cc: Phil Hunt; IETF oauth WG
> Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
>  
> Hi,
>  
> Thanks for your reply and your patience!
>  
> > Our recommendations are based on the assumption that the end state
> > is your app having an access token for your rest API.
> > If that is not what you are trying to do then we may be talking at
> > cross purposes.
>  
> Yes, that is exactly the end state I'm looking for, though there
> is a chance there is some misunderstanding about the whole picture.
> Allow me to summarise the current situation:
>  
> Users interact with a Native App (NA) running on a mobile phone.
> This app talks with a Resource Server (RS) via a RESTful API.
> Because there is private user data on the RS, the very first
> interaction between the NA and the RS is a login where the NA asks
> the user for an email+password combination, which it then sends
> to the RS.  If the email+password combination is valid, the RS
> replies with an access token that must be used by the NA in all
> its future requests.
>  
> This works fine, but has the disadvantage of requiring users to
> manually enter their email and password. The user experience would
> be much improved if users had the option to login using their Google,
> Facebook, or Github account.
>  
> Now, it is my understanding that OpenID Connect is the technology
> used nowadays to provide this sort of Single Sign-On.  All I'm
> looking for is documentation on how OIDC is actually implemented
> in this scenario.
>  
> Best regards,
> Dario Teixeira
>  
>