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

[John Bradley <[e-mail]>]

Justin and I are recommending different approaches.

My recommendation is that your app do appAuth to your server to get a
access token for your API.   Your server performs openid connect to google,
SAML to salesForce or Facebook Connect to Facebook and manages verification
keys.   If the user is authenticated by the IdP it then authorizes your app
on the device to access your API.

Justin is recommending that you build a client/relying party for each IdP
into your native app and pass the results of authentication ID_token,
Facebook signed request etc to your back end server for it to verify and
issue some cookie or webkey (probably not OAuth token) to your App for
accessing your API.

My recommendation allowed you to protect your API using OAuth and to add or
modify IdP for your users without redeploying your native app.

Justin's approach avoids you needing to run a OAuth authorization server.
( He has a great open source one you could use).

I think it is a style diffrence.  I think separating authorization and
authentication into two steps is cleaner and easier to maintain over the
long term.

John B.

On Jan 26, 2017 8:51 AM, "Dario Teixeira" <[e-mail]>
wrote:

> Hi,
>
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2]
>>
>> They are OpenID foundation library's not Google's.   Google, Ping and
>> a number of others are active contributors if you look at the git
>> repositories.
>>
>
> Thanks for the link.  Perhaps I'm missing something, but the AppAuth
> pattern as described by this document represents only half the picture:
> at the end of the interaction, the native app is in possession of a
> token that authenticates the user.  However, my server cannot accept
> that token blindly!
>
> Now, the way I would solve this is by keeping a hard-coded list of
> OpenID Provider public keys on my server, which I would use to
> verify that the token was indeed signed by the OIP.  Correct me
> if I'm wrong, but this also seems to be the recommended approach,
> right?
>
> Thanks again for your time!
> Best regards,
> Dario Teixeira
>
>