# OIDC Published articles for OIDC. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Symfony 6.4.46 released DevFeed: [Symfony 6.4.46 released]() Original publisher: [Read original article]() Author: Fabien Potencier Published: 2026-09-15T07:08:49Z Content type: release Language: en Sources: [Symfony Blog]() Topics: [Symfony](), [Security](), [OpenID connect (OIDC)](), [Cache]() Tags: [bug](), [cache](), [oidc](), [release](), [security](), [symfony](), [upgrade](), [versioning]() ### AI overview Symfony 6.4.46 is released with security, bug, translation, and component updates across the framework, including changes to Messenger, Form, HttpFoundation, OIDC handling, Cache, and other components. ### Source excerpt Symfony 6.4.46 has just been released. Read the Symfony upgrade guide to learn more about upgrading Symfony and use the SymfonyInsight upgrade reports to detect the code you will need to change in your project. Tip... ## How to answer the identity questions on an enterprise security questionnaire DevFeed: [How to answer the identity questions on an enterprise security questionnaire]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-14T00:00:00Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [Security](), [Single sign-on (SSO)](), [Provisioning](), [OpenID connect (OIDC)](), [App]() Tags: [configuration](), [enterprise](), [how-to](), [identity](), [integration](), [oidc](), [okta](), [provisioning](), [saml](), [security](), [sign-in](), [sso]() ### AI overview A practical guide to answering identity-related questions in enterprise security questionnaires. It explains what reviewers are really assessing behind SAML single sign-on and SCIM provisioning questions, including implementation details such as per-organization configuration, certificate rotation, and reliable deprovisioning. ### Source excerpt Every line has a literal answer and a real question behind it. Here is what the buyer is actually checking, which answers you can buy, and the three you cannot fake. ## Set Up Cloud OIDC From the Pulumi CLI DevFeed: [Set Up Cloud OIDC From the Pulumi CLI]() Original publisher: [Read original article]() Author: Sean Yeh Published: 2026-09-11T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [OpenID connect (OIDC)](), [Command-line interface](), [AWS IAM](), [Cloud](), [AWS Identity and Access Management (IAM)](), [Azure](), [Google Cloud Platform (GCP)]() Tags: [automated](), [aws](), [azure](), [cli](), [cloud](), [configuration](), [docs](), [esc](), [google-cloud](), [how-to](), [iam](), [identity](), [oidc](), [openid-connect](), [product](), [pulumi](), [pulumi-cli](), [security](), [terminal](), [workflow]() ### AI overview This tutorial explains how to use the Pulumi CLI command pulumi env setup to configure Pulumi ESC as an OIDC provider for AWS, Azure, and Google Cloud. It covers interactive onboarding, non-interactive flags for scripts and agents, cloud credentials, account selection, access policies, and automatic creation of identity providers, IAM roles, policy attachments, and ESC environments. ### Source excerpt Pulumi ESC can act as an OpenID Connect (OIDC) provider for AWS, Azure, and Google Cloud, issuing short-lived, signed tokens that these clouds exchange for temporary credentials. This eliminates hard-coded credentials and improves your security posture. Last year, we introduced an onboarding flow in the Pulumi Cloud console that makes it super easy to configure OIDC for your cloud provider in a few guided steps. We're bringing Pulumi Cloud into the CLI so agents can use its capabilities directly from the terminal, without requiring a human to complete steps in the console. The new pulumi env setup command brings OIDC onboarding to that workflow, with interactive prompts for guided setup and non-interactive flags for scripts and agents. pulumi env setup - how it works Run the command with your desired cloud provider (aws, azure, gcp). For example: pulumi env setup aws The command then asks what it needs to configure your cloud, including your credentials, the accounts to configure, and the level of access. The questions differ per cloud. For AWS, it asks: How to authenticate to AWS. It uses the credentials you already have, or it signs you in with AWS SSO. Which accounts to configure. Which policy to attach to the OIDC role. Choose AdministratorAccess for Pulumi Deployments, ReadOnlyAccess for Pulumi Insights, or any other policy ARN. Then, it will print out the plan: About to configure OIDC for organization my-org: account 111111111111: create role pulumi-esc-oidc-622e86ea-319ba4c675bb3c00-role attach arn:aws:iam::aws:policy/AdministratorAccess create ESC environment my-org/aws-login/sandbox-account-env Proceed? [yes/no] After you confirm, the command creates the identity provider, the IAM role, and the policy attachment in each account. It then creates one ESC Environment per account, with the aws-login provider already configured. Non-interactive setup You can also run the command without interactive prompts by passing in the necessary flags. Each cloud has its ow ## Adding Google Login to a React App with Auth0 DevFeed: [Adding Google Login to a React App with Auth0]() Original publisher: [Read original article]() Author: Carla Urrea Stabile Published: 2026-09-11T00:00:00Z Content type: tutorial Language: en Sources: [Auth0 Blog]() Topics: [Auth0](), [React](), [SDK](), [OAuth](), [OpenID connect (OIDC)](), [Vite](), [web applications](), [Node.js]() Tags: [auth0](), [authentication](), [google](), [node-js](), [oauth](), [oidc](), [react](), [sdk](), [tutorial](), [vite](), [web-applications]() ### AI overview A step-by-step tutorial for adding Google login to a Vite-based React application with Auth0. It covers installing the Auth0 React SDK, creating and configuring an Auth0 application, setting callback, logout, and web-origin URLs, and preparing credentials for production Google authentication. ### Source excerpt Add Google login to a React app with Auth0. A step-by-step tutorial from installing the Auth0 React SDK to configuring your own production Google credentials. ## OIDC is a standard, identity providers are not DevFeed: [OIDC is a standard, identity providers are not]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-09T16:09:50Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [OpenID connect (OIDC)](), [interoperability](), [OAuth](), [JSON Web Tokens](), [Authentication]() Tags: [compatibility](), [interoperability](), [jwt](), [oauth](), [oidc](), [providers]() ### AI overview This article explains why generic OpenID Connect integrations often require provider-specific compatibility settings. It discusses differences in token-endpoint client authentication, including client secret basic, client secret POST, and private key JWT. ### Source excerpt Generic OIDC connections meet identity providers that read the same spec differently. Here are the per-connection compatibility settings we added, and why. ## How to Implement OIDC Back-Channel Logout DevFeed: [How to Implement OIDC Back-Channel Logout]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-08T00:00:00Z Content type: tutorial Language: en Sources: [WorkOS Blog]() Topics: [OpenID connect (OIDC)](), [Single sign-on (SSO)](), [JSON Web Tokens](), [App](), [Server]() Tags: [how-to](), [implement](), [jwt](), [oidc](), [server](), [sso](), [token](), [tokens]() ### AI overview This tutorial explains OIDC back-channel logout, including provider discovery, endpoint registration, form-encoded logout requests, and logout-token validation. It also describes how session-specific and user-wide logout work and notes limitations acknowledged by the specification. ### Source excerpt It is the one standard that can end a session your app already issued, it has been final since 2022, and almost nobody implements it. Here is the whole mechanism, the validation your endpoint owes, and the two limitations the spec admits to itself. ## Three identity vendors shipped the same agent access pattern in eight days DevFeed: [Three identity vendors shipped the same agent access pattern in eight days]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-04T16:24:43Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [Auth0](), [Authorization](), [MCP](), [OpenID connect (OIDC)](), [Single sign-on (SSO)](), [Model Context Protocol]() Tags: [anthropic-claude](), [api](), [auth0](), [authorization](), [cross-app-access](), [identity](), [mcp](), [oidc](), [okta](), [sso]() ### AI overview Okta, Auth0, and Descope shipped implementations of the Cross App Access agent-access pattern between August 24 and September 1. The pattern uses a Client ID Metadata Document to identify calling software and an ID-JAG token exchange to let an identity provider control application access. ### Source excerpt Okta, Auth0, and Descope all shipped Cross App Access between August 24 and September 1. The two-layer pattern underneath it outlasts whichever vendor wins. ## Announcing the Appwrite OAuth2 server: Turn your project into an identity provider DevFeed: [Announcing the Appwrite OAuth2 server: Turn your project into an identity provider]() Original publisher: [Read original article]() Author: Matej Bačo Published: 2026-09-04T00:00:00Z Content type: release Language: en Sources: [Appwrite Blog]() Topics: [Appwrite](), [OAuth 2.0](), [OpenID connect (OIDC)](), [Authorization](), [API](), [internal developer portal]() Tags: [announcements](), [api](), [authorization](), [developer-portal](), [github](), [oauth](), [oauth2](), [oidc](), [openid-connect](), [product](), [sdks]() ### AI overview Appwrite announces an OAuth2 server that lets projects act as OAuth 2.1 and OpenID Connect providers. Other applications can register as clients, obtain user-approved scoped access to APIs, and use standard authorization and token flows. ### Source excerpt Your Appwrite project can now act as an OAuth 2.1 and OpenID Connect provider, so other apps can offer Sign in with your product and request scoped access to your APIs. ## Meet the Symfony Core Team at the API Platform Conference 2026! DevFeed: [Meet the Symfony Core Team at the API Platform Conference 2026!]() Original publisher: [Read original article]() Author: Cécile HAMEREL Published: 2026-09-02T14:30:00Z Content type: news Language: en Sources: [Symfony Blog]() Topics: [API](), [Symfony](), [PHP](), [migration](), [Domain-driven design (DDD)](), [JSON Web Tokens](), [OAuth 2.0](), [OpenID connect (OIDC)](), [Model Context Protocol (MCP)]() Tags: [2026](), [ai-agents](), [api-platform](), [conference](), [event](), [mcp](), [migration](), [oauth2](), [oidc](), [php](), [symfony]() ### AI overview The API Platform Conference 2026 will take place in Lille, France, on September 17-18. The event will feature nearly 30 talks, including sessions by Symfony Core Team members on migration, API security, DDD, HTTP headers, FrankenPHP, AI agents, and MCP. ### Source excerpt The API Platform Conference, the international event dedicated to the API Platform framework and its ecosystem, will take place in two weeks in Lille, France, on September 17-18, 2026. Nearly 30 talks are scheduled, in both French and English, covering... ## OpenID Connect Authentication for MySQL, Now Fully Open Source DevFeed: [OpenID Connect Authentication for MySQL, Now Fully Open Source]() Original publisher: [Read original article]() Author: Michał Jankowski Published: 2026-09-02T08:56:26Z Content type: article Language: en Sources: [Blog - Percona]() Topics: [MySQL](), [OpenID connect (OIDC)](), [Authentication](), [JSON Web Tokens](), [OAuth](), [Open Source]() Tags: [authentication](), [jwks](), [jwt](), [mysql](), [oauth](), [oauth-2-0](), [oidc](), [open-source](), [openid-connect](), [percona](), [percona-server-for-mysql](), [percona-software](), [security]() ### AI overview Percona Server for MySQL includes an open-source OpenID Connect authentication plugin for specified 8.4 and 9.7 releases. The article explains how it authenticates users through standards-compliant identity providers and describes capabilities beyond the MySQL Enterprise plugin, including JWKS signing-key synchronization, group-to-role mapping, and proxy-user support. ### Source excerpt Percona Server for MySQL now ships with a fully open source OpenID Connect (OIDC) authentication plugin, available starting with Percona Server for MySQL 8.4.11-11 and 9.7.2-2 (not yet released as of this writing). It allows a MySQL account to authenticate against any standards-compliant Identity Provider (IdP) instead of relying on a locally stored password, closing ... Continued The post OpenID Connect Authentication for MySQL, Now Fully Open Source appeared first on Percona. ## Workload identity trust policies govern CI/CD access to production cloud resources DevFeed: [Workload identity trust policies govern CI/CD access to production cloud resources]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-02T00:00:00Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [OpenID connect (OIDC)](), [CI/CD](), [GitHub Actions](), [GitHub](), [Cloud](), [Amazon Web Services]() Tags: [aws](), [ci-cd](), [github](), [identity](), [oidc](), [policy](), [production](), [secrets](), [trust]() ### AI overview This article explains that workload identities used by service principals and CI/CD federation can evade human-focused access reviews. It argues that OIDC trust policies are the key boundary controlling which federated jobs can obtain short-lived cloud access tokens and reach production resources. ### Source excerpt Service principals and CI/CD federation skip the access reviews that catch humans. The OIDC trust policy string is what actually decides who reaches production. ## Keycloak 26.7.3 released DevFeed: [Keycloak 26.7.3 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-08-31T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Security](), [OpenID connect (OIDC)](), [JSON Web Tokens](), [LDAP](), [reCAPTCHA]() Tags: [2026](), [cve](), [idm](), [jwt](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [microsoft](), [oidc](), [openid-connect](), [recaptcha](), [release](), [saml](), [security](), [sso]() ### AI overview Keycloak 26.7.3 was released on August 31, 2026. The release includes security fixes addressing LDAP certificate verification, signed-JWT assertion policies, authorization controls, information disclosure, token exchange restrictions, OIDC response-parameter injection, and related issues. ### Source excerpt To download the release go to Keycloak downloads. Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Security fixes #50785 CVE-2026-35563: LDAP client implementation in version 2.1.7 does not verify if the server certificate matches the intended LDAP hostname ldap #50997 [CVE-2026-16093] Required signed-JWT assertion policy can be bypassed with unsigned assertion headers oidc #50998 [CVE-2026-16072] Organization managers can create managed members through stored registration links without manage-users organizations #51001 [CVE-2026-16108] Realm default-group reads disclose hidden groups under FGAP v2 admin/fine-grained-permissions #51002 [CVE-2026-16105] Missing per-role authorization on RoleContainerResource composite endpoints admin/rbac #51003 [CVE-2026-16089] Authorization codes can be retargeted to another client session oidc #51005 [CVE-2026-16104] Authenticator config surfaces expose raw reCAPTCHA secrets admin/fine-grained-permissions #51112 [CVE-2026-16106] Incorrect authorization in admin role-composite deletion allows delegated admin to remove privileged child roles admin/fine-grained-permissions #51142 [CVE-2026-17059] Information disclosure: GET /roles/{role}/users returns user PII without the per-user view filter admin/fine-grained-permissions #51279 [CVE-2026-18218] Client not-before revocation is ignored when realm not-before is older but nonzero oidc #51282 [CVE-2026-18215] Microsoft external access-token exchange bypasses configured tenant token-exchange #51283 [CVE-2026-18201] Generic identity-provider creation can bind brokers to organizations without manage-organizations organizations #51286 [CVE-2026-18209] Incomplete fix for redirect_uri OIDC response-parameter injection: forbidden-parameter check (commit 18832bca) inspects only the query string, not the URL fragment oidc #51287 [CVE-2026-18214] Google external access-token exchange bypasses hosted-domain restriction token-exchange #5137 ## 【kube-apiserver】Authentication：SA、Bearer、OIDC 边界 DevFeed: [【kube-apiserver】Authentication：SA、Bearer、OIDC 边界]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-28T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Authentication](), [Kubernetes](), [OpenID connect (OIDC)](), [JSON Web Tokens](), [authz]() Tags: [api](), [apiserver](), [authentication](), [authorization](), [bearer-token](), [distributed](), [jwt](), [k8s](), [kubernetes](), [oidc](), [serviceaccount](), [v1-30-3]() ### AI overview This Chinese-language tutorial explains the kube-apiserver authentication chain in Kubernetes v1.30.3. It distinguishes X.509 certificates, ServiceAccount tokens, static and bootstrap tokens, OIDC JWTs, webhook authentication, and anonymous requests, and separates authentication failures such as 401 from storage-layer failures such as 503 or 504. ### Source excerpt 钉 K8s v1.30.3 的认证链：X509、SA token（bound token）、Bearer、OIDC、Webhook token、匿名用户；ServiceAccount bound token 与 TokenRequest 语义；apiserver 认证 flags 边界；401 与存储层故障的分列；AuthZ 路径见第 11 篇。 ## 1Password product enhancements: Smarter autofill, phishing prevention, and more DevFeed: [1Password product enhancements: Smarter autofill, phishing prevention, and more]() Original publisher: [Read original article]() Author: info@1password.com (Elaine Atwell) Published: 2026-08-27T00:00:00Z Content type: article Language: en Sources: [Blog on 1Password Blog]() Topics: [1Password in the browser](), [passwords](), [Authentication](), [Passkeys](), [macOS](), [iOS](), [iphone](), [OpenID connect (OIDC)](), [migration](), [Software as a service]() Tags: [authentication](), [ios](), [iphone](), [macos](), [migration](), [news](), [oidc](), [passwords](), [product](), [saas](), [update]() ### AI overview This English developer article presents recent 1Password product enhancements focused on smoother credential management and sign-in. It covers universal sign-in for personal and business accounts, macOS autofill, native password generation and saving in iOS 26.2, an iOS autofill health check, and improvements related to data ownership and migration. ### Source excerpt At 1Password, we're constantly working to make life simpler and more secure for our users, from the biggest businesses to each individual who signs up for our password manager. Over the past few months, we've been rolling out a slew of updates designed to make a difference for customers, whether you're using us at home, at work, or (ideally) both. Here are some of the latest developments for you to explore. Upgrades to autofill and autosave One of the most immediate benefits of using 1Password in your daily life is a smooth experience of creating, saving, and inputting your credentials and logins. These updates help you get the most out of that experience, with fewer clicks, on the devices you already use. Universal sign-in for personal and business accounts Signing in just got simpler with a smarter, modern experience using a one-click prompt. Now in beta, 1Password seamlessly logs you into any site or service at the right moment using your desired authentication method (passwords, passkeys, social sign in, OIDC, SAML*). We remove all the extra steps so you sign in quickly and smoothly, while staying secure. *SAML is only available for business accounts that also have 1Password SaaS Manager. macOS autofill 1Password now works as a native Credential Provider on macOS, so your logins and passkeys easily fill right inside Safari and other desktop apps. Save and generate passwords in iOS 26.2 The password creation experience on iPhone and iPad should happen at the exact moment you need it, especially when you're signing up for a new account. With this update, 1Password shows up natively in Safari and other iOS-native apps so you can generate and save a strong password right in the account creation flow, without leaving what you're doing. This makes it easier to capture credentials when they're created and keeps account setup uninterrupted. Autofill health check for iOS The reliability of iOS autofill depends on a tangle of systems, and when there's a problem with one, ## Vercel Security Dashboard is now generally available DevFeed: [Vercel Security Dashboard is now generally available]() Original publisher: [Read original article]() Author: Jathin Singaraju Published: 2026-08-26T00:00:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [dashboards](), [Security](), [Vercel](), [Command-line interface](), [OpenID connect (OIDC)](), [Terminal](), [ci](), [CSV](), [JSON]() Tags: [ci](), [cli](), [coding-agents](), [documentation](), [git](), [json](), [oidc](), [report](), [scope](), [security](), [terminal](), [ui](), [vercel]() ### AI overview Vercel Security Dashboard is generally available on all plans. It centralizes security findings across accounts and projects, supports risk-ordered remediation and CSV export, and provides equivalent checks through the Vercel CLI. Agents can inspect findings, apply supported fixes, and re-check results, with JSON output available in CI and other non-interactive environments. ### Source excerpt The Vercel Security Dashboard is now generally available on all plans, giving you one place to see your security posture across every account and project. You can access the Security Dashboard in the UI or run vercel security check in the Vercel CLI. As teams grow and coding agents make it faster to spin up projects, small misconfigurations add up quietly. The Security Dashboard automatically flags issues like: Team members without 2FA Long-lived credentials that can be replaced with OIDC Public preview deployments Non-sensitive and stale environment variables The Security Dashboard UI Misconfigurations are ordered by risk with the most severe first, and each finding links to the settings that fix them. Findings that are just noise for your team can also be muted, and all results can be exported to a CSV file for triage or reporting. The Security Dashboard CLI You can also run the same checks in your terminal through the new Vercel CLI vercel security check command, allowing your agents to work through the findings for you. An agent using vercel security check --findings can read what failed, apply the fix and re-check to confirm. Fixes an agent can apply include: Turning on Git fork protection Marking an environment variable as sensitive Replacing a static credential with OIDC federation You can also scope the check to one project with --project when you want a narrow change set. In CI or any other non-interactive environment, the command writes the report to stdout as JSON automatically, giving agents structured output without extra flags. Get started by running your first scan from the Security Dashboard, and learn more in the Security Dashboard documentation. Read more ## Build an Authenticated Standalone Angular v22 App with the Okta Angular SDK DevFeed: [Build an Authenticated Standalone Angular v22 App with the Okta Angular SDK]() Original publisher: [Read original article]() Author: Alisa Duncan Published: 2026-08-25T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [Angular](), [Authentication](), [OpenID connect (OIDC)](), [Angular CLI](), [OAuth](), [SDKs](), [Node.js]() Tags: [angular](), [angular-v22](), [authentication](), [cli](), [node-js](), [oauth](), [oidc](), [release](), [sdk](), [tutorial]() ### AI overview This tutorial updates a small Angular v22 application to use the standalone Okta Angular SDK. It covers adding authentication with the provider function, protecting routes with functional guards, loading user groups with rxResource and signal inputs, and moving Okta configuration to runtime loading. ### Source excerpt Have you noticed that the Okta Angular SDK went fully standalone? There's no NgModule left to import, no importProvidersFrom wrapper to remember, and the guards are plain functions now. If you've been waiting for the SDK to look like the rest of your standalone Angular app, this is the release you were waiting for. In this post, we'll pick up a small Angular v22 project and finish it. We'll make the following changes: Add authentication using the new provideOktaAuth provider function Protect a route with the SDK's functional guard Load each user's groups with rxResource and a signal input Move the Okta configuration to runtime loading We're calling Okta's APIs directly for this project, so we don't have to stand up a separate backend. If you want to jump to the completed project, you can find it in the okta-angular-auth-signals-example GitHub repository. Otherwise, warm up your fingers and let's get coding! Note This post is best for developers familiar with Angular. If you are an Angular newbie, start by building your first Angular app using the tutorial created by the Angular team. Prerequisites For this tutorial, you will need the following tools: Node.js v22 or greater Angular CLI An Okta Integrator Free Plan account A web browser with good debugging capabilities Your favorite IDE Terminal window (if you aren't using an IDE with a built-in terminal) Table of Contents Get the starting Angular project Secure the Angular app with OAuth 2.1 and OpenID Connect (OIDC) using Okta Grant API scopes to read users and groups Allow cross-origin requests and protect the access token Add authentication with the standalone Okta Angular provider Protect routes with functional route guards Add users to your Okta org Display users and review Angular's rxResource API Load a user's groups with rxResource and a signal input Display group details using signal inputs Load your Okta configuration at runtime Learn more about Angular signals, standalone APIs, and OIDC Get the starting An ## The end of credential sprawl for agents DevFeed: [The end of credential sprawl for agents]() Original publisher: [Read original article]() Author: Dima Voytenko Published: 2026-08-25T04:00:00Z Content type: article Language: en Sources: [Vercel News]() Topics: [Vercel](), [Security](), [OAuth](), [OpenID connect (OIDC)](), [Authorization](), [SDKs](), [API](), [pull-requests]() Tags: [agents](), [connectors](), [github](), [oidc](), [pull-requests](), [sdk](), [security](), [shopify]() ### AI overview Vercel Connect is generally available as a way for applications and agents to obtain short-lived, task-scoped credentials at runtime. It supports connectors for services such as Slack, GitHub, Snowflake, Shopify, and OAuth providers, uses deployment OIDC identity for authentication, refreshes tokens automatically, and avoids storing provider secrets in applications. ### Source excerpt Every useful agent reaches beyond your codebase. It posts to Slack, opens pull requests, queries Snowflake, or calls an internal API. That reach is what makes it valuable, and it's also where the risk lives, because for years, granting it meant provisioning a long-lived token and hoping it never leaked. Vercel Connect replaces long-lived tokens with ones your code requests at runtime, scoped to the task and expiring on their own. During the public beta, we've grown the ecosystem past 100 connectors, unified how they work, and added the governance capabilities teams need in production. Today, Vercel Connect is generally available. Vaults don't fix long-lived tokens Managing credentials has become its own workload. Teams write rotation scripts, copy secrets across environments, and share tokens between users. Putting a token in a vault made it harder to steal, but no less dangerous once stolen. It never expires, and no vault limits what a leaked credential can do. Agents compounded the problem by touching more systems with greater autonomy, more often. Yet the tools to contain a secret haven't changed. With Vercel Connect, your app never stores credentials. It requests one: You register a connector once for a provider like Slack, GitHub, Snowflake, Shopify, or your own OAuth service You attach it to the projects and environments that need it Your code requests a token at runtime, and it refreshes automatically Your app has no provider secret to commit by accident Requesting a token doesn't require another secret. Every deployment on Vercel carries an OIDC identity, and the SDK uses it to prove who's asking. What changes when access becomes a request The difference shows up in the properties of the credential: Property Stored token Vercel Connect Lifetime Never expires Short-lived, refreshed automatically Reach Everything the agent could need Scoped to the task in the request Identity One shared bot for every user App or a specific named user Rotation Mint, update copi ## Vercel Connect now supports Linq DevFeed: [Vercel Connect now supports Linq]() Original publisher: [Read original article]() Author: Dima Voytenko Published: 2026-08-25T00:00:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [Vercel](), [Messaging](), [API](), [OpenID connect (OIDC)](), [Command-line interface](), [SDKs](), [dashboards](), [Deployment]() Tags: [agent](), [agents](), [api](), [apps](), [cli](), [deployment](), [identity](), [oidc](), [partner](), [production](), [sdk](), [token](), [vercel]() ### AI overview Vercel Connect now offers a managed Linq connector that lets applications and agents send and receive messages through iMessage, RCS, and SMS. It can provision or link Linq accounts and phone numbers, manage credentials, and integrate with eve through a configured channel. Projects can use the @vercel/connect SDK and deployment OIDC identity to obtain short-lived Linq tokens for Linq Partner API requests. ### Source excerpt Vercel Connect now includes a managed connector for Linq, so your apps and agents can send and receive messages over iMessage, RCS, and SMS. As a Vercel Managed Connector, Vercel can create a Linq account and phone number for you, or link an existing account. You never manage credentials yourself. Create a connector from the dashboard or Vercel CLI: Give your eve agent a phone number The connector powers the new Linq channel in eve. Run eve add channel/linq, choose Vercel Connect, and eve wires up the connector, phone numbers, and webhook for you: The channel marks accepted messages as read and continues the same eve session for every message in a Linq conversation. Out of the box, the channel supports read receipts, typing indicators, and mid-conversation steering for a more natural messaging experience. Use the connector in any project Call getToken with your connector, and the @vercel/connect SDK exchanges your Vercel deployment's OIDC identity for a short-lived Linq token. Pass it as the bearer token on any Linq Partner API request: Linq delivers each message over the best protocol the recipient supports, starting with iMessage, then RCS, then SMS. The same token works across the full Linq API, including group chats, reactions, rich media, and typing indicators. Read the Vercel Connect documentation, view details about the Linq connector in the Vercel Connect catalog, or create a Linq connector to get started. Read more ## Running your own OAuth and OIDC provider in 2026 is an operations problem DevFeed: [Running your own OAuth and OIDC provider in 2026 is an operations problem]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-25T00:00:00Z Content type: opinion Language: en Sources: [WorkOS Blog]() Topics: [OAuth](), [OpenID connect (OIDC)](), [Authorization](), [Security]() Tags: [oauth](), [oidc](), [operations](), [security](), [upgrade]() ### AI overview The article argues that operating a self-hosted OAuth and OIDC provider in 2026 is primarily an operations challenge. Using Better Auth 1.7 as evidence, it highlights key rotation, revocation, directory lifecycle, uptime, security maintenance, and migration work alongside protocol features such as DPoP and back-channel logout. ### Source excerpt Better Auth 1.7 shipped DPoP, back-channel logout, and MCP alignment. Its own upgrade guide shows why the operational half of an OAuth provider costs more. ## Add Cross App Access to Your OIDC Resource Application DevFeed: [Add Cross App Access to Your OIDC Resource Application]() Original publisher: [Read original article]() Author: Sohail Pathan Published: 2026-08-24T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [OpenID connect (OIDC)](), [API](), [Authorization](), [JSON Web Tokens](), [Single sign-on (SSO)](), [OAuth 2.0]() Tags: [api](), [authorization](), [cross-app-access](), [jwt](), [oauth-2-0](), [oidc](), [okta](), [scopes](), [sso](), [token](), [xaa]() ### AI overview This guide explains how OIDC-federated applications can support Cross App Access (XAA) for API access on behalf of users. It covers validating and redeeming the ID-JAG, resolving users from claims, issuing access tokens, updating authorization server metadata, and testing the end-to-end flow. ### Source excerpt If you currently federate enterprise customers using OpenID Connect (OIDC) and want to allow applications to access your API on behalf of those users, this Cross App Access (XAA) guide is for you. The Identity Assertion Authorization Grant specification, the basis of XAA, was designed with OIDC in mind. Your authorization server already trusts the customer's IdP for single sign-on (SSO), and XAA reuses that same trust for API access. This guide details what you need to support, how to validate the grant, and how to resolve the user at your resource authorization server. Table of Contents How XAA in OIDC works Analyzing the ID-JAG claims XAA implementation checklist for OIDC-federated applications Mapping user identity from iss and sub Validating the ID-JAG and resolving the user Issuing the access token Updating authorization server metadata Making cross-application requests from your OIDC app securely Configure your XAA OIDC Resource app in Okta Create the OIDC requesting app for testing Create the OIDC resource app in Okta Register and configure the AI Agent in Okta Verify your Okta XAA setup on xaa.dev Configure OIDC SSO Verify the refresh token exchange for an ID-JAG token Redeem the ID-JAG for an access token at the resource authorization server Call the resource API with the access token Prove the XAA connection end-to-end Takeaways for implementors who also have SAML apps Learn more about Cross App Access, OIDC, and OAuth 2.0 How XAA in OIDC works When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the customer's Identity Provider (IdP) for your authorization server. Your resource server accepts the token, identifies the user, and issues your own access token, all while leaving the customer's existing OIDC integration untouched. The sequence diagram shown below describes the OIDC XAA flow. Notice that the OIDC SSO flow stays the ## Add Cross App Access to Your OIDC Requesting Application DevFeed: [Add Cross App Access to Your OIDC Requesting Application]() Original publisher: [Read original article]() Author: Sohail Pathan Published: 2026-08-21T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [OpenID connect (OIDC)](), [OAuth](), [OAuth 2.0](), [JSON Web Tokens](), [API](), [Authorization](), [AI Agent]() Tags: [agent](), [api](), [authorization](), [callback](), [claude](), [cross-app-access](), [identity](), [jwt](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [sso](), [third-party-applications](), [token](), [xaa]() ### AI overview This guide explains how an OIDC-federated application can use Cross App Access (XAA) to request resources from a third-party application. It describes exchanging a refresh token for an Identity Assertion Authorization Grant, exchanging that short-lived JWT for an OAuth access token, and using the access token for the resource API request. ### Source excerpt If you currently federate enterprise customers using OpenID Connect (OIDC) and want to connect with third-party applications, this Cross App Access (XAA) guide is for you. The Identity Assertion Authorization Grant specification, the basis of XAA, was designed with OIDC in mind. Your app already holds an ID token after sign-in, but it's the refresh token from that same sign-in that you exchange to reach a third-party app. This guide details what you need to support and how to make resource requests to a third-party app using XAA. Table of Contents How XAA in OIDC works XAA implementation checklist for OIDC-federated applications Request the ID-JAG token Request the access token Call the resource API Handle token expiration Making cross-application requests from your OIDC app securely Configure your XAA OIDC requesting app in Okta Register the requesting app in Okta Register the test resource app in Okta Register your requesting app at xaa.dev Register and configure the AI Agent in Okta Validate the XAA connection end-to-end Learn more about Cross App Access, OIDC, and OAuth 2.0 How XAA in OIDC works When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the Identity Provider (IdP) for your app's user. You exchange the ID-JAG token for an access token to the resource application you're connecting with. The sequence diagram below describes the OIDC XAA flow and how your application fits into it. You'll handle the flow in two parts: where your application requests the ID-JAG from the IdP using the refresh token, and where your app requests the access token from the ID-JAG from the third-party resource app's authorization server. XAA implementation checklist for OIDC-federated applications Follow the guide in this section to support XAA in your OIDC application when your app connects to a third-party resource application. The XAA flow places t ## Auth0 Enterprise Connect in beta vs. WorkOS for enterprise SSO and SCIM DevFeed: [Auth0 Enterprise Connect in beta vs. WorkOS for enterprise SSO and SCIM]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-21T00:00:00Z Content type: comparison Language: en Sources: [WorkOS Blog]() Topics: [Auth0](), [Single sign-on (SSO)](), [Provisioning](), [OpenID connect (OIDC)](), [saml](), [Security]() Tags: [auth0](), [enterprise](), [oidc](), [provisioning](), [saml](), [sso]() ### AI overview This comparison examines Auth0 Enterprise Connect, which is in beta, alongside WorkOS for enterprise SSO and SCIM. It explains how Auth0 preserves an existing authorization server while adding enterprise identity capabilities, and highlights differences in SCIM direction, plan tier, pricing, and access requirements. ### Source excerpt Auth0's beta keeps the authorization server you already run and adds the enterprise surface around it. The differences from WorkOS show up in SCIM direction, plan tier, and which pricing table you are actually reading. ## How to add enterprise SSO to an Express.js API DevFeed: [How to add enterprise SSO to an Express.js API]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-21T00:00:00Z Content type: tutorial Language: en Sources: [WorkOS Blog]() Topics: [Single sign-on (SSO)](), [Tutorial](), [Express](), [Node.js](), [API](), [JSON Web Tokens](), [OpenID connect (OIDC)](), [Authorization](), [Back end]() Tags: [api](), [authorization](), [how-to](), [js](), [jwt](), [middleware](), [node-js](), [oidc](), [security](), [sso]() ### AI overview A step-by-step tutorial for adding enterprise SSO to an Express.js API with WorkOS. It covers SAML and OIDC login redirects, callback handling, JWT verification on protected routes, and multi-tenant authorization using signed token claims. ### Source excerpt Add enterprise SSO (SAML and OIDC) to an Express.js API with WorkOS. Step-by-step Node.js code for the login redirect, the callback, and JWT verification on protected API routes. ## Keycloak 26.7.2 released DevFeed: [Keycloak 26.7.2 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-08-19T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Security](), [OpenID connect (OIDC)](), [Quarkus](), [Jackson](), [OpenTelemetry](), [WebAuthn]() Tags: [2026](), [account-takeover](), [cve](), [idm](), [jackson](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oidc](), [openid-connect](), [opentelemetry](), [password](), [quarkus](), [release](), [resolved](), [saml](), [security](), [sso]() ### AI overview Keycloak 26.7.2 is released with security fixes, a Quarkus upgrade, and additional bug fixes and enhancements. The release addresses issues including account takeover, permission bypasses, secret disclosure, and WebAuthn behavior. ### Source excerpt To download the release go to Keycloak downloads. Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Security fixes #49570 CVE-2026-45292 OpenTelemetry Java SDK has Unbounded Memory Allocation in W3C Baggage Propagation dependencies #50616 [CVE-2026-14613] Keycloak 26.6.3 Fine-Grained Admin Permissions Bypass via Role Groups Endpoint admin/fine-grained-permissions #50955 [CVE-2026-59888 and CVE-2026-59889] Upgrade jackson-databind to 2.21.5 to fix #50966 [CVE-2026-15945] Group hierarchy search discloses hidden parent groups under FGAP v2 admin/fine-grained-permissions #51145 [CVE-2026-17048] Keycloak Admin REST API Leaks Vault-Resolved Rotated Client Secrets oidc #51832 CVE-2026-15571 Predictable account-linking hash enables account takeover via malicious oidc client #51833 CVE-2026-18963 Unauthenticated account takeover via reset-credentials flow bypass Weaknesses #50844 show-config prints the vault keystore password in cleartext dist/quarkus Enhancements #51344 Upgrade to Quarkus 3.33.3.1 Bugs #50751 Password denylist: false fpp warning on startup with large pre-computed .bloom file authentication #50849 Correct SCIM name.formated scim #50855 Rotated client secret remains valid when the feature is disabled oidc #51054 Invalid redirect URI on logout from pages with sub-tab hash fragments admin/ui #51061 Parameterized UserPropertyMapper exposes target user attributes without permission check core #51087 Passkey icons use wrong color variant when realm disables dark mode authentication/webauthn #51088 Verify email not working in incognito browser tab after Keycloak restart authentication #51131 Warning "Proactive closing of the session was missed - refinements are needed to TransactionSessionHandler related logic" appears core #51154 Upgrade to 26.7.0 fails with preview features as the stateless cluster provider captures a null NodeInfo before postInit infinispan #51164 WebAuthn tests are being skipped in Githu [Next page]()