Before learning the two protocols, it helps to see the problem they solve.

The old way: every app keeps its own passwords

In the early days of the web, every website had its own username and password box. If you used ten websites, you had ten accounts. Each website had to store passwords safely, reset them when forgotten, and defend against attackers. Many small websites did this badly, and stolen passwords became a daily headline.

Companies had the same pain. An employee might need email, a payroll tool, a ticket system, a chat app and a customer database. Each tool had separate logins. When a person left the company, someone had to remember to remove their access in every single tool. Forgetting even one tool left a door open.

What Okta does

Okta is an identity service. Identity simply means knowing who a person or a program is. Okta stores user accounts, checks passwords, asks for extra proof such as a phone approval, and then tells your applications the result. Applications stop keeping passwords. They ask Okta, and Okta answers.

For Okta to talk with thousands of different applications written in different languages by different teams, everyone must agree on a common way to ask and answer. That agreement is a standard. OpenID Connect and OAuth 2.0 are the most popular standards for this job.

OAuth 2.0 is about permission, not about proving who you are.

What it is

OAuth 2.0 is an open standard that lets one application receive limited permission to use something that belongs to a person, without ever learning that person’s password. The key word is delegation. You delegate a small, specific power to an app, and you can take it back later.

Before OAuth existed, a photo-printing website that wanted your pictures from another photo site would ask for your username and password there. That meant a stranger held the keys to your whole account. OAuth fixed this by introducing a middle step. You approve the request at the place where your account lives, and the printing website receives only a temporary pass that can touch your photos and nothing else.

Why it exists

OAuth 2.0 exists so that passwords stay in one safe place and apps receive narrow, short-lived, revocable passes. It was published as a standard in 2012 and is now used by almost every large internet service, from email providers to payment platforms to the products inside your company.

Where it is used

You see OAuth every time a screen says something like “this app wants to view your calendar” and offers Allow or Deny buttons. Inside companies, it is also used when one backend service needs to call another backend service with no human present.

OpenID Connect, often shortened to OIDC, sits on top of OAuth 2.0 and adds the missing piece: who the user is.

What it is

OpenID Connect is a thin identity layer built directly on OAuth 2.0. It reuses the same steps, the same endpoints and the same ideas, and then adds one new thing: a special token called the ID token. The ID token is a signed statement from the identity provider saying who just signed in, when they signed in, and how.

Because OIDC is built on OAuth 2.0, you do not choose one or the other. In practice, when an application says it uses OIDC with Okta, it is using OAuth 2.0 underneath and receiving an identity statement as a bonus.

Why it exists

Early developers tried to use plain OAuth for login by checking whether an access pass worked and assuming the person must be who they claimed. This was fragile and led to security mistakes, because an access pass was never meant to describe a person. The OpenID Foundation released OpenID Connect in 2014 to give everyone one clean, well-tested method for sign-in.

Where it is used

OIDC is behind the “Sign in with” buttons on websites, the single sign-on you use for work apps, and the login screens of mobile apps that never ask you to type a password into the app itself.

The two are close relatives, so a direct comparison removes most of the confusion.

Every OAuth and OIDC conversation has the same few actors. Learn them once and every diagram makes sense.

Tokens are the wristbands of this whole system. Each kind has a different job.

What does a token look like?

Okta issues ID tokens and most access tokens in a format called JSON Web Token, usually shortened to JWT and pronounced “jot”. A JWT has three parts separated by dots: a header describing how it was signed, a body holding the facts, and a signature. The signature is a digital seal made with Okta’s private key. Anyone can check the seal using Okta’s public key, but nobody can forge it.

How long do tokens live?

Access tokens and ID tokens are designed to be short-lived, commonly around an hour by default in Okta, and administrators can adjust this in policy. Short life limits the damage if a token is stolen. Refresh tokens last longer, and Okta lets administrators control their lifetime and how they behave when reused.

