# OpenID Connect Published articles for OpenID Connect. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Keycloak 26.7.4 released DevFeed: [Keycloak 26.7.4 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-09-16T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Security](), [Quarkus](), [MariaDB](), [MySQL](), [saml]() Tags: [cve](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [mariadb](), [mysql](), [openid-connect](), [quarkus](), [release](), [saml](), [security](), [sso]() ### AI overview Keycloak 26.7.4 was released on September 16, 2026. The release includes security fixes for several CVEs, an upgrade to Quarkus 3.33.3.2, and fixes for performance, testing, documentation, administration, and UI 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 #52834 [CVE-2026-90997] Default MySQL/MariaDB row counts make stateless replay gates accept reused artifacts #52835 [CVE-2026-79651] Keycloak Unauthenticated Denial of Service via Unbounded Locale Caching #52836 [CVE-2026-74909] Incomplete fix: percent-encoded semicolon bypasses matrix parameter stripping in PathMatcher #52837 [CVE-2026-19607] Username Takeover Leading to Account Lockout #52838 [CVE-2026-17526] Privilege escalation: the "impersonation" role can impersonate a realm administrator #52839 [CVE-2026-18212] SAML Redirect DEFLATE helpers leak native zlib state Enhancements #52354 Upgrade to Quarkus 3.33.3.2 dist/quarkus Bugs #49635 Performance issue with 26.6.2 dist/quarkus #51102 Flaky test: org.keycloak.testsuite.oauth.AccessTokenTest#accessTokenRequest ci #52015 New links errors for https://quarkus.io/guides docs #52172 Cached `RealmAdapter.isUserManagedAccessAllowed()` returns `isEnabled()` infinispan #52173 `realm_client` is computed into a client's attributes and then persisted on save admin/api #52233 Oracle 19 full client OCI driver crashes on startup since 26.6.0 -- SQLFeatureNotSupportedException on setNetworkTimeout dist/quarkus #52241 Clicking on a sub group in the admin console throws an exception admin/ui #52283 Flaky test SessionRestServiceTest.testGetDevicesSessions testsuite #52430 Flaky test: userprofile.spec.ts fails with timeout on "no-users-found-empty-action" in serial suite testsuite ## 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 ## 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. ## 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. ## 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 ## KEYCONF26 agenda and speakers announced for 8 October 2026 in Prague DevFeed: [KEYCONF26 agenda and speakers announced for 8 October 2026 in Prague]() Original publisher: [Read original article]() Author: Alina Rudyk Published: 2026-08-23T00:00:00Z Content type: news Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [identity and access management](), [openid](), [Security]() Tags: [iam](), [idm](), [kerberos](), [keycloak](), [ldap](), [openid](), [openid-connect](), [saml](), [security](), [sso](), [talk]() ### AI overview Keycloak has announced the speaker line-up and agenda for KEYCONF26, taking place in Prague on 8 October 2026. The programme covers Keycloak operations, extensions, identity standards, security, access tokens, and related use cases. ### Source excerpt The KEYCONF26 speaker line-up is taking shape, and this year's agenda is now live! 📍 KEYCONF26 is taking place in Prague on 8 October 2026. This October, the Keycloak community will come together once again for a full day of technical insights, real-world experiences and conversations around identity and access management. This year's programme brings together speakers from across the Keycloak ecosystem - from organisations running Keycloak in complex production environments to experts exploring new standards, architectures and use cases. Talk highlights The talks announced highlight the broad spectrum of the Keycloak ecosystem: how to run Keycloak securely and at scale, how to extend it, and how identity is evolving to support new technologies and use cases. Here are just a few highlights: What Role Can Keycloak Play for International Science? An Introduction to the OpenID Shared Signals Framework Keycloak becomes familiar with AI: the advancement of integrating Keycloak with AI Wicked Keycloak challenges and how to resolve them Token Hygiene - Why Your Keycloak Access Tokens Need a Diet And that is only a glimpse of what is waiting for you in Prague 👉 Explore the KEYCONF26 agenda announced: https://keyconf.dev/ A great place to network KeyConf is about more than the talks. It is also an opportunity to meet the people behind the technology, exchange experiences and connect with others working on similar identity challenges. Networking lunch Our extended lunch break gives you plenty of time to meet fellow attendees, swap ideas and continue conversations from the sessions in a relaxed setting. Meet the community KeyConf brings together Keycloak users, contributors, developers, architects, security specialists and IAM experts from different organisations and industries. Whether you want to discuss a challenge from your own Keycloak environment, exchange experiences or simply meet people from the community in person, there will be plenty of opportunities to connect thr ## 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 ## 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 ## Sign JWTs from your Functions without managing private keys DevFeed: [Sign JWTs from your Functions without managing private keys]() Original publisher: [Read original article]() Author: Jeff Pope Published: 2026-08-18T00:00:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [Vercel](), [JSON Web Tokens](), [OpenID connect (OIDC)](), [JSON Schema](), [Command-line interface](), [dashboards]() Tags: [cli](), [configuration](), [jwks](), [oidc](), [openid-connect](), [rsa](), [tokens](), [vercel]() ### AI overview Vercel KMS enables Vercel Functions to sign JWTs and arbitrary messages with managed asymmetric keys, keeping private keys out of application code and environment variables. It supports issuer and key management, environment-specific access grants, claim constraints, JSON Schema validation, and standard OIDC and JWKS-based verification. ### Source excerpt Vercel KMS lets you sign JWTs and arbitrary messages from your Vercel Functions using managed asymmetric signing keys, so private keys never live in your code or environment variables. Your function authenticates with its Vercel OIDC token, and the private key stays inside Vercel's key management service while verifiers use only the public key. With Vercel KMS you can: Create and rotate issuers and signing keys (RSA, ECDSA, and EdDSA) from the CLI and dashboard. Sign JWTs with custom claims and a configurable TTL, or sign raw bytes, using the @vercel/kms package. Grant a project signing access per environment, including production, preview, development, and custom environments. Constrain the claims a project can request per grant, and validate token claims against a JSON Schema. Verify signed tokens anywhere. Each issuer publishes a public OpenID Connect Discovery document at https://kms.vercel.com//.well-known/openid-configuration and a JWK set at https://kms.vercel.com//jwks.json, so any standard OIDC or JOSE library can validate tokens without Vercel-specific code. Sign a token inside a function: Verify a token anywhere with a standard JOSE library, using the issuer's public JWKS: Set up an issuer and grant a project access from the CLI: As a best practice, create a separate issuer per project and environment. Isolating issuers keeps each token audience distinct, scopes signing access to exactly one project and environment, and lets you rotate or revoke keys for one without affecting the others. To get started, read the docs or open Key Management in your team's dashboard. Read more ## RFC 9470 explained: The OAuth step-up authentication challenge protocol DevFeed: [RFC 9470 explained: The OAuth step-up authentication challenge protocol]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-18T00:00:00Z Content type: tutorial Language: en Sources: [WorkOS Blog]() Topics: [OAuth 2.0](), [Protocol (disambiguation)](), [API](), [Authentication](), [Authorization](), [OpenID connect (OIDC)](), [client]() Tags: [api](), [authentication](), [authorization](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [protocol]() ### AI overview This article explains RFC 9470, the OAuth 2.0 Step-Up Authentication Challenge Protocol. It describes how a resource server can tell a client that the current access token does not meet the required authentication level and how the client can obtain stronger authentication, including the roles of acr_values, max_age, and auth_time. ### Source excerpt How an API tells a client that the user needs to authenticate again, why acr_values is only a request while max_age is a requirement, and what the auth_time claim actually proves. ## ChainDrop npm Worm: Why SLSA Provenance Wasn't Enough DevFeed: [ChainDrop npm Worm: Why SLSA Provenance Wasn't Enough]() Original publisher: [Read original article]() Author: Harness Team Published: 2026-08-10T00:00:00Z Content type: article Language: en Sources: [Harness Blog]() Topics: [ChainDrop](), [npm](), [supply-chain-security](), [Malware](), [npm packages](), [GitHub Actions](), [GitHub]() Tags: [chaindrop](), [ci](), [ci-cd](), [github](), [github-actions](), [integrity](), [least-privilege](), [malware](), [npm](), [npm-worm](), [openid-connect](), [provenance](), [security](), [slsa](), [software-supply-chain-security](), [worm]() ### AI overview The ChainDrop npm worm compromised hundreds of packages while retaining valid SLSA provenance, demonstrating that build attestations do not guarantee source integrity. The article explains the worm's propagation, credential theft, persistence mechanisms, and recommended defenses, including source governance, dependency controls, least-privilege identities, policy gates, and runtime evidence. ### Source excerpt ChainDrop poisoned hundreds of npm packages while retaining valid provenance. Learn why signed builds need source governance, policy gates, and runtime evidence | Blog ## Use OpenID Connect issuer and subject identifiers instead of email as primary keys DevFeed: [Use OpenID Connect issuer and subject identifiers instead of email as primary keys]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-06T00:02:33Z Content type: tutorial Language: en Sources: [WorkOS Blog]() Topics: [OpenID connect (OIDC)](), [account takeover]() Tags: [auth](), [data](), [identity](), [oidc](), [openid-connect](), [schema]() ### AI overview The article explains why email addresses are unsafe as identity keys because they can be reassigned or recycled. It recommends storing the OpenID Connect issuer and subject identifier pair as the stable key for provider logins, while retaining email as mutable profile data. ### Source excerpt Email addresses get reassigned and recycled. If you key identity or link accounts on email, you built an account-takeover path yourself. Here's the fix. ## Keycloak 26.7.1 released DevFeed: [Keycloak 26.7.1 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-08-05T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Security](), [Authorization](), [OpenID connect (OIDC)](), [saml](), [LDAP](), [WebAuthn]() Tags: [2026](), [authorization](), [cve](), [extension](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oidc](), [openid-connect](), [release](), [saml](), [security](), [sso]() ### AI overview Keycloak 26.7.1 is released with multiple security fixes addressing authorization bypasses, privilege escalation, protocol validation issues, and other vulnerabilities, along with bug fixes. ### 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 #49429 [CVE-2026-9793] JWE request object bypasses requestObjectSignatureAlg enforcement oidc #50445 [CVE-2026-4629] Privilege escalation via hardcoded role mapper injection in manage-clients admin/api #50569 [CVE-2026-14209] Keycloak Admin UI Extension `brute-force-user` User Disclosure via `search=id:` under FGAP v2 admin/fine-grained-permissions #50615 [CVE-2026-14614] Keycloak 26.6.3 Fine-Grained Admin Permissions Bypass in Client Scope Assignment admin/fine-grained-permissions #50617 [CVE-2026-14615] FGAP v2 parent group children endpoint bypasses per-child view permission filter admin/fine-grained-permissions #51467 CVE-2026-15573 Authorization bypass via unnormalized uri matching in pathmatcher #51468 CVE-2026-15572 DCR protocol mapper type-swap policy bypass allows privilege escalation #51469 CVE-2026-16100 Unbounded metric cardinality in user event metrics via request-controlled error text #51470 CVE-2026-16442 SAML idp-initiated broker login bypasses link-only restriction #51471 CVE-2026-16443 SAML broker metadata import disables response signature validation #51472 CVE-2026-16071 LDAP entry-dn user search bypasses configured users dn boundary #51473 CVE-2026-16102 Default DCR policy allows role forgery via user property mappers Bugs #50719 WebAuthn authenticator attachment policy is bypassed when the client omits the attachment field authentication/webauthn #50750 Clustering test broken in 26.7 release branch ci #50836 Kustomize cluster-wide faulty Role&RoleBinding operator #50850 New Password is commited when multiple Password Reset is detected authentication #50882 500 when client requests `organization` scope with it already set to `Default` authentication #50928 IllegalFormatConversionException in LiquibaseDBLockProviderFactory and wrong time conversion core ## Keycloak Client Libraries 26.0.12 released DevFeed: [Keycloak Client Libraries 26.0.12 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-08-05T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Caching](), [Security](), [client](), [test]() Tags: [cache](), [idm](), [kerberos](), [keycloak](), [keycloak-client-libraries-release](), [ldap](), [openid-connect](), [resolved](), [saml](), [security](), [sso](), [test]() ### AI overview Keycloak Client Libraries 26.0.12 was released with security fix #234, which normalizes URIs so mutated URIs share the cache key of their canonical form, and bug fix #231 related to changed authentication resource behavior causing test failures. ### Source excerpt Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Security fixes #234 Normalize URIs in PathConfigMatcher to ensure mutated URIs share the same cache key as their canonical form client Bugs #231 AuthenticationManagementResource changed behavior causes test failures client ## Turborepo and Vercel Remote Cache now support OpenID Connect (OIDC) DevFeed: [Turborepo and Vercel Remote Cache now support OpenID Connect (OIDC)]() Original publisher: [Read original article]() Author: Mery Kaftar Published: 2026-07-30T00:00:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [OpenID connect (OIDC)](), [Vercel](), [Cache](), [CI/CD](), [GitHub](), [Command-line interface]() Tags: [ci-cd](), [ci-cd-workflows](), [documentation](), [github](), [oidc](), [openid-connect](), [policy](), [remote](), [tokens](), [vercel]() ### AI overview Turborepo and Vercel Remote Cache now support exchanging OIDC tokens from CI/CD workflows for short-lived Turborepo access tokens. The article recommends migrating from long-lived Personal Access Tokens to OIDC and explains where to configure the required policy. ### Source excerpt You can now exchange OIDC tokens from CI/CD workflows, including GitHub workflows, for short-lived Turborepo access tokens. These tokens grant access to Vercel's Remote Cache, and are a more secure alternative to long-lived Personal Access Tokens (PATs). OIDC tokens are short-lived, only grant access to Vercel Remote Cache, and are associated with your Vercel team, rather than a specific team member. We recommend all customers migrate their CI/CD workflows from PATs to OIDC. Get started by adding a Turborepo OIDC policy under Settings -> Build and Deployment -> OIDC Policies for CLI Access and learn more in the documentation. Read more ## The future of the Keycloak Discourse forum DevFeed: [The future of the Keycloak Discourse forum]() Original publisher: [Read original article]() Author: GR Patil, Niko Köbler Published: 2026-07-20T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [ai-coding](), [dev-tools](), [maintenance](), [Security]() Tags: [ai](), [ai-coding](), [developer-tools](), [idm](), [kerberos](), [keycloak](), [ldap](), [maintenance](), [openid-connect](), [saml](), [security](), [sso]() ### AI overview The Keycloak project announces that it will wind down its Discourse forum. The article explains the forum's historical role, increased use of AI coding assistants and search-like developer tools, reduced forum activity, and the maintenance effort required to keep it open. ### Source excerpt The Keycloak project has always relied on open, searchable, community-owned discussion. Over the years, the Keycloak Discourse forum has been an important part of that: a place where users could ask configuration questions, share migration experiences, debug integrations, and find answers from people who had solved similar problems before. After a lot of consideration, we have decided to wind down the Keycloak Discourse forum. This is not a decision we are taking lightly. The forum contains many years of useful community knowledge, and we recognize the role it has played for Keycloak users. We also recognize that previous changes to the forum caused disruption. For that reason, we want to explain why we are making this change, how it will happen, when it will happen, and where the community should go next. Why we are making this change In June 2023, the Keycloak maintainers decided to sunset Discourse as one of the project's communication channels. That decision was met with strong feedback from the community. Many users explained that Discourse filled an important role that was not fully covered by mailing lists, GitHub Discussions, or chat. After listening to that feedback, we reactivated Discourse in October 2023. In the years since, the way developers seek help has changed. More and more Keycloak users now turn first to AI coding assistants and search-like developer tools when they need help configuring Keycloak, troubleshooting integrations, or understanding errors. Those tools have almost certainly learned from many of the public sources the community has created over the years, including the Discourse forum, GitHub Discussions, mailing lists, documentation, blog posts, and issue trackers. That shift has changed the role of a community forum. The old model depended on a steady flow of new questions, answers, corrections, and follow-up discussion. Without that activity, the forum risks becoming a stale support archive rather than a healthy community space. Keep ## Enable Your SAML Requesting App for Cross App Access DevFeed: [Enable Your SAML Requesting App for Cross App Access]() Original publisher: [Read original article]() Author: Alisa Duncan Published: 2026-07-17T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [OAuth 2.0](), [Authorization](), [JSON Web Tokens](), [OpenID connect (OIDC)](), [API](), [AI Agent]() Tags: [api](), [authorization](), [claude](), [cross-app-access](), [digital-signature](), [identity](), [idp](), [implementation](), [jwt](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [payload](), [saml](), [signing](), [sso](), [xaa]() ### AI overview This guide explains how SAML-federated applications can use Cross App Access (XAA) to connect to third-party applications without migrating to OpenID Connect. It covers exchanging a SAML assertion for an OAuth refresh token, an ID-JAG, and an access token, along with token validation and Okta configuration. ### Source excerpt If you currently federate enterprise customers using Security Assertion Markup Language (SAML) and want to connect with third-party applications without migrating to OpenID Connect (OIDC), this Cross App Access (XAA) guide is for you. The Identity Assertion Authorization Grant specification, the basis of XAA, was originally designed with OIDC in mind. To use it in SAML applications, you must accommodate specific security and uniqueness requirements. 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 SAML works XAA implementation checklist for SAML-federated applications Request the refresh token Request the ID-JAG token Request the access token Handle token expiration Making cross-application requests from your SAML app securely Configure your XAA SAML Requesting App in Okta Register and configure the AI Agent in Okta Test the SAML 2.0 app Validate the XAA connection end-to-end Learn more about Cross App Access, SAML, and OAuth 2.0 How XAA in SAML 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 shown below describes the SAML XAA flow and how your application fits in. You'll handle the flow in two parts: where your application requests the ID-JAG from the IdP using a 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 SAML-federated applications Follow the guide in this section to support XAA in your SAML application when your app connects to a third-party resource application. The XAA flow places the burden of token validation onto the IdP and the resource ap ## Multi-Cluster v2 and Stateless Mode now in Preview DevFeed: [Multi-Cluster v2 and Stateless Mode now in Preview]() Original publisher: [Read original article]() Author: Alexander Schwartz Published: 2026-07-17T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Authentication](), [Database](), [Availability](), [Replication](), [Kubernetes](), [Amazon Web Services]() Tags: [authentication](), [availability](), [clustering](), [database](), [distributed](), [failover](), [idm](), [kerberos](), [ldap](), [monitoring](), [openid-connect](), [preview](), [replication](), [saml](), [sso]() ### AI overview Keycloak 26.7 introduces Stateless Mode as a preview. It moves volatile data, including authentication sessions, action tokens, and brute-force counters, from Infinispan caches to the database, supporting multi-cluster deployments without an external Infinispan cluster. ### Source excerpt Starting with Keycloak 26.7, the stateless feature is available as a preview. It fundamentally simplifies how Keycloak handles volatile data -- authentication sessions, action tokens, and brute-force counters move from embedded or external Infinispan caches to the database. The result: Keycloak deployments that are easier to operate, more resilient, and ready for multi-cluster setups without an external Infinispan cluster. Read on to learn more, and ask questions in our upcoming live Q&A event on Jul 21! The problem with the current approach A multi-cluster setup becomes necessary when no transparent networking between two sites is available for Keycloak's embedded Infinispan to form a single cluster -- for example, when sites are in different availability zones or data centers without a shared network layer. Running Keycloak in such a multi-cluster setup today requires significant infrastructure beyond Keycloak itself. Without the stateless feature, the architecture depends on an external Infinispan cluster with cross-datacenter replication channels, dedicated monitoring to detect and handle Infinispan failover, and operational procedures for failback. It was tied to specific environments like Kubernetes and AWS, and using it in other environments would require significant work to adapt it. Even in single-cluster deployments, Infinispan clustering introduces operational overhead: rebalancing data in distributed caches when a node is lost or restarted, and transient failures in login flows if a node unexpectedly disappears. In large installations, the login failure cache can grow significantly, consuming substantial memory and causing long rebalancing times when nodes join or leave the cluster. While distributed caches replicate data across at least two nodes -- so individual node failures do not lose data -- a full cluster restart during minor upgrades resets volatile state such as in-progress authentication sessions and brute-force counters. What changes with stateles ## Connect Your Cloud Accounts to Pulumi in Minutes DevFeed: [Connect Your Cloud Accounts to Pulumi in Minutes]() Original publisher: [Read original article]() Author: Levi Blackstone Published: 2026-07-15T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Cloud](), [Amazon Web Services](), [Azure](), [OpenID connect (OIDC)](), [Google Cloud Platform (GCP)](), [configuration](), [Authentication]() Tags: [aws](), [azure](), [cloud](), [configuration](), [esc](), [google-cloud](), [governance](), [identity](), [insights](), [openid-connect](), [policy](), [product](), [pulumi-cloud]() ### AI overview Pulumi introduces a Connect cloud accounts wizard for discovering and onboarding AWS accounts, Azure subscriptions, and Google Cloud projects in a single guided flow. It automates OIDC setup, creates Pulumi ESC environments, and applies discovery scans and policy packs. ### Source excerpt Pulumi Insights gives you visibility and governance across your entire cloud footprint, but that visibility is only as complete as the set of accounts you've connected. Until now, connecting an account meant repeating a manual setup for each one: OIDC configuration, hand-written Pulumi ESC environments, and per-account scan and policy setup. For an organization with dozens or hundreds of AWS accounts, Azure subscriptions, or Google Cloud projects, that per-account friction was the biggest obstacle to getting a complete picture. Today, the new Connect cloud accounts wizard removes it: discover every account in your cloud organization, select the ones you want, and onboard them all in a single guided flow. From hours of setup to a single flow The time savings are real: connecting a batch of accounts across AWS, Azure, and Google Cloud takes about three minutes end to end. Setting up those same accounts with the manual per-account workflow would take hours to days. The wizard handles the entire onboarding lifecycle for AWS, Microsoft Azure, and Google Cloud: Bulk discovery: Authenticate once with your cloud organization and the wizard lists every account, subscription, or project you can access. Accounts that are already connected are recognized and skipped. Automatic OIDC setup: The recommended flows configure each account with short-lived credentials based on OpenID Connect (OIDC) and workload identity federation. No long-lived cloud secrets are stored in Pulumi Cloud. ESC environments, created for you: The wizard generates Pulumi ESC environments that follow the best practices from the manual OIDC guides -- environments that previously had to be authored one by one. Scans and policies from day one: By default, scheduled discovery scans and a pre-built policy pack are applied to every account as part of setup: the Pulumi Best Practices pack on the Team and Enterprise editions, or a compliance pack (CIS, or NIST 800-53 for AWS and Google Cloud) on Business Critical. Ho ## Keycloak Client Libraries 26.0.11 released DevFeed: [Keycloak Client Libraries 26.0.11 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-07-15T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [client](), [servers](), [ci](), [migration]() Tags: [2026](), [bugs](), [changes](), [ci](), [client](), [idm](), [kerberos](), [keycloak](), [keycloak-client-libraries-release](), [ldap](), [migration-guide](), [openid-connect](), [release](), [resolved](), [saml](), [sso]() ### AI overview Keycloak Client Libraries 26.0.11 was released on July 15, 2026. The release notes mention an enhancement to sync after the Keycloak server 26.7.0 release and a CI failure issue in keycloak-client. Users are directed to the migration guide before upgrading. ### Source excerpt Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Enhancements #226 Sync after Keycloak server 26.7.0 release client Bugs #222 keycloak-client CI is failing client ## Keycloak 26.7.0 released DevFeed: [Keycloak 26.7.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-07-09T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [API](), [Authentication](), [Authorization](), [Security](), [OAuth 2.0](), [saml]() Tags: [api](), [authentication](), [authorization](), [deprecated](), [haproxy](), [high-availability](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oauth](), [oauth-2-0](), [openid-connect](), [persistence](), [provisioning](), [release](), [saml](), [security](), [sso](), [traefik]() ### AI overview Keycloak 26.7.0 introduces preview support for SCIM-based user provisioning and simplified multi-cluster high availability, along with enhanced HAProxy and Traefik reverse-proxy guidance and step-up authentication for SAML clients. The release also adds a more secure, OAuth 2.0-compliant Identity Brokering API v2, while V1 remains enabled by default but is deprecated. OID4VCI improvements remain experimental. ### Source excerpt To download the release go to Keycloak downloads. Highlights This release features new capabilities for users and administrators of Keycloak. The highlights of this release are: Automate user provisioning with the SCIM API (preview) Simplified multi-cluster high availability without external caches (preview) Enhanced reverse proxy guides with blueprints for HAProxy and Traefik Step-up authentication for SAML clients Read on to learn more about each new feature. If you are upgrading from a previous release, also review the changes listed in the upgrading guide. Security and Standards Stronger security for the Identity Brokering API The Identity Brokering API allows applications to retrieve tokens obtained from external identity providers during federated login. Version 2 of this API replaces the legacy V1 with a more secure and standards-compliant design: Client-level authorization -- access to external tokens is controlled per client using dedicated settings (Allow retrieve external tokens and an identity provider allow list) instead of assigning broker roles to individual users. Confidential clients only -- public clients are rejected, ensuring that only authenticated clients can retrieve external tokens. OAuth 2.0 compliant -- the endpoint uses POST and returns standard JSON responses with access_token, error, and error_description fields. Session-based token storage -- a new Store token in session option keeps tokens in the user session for faster access, with automatic cleanup on session expiry. Database storage remains available for persistence across sessions. V2 is now supported but disabled by default. V1 is deprecated but still enabled by default for backward compatibility. In a future release, V1 will be removed and V2 will become the default. For more information, see the Identity Brokering APIs chapter in the Server Developer Guide. Progress on Verifiable Credentials (OID4VCI) (experimental) Verifiable Credentials (OID4VCI) allow organizations to issue tampe ## Experimental Shared Signals Framework support DevFeed: [Experimental Shared Signals Framework support]() Original publisher: [Read original article]() Author: Thomas Darimont Published: 2026-07-03T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [openid](), [Security](), [JSON Web Tokens](), [HTTP](), [Software as a service]() Tags: [experimental](), [http](), [idm](), [jwt](), [kerberos](), [keycloak](), [ldap](), [openid](), [openid-connect](), [release](), [saas](), [saml](), [security](), [sso]() ### AI overview Keycloak announces experimental support for the OpenID Shared Signals Framework 1.0 in its nightly release. It can transmit signed Security Event Tokens about identity-related events to subscribed receivers over standardized HTTP push or poll channels, enabling faster propagation of changes such as session revocation, account disabling, credential rotation, and device non-compliance. ### Source excerpt We are excited to announce that Keycloak now provides experimental support for the OpenID Shared Signals Framework 1.0 specification, available from today in the nightly release. This allows Keycloak to act as a Shared Signals Transmitter, pushing signed Security Event Tokens (SETs) about identity-relevant events to any subscribed Receiver, using a standardised wire format defined by the OpenID Foundation. This closes a long-standing gap. When you revoke a user's session in Keycloak today, the SaaS app they're logged into usually doesn't sign them out until their next token refresh, which can be minutes, hours, or in some cases never. The same gap exists when an account is disabled, a credential is rotated, or a device is flagged as non-compliant. Keycloak knows; the relying parties don't, until they happen to ask again. With SSF, Keycloak can now push those signals to subscribed receivers in seconds -- no per-vendor webhooks, no bespoke polling endpoints, no Kafka topic per integration. Concretely, this also unlocks an integration the Keycloak ecosystem has been missing: Keycloak can now act as the federated IdP for Apple Business and Apple School Manager, signalling user-state changes back to Apple so enrolled devices can ask the user to reauthenticate. This post is the first in a small series. It introduces SSF, walks through what's actually shipped in the experimental release, and outlines where we'd like to take it next. Follow-up posts will cover how to define custom events, how to emit synthetic events, and an Apple Business and Apple School Manager integration end to end. A short tour of Shared Signals The OpenID Foundation's Shared Signals Framework 1.0 defines a standard way for one party (the Transmitter) to tell another party (the Receiver) about identity-relevant events as they happen. Each event is delivered as a signed JWT, a Security Event Token (RFC 8417) delivered over either an HTTP push channel (RFC 8935) or an HTTP poll channel (RFC 8936). Two pr ## Keycloak Client Libraries 26.0.10 released DevFeed: [Keycloak Client Libraries 26.0.10 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-06-30T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [client](), [Keycloak](), [Documentation]() Tags: [bugs](), [changes](), [client](), [docs](), [guide](), [idm](), [kerberos](), [keycloak](), [keycloak-client-libraries-release](), [ldap](), [openid-connect](), [resolved](), [saml](), [sso]() ### AI overview Keycloak Client Libraries 26.0.10 was released on June 30, 2026. The release includes resolved issues involving supported Keycloak server versions and downstream documentation builds. ### Source excerpt Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Bugs #208 Clarification of supported keycloak server versions client #210 Latest changes break downstream docs build for 26.6 client ## Save the Date: Keycloak DevDay 2027 DevFeed: [Save the Date: Keycloak DevDay 2027]() Original publisher: [Read original article]() Author: Niko Köbler, Sebastian Rose Published: 2026-06-29T00:00:00Z Content type: news Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Hackathon]() Tags: [2026](), [blog](), [community](), [conference](), [contributors](), [germany](), [hackathon](), [idm](), [kerberos](), [keycloak](), [ldap](), [openid-connect](), [saml](), [sessions](), [sso](), [submission](), [talks]() ### AI overview Keycloak DevDay 2027 will take place in Darmstadt, Germany, on April 8-9, 2027. The event will include a conference day with community talks and deep dives, followed by a community day with a hackathon and OpenSpace sessions. Ticket sales have not started, and the call for papers is planned for around the end of August. ### Source excerpt ‼ Mark your calendars! Keycloak DevDay 2027 is coming back to Darmstadt, Germany, on April 8-9, 2027 ‼ Like the previous edition, DevDay 2027 will span two days with the same overall structure - though with a few notable changes participants will notice: 📅 Thursday, April 8, 2027 - Conference Day: talks and deep dives from the Keycloak community and contributors. 📅 Friday, April 9, 2027 - Community Day: a more informal, hands-on day featuring a Hackathon and an OpenSpace with multiple breakout sessions, where attendees shape the agenda together. Stay in the loop Ticket sales haven't started yet, and we don't want you to miss your chance to grab one of the strictly limited seats. If you haven't already, subscribe to the newsletter on keycloak-day.dev to be the first to know the moment tickets go live. Call for Papers We're planning to open the Call for Papers around the end of August. Keep an eye on the newsletter and this blog for the exact date and submission details. Something to watch in the meantime While you wait, why not revisit the talks from past years editions? The full playlists of Keycloak DevDay videos are available on YouTube: Keycloak DevDay 2026 video playlist Keycloak DevDay 2025 video playlist Keycloak DevDay 2024 video playlist We can't wait to see you in Darmstadt next April! Niko & Sebastian [Next page]()