2

When operating an OAuth2 Authorization Server:

The authorization server MUST require the following clients to register their redirection endpoint:

o Public clients.

o Confidential clients utilizing the implicit grant type.

The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint.

...

Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint as an open redirector as described in Section 10.15.

Is there any added security benefit to enforcing a uniqueness constraint on registered redirect_uris? That is, any given redirect_uri could be associated with at most one particular client?

I'm thinking particularly for the case of public clients, where the redirect_uri is the only means the authorization server has to identify the client (since the client cannot protect client credentials), but I'm also interested in answers about private clients.

Are there any vulnerabilities exposed if an attacker could register a new client with the same redirect_uri as an existing client?

3 Answers 3

2

There's really no good way to even securely guarantee that a client is what it says it is, so there's really no point in trying to make each redirect URI unique to a single client. The only reason why you register URIs to begin with is to prevent the open redirect scenario mentioned in the documentation, which would make it trivial to say, configure an evil client that you redirect to after authentication, allowing it to masquerade as a benign client. It does not solve problems like DNS poisoning or host-file modifications.

Since there's no way to guarantee that a client is the same requester as the last time it made a request, because of the stateless nature of HTTP servers, what this means in the long run is that you'd have to issue a nonce each time the client wanted to connected by some secure side-channel, and authorize the request that way. For private clients, that may as well be impossible, because someone could figure out how to do so by reverse engineering the app that does this. For public clients, this would be feasible, but would add extra complexity and a small delay for each request.

There's no scenario that makes a unique client constraint more secure than not having such a rule, because any way that could be used to bypass one could also be used to bypass the other, it just adds a layer of obscurity. It wouldn't even trivially slow down a determined attacker in the case of a private client, and public clients are protected through other means anyways (including a client secret, a type of password that only that client should know).

1

Note that enforcing uniqueness actually causes a variety of problems.

The simplest example is that you're restricting who gets to use https://localhost:8080/ to a single client. Any other client trying to use https://localhost:<port>/ would have to play a guessing game with ports to find an available URI.

Additionally, you're establishing a form of claim to a domain by doing this. Unless you're using something like ACME to enforce that clients actually own the URIs that they're registering, you're allowing a client to lay claim to a URI that it doesn't own. A careless (or malicious) client could register for URIs like https://www.whitehouse.gov/oauth_redirect. If the real whitehouse.gov comes along to register a URI, that value is no longer available -- and there's no way to take that URI away from the other client.

Such a collision isn't necessarily a likely accidental occurrence across different institutions, but whitehouse.gov might register multiple clients. Here you run into other problems: if whitehouse.gov wants to transition from one client to another without changing a redirect URI, they aren't able to do so.

I would also express a mild, general concern over the assumption that seeing a given redirect URI means definitively that the service is interacting with a specific client. No such assumption can or should be made.

0

Redirect URI's don't need to be, nor should they be, globally unique. They should only be unique within a clients profile. Redirect URI's don't necessarily correspond to a real, physical address. They simply need to be understood by the client, and verified by the server.

Client ID's however should be globally unique.

When a client is requesting authorization, it should provide it's client ID, and redirect URI.

If I'm creating a client browser app, my development redirect URI will likely be something like http://localhost:8888/check_auth, it shouldn't matter if someone else happens to have used this same redirect URI.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .