Difference between an Identity Provider and a Directory Service?

Both an Identity Provider and a Directory Service can act as a central platform with identity data to support user authentication. An Identity Provider (IdP) is more capable and can also be used in cloud environments. A Directory Service is primarily designed for internal IT environments.

What is the difference between an Identity Provider and a Service Provider?

An Identity Provider (IdP) authenticates users and provides identity data to applications and services. Such an application or service is in this context referred to as a Service Provider (SP). The IdP therefore performs user authentication for the SP.

What is an Identity Provider (IdP)?

Q: What is an Identity Provider?

An Identity Provider (IdP) is a system that authenticates users and confirms their identity to applications or services. An IdP manages credentials for this purpose and commonly supports Single Sign-On and Multi-Factor Authentication.

An IdP (Identity Provider) is a central platform that can verify the digital identity of users. Applications that are connected to such an IdP through a trust relationship can effectively delegate user authentication to that Identity Provider. The user signs in to the IdP and, upon successful authentication, gains immediate access to the connected applications. The IdP can also supply additional information to support user authorisation.

Why is an Identity Provider important?

The major advantage is that the user does not need to sign in to multiple applications with different credentials. A single set of sign-in credentials is registered in the IdP, typically a username and password, and this provides access to multiple connected applications. In this way, the Identity Provider is a key building block for Single Sign-On (SSO) because authentication can usually be configured so that the user signs in only once at the start of a session; access to the other applications is then granted automatically. This is not only user friendly but also more secure. If users need to sign in only once, they are more likely to use a strong password together with Multi-Factor Authentication.

Alongside SSO, an Identity Provider is also important for federation, where people can use a single set of sign-in credentials to access multiple partner domains. For example, employees of partner organisations, such as several schools within a single education group, can use their own credentials to access each other’s applications and data through the Identity Provider.

Identity Provider and Service Provider

Before explaining how an Identity Provider works, it is helpful to clarify the term Service Provider, since the two are often used together:

The Identity Provider is the platform responsible for verifying a user’s identity and providing authentication data to other systems. It manages user accounts and their credentials such as passwords, as well as, for example, multi-factor authentication (MFA) or biometric data.
A Service Provider is an application or service that uses an Identity Provider to verify users. The SP therefore trusts the IdP for authentication and can grant access to users on that basis. The term Service Provider can therefore be confusing, since in the authentication context it actually consumes a service from the Identity Provider.

How does an Identity Provider work?

How do you use an Identity Provider to sign in easily to applications or services, the Service Providers? To illustrate Single Sign-On at the same time, we provide an example in which two applications are accessed in succession.

Authentication at the Identity Provider for Application 1

A user attempts to access Application 1, that is SP 1.
Application 1 detects that the user is not signed in and therefore sends an authentication request to the Identity Provider (IdP).
The user is redirected to the IdP sign-in page. There, the user enters credentials such as a username and password.
The IdP verifies the user’s identity and, if successful, generates an authentication token, an encrypted digital access credential.
The user is routed back to Application 1 together with this token.
Application 1 validates the token and the user is granted access.

Access has therefore been granted indirectly. A trust relationship exists between the Identity Provider and the Service Provider, so the application grants access based on the authentication token.

Access to Application 2 with SSO

The user then attempts to access Application 2 (SP 2).
Application 2 also detects that the user is not signed in and sends an authentication request to the IdP.
The IdP sees that the user already has an active session from Application 1. The IdP therefore does not ask for credentials again.
The IdP then generates an authentication token for Application 2.
Application 2 validates the token and grants the user access.

The user is now signed in to Application 2 without signing in again. SSO is not a mandatory capability of an Identity Provider, signing in again with the same credentials would also be possible, but an Identity Provider is particularly well suited to enable this capability.

Because Identity Providers must interoperate seamlessly with numerous applications, communication uses standard protocols. For example, SAML (Security Assertion Markup Language) or OpenID Connect is used to exchange authentication tokens. To send authorisation data from the IdP to applications, protocols such as OAuth 2.0 and JWT (JSON Web Token) are used.

Identity Provider examples

Two well-known examples of Identity Providers are Entra ID and Google Identity Platform:

