TRACK: BASICS

What an identity provider does, and what it signs

Editorial assessment · Desk research from public vendor material · Reviewed 2026-09-29

3 min read

Every company application needs to know who is using it. Rather than keep its own list of passwords, it hands that job to an identity provider, or IdP: the system people sign in to once, which then tells each application who they are. Okta, Microsoft Entra ID, Ping Identity, Google Cloud Identity and JumpCloud are identity providers for a workforce. NewCore describes itself as an identity provider for both people and AI agents.

The three jobs

An identity provider does three things. It keeps a directory of people and their attributes. It authenticates them, with a password, a passkey, a security key or another factor. And it issues a statement that an application can trust without contacting anyone else: a SAML assertion or an OpenID Connect ID token, signed with the identity provider's key.

How single sign-on works

When someone opens an application, the application sends them to the identity provider. The identity provider checks whether they are already signed in and, if not, asks them to authenticate. It then sends them back with the signed assertion or token. The application checks the signature and the details inside, such as who the user is, which application the token is for and when it expires, and lets them in. SAML is the older, XML-based way of doing this; OpenID Connect is the newer one, built on OAuth.

Why the signature matters

Applications trust the signature, not the person. If an attacker obtains the signing key, they can issue tokens for anyone, and every application will accept them. The attack known as Golden SAML is exactly this: forging assertions with a stolen federation signing key. NIST IR 8587, finalised on 15 September 2026, sets out recommendations for identity providers and key management with this class of attack in mind.

Identity providers protect their keys in different ways, and most do not describe the details publicly. NewCore's Secure Split Key is one published design: signing needs two key shares, one in NewCore's cloud and one in the customer's environment, so neither side can sign a valid token alone. On the workforce IAM page it is the only product whose public pages describe customer-held signing keys.

Accounts inside each application

Signing in is only half of it. Many applications also need an account for each person before they can use it. SCIM, defined in RFC 7644, is the HTTP-based standard identity providers use to create and update those accounts. App catalogues, the pre-built integrations an identity provider offers, usually bundle single sign-on and SCIM for each application. Okta lists more than 8,000 pre-built integrations; Microsoft describes its gallery as containing thousands of applications.

What to ask any identity provider

• Which sign-in methods are available, and can phishing-resistant ones be required?
• Which applications have pre-built integrations, and which of those include SCIM?
• Who holds the key that signs tokens, and what happens if it is stolen?
• Can AI agents and service accounts be given identities under the same policies as people?

See workforce IAM platforms compared