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

Back to the OP...Why would browser Javascript implementing Authz Code
flow with public client be vulnerable?  Not understanding how an XSS
attack could work in such a scenario.

On Wed, Sep 20, 2017 at 3:22 AM, Jim Manico <jim@manicode.com> wrote:
> PS: The RFC for SameSite cookies has moved to here.
> https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis
>
> It's an approved standard and was rolled into the new cookie RFC.
>
> Chrome support has a big impact on mobile and elsewhere. But I agree we need
> to see FireFox and Safari support and expect to see it within a year.
>
> But that should not stop folks from using it today. It's backwards
> compatible with existing cookie behavior and is quite beautiful in it's
> simplicity and power to defend against CSRF.
>
> Aloha,
> Jim
>
> On Sep 20, 2017, at 1:21 PM, Neil Madden <neil.madden@forgerock.com> wrote:
>
> Is this growing in support? It seems like a good idea, but when I reviewed
> it recently the draft had expired almost a year ago and still only Chrome
> and Opera had implemented it. From the outside it looks as if it has
> (inexplicably) died. Do you know if there is some activity happening behind
> the scenes?
>
> -- Neil
>
> On 20 Sep 2017, at 02:31, Jim Manico <jim@manicode.com> wrote:
>
> Not always, Bill. There is a new standard called "same site cookies" or
> "first party cookies" that allows you to programmatically remove this risk
> in some modern browsers, it's worth reviewing.
>
> https://tools.ietf.org/html/draft-west-first-party-cookies-07
>
> It's live in Chrome and Opera and will only grow in support.
> http://caniuse.com/#search=samesite
>
> Jim
>
>
> On Sep 20, 2017, at 8:44 AM, Bill Burke <bburke@redhat.com> wrote:
>
> Cookies are vulnerable to CXRF.
>
> On Tue, Sep 19, 2017 at 7:48 PM, nov matake <matake@gmail.com> wrote:
>
> Why not using http-only cookies instead of refresh tokens?
>
> If the app can interact with AuthZ server through a hidden iframe with
>
> prompt=none param, you shouldn’t need refresh tokens.
>
>
> If your SAP is running on a different domain with the backend server,
>
> Safari’s Intelligent Tracking Prevention will break the hidden iframe way
>
> though.
>
>
> On Sep 20, 2017, at 7:32, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>
> Right,  Refresh token is bearer for native apps, that is why we came up with
>
> PKCE to protect code.
>
>
> For Angular the code flow with PKCE is probably better than the token
>
> response type.
>
>
> However with bearer tokens it is still riskier than code with a confidential
>
> client so the AS should take that into account and not allow refresh tokens
>
> to live forever.
>
>
> One future way to protect refresh tokens and perhaps Access tokens is to use
>
> token binding to bind the tokens to the user agent.   You could do that now
>
> for refresh tokens in Edge (Chrome has TB off by default still).
>
>
> I think more work needs to be done to come up with a best practice for SPA.
>
>
> John B.
>
>
> On Sep 19, 2017, at 7:02 PM, Adam Lewis <adam.lewis@motorolasolutions.com>
>
> wrote:
>
>
> Only for confidential clients.  No authentication is required for public
>
> clients.
>
>
> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil.hunt@oracle.com>
>
> wrote:
>
>
> Except a refresh token is not purely bearer. The client is required to
>
> authenticate to use it.
>
>
> Phil
>
>
> On Sep 19, 2017, at 2:33 PM, Bill Burke <bburke@redhat.com> wrote:
>
>
> I'd be curious to the response to this too.
>
>
> Seems to me that refresh token has the same possible security risks in
>
> an Angular app as an access token, except the refresh token is valid
>
> longer....Still, if you did the implicit flow, you'd have to have
>
> longer access token timeouts as it would be really annoying for the
>
> user to have to login again and again in a long session with your
>
> Angular app.
>
>
> We have a javascript adapter that does Authz Code Flow with PKCE for
>
> our Angular app.  It also does CORS checks on the code to token XHR
>
> request just in case on the IDP side.
>
>
> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer <sbueringer@gmail.com>
>
> wrote:
>
> Hi,
>
>
> there were some discussions in January regarding recommendations for
>
> browser-based apps
>
> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>
>
> I'd just like to ask if the Authorization Code Flow with PKCE is a
>
> valid
>
> option for Single-Page-Applications (in our case Angular), because
>
> Implicit
>
> Flow cannot be used in our scenario.
>
>
> Authorization Code Flow with PKCE eliminates the necessity for client
>
> secrets, but our concern is that exposing the refresh token to the SPA
>
> might
>
> be a security risk, compared to the Implicit Flow were no refresh token
>
> is
>
> exposed.
>
>
> What's your take on this?
>
>
> Kind regards,
>
> Stefan Büringer
>
>
> P.S. I couldn't find that much on the internet regarding Authorization
>
> Code
>
> Flow with PKCE in SPAs, if you have some recommendations for good blog
>
> posts
>
> I would be grateful.
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> --
>
> Bill Burke
>
> Red Hat
>
>
> _______________________________________________
>
> 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
>
>
>
> _______________________________________________
>
> 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
>
>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> 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

-- 
Bill Burke
Red Hat