OAuth (Open Authorization)?

OAuth is an authorization framework. Recent version: 2.0
Allows user's authorization to third-party application without sharing their password
User receives an access token from an Authorization Server and Service presents this token to a Resource Server to access the resource.

OAuth: For Authorization
Okta(Company using OAuth): For Authentication

Simple Authentication Example — Office Laptop SSO

- You open the browser(jira.compamy.com). IP is resolved using DNS
- HTTP GET(without session cookie) reaches Jira origin server on cloud.
- On Okta login page, You enter your corporate username and password, then the MFA code from your authenticator app
- Okta(Company) validates(user,password,MFA) and sends you back to jira.company.com
- Okta provides authorization code. Browser exchanges that code with Jira to open session.
- We can open confluence.company.com in another tab, it uses same authorization code to access page. This is Single Sign-On (SSO).
Each corporate service (Jira, Confluence, Box, Slack) has its own OAuth Client registered in Okta. Below: DNS resolves jira.company.com, the browser hits the Jira Origin Server with no session, Okta handles login + MFA, then Jira serves content from its cloud. 

%%{init: {'themeVariables': {'fontSize': '11px'}, 'sequence': {'actorMargin': 30, 'messageMargin': 22, 'boxMargin': 8, 'useMaxWidth': false}}}%%
sequenceDiagram
    autonumber

    actor User
    participant Browser
    participant DNS as DNS Resolver

    box Jira Cloud (Atlassian)
        participant JiraClient as OAuth Client
(registered in Okta)
        participant JiraOrigin as Origin Server
jira.company.com
    end

    box Okta Cloud (Cloud 2)
        participant Okta as Okta
(Authorization Server / IdP)
    end

    User->>Browser: Open jira.company.com
    Browser->>DNS: Resolve jira.company.com
    DNS-->>Browser: A record → IP of Jira origin

    Browser->>JiraOrigin: GET / (no jira session cookie)

    JiraOrigin->>JiraClient: No valid session — start OAuth login
    JiraClient-->>Browser: 302 Redirect to Okta

    Note over Browser,Okta: Authorization Request (browser redirect)
    Browser->>Okta: GET /oauth2/v1/authorize?
response_type=code
&client_id=jira-client-id
&redirect_uri=https://jira.company.com/callback
&scope=openid profile email
&state=xyz789

    Okta-->>Browser: 200 HTML Login Page
    User->>Browser: Enter username + password
    Browser->>Okta: POST /login (username, password)
    Okta-->>Browser: 200 MFA challenge page
    User->>Browser: Enter MFA code from authenticator app
(or tap Approve on push notification)
    Browser->>Okta: POST /mfa/verify (OTP or push approval)

    Okta->>Okta: Authenticate user
Create Okta SSO session cookie
Unique String=ssssss

    Okta-->>Browser: Session Cookie=ssss(expiry ~3-4 hour)
    Note over Browser: OKTA Session Cookie set in Browser
So other Okta apps(Eg: Box.com) skip re-login (SSO)

    Note over JiraOrigin: redirect to
Oauth Jira Client
    Okta-->>Browser: 302 Redirect
Location: https://jira.company.com/callback?
Authorization code for JIRA=aaaaaaa(expiry ~1min)
&state=xyz789

    Browser->>JiraClient: GET /https://jira.company.com/callback?code=aaaaaaa&state=xyz789

    JiraClient->>Okta: POST /oauth2/v1/token

grant_type=authorization_code
&code=aaaaaaa
&redirect_uri=https://jira.company.com/callback

    Okta-->>JiraClient: 200 OK application/json
{
 "access_token": "xxx",
 "token_type": "Bearer",
 "expires_in": 3600,
 "scope": "openid profile email",
 "JWT_token": "iii",
 "refresh_token": "rrr"
}
 JWT_Token:{"email": "you@company.com",
"name": "Jane Doe",
"groups": ["engineering", "jira-users"],
"exp": 1721123456}

    JiraClient->>JiraClient: Validate JWT_Token (OIDC)
Extract email, name, groups
JWT_Token:{"email": "you@company.com",
"name": "Jane Doe",
"groups": ["engineering", "jira-users"]}
Create jira.company.com session cookie

    JiraClient-->>Browser: Set-Jira-Session-Cookie=jssssss
