I understand the removal of the client credentials for accessing resources. That's one less set of credentials accessible by all servers which we already have consensus. And by not having signatures, there are no secrets to verify.
But isn't the bearer token itself a sort of plain text secret? I think what this brings up is the need for an HMAC / symmetric secret option because it is not clear what benefits it really offers over bearer token with SSL/TLS. EHL > -----Original Message----- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Thursday, February 18, 2010 9:51 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] operational security > > On Thu, Feb 18, 2010 at 8:02 PM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > > Can you apply this (without too much detail) to both WRAP and OAuth > > 1.0a? I think it would be useful to see how each comply with these goals > (which look pretty important to me). > > In OAuth 1.0a, every system that needs to create or verify signatures needs > access to long-lived secrets. > > This gives implementers a choice: > - let all their machines have those secrets, which increases attack surface > - add more RPCs (and thus latency and availability headaches) to every > request > > OAuth 1.0a also encourages servers to keep secrets in plaintext, which > creates exposure from other directions. There may be some tricks you can > do to avoid this, but they are non-trivial. (I'm not even sure they would > work, haven't thought them through entirely.) > > Token revocation in OAuth 1.0a is also tricky, as it forces another database > lookup on every request. > > WRAP doesn't do those things. > > (Not saying this is the end-all/be-all of security for WRAP or OAuth. > Just additional security considerations.) > > Cheers, > Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
