Subject: [OAUTH-WG] MAC request URI normalization (query parameters)

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 18 Apr 2011 12:26:41 -0700

I would like to drop all the request URI parameters normalization logic and just use the raw request URI instead. A year ago during the discussion on my Token authentication scheme (which had that behavior specified), some people raised the issue that access to the raw request URI isn't always possible on the client or server. This feels like a limitation that is no longer a real problem for any modern web development environment.

If you know of actual deployment issues with using the raw request URI instead of the parameter parsing and sorting voodoo, please let me know. Otherwise, the next draft will drop that entire section.

EHL

---

From: Justin Richer <[email-masked]>
Date: Mon, 18 Apr 2011 15:35:26 -0400

Any instance of apache's mod_rewrite will bork up the request URL for
anything behind the rewrite. The server or client code behind a rewrite
will only see the rewritten URL and not the original request URL.

Why not just pack the signed string in with the payload? You would then
have rules on verification instead of normalization. The client gets to
sign the raw URL (or whatever bits, really) however it wants to, and the
server can decide if the signed bits adequately cover the full query or
not.

 -- Justin

On Mon, 2011-04-18 at 15:26 -0400, Eran Hammer-Lahav wrote:
> I would like to drop all the request URI parameters normalization
> logic and just use the raw request URI instead. A year ago during the
> discussion on my Token authentication scheme (which had that behavior
> specified), some people raised the issue that access to the raw
> request URI isn’t always possible on the client or server. This feels
> like a limitation that is no longer a real problem for any modern web
> development environment.
> 
>  
> 
> If you know of actual deployment issues with using the raw request URI
> instead of the parameter parsing and sorting voodoo, please let me
> know. Otherwise, the next draft will drop that entire section.
> 
>  
> 
> EHL
> 
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 18 Apr 2011 12:40:05 -0700

> -----Original Message-----
> From: Justin Richer [mailto:[email-masked]]
> Sent: Monday, April 18, 2011 12:35 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] MAC request URI normalization (query
> parameters)
> 
> anything behind the rewrite. The server or client code behind a rewrite will
> only see the rewritten URL and not the original request URL.

That's true for any normalization so not a valid issue (for this particular question).

> have rules on verification instead of normalization. The client gets to sign the
> raw URL (or whatever bits, really) however it wants to, and the server can
> decide if the signed bits adequately cover the full query or not.

Any duplication of HTTP request bits for the purpose of signatures (or MAC) is a really bad idea (tm). This is my main objection to the JWT family of proposals in which HTTP request components are duplicated in each request. Why use any HTTP components at all? Just use one URI with GET for all your API needs and define an internal signed structure for the request... If you do that, you are basically moving away from REST and into SOAP. To me, this is a very clear line - absolutely no duplication what-so-ever.

EHL

---

From: Kris Selden <[email-masked]>
Date: Mon, 18 Apr 2011 13:44:13 -0700

Can't the mod_rewrite in Apache set an environment variable with the original request? [E=ORIG_PATH:$1]

Or set a header if proxying the request after rewrite (similar to X-Forwarded-For or X-Forwarded-Proto) to preserve the original request path?

-----

Everyone's main interest, I'm guessing, in OAuth 2 and MAC is in protecting REST APIs.  It would be weird for MAC to treat HTTP as a transport protocol like SOAP.

If you keep it closer to HTTP, maybe we'll eventually have modules created for verifying the signature of MAC signed requests just in the web server without dealing with the backend web framework.

How cool would it be just to have a nginx module to verify the signature using the secret looked up via something like the HttpRedis or Drizzle modules.

On Apr 18, 2011, at 12:40 PM, Eran Hammer-Lahav wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth