Okay, I'm with you. Some text guiding the more obvious (to me anyway) usage might still be useful. Something like,
"If Authorization Code value is a reference to state on the server, the value MUST/SHOULD be constructed from a cryptographically strong random or pseudo-random number sequence [RFC1750] where the probability of two Authorization Code values being identical is less than or equal to 2^(-160)." It's not as clean the previous text but still maybe useful. I'm guessing you don't want any language restricting the length of the code? Though there is some practical limit due to the URL length in the 302 (I think it has to be a redirect). On Thu, Jul 15, 2010 at 3:30 PM, Brian Eaton <bea...@google.com> wrote: > 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
