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

+1 to the AppAuth pattern

On Wed, Jan 25, 2017 at 12:48 PM, <ve7jtb@ve7jtb.com> wrote:

> There are a number of patterns that people use.
>
>
>
> I prefer the AppAuth pattern where the native app is a OAuth client to
> your server and you are protecting your API with OAuth.   Your AS becomes a
> Connect/SAML/Twitter auth/ Facebook etc relying party and uses federated or
> local authentication to issue tokens.  (this gives your backend API access
> to user info)
>
>
>
> The other pattern is for the native app to be a Connect client to Google
> or other IdP and then passes a id_token (not access token) to your backend
> in some secure manor and your backend validates the signature on the
> id_token and that it was issued to your client (verification is essential)
> (the native app gets access to user info api)  You still have the problem
> of how you secure your API, as you need to exchange the validated id_token
> with something.   I thnk that doing this securely winds up being more
> complicated than the first option.
>
>
>
> There are other options that may not be allowed by the IdP where your
> backend is the Connect client and has a client secret.  The mobile app
> makes the request and gets the code back.   It then sends code and pkce
> verifier to it’s backend and the server exchanges it with it’s secret to
> get a id_token and access token.   You still need to add security for your
> API.  (custom scheme redirects for confidential clients may not be allowed
> depending on the Connect IdP)
>
>
>
> I think the first option is the best design that gives the best long term
> design as new IdP can be added without changing the deployed app.
>
>
>
>
>
> John B.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Dario Teixeira <dario.teixeira@nleyten.com>
> *Sent: *January 25, 2017 7:59 AM
> *To: *oauth@ietf.org
> *Subject: *[OAUTH-WG] OAuth2/OIDC for client-server mobile app
>
>
>
> Hi,
>
>
>
> I am building a mobile app and a server.  The mobile app fetches
>
> user-specific data from the server, and therefore some sort of
>
> authentication is required.  I would like to avoid the traditional
>
> username+password scheme, and instead allow users to login via
>
> Google or Facebook.  It seems the OAuth2-based OpenID Connect (OIDC)
>
> is the recommended solution nowadays, so my question is about the
>
> usage of OAuth2/OIDC in this scenario.
>
>
>
> All OIDC docs and tutorials describe the interaction between three
>
> parties: a Relying Party (RP), a User Agent (UA), and an OIDC
>
> Provider (OIP).  There are however four parties in my scenario:
>
> the mobile app, the server, the UA, and the OIP.  Which should
>
> take the role of RP? I see two different ways to do this:
>
>
>
> 1) The mobile app is the RP.  It even takes care of starting a
>
>     small web server to receive the data from the OIP.  At the end
>
>     of the interaction, the mobile app has a JWT signed by the OIP,
>
>     which it sends to the server, which must validate it using a
>
>     built-in list of OIP public signatures.
>
>
>
> 2) The server is the RP.  When the user wishes to login, the mobile
>
>     app asks the server about the OIP's authorization endpoint.
>
>     The server provide the client with an URI whose redirect_uri
>
>     parameter points to the server.  All subsequent steps are
>
>     handled by the server.
>
>
>
> Anyway, this seems like a fairly common scenario, and I would rather
>
> follow some best-practices documentation instead of cooking up my
>
> own schemes, like points 1 and 2 above.  Therefore, if there is
>
> indeed such documentation, could someone please point me towards it?
>
> And if not, which would be the recommended route, 1 or 2?
>
>
>
> Thanks in advance for your attention!
>
> Best regards,
>
> Dario Teixeira
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>