There is a problem here that the endpoint definitions for OpenID Connect and OAuth are different depending on whether an app is a client to OIDC OP or OAuth AS.
Phil Oracle Corporation, Identity Cloud Services & Identity Standards @independentid www.independentid.com <http://www.independentid.com/>[email protected] <mailto:[email protected]> > On Jan 25, 2017, at 10:26 AM, Justin Richer <[email protected]> wrote: > > I would recommend making the mobile app the RP, and having the server be an > additional protected resource that accepts access tokens from the mobile app. > This is how it's commonly handled, and there are libraries (such as Google's > AppAuth) that handle most of these interactions. > > -- Justin > > > On 1/25/2017 9:22 AM, Dario Teixeira wrote: >> 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