Microsoft Entra ID (formerly Azure Active Directory) is a cloud Identity Provider that delivers Single Sign-On (SSO), Multi-Factor Authentication (MFA) and federation (with Active Directory Federation Services, ADFS). Entra ID integrates seamlessly with Microsoft 365, Azure, and enterprise applications. This Microsoft Azure identity provider supports, among others, the OAuth 2.0, OpenID Connect, and SAML standards.
Google Identity Platform provides authentication and authorisation services and supports SSO and MFA. It gives users with Google accounts secure access to Google Workspace, mobile apps and web applications. This IdP supports OAuth 2.0, OpenID Connect and Firebase Authentication.

Modern IAM environments also commonly provide a built-in Identity Provider. HelloID likewise offers customers their own Identity Provider, including MFA and SSO capabilities.

Identity Provider within your IAM solution

An Identity Provider generally plays a specific role within a broader Identity & Access Management (IAM) environment. The IdP is important for verifying users and supplying information that supports authentication and authorisation, after which an IAM environment complements this with additional features. The IAM platform also manages identity and access data across the entire identity lifecycle. This starts with onboarding, continues through employees moving to other roles, and finally offboarding from the organisation. Below, we briefly describe how an IAM platform such as HelloID uses an Identity Provider and adds value.

Access Management

Many customers now use Microsoft 365 as the basis for their office productivity. This also means using AD as the directory service or Entra ID as a full Identity Provider. In that case, you do not use an IAM platform such as HelloID directly for this access functionality but use the platform for further management and governance functions. We explain this in more detail in the sections below.

At the same time, there are certainly scenarios where an organisation wants to apply its own Identity Provider within the IAM platform. For this, the HelloID Access Management module provides its own Identity Provider that delivers SSO and Multi-Factor Authentication for the connected applications. In that scenario, each user has a personalised portal with the icons of their applications that can be opened with one click. This HelloID SSO portal can also be integrated easily as a widget into, for example, the existing intranet of a customer organisation. With the Access Management capabilities we also provide federation to facilitate collaboration between customer organisations and to support migration scenarios.

Provisioning

The data in an Identity Provider such as Entra ID can of course be managed directly on the platform by one of the IT administrators. However, this quickly becomes unmanageable when an organisation has countless applications connected to the IdP with hundreds or even thousands of users. It is not only about granting accounts and permissions once. We must also keep that information continuously up to date.

We simplify that administration with the HelloID Provisioning module, in which, using Attribute Based Access Control (ABAC), we ensure that every employee is automatically provided with the correct accounts and permissions at all times. To do this, the platform queries a source system such as the HR application. This always contains the current role, department and location of employees and, based on this, HelloID automatically determines the required accounts and access rights. These are then propagated automatically for each employee to the Identity Provider and also to other target systems; not every platform is connected to the IdP and access rights are also recorded in other target systems.

Your Identity Provider therefore plays a technically important role in Single Sign-On and thus in the authentication of users and authorisation to target systems. The Provisioning module then ensures that, within large and complex organisations, all settings are managed in a controlled and auditable manner.

Service automation

Something similar applies to the HelloID Service Automation module. With the provisioning functionality we ensure that users are automatically provided with accounts and permissions wherever possible. Besides that automatic provisioning, there are always individual requests. Someone may need an extra application licence to work temporarily on a project. You could, of course, have such a change implemented by second-line administrators directly in the Identity Provider and other target systems. With the Service Automation module, helpdesk staff or managers can now make such changes themselves. Some adjustments can be performed by an employee independently via the self-service portal. These changes also concern, among other things, the Identity Provider, but they are carried out far more efficiently and in a more user-friendly way. Moreover, all changes are easier to trace afterwards. Security is maintained because the changes are executed through HelloID; no one works directly in the target systems.

Governance

Within HelloID we provide extensive reporting functionality, which we also combine with the HelloID Governance module. This allows us to trace all permission changes easily and to evaluate account and access management monthly, adjusting where necessary. Regular reviews identify backdoors and inconsistencies and keep our role model up to date. In this way, IAM functionality is fully embedded within the Plan-Do-Check-Act cycle, an important requirement within ISO 27001 and derived security standards.

Want to know more about the role of an Identity Provider?

Want to learn more about the role of an Identity Provider and its use within HelloID? The Access Management page on our site provides a complete overview of the features and capabilities.