Re: [OAUTH-WG] WGLC for Browser-based Apps

[David Waite]

On Aug 28, 2023, at 9:51 AM, Yannick Majoros  wrote:

> 
> You really have a point about refresh tokens here, but they are a separate, 
> real issue. Refresh tokens should be avoided whenever you can do without. Any 
> pattern that can keep them safe is on the same level, but their safety is 
> always relative. They make any attack worse, indeed (and that is also true 
> for BFFs in some scenario's). This isn't specifically about BFFs.

Commenting on this one in isolation - token policy in general affects security, 
but refresh tokens are orthogonal to that. From a (compliant) client 
perspective, a refresh token thats good for an hour is not different 
security-wise than an access token-only configuration where the access token is 
good for an hour. A refresh token that never expires (to generate an infinite 
number of access tokens) is not fundamentally different from an access token 
that never expires. 

If you are not doing sender constraints that prevent exfiltration, refreshing 
may give more opportunities for exfiltration. Methods that do provider sender 
constraints however typically define how to do so for both types of tokens.

This has been a recurring challenge in the past, where some policy (such as 
certain implementations and how they react to the offline_access scope from 
OIDC) has steered the discussion to comparing particular archetypical policies 
of AS deployments rather than the technology itself. This is problematic not 
just for complicating the discussion at play, but because we don’t have a 
consistent view of what these archetypes might be across the industry.

-DW___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Hector Zepeda]

Need this downloaded and install please
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Hector Zepeda]

Need this downloaded and install
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Hector Zepeda]

Need this downloaded
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] (no subject)

[Hector Zepeda]

Need this downloaded
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Digest, Vol 178, Issue 76

[Hector Zepeda]

Need this down load

On Mon, Aug 28, 2023, 1:35 PM  wrote:

> Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@ietf.org
>
> You can reach the person managing the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>1. Fwd: New Version Notification for
>   draft-gilman-wimse-use-cases-00.txt (Justin Richer)
>2. Re: Fwd: New Version Notification for
>   draft-gilman-wimse-use-cases-00.txt (Dick Hardt)
>
>
> --
>
> Message: 1
> Date: Mon, 28 Aug 2023 18:11:42 +
> From: "Justin Richer" 
> To: oauth 
> Subject: [OAUTH-WG] Fwd: New Version Notification for
> draft-gilman-wimse-use-cases-00.txt
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> Back at IETF116 in Yokohama, Evan Gilman presented information about
> SPIFFE, a workload security platform. At IETF 117 in SF, we presented a set
> of questions and possible new work, to lots of positive feedback. Now we?ve
> set up the Workload Identity in Multi System Environments (WIMSE) mailing
> list for discussing things, wi...@ietf.org ? and
> we?ve just published the following -00 use cases document. If this topic
> area interests you, please take a look through the use cases (it?s pretty
> short right now) and join the conversation on the WIMSE mailing list.
>
> Thanks,
>  ? Justin
>
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-gilman-wimse-use-cases-00.txt
> Date: August 28, 2023 at 1:53:01 PM EDT
> To: "Evan Gilman" , "Joseph Salowey" ,
> "Justin Richer" , "Pieter Kasselman" <
> pieter.kassel...@microsoft.com>
>
> A new version of Internet-Draft draft-gilman-wimse-use-cases-00.txt has
> been
> successfully submitted by Justin Richer and posted to the
> IETF repository.
>
> Name: draft-gilman-wimse-use-cases
> Revision: 00
> Title:Workload Identity Use Cases
> Date: 2023-08-28
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-gilman-wimse-use-cases/
> HTML:
> https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-gilman-wimse-use-cases
>
>
> Abstract:
>
>   Workload identity systems like SPIFFE provide a unique set of
>   security challenges, constraints, and possibilities that affect the
>   larger systems they are a part of.  This document seeks to collect
>   use cases within that space, with a specific look at both the OAuth
>   and SPIFFE technologies.
>
> Discussion Venues
>
>   This note is to be removed before publishing as an RFC.
>
>   Source for this draft and an issue tracker can be found at
>   https://github.com/bspk/draft-gilman-wimse-use-cases.
>
>
>
> The IETF Secretariat
>
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230828/4cc29390/attachment.htm
> >
>
> --
>
> Message: 2
> Date: Mon, 28 Aug 2023 11:34:19 -0700
> From: Dick Hardt 
> To: Justin Richer 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
> draft-gilman-wimse-use-cases-00.txt
> Message-ID:
> <
> cad9ie-vmu+l+c31mgb4iltqbmz919pu9d-kbbg8o+jm0o2r...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Link for WIMSE list https://www.ietf.org/mailman/listinfo/wimse
>
> On Mon, Aug 28, 2023 at 11:12?AM Justin Richer  wrote:
>
> > Hi all,
> >
> > Back at IETF116 in Yokohama, Evan Gilman presented information about
> > SPIFFE, a workload security platform. At IETF 117 in SF, we presented a
> set
> > of questions and possible new work, to lots of positive feedback. Now
> we?ve
> > set up the Workload Identity in Multi System Environments (WIMSE) mailing
> > list for discussing things, wi...@ietf.org ? and we?ve just published
> the
> > following -00 use cases document. If this topic area interests you,
> please
> > take a look through the use cases (it?s pretty short right now) and join
> > the conversation on the WIMSE mailing list.
> >
> > Thanks,
> >  ? Justin
> >
> > Begin forwarded message:
> >
> > *From: *internet-dra...@ietf.org
> > *Subject: **New Version Notification for
> > draft-gilman-wimse-use-cases-00.txt*
> > *Date: *August 28, 2023 at 1:53:01 PM EDT
> > *To: *"Evan Gilman" , "Joseph Salowey"  >,
> > "Justin Richer" , "Pieter Kasselman" <
> > pieter.kassel...@microsoft.com>
> >
> > A new version of Internet-Draft 

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Yannick Majoros]

