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
