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

[John Bradley <[e-mail]>]

If you are protecting your API with OAuth in my recommendation there are
two Authorization and token endpoints.  One set run by Google (as an
example) for authentication and issuing a access token for the Google
User_info endpoint, and one set run by you to issue a access token for your
resource server to your native app.

I don't think Justin is recommending using the id_token directly as an
access token for your resource server.  I think he is recommending a
internists step where it is exchanged for an access token.

Our recommendations are based on the assumption that the end state is your
app having an access token for your rest API.

If that is not what you are trying to do then we may be talking at cross
purposes.

I don't think you understand app Auth by your description.

The NA makes a request to the authorization endpoint of your OAuth server
via a view controller or custom tab, that contains a PKCE code_challange.

Your Authorization server then performs whatever authentication it wants to
in that tab.  It could do openid connect to Google, collect a password via
Web form or authenticate via SAML to Azure or a enterprise IDP the choice
is yours because we are logicly decoupling the two steps.

After authentication your Authorization endpoint returns the user to the
app via a claimed URI or custom scheme redirect with a code.
Your native app exchanges that code and the PKCE verifier for a access and
refresh token from your token endpoint so it can access your rest API on
your Resource Server.

Your native app only needs to know about your Authorization server and it's
endpoints.   The native app doesn't know how your Authorization server is
authenticating the user(resource owner) as that happens transparently in
the chrome custom tab/Safari view controller.

In my recommendation your native app has one and only one client_id for
your Authorization server and your Authorization server has the client ID
for google, Facebook and others.

In Justin's recommendation your native app would have a client ID for each
IDP that it is using.   How your back end would validate a id_token passed
by your native app that it received from a IDP is currently not part of any
specification.  That is why you have not found it.   It can be done but is
in my opinion a shortcut that leads to implimentation issues down the road.


The Google developer documentation has information on how to validate
id_tokens that they issue when used in Justin's pattern, but it is a bit
Google specific.

John B.


On Jan 27, 2017 3:25 AM, "Dario Teixeira" <[e-mail]>
wrote:

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