Hey Aaron,

*> There is a huge difference between being able to access resources
through the user's browser while it's online vs being able to access
resources without the browser's involvement.*

While there are operational differences, the end result is compromission of
the exposed resources for both cases. Once other mitigations are in place,
the damage is typically the same. There is a real need to document the
differences, but an application using either solution isn't more secure.

*> Additionally, in many cases, the BFF exposes only a subset of actions of
the resource server to the client. Or put another way, sometimes access
tokens can access more resources than just the ones the BFF can access.
This obviously doesn't apply to everyone, but it's still common enough to
be significant. This is briefly mentioned in the security considerations
already: 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke
*

If only a subset of actions need to be exposed to the client, the actual
issue is that the access token scope and audience aren't defined well
enough.
A BFF or even a simple proxy can filter the amount of exposed services, but
this is a distinct problematic and is independent from the token storage
solution choice.
Using a BFF for token storage also introduces the opposite problem: cookies
might be sent for resources they weren't intended for.
All of these are basic misconfiguration issues, but reducing the attack
surface by changing which services are potentially exposed isn't an
intrinsic advantage of the BFF as application client.

Le lun. 28 août 2023 à 17:56, Aaron Parecki  a écrit :

> > An XSS compromise would allow an attacker to call the resource server
> from the browser context through the BFF, which would lead to the same
> catastrophous result as doing it from another context.
>
> There is a huge difference between being able to access resources through
> the user's browser while it's online vs being able to access resources
> without the browser's involvement.
>
> Additionally, in many cases, the BFF exposes only a subset of actions of
> the resource server to the client. Or put another way, sometimes access
> tokens can access more resources than just the ones the BFF can access.
> This obviously doesn't apply to everyone, but it's still common enough to
> be significant. This is briefly mentioned in the security considerations
> already:
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke
>
> Aaron
>
>
> On Mon, Aug 28, 2023 at 8:51 AM Yannick Majoros  wrote:
>
>> An XSS compromise would allow an attacker to call the resource server
>> from the browser context through the BFF, which would lead to the same
>> catastrophous result as doing it from another context.
>>
>> Cookies are sent automatically, potentially to resources which shouldn't
>> get it. Same threat level as a token that is too broadly scoped, really.
>>
>> You really have a point about refresh tokens here, but they are a
>> separate, real issue. Refresh tokens should be avoided whenever you can do
>> without. Any pattern that can keep them safe is on the same level, but
>> their safety is always relative. They make any attack worse, indeed (and
>> that is also true for BFFs in some scenario's). This isn't specifically
>> about BFFs.
>>
>> Le lun. 28 août 2023 à 17:38, Aaron Parecki  a écrit :
>>
>>> > BFFs are not any safer, XSS or any successful malicious javascript
>>> execution has the same end effect
>>>
>>> As described in the draft as well as in this email thread, this is
>>> incorrect.
>>>
>>> An XSS compromise of the BFF architecture results in the attacker being
>>> able to make requests to the BFF with the legitimate user's cookie, as long
>>> as the user's browser is active. An XSS compromise of a SPA results in the
>>> attacker being able to obtain access tokens (and possible refresh tokens),
>>> which results in the attacker being able to access the resource server
>>> directly, outside of the context of the user's browser, which may allow the
>>> attacker to access far more data than the browser app alone, and for a
>>> longer period of time.
>>>
>>> The difference between these threats is extremely significant.
>>>
>>> Aaron
>>>
>>> On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros 
>>> wrote:
>>>
 My last comment was rather ironic: user-facing applications are
 dangerous (security is hard, which I say nothing with), and that is true
 for any scheme.. BFFs are not any safer, XSS or any successful malicious
 javascript execution has the same end effect (=game over, complete
 compromise of authenticated calls), and there was still no
 factual demonstration of multiple levels of security here. See my detailed
 explanations.

 Le lun. 28 août 2023 à 11:35,