OAuth Security (Beijing IETF, Nov. 2010)

Hannes Tschofenig
Goal for this Meeting
• Use the next 2 hours to determine what the
security consideration section of the OAuth
draft(s) should contain.
• Currently, the security consideration section of
draft-ietf-oauth-v2-10 is empty.
• Note: No time to actually write text today.
• The next couple of slides are an introduction
to get the discussion started.
– Approaches the topic based on NIST SP 800-63
Abstract View on OAuth
(* *)
`+' User
:--------------|--- ~~~~~~~~~~:
: Service
/ \
: Management
: Interaction
: of Resources
: Consent
+---:-+ Carol
|Carol| as
: Obtain
| Asserting
: Access .'
+-----+ Party
: Token.'
: v'
+--:--+ Bob
|Alice|<------------------------->|Bob | as
2. Authenticated
| Relying
Request +
+-----+ Party
Access Token
Status: draft-ietf-oauth-v2-10
(with relevance for security)
• Token:
– Token Format not specified
– Token Content not specified
– Protection of token unspecified.
• HTTP Basic Authentication used for interaction
with the authorization server, see (1)
• No HTTP-level authentication for
authenticated request (2) specified.
• TLS not mandatory to use for (2) either.
Example Instantiation:
Web Server Flow
Security Threats
(based on NIST SP 800-63)
1. Token manufacture/modification
An attacker may generate a bogus token or modify the
token content of an existing token, causing Bob to grant
inappropriate access to the Alice.
2. Token disclosure
Tokens may contain authentication and attribute
statements that include sensitive information.
3. Token redirect
An attacker uses the token generated for consumption by
Bob to obtain access to a second Relying Party.
4. Token reuse
An attacker attempts to use a token that has already been
used once with Bob.
Threat Mitigation
(based on NIST SP 800-63)
• Token modification:
– Protect the content, or use a reference instead!
• Token redirect:
– Carol must include the identity of the token consumer,
• Token disclosure:
– Variant (a): Do not include sensitive information
– Variant (b): Offer confidentiality protection
Dealing with Token Reuse
• Approach #1: Confidentiality Protection & extra
*: Alice has to make sure it does not distribute the token to
entities other than Bob
Dealing with Token Reuse (2)
• Approach #2: Sender Constraint
• Token contains information about the
legitimate presenter (Alice).
• Bob has to authenticate Alice first to verify
whether the token constraint matches the
authenticated identity
Dealing with Token Reuse (3)
• Approach #3: Key Confirmation
Token, {Request}SK,
Mandatory to implement?
• Challenge: draft-ietf-oauth-v2-10 does not provide a
completely interoperable solution since many aspects
are left for bi-lateral agreements between Alice & Bob.
– So, what should be mandatory to implement?
• Key Confirmation Approach
– Experience in deployment available from Kerberos.
– Other approaches suffer from operational considerations
• Ensuring that Alice only provides token to Bob
• Establishing authentication infrastructure
• Putting proper constraints in the token.
• MUST implement and use TLS between Alice and Carol
(exchange #1)
Additional Security Considerations
• This slide set focuses on the token exchange.
Security for the exchange between Alice and
Carol isn’t described in great detail.
• Main document can only provide requirements
for token protection
– Will have to be postponed to documents covering the
details. Example:
• Additional security considerations based on
properties of individual flows.
– Relate to properties provided by operating systems,
libraries/application frameworks, and browsers.

similar documents