OAuth2: How does OAuth2 Make Crypto Easier for Developers

Note: cross-posted on OracleIDM blog.

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!