Question about restrictions on redirect_uri

[mimi89999]

Hello, Are there any restrictions on the redirect_uri for the open client? If not, is there any mechanism preventing the following scenario?

1. A malicious actor sends an email
2. A user opens the email
3. The user clicks on a link in the email
4. The user is redirected to a malicious website that initiates the OAuth2 Authorization process
5. The user is then redirected to the authorization server that displays a message like: "Do you want to authorize an open client/a client to access your emails?" "Do you want to authorize Firefox to access your emails?" (If the software name is taken from the user-agent http header
6. The user is very confused about that unexpected dialog and accepts it
7. The user is redirected to the malicious website that obtains the OAuth2 authorization code
8. The malicious website redirects the user to a legitimate/neutral website

[benbucksch]

Thank you for the specific threat scenario.

You are right that the redirect URI is part of the client registration and therefore we need to specify it here in the spec.

I would restrict the redirect URI to http[s]://localhost:/ That: a) stops that attack at step 7 b) ensures that the app can optionally use the system browser or an embedded browser without special API. c) ensures that this client ID is indeed used by a client that is running locally on the user's machine, and not any web app.

Do you concur? I will update the spec accordingly. -- Sent from my phone. Please excuse the brevity.

[mimi89999]

The http[s]://localhost:*/* restriction on redirect_uri can't be a simple regex as URLs with HTTP authorization like https://localhost:anything@example.com/ will match.

As for restricting the host to localhost and allowing any port and any URL, I'm not sure.

On multi user PCs, another user could start a HTTP client on say port 1234 and then send the user a message with a URL with redirect_uri=http://localhost:1234/. However, I guess that the second user could do much worse things having physical access to that computer like installing a physical key logger.

On Android devices, a user might be tricked into installing an innocent looking app like a torch that doesn't require any special permissions. The app would also have to be running in the background on say port 1234 and the previous scenario would also apply.

So I'm not quite sure about the safety of that solution. I guess that a malicious actor could do much more harm having physical access to a computer or by tricking a user into installing malware.

[mimi89999]

I found RFC 8252: Best practice fir OAuth 2.0 for Native Apps

It recommends using a private URI scheme. I tested it on Android and it works quite well:

<intent-filter>
    <action android:name="android.intent.action.VIEW"/>
    <category android:name="android.intent.category.BROWSABLE"/>
    <category android:name="android.intent.category.DEFAULT"/>
    <data android:scheme="mimi89999"/>
</intent-filter>

It doesn't require the app to be running in the background and nicely redirects the user back to the app.

However, we need to be extra careful and not allow an attacker to set the scheme to a network protocol (like http, https) as that might result in a request being made to an external server (possibly controlled by the attacker) that would leak the token.