Hi Eran,
On Jul 13, 2010, at 1:40 PM, Eran Hammer-Lahav wrote:
>
> On 7/13/10 10:25 AM, "John Kemp" <j...@jkemp.net> wrote:
>
>> On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
>>
>>> I am ok replacing it with Oacts as a password¹.
>>
>> An access token is something used by the server to decide whether a request
>> is
>> authorized. Although it may also be used for authenticating the request(er),
>> it's purpose is to authorize the request.
>
> It is used to authenticate the *request*
Can you give me a rough pointer to where that text is in the specification?
I see your assertion in section 5, but for example, the glossary definition of
"token" says:
"A string representing an access authorization issued to the
client."
(note "authorization")
and:
"Specific additional authentication
credentials may be required in order for a client to use a
token."
Which suggests that in addition to the presence of an authorizing token, the
server should authenticate the client. We could be more explicit about that,
but the idea seems to be there already (as it should, in my opinion).
> , it is used in the same manner
> other HTTP authentication schemes operate, and it has the same behavior as a
> password (security wise: plain-text storage on the client side, can be
> phished, usable by any bearer).
You may be right that the token MIGHT be stored plain-text on the client. MIGHT
be phished. MIGHT be used by someone who is not the entity to which the token
was originally given.
But it is not required to be used that way, and if the client security
properties that you mention are employed, certainly SHOULD NOT be used to
authenticate the client.
>
>> In the "bearer token" case (and even over SSL unless client certs are used),
>> the token clearly SHOULD NOT be used as a password. Rather, authentication
>> should be performed by some other mechanism, unrelated to the token itself
>> (such as an HMAC, or via client-certificate SSL/TLS, or even via an actual
>> username/password)
>
> OAuth only includes the "bearer token case". There are no other cases
> specified.
Authentication of the request is out of scope for OAuth. OK, but security
considerations should note that requests should be authenticated as well as
being authorized.
>
>> I would be very unhappy if we equated access tokens with passwords.
>>
>> I agree with Dirk that "capability" is a more expressive phrase than either
>> "shared secret" or "password".
>
> Expressive to you and people well-versed in security theory. It means
> nothing to a casual reader. The token definition includes the term,
And I am happy with the text included in the definition (as shown above). Why
should it be different in section 5?
> but in
> this section, it is referring to how an access token is used, and it is used
> just like a password.
>
> For better or worse, we turned the 1.0 access token into a 2.0 password.
I'd really like to understand why you feel that way - is there text that you
feel specifically supports your assertion that the token is used to
*authenticate* rather than *authorize* the request?
- johnk
>
> EHL
>
>> Regards,
>>
>> - johnk
>>
>>>
>>> EHL
>>>
>>>
>>> On 7/13/10 8:55 AM, "Dirk Balfanz" <balf...@google.com> wrote:
>>>
>>>
>>>
>>> On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav <e...@hueniverse.com>
>>> wrote:
>>> From the client's perspective, they are 'shared symmetric secrets' because
>>> the client has to store them as-is and present them as-is. The act exactly
>>> like passwords. I added that text to make that stand out.
>>>
>>> When using passwords, the server doesn't need to store them in plain-text
>>> either (e.g. uses a way one hash).
>>>
>>> That's why we don't call passwords "shared symmetric secrets", either. The
>>> verifier of a passwords can verify it without knowing the secret. In that
>>> sense, it's not "shared" with the verifier.
>>>
>>> I would like the specification to make it clear that bearer tokens are only
>>> secure while they remain *secret* and that *anyone* holding them can gain
>>> full access to what their protect.
>>>
>>> I think the word "capability" expresses that better than the word "shared
>>> secret".
>>>
>>> Dirk.
>>>
>>>
>>> EHL
>>>
>>> On 7/12/10 10:39 PM, "Brian Eaton" <bea...@google.com> wrote:
>>>
>>>> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5
>>>>
>>>> Calling access tokens "shared symmetric secrets" is misleading,
>>>> because if they are implemented well the authorization server and
>>>> protected resource do not store a copy of the secret.
>>>>
>>>> Instead they store a one-way hash of the token. Or they verify the
>>>> token cryptographically. Under no circumstances do they need to store
>>>> a copy.
>>>>
>>>> I'd suggest the following language:
>>>>
>>>> "Access tokens are bearer authentication tokens or capabilities."
>>>>
>>>> Cheers,
>>>> Brian
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
