OIDC SSO invites break redirect URI

[Max Allan]

I enabled OIDC login on my hosted Landscape

Sent a user invitation :
https://landscape.example.com/new-user?invitation=QagbZkCuP6Fqqq

On clicking, we see a message :
"Landscape uses Ubuntu Single Sign On to identify you. Please login or create an Ubuntu Single Sign On account now to accept this invitation.""

With a link to :
https://landscape.example.com/login/authenticate?invitation=QagbZkCuP6Fqqq

Which 302 redirects to :

https://accounts.google.com/o/oauth2/v2/auth?scope=openid+profile+email&state=6a921b52434c&redirect_uri=https%3A%2F%2Flandscape.example.com%2Flogin%2Fhandle-openid%3Finvitation%3DQagbZkCuP6Fqqq&response_type=code&client_id=9563-mqudifr4.apps.googleusercontent.com

Thus the redirect URI is set to "https%3A%2F%2Flandscape.example.com%2Flogin%2Fhandle-openid%3Finvitation%3DQagbZkCuP6Fqqq"

Which is clearly different from the defined URI https://your_landscape/login/handle-openid
(as defined in https://docs.ubuntu.com/landscape/en/onprem-auth)

The redirect URI should be a static URI, the same for each and every request.

As explained here https://www.oauth.com/oauth2-servers/redirect-uris/redirect-uri-validation/ :

> The service should look for an exact match of the URL, and avoid matching on only part of the specific URL. (The client can use the state parameter if it needs to customize each request.) Simple string matching is sufficient since the redirect URL can’t be customized per request.

And many other documents about OIDC.

SECURITY ISSUE :
I have a slight concern that Ubuntu's own SSO server is accepting these wildcarded redirect URIs and is potentially vulnerable to a covert redirect issue (https://oauth.net/advisories/2014-1-covert-redirect/) But haven't the time to experiment. You might want to raise it with them when you fix Landscape to work properly.

[Simon Poirier (simpoir)]

I dug quite a bit into this. It doesn't look like we've got a covert redirect vulnerability here. To be clear, there is a redirect (invitation) but it is limited to the specified resource on the server (not open redirection).
I don't quite see that as vulnerable.

Furthermore, the added "invitation" query parameter does not invalidate matching of the redirect_uri, as query parameters are allowed per
https://tools.ietf.org/html/rfc6749#section-3.1.2

However, I do agree that we should switch to use the state parameter instead, if only to follow recommendations
https://www.oauth.com/oauth2-servers/redirect-uris/redirect-uri-registration/#per-request

[BloodyIron (bloodyiron)]

So does this mean Hosted/SaaS Landscape has SSO then? Because I'm now seeing conflicting info about such a feature.

[Simon Poirier (simpoir)]

SaaS talks to UbuntuSSO using openid2.0, which is a completely different protocol (not oauth2), so that bug doesn't apply to SaaS.