On Aug 28, 2023, at 9:51 AM, Yannick Majoros <yann...@valuya.be> wrote:
<snip>
>
> 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
