IAM Fundamentals
This section provides some unusual answers to questions related to IAM.
The answers are unusual because take a fundamental approach and challenge traditional definitions, because the latter are often very confusing and require a FAQ.
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. While HR records of an employee may be kept by an organisation and contain identity information, these records are typically not seen as an identity in an IAM context. And while a CRM may contain contact details of a person, they are also not seen as an identity in an IAM context. Because of the confusion around the term “identity”, TrustBuilder adopts the term “User Profile” to record all characteristics related to a user that are needed to perform access management.
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 source, 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 “authorisation”
When the IAM world speaks about “authorisation” it actually refers to the way a user is granted access to a resource, an application, an API, and a record in a CRM. While “authentication” means that the system knows who you are (or better which identifier belongs to you), “authorisation” means that you are allowed to get in and do the thing you requested. So while “authentication” is something that happens at the front-door, “authorisation” is a decision whether you can enter a room and open a locker.
In principle, the act of authorisation is an event, a decision in time. The conditions and the period during which this decision remains valid is called a “grace period,” often encoded as token expiration.
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.
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. Federated identity is an agreement between organisations about the definition and use of the identifier and a selection of those attributes.
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, OAuth2 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?
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.
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, OAuth2 and OpenID Connect have been defined to enable a secure configuration.
Does it imply less control? Protocols such as SAML, OAuth2 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 official version is 2.0 with 2.1 in draft. OAuth2.0 is not backwards compatible with OAuth 1.0 or 1.1, and should be thought of as a completely new protocol.
In principle, OAuth2 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.
OAuth2 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 OAuth2 is not suited for federated authentication. OAuth2 in combination with OpenID Connect, however, is.
What is OpenID Connect?
OpenID Connect is a authentication and identity layer on top of the OAuth2 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 OAuth2 be used for authentication?
The OAuth2 specification defines a delegation protocol that is useful for conveying authorisation decisions across a network of web-enabled applications and APIs.
Since OAuth2.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, OAuth2.0 is not an authentication protocol. It does assume authentication of the user and user authentication can happen alongside the OAuth2.0 authorisation protocol, but OAuth2.0 itself is not an authentication protocol. In fact, OAuth2.0 does not even require the user to be present and is not designed to tell the application anything about the user.
The OAuth2.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.
OAuth2.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 OAuth2 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?
OAuth2 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 OAuth2 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 OAuth2 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?
OAuth2 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 claims. Claims are assertions made by the authorisation server about the end user or the context.
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 OAuth2 and OpenID Connect protocols.
OAuth2 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 OAuth2 that performs authentication and yields the single sign-on experience.
What is the difference between OpenID Connect and OAuth?
OAuth2 defines a protocol for conveying authorisation decisions across a network of web-enabled applications and APIs. With OAuth2, access tokens are issued that bear authorisation information in the form of scopes and claims. With OAuth2, 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 OAuth2.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 can access multiple applications after a single login. OAuth2 is a technical protocol that can create this experience. Single sign-on, however, can also be achieved in different ways, OAuth2 being one of those. Conversely, OAuth2 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 OAuth2 is an authorisation protocol, OpenID Connect is an authentication and identity protocol on top of OAuth2.0. So, if you’re doing authentication, use OpenID Connect, while if you’re securing APIs, use OAuth2.
Whereas the format of OAuth2 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 OAuth2.