If you only read one chapter, read this one. Everything after it is detail.

A cloud-based identity provider (often shortened to IdP) is an online service that stores digital identities, checks that people are who they claim to be, and then vouches for them to other applications. The word “cloud-based” means the service runs on a provider’s servers on the internet. You do not buy, install or maintain the machines yourself. You rent the service and reach it through a web address.

Put simply: instead of every app keeping its own list of usernames and passwords, the apps agree to trust one central service. That service does the checking. The apps only ask, “Did the identity provider approve this person?”

When that security desk lives in a data center run by someone else, and you reach it over the internet, you have the “cloud-based” version. Well-known examples include Microsoft Entra ID, Okta, Google Cloud Identity, Auth0, Amazon Cognito and AWS IAM Identity Center. We will meet each of them later.

Long technical phrases become easy when you split them into small parts.

Piece one: “Identity”

An identity is the digital version of a person, or sometimes a machine. It is a collection of facts: a name, an email address, a job title, the teams the person belongs to, and the devices they use. Think of it as a profile card. The card says who you are, and it carries a few details that decide what you are allowed to do.

Identities are not only for humans. A payment service that calls a billing service also needs an identity, so the billing service knows who is knocking. These are called machine identities or service identities.

Piece two: “Provider”

A provider is something that supplies a service to others. Here, the service is a simple promise: “I will check this person for you, and I will tell you the result.” Many applications can lean on the same provider. That is the whole point.

Piece three: “Cloud-based”

“Cloud-based” tells you where the service lives and who runs it. The servers, the databases that hold identities, the backups and the security patches all belong to the vendor. You receive the finished service through the internet, usually paying per user per month.

A handful of words carry most of the meaning in this field. Learn them once and the rest reads easily.

Authentication: proving who you are

Authentication answers the question, “Are you really Priya?” You prove it with something you know (a password), something you have (a phone or a security key) or something you are (a fingerprint or face scan). Authentication is the identity provider’s main job.

Authorization: deciding what you may do

Authorization answers a different question: “Now that we know you are Priya, what are you allowed to open?” Being who you say you are does not mean you may enter every room. Authorization depends on roles, groups and rules.

Single Sign-On (SSO)

Single sign-on means you authenticate once and then reach many applications without signing in again. The identity provider remembers that you already proved yourself and tells each new app.

Service Provider (SP) or Relying Party

The application you want to use is called the service provider in one family of standards, and the relying party in another. Both names mean the same thing: an app that relies on the identity provider to do the checking. Do not let the word “provider” confuse you here. The identity provider checks you. The service provider offers the app.

Directory

A directory is the database of identities inside the identity provider. It stores users, groups, and the relationships between them. Older companies often kept this directory in a server room, with Microsoft Active Directory being the best-known example. Cloud identity providers keep it in the cloud, and many can also connect to an older directory so both stay in step.

Token

A token is a small, signed piece of data that says, “The identity provider vouches for this person, for this app, until this time.” The app trusts the token because the identity provider signed it with a secret key that only the provider holds. The app can check the signature using a matching public key. Tokens are the badges from our lobby story.

Federation

Federation means two separate organizations agree to trust each other’s identity checks. When a company lets its employees open a partner’s portal using their normal work login, that is federation. The partner never sees the employee’s password. It only receives a signed statement from the employee’s own identity provider.

Multi-Factor Authentication (MFA)

MFA asks for more than one kind of proof, such as a password plus a code from a phone app. If a thief steals only the password, the door stays shut.

Every useful technology exists because something was painful. Here is the pain.

The old world: one account per app

In the early days of business software, each application kept its own user list. The email system had its list. The payroll system had another. The sales tool had a third. When a new employee joined, someone had to create an account in each of them by hand. When the employee left, someone had to remember to delete every one of those accounts.

