On Tue, Mar 9, 2010 at 4:44 PM, David Recordon <record...@gmail.com> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
