X

Cloud Security Perspectives and Insights

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!

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.