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

[Dario Teixeira]

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

[Justin Richer]

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

Post by Dario Teixeira
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
the mobile app, the server, the UA, and the OIP. Which should
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
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt]

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

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

Post by Dario Teixeira
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
the mobile app, the server, the UA, and the OIP. Which should
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
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Dario Teixeira]

Hi,

And thanks for the prompt reply!

Post by Justin Richer
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.

So basically the mobile app performs all the steps until it gets
the ID token from the OIDC Provider, and then sends this token to
my server, who must check the signature of the token to make sure
it really came from the OIDC Provider.

I'm just wondering how durable this solution is. Suppose the OIDC
Provider would change their signing key; my server would then falsely
reject valid tokens unless it periodically checked for public key
updates (or does this never/seldom happen?).

Best regards,
Dario Teixeira

[v***@ve7jtb.com]

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: ***@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

[Brian Campbell]

+1 to the AppAuth pattern

Post by v***@ve7jtb.com
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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*Sent: *January 25, 2017 7:59 AM
*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
the mobile app, the server, the UA, and the OIP. Which should
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt (IDM)]

+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

Post by Brian Campbell
+1 to the AppAuth pattern

Post by v***@ve7jtb.com
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
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
the mobile app, the server, the UA, and the OIP. Which should
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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Torsten Lodderstedt]

+1

Post by Phil Hunt (IDM)
+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

Post by Brian Campbell
+1 to the AppAuth pattern
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 <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
Sent: January 25, 2017 7:59 AM
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
the mobile app, the server, the UA, and the OIP. Which should
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
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Dario Teixeira]

Hi,

Post by Phil Hunt (IDM)
+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.

Is the AppAuth pattern documented somewhere? There's a chance I may not
be able to use Google's libraries...

Best regards,
Dario Teixeira

[John Bradley]

https://tools.ietf.org/html/draft-ietf-oauth-native-apps

They are OpenID foundation library's not Google's. Google, Ping and a
number of others are active contributors if you look at the git
repositories.

John B.

Post by Phil Hunt (IDM)
Hi,
+1 to AppAuth

Post by Phil Hunt (IDM)
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.

Is the AppAuth pattern documented somewhere? There's a chance I may not
be able to use Google's libraries...
Best regards,
Dario Teixeira
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Dario Teixeira]

Hi,

https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2]
They are OpenID foundation library's not Google's. Google, Ping and
a number of others are active contributors if you look at the git
repositories.

Thanks for the link. Perhaps I'm missing something, but the AppAuth
pattern as described by this document represents only half the picture:
at the end of the interaction, the native app is in possession of a
token that authenticates the user. However, my server cannot accept
that token blindly!

Now, the way I would solve this is by keeping a hard-coded list of
OpenID Provider public keys on my server, which I would use to
verify that the token was indeed signed by the OIP. Correct me
if I'm wrong, but this also seems to be the recommended approach,
right?

Thanks again for your time!
Best regards,
Dario Teixeira

[Phil Hunt (IDM)]

Afaik, the client app ends up with an access token (at). It never has to deal with id tokens. That all happens by way of the oauth AS server calling oidc itself. Iow the oauth as is the oidc client.

The code in the mobile client is trivial by comparison and does not need to do id token validation.

Phil

Post by Dario Teixeira
Hi,

https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2]
They are OpenID foundation library's not Google's. Google, Ping and
a number of others are active contributors if you look at the git
repositories.

Thanks for the link. Perhaps I'm missing something, but the AppAuth
at the end of the interaction, the native app is in possession of a
token that authenticates the user. However, my server cannot accept
that token blindly!
Now, the way I would solve this is by keeping a hard-coded list of
OpenID Provider public keys on my server, which I would use to
verify that the token was indeed signed by the OIP. Correct me
if I'm wrong, but this also seems to be the recommended approach,
right?
Thanks again for your time!
Best regards,
Dario Teixeira

[John Bradley]

Justin and I are recommending different approaches.

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.

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.

My recommendation allowed you to protect your API using OAuth and to add or
modify IdP for your users without redeploying your native app.

Justin's approach avoids you needing to run a OAuth authorization server.
( He has a great open source one you could use).

I think it is a style diffrence. I think separating authorization and
authentication into two steps is cleaner and easier to maintain over the
long term.

John B.

Hi,
https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2]

Post by John Bradley
They are OpenID foundation library's not Google's. Google, Ping and
a number of others are active contributors if you look at the git
repositories.

