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
