There are just as many ways to defend data as there are to attack it. When considering multi-factor authentication, single sign-on, firewalls, and various other controls, the options can be overwhelming. For security professionals (amongst others), the decisions on how to keep data and identities secure starts much earlier – choosing the correct standard to deploy to keep federated identity secure.
Authorisation and Authentication Basics
Authorisation and authentication forms part of the IAAA principle in Information Security. In simple terms, and as defined in ‘What is IAAA?‘, authentication is the ability to prove your identity to a particular system (such as providing a correct password) and authorisation covers what you are allowed to access once authenticated.
OpenID is an open standard for authentication and promoted by the non-profit OpenID Foundation. There are well over a billion OpenID-enabled accounts on the Internet and many well-known organisations, such as Google and PayPal, use OpenID to authenticate users.
A user can obtain an OpenID account through an identity provider such as Google. Once obtained, the user will then use that account to sign into websites that accept OpenID as a form of authentication (as an example, using your Google account to sign in to YouTube). The OpenID standard is the framework that defines what must take place between the identity provider (Google) and the relying party (YouTube).
For the above example using Google and YouTube, the authentication process is fairly simple:
- John wants to log into his YouTube account and navigates to the login page
- When he clicks login, he is offered the opportunity to login using his Google account and decides to do so
- YouTube will then initiate association with Google and requests and receives an association handle
- YouTube then forwards John to the Google login page and enters his Google account credentials
- Google then validates the credentials, and if correct, redirects John back to YouTube, along with a token stating that Google have validated the credentials
- YouTube will then accept the token from Google and open a session for John
In contrast to OpenID, OAuth2 is a standard for authorisation rather than authentication. OAuth2 also forms the foundation for OpenID Connect, which provides OpenID (authentication) on top of OAuth2 (authorisation).
OAuth2 provides delegated access resulting in an application being able to take actions on behalf of a user, but without needing access to that users’ credentials. OAuth2 does this by using tokens issued by an identity provider and consumed by a third-party application.
Some material points to OAuth2 as an authentication standard, and although not strictly true, it can be a form of pseudo-authentication. As an example use case, John has asked his friend June to house sit whilst he is on holiday.
John gives June his house keys to allow her to enter the property. The key is John providing June with authorisation to enter his house (as authorisation determines what resources a user can access). This can be seen as a form of pseudo-authentication by assuming that the person with the key (June) is the homeowner (which is actually John); this is not the case in this scenario.
For a more technical example scenario, OAuth2 could look like this:
- John signs up for a newsletter online and is invited to see which of his contacts are also subscribed
- There is an option to import contacts from LinkedIn and John decides this would be a good idea
- John is redirected to LinkedIn, signs in successfully, and agrees to share his LinkedIn contacts with the newsletter provider
- John is then sent back to the newsletter along with a token granted access for the newsletter to access Johns LinkedIn contacts.
In this scenario John has not shared his credentials with the newsletter and has eliminated the risk of the newsletter site being able to login to his LinkedIn account.
SAML, or Security Assertion Markup Language, is the oldest of the three options and was originally developed in 2001. SAML is an open standard that provides authentication and authorisation. Much like the other two options SAML defines a principal (user trying to access a resource), a service provider (the resource which needs to be accessed), and an identity provider (which holds credentials and identities).
The SAML 2.0 specification defines assertions, protocols (assertion requests and responses), bindings (how the requests and responses happen between the identity and service providers, using HTTPS, POST etc), and profiles (combinations of assertions, protocols, bindings for use cases such as SSO).
A simple use case for SAML might look like this:
- John is at work and accesses his organisations intranet portal and logs in with his credentials
- Once logged in, he clicks on a link (which contains a SAML assertion) for Dynamics which is used as the company CRM system
- John is then forwarded to Dynamics which receives the SAML assertion
- Dynamics trusts the organisation and therefore trusts the assertion
- Using information in the token, John can now access Dynamics and view data appropriate for him based on attributes in the assertion
The table below summarises the three options and compares their various attributes
|Token (or assertion) format||JSON||JSON or SAML2||XML|
|Current version||OpenID Connect||OAuth2||SAML 2.0|
|Transport||HTTP GET and HTTP POST||HTTP||HTTP Redirect (GET) binding, SAML SOAP binding, HTTP POST binding, and more|
|Security risks||Phishing identity providers have a log of OpenID logins, making a compromised account a bigger concern||Phishing OAuth2 does not support signature, encryption, channel binding, or client verification. Relies completely on TLS for confidentiality||XML signature wrapping to impersonate any user|
|Best suited for||SSO for consumer applications||API authorisation||SSO for enterprise applications|