The Token’s Route: From Auth0 Login to API Authorization
See how an Auth0 login becomes an API decision: redirect the user, issue the right token, validate its claims, and apply audience, scope, and access policies.
Loading…
Topic
OIDC
15 posts about OIDC. Every summary links to the original.
- 15 posts
- 10 companies
- 1 explainer
See the idea
OIDC explainers
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Kube AuthKit: Unified Kubernetes and OpenShift auth in Python
Kube AuthKit is a lightweight Python library that unifies Kubernetes and OpenShift authentication behind a single API, eliminating conditional code paths across local, pod, notebook, and CI/CD environments. It supports four strategies—kubeconfig, in-cluster, OIDC, and OpenShift OAuth—auto-detected by an AuthFactory that probes environment variables and in-cluster markers in a defined order. The library handles token lifecycle transparently, with in-memory storage by default and optional OS keyring persistence for local development to avoid repeated logins. It provides two OIDC flows: device code for headless environments and authorization code with PKCE for interactive applications, both with automatic token refresh. Kube AuthKit returns a standard Kubernetes Python client ApiClient, ensuring full compatibility with the official library, and is actively maintained by the Open Data Hub community for OpenShift AI environments.
Introducing IdentiFlows.dev: A Visual Reference for Identity Flows
Developers often struggle to quickly find accurate sequence diagrams for OAuth 2.0 and OpenID Connect flows. IdentiFlows.dev is a new website that provides a visual reference for common identity protocols, organized into four categories. Each flow page includes an introduction explaining the flow’s purpose, a sequence diagram showing the full exchange, and a step-by-step breakdown of each stage, with an interactive mode to walk through the steps. The initial release covers eight flows, including OAuth 2.0 Authorization Code with PKCE, the recommended login flow for most modern apps, SAML 2.0 SP-Initiated SSO, DPoP-Bound Access Token requests, and OpenID Connect Discovery. The project is an early release with plans to add more flows like Client Credentials, Device Authorization, and WebAuthn, and the author invites feedback to guide development.
How to Carry User Identity Across Federated Kubernetes and AI Platforms
Federated data and AI platforms let users move among portals, datasets, notebooks, and assistants across clusters, but single sign-on alone does not carry trusted identity across control-plane and data-plane boundaries. The post presents a central identity gateway that owns platform sessions through OIDC, a shared session store, stateless data-plane gateways, and an identity-validation API. Regional gateways validate sessions through /gateway/userinfo, enforce local policy, and inject standardized identity headers instead of forwarding raw tokens or independently managing refresh and logout. This separates session ownership from request enforcement, supports consistent logout, and lets assistants pass delegated user identity to backend tools without broad service credentials. At NVIDIA, the approach reduced repeated login events by 55% across internal developer platforms spanning Kubernetes clusters in AWS and OCI, while establishing a foundation for unified platform shells and AI assistants.
Authenticating TeamCity Builds to External Services With OIDC
Static CI/CD credentials can leak through logs or artifacts, expose uncertainty over who copies them, and require rotation, so the article presents OIDC as an alternative for authenticating TeamCity builds. It explains the workload flow: an identity provider issues a signed JWT whose claims include validity, audience, and issuer, while the consuming service retrieves metadata and JWKS, verifies the signature, and checks those claims. The TeamCity OIDC JWT plugin makes the server an identity provider, supports RSA- or ECDSA-based signing, key rotation, configurable public issuer hosting, and extensions for HSMs or key-management services. After installation from JetBrains Marketplace, build configurations can issue tokens at startup or on demand, with default or fixed five-minute lifetimes, for direct presentation or token exchange with AWS, Google Cloud, and other OIDC services.
How to Make Your AI Agent Enterprise-Ready: Enabling Enterprise-Managed Authorization for Client Apps in Auth0
Auth0 is launching Early Access for Client App, or Requesting App, capabilities that support Cross App Access (XAA) for AI assistants, developer tools, and autonomous agents. In the Enterprise-Managed Authorization (EMA) model, an employee’s corporate SSO login can authorize access to external APIs or Model Context Protocol (MCP) servers through the IETF Identity Assertion Authorization Grant (ID-JAG) draft specification. Auth0’s Token Vault brokers the multi-hop exchange: it stores an upstream enterprise refresh token, retrieves a short-lived ID-JAG, exchanges it with the downstream Resource App, and returns a standard access token to the backend. Setup uses dashboard toggles and connection settings, followed by a standard /oauth/token federated exchange, while the API requires no XAA-specific changes. The release also describes audit logging, enterprise IdP policy control, OIN distribution, and caching downstream tokens because ID-JAG exchanges are rate-limited to 50% of the tier’s standard Auth API limit.
New in Together GPU Clusters: Reliability and control for production GPU clusters
Together GPU Clusters introduces changes for production training and inference workloads, addressing hardware failures, scheduler problems, and the limits of single-admin access. Platform health improvements include continuously running passive health checks, human-approved node repair recommendations, and Slurm-on-Kubernetes 2.0, which adds self-healing daemons, durable job accounting, descendant-process cleanup, and refreshed GPU state after reschedules. Operational controls include a cluster details view with health, utilization, events, configuration, and node actions, plus external OIDC, startup scripts, and an acceptance-test opt-out. Newly provisioned Slurm clusters use the latest stack by default, while existing managed clusters can be migrated during a maintenance window at no cost; the stated result is faster recovery, fewer support tickets, and greater visibility and control for growing teams running large clusters.
How to Build and List Secure Cross App Access (XAA) Connections on Okta Integration Network (OIN)
Cross App Access (XAA) provides an identity framework for securing token-based communication when software or AI agents access external ecosystems through trusted identity providers. It replaces long-lived API keys and hardcoded secrets with real-time identity propagation, while allowing enterprises to control connected apps, requested scopes, and user access. The guide explains prerequisites for requesting and resource apps, including OIDC or SAML SSO, authorization-server support, protected resources, scopes, an Okta Integrator Free Plan org, and tested workflows. It then describes token exchange testing: requesting apps obtain an ID token and mint an ID-JAG, while resource apps validate the ID-JAG and issue a scoped access token. To seek OIN listing and XAA enablement, applicants submit SSO integration details, metadata, testing evidence, and a questionnaire to Okta.
Enhance Security and Trust: New Session Metadata in Sign in with Google
Sign in with Google now provides verified applications with two OpenID Connect session metadata claims, auth_time and amr, in ID tokens. auth_time records the last successful Google authentication time, distinguishing session freshness from token issuance, while amr is a JSON array identifying authentication methods such as pwd, mfa, hwk, swk, tel, and sms. The claims are available across Android, iOS, and web client and server applications, and can support audit logging, step-up authentication based on session age, and authorization rules requiring stronger methods for sensitive operations. Verified applications request them through the standard OIDC claims parameter without significantly changing an existing Sign in with Google authentication flow.
Build Secure Agent-to-App Connections with Cross App Access (XAA) Using OIDC
The guide presents Cross App Access (XAA) as a protocol for secure agent-to-app and app-to-app access, giving enterprise IT centralized control over connections, policies, and accessed resources. It walks through an OIDC demonstration using Todo0 as the Resource App, Agent0 as the Requesting App, and Okta as the enterprise identity provider, covering app registration, trust establishment, token exchange, and API calls. The flow uses the OAuth 2.0 Identity Assertion Authorization Grant: Bob logs in once, Agent0 obtains an identity assertion, Okta exchanges it for a Todo0 access token, and Agent0 calls the protected API. The demonstrated result is an agent that can read pending tasks, add tasks, and mark tasks complete, with changes reflected in Todo0. The guide is marked out of date because its Admin Console instructions have been replaced by AI agent registration under Directory > AI Agents.
How to Build a Secure iOS App with MFA
This tutorial shows how to add secure authentication and backend authorization to an iOS app using Okta’s BrowserSignIn module from the Okta Swift SDK. It registers a native OIDC client with Authorization Code Flow and PKCE, configures redirect URIs and authorization-server policies, and recommends phishing-resistant MFA factors such as Okta Verify with biometrics and FIDO2 with WebAuthn. The implementation uses Swift Package Manager, an Okta.plist configuration file, a testable AuthService protocol, and SwiftUI views for login, token handling, user information, and authenticated state. It then demonstrates authorized API requests by attaching an access token to a URLRequest, calling a backend endpoint, decoding its response, and displaying a returned message, concluding that OAuth 2.0 and JWT validation provide integrated authorization verification.
It's Time to Evolve Authentication Security
Identity-based attacks and compromised credentials are driving a need for stronger authentication, while security requirements must be balanced against user friction and application sensitivity. The guidance recommends phishing-resistant factors, including smart cards, biometric-capable hardware, FIDO2 with WebAuthn, and Passkeys, while warning against security questions, SMS codes, email TOTP, and password antipatterns. It also advises using strong MFA as a backup, dynamic authentication policies and threat detection, and OAuth 2.1/OIDC through an identity provider, with step-up authentication to maintain assurances during a session. For application integration, the recommended approach is to redirect users to an Okta-hosted Sign-In Widget through vetted OIDC client libraries or Okta SDKs, reducing implementation errors in PKCE and token verification while supporting evolving standards.
Integrate Your Enterprise AI Tools with Cross App Access (XAA)
Enterprise AI tools increasingly use protocols such as Model Context Protocol (MCP) to request data and resources from work applications, creating identity and authorization challenges that ordinary app-to-app consent does not expose to enterprise administrators. Cross App Access (XAA) places the enterprise identity provider between the requesting application and resource application by combining OAuth Token Exchange (RFC 8693), JWT Profile for Authorization Grants (RFC 7523), and the Identity Assertion Authorization Grant profile. In the illustrated flow, a user signs in to Agent0, the IdP issues an ID token, and Agent0 exchanges it for an ID-JAG targeted at Todo0’s authorization server. Todo0 validates that assertion and returns its normal access token, enabling MCP requests without interactive consent while allowing enterprise policy checks. The design leaves access-token format and validation with the resource application, while refresh-token behavior remains to be defined to balance policy enforcement and session continuity.
Effortless enterprise authentication at Grab: Dex in action
Grab built Concedo to centralise access management, authentication, and authorisation across internal applications and external platforms. Its customised Google OAuth2.0-based mechanism created integration challenges with systems such as Databricks and Datadog, producing fragmented sign-on experiences and administrative overhead. To standardise identity, the team adopted OpenID Connect (OIDC) and used Dex, a federated OpenID Connect provider that aggregates identity providers and issues standardised OIDC tokens. Dex supports single sign-on, multiple identity providers, token delegation between trusted peer services, and a kill switch that can redirect traffic during an identity provider outage. The implementation separated application authentication concerns and established a single identity source, while a future phase will address fragmented authorisation through a unified model.
AWS without Access Keys
The post describes how Fly Machines can access AWS resources such as an S3 bucket without distributing long-lived AWS access keys. It uses OpenID Connect (OIDC): AWS IAM trusts Fly.io’s OIDC identity provider, a role grants narrowly scoped permissions, and the app receives the role ARN as an environment variable. At boot, Fly’s Rust init requests a machine-specific OIDC token through the /.fly/api Unix socket, writes it to /.fly/oidc_token, and sets AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_SESSION_NAME so the AWS SDK can call STS AssumeRoleWithWebIdentity. AWS verifies the token, issues short-lived credentials, and evaluates the role’s IAM policy before serving the requested object. The trust policy can constrain tokens by audience and subject, including an organization, Fly App, or machine; the same pattern can authenticate against other OIDC-compliant providers, although Azure and GCP lack equivalent init integration.
How to Implement a Secure Central Authentication Service in Six Steps
Shopify built Identity to reduce the overhead of managing separate staff accounts across multiple stores, where each Shop isolated user data and lacked single sign-on. The service uses OpenID Connect (OIDC) to centralize authentication while retaining destination-specific authorization, and it models legacy one-store accounts separately from Identity accounts that can access multiple destinations. Migration begins by synchronizing profile and security data, routing authentication through Identity, and prompting eligible users to verify email ownership, combine accounts, and provide required 2FA credentials. Single legacy accounts can be auto-upgraded without changing their UUID, while multi-account merges use a MergeSession and operations implemented with ActiveOperation; WebAuthn also supports physical security keys as a second factor. Finally, Shopify changed store signup and staff invitations to prevent new legacy accounts, reporting that more than 75% of active accounts had been upgraded or combined at the time of writing.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.