Re: [OAUTH-WG] Defining a maximum token length?

[Brian Eaton <[e-mail]>]

On Tue, Mar 9, 2010 at 4:44 PM, David Recordon <[e-mail]> wrote:
> I believe that Google wishes to encode information within access
> tokens so that they can be verified in a stateless manner.  Brian, how
> many characters do you need?

I think it would be OK to make request tokens short.  They are
service-specific passwords, and can/should be treated as such.

For authorization servers: store cryptographically strong one-way
hashes.  No need to salt the hashes, because they are very
high-entropy already.

For clients: store them in a DB that is locked down as tight as you
can get it.  Plan on changing your client secret when the DBA leaves
the company.

(hrm, I just saw that Torsten has a use case for refresh token ==
encrypted blob.  I am deeply suspicious.)

For most deployments, access tokens are basically like session
cookies.  Some deployments use self-verifying cookies with keys stored
server-side, other people store sessions in databases or in-memory.
There are lots of fun trade-offs here.  The choices you make have
fundamental impacts on every facet of your systems, ranging from DNS,
to load balancers, to frontends, to backend servers.  The choice
ripples out to impact scalability, security, latency, and availability
*everywhere*.

It would be a mistake for the spec to say that access tokens have to
be short - that one decision impacts way too many other things.

The non-opaque access token use cases (SWT, claims in access tokens)
are interesting, and for those use cases access tokens can't be short
either.

Cheers,
Brian