We're basically on the same page, I think.
I Was just coming from the perspective that once you've solved the iframe
problem (say via a library), then it's six and one, or half a dozen and
another, so to speak. Of course if the spec were redone today, it would look
different and able to take i
gt; stop people from creating them.
>
>
>
> We can try to put together the best advice, and limit the damage.
>
>
>
> John B.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Neil Madden
> Sent: Friday, May 18, 2018 7:38 PM
> T
protect it.
>>
>> Having a refresh token in local storrage may introduce new security issues
>> unless it is token bound.
>>
>> Understanding the security issues of the code flow in the browser is
>> important, before any new recommendation.
>>
&g
d...@forgerock.com)
> Sent: Friday, May 18, 2018 7:38 PM
> To: John Bradley (mailto:ve7...@ve7jtb.com); Jim Manico
> (mailto:j...@manicode.com)
> Cc: oauth@ietf.org (mailto:oauth@ietf.org)
> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>
>
>
>
>
&
> On May 18, 2018, at 11:55 AM, Brock Allen wrote:
>
> > I don’t believe code flow today with an equivalent token policy as you have
> > with implicit causes any new security issues, and it does correct _some_
> > problems. The problem is that you immediately want to change token policy
> >
> I don’t believe code flow today with an equivalent token policy as you have
>with implicit causes any new security issues, and it does correct _some_
>problems. The problem is that you immediately want to change token policy to
>get around hidden iframes and special parameters.
Hidden frames
Manico
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
I might be missing something here, but aren’t bound tokens exactly as
vulnerable to the XSS attacks you describe as http-only cookies are?
— Neil
On Friday, May 18, 2018 at 5:43 pm, Jim Manico wrote:
A
d Waite
> <mailto:da...@alkaline-solutions.com>; Hannes Tschofenig
> <mailto:hannes.tschofe...@arm.com>
> Cc: oauth@ietf.org <mailto:oauth@ietf.org>
> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>
>
nding the security issues of the code flow in the browser is
> > important, before any new recommendation.
> >
> > John B.
> >
> > From: Brock Allen
> > Sent: Friday, May 18, 2:46 PM
> > Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA
issues around potentially
>> using service workers etc as well.
>>
>>
>>
>> So we should start but I am not sure of what the correct answer is yet.
>>
>>
>>
>> John B.
>>
>>
>>
>> Sent from Mail for Windows 10
>>
;>
>>
>> So we should start but I am not sure of what the correct answer is yet.
>>
>>
>>
>> John B.
>>
>>
>>
>> Sent from Mail for Windows 10
>>
>>
>>
>> From: Brock Allen
>> Sent:
iday, May 18, 2018 6:43 PM
> To: John Bradley
> Cc: David Waite; Hannes Tschofenig; Brock Allen; oauth@ietf.org
> Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>
> A few notes:
>
> > The session cookie should also be flagged as http only to protect it
Tschofenig
[mailto:hannes.tschofe...@arm.com]
Cc: oauth@ietf.org [mailto:oauth@ietf.org]
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
It sounds to me as if you're hesitant to recommend code flow (at least for now)
then for browser-based JS apps.
-Brock
On 5/18/2018 12
Waite; Hannes Tschofenig; Brock Allen; oauth@ietf.org
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
A few notes:
> The session cookie should also be flagged as http only to protect it..
This provides no real protection. If I get XSS into your site I don’t need to
steal
sure of what the correct answer is yet.
John B.
Sent from Mail for Windows 10
From: Brock Allen
Sent: Friday, May 18, 2018 6:36 PM
To: John Bradley; David Waite; Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
It sounds to me as if you
>> -DW
>>
>>> On May 17, 2018, at 10:23 AM, Hannes Tschofenig
>>> wrote:
>>>
>>> Hi Brock,
>>>
>>> there have been several attempts to start writing some guidance but so far
>>> we haven’t gotten too far.
>>> IM
ent.
>
> Ciao
> Hannes
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brock Allen
> Sent: 17 May 2018 14:57
> To: oauth@ietf.org
> Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>
> Much like updated guidance was provided with the &q
y new recommendation.
John B.
From: Brock Allen
Sent: Friday, May 18, 2:46 PM
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
To: David Waite, Hannes Tschofenig
Cc: oauth@ietf.org
One thing I maybe should have listed in the pros/cons in my original email is
session managemen
it is token bound.
Understanding the security issues of the code flow in the browser is important,
before any new recommendation.
John B.
From: Brock Allen
Sent: Friday, May 18, 2:46 PM
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
To: David Waite, Hannes Tschofenig
Cc
en too far.
IMHO it would be great to have a document.
Ciao
Hannes
From: OAuth [mailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]] On
Behalf Of Brock Allen
Sent: 17 May 2018 14:57
To: oauth@ietf.org [mailto:oauth@ietf.org]
Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
o:oauth-boun...@ietf.org>]
> On Behalf Of Brock Allen
> Sent: 17 May 2018 14:57
> To: oauth@ietf.org <mailto:oauth@ietf.org>
> Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
>
> Much like updated guidance was provided with the "OAuth2 for native apps&q
-WG] is updated guidance needed for JS/SPA apps?
Much like updated guidance was provided with the "OAuth2 for native apps" RFC,
should there be one for "browser-based client-side JS apps"? I ask because
google is actively discouraging the use of implicit flow:
https://githu
Much like updated guidance was provided with the "OAuth2 for native apps" RFC,
should there be one for "browser-based client-side JS apps"? I ask because
google is actively discouraging the use of implicit flow:
https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290
>From what I
23 matches
Mail list logo