While we did see android support in January 2017, Chrome and Opera only offered
support a few months ago. FireFox has a bug on this with notes suggesting it
will be rolled out in a year or so. And while the original RFC expired, it's
being rolled into the cookie RFC per my understanding.
I also
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 th
Can anyone provide insight about what protection PKCE adds for browser
based apps using the authorization code flow? The PKCE intro says that the
specification is designed to mitigate an attack where:
> the attacker intercepts the authorization code returned from the
authorization endpoint within
you have redirect uri restriction there.
nov
> On Sep 20, 2017, at 9:44, Bill Burke wrote:
>
> Cookies are vulnerable to CXRF.
>
>> On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote:
>> Why not using http-only cookies instead of refresh tokens?
>> If the app can interact with AuthZ server thr
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
Cookies are vulnerable to CXRF.
On Tue, Sep 19, 2017 at 7:48 PM, nov matake 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 runni
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
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 t
Only for confidential clients. No authentication is required for public
clients.
On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM)
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 wro
One of the reasons I see so many security folk discouraging implicit in web
applications (like your Angular scenario) is because even though refresh tokens
and similar require authentication, how do you store that info securely in a
browser? One XSS and it's http://m.youtube.com/watch?v=dsx2vdn7
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 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
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
longerStill, if you did the implicit flow, you'd have to have
longer access token timeouts as it would be real
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), bec
13 matches
Mail list logo