Thanks for the link. Perhaps I'm missing something, but the AppAuth
at the end of the interaction, the native app is in possession of a
token that authenticates the user. However, my server cannot accept
that token blindly!
Now, the way I would solve this is by keeping a hard-coded list of
OpenID Provider public keys on my server, which I would use to
verify that the token was indeed signed by the OIP. Correct me
if I'm wrong, but this also seems to be the recommended approach,
right?
Thanks again for your time!
Best regards,
Dario Teixeira

[Phil Hunt (IDM)]

An seeing bad impls with justins pattern. In particular aud is not checked.

The idp has to know the rsrc aud or the as has to know the client id the mobile app is using with OP provider. It ends up being complex with room for mistakes.

Phil

Post by John Bradley
Justin and I are recommending different approaches.
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.
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.
My recommendation allowed you to protect your API using OAuth and to add or modify IdP for your users without redeploying your native app.
Justin's approach avoids you needing to run a OAuth authorization server. ( He has a great open source one you could use).
I think it is a style diffrence. I think separating authorization and authentication into two steps is cleaner and easier to maintain over the long term.
John B.

Post by Dario Teixeira
Hi,

https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2]
They are OpenID foundation library's not Google's. Google, Ping and
a number of others are active contributors if you look at the git
repositories.

Thanks for the link. Perhaps I'm missing something, but the AppAuth
at the end of the interaction, the native app is in possession of a
token that authenticates the user. However, my server cannot accept
that token blindly!
Now, the way I would solve this is by keeping a hard-coded list of
OpenID Provider public keys on my server, which I would use to
verify that the token was indeed signed by the OIP. Correct me
if I'm wrong, but this also seems to be the recommended approach,
right?
Thanks again for your time!
Best regards,
Dario Teixeira

[Dario Teixeira]

Hi,

Post by John Bradley
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.

Post by John Bradley
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.

Post by John Bradley
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

[John Bradley]

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" <***@nleyten.com>
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

Post by John Bradley
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

Post by John Bradley
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

[Dario Teixeira]

Hi,

Thanks for your reply and your patience!

Post by John Bradley
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.

Yes, that is exactly the end state I'm looking for, though there
is a chance there is some misunderstanding about the whole picture.
Allow me to summarise the current situation:

Users interact with a Native App (NA) running on a mobile phone.
This app talks with a Resource Server (RS) via a RESTful API.
Because there is private user data on the RS, the very first
interaction between the NA and the RS is a login where the NA asks
the user for an email+password combination, which it then sends
to the RS. If the email+password combination is valid, the RS
replies with an access token that must be used by the NA in all
its future requests.

This works fine, but has the disadvantage of requiring users to
manually enter their email and password. The user experience would
be much improved if users had the option to login using their Google,
Facebook, or Github account.

Now, it is my understanding that OpenID Connect is the technology
used nowadays to provide this sort of Single Sign-On. All I'm
looking for is documentation on how OIDC is actually implemented
in this scenario.

Best regards,
Dario Teixeira

[v***@ve7jtb.com]

It sounds like you are currently doing something like the OAuth resource owner flow.

Is there a Authorization server currently associated with your resource server?

If so you can change the OAuth flow you are using to the code one as described in App Auth.

You still need to authenticate the users at your server using the current username and password or via OpenID Connect to Google.

This is a two step process. If you try to combine them by trying to make your NA the connect client you may save a step in the short term but will regret it in the long term when you decide to add another identity provider like Microsoft etc.


OAuth from the NA to your server to authorize the native app, and your server to Google via Connect to Authenticate the user.

Regards
John B.




Sent from Mail for Windows 10

From: Dario Teixeira
Sent: January 27, 2017 9:16 AM
To: John Bradley
Cc: Phil Hunt; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

Hi,

Thanks for your reply and your patience!

Post by John Bradley
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.

Yes, that is exactly the end state I'm looking for, though there
is a chance there is some misunderstanding about the whole picture.
Allow me to summarise the current situation:

Users interact with a Native App (NA) running on a mobile phone.
This app talks with a Resource Server (RS) via a RESTful API.
Because there is private user data on the RS, the very first
interaction between the NA and the RS is a login where the NA asks
the user for an email+password combination, which it then sends
to the RS. If the email+password combination is valid, the RS
replies with an access token that must be used by the NA in all
its future requests.

This works fine, but has the disadvantage of requiring users to
manually enter their email and password. The user experience would
be much improved if users had the option to login using their Google,
Facebook, or Github account.

Now, it is my understanding that OpenID Connect is the technology
used nowadays to provide this sort of Single Sign-On. All I'm
looking for is documentation on how OIDC is actually implemented
in this scenario.

