Re: [OAUTH-WG] Recommendations for browser-based apps

[Aaron Parecki]

Yeah, I guess the terminology now is "single-page apps."

These apps don’t by definition need offline access as they go away when the
> user is not present.


I'm sure there are plenty of cases of people creating SPAs that store the
access token in a cookie or Local Storage and resume that session when the
user loads the browser again. Not that it's necessarily a good idea, but
I'm sure it's been done.

It seems like avoiding the concerns of the Implicit flow described in
the threat
model  by using the
authorization code flow is a good idea anyway, especially as these
single-page apps start to look more and more like native apps.

Basically I'm struggling to think of a reason to recommend using the
Implicit flow when it's not much harder to use the authorization code flow
in the first place.


Aaron Parecki
aaronparecki.com
@aaronpk 


On Wed, Jan 25, 2017 at 4:24 PM,  wrote:

> It depends on what you mean by browser based apps.
>
>
>
> In general for single page apps that are java script executing in the
> browser dom, the recommendation would be implicit flow.
>
>
>
> These apps don’t by definition need offline access as they go away when
> the user is not present.
>
>
>
> We have talked about developing guidance for single page apps, but don’t
> have anything yet.
>
>
>
> I think it needs to be thought through again now that new things like
> service workers are available, and we will eventually get token binding in
> the browser (hint it is on in IE and Edge on windows 10 preview and in
> Chrome behind a feature flag now)
>
>
>
> You could use the PKCE appAuth type flow in a SPA app if you have the
> correct CORS setup.
>
> I however cant at this point say that you are getting improved security
> for the extra work in that environment.
>
>
>
> John B.
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Aaron Parecki 
> *Sent: *January 25, 2017 3:12 PM
> *To: *OAuth WG 
> *Subject: *[OAUTH-WG] Recommendations for browser-based apps
>
>
>
> Thanks to the new "OAuth 2.0 for Native Apps" and PKCE documents, we have
> a solid recommendation for how to do OAuth 2.0 for native apps.
>
>
>
> Given that PKCE is intended for "public clients" and not specifically
> native apps, I'm wondering where that leaves browser-based apps. The core
> spec still says that the implicit grant is recommended for browser-based
> apps, but it's looking like the recommendation is to use the authorization
> code flow + PKCE with no secret for browser-based apps.
>
>
>
> Am I correct in thinking that the general recommendation would be to use
> the authorization code flow with no secret, and even better to use PKCE for
> browser-based apps?
>
>
> 
>
> Aaron Parecki
>
> aaronparecki.com
>
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Recommendations for browser-based apps

[ve7jtb]

It depends on what you mean by browser based apps.

In general for single page apps that are java script executing in the browser 
dom, the recommendation would be implicit flow. 

These apps don’t by definition need offline access as they go away when the 
user is not present.

We have talked about developing guidance for single page apps, but don’t have 
anything yet.

I think it needs to be thought through again now that new things like service 
workers are available, and we will eventually get token binding in the browser 
(hint it is on in IE and Edge on windows 10 preview and in Chrome behind a 
feature flag now) 

You could use the PKCE appAuth type flow in a SPA app if you have the correct 
CORS setup.
I however cant at this point say that you are getting improved security for the 
extra work in that environment.

John B.
Sent from Mail for Windows 10

From: Aaron Parecki
Sent: January 25, 2017 3:12 PM
To: OAuth WG
Subject: [OAUTH-WG] Recommendations for browser-based apps

Thanks to the new "OAuth 2.0 for Native Apps" and PKCE documents, we have a 
solid recommendation for how to do OAuth 2.0 for native apps. 

Given that PKCE is intended for "public clients" and not specifically native 
apps, I'm wondering where that leaves browser-based apps. The core spec still 
says that the implicit grant is recommended for browser-based apps, but it's 
looking like the recommendation is to use the authorization code flow + PKCE 
with no secret for browser-based apps.

Am I correct in thinking that the general recommendation would be to use the 
authorization code flow with no secret, and even better to use PKCE for 
browser-based apps?



Aaron Parecki
aaronparecki.com




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Recommendations for browser-based apps

[Aaron Parecki]

Thanks to the new "OAuth 2.0 for Native Apps" and PKCE documents, we have a
solid recommendation for how to do OAuth 2.0 for native apps.

Given that PKCE is intended for "public clients" and not specifically
native apps, I'm wondering where that leaves browser-based apps. The core
spec still says that the implicit grant is recommended for browser-based
apps, but it's looking like the recommendation is to use the authorization
code flow + PKCE with no secret for browser-based apps.

Am I correct in thinking that the general recommendation would be to use
the authorization code flow with no secret, and even better to use PKCE for
browser-based apps?


Aaron Parecki
aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[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

> On Jan 25, 2017, at 12:24 PM, Brian Campbell  
> wrote:
> 
> +1 to the AppAuth pattern
> 
>> On Wed, Jan 25, 2017 at 12:48 PM,  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
> 

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

[Brian Campbell]

+1 to the AppAuth pattern

On Wed, Jan 25, 2017 at 12:48 PM,  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

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

[ve7jtb]

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[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


On 1/25/2017 9:22 AM, Dario Teixeira wrote:

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-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

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