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:
- Identity Tokens. They tell us who the user is.
- 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.
- 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.
- 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.
- 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:
- OAuth 2.0 Threat Model and Security Considerations
- OpenID Connect Security Considerations
- OASIS Security Considerations for SAML V2.0
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 |
Complexity and design choices leads non-security expert developers to build insecure solutions |
Well suited for modern authorisation scenarios (native apps / devices) |
Does not provide inseparability (due to different implementations of the framework) |
|
|
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 |
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 |