302 Redirect /jira/dashboard
    Note over Browser: Jira session Cookie set in Browser

    Browser->>JiraOrigin: GET /jira/dashboard
Cookie: JSESSIONID=jssssss
    JiraOrigin->>JiraOrigin: Validate session
Load boards, projects, tickets
    JiraOrigin-->>Browser: 200 OK HTML (Jira home page)
    Browser-->>User: Content served from jira.company.com origin

Flow Explained

1. User opens Jira https://jira.company.com Browser gets Jira's IP address. The browser connects to the Jira server.
2. Since session cookie is sent in request, Jira concludes: "This user is not logged into Jira."
3. Jira redirects the browser to Okta(Company) to authenticate(HTTP 302 Redirect)
4. user provides is Username Password MFA
5. Okta(Company) verifies and creates SSO Session cookie=sssssss, which is set in browser
6. Okta creates an short lived(~1 minutes) authorization code=aaaaa, which is sent to browser, browser uses same authroization code in HTTP GET to to Okta client. Okta client presents, same code(aaaaa) to Okta server in return of which okta server provides 3 tokens:
  a. Refresh token: lets Jira obtain new access tokens without asking the user to log in again
  b. Access token: allows Jira to call Okta APIs if needed
  c. ID Token/JWT token: information about the user (name, email, groups)
7. Jira reads the ID Token Jira verifies the ID Token and extracts information such as: User ID Email Name Groups This tells Jira exactly who has logged in. 

{"iss": "https://company.okta.com",
  "sub": "00u1abc...",
  "email": "you@company.com",
  "name": "Jane Doe",
  "groups": ["engineering", "jira-users"],
  "exp": 1721123456}

8. Jira now creates its own session cookie and stores session in its database or cache.
9. Jira sends its session cookie to the browser, which is used by it to on subsequent requests.

So the step "Validate ID Token — extract email, name, groups" happens on the Jira OAuth Client server after it receives the token response from Okta. It:

How the OAuth Access Token Is Used

Question Answer
Who generates the token? The Authorization Server (e.g. Okta, FortiAuthenticator) generates and signs the access token after the user consents and credentials are verified.
What is inside it? Usually a signed JWT containing claims such as iss (issuer = Okta URL), sub (user ID), aud (intended API audience), exp (expiry), scope (granted permissions, e.g. read:jira-work), and optionally custom claims (groups, tenant ID).
How is it sent? In the HTTP Authorization header: Authorization: Bearer <access_token>
Is it an "authentication token"? The access token proves authorization to call an API. For login identity, OIDC's ID Token is the authentication token — the app validates it to know who logged in.
Who validates it? The Resource Server (API) validates signature, expiry, audience, and scopes — either locally using the IdP's public keys (JWKS) or via Okta's /introspect endpoint.

Example token response (generated by Okta)

{
  "token_type": "Bearer",
  "expires_in": 3600,
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "scope": "openid profile email read:jira-work",
  "id_token": "eyJhbGciOiJSUzI1NiIs...",
  "refresh_token": "eyJhbGciOiJSUzI1NiIs..."
}

Example API request — Jira calls Atlassian API with the access token 

GET /rest/api/3/issue/PROJ-101 HTTP/1.1
Host: jira.company.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Accept: application/json

Standard OAuth 2.0 / OIDC Terms

Term Meaning Correct?
Resource Owner The user who owns the data (e.g. the employee) Standard RFC term
Client The application requesting access (web app, mobile app, service) Standard RFC term
Authorization Server Issues tokens after authenticating the user (Okta, FortiAuthenticator) Standard RFC term
Resource Server The API that accepts access tokens and returns protected data Standard RFC term
Relying Party (RP) OIDC term for the app that relies on the IdP for login — same role as OAuth Client OIDC term; valid but vendor docs sometimes use it differently
Client ID Public identifier for the registered OAuth client Correct
Client Secret Confidential credential for server-side clients only; never exposed in browser Correct
Redirect URI Pre-registered callback URL where the Authorization Server sends the user after login Correct
Scope Space-separated list of permissions requested (e.g. openid email read:jira-work) Correct
Claims Name/value pairs about the user or token (email, groups, sub) Correct (OIDC)
Access Token Short-lived credential for API access Correct
Refresh Token Long-lived token used to obtain new access tokens without re-login Correct