I tend to agree with Eran, although it should be qualified that a token
is BASED on a shared secret, rather than is a shared secret itself. (By
the way, I think the word "symmetric" is redundant here.).
I also think that the text in the Security Considerations must contain
the last paragraph of Eran's message. Probably the recommendation not to
store the token on the server, along with the suggestion of storing the
hash should also be in place.
Igor
Eran Hammer-Lahav 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).
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.
EHL
On 7/12/10 10:39 PM, "Brian Eaton" <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