People are not good at remembering many passwords, so they reuse the same one, or choose simple ones, or write them on sticky notes. Attackers love this. If one small app gets breached, the stolen password often opens the bigger, more valuable apps too. Industry breach reports, such as the yearly Verizon Data Breach Investigations Report, keep listing stolen or weak credentials among the most common ways attackers get in.

Why this became worse with the cloud

Once companies started using dozens or hundreds of internet-based tools, the number of separate logins exploded. Each tool lives outside the company network, so the old trick of “if you are inside the office, you are trusted” no longer works. The sign-in page itself became the front door, and there were too many front doors to guard.

What a cloud identity provider fixes

• Fewer passwords. One strong login replaces many weak ones.
• One place to enforce rules. Want everyone to use MFA? Switch it on once, not in fifty tools.
• Fast onboarding and offboarding. Create or disable one account and access follows everywhere.
• A single audit trail. Every sign-in is recorded in one log you can search.
• Less to build. Developers stop writing their own login pages and password storage, which is easy to get wrong.

Let us open the box and see what a cloud identity provider is made of.

Almost every cloud identity provider, no matter the brand, has the same building blocks. Think of them as departments inside the lobby security office.

flowchart LR
    U["User with Browser or Phone"] -->|"1. Opens app"| APP["Application - Service Provider"]
    APP -->|"2. Redirects to sign in"| IDP["Cloud Identity Provider"]
    IDP --> DIR[("User Directory")]
    IDP --> MFA["MFA and Risk Engine"]
    IDP --> POL["Access Policy Engine"]
    IDP --> LOG["Audit Log and Monitoring"]
    IDP -->|"3. Signed token"| APP
    HR["HR System"] -.->|"Syncs people"| DIR
    APP -.->|"Gets user updates"| IDP
    

The user directory

This is the database of people, groups and devices. It is the memory of the system. A good directory also stores facts called attributes, such as department, manager or country. Policies use these attributes to make decisions.

The authentication engine

This part checks your proof. It verifies your password, sends a push request to your phone, or validates a fingerprint through a security key. It also protects itself against guessing attacks by slowing down or blocking repeated failures.

The MFA and risk engine

Modern providers do not treat every sign-in the same. They look at signals: Is this a new device? Is the location strange? Is the sign-in happening at an unusual hour, or from two far-apart countries within minutes? Based on a risk score, the engine may ask for an extra step or deny access.

The policy engine

Policies are the written rules. Examples: “Only finance staff may open the payroll tool.” “Admins must use a hardware security key.” “Block sign-ins from countries where we have no staff.” The policy engine applies these rules every time someone asks for access.

The token service

After the checks pass, this component creates the signed token and hands it to the application. It holds the private signing keys, which are among the most sensitive secrets in the whole system.

The application catalog and connectors

Providers keep a library of ready-made connections to popular apps. Setting up a new app can be as simple as picking it from a list and pasting a few settings. Large vendors advertise thousands of such prebuilt integrations.

The provisioning service

This part creates, updates and removes accounts inside connected apps automatically. It usually speaks a standard called SCIM, which we cover later.

The audit log

Every sign-in, failure, policy change and admin action is recorded here. It is your security camera footage.

How the trust between the app and the provider is set up

An app does not simply believe any token that arrives at its door. Before the very first sign-in, an administrator performs a one-time introduction between the two sides. Think of it as two companies signing a short partnership letter before they trade.

During this introduction, the identity provider gives the app a few important facts: its own name (called the issuer), the web address where users should be sent to sign in, and a public key or certificate that the app will use later to check signatures. In return, the app tells the provider its own name, sometimes called a client ID or entity ID, plus the exact web address where tokens may be delivered. This last address is called the redirect address.

That redirect address matters more than it looks. The provider will only deliver tokens to addresses that were registered ahead of time. If an attacker could trick the provider into sending a token to a different address, they could steal it. By keeping a strict list of allowed addresses, the provider closes that door.

Why a shared set of facts makes it scale

