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

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/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>

> On Jan 25, 2017, at 10:26 AM, Justin Richer <jricher@mit.edu> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth