Start with the idea, then the name.

An identity is the digital version of “who you are” inside a service. It is made of an account, a way to prove that you own the account, and a set of facts about you, such as a name, an email address, and your preferences. Access is what that identity is allowed to do, such as viewing an order history or changing a delivery address. Management means that someone has to create, protect, update and eventually remove these identities in an orderly way.

When the people holding the identities are a company’s own staff, we call it workforce identity. When the people are the company’s customers, such as shoppers, patients, bank clients or app users, we call it customer identity. Customer identity is the front door of a digital business.

The same words, but a very different job.

Many people first meet Okta as a tool for company staff. Employees are known in advance, they are given accounts by their company, and they can be told which phone app to install. Customers are different in almost every way. They arrive on their own, they pick their own passwords, they use any device they like, and they leave the moment the experience feels annoying.

The tension at the heart of CIAM

Every extra step in a sign-up form drives some customers away. Every missing safeguard invites criminals in. A good customer identity system walks the line between convenience and security. Much of what follows in this guide is about how to keep both.

It is not only a security feature. It is part of the product.

It affects growth

A slow or confusing sign-up page loses customers before they ever buy. Studies and common experience show that every extra form field costs something. Letting people sign up with a single tap, or with an account they already have, removes a lot of that friction.

It affects trust

Customers hand over personal facts and payment details. If an account is taken over, the customer blames the business. A business that visibly protects accounts earns loyalty, and one that suffers a breach pays in lost trust for years.

It affects cost

Forgotten passwords are among the most common reasons people phone a help desk. Fewer passwords, smoother recovery and safe self-service reduce those calls. Building all of this from scratch is slow and risky, so many companies choose a specialist service.

It affects the law

Many places have privacy laws that govern how customer data is collected, stored and deleted. Examples include the GDPR in Europe and the CCPA in California. A good identity system helps a business collect consent and respond to requests from customers about their data. This guide is not legal advice, so always involve your own legal and privacy teams.

The big picture first, the details later.

Okta is an identity provider, which means it is a trusted service that knows who people are and tells applications whether to let them in. For customer-facing needs, Okta offers its Customer Identity products. A major part of these is the Okta Customer Identity Cloud, which is built on the platform of Auth0, a company that Okta acquired in 2021. Okta also offers customer-oriented capabilities on its wider platform. Product names and packaging change from time to time, so always check Okta’s current documentation for the exact offering that fits your plan.

What the service gives you

What “brief” means in this guide

This guide covers the foundation: what CIAM is, the main parts, how sign-up and login work, the main protections, and the habits that avoid trouble. It does not cover every setting or every advanced design. Once these basics feel natural, the deeper options become easy to learn.

Ten small ideas explain almost everything in this topic.

Why use standards at all?

A standard is an agreement that many companies follow. Because OpenID Connect and OAuth 2.0 are standards, a sign-in built with Okta can work with web apps, phone apps and many software tools without a special deal for each. It is also safer, because thousands of experts have examined the standards over many years.

Who are the players, and what does each one do?

flowchart LR
  C["Customer"] --> APP["Your Web or Mobile App"]
  APP --> LP["Hosted Login Page"]
  LP --> CI["Okta Customer Identity"]
  CI --> US["User Store"]
  CI --> SO["Social and Enterprise Connections"]
  CI --> AP["Attack Protection and MFA"]
  CI --> T["Tokens sent back to the app"]
  T --> APP
  APP --> API["Your Backend APIs"]

The parts, one by one

The customer is the person using your product. Your app is the website or mobile app. It does not collect passwords itself. Instead, it sends the customer to the hosted login page, which is a page run by the identity service that looks like your brand but is built and secured by specialists.

Okta Customer Identity sits behind that page. It checks who the customer is using the user store, which is the secure database of accounts. It can also use connections to other sign-in sources, such as a social account or a business customer’s own company login. Attack protection and multi-factor checks run during the process to stop criminals.

When the check passes, the service sends back tokens to your app. Your app then uses a token when it calls your backend APIs, which are the services that hold the customer’s data. An API checks the token and answers only if it is valid.

Why separate the login from the app?

Handling passwords is risky, and mistakes are costly. By moving that job to a specialist service, your app team can focus on the product. Customers also enjoy one login that works across many of your apps, and you can improve security in one place for all of them.

The first impression is a form. Keep it short.

flowchart TD
  V["Visitor arrives"] --> S{"Has an account?"}
  S -->|No| R["Sign up with email, social account or passkey"]
  S -->|Yes| L["Log in"]
  R --> W["Verify the email address"]
  W --> PP["Ask a few more details over time"]
  L --> M{"Risky or sensitive action?"}
  M -->|Yes| MF["Ask for extra proof"]
  M -->|No| OK["Continue"]

