Re: [OAUTH-WG] redirect uri and portals

Dear Yannick,

1. I agree with Neil and Hans. It's one hardened endpoint vs any other
endpoint which may have inadvertent security issues. It substantially
increases the attack surface.

2. Karsten has given a detailed explanation on the use of "state"
parameters. However in my opinion this design pattern is very annoying for
the end user. It results in delayed performance due to multiple redirects
or 'the dance of redirects'. In some implementations, the hardened endpoint
even displays content, which further adds to the unpleasant user
experience. Also, the "state" parameter may result in unintended
information disclosure and the encryption and signature validation does
have its own performance overheads resulting in increased wait time
especially when the end user is waiting at the screen for the process to
end. So, as per my understanding, there are two issues here:

(a) The url automatically changes, which makes the user scary as he does
not know what is happening and does not seem to be incontrol of his actions.
(b) The degraded performance due to reading and verification of "state"
parameters.

3. I agree with Yannick that there is a definite need to look at other
options in a standardized way which can substitute for "state" parameter
design pattern. Especially in view of PCKE which was designed specifically
to mitigate the misuse of leaked authz code. Yannick you may like to bring
it up in the upcoming meeting and can request a time slot from Rifaat.

Regards
Jaimandeep Singh

On Tue, 7 Mar, 2023, 8:30 pm Karsten Meyer zu Selhausen, <
karsten.meyerzuselhausen@hackmanit.de> wrote:

> The benefit of not storing the state of all users on the server-side is
> still present. The client only needs to store and use *one *key-pair for
> all JWTs.
> On 07.03.2023 15:57, Yannick Majoros wrote:
>
> I'm still missing the point:
> - any key used to sign or encrypt the state... is state itself
> - if we can store that key (or anything, like an url to go back to after
> login), why bother passing the state around?
>
>
> Le mar. 7 mars 2023 à 15:07, Hannes Tschofenig <hannes.tschofenig@gmx.net>
> a écrit :
>
>> Hi Yannick,
>>
>>
>> Am 07.03.2023 um 14:25 schrieb Yannick Majoros:
>>
>> One possible solution: Store the redirect information in a signed JWT and
>> place the JWT in the state parameter. I don't think this is written
>> somewhere in the security BCP but I think this is a solutions used in the
>> wild by multiple clients.
>>
>>
>> Section 4.7.1 of the security BCP lists this solution as one possible
>> countermeasure:
>>
>>    -
>>
>>    If state is used for carrying application state, and integrity of its
>>    contents is a concern, clients MUST protect state against tampering
>>    and swapping. This can be achieved by binding the contents of state to the
>>    browser session and/or signed/encrypted state values as discussed in the
>>    now-expired draft [I-D.bradley-oauth-jwt-encoded-state
>>    <https://www.ietf.org/archive/id/draft-bradley-oauth-jwt-encoded-state-09.txt>
>>    ].¶
>>    <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.7.1-3.2.1>
>>
>>
>> The referenced draft has, however, expired:
>> https://www.ietf.org/archive/id/draft-bradley-oauth-jwt-encoded-state-09.txt
>>
>>
>> Ciao
>>
>> Hannes
>>
>>
>>
>>
>>
>
> --
> Yannick Majoros
> Valuya sprl
>
> --
> Karsten Meyer zu Selhausen
> Senior IT Security Consultant
> Phone:	+49 (0)234 / 54456499
> Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training
>
> Save the date: 11.-12.5.2023. Join us in celebrating the 5th anniversary of RuhrSec - the IT security conference in Bochum: https://www.ruhrsec.de/2023
>
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>