Subject: [OAUTH-WG] Google's use of Implicit Grant Flow

From: Jim Manico <[email-masked]>
Date: Thu, 16 Feb 2017 12:44:42 -1000

Hello Folks,

I noticed that Google supports the OAuth 2 Implicit flow for third-party
JavaScript applications.

https://developers.google.com/identity/protocols/OAuth2UserAgent

Isn't this generally discouraged from a security POV? *Is there a better
OAuth 2 flow for third party SPA applications?*

Aloha,

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Bill Burke <[email-masked]>
Date: Thu, 16 Feb 2017 18:13:38 -0500

For our IDP [1], our javascript library uses the auth code flow, but 
requires a public client, redirect_uri validation, and also does CORS 
checks and processing.  We did not like Implicit Flow because

1) access tokens would be in the browser history

2) short lived access tokens (seconds or minutes) would require a 
browser redirect

I'd be really curious to hear other's thoughts though.

[1] http://keycloak.org

On 2/16/17 5:44 PM, Jim Manico wrote:
>
> Hello Folks,
>
> I noticed that Google supports the OAuth 2 Implicit flow for 
> third-party JavaScript applications.
>
> Isn't this generally discouraged from a security POV? *Is there a 
> better OAuth 2 flow for third party SPA applications?*
>
> Aloha,
> -- 
> Jim Manico
> Manicode Security
> https://www.manicode.com
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Josh Mandel <[email-masked]>
Date: Thu, 16 Feb 2017 21:22:28 -0500

We've taken a similar approach for SMART Health IT [1], using the code flow
for public clients to support in-browser apps, and <1h token lifetime. (We
also allow these public clients to request a limited-duration refresh token
by asking for an "online_access" scope; these refresh tokens stop working
when the user's session with the AS ends — useful in systems where that
session concept is meaningful.)

  -Josh

1. http://docs.smarthealthit.org/authorization/

On Thu, Feb 16, 2017 at 6:13 PM, Bill Burke <[email-masked]> wrote:

> 2) short lived access tokens (seconds or minutes) would require a browser
> redirect
>
> Manicode Securityhttps://www.manicode.com
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: <[email-masked]>
Date: Fri, 17 Feb 2017 16:03:52 +0000

Same for Deutsche Telekom. Our javascript clients also use code flow with CORS processing and of course redirect_uri validation.

Best regards

Sebastian

Von: OAuth [mailto:[email-masked]] Im Auftrag von Bill Burke
Gesendet: Freitag, 17. Februar 2017 00:14
An: [email-masked]
Betreff: Re: [OAUTH-WG] Google's use of Implicit Grant Flow

For our IDP [1], our javascript library uses the auth code flow, but requires a public client, redirect_uri validation, and also does CORS checks and processing.  We did not like Implicit Flow because

2) short lived access tokens (seconds or minutes) would require a browser redirect

[1] http://keycloak.org

Hello Folks,

I noticed that Google supports the OAuth 2 Implicit flow for third-party JavaScript applications.

Isn't this generally discouraged from a security POV? Is there a better OAuth 2 flow for third party SPA applications?
Aloha,

--

Jim Manico

Manicode Security

https://www.manicode.com

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Jim Manico <[email-masked]>
Date: Fri, 17 Feb 2017 07:40:25 -1000

Thank you to those answering my question on implicit for JS clients.

The responses so far seem to represent what the security world is
saying  about the implicit grant - keep away from it other than for a
few OIDC use cases.

Does anyone think it would be valuable to author a brief RFC to give
clear OAuth 2 recommendations for JavaScript client developers?

I mean - the OAuth 2 body of work just needs a few more RFC's, right? :)

Aloha, Jim

On 2/17/17 6:03 AM, [email-masked] wrote:
>
> Same for Deutsche Telekom. Our javascript clients also use code flow
> with CORS processing and of course redirect_uri validation.
>
>  
>
> Best regards
>
>  
>
> Sebastian
>
>  
>
> *Von:*OAuth [mailto:[email-masked]] *Im Auftrag von *Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* [email-masked]
> *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>
>  
>
>     [email-masked] <mailto:[email-masked]>
>

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Adam Lewis <[email-masked]>
Date: Fri, 17 Feb 2017 11:42:54 -0600

+1000

We are currently going through internal turmoil over the usage of implicit
grant for ua-based apps.  The webapp case is well understood and the WG has
work in progress to define best practices for native apps.  Having one for
ua-based apps would be HUGELY beneficial

On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico <[email-masked]> wrote:

