A Look at OAuth2 - A Follow-Up to the Reader's Comments

Originally posted on Phil Hunt's blog IndependentID

On my last blog post on Oracle IDM, Marc asks some very good questions that deserve a longer response:

Phil,

Here's where I get confused about OAuth2. I keep hearing you don't need crypto (which is often where developers get so tripped up on other federation protocols) but how do you securely have a self contained token without crypto? You mention signing a token, but isn't that crypto? If you are relying solely on transport security does that mean all connections need to be HTTPS mutual authentication to be viable?

Thanks
Marc

Let me break this up into a couple of paraphrased pieces:

1. If you do not use crypto, how do you securely have a self-contained token without crypto (aka bearer token)?

In OAuth1, the algorithm, usage and signing instructions were narrowly defined (probably limiting the life of the spec). OAuth1, assumed all communication would be insecure and therefore the access token itself needed to be secure. This required each client developer to implement the specifications MAC token in order to access services.

In contrast, OAuth2 the assumptions are reversed. Communication are secure, so tokens do not need to be self-securing (as MAC tokens were in OAuth1). OAuth2 opens the door to using simple bearer tokens (RFC 6750) to access services. OAuth2 assumes that because the issuing process is secured by TLS, the mere possession of a valid token is sufficient to authenticate or rather maintain the session relationship with the client.

With that said, there are still many scenarios where stronger ongoing authentication of the client is important to improve security. For a larger discussion on this, check out the current OAuth2 WG Security draft which discusses these issues.

2. Does this mean all connections must be HTTPS mutual authentication to be viable?

Mutual:
TLS Mutual authentication is useful, but is not required. OAuth2 allows the client application to be authenticated through other means such as client secret, a JWT, or SAML assertion. One of the problems with TLS mutual authentication is when TLS terminates before the server (e.g. in a load balancer), the server may not be able to access the client's authentication with the load balancer.

All:
Let me first qualify that not all communication needs to be secured in all cases. Let's look at the two main endpoints that are being communicated with. The Authorization Server (aka Token Server), does require that at least server-authenticated TLS be enabled for all communication. In the case of a Resource Server, server-authenticated TLS is not required but SHOULD be used when using tokens without crypto (aka bearer tokens).

Thanks for the questions. Please keep them coming!

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Oracle Identity Management is a complete and integrated next-generation identity management platform that provides breakthrough scalability; enables organizations to achieve rapid compliance with regulatory mandates; secures sensitive applications and data regardless of whether they are hosted on-premise or in a cloud; and reduces operational costs. Oracle Identity Management enables secure user access to resources anytime on any device.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
3
4
5
6
7
8
11
12
13
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today