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.tschofe...@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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
