SAML vs OAuth
Overview
SAML and OAuth are orthogonal concepts. SAML is designed to be used as both Authentication and Authorization. OAuth can also be used for both, but using OAuth for Authentication is a hack that opens the door to a security vulnerability. OAuth returns a token that can be used to implicitly Authenticate, but this access token does not contain any features to prevent replays. The access token can be used more than once and this is a problem in the realm of Authentication. This token replay problem can be solved by using OpenID Connect, which is built on top of OAuth.
Both SAML and OAuth can be used in the same system, but the scope (i.e. area) of the system they operate on is different.
Let’s explore the possible configurations of these protocols to understand them both better.
Table of Contents
Closer Looks
Important Concepts
- Identity Provider (IDP): This is a service that validates a user’s identity. It can belong to the Service Provider, or it can be a trusted third party like Google, Apple, etc.
- Service Provider (SP): This is any service that provides user functionality that requires authentication to access. It could be your system, or it could be a third party Service Provider.
Possible Configuration Examples
SAML for Authentication and Authorization, OAuth for Authorization Example
This example is a plausible scenario that highlights all the possible components in SAML and OAuth.
SAML is used for Authentication and Authorization (our system is both IDP and SP):
- A user signs in using their password that is stored in our system (IDP).
- Our system’s IDP provides the permissions for the user.
- A feature exists in our system that fetches data from a third party application. We implicitly Authenticate with that third party application via OAuth, which returns an access token. Note that this access token should not be used to verify identity.
- Our access token can be used to fetch the data we seek.
Note: If you’re building an application or a system of any kind, you may be able to increase your security posture by outsourcing your Sign-In process’s Identity Provider to a trusted third party.
SAML for Authentication, OAuth (OpenID Connect) for Authentication + Authorization Example
In this example, an enterprise customer (ourselves in this example) purchases an opaque system and would like to integrate it with our own. We also want our own system to have the role of IDP (whereas the enterprise system we purchased is the SP):
- A user signs into the SAML Authentication using OAuth (OpenID Connect), which requires Authenticating against our IDP.
- Our IDP approves the Authentication request and returns both an ID token and access token. The latter allows fetching a list of permissions that are associated to the SAML user.
SAML for Authentication + Authorization Example
Our system is both the IDP and SP.
- A user signs in using their password that is stored in our system (IDP).
- Our system’s IDP provides the permissions for the user.
OAuth (OpenID Connect) for Authentication Example
One example is a system that requires Sign-In via a trusted third party.
- A user signs into our system using OAuth (OpenID Connect) and both an ID token and access token are returned (we ignore the access token because we only want to verify the identity of the user).
OAuth (OpenID Connect) for Authentication + Authorization Example
One example is a system that requires Sign-In via a trusted third party.
- A user signs into our system using OAuth (OpenID Connect) and both an ID token and access token are returned.
- We use the access token to fetch data that is also available from the third party.
Conclusion
SAML and OAuth have some overlap, but both can be used simultaneously in a system.
To be updated with diagrams and more details, including OpenID Connect’s nonce, OAuth refresh tokens, implicit Authentication nuances, and more…
Author
Sam Malayek works in Vancouver, using this space to fill in a few gaps. Opinions are his own.