On Thu, Jul 15, 2010 at 2:16 PM, Brian Campbell <bcampb...@pingidentity.com> wrote: > I must admit to never having considered the authz code as anything but > a random string as a reference that must be resolved. Can you expand > on your thinking a bit, if only to enlighten me? > > Are you thinking of embedding what would be the entire access token > response to the eventual authorization_code grant type request inside > the access token itself and encrypting and/or singing it?
Yes. The oauth2 authorization code and the SAML artifact are similar in that they end up creating this pattern: user in location A creates some value value is transferred to location B server in location B resolves value value expires If A and B are geographically distant, you end up having to replicate rapidly changing state. that's expensive, and not terribly useful. If you use a stateless implementation (e.g. authorization code is a signed blob containing the client-id, the user-id, the list of scopes granted, a timestamp, and a hash of the callback URL) things are much more efficient. The code is a bit longer. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
