Subject: [OAUTH-WG] Requiring Cryptographic Access Tokens

From: Michael D Adams <[email-masked]>
Date: Thu, 13 May 2010 18:05:47 -0700

I'm interested in the possibility of requiring clients to use
cryptographic tokens.

Context: I'm writing a WordPress plugin to handle OAuth 2.0
authentication.  Small one-off WordPress sites (probably on a shared
host) likely cannot use SSL.  Such a site would necessarily be
non-compliant because "the authorization server MUST require the use
of a transport-layer mechanism such as TLS/SSL (or a secure channel
with equivalent protections) when sending requests to the token
endpoints".

I understand that bearer tokens over SSL are "the way of the future",
but I don't think they're the "way of the now", and the future is a
ways off for small sites.

OAuth 2.0 use case for WordPress site without SSL:
Mars Edit, Windows Live Writer, and other desktop blog editors.
(Ignore for the moment that the APIs WordPress offers to blog editors
require XML POST bodies which are unsigned by core OAuth 2.0.)

Tripartite Proposal:

1. Change the above "MUST" to a "SHOULD".

2. Somewhere in section 3. Obtaining an Access Token, add <<EOP

During an access token request over an insecure channel, the
authorization server MAY enforce the use of cryptographic tokens by
requiring the client to set the secret_type parameter.  If the
secret_type parameter is not set for such a request to such an
authorization server, the authorization server MUST issue a 400 Bad
Request response with error code "unsupported_secret_type".
EOP

3. In section 5. Accessing a Protected Resource, add <<EOP

During a protected resource request using a over an insecure channel,
the protected resource server MAY enforce the use of cryptographic
tokens.  If a bearer token is sent for such a request to such a
protected resource server, the protected resource server MUST issue a
400 Bad Request response with an error code "invalid_signature".
EOP

The wording may not be the best.  The idea is that these optional
requirements imposed by the authorization/protected resource server
should be discoverable by the client.

Requiring cryptographic tokens *isn't* necessary for a WordPress
plugin, just nice.  For example, sending bearer tokens in the clear is
no worse than sending WordPress's default auth cookies in the clear
(except that one is for API calls and one is for user-agents).

Saying that token endpoints "SHOULD" use SSL vs. "MUST" use SSL (part
1 of the above), though, would allow such sites to be conditionally
compliant instead of non-compliant.

--mdawaffe