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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
