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: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
