Re: [OAUTH-WG] redirect uri and portals

[Aaron Parecki <[e-mail]>]

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