I very much agree with Neil here, sending the authorization code to application URLs is a recipe for leaking that code through the Referer header to any remote site that content is loaded from (JS, analytics, images etc. etc.). In addition to the inherent risk of "sloppy" pattern matching, underestimation of what applications, frameworks and plugins are actually added to the attack surface is the biggest risk, not in the least because these will change over time. Using a fixed, hardened endpoint is the only safe choice here, managing state at that endpoint to be able to redirect to the original application URL is a small trade off compared to the previously mentioned risk.
Hans. On Tue, Mar 7, 2023 at 10:59 AM Neil Madden <neil.e.mad...@gmail.com> wrote: > On 6 Mar 2023, at 17:10, Yannick Majoros <yann...@valuya.be> wrote: > > > Hello, > > From my understanding, OAuth 2 as well as 2.1 do not allow for wildcards > in redirect_uri . Now, a common requirement for a portal or company-wide > website, where multiple applications are deployed, is to be able to login > and come back to the page from which the login was triggered. > > > When you talk about login here, are you talking about OIDC? > > > How can this be achieved securely with OAuth? > > Some options: > 1) passing a parameter, say *callback_uri*, around from auth request back > to redirect from auth server. > 2) storing some state, e.g. in session storage, and redirect after login > 3) violating the specifications and just use a redirect uri with a > wildcard in the last part (some implementations, like keycloak, allow that) > > 1) and 2) are kind of similar IMO: the application has to validate > whatever context comes and redirect to the right page, akin to deep linking > But then, outside of some extra validation, I'd prefer to have a standard > mechanism (less bypassing the restrictions) as redirect uri than to > reinvent the wheel for each application, which is what that kind of > callback url does. Also, I'm not sure why that extra validation would > improve things in practice: if there is a vulnerability in the application > routing code leading to some vulnerable redirect, wouldn't it just be > duplicated in that validation step? > > So, I'm tempted to go for 3, knowing we would have those mitigations: > - checking at authorization server whether the redirect is to the same uri > the request originally came from > - PKCE will restrict reuse of the authorization code anyway > > > I'm not sure PKCE does actually prevent all the issues here. Generally > speaking the target for the redirect_uri should be a minimal page that just > does the code exchange. That page should not be loading any content or > large JS frameworks or adverts/social media integrations, etc. Otherwise > the attack surface is enormous. > > For example, if you are doing an OIDC flow for SSO then you do the code > exchange on that page and then set a secure/http-only cookie or setup a > service worker or a BFF or .... If every single page in your app is > potentially responsible for doing this code exchange then a single mistake > by any developer can completely compromise the security of your site. Have > one hardened endpoint that does this and performs the app-specific setup > and then redirect from there using one of the patterns others have pointed > out in this thread. > > -- Neil > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandb...@openidc.com OpenIDC - www.openidc.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
