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
f I send the authorization code to
> /token, but I don't get a response, or I get an invalid (5xx /
> server_error) response, should I assume it is used or unused or
> unknown-state? If unknown-state, should I send it to some /mark-used-code
> endpoint so that it's definitely marked as used?&q
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: Saturday, December 4, 2021 4:46 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Requ
ve 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.”
>>>>
>>>>
>>>>
>>>>--
>> that these attacks can occur “when the attacker has access to both the
>>> authorization code as well as the PKCE code verifier.”
>>>
>>>
>>>
>>> -- Mike
>>>
>>>
>>>
>>&
>> *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
>> Parameter
>>
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 should
> continue to expect them), but instead address the limitations around
> implementing on
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 both
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 by these sophisticated attackers.
>>
>>
>>
>> Cheer
ophisticated 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
> *Subject:* Re: [OAUTH-WG] [EXTERNAL
cember 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
use, surely the
>
> (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
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
13 matches
Mail list logo
