As Filip stated, cookies are the main reason. There is almost always some session state that the app wants to maintain between making the authorization request and getting the authorization response. It can be as simple as where the user was in the app so they are redirected to the original place, to what is already in the shopping cart, or even existing authentication context as the user is linking another account. With the use of PKCE, the threats of intercepted query parameters are reduced.
If we were to make a recommendation, it would be the redirect and not form post as session hijacking is the larger threat now from my understanding. /Dick On Sat, Oct 25, 2025 at 8:51 AM Andrey Kuznetsov < [email protected]> wrote: > That is why I emphasized "significant". > > > UX - FOUC or briefly displayed submit page at the AS when it's sending > responses > > - The returning page with the autosubmitted form usually does not contain > any explicit content. In fact, I'm not sure how it's different from any > redirect URI page that might appear briefly, as you mentioned, when other > response modes are in use > > > sameSite - the client is required to use sameSite=none for the cookies > they expect to load at the redirect_uri, that may include session related > cookies for which sameSite=none is the exact opposite of what they should > strive for. > > - I agree with the first part of your statement, that's true. However, we > should define what we mean by a "session" here and determine if it's a > problem. Usually, this applies only to certain cookies that are used to > maintain a "pre-auth session" and for such a case I'm not sure if it's a > significant issue. I considered this nuance in the research i mentioned > previously and explicitly stated that constraint. Could you share your > example, If you have another case where we do need a cookie to be sent to > the redirect URI endpoint? > ---------------- > Кому: Andrey Kuznetsov ([email protected]); > Копия: [email protected]; > Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in OAuth/OIDC > Security Best Practices; > 25.10.2025, 16:40, "Filip Skokan" <[email protected]>: > > On the other hand, i cannot identify any significant drawbacks to using > this response mode, aside from inconsistent support across implementations. > > > What about > - UX - FOUC or briefly displayed submit page at the AS when it's sending > responses > - sameSite - the client is required to use sameSite=none for the cookies > they expect to load at the redirect_uri, that may include session related > cookies for which sameSite=none is the exact opposite of what they should > strive for. > > - Filip > > > 25. 10. 2025 v 15:21, Andrey Kuznetsov <[email protected]>: > > On the other hand, i cannot identify any significant drawbacks to using > this response mode, aside from inconsistent support across implementations. > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > -- > Best regards, > Andrey Kuznetsov > Software Architect > Identity & Access Management > Yandex Cloud > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