Two small words that explain what goes inside the tokens.

Scopes: what the app asks for

A scope is a named permission. When an application starts a sign-in, it lists the scopes it wants. The scope called openid is special: it tells Okta “I want OIDC, so please give me an ID token.” Other common OIDC scopes ask for profile details such as the name, the email address, and the phone number. Another well-known scope requests a refresh token so the session can continue quietly.

Scopes are the heart of the principle of least privilege. An app should ask only for what it truly needs. A weather widget has no business asking for permission to read your contacts.

Claims: the facts inside the token

A claim is a single fact that Okta states about the user or the token, such as the user’s unique identifier, their email, the time the token was issued, the time it expires, and the audience, meaning which app or API the token is meant for. Scopes decide which claims appear. If an app never asks for the email scope, the email claim stays out.

Keep claims small and purposeful

It is tempting to place every possible detail about a person inside a token, but tokens travel with every request, and larger tokens slow down networks and can even break limits in browsers and gateways. A healthier habit is to include only the facts an application truly needs to make a decision, and to fetch extra profile details from the UserInfo endpoint when they are required. This keeps tokens light, limits what leaks if a token is copied, and makes privacy reviews simpler because each claim has a clear reason to exist.

Another good habit is to treat claims as a snapshot. A group claim reflects membership at the moment the token was issued. If an administrator removes a person from a group a minute later, tokens already issued still carry the old claim until they expire. This is one more reason to prefer short token lifetimes for sensitive applications.

Inside Okta, tokens are minted by an authorization server. There are two kinds, and picking the right one matters.

The Org Authorization Server

Every Okta organization has a built-in authorization server called the org authorization server. It is meant for signing users in to applications with OIDC and for working with Okta’s own management APIs. The access tokens it produces are intended for Okta’s own services, so your custom APIs should not rely on them.

Custom Authorization Servers

For protecting your own APIs, Okta offers custom authorization servers. You can create several, each with its own address, its own scopes, its own claims and its own access policies. A default one often exists for convenience. Depending on your Okta plan, custom authorization servers may be part of an additional feature, so it is worth confirming with your administrator.

Okta will only talk to applications it knows. Registering your app is how you introduce it.

In the Okta Admin Console, an administrator creates an app integration and chooses OIDC as the sign-in method. Okta then asks what kind of application it is. This choice is important because it decides which safe flow is used.

The important settings

Who does what in a real team

Identity projects succeed when responsibilities are clear. Three groups usually share the work, and each looks at the same Okta setup from a different angle.

When these three talk early, most problems vanish before launch. A developer who knows the policy rules writes fewer broken requests, and an administrator who knows the app type chooses safer settings. Sharing a simple written checklist of app type, flow, redirects, scopes and token lifetimes for each application keeps everyone aligned and makes later audits much easier.

A flow is a recipe for getting tokens. Different apps need different recipes.

Choosing the right flow

flowchart TD
    A["What kind of client is it?"] --> B{"Is a human signing in?"}
    B -- "No" --> C["Client Credentials"]
    B -- "Yes" --> D{"Can it keep a secret safely?"}
    D -- "Yes, server side web app" --> E["Authorization Code, PKCE recommended"]
    D -- "No, browser or mobile app" --> F["Authorization Code with PKCE"]
    A --> G{"Device without a keyboard?"}
    G -- "Yes" --> H["Device Authorization"]
        

Let us follow one real sign-in from the first click to the first protected page.

sequenceDiagram
    participant U as User
    participant A as App
    participant O as Okta
    participant P as API
    U->>A: Click Sign In
    A->>A: Create one-time secret and its fingerprint
    A->>O: Send user to Okta with scopes and fingerprint
    O->>U: Show sign-in page and ask for MFA
    U->>O: Prove identity
    O->>A: Redirect back with a short-lived code
    A->>O: Swap code and original secret for tokens
    O->>A: ID token, access token, optional refresh token
    A->>P: Call API with access token
    P->>A: Protected data
        