Because the trust is set up once and uses public keys, the provider never needs to talk to the app on every sign-in. The app can check a token entirely on its own. This is one reason cloud providers can serve very large numbers of sign-ins: Microsoft Entra ID and Google handle sign-ins for huge numbers of apps and users, and each app simply verifies signatures locally rather than phoning home each time. The provider also publishes its public keys at a well-known web address, so apps can fetch updated keys when the provider rotates them.

Follow one person from the first click to the finished sign-in.

Suppose Priya wants to open a project-tracking tool at her company. The tool is the service provider. Her company uses a cloud identity provider. Here is the journey.

sequenceDiagram
    participant P as Priya in Browser
    participant A as Project Tool
    participant I as Cloud Identity Provider
    P->>A: 1. Open the tool
    A-->>P: 2. You are not signed in, go to the identity provider
    P->>I: 3. Arrive at the sign-in page
    I->>P: 4. Ask for password and a second proof
    P->>I: 5. Send password and approve on phone
    I->>I: 6. Check policy and risk
    I-->>P: 7. Send signed token back through the browser
    P->>A: 8. Hand over the signed token
    A->>A: 9. Verify the signature and read the claims
    A-->>P: 10. Welcome, you are in
    

Why the app never sees the password

Notice what did not happen: Priya’s password never went to the project tool. She typed it into the identity provider’s own page. This matters a great deal. If the project tool is hacked, the attacker finds no password to steal. The only thing the app holds is a token that expires.

What happens when Priya opens a second app

Later that morning, Priya opens the company chat tool. Again the chat tool does not know her, so it sends her browser to the identity provider. This time something nice happens. Her browser still carries a small session cookie from the earlier sign-in. The identity provider sees the cookie, recognizes that Priya already passed every check, and immediately issues a fresh token for the chat tool. She sees only a quick flicker of the screen and lands inside the chat tool. No password, no phone prompt.

Two sessions exist at the same time, and it helps to keep them apart in your mind. The first is the identity provider session, which proves Priya signed in to the provider. The second is each application session, which proves Priya is signed in to that one app. Each can have its own length. A provider might keep her session alive for eight hours, while a bank-like app might expire its own session after fifteen minutes of inactivity.

The tricky part: signing out

Signing in is easy to picture. Signing out is harder. If Priya presses “sign out” in the chat tool, should she also be signed out of the project tool? Many companies want the answer to be yes, especially on shared computers. Providers support a feature called single logout, where the provider tells every connected app to end its session. In practice this works well in some apps and poorly in others, because each app must listen for the message. This is why security teams also rely on short app sessions: even if a logout message is missed, the session ends by itself soon enough.

A protocol is just an agreed way of talking. Three of them dominate this world.

SAML 2.0

SAML stands for Security Assertion Markup Language. It was designed for sign-in to web applications, especially in big organizations. The identity provider sends an assertion, which is a signed statement written in XML, saying who the user is. SAML is older and very common in workplace tools. If you have used SSO at work with a tool like Slack on a paid plan, GitHub Enterprise or Zoom, SAML may well have been involved.

OAuth 2.0

OAuth 2.0 is about delegated permission, not about proving who you are. It lets you say, “App A may read my calendar, but nothing else,” without handing App A your password. The result is an access token that carries limited permission. This is authorization, not authentication.

OpenID Connect (OIDC)

OpenID Connect is a thin layer built on top of OAuth 2.0 that adds the missing piece: proof of who the user is. It introduces an ID token, usually written as a JSON Web Token (JWT), that carries identity facts. When you press “Sign in with Google” on a third-party site or app, OpenID Connect is the usual technology behind it.

What is inside a token?

A token carries claims, which are small facts. Typical claims are: who issued the token, who the user is, which app it is meant for, when it was created and when it expires. Because the token is signed, the app can detect if anyone changed even one character. Tokens are deliberately short-lived. Access tokens often last only from a few minutes to about an hour, so a stolen one is useful for a very short time.

Three kinds of tokens, three different jobs

Beginners often hear “token” and assume there is only one kind. In reality, modern sign-in uses several, and mixing them up leads to mistakes.

The authorization code journey in plain words

For web and mobile apps, the safest and most popular way to use OpenID Connect and OAuth 2.0 is called the authorization code flow. The name sounds scary, but the idea is simple. The identity provider does not hand the real tokens through the browser, where they might be seen. Instead, it hands the app a short, one-time code. The app then goes directly to the provider, behind the scenes, shows the code along with its own secret proof, and receives the real tokens in return.

Mobile apps and single-page web apps cannot keep a secret safely, because anyone can inspect them. For those, providers add an extra safeguard called PKCE (pronounced “pixie”). The app invents a one-time secret for each sign-in, shows only a scrambled version at the start, and reveals the real one at the end. If an attacker steals the code halfway, they cannot finish the trade. PKCE is now widely recommended for nearly all apps.

People change jobs. Good identity systems follow them automatically.

Signing in is only one part of the story. The identity provider also manages the whole lifecycle of an account. Security teams describe it as three events: joiner, mover and leaver.

flowchart TD
    HR["HR System records a new hire"] --> IDP["Cloud Identity Provider creates the identity"]
    IDP --> G["Adds user to groups by role"]
    G --> SCIM["Provisioning sends accounts using SCIM"]
    SCIM --> A1["Email"]
    SCIM --> A2["Chat"]
    SCIM --> A3["Project Tool"]
    HR2["HR System records a role change or exit"] --> IDP2["Identity Provider updates or disables the identity"]
    IDP2 --> SCIM2["Accounts changed or removed in every app"]
    

Joiner

A new employee is added to the HR system. The identity provider notices, creates an identity, puts the person into the right groups (for example, “Engineering”), and sends account-creation requests to each connected app. On day one, the person signs in and everything is ready.

Mover

When someone changes teams, their group membership changes, and the access they hold changes with it. Old access is removed and new access is added. Without automation, people tend to collect permissions over the years and keep rights they no longer need. Security people call this privilege creep.

Leaver

When someone leaves, disabling the single identity in the provider cuts off access everywhere, ideally within minutes. This is one of the biggest safety wins of a central provider. Without it, forgotten accounts in forgotten tools become open doors.

SCIM: the automatic account courier

SCIM stands for System for Cross-domain Identity Management. Version 2.0 was published as standards documents in 2015. It gives apps a common way to accept instructions like “create this user,” “change this user’s group” and “remove this user.” It saves administrators from clicking through every app by hand.

Passwords alone are weak. Providers add stronger proofs around them.

Multi-factor authentication

MFA combines two or more different kinds of proof. Common choices are listed below, from weakest to strongest in general.

Passkeys and phishing resistance

Passkeys are built on the FIDO2 and WebAuthn standards. WebAuthn became a W3C recommendation in 2019. With a passkey, your device holds a private key that never leaves it. The website only receives a signed answer to a challenge. Because the answer is tied to the genuine site, a fake look-alike page gets nothing useful. This is why security teams call passkeys phishing-resistant.

Adaptive and conditional access

Instead of asking everyone for the same steps all the time, the provider adjusts. A sign-in from a company laptop in the usual city might glide through. A sign-in from a new device in a new country might require a security key, or be blocked. This keeps normal days easy and unusual moments safe.

“Cloud-based” is a choice. Here is how it compares with the alternatives.

An on-premises identity system runs on servers in your own building or your own data center. A cloud-based one runs at the vendor. A hybrid setup uses both, often because a company still has older apps that only understand the older directory.

For most organizations today, the practical answer is hybrid on the way to cloud. They keep the older directory while they move users, then slowly retire it as apps modernize. Microsoft’s own products show this pattern: companies often sync an on-premises Active Directory to Microsoft Entra ID so that the same person has one identity in both worlds.

