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