> The responses so far seem to represent what the security world is saying
> about the implicit grant - keep away from it other than for a few OIDC use
> cases.
>
> Does anyone think it would be valuable to author a brief RFC to give clear
> OAuth 2 recommendations for JavaScript client developers?
>
> Same for Deutsche Telekom. Our javascript clients also use code flow with
> CORS processing and of course redirect_uri validation.
>
>
>
> Best regards
>
>
>
> Sebastian
>
>
>
> *Von:* OAuth [mailto:[email-masked] <[email-masked]>] *Im
> Auftrag von *Bill Burke
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__keycloak.org&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=YExyuyZO5YNpSvS3mEUG5pjKAjRXXVT8Xvk8hIb-Efw&e=>
>
>
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.google.com_identity_protocols_OAuth2UserAgent&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=_Mig-zmCt1y9dZpCece1dqby3VmcZVOu2JPcmAwzwKU&e=>
>
> https://www.manicode.com <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.manicode.com&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=H8pXLA4TE27vW-gz5Sbr9VOUP-KZMmd-gQ-okH4ohMU&e=>
>
>
>
>
> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=jAjifWdP3vqnDgWricLE62R9_d0BQReWRUitqM5S1JU&e=>
>
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=jAjifWdP3vqnDgWricLE62R9_d0BQReWRUitqM5S1JU&e=>
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.manicode.com&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=H8pXLA4TE27vW-gz5Sbr9VOUP-KZMmd-gQ-okH4ohMU&e=>
>
>

---

From: Dominick Baier <[email-masked]>
Date: Fri, 17 Feb 2017 13:02:51 -0500

Given a solid client library for JS, I think implicit flow is OK to use.

But I agree that there are many “home grown” implementation out there that
are not secure - and the necessary JS code to write a good client is not
necessarily the “pit of success”.

You should give this lib a go (it’s also a certified RP):

https://github.com/IdentityModel/oidc-client-js

Many people argue that handling the protocol and crypto pieces in JS is
problematic (and I agree if no proper lib is used for that) - but at then
end of the day the access token will end up in the browser - and a sloppy
developer (e.g. not using CSP) will always write bad code that might lead
to leaking a token.

-------
Dominick Baier

On 17 February 2017 at 18:43:25, Adam Lewis (
[email-masked]) wrote:

+1000

On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico <[email-masked]> wrote:

> * Von:* OAuth [mailto:[email-masked] <[email-masked]>] *Im
> Auftrag von* Bill Burke

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 17 Feb 2017 10:05:27 -0800

Can you describe the aspects that make a JS client library "solid"? This is
what I think would be useful to see written up in a document like the
Native Apps one.

It's interesting to me that so many of you have independently opted to use
the auth code flow for Javascript apps. I think that's a sign that it's a
better recommendation than the implicit flow for JS apps.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

On Fri, Feb 17, 2017 at 10:02 AM, Dominick Baier <[email-masked]>
wrote:

> On 17 February 2017 at 18:43:25, Adam Lewis (adam.lewis@motorolasolutions.
> com) wrote:
>
> +1000
>

---

From: Jim Manico <[email-masked]>
Date: Fri, 17 Feb 2017 08:06:20 -1000

> Given a solid client library for JS, I think implicit flow is OK to use.

If you can, can you dig deeper here? What is it about this particular
library that makes its use of the OAuth 2 implicit flow secure? Signed
messages? Only supports registered clients? Something else?

Aloha, Jim

