Hi Rodrigo, Thanks for the link. I'm already familiar with that document, but maybe you can point me to some part that I missed.
My questions are: - In a context where all redirect URIs are under our control, how is passing state and validating it back after login better, from a security point of view, than validating redirect uri in the routing implementation of the application? Both sound equally secure to me, though redirect_uri seems much easier to implement. - How can I implement that use case easily: after login, redirecting the user back to the originally requested page, including parameters? Is that somehow covered in the document you provided, or somewhere else? - And regarding that document, isn't 4.1.1 easily mitigated by PKCE anyway? I'm currently under the impression that this is a very common and legitimate use case, but that it is somehow underspecified and that everyone is reimplementing a variant of state passing + custom redirection after login. I'm failing to understand how such an implementation, besides being non-standard anyway, would be better than redirect URI patterns, in a controlled context. More thoughts on that? Thanks, Yannick Le lun. 6 mars 2023, 22:08, Rodrigo Speller <rspel...@primosti.com.br> a écrit : > Hi Yannick, > > There is a work-in-progress draft that touches many threats and best > practices when implementing OAuth 2 [ > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/21/]. I > recommend that you read entire document, but, especially, about your > questions, you may understand the threats about wildcards URL validation in > section 4.1.1. > > This document also addresses some state threats and best practices. > > Rodrigo Speller > > > Em seg., 6 de mar. de 2023 às 17:06, Yannick Majoros <yann...@valuya.be> > escreveu: > >> Hey Aaron, >> >> Sure, this is some kind of open redirector. I had a similar example with >> Uber. Still, those examples involve integrations with 3rd party >> applications. It also seems to me that they either imply implicit flow, or >> an authorization code not protected by PKCE. Aren't we mitigating these use >> cases anyway? >> >> So, I'm wondering: >> - How should I implement a redirection to the page which was requested >> before login (which optionally takes parameters)? I understand I can use >> some persisted state for that, but what then? Should the portal or company >> web site know about all application URLs underneath it, with all their >> parameters, to be able to validate them against a list? >> - How is that better, from a security point of view, than having a >> redirect to our domain, with a wildcard, making all applications that need >> some form of routing to validate their URLs? >> >> >> >> Le lun. 6 mars 2023 à 20:38, Aaron Parecki <aa...@parecki.com> a écrit : >> >>> 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 >>>> >>> >> >> -- >> 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
