I have also seen what you describe in 2, as well as a variation of that, which is to encode the redirect in the "state" parameter, as described (briefly) in RFC6749 https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2.2
Note that using "state" to carry this redirect should only be done with a fixed list of destinations or by using a signed "state" value like encapsulating it in a JWT in order to avoid creating an open redirector: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.10.1 There is even a claim described in the (expired) JWT-encoded state draft to specify this redirect target: https://datatracker.ietf.org/doc/html/draft-bradley-oauth-jwt-encoded-state-09#section-2 Aaron On Mon, Mar 6, 2023 at 9:28 AM Vittorio Bertocci <vittorio= 40auth0....@dmarc.ietf.org> wrote: > 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 >> > _______________________________________________ > 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
