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

[Dominick Baier]

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

On 17 February 2017 at 19:06:23, Jim Manico (j...@manicode.com) wrote:

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

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 (
adam.le...@motorolasolutions.com) 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  wrote:

> 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, sebastian.ebl...@telekom.de 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:oauth-boun...@ietf.org ] *Im
> Auftrag von* Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *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
>
> 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.
>
> 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 
> 
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
> 

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

[Jim Manico]

+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 
> @aaronpk 
>
>
> On Fri, Feb 17, 2017 at 10:02 AM, Dominick Baier
> mailto:dba...@leastprivilege.com>> wrote:
>
> 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
> (adam.le...@motorolasolutions.com
> ) 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 > > wrote:
>>
>> 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, sebastian.ebl...@telekom.de
>>  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:oauth-boun...@ietf.org] *Im Auftrag
>>> von* Bill Burke
>>> *Gesendet:* Freitag, 17. Februar 2017 00:14
>>> *An:* oauth@ietf.org 
>>> *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
>>>
>>> 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.
>>>
>>> https://developers.google.com/identity/protocols/OAuth2UserAgent
>>> 
>>> 

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

[Jim Manico]

> 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:
> 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
> (adam.le...@motorolasolutions.com
> ) 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 > > wrote:
>>
>> 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, sebastian.ebl...@telekom.de
>>  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:oauth-boun...@ietf.org] *Im Auftrag von*
>>> Bill Burke
>>> *Gesendet:* Freitag, 17. Februar 2017 00:14
>>> *An:* oauth@ietf.org 
>>> *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
>>>
>>> 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.
>>>
>>> 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
>>> 
>>> 
>>>
>>>
>>>
>>>
>>> ___
>>>
>>> OAuth mailing list
>>>
>>> OAuth@ietf.org 
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 

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

[Aaron Parecki]

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 


On Fri, Feb 17, 2017 at 10:02 AM, Dominick Baier 
wrote:

> 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 (adam.lewis@motorolasolutions.
> com) 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  wrote:
>
>> 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, sebastian.ebl...@telekom.de 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:oauth-boun...@ietf.org ] *Im
>> Auftrag von* Bill Burke
>> *Gesendet:* Freitag, 17. Februar 2017 00:14
>> *An:* oauth@ietf.org
>> *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
>>
>> 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.
>>
>> 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 
>> 
>>
>>
>>
>>
>> ___
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
>>
>>
>>
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth 
>> 

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

[Dominick Baier]

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 (
adam.le...@motorolasolutions.com) 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  wrote:

> 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, sebastian.ebl...@telekom.de 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:oauth-boun...@ietf.org ] *Im
> Auftrag von* Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *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
>
> 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.
>
> 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 
> 
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
> 
>
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth 
> 
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com 
> 
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

[Adam Lewis]

+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  wrote:

> 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, sebastian.ebl...@telekom.de 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:oauth-boun...@ietf.org ] *Im
> Auftrag von *Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *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
>
> 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.
>
> 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 
> 
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
> 
>
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth 
> 
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com 
> 
>
>
> ___
> 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] Google's use of Implicit Grant Flow

[Jim Manico]

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, sebastian.ebl...@telekom.de 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:oauth-boun...@ietf.org] *Im Auftrag von *Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *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
>
> 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.
>
> 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
>
>
>
>
> ___
>
> 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

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

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

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

[Sebastian.Ebling]

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:oauth-boun...@ietf.org] Im Auftrag von Bill Burke
Gesendet: Freitag, 17. Februar 2017 00:14
An: oauth@ietf.org
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

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.

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




___

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