Where the data physically lives

One question comes up in almost every company meeting about cloud identity: “Where are our employees’ details stored?” Identity data often includes names, email addresses, phone numbers and job titles, which count as personal information under many privacy laws. Large providers let customers choose a region, such as Europe or North America, where the directory is stored. Some also publish reports from independent auditors that confirm their security practices. Before you sign a contract, read these reports and ask about region choices, how long logs are kept, and what happens to your data if you leave.

Cost: what you actually pay for

Pricing usually has a per-user, per-month base, with higher tiers adding advanced features such as risk-based sign-in rules, automatic provisioning and detailed governance reports. For customer-facing identity, pricing often depends on the number of monthly active users instead. The cheapest tier can be tempting, but remember that features like phishing-resistant MFA, conditional access and lifecycle automation are exactly the ones that reduce risk. Count the cost of an incident, not only the cost of the subscription.

The “consumer” cousin: customer identity

So far we mostly talked about employees. A second kind of cloud identity provider serves customers of an app: shoppers, players, app users. This is called customer identity and access management, or CIAM. Services such as Amazon Cognito and Auth0 are built for this. The scale is different: instead of thousands of staff, there may be millions of customers, who expect sign-in with email, with a social account, or with a passkey, all in a few taps.

Because one service guards many apps, protecting it matters more than almost anything else.

There is a trade-off hidden in this whole idea. A central identity provider is a very valuable target. If an attacker takes over the provider, they might reach everything behind it. So the provider and its administrators must be defended with extra care. Let us look at the main risks.

Stolen or guessed credentials

Attackers try lists of leaked passwords against sign-in pages, a technique called credential stuffing. MFA, rate limiting and breached-password checks are the standard defenses.

Phishing and fatigue attacks

In phishing, a fake page copies the real sign-in page to trick you. In MFA fatigue, an attacker who already knows your password spams your phone with approval requests until you tap “yes” just to make them stop. Number matching and phishing-resistant passkeys help beat both.

Token theft

If someone steals a valid token, they may be able to act as the user until it expires. Short lifetimes, binding tokens to a device where possible, and quick revocation reduce the damage.

Signing key theft and forged tokens

The signing keys are the crown jewels. If an attacker steals them, they can create tokens that look perfectly genuine. A famous example is the technique called Golden SAML, where attackers who control the key material of a federation server forge SAML assertions. Security agencies and vendors described this technique in connection with the SolarWinds intrusions revealed in late 2020. The lesson: guard signing keys like gold, rotate them, and monitor the systems that hold them.

Compromise of the vendor or its support tools

Even the vendors themselves can have bad days. In 2023, Okta publicly disclosed that an attacker had used stolen credentials to access its customer support case system, which could contain files customers uploaded when asking for help. It is a reminder that you should limit what you upload to support tickets and that you should plan for the day your provider has trouble.

Device trust and session limits

Knowing who is signing in is only half of the picture. Modern providers also ask, “What device is this?” A laptop that is managed by the company, has a screen lock, an encrypted disk and up-to-date software is more trustworthy than an unknown computer in a hotel lobby. Policies can say: managed devices get easy access, unknown devices get limited access or must use stronger proof.

Session limits add another layer. Even after a successful sign-in, the provider can require a fresh check after a set time, or when the person tries something sensitive, such as changing payment details. This idea is called step-up authentication. A good everyday example is a banking app that lets you view your balance with a quick fingerprint but asks for an extra code before you send a large transfer.

Protecting the recovery path

Attackers do not always attack the front door. Often they go after the “I lost my phone” process. If a help desk can reset someone’s MFA after a short friendly phone call, the whole security system is only as strong as that call. Strong programs verify identity in several ways before any reset, notify the person and their manager, and give brand-new MFA devices limited access at first. Several well-publicized breaches in recent years began with attackers convincing a help desk to reset an account.

