Re: [OAUTH-WG] redirect uri and portals

[Jaimandeep Singh <[e-mail]>]

Dear Yannick,

1. You have brought out a very valid design issue. I think it is a
good design imperative to land back on the same webpage from where we
started the oauth process. While there are various ways to handle this
problem at the application level, why should we do the same in custom
ways,  when we have specifications that can provide a standardized way.
Therefore, I suggest that we incorporate this requirement as a design goal
for the specification.

2. Once we have agreed that it is a valid design goal, we can discuss ways
to handle the same such as:

(a) The client includes redirect_uri in the request which currently has no
practical use. However, it can be utilized to store information about the
current page where the client is engaged. We can compare the domain of the
`request_uri` with the `registered_uri` at auth server (non-standard
terminology is used here for ease of comprehension) and then redirect the
page back to `request_uri`, if it meets the specified criteria such as same
domain as that of `registered_uri`. Additionally, we can incorporate other
fields at the time of client application registration with the
authorization server such as `strict` and `lax` similar to those used in
same-site cookie management  [draft-rfc referred here
<https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-11.html#name-same-site-and-cross-site-re>].
The `strict` setting can enable strict domain checking, whereas the `lax`
setting can allow subdomains. This will at least address the routing
problem.

(b) Alternatively, we can move client application authentication before
starting the user interaction as already mentioned in the PAR
specification. And also suggested here
<https://www.researchgate.net/publication/367557833_Unified_Singular_Protocol_Flow_for_OAuth_USPFO_Ecosystem>
.

These can be considered for discussion in the upcoming IETF.

Regards
Jaimandeep Singh

On Tue, Mar 7, 2023 at 4:04 AM Yannick Majoros <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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 <[e-mail]> 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 <[e-mail]>
>>>>>> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Yannick Majoros
>>>>> Valuya sprl
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>
>>> --
>>> Yannick Majoros
>>> Valuya sprl
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Regards and Best Wishes
Jaimandeep Singh
LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>