Best regards,
Dario Teixeira

[Phil Hunt (IDM)]

What is concerning is that many are using resource owner flow so the client app can capture the uid/password under the assumption that the client needs to control the branding experience much has been done in silo approaches of the past.

Adding to the confusion I note that many of the cloud provider site docs do not clearly distinguish mobile apps from web apps. Mobile app developers arw reading docs and telling me that oracle, google, and azure require the mobile app to register for an openid client id.

Near as I can tell it is confusion over the difference between authz and authN.

Phil

Post by v***@ve7jtb.com
It sounds like you are currently doing something like the OAuth resource owner flow.
Is there a Authorization server currently associated with your resource server?
If so you can change the OAuth flow you are using to the code one as described in App Auth.
You still need to authenticate the users at your server using the current username and password or via OpenID Connect to Google.
This is a two step process. If you try to combine them by trying to make your NA the connect client you may save a step in the short term but will regret it in the long term when you decide to add another identity provider like Microsoft etc.
OAuth from the NA to your server to authorize the native app, and your server to Google via Connect to Authenticate the user.
Regards
John B.
Sent from Mail for Windows 10
From: Dario Teixeira
Sent: January 27, 2017 9:16 AM
To: John Bradley
Cc: Phil Hunt; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
Hi,
Thanks for your reply and your patience!

Post by John Bradley
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.

Yes, that is exactly the end state I'm looking for, though there
is a chance there is some misunderstanding about the whole picture.
Users interact with a Native App (NA) running on a mobile phone.
This app talks with a Resource Server (RS) via a RESTful API.
Because there is private user data on the RS, the very first
interaction between the NA and the RS is a login where the NA asks
the user for an email+password combination, which it then sends
to the RS. If the email+password combination is valid, the RS
replies with an access token that must be used by the NA in all
its future requests.
This works fine, but has the disadvantage of requiring users to
manually enter their email and password. The user experience would
be much improved if users had the option to login using their Google,
Facebook, or Github account.
Now, it is my understanding that OpenID Connect is the technology
used nowadays to provide this sort of Single Sign-On. All I'm
looking for is documentation on how OIDC is actually implemented
in this scenario.
Best regards,
Dario Teixeira

[v***@ve7jtb.com]

A mobile app that just used Google API only would/should register for a Google client Id and use connect with Google.

A mobile app that uses only its own API should have a client ID from its own authorization server, and leave it to the authorization server to deal with the authentication.

Where it gets more grey is when the native app wants to access both Google API directly and its own REST API.

In the simple AppAuth model you could have the App owners Resource server proxy the information from Google etc as it gets a google access token if the user authenticates to google via Connect.

I think that is the safest way to do it.

Justin’s recommendation is a bit more optimised for this scenario where the Native application wants to access two resource servers. In that case with one client_id from Google it can get both a id_token and access token for Google. It uses the acess token to get the plus friends list or something like that and sends the id_token to its backend to exchange for a cookie or some other form of access token assuming the Native apps authorization/resource server doing the exchange properly validates the signature and audience in the id_token.

The original question was not about multiple RS and I don’t think that is really the most common case, so I didn’t go there in my answer as it adds more complexity to something that is complex enough.

John B.



Sent from Mail for Windows 10

From: Phil Hunt (IDM)
Sent: January 27, 2017 5:45 PM
To: ***@ve7jtb.com
Cc: Dario Teixeira; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

What is concerning is that many are using resource owner flow so the client app can capture the uid/password under the assumption that the client needs to control the branding experience much has been done in silo approaches of the past. 

Adding to the confusion I note that many of the cloud provider site docs do not clearly distinguish mobile apps from web apps. Mobile app developers arw reading docs and telling me that oracle, google, and azure require the mobile app to register for an openid client id. 

Near as I can tell it is confusion over the difference between authz and authN. 

Phil

On Jan 27, 2017, at 5:23 PM, ***@ve7jtb.com wrote:
It sounds like you are currently doing something like the OAuth resource owner flow.
 
Is there a Authorization server currently associated with your resource server?
 
If so you can change the OAuth flow you are using to the code one as described in App Auth.
 
You still need to authenticate the users at your server using the current  username and password or via OpenID Connect to Google.
 
This is a two step process.  If you try to combine them by trying to make your NA the connect client you may save a step in the short term but will regret it in the long term when you decide to add another identity provider like Microsoft etc.
 
 
OAuth from the NA to your server to authorize the native app, and your server to Google via Connect to Authenticate the user.
 
Regards
John B.
 
 
 
 
Sent from Mail for Windows 10
 
