Introduction
I was asked recently in an interview to explain my understanding of OAuth 2.0, OpenID Connect, and SAML. I had heard of the terms before, and knew they had to do with single sign-on and authenticating users. I had implemented auth in Rails using sessions, in Node using JWT, and again with Auth0, but couldn't speak to the differences between these SSO frameworks. In this post, I'll briefly summarize these frameworks, their differences, and what they're commonly used for.
OAuth 2.0: An authentication framework
OAuth is a framework for delegated authorization. It is designed to be generic and flexible. In OAuth, an identity provider (IDP) issues tokens to other services with the user's approval. This lets an application access resources from a server on behalf of the user, without having to share the user's credentials. It allows for sign-in, as well as sharing contacts across applications, or gaining access to a third-party service.
OpenID Connect: A modern flavor of OAuth 2.0
OpenID Connect (and SAML) are frameworks for federated authentication. OpenID is built on top of OAuth. It uses JWT to issue id_tokens, which include information about the subject (who is authenticating), the issuer (who is issuing the token), and the necessary authentication information about the user. Passport, a popular Node module for auth, can be configured as OpenID.
OpenID is specifically designed for user authentication. It's used widely in consumer and mobile applications. It allows for third-party sign in features, like "Sign in with Google".
SAML: An enterprise approach to SSO
SAML (security assertion markup language) is an authentication standard independent from OAuth/OpenID. It uses a flavor of XML, shared between identity providers and service providers, to authenticate and authorize users. The identity provider will write an assertion, which is an XML document that includes information on the subject, the issuer, and the authentication information.
SAML is commonly used in enterprises that need to manage authorization and authentication for a suite of different software tools. In SAML, the service provider is almost always a web app (a hangover from its early days as an SSO solution for Windows Active Directory), which makes it not ideal for mobile.
Conclusion
Like any other technology, each SSO strategy has its tradeoffs and teams evaluate their specific use case before selecting a strategy. I hope this brief introduction was helpful! I have some examples of different authentication strategies on display in my GitHub profile.
Top comments (0)