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

[Dario Teixeira <[e-mail]>]

Hi,

> Justin and I are recommending different approaches.

Thanks for the clarification.  To make sure there's no further
confusion, allow me to define the various parties involved in
the exchange:

  * Native App (NA): the native application running on the user's
    phone. This application is written by me.

  * Resource Server (RS): the server application that the NA wishes
    to communicate with. This application is also written by me,
    and offers a RESTful API to the NA.

  * OpenID Provider (OP): a 3rd party organization like Google that
    is able to authenticate users.

  * Authorization Endpoint (AE): a server run by the OP.

  * Token Endpoint (TE): another server run by the OP.

  * User Agent (UA): a browser running on the user's phone.


> Justin is recommending that you build a client/relying party for
> each IdP into your native app and pass the results of authentication
> ID_token, Facebook signed request etc to your back end server for
> it to verify and issue some cookie or webkey (probably not OAuth
> token) to your App for accessing your API.

To make sure I understood it correctly, here are the steps involved
in Justin's scheme:

  1. The NA asks the UA to show a webpage with links such as "Login
     with Google" or "Login with Facebook".  Clicking on those links
     executes a request to the AE of the corresponding OP.
     The 'redirect_uri' parameter of the request points to the NA.

  2. The user clicks on one of the links shown in the UA.

  3. The AE sends the NA an Authorization Code.

  4. The NA executes a request to the TE of the OP, sending it the
     Authorization Code obtained in step 3. The 'redirect_uri'
     parameter of the request points to the NA.

  5. The TE sends the NA an ID token.

  6. The NA sends the RS this ID token.

  7. The RS validates the ID token by checking its signature against
     a hardcoded list of OP public keys. If valid, it sends back to
     the NA a cookie that can be used in future requests.

It's pretty straightforward, but there's a bunch of corner cases
surrounding expiration of tokens and making sure the list of OP
public keys are synchronised.


> My recommendation is that your app do appAuth to your server to get
> a access token for your API.   Your server performs openid connect
> to google, SAML to salesForce or Facebook Connect to Facebook and
> manages verification keys.   If the user is authenticated by the
> IdP it then authorizes your app on the device to access your API.

Again, please allow me to describe the various steps involved in
the AppAuth scheme, to make sure we're on the same page:

  1. The NA executes a request to the RS, telling it the user wishes
     to login.  It also sends the RS a secret S to be used later.

  2. The RS replies with a webpage with links such as "Login with
     Google" or "Login with Facebook".  The 'redirect_uri' present
     on those links points towards the RS.

  3. The NA asks the UA to show the webpage it received in step 2.

  4. The user clicks on one of the links shown in the UA.

  5. The AE sends the RS an Authorization Code.

  6. The RS executes a request to the TE of the OP, sending it the
     Authorization Code obtained in step 5. The 'redirect_uri'
     parameter of the request points to the RS.

  7. The TE sends the RS an ID token.

  8. The RS validates the ID token by checking its signature against
     a hardcoded list of OP public keys. It now knows that any
     future requests from the NA with secret S are authentic.

There's an obvious problem with this scheme: there's no way for the
NA to know when and if the authentication was successful.  Did I
miss something, or is this a know problem with the AppAuth scheme?

Thanks again for your attention!
Best regards,
Dario Teixeira