Authentication asks “who are you?” Authorization asks “what may you do?”

Authentication is the act of proving identity. When you type a password, tap a prompt on your phone, or touch a security key, you are authenticating. The system is trying to become confident that you are the person you claim to be. It is often shortened to AuthN.

Authorization is the act of deciding permissions. After the system knows who you are, it checks what you are allowed to see, change, or delete. A manager may approve expenses while a new intern may only view them. The same person, once identified, receives different rights depending on rules. It is often shortened to AuthZ.

The order always matters

Authentication comes first, and authorization comes second. A system cannot decide what you may do until it knows who you are. This is why the two are often mentioned together, and also why they are so easily confused. But they are separate steps, answered by separate parts of the system, often at separate times.

Confusing the two leads to real design bugs and real security holes.

A sign-in is not a permission

Imagine a company dashboard. Everyone in the company can sign in, so everyone is authenticated. But only the finance team should see salary data. If the developers built the dashboard with the idea that “anyone who is signed in can see everything,” then a successful login quietly turns into unlimited access. This is a classic mistake. A login only proves identity. It says nothing about rights.

Two different error messages

The web has two well-known error codes that show the difference. The code 401 is officially named “Unauthorized,” but it really means “we do not know who you are, please authenticate.” The code 403 is named “Forbidden,” and it means “we know exactly who you are, and you are not allowed to do this.” The first is an authentication problem and the second is an authorization problem. Knowing which one you are seeing saves hours of debugging.

Different people own them

In many organisations, a security or identity team owns authentication: passwords, multi-factor checks, and sign-in rules. Application teams or business owners often own authorization: who should be allowed to approve a payment or read a record. If the two ideas are mixed together, nobody is sure who is responsible for which decision.

Different lifetimes and different changes

A person’s identity changes rarely. Their permissions change often, for example when they switch teams or take on a new project. Keeping the two apart means you can change who can do what without touching how people sign in, and you can strengthen sign-in without rewriting every permission rule.

A short dictionary. Each term says what it is, why it exists, and gives a picture to remember it.

A map of the parts of Okta that handle sign-in and the parts that handle permissions.

Okta is built as a cloud service that runs for many customers at once. Requests first meet a load balancer and an API gateway at Okta’s edge, which spread traffic across many servers and apply limits. After that, the work splits. One set of components handles authentication: checking credentials, running multi-factor challenges, and applying sign-in policies. Another set handles authorization: deciding what tokens to issue, what scopes and claims to include, and what administrators may do.

flowchart LR
    U["User"] --> LB["Load Balancer and API Gateway at Okta Edge"]
    LB --> AUTHN["Authentication Service"]
    AUTHN --> UD[("Universal Directory")]
    AUTHN --> AUTHR["Authenticators and MFA"]
    AUTHN --> POL["Sign-in Policies"]
    AUTHN --> SESS[("Session Store")]
    LB --> AS["Authorization Servers"]
    AS --> SC["Scopes Claims and Access Policies"]
    AS --> UD
    ADM["Admin Roles and Resource Sets"] --> UD
    AUTHN --> LOG["System Log"]
    AS --> LOG
    AUTHN --> APP1["SAML and OIDC Apps"]
    AS --> APP2["Client Apps and APIs"]

The shared foundation

Both halves lean on Universal Directory, Okta’s store of people, groups, and attributes. For authentication it answers “does this person exist and are they active?” For authorization it answers “which groups does this person belong to, and what facts describe them?” This is a useful reminder that the directory is shared, but the decisions made from it are different.

Two engines, same ideas

Okta has two generations of its sign-in system, often called the Classic Engine and the Identity Engine. Screen names and some policy types differ between them, but the ideas in this guide apply to both. Always check which engine your Okta organisation uses before following step-by-step instructions, since menu names may not match exactly.

Passwords, phone prompts, security keys, and the idea of factors.

Security experts group proofs of identity into three families, called factors. Using proofs from more than one family is what makes sign-in strong.

The authenticators Okta supports

• Password: the classic secret. Okta can enforce length, complexity, age, and history rules through password policies.
• Okta Verify: Okta’s own app on a phone or computer. It can send a push prompt, produce one-time codes, and support passwordless sign-in. A number challenge asks the person to choose the matching number shown on screen, which helps defeat accidental approvals.
• Okta FastPass: a passwordless way to sign in through Okta Verify that uses a key held on the device, together with checks on the device itself.
• Security keys and platform biometrics: standards-based methods, known as WebAuthn or FIDO2, that bind a sign-in to the real website and so resist phishing very well.
• One-time codes from other authenticator apps: the six-digit codes that change every thirty seconds or so.
• Email, text message, and voice codes: convenient but weaker, because messages can be intercepted or redirected. They are best kept for recovery or low-risk cases.
• Security questions: old, guessable, and best avoided for anything important.

