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

+1 to AppAuth

One disturbing pattern I see for mobile apps relaying the idtoken is that the aud isn't checked by the AS in the Oauth exchange. This in part caused by the fact that the mobile app has two client-id identifiers. If the aud only has the clientid for the OIDC call this can be a problem if the AS doesn't know what that id is (since it didnt issue the id). If the issued id token does not have an aud value the AS can recognize it should be rejected.

Phil

> On Jan 25, 2017, at 12:24 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
> 
> +1 to the AppAuth pattern
> 
>> On Wed, Jan 25, 2017 at 12:48 PM, <ve7jtb@ve7jtb.com> 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 for Windows 10
>> 
>>  
>> 
>> From: Dario Teixeira
>> Sent: January 25, 2017 7:59 AM
>> To: oauth@ietf.org
>> 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
>> 
>> OAuth@ietf.org
>> 
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>>  
>> 
>> 
>> _______________________________________________
>> 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