Introducing our new IAM Concept of the Week blog series – Each week we’ll define and explain the significance of a concept in the world of Identity and Access Management.
This week let’s talk about 3 protocols – SAML, OAuth and OpenID Connect – that are often mentioned when discussing authentication (AuthN) and authorization (AuthZ). Remember authentication is verifying that someone is who they claim to be while authorization is deciding which resources a user should be able to access, and what they should be allowed to do with those resources.
The table below compares and contrasts the protocols.
SAML (Security Assertion Markup Language) – Is the oldest of the 3 protocols. It’s XML-based and is used for exchanging Authn and Authz data between parties, in particular, between identity providers and service providers. Its most common use case is enabling SSO within the enterprise.
An example of SAML in action would be a user at work requesting access to a service provider like Google G Suite. Before G Suite can grant access it must first authenticate (and then authorize) the user. It does this by requesting and receiving an identity assertion or token from an identity provider, in this case the user’s employer. The token also includes authorization information about which resources the user can access within G Suite, and what they can do with those resources. On the basis of this assertion G Suite makes an access control decision and grants access to the user.
Limitations – The standard was not originally designed for mobile or native apps.
OAuth2 – The “Auth” here stands for authorization. Developed in 2006 by companies like Twitter and Google, who saw the need to enable third party applications limited access to their users’ information. OAuth2 offers what’s known as delegated access, meaning that an application can take actions or access resources on behalf of a user without having to share credentials with the application. This is made possible by the identity provider issuing a token to the third-party application with the approval of the user.
An example of OAuth2 would be a user who signs up with a third-party app that wants to import the user’s Facebook friends list. To accomplish this the user clicks on the “Import contacts from Facebook” button from within the app. The user is then taken to Facebook where they need to authenticate. Once they successfully login they will be prompted to share their Facebook friends list. Clicking yes will send the user back to the app along with a token that grants the app permission or authorization to import the Facebook friends list. OAuth2 offers a secure and simple way for consumers to allow access to their resources on the web without having to share their credentials.
Limitations – The standard does not include authentication.
OpenID Connect (OIDC) – Is an open standard for authentication that is designed to work in conjunction with the authorization capabilities of OAuth2. OIDC is essentially an identity layer built on top of OAuth2 that allows the verification of the identity of an end-user, as well as, to obtain basic profile information about the end-user. It achieves this by adding an identity token to the OAuth2 authorization flow.
In many ways OIDC represents the future of authentication and authorization particularly because it was developed with mobile and native apps in mind. Having said that SAML will be with us for a longer time because of its dominant position within the enterprise.
Further reading
- SAML Wikipedia
- OAuth2 (OAuth.Net)
- OpenID Connect FAQ (OpenID.Net)
- Authentication and Authorization: OpenID vs OAuth2 vs SAML
Other blogs in the IAM Concept of the Week series:
- FIDO (Fast Identity Online)