Re: [OAUTH-WG] Token Access Authentication Scheme Draft

[Brian Eaton <beaton at google.com>]

On Mon, Dec 7, 2009 at 12:27 AM, Eran Hammer-Lahav <eran at hueniverse.com> wrote:
> http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt

I'm not a fan, for a couple of reasons.

The signature base string (section 8 in the draft) is still very
complex to describe and construct... and even with all that
complexity, I don't think it meets most of the use cases for
two-legged OAuth that were identified in earlier conversations about
why people are using OAuth signing [1].

I'd like to propose an alternative approach for OAuth message
authentication that focuses on providing a reusable signature base
string and meeting existing two-legged OAuth use cases.  This is
fairly close to SWT [2], but I think SWT has some warts [3] that need
fixing.

If there is general support/interest in this, I'm happy to write it up
more formally.  Here's an informal version:

An OAuth message signature is made up of three components, an
envelope, a message, and a signature.  The envelope and the message
are base64 encoded JSON objects.  The signature is a base64 encoded
byte string.  The encoding uses the web-safe base64 alphabet without
line feeds or padding described by RFC 4648 [4].  The three components
are joined with '.' characters.

The envelope field is a description of the payload.  It contains a
"name" field that identifies the key used to sign the message.  It
contains an "algorithm" field that identifies the signature algorithm
used to sign the message.  And it contains a timestamp (measured in
seconds since the epoch) and a nonce used to prevent replay attacks.
For example, the envelope might look like this:

{
    "name": "source.example.com",
    "algorithm": "RSA-SHA256",
    "timestamp": 1260253850,
    "nonce": "0437f743b5809"
}

The message field contains the payload of the signed message.  For
signing an HTTP request, the message contains a single field "url",
with a copy of the HTTP URL of the request:

{
    "url": "http://destination.example.com/resource?abcd=1234";
}

Signing messages besides HTTP requests, or extending the HTTP request
signature to cover additional components of the request, is trivial:
add new fields to the JSON payload of the message.

The signature base string is generated by concatentating the base64
encoded envelope and message.  First, the envelope is encoded.  For
the example above, the envelope becomes:

ewogICAgIm5hbWUi<elided>Cg

Next, the message is encoded.  For the example above, the message becomes:

ewogICAgIm5hbWUi<elided>Cg

The envelope and the message are then joined with a '.' character:

ewogICAgIm5hbWUi<elided>Cg.ewogICAgIm5hbWUi<elided>Cg

The resulting string is signed with the specified key and algorithm.
The signature is base64 encoded and appended to the envelope and
message.  For the example above:

ewogICAgIm5hbWUi<elided>Cg.ewogICAgIm5hbWUi<elided>Cg.qSSVPG3bTw5<elided>-YFab315w

The resulting signed token can then be embedded in an HTTP header:

Authorization: Token
ewogICAgIm5hbWUi<elided>Cg.ewogICAgIm5hbWUi<elided>Cg.qSSVPG3bTw5<elided>-YFab315w

Verification of the signature is trivial, because it does not require
reconstructing the signature base string or canonicalization of
values.  The exact data that was signed is present in the request.

Cheers,
Brian

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg00530.html
[2] https://oauth-wrap-wg.googlegroups.com/web/SWT-v0.9.5.1.pdf
[3] https://groups.google.com/group/WRAP-WG/browse_thread/thread/a88135610e57b976
[4] http://tools.ietf.org/html/rfc4648#section-5