There is no situation in which supporting arbitrary redirects (whether from the OAuth redirect URI or within your own app) is a good idea.
This is known as an Open Redirector, and is the basis of many attacks on OAuth as well as other things unrelated to OAuth. OWASP has a cheat sheet about this as well: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html There was an example published just last week of combining a wildcard redirect_uri with another open redirector to accomplish an account takeover. It's worth reading the writeup if you're curious about the implications of wildcard redirects within and outside of OAuth. https://salt.security/blog/traveling-with-oauth-account-takeover-on-booking-com Aaron On Mon, Mar 6, 2023 at 11:31 AM Yannick Majoros <yann...@valuya.be> wrote: > Thanks for your input. > > All of that would be quite common indeed, but in what way is it better, > from a security perspective, than redirect URIs with wildcards? > > Yannick > > Le lun. 6 mars 2023 à 18:28, Vittorio Bertocci <vitto...@auth0.com> a > écrit : > >> In my experience the most common solution, adopted by many SDKs, is based >> on 2. >> Where you redirect after you concluded the token acquisition ceremony is >> a private consideration for your app, that shouldn’t interfere with how the >> client is registered. Oauth offers you the chance to store and retrieve >> state, you can use that to save the initial requested URL and redirect to >> it after the fact. If you are concerned with injections, you can always >> sign/encryp the state to protect it from tampering. >> All of the above is mainstream, you can observe the traffic from popular >> SDKs to see how that works. >> HTH >> V. >> >> On Mon, Mar 6, 2023 at 09:12 Yannick Majoros <yann...@valuya.be> wrote: >> >>> *This message originated outside your organization.* >>> >>> ------------------------------ >>> >>> 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. >>> >>> 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 >>> >>> What are your thoughts on how to implement that quite common feature? >>> >>> Best regards, >>> -- >>> Yannick Majoros >>> Valuya sprl >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > > -- > Yannick Majoros > Valuya sprl > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
