Subject: [OAUTH-WG] message signing use case

From: Justin Smith <[email-masked]>
Date: Wed, 3 Mar 2010 21:05:18 +0000

During the last call I volunteered to write a use case that warrants message signing. After thinking about the problem for a bit, it is no longer abundantly clear to me that message signing needs to be addressed in OAuth (clearly signing a token is a different story). 

However, here's the use case that I've run into a few times while building layered systems. It may help anchor the discussion on message signing. 

I'd like to hear what the group thinks.

Actors & Background:
1) Protected Resource - A service front-end that crunches data and returns results / reports. Processing these reports can take time, depending on complexity and load (seconds to hours). Only subscribed clients can access the service. Clients pay for the amount of time they use the service. The Protected Resource uses tokens issued by an Authorization Server in order to access the Protected Resource. The Protected Resource uses SSL for all inbound connections, but the SSL connection is terminated early (at an appliance).
2) Client - An autonomous client that intermittently requests data / reports from the Protected Resource. Before requesting data / reports from the Protected Resource, the Client must acquire a token from the Authorization Server.
3) Authorization Server - A service that authenticates Clients and issues tokens that eventually grant access to the Protected Resource. The Authorization Server uses SSL for all connections with Clients.

Challenge:
The Protected Resource needs to be able to handle processing that takes quite a bit of time, and it can arrive in bursts. When the Protected Resource receives a message from a client, it validates the token in the message, pushes authorized requests into a queue for future processing, and returns the client an ID of the job in the queue. An internal system pulls messages from this queue and processes them. By the time the message is in the queue, it is in clear text and could be tampered with. If a message is tampered with, all sorts of bad things can happen (easy to imagine possibilities). The Protected Resource needs a way to guarantee the data hasn't been tampered with after the message is pulled from the queue and before processing.

Possible Solutions:
a) Require the client to sign the message (URI, Token, other headers, and Body) before sending to the Protected Resource. The Protected Resource just pushes the message (URI, Token, other headers, Body, signature) into the queue.
b) The Protected Resource signs the message (or some transformation of it) after the message is received and before pushing the message into the queue.

Solution (a) has drawbacks. It forces the Protected Resource to know the signing keys (public or symmetric) used when signing the message. It also exposes several parts of the Protected Resource to versioning issues, so if the public API changes (message formats), multiple layers of the system need to be aware of the change.

Solution (b) seems more appealing. The Protected Resource front end needs to have a signing key that is shared with the back-end. Customers don't see it. Additionally, the back-ends don't necessarily have to be aware of changes in the message format; the front ends can transform the message to a canonical format.

--justin