;>> >
>>>>> >> How is that different from a regular server client with a web
>>>>> interface if the backed is doing the API calls to the RS?
>>>>> >>
>>>>> >>
>>>>> >>
>&
n at the interface between SPA and backend can 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 <
>
aining.
>>> >>>
>>> >>> 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 tok
eplay
>> detection) and issue short living and privilege restricted access tokens..
>> >>>>
>> >>>> Sender constrained access tokens in SPAs need adoption of token
>> binding or alternative mechanism. mtls cou
nism. 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
> level PoP mechanisms in conjunction with web crypto. Another path to be
> evaluated could be web aut
eb 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.
>>>&
018 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 Ca
> 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 pointe
ion of token binding
>>>>>>> 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
>> 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.
>>
>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
>> hannes.tschofe...@arm.co
conjunction with 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 Bri
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
&g
> 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-apps-00
>
>
>
>
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.
>>>&g
12.2018 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, Nove
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 i
> 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 st
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 token
+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 pu
Hi all,
please find some thoughts about refresh token protection in the new revision of
the Security BCP
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12
Feedback welcome!
kind regards,
Torsten.
> Am 19.11.2018 um 11:33 schrieb Jim Manico :
>
> I want to +1 this
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
>
> Ha
+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 combinati
On 17/11/2018 13:26, Torsten Lodderstedt wrote:
> To start with, the AS may use refresh token rotation in combination with
> automatic revocation in case of detected replay attempts.
>
> How does it work? The AS issues a new refresh token with every refresh and
> invalidate the old one. This res
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 latter
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 Lod
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 managemen
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
> HTTP
> 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. T
> 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 valida
>> 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 impli
” 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 k
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 ac
> 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 im
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
> suffic
> 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 conc
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 t
> 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 request
> 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 outlines
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 no
> 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 w
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 store
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 in
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. Dur
54 matches
Mail list logo
