On Mon, Jan 5, 2026 at 8:56 PM Nick Watson <[email protected]> wrote:
> As I understand it, Redirect-Origin is something that security-conscious > RPs could implement if they want, but isn't required for functionality. So > existing form_post RPs would work out of the box. > yes -- but they would have compromised of using form_post and not having SameSite=Lax cookies -- that was the tradeoff in an earlier thread here about form_post vs query / fragment > Furthermore, I'd expect a switch from query to post to be a fairly trivial > one handled nearly invisibly by most robust HTTP frameworks, > But what is the AS supposed to do if the RP is asking for query? How does the AS know the RP will support POST? > whereas a switch to Redirect-Query would require more custom impl. (Yes I > assume if/when this spec lands HTTP frameworks would gradually adopt > support, but that's a slow process and RPs will be even slower to pull new > versions of HTTP frameworks, as it can be a big change.) > I'm not sure what you mean by HTTP frameworks. I'm thinking it would be a change to the OAuth library. I tasked my robot to do some research on popular nodejs libraries: | Library | Effort for Library Author | Developer Gets It Free? | Default response_mode | |-----------------|---------------------------|-------------------------|-----------------------| | BetterAuth | ~10 lines (hooks) | ✅ Yes | query | | passport-oauth2 | ~10 lines (strategy) | ✅ Yes | query | | NextAuth.js | ~10 lines (provider) | ✅ Yes | query | | oidc-client-ts | ~10 lines (redirect) | ✅ Yes | query | Summary: All four libraries default to query response mode, so developers using the defaults would get Redirect-Query protection automatically with a library update - no code changes required. Note that form_post is NOT the default in these libraries. >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