What state and nonce are for

The state value is a random label the app attaches to the outgoing request and expects to see on the way back. If the label does not match, the response did not come from this sign-in attempt, and the app throws it away. This blocks a trick where an attacker pushes a forged response at a victim.

The nonce value is placed inside the ID token by Okta. The app compares it to the one it created. This stops an attacker from replaying an old, stolen ID token.

Okta publishes a small set of web addresses, each with a single clear job.

The discovery document

You do not have to memorize any of these addresses. Every OIDC provider, Okta included, publishes a discovery document at a standard location. It is a single page that lists every endpoint, the supported scopes, the supported flows and the signing methods. Most libraries need only the address of the issuer, and they read the discovery document themselves to configure everything else.

Validating tokens

An API receives an access token and must decide whether to trust it. It downloads Okta’s public keys once, remembers them, and checks the signature. It then confirms the issuer is the expected Okta address, the audience is itself, the token has not expired, and the required scopes are present. Because the check uses stored keys, the API does not call Okta for every request, which keeps things fast.

Identity systems are a favorite target for attackers, so these habits matter.

Where tokens should live

Browser apps should avoid leaving long-lived tokens in places that any script on the page can read. Mobile apps should place tokens in the secure storage the phone provides. Servers should keep tokens in memory or in protected stores and never print them in logs. A leaked access token works for whoever holds it until it expires.

A sign-in system you cannot observe is a system you cannot trust.

Okta records activity in its System Log. This is a searchable timeline of events such as sign-in attempts, failures, factor challenges, policy decisions and token activity. Administrators use it to answer questions like “who signed in to this app last night?” and “why did this sign-in fail?”

Here is how the ideas look in everyday company life.

No design is perfect. Knowing both sides helps you decide wisely.

These mistakes appear again and again in real projects. Learn to recognize them.

Helpful design patterns

Good patterns are the opposite of anti-patterns: habits that teams repeat because they work. These four appear often in healthy Okta projects.

Troubleshooting with calm steps

When sign-in fails, beginners often change many settings at once and make things worse. A calmer method is to read the error message first, because Okta’s messages are specific. Then check the most common causes in order.

Tokens are one half of the story. The other half is the session that Okta keeps for the person.

Two sessions, not one

When a person signs in through Okta, two separate things start. First, Okta creates its own session in the browser, which is a record that this person already proved who they are. Second, your application creates its own session, usually built from the tokens it received. These two sessions live independently, and they end at different moments.

This is exactly why single sign-on feels magical. When the person opens a second application, that application sends the browser to Okta. Okta notices its session is still alive, skips the password page, and sends the person straight back with fresh tokens. The user sees only a quick flicker of the address bar.

Why signing out is harder than signing in

Signing out of one application does not automatically end the Okta session, and ending the Okta session does not automatically end every application session. A careful design handles both. The application clears its own session and tokens, asks Okta to end the central session, and then returns the person to a safe page that was registered in advance.

Okta also lets administrators decide how long a session may stay idle and how long it may last in total. Sensitive environments choose short limits so a forgotten laptop does not become an open door.

Teams must decide where the username and password boxes will appear.

The redirect model

In the redirect model, your application sends the user to a sign-in page hosted by Okta. The user types credentials on Okta’s page, not yours. After success, Okta sends the browser back with a code. Because your application never sees the password, it carries less risk and less work. Okta also keeps the page up to date with new security features, such as new factor types, without any code change on your side.

The embedded model

In the embedded model, the sign-in form is placed inside your own application, using a widget or a software kit provided by Okta. This gives complete control over the look and feel, which some brands want strongly. The cost is that your team now carries more responsibility. Your pages handle sensitive input, and you must keep the embedded component updated.