Ask for little at first

A long sign-up form feels like homework. A shorter one, with just an email address and a way to prove it, invites people in. The business can collect more facts later, when it has earned some trust. This habit is called progressive profiling. The system asks for a few more details at natural moments, such as when a customer places a first order, instead of asking for everything on day one.

Verify the email address

People mistype their email or use one that belongs to someone else. Sending a link or a short code to the address, and asking the customer to use it, proves that they own it. This protects against fake accounts and makes later password recovery work.

Give people choices, and make the safest choice the easiest.

Passwordless is the direction of travel

Passwords cause most of the pain in sign-in. People forget them, reuse them and have them stolen. Passkeys and one-time codes remove the password from the story. Many businesses now offer passkeys next to the older methods, and let customers move across at their own pace.

A lot happens in the few seconds after a customer taps Sign In.

sequenceDiagram
  autonumber
  participant C as Customer
  participant A as App
  participant O as Okta Login Page
  participant API as Your API
  C->>A: Tap Sign In
  A->>O: Redirect to the login page with a one time secret
  C->>O: Enter credentials or choose social login
  O->>O: Check attack protection and MFA rules
  O-->>A: Return a short lived code
  A->>O: Swap the code and the secret for tokens
  O-->>A: ID token and access token
  A->>API: Call the API with the access token
  API-->>A: Return the customer data

Walking through the diagram

The customer taps Sign In, and your app sends them to the hosted login page. Along with the request, the app includes a one-time secret that it made up for this single attempt. This is a protective step used for apps that cannot keep a permanent secret, such as mobile apps and web apps that run in the browser. It is commonly known as PKCE, pronounced “pixy”.

The customer proves who they are on the login page, by password, social account, passkey or code. Behind the scenes, the service checks its attack protection and decides whether to ask for extra proof. When all is well, it sends the app back a short-lived code. The app swaps that code and its one-time secret for the tokens. A thief who steals only the code cannot use it, because they do not have the secret.

The app then calls your API and presents the access token. The API checks that the token is genuine and fresh before it shares any customer data.

Three small messages do most of the work.

A token is a small piece of data, signed by the identity service so that nobody can change it without being noticed. Apps trust a token because they can check the signature. Three kinds appear again and again.

Why tokens expire

Access tokens are deliberately short-lived, often only minutes or hours. If a token is stolen, it stops working soon. The refresh token lasts longer, so it is guarded more carefully. If a refresh token is suspected to be stolen, the service can cancel it, and the customer simply signs in again.

A secure page that still looks like your own.

Customers trust pages that look familiar. A login page with the wrong colors or a strange web address makes people nervous. At the same time, building a login page is risky work, because small mistakes can expose passwords. The hosted login page solves both problems. The service builds and secures the page, and you decide how it looks.

What you can usually adjust

Why one login page for many apps

If every app had its own login page, customers would see different screens, and attackers would have many places to probe. A single shared login page gives a consistent look. It also allows single sign-on, which means that once a customer has signed in to one of your apps, they can open another without typing anything again.

Strong enough to stop criminals, light enough to keep customers.

Multi-factor authentication, or MFA, means asking for more than one kind of proof. A password is something you know. A code on your phone is something you have. A fingerprint is something you are. Combining two kinds makes a stolen password far less useful.

With employees, a company can say “install this app, or you cannot work.” Customers will not accept that for a simple shopping trip. So customer identity systems lean on more flexible approaches.

Ask only when it matters

One popular approach is adaptive or risk-based MFA. The system looks at the situation. Is this a new device? A new country? A sensitive action such as changing a bank detail or an email address? If the risk is low, the customer sails through. If it is higher, the system asks for extra proof.

Choices for the second proof

• A code sent by email or text message, which is easy but less safe.
• A code from an authenticator app on the customer’s phone.
• An approval on a phone through a push message.
• A passkey or a security key, which is the strongest and often the smoothest.

The open door of a public service is a magnet for criminals.

Anyone on the internet can reach a customer login page, including criminals with automated tools. They do not need to hack anything clever. They simply try an enormous number of stolen or guessed passwords, hoping that a few will work. Okta’s customer identity services include a set of defenses, often grouped under the name attack protection.

flowchart TD
  A["Login attempt arrives"] --> B["Bot detection"]
  B --> C["Suspicious address throttling"]
  C --> D["Brute force protection per account"]
  D --> E["Breached password detection"]
  E --> F["Risk based MFA"]
  F --> G["Allow, challenge or block"]

The common defenses

Credential stuffing in one paragraph

Credential stuffing is an attack in which criminals take username and password pairs leaked from one website and try them on many others. It works because people reuse passwords. It is one of the biggest threats to customer accounts, and it is exactly what these defenses aim to catch.

Many roads can lead to the same person.

Social login

Many customers already hold an account with a large provider. With social login, they tap a button, approve a short request, and they are in, with no new password. It lowers friction for the customer and lowers the number of passwords your business must protect. The trade-off is a dependency on the provider and on what the customer agrees to share.

Enterprise login

When your product serves other companies, an employee of a customer company may want to sign in with their own corporate account. This is called enterprise login. Their company controls who may sign in, and when an employee leaves that company, their access to your product can end at the same time.

The problem of two accounts

Imagine a customer who first signs up with an email and password, and later taps “continue with a social account” using the same email. Without care, your system could create a second, empty account. The customer thinks their history has vanished. Account linking is the careful process of joining these two sign-in methods into one profile.

When your customer is a company, not a person.

Many software products are sold to other companies. These are often called business-to-business products, or B2B for short. A project tool, for example, serves hundreds of companies, and each company has its own staff, its own roles and often its own corporate login. Okta’s customer identity services offer a concept called organizations to model this.

flowchart LR
  P["Your Software Product"] --> A["Customer Company A"]
  P --> B["Customer Company B"]
  A --> AU["Users and roles of A"]
  B --> BU["Users and roles of B"]
  A --> AI["Own corporate login of A"]

What this lets you do

Each customer company can have its own group of users, its own roles such as “admin” and “viewer”, and its own way to sign in. A person from Company A sees only Company A’s data. If Company B wants all its staff to sign in with its corporate account, you can allow that for Company B alone without changing anything for Company A.

Every business has special needs. The service leaves room for them.

No ready-made login can fit every business. A retailer may want to block sign-ups from disposable email addresses. A bank may want to check a rule before allowing a login. A software company may want to add a customer’s plan name into the token, so that APIs can see it. Okta’s customer identity services offer extension points, often called actions or hooks, where you can add your own steps at specific moments in the sign-up or login journey.

Moments where you can add steps

• After a customer signs up, to send a welcome message or create a record in your own system.
• Before a login completes, to check a rule and allow or deny it.
• When tokens are built, to add extra facts such as a role or plan.
• When a password is changed or a user is deleted, to inform other systems.

Programs that talk to programs

Not every caller is a person. A nightly job in your system may need to call an API. For this, the service offers tokens for machine-to-machine access, where a program proves its identity with its own credentials. Keep these credentials as carefully as passwords.

Customers are lending you their details. Treat them as a loan.

Customer identity systems hold personal data: names, emails, phone numbers, sometimes addresses and preferences. Laws in many countries set rules for this, and customers increasingly expect clear control. This guide is not legal advice, but the ideas below come up again and again.

Where the data lives

Some laws and company policies care about the country where data is stored. Okta’s customer identity services offer choices of region for a tenant, and your privacy team should confirm which region fits your needs. Choose carefully at the start, because moving later can be hard.

The front door must hold up on the busiest day of the year.

Customer traffic is unpredictable. A product launch, a holiday sale or a viral post can multiply logins within minutes. A login system that slows down turns customers away at the very moment the business most wants them. One of the strongest reasons to use a specialist service is that it is built to handle such spikes.

What can go wrong

Keep a second way in

Never make one method the only way to sign in. If the customer’s only option is a social provider and that provider has a problem, the customer cannot reach you. A second option, such as an emailed code, keeps the door open.

An account has a life, from first visit to goodbye.

flowchart LR
  A["Sign up"] --> B["Verify email"]
  B --> C["Everyday use"]
  C --> D["Add methods or link accounts"]
  D --> C
  C --> E["Recover access when something is lost"]
  E --> C
  C --> F["Customer leaves or asks for deletion"]
  F --> G["Account and data removed"]

Sign up and verify

The customer creates an account and proves they own their email address. The system records the account in the user store, along with the time and the consent the customer gave.

Everyday use

The customer signs in again and again. Tokens are issued and refreshed. The system watches for unusual signs and asks for extra proof when risk goes up.

Change and linking

Over time customers add a phone number, a passkey or a social account. Each addition makes the account stronger or easier to use, as long as it is done carefully and verified.

Recovery

People forget passwords, lose phones and change emails. A good recovery process is safe and kind. It must be easy for the real owner and hard for a thief. This is one of the most attacked parts of any system, so design it with extra care.

Leaving

When customers leave or ask for deletion, the account and related data must be removed in a clear and complete way, including copies held in other systems that you connected.

Every design trades something away. Here is an honest balance sheet.

Build or buy?

The big trade-off: friction versus safety

The smoother the path, the more customers finish it. The tighter the checks, the fewer criminals do. A good design uses risk to decide: easy for ordinary situations, stricter for unusual or sensitive ones.

Know the criminals’ tricks so that you can design against them.

Threat 1: Credential stuffing

Criminals take leaked passwords from other sites and try them on yours at huge speed. Defenses include bot detection, throttling of suspicious addresses, breached password detection, and encouraging passkeys or a second proof.

Threat 2: Phishing

A fake login page tricks the customer into typing their password and code. Defenses include passkeys, which do not work on fake sites, a custom domain that customers learn to recognize, and clear messages that you never ask for a code by phone.

Threat 3: Account takeover through recovery

A criminal pretends to be the owner and uses the forgot-password path. Defenses include sending recovery links only to verified addresses, asking for extra proof for risky changes, and notifying the customer when a password, email or phone number changes.

Threat 4: Fake sign-ups

Bots create thousands of fake accounts to abuse offers or send spam. Defenses include bot checks, email verification and limits on how fast one address can create accounts.

Threat 5: Stolen tokens

If a token is copied from a device or a log, it can be used until it expires. Defenses include short lifetimes, careful storage, never writing tokens to logs, and the ability to cancel refresh tokens.

Threat 6: Weak settings and over-trust in your own code

Wrongly set redirect addresses, loose permissions and rushed custom steps can open holes. Defenses include allowing only exact, known return addresses, giving each app only the permissions it needs, and reviewing custom steps like any other security code.

If nobody watches the dashboard, a quiet attack stays quiet.

Customer identity services write a record of important events into logs. Each record can show who tried to sign in, from where, using which method, and whether it worked. Many services can also stream these logs to your own monitoring tools, so that your security team sees them next to everything else.

What to keep an eye on

Useful numbers to track over time

Teams track simple health numbers, such as the share of visitors who finish sign-up, how many logins succeed on the first try, how many use passkeys or social login, how often extra proof is asked and passed, how many are blocked by attack protection, and how many customers contact support about access. A healthy system moves these numbers in the right direction. A sudden change is a signal to investigate.

Most businesses already have customers. They cannot start from zero.

Many companies adopt a customer identity service while they already hold thousands or millions of accounts in an older database. Asking every customer to sign up again would be a disaster. There are two main ways to move customers across.

Things to plan

• How the old passwords are stored, and whether they can be carried over safely.
• Which customer facts to bring, and which to leave behind.
• How to avoid duplicate accounts, especially where people used several emails.
• What to tell customers, and when.
• How long to keep the old system running while the move is in progress.

Habits that work well, and habits that cause trouble.

Patterns that work

Anti-patterns that cause trouble

A short checklist for the team setting this up.

Before you start

• Decide who your customers are: people, companies, or both.
• Decide which sign-in methods you will offer, and in what order.
• Write down the minimum facts you need at sign-up.
• Involve privacy and legal teams early.

While you build

• Use the hosted login page and a custom domain for your brand.
• Turn on attack protection and test it.
• Offer passkeys or another strong method alongside passwords.
• Use separate tenants for development, testing and production.
• Allow only exact, known return addresses for each app.
• Keep custom steps small, fast and well tested.

After go-live

• Watch failed logins, sign-up surges and reset requests.
• Review who has admin access to the tenant, and use strong proof for them.
• Load-test before big events.
• Review privacy settings, consent records and deletion steps on a schedule.
• Practice what to do if an attack or an outage happens.

Common mistakes

Good projects are decided on paper before they are decided in the console.

Roll out in phases

Where this idea shows up in daily life.

Customer identity is used by businesses of every size and in nearly every industry. The scenarios below are typical examples of how organizations apply the same ideas. They are general descriptions, not accounts of any named company.

Lessons from real projects in the industry

Teams that report smooth customer identity projects share the same habits. They keep sign-up short, offer several sign-in methods, turn on attack protection from the first day, plan recovery carefully, test for peak traffic, and watch the logs. Teams that report pain tend to build their own login first, collect too much data, or rush a migration. The lesson is that the front door is a product in itself, and it deserves the same care as the rest.

Keep this chapter handy. Every word used in the guide is explained here.

Identity words

Security and technology words