From: Dario Teixeira
Sent: January 27, 2017 9:16 AM
To: John Bradley
Cc: Phil Hunt; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
 
Hi,
 
Thanks for your reply and your patience!
 

Post by John Bradley
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.

 
Yes, that is exactly the end state I'm looking for, though there
is a chance there is some misunderstanding about the whole picture.
Allow me to summarise the current situation:
 
Users interact with a Native App (NA) running on a mobile phone.
This app talks with a Resource Server (RS) via a RESTful API.
Because there is private user data on the RS, the very first
interaction between the NA and the RS is a login where the NA asks
the user for an email+password combination, which it then sends
to the RS.  If the email+password combination is valid, the RS
replies with an access token that must be used by the NA in all
its future requests.
 
This works fine, but has the disadvantage of requiring users to
manually enter their email and password. The user experience would
be much improved if users had the option to login using their Google,
Facebook, or Github account.
 
Now, it is my understanding that OpenID Connect is the technology
used nowadays to provide this sort of Single Sign-On.  All I'm
looking for is documentation on how OIDC is actually implemented
in this scenario.
 
Best regards,
Dario Teixeira
 
 

[Dario Teixeira]

Hi,

And thanks for the prompt reply!

Post by v***@ve7jtb.com
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)

I'm not sure I followed due to the use of non-standard terminology...
What do you mean by "OAuth client" - the Relying Party? And what
about AS? Is that the Authorization Server, Application Server,
or what? (One of the frustrating aspects of learning about OAuth2
and OIDC is that not everyone uses the standard terminology.)

Post by v***@ve7jtb.com
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.

The same problem as above. I cannot find "Connect client" anywhere
on the OIDC terminology. And is IdP what the standard calls OP?

I don't mean to sound ungrateful, but when a newcomer asks a basic
question is usually a bad idea to throw a lot of jargon or non
standard terminology at them...

Best regards,
Dario Teixeira

[Dario Teixeira]

Hi,

Post by Dario Teixeira
I'm not sure I followed due to the use of non-standard terminology...
What do you mean by "OAuth client" - the Relying Party? And what
about AS? Is that the Authorization Server, Application Server,
or what? (One of the frustrating aspects of learning about OAuth2
and OIDC is that not everyone uses the standard terminology.)

Btw, I strongly suspect that AS stands for OAuth2's "Authorization
Server".
Is that correct?

Best regards,
Dario Teixeira

[v***@ve7jtb.com]

Unfortunately RFC 6749 lacks a terminology section.

From Connect we have http://openid.net/specs/openid-connect-core-1_0.html#Terminology

(AS) is a common abbreviation for Authorization server.

In sec 1.1 of OAuth https://tools.ietf.org/html/rfc6749#section-1.1

Roles are defined Client and authorization server.

Given that we have two sorts of clients one as defined by OAuth that is doing authorization only and one using the Connect extensions that is additionally doing Authentication I refer to them as OAuth client and Connect client. A connect client being a OAuth client using the Connect extensions for authentication (id_token etc).

The connect spec calls it a client and as it is the connect spec the connect part is implied.

OpenID Provider (OP) is a term going back to OpenID 1. Generic identity standards like SP-800-63-3 https://pages.nist.gov/800-63-3/sp800-63-3.html#sec3 Use the term Identity Providers (IdP) to refer to servers providing federated identity using any protocol.
(Note to NIST the term Identity provider is used but not defined in terms. Probably obvious to the authors, but not neccicarily to the reader😊

My point being that twitter, facebook and some others do not do OpenID Connect so are not technically OP.

I could use relying while in the middle of a Fido meeting as a excuse but everyone knows that even if I had taken the time it would have come out about the same.


Hope that helps.

John B.



Sent from Mail for Windows 10

From: Dario Teixeira
Sent: January 26, 2017 7:03 AM
To: ***@ve7jtb.com
Cc: ***@ietf.org
Subject: RE: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

Hi,

And thanks for the prompt reply!

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)

I'm not sure I followed due to the use of non-standard terminology...
What do you mean by "OAuth client" - the Relying Party? And what
about AS? Is that the Authorization Server, Application Server,
or what? (One of the frustrating aspects of learning about OAuth2
and OIDC is that not everyone uses the standard terminology.)

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.

The same problem as above. I cannot find "Connect client" anywhere
on the OIDC terminology. And is IdP what the standard calls OP?

I don't mean to sound ungrateful, but when a newcomer asks a basic
question is usually a bad idea to throw a lot of jargon or non
standard terminology at them...

Best regards,
Dario Teixeira