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

[<[e-mail]>]

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 for Windows 10

From: Dario Teixeira
Sent: January 25, 2017 7:59 AM
To: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth