A computer lets you make more mistakes faster than any invention in human history – with the possible exceptions of handguns and tequila. – Mitch Ratliff

In order to fully understand your choices and risks when selecting your security components in the claims and tokens world you first need to understand a little history that led to creation of an OpenID Connect. It’s the latest and often recommend framework that deals with both authentication and authorisation. I will also talk a bit about real attack scenarios that you can be opening your system to if you do not fully understand the idea behind some core concepts in this brave new world of claims and tokens.

The age of SAML tokens

At the dawn of the federated security era we had SAML tokens called assertions. SAML was mostly enterprise oriented and didn’t work well in more advanced scenarios that were emerging (think iPhone and mobile apps authentication/authorisation).

Due to inflexibility of SAML as a protocol, the open source community started working on something more modern they could call their own. At around 2006 Open ID was created to help users authenticate to multiple websites using single credentials. Year later work on OAuth began, which was meant to deal with another modern age problem. Federated API authorisation (think: granting API access tokens to various scheduled jobs or even other applications rather than actual human beings).

What OAuth is really for?

OAuth was never meant to be used for authentication scenarios and so it lacks a standard way of doing it. “Standard” being a keyword here. Of course we are cleaver people and we won’t be told what we can and cannot do with our OAuth enabled project. Or at least that’s what many people thought while adding authentication capabilities to their OAuth implementations. Nothing really stops us in doing so. After all OAuth is nothing else but a token provider. If I want to pass my credentials to an OAuth server and expect it to give me one token that authenticates me (hold information about who I am) and authorise me (list what I can or cannot do) then by God who are you stop me?!

As it turned out nothing could stop people who didn’t fully understand the risks of using a hammer for screwing in screws. Unfortunately there was also nothing that could stop malicious parties from using security holes that got created this way. You can read more about why it is a bad idea to use OAuth for authentication here

 

And then there was OpenID Connect

To help out those trying to abuse OAuth some clever people created OpenID Connect. It builds on top of OAuth framework and essentially is not doing much more than providing the additional standardised endpoint dedicated for authentication. So to sum up the above. SAML is still here. I’d say don’t use it for new projects unless you have to support/integrate with WS* standards. OAuth2 is great for API access delegation. If you need authentication capabilities it is always better to pick OpenID Connect as it does everything OAuth does. Plus authentication.

The challenge of securely transporting messages in OpenID Connect was trusted to a tokenized messages called JWT (JSON web tokens). There’s a whole standard of structuring, encrypting and signing them. These JWTs are what is called the identity tokens. On the other hand – provided for us thanks to the underlying OAuth2 framework are the Access Tokens. These should be used for federated access delegation and authorisation. OAuth2 specification requires use of what is called a “Bearer” tokens. Bearer tokens (according to specification) could be in any format, JWT, SAML Assertion or a Kerberos ticket. So again (because this is very important) – we have 2 types of tokens in OpenID Connect:

  1. Identity Tokens. They tell us who the user is.
  2. Access Tokens. They tell us what the request “bearing” these tokens is allowed to access. It doesn’t have to be linked to a person. Could be a scheduled CRON job or any other piece of code that was granted this access token).

Worth mentioning is that JWT is a type of bearer token. So often when people talk about bearers or JWTs in context of OAuth /OIDC they usually mean the same thing.

Know your risks

Now since you understand what is OAuth2 and OpenID Connect we can start talking about the risks. There are few root causes of most security problems with both OAth2 and OpenID Connect.

  1. Picking wrong flow. Flows are ways of retrieving tokens from security authority. I strongly recommend you learn strengths and weaknesses of each flow and pick one that is most secure instead of one that is easiest to implement.
  2. Not implementing all the security features correctly. You can either create your own or (much better choice) use certified OpenID Connect implementation. In both cases it is important to read specification and use all the build in security features. You shouldn’t consider them optional! For example – you may omit populating and checking the STATE parameter of OAuth2 access tokens but this will open you to cross site request forgery attacks. There are more little things that may seem optional but each one protects from a group of attacks. Therefore you need to be aware of them and use them correctly.
  3. Extending existing implementations and mixing concerns. Authentication and Authorisation components should only do 1 thing. And that is checking who is who and provide claims. They don’t need to know any of your domain objects. If you feel like you need to call a resource service from your authentication service, you are doing something horribly wrong.

Another important subject to familiarize yourself with are threat assessments for the protocol or framework you choose. They describe known vulnerabilities and ways to protect your system from many different types of attacks:

Summary 

Additionally the Helsinki meeting summary offers some more comparative analysis and I highly recommend to familiarize yourself with its content. Especially if you are interested in what can go wrong in seemingly simple task of setting up security components. 

Finally, beware of blogs! Software security is a highly volatile and complex subject. You will find people who “claim” they know what they are talking about. And you will find those who actually do but the knowledge they have passed isn’t up to date due to the pace new vulnerabilities are discovered. Every now and then it’s worth checking updates at the source

Below I’ve summed up all the “current” information regarding OAuth2, OIDC and SAML with links to specifications whenever appropriate. Hopefully you’ll find it helpful. If you can spot any inaccuracies please leave your comment bellow. That way we can all benefit with the most up to date data source! And also since I’ve started with a Quote it only makes sense to finish with one, so here it is:

Passwords are like underwear: don’t let people see it, change it very often, and you shouldn’t share it with strangers. – Chris Pirillo

“Current” information regarding OAuth2, OIDC and SAML

  Token/s Type and Encryption Suggested Use Scenario Protocol/framework Security features Protocol/framework Security Vulnerabilities Unique Benefits Unique Flaws

OAuth2 (Authorisation Framework)

 

Access Token (format is not specified – can be anything you like really including SAML or Kerberos tickets) Enterprise Authorisation

Signed Messages

Encrypted Messages

Requires SSL

Complexity and design choices leads non-security expert developers to build insecure solutions

Well suited for modern authorisation scenarios (native apps / devices)

Provides Dynamic Client Registration

Does not provide inseparability (due to different implementations of the framework)

No discovery endpoint (but we may be getting one soon)

Open ID Connect (Authentication and Authorisation protocol) 

 

JWT (Id Token)

Access Token (see OAuth2 above)

Inter-operable Authentication and Authorisation (list of certified implementations)

ID tokens are Signed

ID tokens may be OPTIONALLY encrypted

Since OIDC builds on top of OAuth2 it takes the same well described threat model. Key issues are around inputs and parameters validation and binding them to specific clients (making sure no one hijacks the communication) 

Stateless Sessions

Passing identity to 3rd party services / applications

Ability to boost security by the use of token exchange endpoint – we pass our ID-Token and get back Access token to some api

Well suited for modern authentication scenarios (native apps / devices)

Discovery Endpoint boosts inter-operability

Client Registration as part of specification

Session management as part of specification (helpful for single sign out)

Data overhead in payload of each request carrying the token
SAML

SAML Assertions (XML based tokens)

Enterprise Authorisation and Authentication. Many cloud service providers allow SAML integration to provide single-sign-on (Google, Zendesk, Saleforce, Hackerone)

XML Digital Signature

XML Encryption (optional)

   

Not well suited for modern auth scenarios (native apps / devices)

Does not support API management scenarios (discoverability/client registration)

Heavy weight tokens

Software developer at Aspire Systems Poland. Problem solver. The more complicated the problem is, the more motivated he gets. Whether it’s designing, improving processes, architecture or coding, he will be the first one to jump right in.