FAQ on IAM

What is “identity”

When the IAM world speaks about “identity” it actually refers to the way an organisation identifies a person (organisation-specific “identifier”) and the attributes that organisation keeps about the person in relation to access management. The latter means that HR records may be kept by the organisation but they are not seen as attributes in an IAM context. It also means that a CRM may contain notes of sales calls, payment methods and delivery addresses, but again, they are typically not seen as attributes in an IAM context. The HR records and the notes in a CRM, however, may contain personal information and be subject to GDPR rules.

Note that ISO 24760-1 IT Security and Privacy — A framework for identity management, speaks of “identity” as a set of attributes (characteristics or property) related to a person, which is to be distinguished from “identifier” that is an (often specifically created) attribute to uniquely characterise a person in a domain. Identifiers are, for example, a club-membership number together with the club’s name, a health insurance card number together with the insurer’s name, or an email address together with a mobile app. The domain is origin of the identifier, for example the club, the health insurer or the app developer.

What is “authentication”

When the IAM world speaks about “authentication” it actually refers to the way a user proves their presence and the ownership of their identifier. Contrary to popular belief, authentication is not “proof of who you are” but rather gives “proof of which identifier you own.” The semantical nuance is that proving “who you are” can only be done against an authoritative sources, such as a national registry, while proving “you own an identifier” is done by presenting a credential that has been associated with the identifier when it was created. For example an email address can be the identifier, a password can be the credential that was set when the email address was registered.

In principle, the act of authentication is an event. The conditions and the period during which this event remains valid is called a “session” and should be subject of an authentication policy. For example, an authentication may become invalid after it expires, or after a period of inactivity, or after the user switched to another device, browser or app.

What is “federated identity”

The goal of federated identities is to allow users registered by one organisation to be recognised in the domain of another organisation.

Identity federation is a generic term and can be implemented using a variety of technologies and protocols. To be effective, however, those technologies and protocols must adopt common standards so that organisations using different vendors can interpret each other’s identities.

Identity federation does raise some privacy concerns; even though a strong federation agreement must be in place between the participating organisations, it is not always clear that the users have given their consent to pass on attributes of their identity from one to the other organisation. The federation agreement should therefore deal with this matter explicitly.

What is “federated authentication”

Whereas the goal of federated identity is to allow users registered by one organisation to be recognised in the domain of another organisation, the goal of federated authentication is to allow organisations to trust authentication done by another organisation.

Federated authentication is a generic term and can be implemented using a variety of technologies and protocols. To be effective, however, those technologies and protocols must adopt common standards so that organisations using different vendors can interpret each other’s identities. Typical standards in this context are SAML, OAuth 2 and OpenID Connect, whereby organisations use security tokens, such as JWT and SAML assertions, to pass permissions from one organisation to the other. When done right, the process yields a seamless single sign-on experience for the end user. Conversely, the user may be asked to give their consent prior to passing on the attributes, so as to comply with GDPR rules.

What is single sign-on?

Much like the name implies, single sign-on is a function that allows users to access multiple applications after a single login. This implies that all these applications accept the same identifier and the way they are used for authentication. For example, applications connected to the same Active Directory allows a user to use their account in the Active Directory to login once and use it throughout all connected applications. For example, all websites and apps connected to the same CIAM allows a user to use their account in the CIAM to login once and use it throughout all connected websites and apps.

What is the difference between single sign-on and federated identity management?

Single sign-on enables a user to access multiple applications, websites and apps after a single login, but it requires those applications, websites and apps to be connected to the same identity management system, e.g. the same Active Directory or the same CIAM.

Federated identity management offers the same single sign-on experience for applications, websites and apps that are not connected to the same identity management system. It achieves this by set of agreements and standards that help applications, websites and apps of different domains to share user identities and to pass on authentication events.

Is federated identity safe?

So, how trustworthy is this? Firstly, it depends on the agreements between the organisations. Secondly, it depends on the security of the process to pass on identity and authentication. Protocols such as SAML, OAuth 2 and OpenID Connect have been defined to enable a secure configuration.

Does it imply less control? Protocols such as SAML, OAuth 2 and OpenID Connect enable an organisation to put constraints on what it accepts. For example, organisations can specify that tokens must be signed by an accepted and trusted issuer. They can also specify the type and level of authentication they would accept.

Does it introduce new risks? Since an organisation needs to trust authentication and identity management done by another organisation, it should do its due diligence before accepting these and tell the users about the level of trust. On the other hand, no implementation is without vulnerabilities, and federation protocols must be configured carefully and updated when vulnerabilities have been reported.

What are federated identity providers?

An identity provider offers identities and authentication mechanisms within a specific domain, typically constrained to a single organisation. Federated identity providers offer identities across different domains as long as these domains subscribe to the same agreement and implement the necessary protocols.

Federated identity may be provided by participating organisations that recognise each other’s identification and authentication. This is meshed federation.

