+1 to the AppAuth pattern On Wed, Jan 25, 2017 at 12:48 PM, <[email protected]> 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 <[email protected]> > *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 > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
