1 / 15

OAuth 2.0 Security

OAuth 2.0 Security. OAuth WG Conference Call, 11 th Jan. 2013. Crypto-Agility. [C->RS: Discovery] C->AS: [algorithm list]**, id(RS), id(client), scope C<-AS: algorithm*, key, access token C->RS: algorithm, HMAC/signature, access token*** C<-RS: OK.

drew
Download Presentation

OAuth 2.0 Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OAuth 2.0 Security OAuth WG Conference Call, 11th Jan. 2013

  2. Crypto-Agility • [C->RS: Discovery] • C->AS: [algorithm list]**, id(RS), id(client), scope • C<-AS: algorithm*, key, access token • C->RS: algorithm, HMAC/signature, access token*** • C<-RS: OK. *Assumption: AS knows what algorithms are supported by the RS. AS selects appropriate algorithm from the client-provided list. **: Algorithm list & token types could be conveyed implicitly via the client id. Client registers the data during the registration phase. ***: Alternatively an error message is returned if no common algorithms are supported.

  3. Confirm Cryptographic Algorithm Selection • Client supported list of algorithms cannot be modified since it is sent over a TLS protected channel.

  4. Uniquely Named Keys • Key used for client authentication is named via Client_id • Key used to protect the access token is named kid (if the JOSE work is used). • Session key used for client<->RS interaction could be named via id (as in MAC draft). • Should a session key also be used for a subsequent exchange of data between the client and the resource server?

  5. Authorization Restriction • Information needed by client: • Lifetime of the session key + Key identifier • Authorization Scope • Resource Server the access token can be used • (Any information related to delegation, or post-dated access tokens.)

  6. Bind Key to its Context • Session key to be used for client-to-RS interaction • Lifetime of session key. • Symmetric key: lifetime of access token • Asymmetric key: longer lifetime • Who has access to the session key? Depends on the type: • Symmetric: AS, client instance, RS • Asymmetric: privacy key known to the client instance only

  7. Prevent the Domino Effect • What happens when a client gets compromised? • Rouge client must not get access to resources of resource owners who have been interacted with that client. • What happens when a resource server gets compromised? • Rouge RS must not be able to impersonate clients to other RSs

  8. Strong, fresh session keys • Randomly generated with sufficient entropy • Client id: • client id is not visible to RS • Joint key control (client & AS) for symmetric keys? • Scope • Should a different session key be used when the scope changes? • Lifetime of C<->RS session key : • For symmetric keys: lifetime of the session key is bound to the access token lifetime.

  9. Replay Detection Mechanism • Based on timestamp with optional seq-number

  10. Authenticate All Parties • AS authenticated by the client • Client authentication to the AS (mandatory?) • Client authentication to the RS via keyed message digest/signature • RS authentication to the client?

  11. Authorization • Resource Owner is authorized by the AS. • Client is authorized by the AS via client authentication (mandatory?) • RS authorizes client based on access token in combination with proof of possession of key. • AS authorizes RS via the encrypted session key.

  12. Keying Material Confidentiality and Integrity • Client obtains session key via TLS protected channel. • If refresh token leaks then it can be used to obtain access token + new session key. The refresh token behaves like a bearer token. A problem? • Without channel binding the TLS tunnel may terminate before the AS • RS obtains session key via encrypted access token (in case of symmetric keys) (optionally: RS obtains session key from AS)

  13. Client Identity Confidentiality • A Client has identity confidentiality when any party other than the Resource Server and the Authorization Server cannot sufficiently identify the Client within the anonymity set. • Client to AS exchange is confidentiality protected. • Client id is not exposed to RS.

  14. Resource Owner Identity Confidentiality • Only the Authorization Server gets to know the identity of the resource owner • Unless a JWT carries a "sub" (Subject) Claim

  15. Collusion • The Authorization Server can be prevented from knowing which Resource Servers a Resource Owner interacts with. • Consequence: • The AS is unable to populate the audience field in a JWT. • The AS cannot encrypt a session key for usage with a specific RS. • Best supported with asymmetric cryptography • Is this a desirable feature for an initial version?

More Related