Federated identity may also be provided by a specialised organisation that does not participate in transactions and that does not necessarily recognise the identities from participating organisations. This is star-shaped federation. Star-shaped federation is often provided by public authorities, such as a national ID or a sector-specific registry of professionals. Star-shaped federation is also provided by some social media; for example Facebook offers its identification and authentication to other organisations (“login with Facebook”) but rarely accept authentication done by someone else. This is because g-Facebook’s main purpose is to collect information about people and not to rely on someone else to collect information about people.

What is SAML?

Security Assertion Markup Language (SAML) is an open-source framework that allows one system to perform both authentication and authorisation on behalf of other systems using tokens. SAML can thus provide single sign-on functionality as well as federated identity.

SAML defines following roles:

An end user consuming services from a service provider
An identity provider (IdP) authenticates a user and provides a SAML Assertion to service providers.
A service provider (SP) verifies the assertion and allows the user to use its services accordingly.

SAML is an XML-based markup language for creating, requesting, and exchanging security assertions between applications.

SAML is not well suited for consumer authentication and authorisation since it is not designed to take end user consent into account. SAML, however, is used in G2C communication whereby the governments assume they do not need explicit consent from its citizens.

What is OAuth?

Open Authorisation (OAuth) is a standard for token-based authorisation and can be used by end users and for device-to-application and application-to-application access. Its model is: an application first requests a token from an Authorization Server that returns an access token. With this access token, the application can access a protected resource.

The OAuth specifications define the following roles:

A Resource Owner that can grant access to a protected resource. The resource owner is a person (like an end user), an application that owns the service, or a security policy.
A Resource Server that hosts the protected resource or service. The resource server can accept and respond to protected resource requests.
A Client Application (also referred to as OAuth client or consumer) that wants to access a protected resource on behalf of the resource owner. The client application is the application requesting access to resources kept by the resource server. The client application also obtains authorisation from the resource owner.
Authorization Server that supplies access tokens to the Client Application after ensuring authentication of the requestor (not necessarily the end user) and obtaining the necessary authorisation.

OAuth most current version is 2.0 with 2.1 in draft. OAuth 2.0 is not backwards compatible with OAuth 1.0 or 1.1, and should be thought of as a completely new protocol.

In principle, OAuth was designed as a delegated authorisation protocol. It is increasingly used to provide authorisation in the form of a token after a series of policy conditions are met. This facilitates the implementation of a security model adopting a XACML architecture.

OAuth 2 does not specify how tokens look like, and they can be opaque (a string of hex characters) or can contain explicit permissions in a JSON format. As such, bare OAuth 2 is not suited for federated authentication. OAuth 2 in combination with OpenID Connect, however, is.

What is OpenID Connect?

OpenID Connect is a authentication and identity layer on top of the OAuth 2 protocol. OpenID Connect enables applications to check the end user’s identity, the user’s authentication and to obtain essential profile data about the end user.

The OpenID Connect specifications define the following roles:

An end-user that is looking to verify its identity.
A relying party (RP) is the entity looking to verify the identity of the end-user.
An OpenID provider (OP) is the entity that registers the OpenID URL and can confirm the end user’s identity.

Since OpenID Connect deals with identification and authentication, its specifications include registration and session management as well as federation and logout models.

OpenID Connect specifies the content of the token as signed JSON web tokens (JWT).

What is OATH?

OATH is an open reference architecture for implementing strong authentication. The OATH standard, at a basic level, describes implementation of a core set of authentication credentials:

One Time Password (OTP)-based authentication (HOTP is counter based and TOTP is time based)
Public key infrastructure (PKI) -based authentication (using X509.v3 certificate)
Subscriber identity module (SIM) -based authentication (using GSM/GPRS SIM)

As the token seeds of OATH tokens can be exported from one OATH platform and imported into another, the standard’s open architecture creates more freedom for enterprises by preventing ‘vendor lock-in’.

Can OAuth 2 be used for authentication?

The OAuth 2 specification defines a delegation protocol that is useful for conveying authorisation decisions across a network of web-enabled applications and APIs.

Since OAuth 2.0 is used in a wide variety of applications that include user authentication, many people incorrectly conclude that OAuth itself would be an authentication protocol. Contrary to popular belief, however, OAuth 2.0 is not an authentication protocol. It does assume authentication of the user and user authentication can happen alongside the OAuth 2.0 authorisation protocol, but OAuth 2.0 itself is not an authentication protocol. In fact, OAuth 2.0 does not even require the user to be present and is not designed to tell the application anything about the user.

The OAuth 2.0 process does, however, usually include several kinds of authentication in its process as it requires the client side to be fully authenticated, which may or may not include user authentication. It is tempting to consider reception of an access token of any type of proof that authentication has been carried out. However, mere possession of an access token doesn’t tell anything about the user on its own.