On 2/17/17 8:02 AM, Dominick Baier wrote:
> But I agree that there are many “home grown” implementation out there
> that are not secure - and the necessary JS code to write a good client
> is not necessarily the “pit of success”.
>
> Many people argue that handling the protocol and crypto pieces in JS
> is problematic (and I agree if no proper lib is used for that) - but
> at then end of the day the access token will end up in the browser -
> and a sloppy developer (e.g. not using CSP) will always write bad code
> that might lead to leaking a token.
>
> -------
> Dominick Baier
>
> On 17 February 2017 at 18:43:25, Adam Lewis
> ([email-masked]
> <mailto:[email-masked]>) wrote:
>
>> +1000
>>
>> We are currently going through internal turmoil over the usage of
>> implicit grant for ua-based apps.  The webapp case is well understood
>> and the WG has work in progress to define best practices for native
>> apps.  Having one for ua-based apps would be HUGELY beneficial
>>
>>
>>
>> On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     saying  about the implicit grant - keep away from it other than
>>     for a few OIDC use cases.
>>
>>     Does anyone think it would be valuable to author a brief RFC to
>>     give clear OAuth 2 recommendations for JavaScript client developers?
>>
>>     On 2/17/17 6:03 AM, [email-masked]
>>     <mailto:[email-masked]> wrote:
>>>
>>>     Same for Deutsche Telekom. Our javascript clients also use code
>>>     flow with CORS processing and of course redirect_uri validation.
>>>
>>>      
>>>
>>>     Best regards
>>>
>>>      
>>>
>>>     Sebastian
>>>
>>>      
>>>
>>>     *Von:* OAuth [mailto:[email-masked]] *Im Auftrag von*
>>>     Bill Burke
>>>     *An:* [email-masked] <mailto:[email-masked]>
>>>     For our IDP [1], our javascript library uses the auth code flow,
>>>     but requires a public client, redirect_uri validation, and also
>>>     does CORS checks and processing.  We did not like Implicit Flow
>>>     because
>>>
>>>         Isn't this generally discouraged from a security POV? *Is
>>>         there a better OAuth 2 flow for third party SPA applications?*
>>>
>>>         Aloha,
>>>
>>>         -- 
>>>
>>>         Jim Manico
>>>
>>>         Manicode Security
>>>
>>>         https://www.manicode.com
>>>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.manicode.com&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=H8pXLA4TE27vW-gz5Sbr9VOUP-KZMmd-gQ-okH4ohMU&e=>
>>>
>>>
>>>
>>>
>>>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=jAjifWdP3vqnDgWricLE62R9_d0BQReWRUitqM5S1JU&e=>
>>>
>>>      
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=jAjifWdP3vqnDgWricLE62R9_d0BQReWRUitqM5S1JU&e=>
>>     --  
>>     Jim Manico
>>     Manicode Security
>>     https://www.manicode.com
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.manicode.com&d=DwMD-g&c=q3cDpHe1hF8lXU5EFjNM_A&r=hS3A5qzQnW1hxYBhPrxNW10ESeDiiiRwR8H84JHIXTI&m=IfM1P0zp986kOQNk7-NwlgfRZMq5MppK0kISXhIOF_s&s=H8pXLA4TE27vW-gz5Sbr9VOUP-KZMmd-gQ-okH4ohMU&e=>
>>
>>     _______________________________________________ OAuth mailing
>>     list [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/oauth> 
>>
>> _______________________________________________ OAuth mailing list
-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Jim Manico <[email-masked]>
Date: Fri, 17 Feb 2017 08:07:33 -1000

+1 I'm with you Aaron. I am not as well versed as other members of this
standard body in OAuth but I would be happy to help build this document
if folks with more experience would help.

- Jim

On 2/17/17 8:05 AM, Aaron Parecki wrote:
> Can you describe the aspects that make a JS client library "solid"?
> This is what I think would be useful to see written up in a document
> like the Native Apps one.
>
> It's interesting to me that so many of you have independently opted to
> use the auth code flow for Javascript apps. I think that's a sign that
> it's a better recommendation than the implicit flow for JS apps.
>
> ----
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com>
> On Fri, Feb 17, 2017 at 10:02 AM, Dominick Baier
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     But I agree that there are many “home grown” implementation out
>     there that are not secure - and the necessary JS code to write a
>     good client is not necessarily the “pit of success”.
>
>     <https://github.com/IdentityModel/oidc-client-js>
>
>     Many people argue that handling the protocol and crypto pieces in
>     JS is problematic (and I agree if no proper lib is used for that)
>     - but at then end of the day the access token will end up in the
>     browser - and a sloppy developer (e.g. not using CSP) will always
>     write bad code that might lead to leaking a token.
>
>     -------
>     Dominick Baier
>
>>     implicit grant for ua-based apps.  The webapp case is well
>>     understood and the WG has work in progress to define best
>>     practices for native apps.  Having one for ua-based apps would be
>>     HUGELY beneficial
>>
>>
>>
>>         The responses so far seem to represent what the security
>>         world is saying  about the implicit grant - keep away from it
>>         other than for a few OIDC use cases.
>>
>>         Does anyone think it would be valuable to author a brief RFC
>>         to give clear OAuth 2 recommendations for JavaScript client
>>         developers?
>>
>>>         Same for Deutsche Telekom. Our javascript clients also use
>>>         code flow with CORS processing and of course redirect_uri
>>>         validation.
>>>
>>>          
>>>
>>>         Best regards
>>>
>>>          
>>>
>>>         Sebastian
>>>
>>>          
>>>
>>>         *Von:* OAuth [mailto:[email-masked]] *Im Auftrag
>>>         von* Bill Burke
>>>         For our IDP [1], our javascript library uses the auth code
>>>         flow, but requires a public client, redirect_uri validation,
>>>         and also does CORS checks and processing.  We did not like
>>>         Implicit Flow because
>>>
>>>             Isn't this generally discouraged from a security POV?
>>>             *Is there a better OAuth 2 flow for third party SPA
>>>             applications?*
>>>
>>>             Aloha,
>>>
>>>             -- 
>>>
>>>             Jim Manico
>>>
>>>             Manicode Security
>>>
>>>             https://www.manicode.com
-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Dominick Baier <[email-masked]>
Date: Fri, 17 Feb 2017 13:25:11 -0500

Well - first of all that it uses all the recommend validation techniques

- state validation + protection
- nonce validation
- at_hash validation
- identity token validation
- discovery

+ solid and tested JS code

I don’t see extra value for a JS client in things like “signed requests” -
as I said before - at the end of the day the access token will end up in
the browser. Regardless how secure you made the authentication request in
the first place.

-------
Dominick Baier

Aloha, Jim

-------
Dominick Baier

+1000

On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico <[email-masked]> wrote:

> [email-masked] https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________ OAuth mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/oauth