Subject: [OAUTH-WG] Redirection URI and Implicit grant

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 12:37:54 -0700

This is coming from recent experience building a full web service and multiple clients using OAuth 2.0. I am going to make these changes to my own implementation and would like to raise the questions here and discuss possible changes.

A few questions:

1. Why not require the registration of a redirection URI for implicit grant requests, removing the redirect_uri parameter completely from the request (the client can still use the state parameter)?

2. What is the value of the client_id when a redirection URI is not pre-registered? The client identity cannot be verified without other means for the purpose of informing the user who is asking for access, no refresh token is issued, and the redirect_uri parameter contains the only useful information for both the flow and identifying the client (to the extent it can be trusted not to be an open redirector).

3. Are there real use cases for performing redirection URI matching against a pre-registered value, where partial (i.e. not string) comparison is needed? Why can't this be solved by simply using any URI variations into the state parameter?

Changes I would like to see:

The implicit grant should be split into 2 flavors (can be given different grant type name or just using normative language to define the restrictions), one with client_id and state, and one with redirect_uri only.

Registered client: the client request token response type by including its client identifier and optional state parameter. No redirect_uri is allowed. The authorization server will be able to inform the user about the client identity, where the token will be sent (the domain of the registered URI, if the server can verify if the endpoint is not an open redirector), and prevent others from hijacking the client identifier for their own application. The exception is when using custom URI schemes which other applications can hijack on the local operating system (but that's the least of our concern if a native application is doing bad things).

Unregistered client: the client request token response type by including a redirection URI (no client_id or state). The authorization server may require registration of the redirection URI for the purpose of accepting terms of service, but not issue an client identifier which is useless without a registered redirection URI. This way, the operator of example.com can go to the authorization server and ask to enable issuing tokens to requests with callbacks at example.com, in case the authorization server requires some legal contracts before sharing data.

EHL

---

From: Shane B Weeden <[email-masked]>
Date: Thu, 16 Jun 2011 08:19:27 +1000

> From: Eran Hammer-Lahav <[email-masked]>
> To: OAuth WG <[email-masked]>
> Date: 16-06-11 05:43 AM
> Subject: [OAUTH-WG] Redirection URI and Implicit grant
> Sent by: [email-masked]
>
> This is coming from recent experience building a full web service
> and multiple clients using OAuth 2.0. I am going to make these
> changes to my own implementation and would like to raise the
> questions here and discuss possible changes.
>
> A few questions:
>
> 1. Why not require the registration of a redirection URI for
> implicit grant requests, removing the redirect_uri parameter
> completely from the request (the client can still use the state
parameter)?

I can imagine situations where one-or-more redirect URI's may be required
rather than a single explicit URI. I think that either a
child-urlpath-of-the-registered URI, and/or the ability to register
multiple valid URI's for a particular client id allows this without being
overly restrictive.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 18:09:44 -0700

> -----Original Message-----
> From: Shane B Weeden [mailto:[email-masked]]
> Sent: Wednesday, June 15, 2011 3:19 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant
> 
> > Subject: [OAUTH-WG] Redirection URI and Implicit grant Sent by:
> > [email-masked]
> >
> > This is coming from recent experience building a full web service and
> > multiple clients using OAuth 2.0. I am going to make these changes to
> > my own implementation and would like to raise the questions here and
> > discuss possible changes.
> >
> > A few questions:
> >
> > 1. Why not require the registration of a redirection URI for implicit
> > grant requests, removing the redirect_uri parameter completely from
> > the request (the client can still use the state
> parameter)?
> 
> rather than a single explicit URI. I think that either a child-urlpath-of-the-
> registered URI, and/or the ability to register multiple valid URI's for a
> particular client id allows this without being overly restrictive.
> 

Then just use multiple client identifiers if you need multiple redirection URIs, or better yet, use the state parameter and route the request on the client side based on the state value. Authorization server who want to be fancy can allow you to register more than one and let you indicate which one you want by adding a suffix to the client id (say 'abcd-1' to pick URI 1).

I want to be restrictive because right now we offer too many insecure combinations for the implicit grant.

EHL

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 16 Jun 2011 12:36:52 +1000

It seems like an authorization server receiving a request with an unregistered redirect_uri of https://example.org/ can tell the user:

  "Permission will be passed to your browser then onto *example.org*"

An authorization server receiving a request with a registered redirect_uri of https://example.net/ can tell the user:

  "Permission will be passed to your browser then onto *WidgetXYZ by Example Inc (example.net) [logo]*"

Where the label, company, and logo are extra details from the registration, hopefully after some verification by the authorization server that all these details are a consistent set. That verification could come from some discovery on the redirect_uri, or from reputation stats - perhaps even without a priori registration.

We might be better off ditching the client_id field and just keeping redirect_uri in the implicit grant. If the value is registered (or the server has done some discovery on it, or has some reputation stats for it) it can display a more user-friendly permission message.

The difference between registered and unregistered for clients without secrets feels like a continuum, not black and white. So separate flavours (client_id+state vs redirect_uri) makes less sense to me.

--

James Manger

From: Brian Eaton [mailto:[email-masked]]

Security for the implicit grant type comes from identifying the client based on the redirect URI.  At client registration time, you bind client_id X to redirect URIs Y and Z.

If the redirect URIs use HTTPs, that gives you reasonable security.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav

Registered client: the client request token response type by including its client identifier and optional state parameter...

Unregistered client: the client request token response type by including a redirection URI (no client_id or state)...

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 19:50:54 -0700

I would be interested in working out a solution where client identifier is just the redirection URI registered (or not), which would completely decouple client authentication from the rest of the flow. But that's a much bigger change.

EHL

From: Manger, James H [mailto:[email-masked]]
Sent: Wednesday, June 15, 2011 7:37 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Redirection URI and Implicit grant

--
James Manger

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 09:19:05 -0700

On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> 1. Why not require the registration of a redirection URI for implicit grant
> requests, removing the redirect_uri parameter completely from the request
> (the client can still use the state parameter)?
>

As others have stated, this is a bad idea because there are legitimate
reasons for a single client to have multiple redirect URIs.

> **
>
> 2. What is the value of the client_id when a redirection URI is not
> pre-registered? The client identity cannot be verified without other means
> for the purpose of informing the user who is asking for access, no refresh
> token is issued, and the redirect_uri parameter contains the only useful
> information for both the flow and identifying the client (to the extent it
> can be trusted not to be an open redirector).
>

I think you're saying that redirect URIs should always be preregistered for
the implicit grant flow.  That's a very good idea.

> 3. Are there real use cases for performing redirection URI matching against
> a pre-registered value, where partial (i.e. not string) comparison is
> needed? Why can’t this be solved by simply using any URI variations into the
> state parameter?
>

I don't understand this question.

> Authorization server who want to be fancy can allow you to register more
than one and let you indicate which one you want by adding a suffix to the
client id (say 'abcd-1' to pick URI 1).

This is a bad idea.  Client identifiers are like usernames; you wouldn't
tell a user to use a different variety of their username, don't tell
developers that they have to use a different variety of their client
identifiers.

Please don't tamper with these protocol flows.  The protocol flows are fine
as is.  There should be language making it clear that registration is
required.  Everyone is doing that already, so that's not a particularly
disruptive change.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 16 Jun 2011 10:48:29 -0700

I think we want the same thing and I can adjust my proposal to align with your comments below. I'll post in a separate thread.

EHL

From: Brian Eaton [mailto:[email-masked]]
Sent: Thursday, June 16, 2011 9:19 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant

On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
1. Why not require the registration of a redirection URI for implicit grant requests, removing the redirect_uri parameter completely from the request (the client can still use the state parameter)?

As others have stated, this is a bad idea because there are legitimate reasons for a single client to have multiple redirect URIs.

I think you're saying that redirect URIs should always be preregistered for the implicit grant flow.  That's a very good idea.

> Authorization server who want to be fancy can allow you to register more than one and let you indicate which one you want by adding a suffix to the client id (say 'abcd-1' to pick URI 1).

This is a bad idea.  Client identifiers are like usernames; you wouldn't tell a user to use a different variety of their username, don't tell developers that they have to use a different variety of their client identifiers.

Please don't tamper with these protocol flows.  The protocol flows are fine as is.  There should be language making it clear that registration is required.  Everyone is doing that already, so that's not a particularly disruptive change.

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 17 Jun 2011 19:22:56 -0700

On Wed, Jun 15, 2011 at 6:09 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Then just use multiple client identifiers if you need multiple redirection URIs, or better yet, use the state parameter and route the request on the client side based on the state value.

If you allow localhost or non-routable IP addresses in the redirect
URI this is not possible.

> Authorization server who want to be fancy can allow you to register more than one and let you indicate which one you want by adding a suffix to the client id (say 'abcd-1' to pick URI 1).

What Brian said. Plus, this is extremely fragile and confusing, as
soon as the client edits its registration information the order may
change.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 17 Jun 2011 19:25:24 -0700

On Wed, Jun 15, 2011 at 7:36 PM, Manger, James H
<[email-masked]> wrote:
> It seems like an authorization server receiving a request with an
> unregistered redirect_uri of https://example.org/ can tell the user:
>
>
>
>   “Permission will be passed to your browser then onto *example.org*”
>
>
>
> An authorization server receiving a request with a registered redirect_uri
> of https://example.net/ can tell the user:
>
>
>
>   “Permission will be passed to your browser then onto *WidgetXYZ by Example
> Inc (example.net) [logo]*”
>
>
>
> Where the label, company, and logo are extra details from the registration,
> hopefully after some verification by the authorization server that all these
> details are a consistent set. That verification could come from some
> discovery on the redirect_uri, or from reputation stats – perhaps even
> without a priori registration.
>
>
>
> We might be better off ditching the client_id field and just keeping
> redirect_uri in the implicit grant. If the value is registered (or the
> server has done some discovery on it, or has some reputation stats for it)
> it can display a more user-friendly permission message.

Several clients may register the exact same redirect URI: localhost or
non-routable IP address. You cannot uniquely identify the client based
on the redirect URI.

Similarly, you cannot perform discovery in these cases either.

Marius