Relock with Okta
This article covers the Okta-specific part of a Relock integration.
This guide describes:
- The Okta console settings
- The AWS Application Load Balancer wiring
It is a companion to the Relock Integration Guide, which describes the architecture, the relay, and the NGINX/Lua deployment that are the same for every provider. Read that guide first — or alongside this one — and return here for the Okta specifics.
Replace
app.example.comthroughout with the domain your application is served from (the domain the Relock relay sits in front of).
What Relock needs from Okta. The relay derives its session anchor from the sub and auth_time claims in the access token the ALB injects. Okta exposes both by default, so no custom action or claim mapping is required — the two steps below are the whole configuration.
Step 1 — Application sign-in and sign-out URIs
In the Okta admin console: Applications → your application → General → LOGIN.
| Field | Value |
|---|---|
| Sign-in redirect URIs | https://app.example.com/oauth2/idpresponse |
| Sign-out redirect URIs | https://app.example.com |
The sign-out redirect is what lets termination cascade through Okta to the SSO session (see Q2 in the main guide). Without it, a terminated session can silently respawn on the next request.
Step 2 — Trusted origin
In Security → API → Trusted Origins → Add Origin, add:
- Origin URL:
https://app.example.com
This authorizes the browser origin for the OIDC redirect flow.
Step 3 — AWS Application Load Balancer
On the HTTPS (443) listener → Rules → Default rule, add an authenticate-oidc action ahead of the forward action (the mechanics are described in §5.2 of the main guide). Populate it with Okta's OIDC endpoints and the client credentials from your Okta application.
Pull the exact endpoint values from Okta's discovery document — https://<your-okta-domain>/oauth2/default/.well-known/openid-configuration (or the discovery document of the custom authorization server you use). The typical pattern:
| Field | Value |
|---|---|
| Issuer | https://<your-okta-domain>/oauth2/default |
| Authorization endpoint | https://<your-okta-domain>/oauth2/default/v1/authorize |
| Token endpoint | https://<your-okta-domain>/oauth2/default/v1/token |
| User info endpoint | https://<your-okta-domain>/oauth2/default/v1/userinfo |
| Client ID | from the Okta application |
| Client Secret | from the Okta application |
Do not add an
audienceextra parameter. Okta returns a decodable JWT access token by default, which is what the relay reads to derive the anchor. (This is the one field that differs from the Auth0 setup, where it is required.)
The ALB now sets its session cookie and injects x-amzn-oidc-accesstoken (plus x-amzn-oidc-data and x-amzn-oidc-identity) into requests reaching the NGINX target.
With Okta and the ALB configured, deploy the relay as described in the Relock Integration Guide → §5.2 The relay. No application code changes are required.
Check more resources
Relock for Fintech
A large US-based FinTech using Relock to close the post-authentication security gap for more than 5,000 employees.
Session Security Landscape 2026
Inaugural Relock session security research finds that 93% of leading SaaS applications are vulnerable to session attacks.
Integration Guide
Step-by-step guide on how Relock fits into your stack. It will get your team from "how does this work?" to a running integration, without guesswork.