Re: [OAUTH-WG] authz code randomness (was: single use authorization codes)

No normative language needed. Security consideration is the right approach. 

EHL

On Jul 15, 2010, at 19:05, "Brian Campbell" <bcampbell@pingidentity.com> wrote:

> 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 <beaton@google.com> wrote:
>> On Thu, Jul 15, 2010 at 2:16 PM, Brian Campbell
>> <bcampbell@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