Subject: [OAUTH-WG] Clarification: authorization server matching of redirect URI

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 21:22:04 -0700

Some AS will match part of the URI to what was registered, some require everything up to the start of a query. The spec needs to clarify how much of the URI needs to be matched, or state it is AS specified.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 18 Apr 2010 22:16:20 -0700

This is where limiting variations to a client state parameter helps, but consensus was that we cannot limit clients not to use local query parameters outside the state.

The problem with giving specific guidance is that it can open security holes. For example, not checking the value of a query parameter can turn the callback into an open redirector. On the other hand, limiting the sub-domain can make scalability harder.

Care to propose text?

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dick Hardt
> Sent: Sunday, April 18, 2010 9:22 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Clarification: authorization server matching of redirect
> URI
> 
> Some AS will match part of the URI to what was registered, some require
> everything up to the start of a query. The spec needs to clarify how much of
> the URI needs to be matched, or state it is AS specified.
> 
> -- Dick
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 22:35:47 -0700

The spec should describe how the redirect URI is verified to what is registered. I can enumerate the options for discussion adding in the state parameter as an option.

---

From: Brian Eaton <[email-masked]>
Date: Mon, 19 Apr 2010 08:36:50 -0700

> The spec should describe how the redirect URI is verified to what is registered. I can enumerate the options for discussion adding in the state parameter as an option.

Note that there are two spots where the AS does some URI matching.

The first is before redirecting the user to the callback URI.  This
seems doomed to being service provider specific, unfortunately.

The second is when exchanging the verification code for the refresh
token and access token.  This can always be a string equality match.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 08:39:42 -0700

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Monday, April 19, 2010 8:37 AM
> To: Dick Hardt
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] Clarification: authorization server matching of
> redirect URI
> 
> > The spec should describe how the redirect URI is verified to what is
> registered. I can enumerate the options for discussion adding in the state
> parameter as an option.
> 
> The first is before redirecting the user to the callback URI.  This seems
> doomed to being service provider specific, unfortunately.

I agree. If someone wants to suggest some security consideration text that would be good.

> The second is when exchanging the verification code for the refresh token
> and access token.  This can always be a string equality match.

It should be a case-sensitive string comparison with the value provided by the client in the first step.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Mon, 19 Apr 2010 10:16:23 -0700

> I agree. If someone wants to suggest some security consideration text that would be good.

See page 9: http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/OAuth%20WRAP%202.0%20Security%20Considerations.pdf

Cheers,
Brian

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 10:45:33 -0700

> I agree. If someone wants to suggest some security consideration text that would be good.

If this is authz server specific I can see the following problem:
- authz server 1 allows regular expressions in registered callback URLs
- client integrates with authz server 1 and designs its own
implementation based on these callback URLs, uses load balancing on
different hosts and passes state through query parameters
- authz server 2 comes along and it requires strict matching on callbacks
- client wants to integrate with authz server 2 as well, but will have
to rewrite everything because the load balancing and state
infrastructure will not work

In order to support interop I think it would be useful to specify how
callbacks are matched.

Proposal:
- path and query string are strictly matched (the spec has a state parameter)
- host names can contain a wild card (to allow for load balancing)
- port and scheme strictly matched

For example:
- registered callback: https://*.example.com/client?controller=oauth2
- matching callbacks:
  https://example.com/client?controller=oauth2
  https://sv1.example.com/client?controller=oauth2
  https://sv2.n1.example.com/client?controller=oauth2
- not matching:
  https://example.net/client?controller=oauth2
  https://example.com/client?controller=oauth2&user=x
  http://example.com/client?controller=oauth2
  https://example.com:8080/client?controller=oauth2

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 11:19:54 -0700

I am not sure we can specify how callbacks are registered which is where your syntax resides. The whole registration process is out of scope. The server has *something* and needs to match the callback in the request to it.

My proposal is to provide a narrow facility with the client state parameter which makes this simple, but somewhat limited, and allow servers to support a more robust system using any client provided callback parameter.

My problem is that I don't know where to put these rules because we don't have a section dealing with callback registration.

EHL

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Monday, April 19, 2010 10:46 AM
> To: Eran Hammer-Lahav
> Cc: Brian Eaton; Dick Hardt; OAuth WG
> >> Subject: Re: [OAUTH-WG] Clarification: authorization server matching
> >> of redirect URI
> >>
> >> registered. I can enumerate the options for discussion adding in the
> >> state parameter as an option.
> >>
> - client integrates with authz server 1 and designs its own implementation
> based on these callback URLs, uses load balancing on different hosts and
> passes state through query parameters
> - client wants to integrate with authz server 2 as well, but will have to rewrite
> everything because the load balancing and state infrastructure will not work
> 
> In order to support interop I think it would be useful to specify how callbacks
> are matched.
> 
> Proposal: