Every digital product that lets people have an account has an identity problem. The question is only whether you solve it well.

Think of the last time you signed up for an online service. You probably typed an email address, chose a password, perhaps confirmed your email, and maybe approved a code on your phone. Behind those few moments sit many decisions: how to store the password safely, how to stop someone guessing it, what to do when you forget it, how to let you sign in with a social account, and how to remember you on your own phone without asking too often. Each decision affects security, convenience, and trust.

The business stakes

• Conversion: a clumsy sign-up form makes visitors give up before becoming customers.
• Trust: a breach of customer accounts damages a brand for years.
• Cost: support calls about lost passwords consume time and money.
• Compliance: laws about personal data apply to the information you collect at the front door.
• Speed: every week spent building login screens is a week not spent on your real product.

Why not simply build it yourself

Many teams start by building sign-in themselves, because it seems simple. A table of usernames and passwords, a form, and a check. Years later they are maintaining password storage, reset emails, multi-factor prompts, social sign-in connections, breach monitoring, bot defences, audit trails, and accessibility fixes, while attackers constantly invent new tricks. A specialist service spreads that cost across thousands of customers and employs people who think about identity all day.

flowchart LR
    V["Visitor"] --> FD["Front door:
sign up, sign in, recover"]
    FD --> P["Your product"]
    FD --> S["Security checks"]
    FD --> D["Customer data"]
    

Figure 1 shows the front door in the middle. Everything flows through it: who gets in, what protection they pass, and what information is gathered about them. A well-run door makes the rest of the building easier to manage.

A short vocabulary unlocks everything else. Read the table once, then return to it whenever a word feels unfamiliar.

Authentication versus authorization

These two words sound alike and are constantly confused. Authentication answers “who are you?” Authorization answers “what are you allowed to do?” A hotel receptionist checks your booking to authenticate you, then hands you a key that opens only your room, which is authorization. Customer identity covers both, but they are different jobs, and mixing them up leads to design mistakes.

Customer versus workforce identity

Workforce identity is about the people who work for a company: employees, contractors, and partners who need access to internal tools. Customer identity is about the people who use a company’s products. The two differ in scale, behaviour, and expectations. Employees are few, known, and managed; customers can be millions, anonymous at first, and unwilling to jump through hoops. Customers choose whether to use your product at all, so friction costs money.

flowchart TD
    ID["Identity
who someone is"] --> AN["Authentication
prove it"]
    AN --> TK["Token
signed proof"]
    TK --> AZ["Authorization
what is allowed"]
    AZ --> RS["Resource
your product"]
    

Figure 2 gives the order of events in the simplest case. A person with an identity proves themselves, receives a token as evidence, and the product uses that token to decide what to allow.

Why precise vocabulary saves time

Teams that use words loosely argue at cross purposes. One person says “login” and means the whole journey from first click to final redirect; another means only the password check. Agreeing on terms such as tenant, application, connection, token, and session lets everyone discuss problems with the same meaning. Keep a short glossary beside your design documents, and add to it whenever a new word appears in a meeting.

Okta serves two audiences with two families of products. Knowing which is which prevents a great deal of confusion.

Okta is best known for workforce identity: helping organizations manage how employees sign in to the tools they use for work. The customer-facing side is a different offering, shaped for the needs of products with public audiences. It grew out of a platform widely known as Auth0, which Okta acquired, and the two names may still appear together in documentation, dashboards, and conversations. Naming and packaging have shifted over time, so confirm current names in the official documentation.

Typical differences in practice

flowchart LR
    ORG["Your organization"] --> WF["Workforce identity
employees"]
    ORG --> CI["Customer identity
product users"]
    WF --> INT["Internal tools"]
    CI --> PROD["Customer-facing products"]
    

Figure 3 shows that a single organization can use both. Staff use the workforce side to reach internal tools, and customers use the customer side to reach products. Keeping them conceptually separate makes designs cleaner and safer.

Your tenant is your private home inside the service. Where it lives and how many you keep shape everything downstream.

A tenant is a self-contained space in which all your settings, applications, connections, users, and logs live. Nothing in your tenant is visible to other customers, and nothing in theirs is visible to you. When you begin, you create a tenant and choose a name and a region. The region is the geographic area in which your data is stored and processed. Region choices matter for speed, because distance adds delay, and for law, because some rules restrict where personal data may live.

Separate tenants for separate stages

A common and wise practice is to keep different tenants for different stages of your work: one for development and experiments, one for testing, and one for real customers. Changes can be tried safely in the first two before they touch the third. Without this separation, a mistaken experiment could lock out real customers.

Choosing a region

• Where are most customers? Closer regions usually give snappier sign-in.
• What do laws require? Some places require that personal data stay within their borders.
• What are your contracts? Large customers may demand particular locations.
• Can you change later? Moving a tenant between regions can be difficult, so decide with care and confirm the options in current documentation.

Tenant naming and domains

A tenant has a name that usually appears in its default web address. Customers see this address during sign-in unless you set up a custom domain, which lets sign-in pages appear under your own brand, such as a login address on your own website. Custom domains build trust, because people see a familiar name in the address bar rather than a stranger’s. They also help with some browser privacy features. Plan for a custom domain early, since changing the address that customers see later is disruptive.

flowchart LR
    DEV["Development tenant"] --> TST["Test tenant"]
    TST --> PRD["Production tenant"]
    PRD --> CUS["Real customers"]
    

Figure 4 shows a one-way flow. Changes are made and checked early, then promoted. Real customers only ever meet changes that have survived two earlier stages.

To use the service, you register each of your products so the service knows who is asking for sign-in.

In the service, an application is a registration that represents one of your products: a website, a mobile app, a single-page app, or a server-side program. Registering gives the application a public identifier and, where appropriate, a secret. It also records where customers may be sent after sign-in. Think of registration as introducing each of your entrances to the reception desk, so that the desk knows which doors are legitimate.

Kinds of applications

Why the type matters

The kind of application decides which sign-in methods are safe. A program running on your server can hold a private secret that proves it is who it says it is. A program running in a visitor’s browser or on their phone cannot, because anyone can inspect it. So public applications use methods designed not to depend on a secret. Picking the right type is one of the most important early choices, and the wrong choice is a common source of security problems.

APIs as protected resources

Besides applications, you can register your own back-end services, called APIs, as resources that the service knows about. When an application asks to call your API, the service can issue a token that is meant for that API and carries only the permissions that API recognizes. This lets your back-end verify, without calling anyone, that a request really carries proper permission.

flowchart TD
    APP1["Website"] --> TEN["Your tenant"]
    APP2["Mobile app"] --> TEN
    APP3["Back-end job"] --> TEN
    TEN --> API["Your registered API"]
    

Figure 5 shows that one tenant can serve many entrances and many protected services. Each registration is independent, with its own settings, but they share the same customers and the same sign-in experience.

A connection is a way of recognizing a person. You can accept several kinds at once.

When someone signs in, the service must check them against some source of truth. That source is called a connection. Different customers prefer different ways to prove who they are, and a flexible service lets you offer several side by side.

Database connections

This is the classic choice. The customer creates an account with your product, and the service stores their credentials safely, using one-way scrambling of passwords so that the real password is never kept. It also handles the awkward parts: reset emails, rules about password strength, checks against known stolen passwords, and blocks after too many failed attempts.

Social connections

Many customers prefer not to invent yet another password. Letting them sign in with an account they already have is fast and reduces forgotten-password problems. The provider vouches for the customer, and the service passes along the details the customer agreed to share. You should decide which providers your audience actually uses, because offering too many buttons clutters the screen.

Passwordless

Passwordless sign-in removes the password altogether. The customer receives a short-lived code or a link, or uses a key held in their device. This removes the biggest weakness in most systems, the human habit of reusing weak passwords.

Enterprise connections

When you sell to other businesses, their employees often prefer to sign in with their company credentials. Enterprise connections connect to a customer’s own directory or identity provider. Each business gets its own connection, and the service routes people to the right one based on a hint, usually their email domain.

flowchart LR
    C1["Database
email and password"] --> UL["Sign-in page"]
    C2["Social account"] --> UL
    C3["Passwordless
code or key"] --> UL
    C4["Enterprise
company directory"] --> UL
    UL --> OUT["Same kind of result
for your product"]
    

Figure 6 shows the key benefit. Your product receives a uniform answer no matter how the customer proved who they are. You can add or remove ways of signing in without rebuilding your product.

Deciding which connections to offer

More choice is not always better. Each connection adds a button, a test case, and a support topic. Start by asking your customers or studying their habits. A shop for young shoppers may benefit from several social options, while a professional tool may prefer corporate sign-in and a plain email option. Begin with a small set, measure which are used, and expand only when there is evidence of demand.

The hosted sign-in page is where trust is won or lost. Understand why the service wants to run it.

Universal Login is the hosted sign-in experience. Instead of building login forms inside every product, you send customers to a page run by the service, and once they are signed in, send them back. The page is customizable in appearance, so it can carry your logo, colours, and wording. This centralization has a security benefit and a practical one.

Why a hosted page is safer

When login forms live inside every application, every application must handle passwords correctly. One mistake in one app can expose customers. With a hosted page, passwords are only ever typed into one carefully maintained place. Applications never see them. Additionally, new protections, such as new factors or new bot defences, appear everywhere at once, because there is only one page to update.

Why a hosted page is more convenient

A single sign-in page makes it possible for a customer to sign in once and move between your products without typing credentials again. That is called single sign-on, and it relies on the central page remembering the visitor. It also gives a consistent look across web and mobile.

Branding your page

• Logo and colours: help people recognize they are in the right place.
• Wording: friendly, short, and clear text in the languages your audience speaks.
• Custom domain: shows your own web address, which builds trust.
• Accessibility: readable contrast, keyboard use, and screen-reader support.
• Layout choices: advanced customization may be available, and should be tested thoroughly.

sequenceDiagram
    participant C as Customer
    participant A as Your app
    participant U as Universal Login
    C->>A: Open app, press Sign in
    A->>U: Send customer to hosted page
    C->>U: Prove who they are
    U->>A: Send customer back with proof
    A->>C: Signed in
    

Figure 7 shows the redirect round trip. The customer is briefly in the hands of the service, then returns to your app carrying proof. Your app never touches the password.

Sign-in follows agreed recipes, called flows, based on open industry standards.

You do not need to memorize protocol details to use the service well, but knowing the shape of a few ideas helps greatly. Customer identity today rests on open standards that let different systems work together. Two names appear constantly. One is about delegated permission: letting an application act on a person’s behalf without learning their password. The other builds on it to describe who the person is. Together they are the common language of modern sign-in.

The idea of a flow

A flow is a sequence of steps between the customer, your application, and the service. Different applications use different flows because their capabilities differ. The most widely recommended pattern for apps with a user present is one in which the application first receives a short-lived code after the customer signs in, then exchanges that code for tokens. This avoids passing tokens through the browser’s address bar, and has added safeguards that protect against interception, which are especially important for public applications.

Flows for different situations

Older flows to avoid

Some older approaches, such as handing passwords directly to an application, or returning tokens directly through the browser’s address, are now discouraged for good reasons. Prefer the modern recommended flows, and confirm in the current documentation which flows the service recommends for each application type.

sequenceDiagram
    participant B as Browser or app
    participant S as Service
    participant R as Your back-end
    B->>S: Request sign-in
    S->>B: Customer signs in, returns short-lived code
    B->>S: Trade code for tokens
    S->>B: Tokens
    B->>R: Call with token
    R->>B: Protected data
    

Figure 8 shows why the code step exists. The code is useless on its own and expires quickly. Only the legitimate application can trade it for tokens, which keeps eavesdroppers away from real credentials.

Tokens carry proof. Sessions remember people. The two work together but are not the same.

After a successful sign-in, the service issues tokens. A token is a small, digitally signed message. Because it is signed, anyone who trusts the service can check that it is genuine and unmodified, without phoning the service each time. Different tokens do different jobs.

Short lives are safer

Tokens are intentionally short-lived. If one is stolen, it becomes useless soon. Refresh tokens last longer, so they deserve extra care, and many designs rotate them: each time one is used, a new one is issued and the old one is retired. If an old one appears again, it signals theft and the whole chain can be cancelled.

Two kinds of memory

There are really two memories at work. The service remembers the customer, so that returning to the hosted page does not require typing credentials again. Your application also remembers the customer, usually with its own session in the browser. Signing out must therefore consider both. A customer who signs out of your app but remains signed in at the service may be signed straight back in the next time. Decide what sign-out should mean in your product, and test it.

Lifetimes are product decisions

How long should a session last? A banking product may want short sessions and frequent re-checks. A casual reading app may prefer long sessions for convenience. Neither answer is right everywhere. Balance risk against convenience, and let the sensitivity of the data guide you.

flowchart LR
    SI["Sign-in succeeds"] --> IDT["Identity token
who"]
    SI --> ACT["Access token
what is allowed"]
    SI --> RFT["Refresh token
renewal"]
    ACT --> EXP["Expires soon"]
    EXP --> RFT
    RFT --> NEW["New access token"]
    

Figure 9 shows the renewal loop. The short-lived access token expires, and the refresh token is used to obtain a replacement. The customer sees nothing, and security improves because the exposed token is always brief.

What goes wrong when tokens are mishandled

Common mistakes include storing long-lived tokens in places that other programs on the device can read, putting too much personal detail inside tokens that many systems can see, and accepting tokens without checking who they were meant for. Each mistake is avoidable. Store tokens where the platform recommends, include only what is needed, and always check the audience and expiry in your back-end.

Passwords alone are weak. Adding more evidence, or removing the password entirely, makes accounts far safer.

Passwords are the oldest and most abused method of proof. People reuse them, choose guessable ones, and get tricked into typing them into fake pages. Multi-factor authentication asks for a second kind of evidence, so that a stolen password alone is not enough. The kinds of evidence are traditionally grouped as something you know, something you have, and something you are.

Choosing second factors

• Codes by text message: familiar and easy, but weaker because numbers can be hijacked.
• Authenticator apps: generate time-based codes on the phone, stronger than text.
• Push approvals: a prompt to approve on a phone, convenient but open to tired users approving by mistake.
• Security keys and device-bound credentials: the strongest, resistant to fake pages.

Passkeys

Passkeys are a newer approach where the customer proves themselves with a secret held in their device and unlocked with a fingerprint, face, or device code. There is no password to steal and nothing to type into a fake page, because the secret works only for the real site. They are both safer and easier, which is rare. Support for them is growing, and you should confirm current availability and recommended setup in the documentation.

Adaptive prompting

Asking for extra proof every time annoys customers. A smarter approach asks only when something looks unusual, such as a new device, a distant location, or odd behaviour. This balances safety with convenience, and is often called adaptive or risk-based multi-factor authentication. Availability depends on your plan.

flowchart TD
    SI["Customer signs in"] --> RK{"Looks risky
or unusual?"}
    RK -->|"no"| EZ["Let in smoothly"]
    RK -->|"yes"| MF["Ask for extra proof"]
    MF --> OK{"Proof valid?"}
    OK -->|"yes"| EZ
    OK -->|"no"| BL["Block and record"]
    

Figure 10 explains the balance. Most sign-ins pass smoothly. Unusual ones face a challenge. Failures are blocked and logged. Customers feel little friction while attackers meet resistance.

Recovery when a factor is lost

Customers lose phones, change numbers, and forget which device they enrolled. A recovery plan is therefore as important as the factor itself. Offer more than one enrolled method, provide backup codes that customers can store safely, and design a support path that verifies identity carefully. If recovery is too easy, attackers use it as a side door; if it is too hard, loyal customers are locked out for good.

Every customer has a profile. Deciding what goes in it, and where, is a design choice with lasting effects.

A user record holds the basics: identifiers, email, name, when they last signed in, and which connection they used. It also lets you store extra information about the person, usually called metadata. Metadata comes in two flavours that differ in who may change them. Information the customer may edit about themselves sits in one place. Information that only trusted parts of your system should control, such as a subscription level or an internal flag, sits in another.

What belongs in the profile

• Identity facts: email, name, picture, verified status.
• Preferences: language, theme, notification choices.
• Permissions-related facts: roles or plan level, set by trusted systems only.
• Little else: avoid turning the identity record into a general customer database.

Keep the profile lean

It is tempting to store everything about a customer in the identity record, since it is close at hand. Resist. Large, constantly changing data slows things down and creates privacy duties. Keep rich business data in your own systems and link it to the identity record by its identifier. The identity service should answer “who is this and what may they do”, not “what did they buy last year”.

Linking accounts

Customers often sign up with an email one day and use a social account the next, creating two records for one human. Account linking merges them so the person sees one history. Linking must be done carefully: automatically merging accounts based on an unverified email can let an attacker take over someone else’s account. Require proof that the person controls both accounts before merging.

Verified email matters

An email address is only meaningful if the person has proved they control it. Many decisions, such as password resets and account linking, depend on this. Make email verification part of your sign-up flow, and treat unverified addresses as unconfirmed claims rather than facts.

flowchart LR
    U["User record"] --> B["Basic facts
email, name, verified"]
    U --> UM["Customer-editable
preferences"]
    U --> AM["Trusted-only
plan, flags"]
    U --> L["Link to your own
business database"]
    

Figure 11 shows the recommended shape. The identity record stays small. Heavier business data lives in your own systems and is joined using a stable identifier.

When your customers are companies, you need a way to group people by the business they belong to.

Many products sell to businesses, whose employees then become users of your product. Each business wants its own members, its own sign-in rules, and its own administrators, while sharing the same underlying product. An organization is a grouping inside your tenant that represents one such business. It lets you manage members, roles, and sign-in options per business, rather than lumping everyone together.

What organizations enable

• Membership: know which people belong to which business.
• Per-business roles: a person can be an administrator in one business and an ordinary member in another.
• Per-business sign-in options: one business signs in with its corporate directory; another uses passwords.
• Invitations: business administrators invite their own colleagues.
• Branding per business: optional tailored sign-in pages.

The multi-tenant product problem

Products that serve many businesses face a classic challenge: keeping each business’s data and settings apart while running one product for all. Organizations give you the identity side of the answer: every token can say which business the person is acting for. Your product then uses that fact to show only that business’s data.

Self-service administration

As you add business customers, you cannot manually configure each one’s sign-in. Look for ways to let each business administrator set up their own corporate sign-in connection and invite their own people, within boundaries you set. This turns a bottleneck into a feature.

flowchart TD
    T["Your tenant"] --> O1["Organization:
Business A"]
    T --> O2["Organization:
Business B"]
    O1 --> M1["Members and roles A"]
    O2 --> M2["Members and roles B"]
    O1 --> S1["Business A sign-in:
corporate directory"]
    O2 --> S2["Business B sign-in:
passwords"]
    

Figure 12 shows two businesses side by side. They share your product and tenant but keep separate membership and rules. Adding a third is a matter of configuration, not building.

A bird’s-eye view of how the pieces fit together makes every later topic easier.

Picture the whole system as layers. At the top are your customers and the devices they use. Below them are your applications. Between your applications and your back-end sits the identity service, which handles sign-in and issues proof. Your back-end services trust that proof, and your own business data sits behind them. Supporting this are extension points, protective defences, and records of what happened.

flowchart TD
    CU["Customers and devices"] --> AP["Your applications"]
    AP --> IS["Identity service"]
    IS --> CN["Connections"]
    IS --> UL["Hosted login"]
    IS --> MF["Factors"]
    IS --> TK["Token issuing"]
    IS --> EX["Custom steps"]
    IS --> AT["Attack protection"]
    IS --> LG["Logs"]
    TK --> BE["Your back-end APIs"]
    BE --> DB["Your business data"]
    LG --> MON["Monitoring and alerts"]
    

Figure 13 gives the full picture. Notice that your back-end never handles passwords. It receives tokens from the identity service and checks them, which keeps the most sensitive work in one place designed for it.

Shared responsibility

Using a managed service does not mean all responsibility moves away. The provider keeps its platform secure, available, and up to date. You remain responsible for how you configure it, how you design your applications, how you protect your own back-end, and how you respond to events. Understanding where the line falls prevents the dangerous assumption that “the vendor handles security”.

Every business has its own rules. Extension points let you add them without waiting for the vendor.

Out-of-the-box behaviour never fits everyone. You might want to block sign-ups from certain domains, add a customer’s plan level to their tokens, notify another system when a new account appears, or demand extra proof for particular situations. Actions are small pieces of custom logic that run at defined moments in the journey. The service hosts and runs them, so you do not need your own server for these tasks.

Moments where custom steps can run

Use sparingly and carefully

Custom steps run in the middle of sign-in, so anything slow or broken in them directly affects customers. If a step calls another system and that system is slow, sign-in becomes slow. If a step fails, sign-in may fail. Keep steps short, avoid unnecessary outside calls, plan for failure, and test thoroughly. Treat each step as part of the front door, not as a side project.

Managing custom steps like any other change

Custom steps are logic, and logic needs the same care as any product feature: written deliberately, reviewed by a second person, tested in a non-production tenant, versioned, and rolled out gradually. Teams that treat them as quick tweaks in a dashboard often discover that nobody remembers why a rule exists, or what will break if it is removed.

flowchart LR
    ST["Sign-in begins"] --> A1["Custom step:
check rules"]
    A1 --> D{"Allowed?"}
    D -->|"no"| BL["Refuse politely"]
    D -->|"yes"| A2["Custom step:
add plan to token"]
    A2 --> TK["Tokens issued"]
    

Figure 14 shows two typical uses. The first step decides whether to continue. The second adds helpful facts to the tokens, so your product knows the customer’s plan without extra lookups.

Keeping custom steps small and focused

Give each custom step a single, clear purpose and a descriptive name. A step that adds the plan to a token should do only that. Small steps are easier to test, easier to explain, and easier to remove. Write a short note describing what each step does, who owns it, and what depends on it, so that future team members do not have to guess.

Public sign-in pages attract attackers constantly. Built-in defences handle the common attacks.

The moment your product has a public sign-in page, automated attackers find it. They try stolen username and password lists from other breaches, hoping customers reused credentials. They create thousands of fake accounts. They hammer password-reset forms. A good identity service includes defences against the common patterns, which you should understand and turn on.

Layers of defence

• Bot detection: distinguishes real people from automated programs, sometimes by asking suspicious visitors to complete a challenge.
• Breached password detection: warns or blocks when a customer uses a password found in known leaks.
• Brute-force protection: locks or slows an account after many failed attempts.
• Suspicious IP throttling: slows traffic from sources behaving abnormally.
• Notifications: tells customers when something unusual happened on their account.

Do not punish the innocent

Defences that are too aggressive lock out real customers, especially those sharing a network address, such as an office or a mobile carrier. Tune settings, watch for false positives, and provide an easy recovery path. A defence that angers customers has a real cost.

flowchart TD
    REQ["Sign-in attempt"] --> BT{"Looks like a bot?"}
    BT -->|"yes"| CH["Challenge or block"]
    BT -->|"no"| BP{"Password in known leaks?"}
    BP -->|"yes"| WR["Warn or require reset"]
    BP -->|"no"| BF{"Too many failures?"}
    BF -->|"yes"| LK["Slow or lock"]
    BF -->|"no"| PASS["Continue sign-in"]
    

Figure 15 shows layered inspection. Each layer catches a different kind of abuse, and honest customers pass through all of them without noticing.

Telling customers when something unusual happens

Customers appreciate being told. A short message saying that a new device signed in, or that a password was changed, lets them react quickly if it was not them. Provide a simple link to secure the account. These notices are cheap, build trust, and turn every customer into an extra sensor against takeover.

After sign-in, your product must decide what each person may do. Roles keep this manageable.

Authorization is the second half of access. A permission is a single allowed action, such as reading an invoice. A role is a named bundle of permissions, such as “billing manager”. People are assigned roles, and the roles carry the permissions. This is far easier to manage than assigning individual permissions to thousands of people.

How roles reach your product

When tokens are issued, they can include the person’s roles or permissions. Your back-end reads these from the verified token and decides what to allow. Because the token is signed, it cannot be forged. Because it is short-lived, a change in someone’s roles takes effect fairly soon.

Where decisions should live

A useful rule of thumb is to keep coarse decisions near identity and fine decisions near the data. “Is this person a billing manager?” is a coarse question suited to identity. “May this person view this particular invoice belonging to this particular department?” is fine-grained and depends on business data, so your product should decide it. Cramming complex business rules into the identity service makes it brittle.

Least privilege

Give each person only what they need. A new role should start with few permissions and gain more only when a real need appears. Review who holds powerful roles on a regular rhythm, and remove access that is no longer needed.

flowchart LR
    P1["Permission:
view invoice"] --> R["Role:
billing manager"]
    P2["Permission:
export report"] --> R
    P3["Permission:
update payment method"] --> R
    R --> U1["Person A"]
    R --> U2["Person B"]
    U1 --> TK["Token carries role"]
    TK --> API["API checks token"]
    

Figure 16 shows the chain from permission to decision. Management happens at the role level, which scales. Enforcement happens in your API, which reads the verified token.

Most teams already have customers. Moving them without forcing everyone to start over is its own craft.

If you have an existing user database, moving to a new identity service needs care. Customers expect to sign in tomorrow exactly as they did yesterday. Two main approaches exist, and many teams combine them.

Choosing between them

• Bulk is quick but depends on whether protected password data can move across.
• Gradual is smooth for customers, but takes longer, and the old system must stay available during the transition.
• Inactive users never migrate under the gradual approach, so decide in advance what to do with them.

Plan the cut-over

Test with a small group first. Prepare clear communications. Have a rollback plan. Watch error rates and support requests closely in the first days. Keep the old system in a read-only state for a while so you can compare records if disputes arise.

sequenceDiagram
    participant C as Customer
    participant N as New identity service
    participant O as Old user database
    C->>N: Sign in with existing credentials
    N->>O: Check credentials
    O->>N: Valid
    N->>N: Create the customer record
    N->>C: Signed in, no reset needed
    

Figure 17 shows why customers barely notice. They type the same credentials, the new service checks the old one in the background, and the customer is quietly moved over.

A sensible order of work saves you from rework later.

Common early traps

• Building in production because it was “just a quick test”.
• Forgetting to configure the return addresses for each environment.
• Leaving default email templates and senders unbranded, which looks untrustworthy.
• Using a shared mailbox sender that lands in spam folders.
• Skipping a custom domain until after customers have seen the default address.

Email deliverability

Sign-up verification and reset emails are part of your front door. If they land in spam, customers cannot finish signing up. Configure a proper sending service and authenticate your sending domain according to current email standards, so that mailbox providers trust your messages. Test with several mailbox providers.

flowchart LR
    N["Needs"] --> T["Tenants"]
    T --> A["Applications"]
    A --> C["Connections"]
    C --> B["Branding"]
    B --> P["Protection"]
    P --> X["Roles and steps"]
    X --> M["Monitoring"]
    M --> L["Pilot and launch"]
    

Figure 18 summarizes the roadmap. Each stage builds on the previous one, and skipping ahead usually leads to rework.

Three short stories show the pieces working together.

Example one: a first-time shopper

Priya visits an online clothing shop for the first time. She taps “Sign in with a social account”, approves a short request on her phone, and lands back on the shop, signed in. Behind the scenes, the shop’s application sent her to the hosted login page, which handed her to the social provider, which vouched for her, and returned a one-time code. The shop’s application traded the code for tokens, created a profile for her, and greeted her by name. A custom step noted that she was new and added a welcome-offer flag. She never typed a password, and the shop never saw one.

Example two: a suspicious midnight attempt

Later, someone tries to sign in to Priya’s account from a distant country using a password that is already known from an old, unrelated leak. Breached-password detection flags the password. The unusual location triggers an extra proof request, which the attacker cannot answer. The attempt is blocked, recorded in the logs, and Priya receives a notice that someone tried to get in. She changes her sign-in method to a passkey the next morning.

Example three: a business customer joins

A software company called Northwind Supplies signs up for a business edition of a product. Its administrator creates an organization, connects the company’s own corporate directory so employees sign in with work credentials, and invites colleagues. Each employee is automatically placed in the right role. Northwind’s data is separate from other businesses, because every token states which organization the person is acting for. When an employee leaves Northwind, removing them from the corporate directory ends their access to the product.

flowchart TD
    E1["Shopper
social sign-in"] --> R1["Smooth entry,
new profile created"]
    E2["Attacker
leaked password, odd location"] --> R2["Blocked, logged,
customer notified"]
    E3["Business customer
corporate directory"] --> R3["Organization created,
members onboarded"]
    

Figure 19 sums up the stories. Convenience, protection, and business-to-business features all run through one service, which keeps the product team’s attention on its real work.

Customer identity is a prime target. Treat configuration as part of your security posture.

A strong platform can be undermined by weak configuration. Many real-world breaches involve a misconfigured setting, an over-powered key, or an overlooked test environment, not a flaw in the underlying service. Review security as part of your regular routine.

Protect the administrators

• Strong sign-in for dashboard users: require multi-factor authentication for everyone with access to the management console.
• Few administrators: grant the highest roles to as few people as practical.
• Individual accounts: avoid sharing logins, so actions can be traced to a person.
• Prompt removal: remove access immediately when someone leaves or changes role.

Protect secrets and keys

Server-side applications and machine programs hold secrets that prove their identity. Keep these in a proper secrets store, never in documents, chat messages, or public code. Rotate them on a schedule and immediately after any suspected exposure. Give each application its own secret so that one leak does not expose all.

Validate tokens properly

Your back-end must check every token it receives: that it is genuinely signed by your tenant, that it has not expired, that it was meant for this particular API, and that it carries the permission needed for the action. A back-end that trusts any token it is shown is open to forgery.

Restrict return addresses

Each application has a list of addresses where customers may be sent after sign-in. Keep the list tight and exact. Wildcards or stale entries can let an attacker redirect customers, along with their codes or tokens, to a hostile site.

Privacy and data protection

Customer identity data is personal data. Collect only what you need, tell customers how it is used, honour deletion and access requests, and choose the tenant region with legal duties in mind. Involve your privacy and legal advisers early, because mistakes here are costly and public.

flowchart LR
    SEC["Security posture"] --> A1["Protect administrators"]
    SEC --> A2["Protect secrets"]
    SEC --> A3["Validate tokens"]
    SEC --> A4["Tight return addresses"]
    SEC --> A5["Privacy by design"]
    SEC --> A6["Monitor and respond"]
    

Figure 20 offers a checklist of areas. Review each on a regular rhythm, not only at launch, because configuration drifts over time.

Periodic security reviews

Put a security review on the calendar every quarter. Check who holds administrator roles, which applications and secrets exist, whether return address lists still make sense, what defences are enabled, and how recent incidents were handled. Write down findings and assign owners. A short, regular review catches drift long before it becomes an incident.

You cannot protect or improve what you cannot see. Logs are the camera footage of your front door.

The service records events: successful and failed sign-ins, sign-ups, password changes, blocked attempts, factor challenges, and configuration changes. These logs are available in the dashboard for a limited time, so for long-term analysis you should send them to a system you control, where you can search, chart, and alert.

What to watch

• Failed sign-in rates: sudden jumps may indicate an attack or a broken change.
• Sign-up volume: abnormal surges often mean bots.
• Blocked attempts: shows your defences working, or overworking.
• Multi-factor completion rates: low numbers signal friction.
• Reset email volume: high numbers may mean confusing forms or an attack.
• Configuration changes: who changed what, and when.
• Custom step errors and slowness: these directly affect sign-in.

Business metrics too

Identity data is also a window into your product’s health. How many visitors start sign-up and how many finish? Which sign-in method do people prefer? Where do they abandon? Treat these as product questions, not only security questions.

Alerts that mean something

Choose a few alerts that truly require action, with a named responder for each. An inbox full of ignored alerts is as bad as none at all. Review thresholds after every incident.

flowchart LR
    EV["Events in the service"] --> ST["Log stream"]
    ST --> SY["Your log system"]
    SY --> DS["Dashboards"]
    SY --> AL["Alerts"]
    AL --> OC["On-call responder"]
    DS --> RV["Regular review"]
    

Figure 21 shows the path from event to action. Logs leave the service, land in a place you control, and feed both live alerts and calm periodic reviews.

Sign-in has many paths. Test all of them before customers do.

Because sign-in has so many branches, such as new versus returning customers, different connections, factor choices, errors, and device types, testing must be systematic. Use your development and test tenants, create realistic test accounts, and walk through each path by hand and, where possible, with automated checks.

A test checklist

• New customer sign-up with each connection type.
• Returning customer sign-in on web and mobile.
• Forgotten password and reset email delivery.
• Enrolling and using each multi-factor option, including losing the device.
• Sign-out, including whether the customer is truly signed out everywhere intended.
• Expired tokens and quiet renewal.
• Blocked and suspicious attempts.
• Custom step failure: what does the customer see when a step breaks?
• Accessibility with keyboard only and with a screen reader.
• Different languages and screen sizes.

Load and spike testing

Customer traffic is unpredictable. A marketing email or a sale can multiply sign-ins within minutes. Plan for peaks, understand any rate limits that apply to your plan, and coordinate large events with the provider where appropriate. Never run heavy load tests against production without agreement.

Test the unhappy paths

Most testing proves that things work when everything goes right. The failures customers remember occur on unhappy paths: an email that never arrives, a code that expires, a phone that is lost. Test these deliberately and make sure the screens give clear next steps.

flowchart TD
    CH["Change prepared"] --> D1["Test in development tenant"]
    D1 --> D2["Test in staging tenant"]
    D2 --> PL["Small pilot in production"]
    PL --> FR["Full rollout"]
    FR --> WT["Watch logs closely"]
    

Figure 22 shows a cautious path. Each stage catches a different kind of problem, and the final watching period catches anything the earlier ones missed.

Technology works only when people own it. Decide early who does what.

Customer identity touches many teams: product, engineering, security, support, legal, and marketing. Without clear ownership, important tasks fall between chairs. Name an owner for each area, and set a regular rhythm of review.

Change management

Treat configuration changes like code changes. Record who requested a change, who approved it, when it was made, and why. Roll out in stages. Keep a written record of the intended settings, so that if someone accidentally changes one, the difference is noticed. Where possible, manage settings through repeatable, reviewed procedures rather than manual clicks.

Support readiness

The support team meets customer identity problems every day. Equip them with clear guides, safe recovery procedures that verify identity properly, and a quick route to the platform team. Attackers often target support staff with persuasive stories, so support rules for resetting access must be firm.

flowchart TD
    PT["Platform team"] --> CF["Configuration and standards"]
    PD["Product team"] --> UX["Experience and conversion"]
    SE["Security team"] --> DF["Defences and response"]
    SU["Support team"] --> CR["Customer recovery"]
    LG["Legal and privacy"] --> CO["Compliance"]
    CF --> GOAL["Reliable, safe, friendly front door"]
    UX --> GOAL
    DF --> GOAL
    CR --> GOAL
    CO --> GOAL
    

Figure 23 reminds us that the front door belongs to everyone. Shared goals, clear roles, and a steady review rhythm keep it in good order.

Planning for growth and change

Your audience will grow, your product will change, and the provider will release new features. Assign someone to follow the provider’s announcements, evaluate which new features help, and schedule changes sensibly. Review your setup once a year with fresh eyes, asking whether each customization still earns its place. Removing outdated rules is as valuable as adding new ones.

A managed customer identity service has real benefits and real costs. Weigh both honestly.

Key trade-offs

• Build versus buy: building gives control but costs time and ongoing security work. Buying saves effort but ties you to a vendor.
• Hosted versus embedded login: hosted pages are safer and simpler; fully embedded forms give more control but more responsibility.
• Security versus friction: every extra check reduces risk and may lose customers.
• Customization versus upgradeability: heavy customization can complicate later improvements.
• Rich profiles versus lean profiles: storing more convenience data increases privacy duties.

quadrantChart
    title Choices by effort and value
    x-axis Low effort --> High effort
    y-axis Low value --> High value
    quadrant-1 Plan carefully
    quadrant-2 Do first
    quadrant-3 Skip for now
    quadrant-4 Reconsider
    Hosted login: [0.2, 0.9]
    Bot detection: [0.25, 0.8]
    Multi-factor: [0.4, 0.85]
    Custom domain: [0.35, 0.7]
    Passkeys: [0.55, 0.8]
    Heavy login customization: [0.85, 0.4]
    

Figure 24 ranks sample decisions. Hosted login, protection, and multi-factor deliver much value for modest effort. Heavy customization of the login page costs the most and should earn its place.

Patterns are proven shapes of good practice. Each solves a recurring problem in customer identity.

flowchart LR
    DP1["Hosted login"] --> OUT["Safe, friendly,
maintainable front door"]
    DP2["Tenants per stage"] --> OUT
    DP3["Lean profile"] --> OUT
    DP4["Adaptive prompts"] --> OUT
    DP5["Organizations"] --> OUT
    DP6["Coarse roles in tokens"] --> OUT
    DP7["Streamed logs"] --> OUT
    

Figure 25 shows that the patterns reinforce each other. None requires heroic skill, but together they keep growth manageable.

These habits look sensible but cause trouble. Recognize them early.

flowchart TD
    A1["Forms in every app"] --> BAD["Fragile, risky front door"]
    A2["One tenant for all"] --> BAD
    A3["Secrets in public"] --> BAD
    A4["Overloaded profiles"] --> BAD
    A5["Auto-merging accounts"] --> BAD
    A6["Heavy custom steps"] --> BAD
    

Figure 26 gathers the habits to avoid. Compare your own setup against this list from time to time.

A short checklist of what to do and what to avoid.

Best practices

• Use the hosted login page and a custom domain from the start.
• Keep separate tenants for development, test, and production.
• Register each application and environment separately, with the correct type.
• Turn on bot detection, breached-password checks, and brute-force protection.
• Offer phishing-resistant options such as passkeys, and use adaptive prompts for extra proof.
• Verify email addresses and link accounts only with proof.
• Keep profiles lean and link to your own database.
• Validate every token fully in your back-end.
• Keep return address lists exact and tight.
• Protect administrators with strong sign-in and keep their number small.
• Stream logs to your own system and alert on the few signals that matter.
• Treat configuration changes as reviewed, recorded, staged changes.
• Confirm every plan-specific detail in the official documentation.

Common mistakes

• Testing only the happy path.
• Leaving default emails and senders unbranded or landing in spam.
• Choosing the wrong application type for a public app.
• Forgetting that signing out of the app may not sign out of the service.
• Making tokens carry too much information.
• Letting defences lock out honest customers without an easy recovery path.
• Ignoring customers who cannot use the common sign-in method, such as people without a smartphone.
• Launching without a plan for growth spikes.

flowchart LR
    PL["Plan"] --> BU["Build and configure"]
    BU --> TE["Test"]
    TE --> LA["Launch gradually"]
    LA --> MO["Monitor"]
    MO --> IM["Improve"]
    IM --> PL
    

Figure 27 reminds us that identity work never ends. Customers change, attackers change, and your product changes. A steady cycle keeps the front door in good shape.

Four fictional companies show the ideas in use. All names and details are invented for teaching.

flowchart LR
    M["Marigold
growth and bot defence"] --> LESSON["Common thread:
design the front door deliberately"]
    P["Pinewood
privacy and strong proof"] --> LESSON
    Q["Quillfeather
business customers"] --> LESSON
    T["Tidewater
careful migration"] --> LESSON
    

Figure 28 shows each company’s focus. Different needs produced different configurations, but all began with understanding their audience and risks.

Thirty short answers to questions beginners often ask. Always confirm specifics in the official documentation and your plan.

A good front door welcomes customers, stops attackers, and quietly scales. Customer identity is how you build it.

You began this guide knowing little about customer identity. You now understand its vocabulary, how tenants, applications, connections, and the hosted login fit together, how tokens and sessions carry proof, how multi-factor, passwordless, and passkeys raise safety, how organizations support business customers, and how custom steps, attack protection, roles, and logs complete the picture. You also know the patterns that help, the anti-patterns that hurt, and the operating habits that keep the system healthy.

Treat the work as a cycle of planning, building, testing, launching gradually, monitoring, and improving. Keep profiles lean, keep secrets safe, keep changes staged, and keep customers’ experience at the centre. Confirm every specific detail against the current official documentation and your plan, since names and limits change while the ideas stay steady.