OAuth 2.0, however, enables an ‘authentication and identity protocol’ to be created on top of its authorisation protocol. OpenID Connect is such a protocol. Most implementations of OpenID Connect issue an identity token alongside an OAuth 2 access token. One major benefit of building authentication on top of authorisation this way is that it enables proper management of user consent.

What is an OAuth scope?

OAuth 2 is a request-response protocol to carry forward authorisation decisions in the form of an access token. Older CIAM systems issued opaque access token as a string of hex characters. Modern OAuth authorisation servers, however, issue access tokens in JWT format that contain explicit permissions.

One of the key elements in an OAuth 2 request is the Resource Server(s) for which authorisation is requested. This defines the scope of the authorisation and is confirmed in the access token returned by the authorisation server. Many OAuth 2 authorisation servers also allow the request to state specially whether READ access is needed or WRITE access. The corresponding access token will then contains the scope in terms of READ or WRITE access to a resource server. So, if a client receives an access token with a READ scope, and it tries to call an API endpoint that requires WRITE access, the call will fail.

What is an OAuth claim?

A claim can say “the user is authenticated using MFA,” “the user is a registered health care professional,” “the user has a team leader role,” “the user is 18 years or older,” or “the user is located in Belgium,” or “the request carries risk level 4.”

As such, claims can be used by APIs to perform fine-grained authorisation using assertion about the user and the context.

What is the difference between Single Sign-On and OAuth?

Single sign-on allows users to access multiple applications after a single login. One way of achieving this is by connecting all applications to the same identity provider doing the identification and authentication on their behalf (for example an Active Directory or a CIAM).

Connecting all applications to the same identity provider, however, is not possible when the applications belong to different organisations. In that case, federated authentication yields the same single sign-on experience for users. With federated authentication, the login you do for one organisation, is also valid for other organisations of the federated authentication.

One way of technically implementing federated authentication is by using the OAuth 2 and OpenID Connect protocols.

OAuth 2 in itself, however, is not designed for single sign-on: it is an authorisation protocol to carry forward authorisation decisions. OpenID Connect is a layer on top of OAuth 2 that performs authentication and yields the single sign-on experience.

What is the difference between OpenID Connect and OAuth?

OAuth 2 defines a protocol for conveying authorisation decisions across a network of web-enabled applications and APIs. With OAuth 2, access tokens are issued that bear authorisation information in the form of scopes and claims. With OAuth 2, single sign-on can be experienced within the domain of a single identity provider; the access token allows applications to request and obtain more information about the user via the UserInfo endpoint of the identity provider.

OpenID Connect is an authentication and identity protocol on top of OAuth 2.0. With OpenID Connect, identity tokens are issued that bear end user information in the form of claims. With OpenID Connect, single sign-on can be experienced across domains of different identity providers.

An identity token is often issued in addition to (and not in lieu of) an access token. Strictly speaking, the identity token is in fact an access token that gives the authorisation to access the UserInfo endpoint of the issuing identity provider.

Which is better; Single Sign-On or OAuth?

Single sign-on is an “end user experience” whereby users to access multiple applications after a single login. OAuth 2 is a technical protocol that can create this experience. Single sign-on, however, can also be achieved in different ways, OAuth 2 being one of those. Conversely, OAuth 2 is an authorisation protocol that also supports device-to-application and application-to-application communication and supports API security.

Which is better; OpenID Connect or OAuth?

Whereas OAuth 2 is an authorisation protocol, OpenID Connect is an authentication and identity protocol on top of OAuth 2.0. So, if you’re doing authentication, use OpenID Connect, while if you’re securing APIs, use OAuth 2.

Whereas the format of OAuth 2 access tokens is not standardised, OpenID Connect specifies the content of the token as signed JSON web tokens (JWT). So, if need identity attributes, use OpenID Connect, while if you’re implementing fine-grained access control, use OAuth 2.

What is good practice for implementing OAuth 2?

Token-based policy enforcement with OAuth 2 can achieve top-level security. Yet, there are some security concerns when implemented without due care. In case the tokens are issued adopting OAuth 2, please observe the security best practices here, which can be summarised as:

Rule #1. do not use OAuth 2.0 itself for authentication: use OpenID Connect instead.

Rule #2. choose the correct mechanism:

do not use the OAuth 2.0 implicit grant type (which has been abandoned in OAuth 2.1)
return the access token in the body of HTTP response to POST request using CORS
the client credentials mechanism should only be used when the client application and policy server are owned by the same authority

Rule #3. use the access token correctly:

verify access token signature and expiration
implement short-lived and one-time use access tokens
buffer it securely and defend your frontend applications from XSS attacks that could steal tokens from localStorage

Rule #4. deliver the access token securely:

secure the redirection by registering the redirection url
use state parameter to prevent Cross-Site Request Forgery attacks
harden it with Proof Key for Code Exchange.