Hi Warren,
For (1), I will try to be more concrete using a variation of Microsoft's system
on mobile for public clients - but it is a bit of a long explanation. Microsoft
OAuth applications are assigned a random ID (for example, we'll use 1-2-3-4).
If they use iOS, they add a redirect_uri=micros
such invalidation databases for its authorization codes,
> Microsoft is not going to get rid of it. But when security minded
> individuals ask us questions like "If I send the authorization code to
> /token, but I don't get a response, or I get an invalid (5xx /
> server_error) respo
de
endpoint so that it's definitely marked as used?" I'd like to be able to tell
them to just use DPoP and not worry about one time codes so much.
Thanks for reading, and I'll try to respond to any follow ups on these topics,
Will
From: OAuth On Behalf Of Warren Parad
Sent: S
for this thoughtful analysis, Aaron. I believe you’re spot on
>>>> that these attacks can occur “when the attacker has access to both the
>>>> authorization code as well as the PKCE code verifier.”
>>>>
>>>>
>>>>
>>>>
s, Aaron. I believe you’re spot on
>>> that these attacks can occur “when the attacker has access to both the
>>> authorization code as well as the PKCE code verifier.”
>>>
>>>
>>>
>>> -- Mike
>>>
gt;>
>>
>>
>> *From:* OAuth *On Behalf Of * Aaron Parecki
>> *Sent:* Thursday, December 2, 2021 2:58 PM
>> *To:* Warren Parad
>> *Cc:* Pieter Kasselman ;
>> oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request
&g
ces and incorporate it into standards and products. Attacks that
> seemed impossibly complex are not only possible, but have become probable.
>
>
>
> The proposed changes for DPoP are not meant to replace the need for
> one-time use tokens (single use tokens are preferable and we shou
Parecki
Sent: Thursday, December 2, 2021 2:58 PM
To: Warren Parad
Cc: Pieter Kasselman ;
oauth@ietf.org
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter
Hi all, I've been giving this some more thought.
The problem occurs when the attacker has access to bot
o replace the need for
>> one-time use tokens (single use tokens are preferable and we should
>> continue to expect them), but instead address the limitations around
>> implementing one-time use, especially at scale. The 60s window you mention
>> below is sufficiently long to be exploited
ong to be exploited by these sophisticated attackers.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth *On Behalf Of *Warren Parad
> *Sent:* Wednesday 1 December 2021 15:29
> *To:* Pieter Kasselman
> *Cc:* Mike Jones ;
> oauth@ietf.org
> *Subj
1 December 2021 15:29
To: Pieter Kasselman
Cc: Mike Jones ; oauth@ietf.org
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter
(e.g. one-time use in a certain timeframe etc).
Sure but couldn't we just reduce the lifetime? Even if the token isn't one time
>
> (e.g. one-time use in a certain timeframe etc).
Sure but couldn't we just reduce the lifetime? Even if the token isn't one
time use, surely the reuse time is trivially short which would prevent
against exfiltration of the necessary security tokens to issue the attack?
I feel like the simpler
Hi Aaron, Neil
Thanks for the questions.
We agree that ideally authorization codes and PKCE proofs would never end up in
log files and one-time use would be perfectly implemented.
However, in practice these artefacts do find their way into log files in
various places and one-time use may not a
13 matches
Mail list logo