Strong, weaker, and phishing-resistant

Not all authenticators are equally safe. A text message code can be stolen by tricking a phone company or by a fake website that asks for it in real time. Security keys and device-bound passwordless methods are phishing-resistant, because the secret never leaves the device and will only answer to the genuine site. For sensitive access, prefer the strongest options.

Rules that decide how much proof is needed, and when.

Okta does not ask everyone for the same proof every time. It follows policies. These are rules that look at the situation and decide how strict to be. In general, two layers are involved.

Two layers of policy

• Global session policy: controls signing in to Okta itself. It decides whether a person may start an Okta session, how long the session lasts, and what proof is needed to begin it.
• Application sign-in policy: controls access to each particular app. Even after a person has an Okta session, a sensitive app can demand extra proof. This is where step-up happens.

What a policy rule can look at

Rules are checked in order

A policy contains several rules, checked from top to bottom. The first rule whose conditions match is the one that applies. At the bottom sits a catch-all rule that covers every request no earlier rule matched. Because this last rule applies to everything else, it deserves careful attention. A catch-all that is too relaxed can quietly let in people you never intended to allow.

flowchart TD
    S["Sign-in request arrives"] --> G{"Global session policy allows sign-in?"}
    G -- No --> D1["Deny"]
    G -- Yes --> R{"App sign-in policy rule matches?"}
    R -- No --> C["Catch-all rule applies"]
    R -- Yes --> L{"Rule requires extra proof?"}
    C --> L
    L -- Yes --> F["Ask for authenticator such as Okta Verify"]
    L -- No --> A["Allow"]
    F --> V{"Proof passes?"}
    V -- Yes --> A
    V -- No --> D2["Deny"]

Step-up authentication

Step-up means asking for stronger proof only when it is needed. A person might sign in to the company portal with one factor from the office network. When they open the payroll app, the app’s policy asks for a stronger method, such as a security key. They are not burdened all day, yet the most sensitive door gets the most protection.

Why you are not asked to prove yourself again at every click.

Once a person passes authentication, Okta creates a session. It places a small piece of information, called a cookie, in the browser so that later requests are recognised. This is why opening a second app often feels instant: Okta sees the session and does not ask again. The app also keeps its own small session, so there are really two layers.

Controls on a session

• Maximum lifetime: the longest a session may last, even when the person is active.
• Idle timeout: how long a session may sit unused before it expires.
• Re-authentication: forcing a fresh proof of identity for sensitive apps after a chosen period.
• Persistence: whether the session survives closing the browser.

Shorter sessions are safer because stolen sessions stop working sooner, but they cost convenience. A good design uses a reasonable base session and asks for fresh proof on risky apps or risky actions.

Authorization is not one setting. It appears at several layers, each answering a slightly different question.

Many beginners search for a single “authorization switch” in Okta. There is none. Instead, authorization is spread across layers. Understanding which layer answers which question is the key to designing it well.

Layer 1: assigning apps through groups

The simplest form of authorization is deciding who gets which app. In Okta this is typically done by assigning a group to an app. When a person joins the group, they gain the app. When they leave, they lose it. Combined with group rules that place people in groups based on attributes such as department, access follows the person’s role without manual tickets.

Layer 2: roles and attributes sent to apps

Many apps have their own roles, such as viewer, editor, and admin. Okta can send a person’s group names or a role attribute to the app when they sign in. For SAML apps these facts travel in attribute statements. For OIDC apps they travel as claims in tokens. The app reads them and sets the person’s rights. This is a powerful pattern: Okta stays the single place where group membership is managed, while each app keeps control over what its own roles mean.

Layer 3: OAuth 2.0 authorization servers

When an app needs to call an API on behalf of a person, or when one service calls another, Okta acts as an OAuth 2.0 authorization server. The next chapters explain this layer in depth, because it is the part most likely to be misunderstood.

Layer 4: who administers Okta

Administrators also need authorization. A help desk worker should be able to reset a password but not delete applications. Okta provides standard administrator roles and custom roles, and chapter eleven describes them.

The two standards that carry authentication and authorization between apps.

OpenID Connect: telling the app who you are

When an app wants to know who signed in, it uses OpenID Connect. Okta returns an ID token, a signed note that names the person and says when and how they signed in. The app reads the ID token and starts its own session for that person. The ID token is meant for the app itself. It is not a pass to give to other services.

OAuth 2.0: letting an app act with limited rights

OAuth 2.0 solves a different problem. Suppose a calendar app wants to read your contacts. You do not want to hand it your password. Instead, you approve a limited permission, and the app receives an access token that is good only for that purpose, for a short time. The access token is meant for the API. The API checks it and decides what to allow.

The most common sign-in flow

For web and mobile apps, the recommended pattern is the authorization code flow with PKCE. PKCE, pronounced “pixie,” adds a one-time secret so that a stolen code is useless to a thief. The journey looks like this.

sequenceDiagram
    participant U as User Browser
    participant C as Client App
    participant O as Okta Authorization Server
    participant R as Resource API
    U->>C: 1. Open the app
    C-->>U: 2. Redirect to Okta with scopes and a PKCE challenge
    U->>O: 3. Follow the redirect
    O->>O: 4. Authenticate the user using sign-in policy
    O-->>U: 5. Redirect back with a one-time code
    U->>C: 6. Deliver the code to the app
    C->>O: 7. Exchange code and PKCE verifier for tokens
    O-->>C: 8. ID token and access token
    C->>R: 9. Call the API with the access token
    R->>R: 10. Validate token, scopes and audience
    R-->>C: 11. Return data or 403 Forbidden

Apps without a human

Sometimes there is no person at all. A back-end service may need to call another service on a schedule. For this, OAuth offers the client credentials flow, in which the service proves its own identity using its own secret or key and receives an access token for what it is allowed to do. Here authentication is of a machine, and authorization is still decided by scopes and policies.

The controls Okta gives you to decide exactly what a token allows.

Two kinds of authorization server

• Org authorization server: built into every Okta organisation. It is used for signing people in to Okta-related apps and for calling Okta’s own management APIs.
• Custom authorization servers: ones you create, usually to protect your own APIs. Each has its own address, scopes, claims, and access policies, so different APIs can have different rules. Okta provides a default custom server to get started.

Using a custom server for your own APIs is generally recommended, because it gives you control over token content and lifetimes.

Scopes

A scope is a named permission that an app can request, such as reading a profile or reading orders. When a token is issued, it lists the scopes that were granted. An API reads the scopes in the token and allows only matching actions. Scopes should be small and specific, so that an app receives only what it truly needs. This idea is called least privilege.

Claims

A claim is a fact placed inside a token. Okta can add standard claims, such as the person’s email, and custom claims, such as department or a list of groups. Claim values can be built from profile attributes using Okta Expression Language. Claims let an API make decisions without calling back to Okta every time. But they also mean token size and privacy need thought. A token should carry only the facts that are really needed.

Access policies and rules

Each custom authorization server has access policies. A policy applies to certain apps, and it contains rules. A rule says, for example, “for people in the Finance group, using this kind of flow, grant these scopes, and issue access tokens that last this long.” If no rule matches, no token is issued. This is where authorization in Okta becomes truly detailed: who may receive which scopes, for which app, and for how long.

How the API verifies a token

The receiving API should never trust a token blindly. It checks that the signature is valid using Okta’s published public keys, that the issuer is the expected authorization server, that the audience names this API, that the token has not expired, and that the needed scope is present. Many teams use a well-maintained library for this instead of writing their own checks.

flowchart TD
    Q["Request reaches an API"] --> T{"Valid token present?"}
    T -- No --> E1["401 Unauthorized, meaning not authenticated"]
    T -- Yes --> S{"Token has the needed scope and role?"}
    S -- No --> E2["403 Forbidden, meaning not authorised"]
    S -- Yes --> OK["200 OK, return the data"]

Authorization also applies to the people who manage Okta.

The people who run Okta can change who gets in and what they can reach. That makes administrator permissions some of the most sensitive in the whole organisation. Okta lets you give each administrator only the powers they need.

Custom roles and resource sets

Standard roles are broad. For tighter control, Okta supports custom administrator roles, where you choose exactly which actions are allowed, and resource sets, which limit those actions to chosen groups, users, or apps. For example, a regional help desk lead can reset passwords only for people in their own region’s group. Pairing a custom role with a resource set is the best way to follow least privilege.

A summary table to keep beside your desk.

Follow a single working day to see authentication and authorization taking turns.

Take an example employee, Asha, who works in finance and uses a company reporting app. The app calls an internal API for numbers. Here is her morning in order.

This single story shows the pattern clearly. Authentication happened at the beginning and again for step-up. Authorization happened at app assignment, at token issue, and at the API. They alternate, but they are always separate decisions.

Centralising both ideas in Okta brings strong benefits and some responsibilities.

Thinking in trade-offs

The first trade is security against convenience. More prompts protect better, but too many prompts push people toward shortcuts. Step-up and risk-based rules aim for the middle: ask for more only when it matters. The second trade is central rules against local rules. Putting every permission in Okta gives uniform control but can make Okta full of app-specific detail. Putting every permission inside each app keeps Okta simple but loses a single view. A healthy balance keeps identity, groups, and coarse scopes in Okta, and fine business rules inside the apps and APIs that understand them.

What attackers try against each half, and how to defend.

Threats against authentication

Threats against authorization

Defences that matter most

• Phishing-resistant authentication for administrators and for sensitive apps.
• Least privilege everywhere: small scopes, narrow roles, and group-based access that follows the real job.
• Strict token validation in every API: signature, issuer, audience, expiry, and scope.
• Short token lifetimes with refresh handled carefully.
• Controlled sources of truth for attributes that drive access, so people cannot self-promote.
• Regular access reviews to remove unneeded group memberships and admin roles.
• Protected secrets for service apps, stored in a vault and rotated.

What to watch so you can see problems early on both sides.

Okta records events in its System Log. These records include sign-in successes and failures, multi-factor events, policy decisions, token issuance, group and role changes, and administrator actions. Teams can search them inside Okta, read them through an API, or stream them to external tools for storage and analysis.

Authentication signals to watch

• Bursts of failed sign-ins for one account or across many accounts
• Large numbers of push prompts to one person in a short time
• Sign-ins from unusual places or new devices, especially for administrators
• New authenticators being registered, which may mean a takeover in progress
• Factor resets and recovery requests that suddenly increase

Authorization signals to watch

• Changes to privileged groups or administrator roles, and who approved them
• New apps, new scopes, or new access policy rules on authorization servers
• Token requests that ask for unusual or very broad scopes
• Policy denials that spike for one app, which may show a broken rule or an attack
• Service apps suddenly calling from new places or at new volumes

Health metrics

Beyond security events, teams track sign-in success rate, average time to sign in, how often step-up is triggered, how many users are enrolled in strong authenticators, and how many are still using weak ones. Another useful number is how many people hold powerful roles and how long since those roles were last reviewed. Okta also limits how many API calls an organisation may make in a short time, so automated tools should be built to slow down and retry when asked.

Habits that keep the two ideas clean, and habits that blur them.

Patterns worth copying

Anti-patterns to avoid

A short checklist for running both halves well.

Best practices for authentication

• Require multi-factor authentication for everyone, and require phishing-resistant methods for administrators and sensitive apps.
• Offer passwordless options such as Okta FastPass or security keys, which are both safer and easier for people.
• Use network zones, device state, and risk signals to adjust how much proof is needed.
• Review every app sign-in policy, especially the catch-all rule at the bottom.
• Set sensible session lifetimes and idle timeouts, and force fresh sign-in for the most sensitive apps.
• Protect recovery paths as strongly as the sign-in itself.

Best practices for authorization

• Assign apps to groups, and fill groups with rules driven by trusted attributes.
• Master access-driving attributes in HR or another controlled source, and make them read-only for users.
• Use custom authorization servers for your own APIs, with narrow scopes and clear access policies.
• Put only needed claims in tokens, and keep token lifetimes short.
• Make every API validate tokens fully, and enforce business rules on its own side.
• Use custom administrator roles and resource sets so each admin holds only the needed powers.
• Run regular access reviews to remove stale group memberships and roles.

Common mistakes

Four illustrative situations that show the two ideas working together.

The scenarios below are illustrative examples built from common patterns, not accounts of any one named customer.

Quick answers to the questions people ask most.

The whole story of the two ideas in one place.

Authentication and authorization are two separate decisions that happen in order. Authentication proves identity, and authorization decides permission. Okta handles authentication through authenticators, sign-in policies, and sessions. It handles authorization through app assignments, groups, information sent to apps, OAuth 2.0 authorization servers with scopes, claims, and access policies, and administrator roles. When these are designed separately and checked carefully at every layer, systems become both safer and easier to change.