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

Discussion:

Jim Manico

2017-02-16 22:44:42 UTC

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

Bill Burke

2017-02-16 23:13:38 UTC

Permalink

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

Post by Jim Manico
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
https://www.ietf.org/mailman/listinfo/oauth

Josh Mandel

2017-02-17 02:22:28 UTC

Permalink

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/

Post by 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
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
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 Securityhttps://www.manicode.com
_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

S***@telekom.de

2017-02-17 16:03:52 UTC

Permalink

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

***@ietf.org<mailto:***@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth

Jim Manico

2017-02-17 17:40:25 UTC

Permalink

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

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

Adam Lewis

2017-02-17 17:42:54 UTC

Permalink

+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

Post by 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
Same for Deutsche Telekom. Our javascript clients also use code flow with
CORS processing and of course redirect_uri validation.
Best regards
Sebastian
Auftrag von *Bill Burke
*Gesendet:* Freitag, 17. Februar 2017 00:14
*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
<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=>
Hello Folks,
I noticed that Google supports the OAuth 2 Implicit flow for third-party
JavaScript applications.
https://developers.google.com/identity/protocols/OAuth2UserAgent
<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=>
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=>
_______________________________________________
OAuth mailing list
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=>
_______________________________________________
--
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=>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Dominick Baier

2017-02-17 18:02:51 UTC

Permalink

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

Post by 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
Same for Deutsche Telekom. Our javascript clients also use code flow with
CORS processing and of course redirect_uri validation.
Best regards
Sebastian
Auftrag von* Bill Burke
*Gesendet:* Freitag, 17. Februar 2017 00:14
*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
<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=>
Hello Folks,
I noticed that Google supports the OAuth 2 Implicit flow for third-party
JavaScript applications.
https://developers.google.com/identity/protocols/OAuth2UserAgent
<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=>
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=>
_______________________________________________
OAuth mailing list
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=>
_______________________________________________
--
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=>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Aaron Parecki

2017-02-17 18:05:27 UTC

Permalink

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>

Post by 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â.
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
+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

Post by 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
Same for Deutsche Telekom. Our javascript clients also use code flow
with CORS processing and of course redirect_uri validation.
Best regards
Sebastian
Auftrag von* Bill Burke
*Gesendet:* Freitag, 17. Februar 2017 00:14
*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
<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=>
Hello Folks,
I noticed that Google supports the OAuth 2 Implicit flow for third-party
JavaScript applications.
https://developers.google.com/identity/protocols/OAuth2UserAgent
<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=>
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=>
_______________________________________________
OAuth mailing list
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=>
_______________________________________________
--
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=>
_______________________________________________
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

Jim Manico

2017-02-17 18:07:33 UTC

Permalink

+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

Post by 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 <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>
On Fri, Feb 17, 2017 at 10:02 AM, 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â.
https://github.com/IdentityModel/oidc-client-js
<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

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

Post by S***@telekom.de
Same for Deutsche Telekom. Our javascript clients also use
code flow with CORS processing and of course redirect_uri
validation.
Best regards
Sebastian
von* Bill Burke
*Gesendet:* Freitag, 17. Februar 2017 00:14
*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
<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=>
Hello Folks,
I noticed that Google supports the OAuth 2 Implicit flow
for third-party JavaScript applications.
https://developers.google.com/identity/protocols/OAuth2UserAgent
<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=>
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=>
_______________________________________________
OAuth mailing list
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 list
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=>

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

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

Jim Manico

2017-02-17 18:06:20 UTC

Permalink

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

Post by 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â.
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

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

Post by S***@telekom.de
Same for Deutsche Telekom. Our javascript clients also use code
flow with CORS processing and of course redirect_uri validation.
Best regards
Sebastian
Bill Burke
*Gesendet:* Freitag, 17. Februar 2017 00:14
*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
<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=>
Hello Folks,
I noticed that Google supports the OAuth 2 Implicit flow for
third-party JavaScript applications.
https://developers.google.com/identity/protocols/OAuth2UserAgent
<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=>
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=>
_______________________________________________
OAuth mailing list
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 list
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=>

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

Dominick Baier

2017-02-17 18:25:11 UTC

Permalink

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

Post by Dominick Baier
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 (
***@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

Post by Dominick Baier
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
Same for Deutsche Telekom. Our javascript clients also use code flow with
CORS processing and of course redirect_uri validation.
Best regards
Sebastian
Auftrag von* Bill Burke
*Gesendet:* Freitag, 17. Februar 2017 00:14
*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
<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=>
Hello Folks,
I noticed that Google supports the OAuth 2 Implicit flow for third-party
JavaScript applications.
https://developers.google.com/identity/protocols/OAuth2UserAgent
<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=>
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=>
_______________________________________________
OAuth mailing list
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=>
_______________________________________________
--
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=>
_______________________________________________ OAuth mailing list

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

--
Jim Manico
Manicode Securityhttps://www.manicode.com