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:
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
OAuth2 (Authorisation Framework)
Access Token (format is not specified – can be anything you like really including SAML or Kerberos tickets)
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)
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 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)
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.
We process cookies and make them available to Google Analytics (a service provided by Google, Inc.) to improve the performance of the website, to learn your preferences about using it and to tailor it to your needs. The data will be anonymised before being transmitted. If you do not agree to this, you may disable cookies in your browser. If you do not change your browser settings, you accept the fact that it saves cookies.