flowchart LR
    A["User opens app"] --> B{"Where is the sign-in form?"}
    B -- "Okta hosted page" --> C["Browser redirected to Okta"]
    B -- "Embedded in app" --> D["App shows Okta widget"]
    C --> E["Okta checks user and issues code"]
    D --> E
    E --> F["App exchanges code for tokens"]
        

On a custom authorization server, administrators write the rules that decide who gets which token.

Policies and rules

A custom authorization server contains access policies. A policy is a container that applies to a chosen set of client applications. Inside each policy sit rules, and every rule answers a few questions: which grant types are allowed, which users or groups qualify, which scopes may be granted, and how long the resulting tokens will live. Okta evaluates policies in a priority order and applies the first match.

This design lets one authorization server serve many applications with different needs. A public mobile app might receive only basic scopes and short lifetimes. A trusted internal tool might receive broader scopes for staff in a particular group.

Looking after refresh tokens

A refresh token is powerful because it can keep producing new access tokens for a long time. If an attacker steals one, they could quietly maintain access. Okta offers refresh token rotation to reduce this risk. With rotation, every time an app uses a refresh token, Okta hands back a brand new one and retires the old one. If the old one appears again, Okta can treat it as a sign of theft and shut down the chain.

Let us tie everything together with one imaginary company, from planning to daily life.

A company called BrightCart sells groceries online. It has a customer website, a mobile app and an order API that stores purchases. The team wants customers to sign in once and place orders safely. Here is how they use Okta with OIDC and OAuth 2.0.

Notice how every concept from this guide appears in the story: roles, tokens, scopes, claims, authorization servers, flows, redirects, policies, refresh care and monitoring. Nothing here is exotic. It is a small number of ideas, applied carefully and repeated across every application.

Okta also offers SAML, so beginners often wonder when each one fits.

SAML is an older identity standard that passes information in XML documents called assertions. It became popular in large companies for web-based business tools, and many vendors still support it. OIDC arrived later, uses compact JSON tokens, and was designed with mobile apps, browser apps and APIs in mind. Okta supports both, and it is common to see them side by side inside one organization.

Short answers to the doubts beginners raise most often.

Not really. OIDC is built on OAuth 2.0, so choosing OIDC for an app integration gives you both. Add the openid scope to receive an ID token, and use other scopes to control API access.

No. The ID token tells the app who the user is. The access token tells an API what the app may do. Keep them separate and use each for its own purpose.

Because all of its code runs in the user’s browser, where any visitor could read a secret. PKCE gives such apps a safe one-time proof instead.

The API refuses it. The app then either uses a refresh token to ask Okta for a new access token quietly, or sends the user through sign-in again if no valid refresh token exists.

It is better not to. Separate integrations let you set separate redirects, scopes, policies and assignments, and they make audit trails clear.

SAML is an older standard that passes identity in XML documents and is common in enterprise web apps. OIDC is newer, lighter, uses JSON tokens, and fits mobile and single-page apps well. Okta supports both, and many companies run them side by side.

A signature proves the token is genuine and unchanged, not that it is secret. Anyone who steals a valid token can use it until it expires, so protect and shorten it.

Administrators manage app integrations in the Applications area of the Admin Console, and authorization servers and their scopes, claims and policies in the security section for API settings. Menu names can change between Okta releases, so check the current Okta documentation for exact locations.

We started at a music festival with a careful guard and colored wristbands, and we ended with a complete picture of how Okta uses OAuth 2.0 and OpenID Connect. OAuth 2.0 decides what an app is allowed to do. OpenID Connect proves who the user is. Okta acts as the trusted guard that checks people, applies your rules and issues short-lived tokens that apps and APIs can verify on their own.

Once you understand the roles, the three tokens, scopes and claims, and the safe flows, the Okta Admin Console stops looking like a wall of settings and starts looking like a set of sensible choices. Pick the right app type, register exact redirects, prefer the code flow with PKCE, keep tokens short-lived and private, and watch the logs. Do these things and you will have a solid, beginner-proof foundation.