The shared responsibility idea

With cloud services, security is split. The vendor protects the platform: servers, networks and the service software. You protect how you use it: who gets admin rights, which policies are on, which apps are connected, and how you respond to alerts. Many incidents happen not because the platform failed, but because a customer left a setting too open.

Availability is a security topic too

If the identity provider is unreachable, nobody can sign in. Providers publish uptime targets, often 99.9% or higher, and run in several data centers. Smart organizations also prepare for the worst: a small set of emergency “break-glass” administrator accounts, stored safely and tested now and then, so they can still get in if the normal path fails.

You cannot protect what you cannot see.

Because every sign-in passes through the identity provider, its logs are a gold mine. They show who signed in, from where, on what device, which app they opened, whether MFA passed, and which policy made the decision. Security teams usually forward these logs to a central monitoring system so they can search them next to logs from other tools.

What to watch

Useful health numbers

• Sign-in success rate and sign-in latency (how long a sign-in takes) show whether users are having a smooth day.
• MFA coverage: the percentage of users and admins who have strong MFA enrolled.
• Provisioning errors: accounts that failed to be created or removed in connected apps.
• Dormant accounts: identities that have not signed in for months and may be safe to disable.
• Token and certificate expiry dates, so nothing breaks because a certificate quietly ran out.

Alerts should lead to action. A useful alert says what happened, to whom, and what the first step is. Too many noisy alerts train people to ignore them, so tune them regularly.

A pattern is a proven way of doing something. An anti-pattern is a popular way of doing it badly.

Helpful patterns

Anti-patterns to avoid

A short checklist you can use at work tomorrow.

Best practices

• Turn on MFA for everyone, and phishing-resistant MFA for admins. This single step blocks a large share of account takeovers.
• Prefer OpenID Connect or SAML over homemade logins. Writing your own password system invites mistakes.
• Automate the joiner, mover and leaver steps. Connect the provider to your HR system and use SCIM wherever apps support it.
• Keep tokens short-lived and verify every token fully: the signature, the issuer, the intended audience and the expiry time.
• Plan for outages. Document and test the emergency access procedure.
• Send logs to a central monitoring tool and alert on risky events.
• Review access regularly and remove what is no longer needed.
• Track certificate and key expiry dates. Rotate signing keys on a schedule.
• Use the authorization code flow with PKCE for web and mobile apps, and register exact redirect addresses rather than broad patterns.
• Harden the help desk process. Make MFA resets slow, verified and visible, because attackers target them.
• Pilot before you roll out. Start with one friendly team, learn what breaks, then expand in waves.
• Write down who owns what. Every connected app should have a named owner who can answer, “Who needs this access and why?”

Common mistakes

• Confusing authentication with authorization. Knowing who someone is does not tell you what they may do. Always check permissions as well.
• Trusting a token without checking it. Reading the contents of a token is not the same as verifying its signature.
• Leaving old test apps connected. Forgotten connections remain doors into your system.
• Letting certificates expire. A single expired SAML certificate can lock a whole department out of a critical app on a Monday morning.
• Over-trusting social sign-in for sensitive business features without extra checks.
• No plan for vendor trouble. Assuming the provider will never fail is a bet, not a plan.

Where you already meet cloud identity providers every day.

Names change and features grow, so treat this as a map, not a buying guide.

How to choose

Start with your situation, not with brand names. Ask: Are we protecting employees or customers? Which ecosystem do most of our apps live in? Do we have old apps that need a bridge? What rules apply to where data is stored? How many people will sign in, and how much will it cost as we grow? Then test with a small pilot group before you roll it out to everyone.

You started with a long, scary phrase. Now you can say it in one calm sentence: a cloud-based identity provider is an internet-hosted service that stores identities, verifies people, and vouches for them to many applications using signed tokens. Everything else in this guide is a closer look at that sentence.