n utilize
>>>> standard web techniques (see OWASP). The backend in turn can use mTLS for
>>>> sender constraining.
>>>> >>>
>>>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
>>>> tors...@lodderstedt.net>:
&g
gt;
>>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
>>> tors...@lodderstedt.net>:
>>> >>>
>>> >>>> IMHO the best mechanism at hand currently to cope with token
>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
>&g
and issue short living and privilege restricted access tokens..
>> >>>>
>> >>>> Sender constrained access tokens in SPAs need adoption of token
>> binding or alternative mechanism. mtls could potentially work in
&g
could potentially work in
> deployments with automated cert rollout but browser UX and interplay with
> fetch needs some work. We potentially must consider to warm up application
> level PoP mechanisms in conjunction with web crypto. Another path to be
> evaluated could be web auth.
> >>
t;>>
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig
>>>> :
>>>>
>>>>> I share the concern Brian has, which is also the conclusion I came up
>>>>> with in my other email sent a few minutes ago.
>>>>>
>&g
hrieb Hannes Tschofenig <
>> hannes.tschofe...@arm.com>:
>>
>> I share the concern Brian has, which is also the conclusion I came up
>> with in my other email sent a few minutes ago.
>>
>>
>>
>> *From:* OAuth *On Behalf Of *Brian Campbell
>&
> On Dec 3, 2018, at 1:25 AM, Torsten Lodderstedt
> wrote:
>
> I think the BCP needs to point out there are solutions beyond an app directly
> interacting with AS and RSs from the browser. Otherwise people get the wrong
> impression this is the only way to go. To the contrary and as I
nding
>>>>>>> or alternative mechanism. mtls could potentially work in deployments
>>>>>>> with automated cert rollout but browser UX and interplay with fetch
>>>>>>> needs some work. We potentially must consider to warm up application
rk. We potentially must consider to warm up application level PoP
>> mechanisms in conjunction with web crypto. Another path to be evaluated
>> could be web auth.
>>
>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
>> hannes.tschofe...@arm.com>:
>>
th web crypto. Another path to be evaluated
>>>> could be web auth.
>>>>
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig
>>>> mailto:hannes.tschofe...@arm.com>>:
>>>>
>>>>> I share the concern Brian has, which i
st consider to warm up application level PoP
>>>>> mechanisms in conjunction with web crypto. Another path to be evaluated
>>>>> could be web auth.
>>>>>
>>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig
>>>>&
y other email sent a few minutes ago.
>
>
>
> *From:* OAuth *On Behalf Of *Brian Campbell
> *Sent:* Friday, November 30, 2018 11:43 PM
> *To:* Torsten Lodderstedt
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>
>
>
>
>
> On S
h needs some
>>>>> work. We potentially must consider to warm up application level PoP
>>>>> mechanisms in conjunction with web crypto. Another path to be
>>>>> evaluated could be web auth.
>>>>>
&g
8 um 10:15 schrieb Hannes Tschofenig <
> hannes.tschofe...@arm.com>:
>
> I share the concern Brian has, which is also the conclusion I came up with
> in my other email sent a few minutes ago.
>
>
>
> *From:* OAuth *On Behalf Of *Brian Campbell
> *Sent:* Friday, November 30, 2
could be web auth..
>>>
>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig
>>> :
>>>
>>>> I share the concern Brian has, which is also the conclusion I came up with
>>>> in my other email sent a few minutes ago.
>>>>
>
rg>> *On Behalf Of *Brian Campbell
*Sent:* Friday, November 30, 2018 11:43 PM
*To:* Torsten Lodderstedt <mailto:tors...@lodderstedt.net>>
*Cc:* oauth mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
On Sat, Nov 17, 2018 at 4:07
ich is also the conclusion I came up with
>> in my other email sent a few minutes ago.
>>
>> From: OAuth On Behalf Of Brian Campbell
>> Sent: Friday, November 30, 2018 11:43 PM
>> To: Torsten Lodderstedt
>> Cc: oauth
>> Subject: Re: [OAUTH-WG]
Lodderstedt
> Cc: oauth
> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>
>
>
> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt
> wrote:
> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> >
> > So you mean at the resource server
I share the concern Brian has, which is also the conclusion I came up with in
my other email sent a few minutes ago.
From: OAuth On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt
Cc: oauth
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based
On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt
wrote:
> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> >
> > So you mean at the resource server ensuring the token was really issued
> to the client? Isn't that an inherent limitation of all bearer tokens
> (modulo HTTP token binding, which
> On Nov 21, 2018, at 12:08 AM, Hans Zandbelt
> wrote:
>
> I think of this as somewhat similar to:
> a) a grant type where a cookie grant is exchanged at an "RP token endpoint"
> for an associated access and refresh token; the protocol between SPA and the
> API to do so would benefit from
I think of this as somewhat similar to:
a) a grant type where a cookie grant is exchanged at an "RP token
endpoint" for an associated access and refresh token; the protocol between
SPA and the API to do so would benefit from standardization e.g. into SDKs
and server side frameworks
b) an "RP
+1
This model is useful and should be documented in its own right. Once
documented it could possibly be referenced in the BCP.
On 11/9/18 1:44 PM, David Waite wrote:
Hi Hans, I hope it is acceptable to reply to your message on-list.
Others could correct me if I am wrong, but I believe the
On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan wrote:
> It may be worth slightly rewording 7.2 as it may encourage a growing
> misconception that all native apps must be public clients. With many
> devices now having embedded HSMs, we’ve seen increasing interest in mobile
> apps being dynamically
You mean the binding between refresh tokens and sessions?
> Am 19.11.2018 um 11:03 schrieb Hans Zandbelt :
>
> +1 to the suggestions that Vladimir raises; I've seen a fair number of
> requests in the field for exactly that
>
> Hans.
>
>> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov
I want to +1 this as well. This really got my attention as an impressive and
straightforward defense technique.
Jim
> On Nov 19, 2018, at 3:48 PM, Hans Zandbelt wrote:
>
> +1 to the suggestions that Vladimir raises; I've seen a fair number of
> requests in the field for exactly that
>
>
+1 to the suggestions that Vladimir raises; I've seen a fair number of
requests in the field for exactly that
Hans.
On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov
wrote:
> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>
> To start with, the AS may use refresh token rotation in
Hi everyone,
On 17/11/2018 13:07, Torsten Lodderstedt wrote:
>
>> The alternative, as you mentioned, is to not issue refresh tokens and do
>> token renewal the "same old way" via iframe with prompt=none, while still
>> using code flow.
> yes.
>
> Have you ever experienced issues with the
I might suggest that neither of those are really best current practice per
se. Using key constrained tokens is more of an aspirational recommendation
for what would be good security practice than it is something that's done
much for real in practice today.
On Sat, Nov 17, 2018, 4:07 AM Torsten
Hi Tomek,
> Am 16.11.2018 um 13:59 schrieb Tomek Stojecki :
>
> >> The AS can bind the lifetime of the refresh tokens to the session
> >> lifetime, i.e. automatically revoke it on logout.
>
> > Yea, I saw your other email asking about refresh token revocation relating
> > to session
u were always on the „make it secure“ side, I’m a bit surprised.
kind regards,
Torsten.
>
>
>
> Best,
>
>
>
> Nat Sakimura
>
>
>
> From: OAuth On Behalf Of Brock Allen
> Sent: Friday, November 16, 2018 7:01 AM
> To: Torsten Lodderstedt
> Cc
Hi Brock,
> Am 15.11.2018 um 23:01 schrieb Brock Allen :
>
> > It still lacks the ability to issue sender constraint access tokens.
>
> So you mean at the resource server ensuring the token was really issued to
> the client? Isn't that an inherent limitation of all bearer tokens (modulo
>
> Going from Implicit to Code deals with the problem of sending RT in the URL,
>which I agree is a plus. Is there anything else in a way of an improvement?
As far as I can tell, that's the only additional security feature (beyond what
we already use for mitigations today) that code flow adds.
> Could you please expand on what you are achieving with replacing the URL
>using the history API? Removing the token from the browser's history, or any
>protection beyond that?
Just this block of code which would be run on the redirect_uri page loaded in
the client (after id_token/token
>> The AS can bind the lifetime of the refresh tokens to the session lifetime,
>>i.e. automatically revoke it on logout.
> Yea, I saw your other email asking about refresh token revocation relating to
> session management. Obviously for certain clients, this won't make sense, but
> for
” as well) has this
repercussion and I would not agree to it.
Best,
Nat Sakimura
From: OAuth On Behalf Of Brock Allen
Sent: Friday, November 16, 2018 7:01 AM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
> It still lacks the abil
Hi all,
Am 09.11.18 um 21:22 schrieb Brock Allen:
>
> Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get
> into specifics, but many of the points seem confused (or at least
> confuse me) and/or the conclusion that code flow is the only approach
> seems misleading. For example:
> It still lacks the ability to issue sender constraint access tokens.
So you mean at the resource server ensuring the token was really issued to the
client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP
token binding, which is still some time off)? Resource servers don't
Hi Brock,
> Am 15.11.2018 um 15:01 schrieb Brock Allen :
>
> > Helps to prevent leakage, not injection in the authorization response.
>
> So then wording and its motivation could get updated to correctly reflect
> that.
>
> >> "OAuth 2.0 provides no mechanism for a client to verify that an
> Helps to prevent leakage, not injection in the authorization response.
So then wording and its motivation could get updated to correctly reflect that.
>> "OAuth 2.0 provides no mechanism for a client to verify that an access token
>> was issued to it, which could lead to misuse and possible
Hi Brock,
> Am 09.11.2018 um 21:22 schrieb Brock Allen :
>
> Hello all --
>
> I also have some thoughts/feedback on this document.
>
> Personally I agree with some of the conclusions, but as it stands I think the
> document's main conclusion that code flow is the real solution is not
>
> Finally, my last real concern (which is why I'm pushing back so much on code
>flow), is that this implies refresh tokens in the browser. My sense is that
>given the danger of this, the original OAuth2 RFC (via the implicit flow) was
>designed to limit the client's ability to obtain new access
Hello all --
I also have some thoughts/feedback on this document.
Personally I agree with some of the conclusions, but as it stands I think the
document's main conclusion that code flow is the real solution is not
sufficiently convincing.
I would like to see a brief summary of the current
Hi Hans, I hope it is acceptable to reply to your message on-list.
Others could correct me if I am wrong, but I believe the purpose of this
document is to recommend uses of other OAuth/OIDC specifications, not to
include its own technologies.
In terms of being another spec to be referenced, I
> Am 08.11.2018 um 22:59 schrieb David Waite :
>
> PCKE does not resolve any known code injection attacks for SPA public clients.
It can be utilized to detect code injection at the redirect between AS and
client. The PKCE verifier is bound to user agent that initiated the
corresponding
> On Nov 8, 2018, at 4:19 AM, Tomek Stojecki
> wrote:
>
> Thanks for putting this together Aaron.
>
> Having read through the document, I am not as convinced that there is enough
> of a benefit of Authorization Code + PKCE vs Implict Flow for SPAs.
>
> In section 7.8. the document
Hi Tomek,
Am 08.11.18 um 12:19 schrieb Tomek Stojecki:
> Thanks for putting this together Aaron.
>
> Having read through the document, I am not as convinced that there is enough
> of a benefit of Authorization Code + PKCE vs Implict Flow for SPAs.
>
> In section 7.8. the document outlines the
Hi Aaron,
Thanks for writing up clear guidelines for SPAs. I reviewed the draft
and would like to offer some feedback:
One important aspect I am missing is a brief discussion on how, in
general, SPAs should be implemented; in particular, whether the
browser-app exchanges the code for an access
Thanks for putting this together Aaron.
Having read through the document, I am not as convinced that there is enough of
a benefit of Authorization Code + PKCE vs Implict Flow for SPAs.
In section 7.8. the document outlines the Implicit flow disadvantages as
following:
"- OAuth 2.0 provides
> On Nov 7, 2018, at 9:08 AM, Simon Moffatt wrote:
>
> It's an interesting topic. I think there is a definitely a set of options
> and considerations for this. Namely operational. For example, hugely
> popular mobile apps (multi-million downloads across different OS's) using
> dynamic reg
It's an interesting topic. I think there is a definitely a set of
options and considerations for this. Namely operational. For example,
hugely popular mobile apps (multi-million downloads across different
OS's) using dynamic reg with per-instance private creds requires the AS
to be able to
Hi Aaron,
Thanks for putting this document together, I think this kind of guidance is
invaluable.
It may be worth slightly rewording 7.2 as it may encourage a growing
misconception that all native apps must be public clients. With many devices
now having embedded HSMs, we’ve seen increasing
Thanks Hannes,
Since I wasn't able to give an intro during the meeting today, I'd like to
share a little more context about this here as well.
At the Internet Identity Workshop in Mountain View last week, I led a
session to collect feedback on recommendations for OAuth for browser based
apps.
Hi all,
Today we were not able to talk about draft-parecki-oauth-browser-based-apps-00,
which describes "OAuth 2.0 for Browser-Based Apps".
Aaron put a few slides together, which can be found here:
54 matches
Mail list logo
