# oauth 2.0 Published articles for oauth 2.0. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## This Week in Spring - September 15th, 2026 DevFeed: [This Week in Spring - September 15th, 2026]() Original publisher: [Read original article]() Author: joshlong Published: 2026-09-15T00:00:00Z Content type: article Language: en Sources: [Spring]() Topics: [Spring AI](), [Java](), [Security](), [OAuth 2.0](), [Spring Boot](), [JavaFX](), [IntelliJ IDEA](), [debugging]() Tags: [batch](), [boot](), [cloud](), [debugging](), [event-driven](), [intellij-idea](), [java](), [learn](), [microservices](), [oauth-2-0](), [reactive](), [security](), [serverless](), [spring](), [spring-ai](), [web-applications]() ### AI overview A September 15, 2026 roundup of Spring-related developer content, covering Java memory management, Spring AI chat-memory summarization, JavaFX application security with Spring Security and OAuth 2.0, OAuth 2.1 with Spring Authorization Server, Spring and Gemini video understanding, Java AI libraries, Netflix's Java and Spring story, Spring Batch, and Spring Boot debugging. ### Source excerpt Hi, Spring fans! Welcome to another rip-roarin' installment of This Week in Spring! I'm writing this to you from sun-kissed San Francisco, CA, sipping some coffee and watching the bay from my breakfast nook. What a wonderful day! A wonderful day in which to learn about the latest and greatest in Spring, even! Let's dive right in! I really loved this presentation by Oracle's Ron Pressler on the principles of memory management in Java More Craig Walls Spring AI goodness! Here's a nice recipe on summarizing chat memory Over the last few weeks, I've done some content on securing JavaFX applications with Spring Security and OAuth 2.0. That work has landed, and our friends at JFX-central.com have taken that video and the resulting code and transcribed the content into this lovely tutorial - check it out! I loved this post on securing modern applications with OAuth 2.1 and Spring Authorization Server This is a really cool video on understanding video with Spring and Gemini I just learned about this amazing new Java library called Quixotic.ai (what a name! LOL) that provides all sorts of cool stuff that might make your Java-based AI workloads even better. I wonder if there are amazing integration possibilities for Spring AI, too... In last week's A Bootiful Podcast, I was delighted to sit down and chat with Netflix's Paul Bakker on their Java and Spring story, scaling the system, and more. Huh! There's a new Spring Batch IntelliJ IDEA plugin, but search me for what's new! No release notes. Either way, get it while it's hot! Speaking of Spring Batch, there's a nice post here on scaling to millions of rows with Spring Batch that just dropped Speaking of Spring and IntelliJ, there's a nice article over on Baeldung on debugging Spring Boot-based workloads with the Spring debugger ## 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. ## Your app is the other half of agent SSO DevFeed: [Your app is the other half of agent SSO]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-31T20:22:53Z Content type: opinion Language: en Sources: [WorkOS Blog]() Topics: [Single sign-on (SSO)](), [Authorization](), [JSON Web Tokens](), [OAuth 2.0](), [computer-use]() Tags: [ai-agents](), [app](), [authorization](), [jwt](), [oauth-2-0](), [security](), [sso]() ### AI overview This commentary explains that Okta's Agent SSO and the Cross App Access standard broker connections between AI agents and enterprise applications, but the connected application remains responsible for validating the grant and issuing its own access token. It describes the resource-side roles and the underlying OAuth and JWT-based standards. ### Source excerpt Okta's Agent SSO went GA on the Cross App Access standard. The IdP brokers the connection, but your app still has to validate the grant and issue the token. ## Type-Safe Authentication in Rust with Auth0 and Axum DevFeed: [Type-Safe Authentication in Rust with Auth0 and Axum]() Original publisher: [Read original article]() Author: Aniket Bhattacharyea Published: 2026-08-31T00:00:00Z Content type: tutorial Language: en Sources: [Auth0 Blog]() Topics: [Authentication](), [Auth0](), [Rust](), [Command-line interface](), [OAuth 2.0](), [Authorization](), [API]() Tags: [api](), [auth0](), [authentication](), [authorization](), [cli](), [oauth](), [oauth-2-0](), [rust](), [tokens](), [tutorial]() ### AI overview A tutorial showing how to build a Rust CLI that uses Auth0's OAuth 2.0 Device Authorization Flow, then create an Axum API that validates the resulting access token before allowing access to a protected route. ### Source excerpt Secure your Rust CLI applications with Auth0 Device Code flow and protect your Axum backend endpoints by validating JWTs with Rust's type safety. ## What invalid\_grant actually means, provider by provider DevFeed: [What invalid\_grant actually means, provider by provider]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-27T00:00:00Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [OAuth 2.0](), [Authentication](), [Google](), [Microsoft](), [Slack]() Tags: [authentication](), [bug](), [oauth](), [oauth-2-0]() ### AI overview This article explains that OAuth 2.0's invalid_grant error covers five specification conditions, while providers use the same error differently. It compares provider-specific meanings for Google, Microsoft, Salesforce, Xero, QuickBooks, and Slack, and explains why recovery depends on provider-specific error details, often with a fallback to full re-authorization. ### Source excerpt One string, five spec conditions, and a different meaning at every provider. Here is what Google, Microsoft, Salesforce, Xero, QuickBooks, and Slack each mean by it. ## 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 ## 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. ## Announcing OAuth Device Authorization for the Appwrite CLI: Log in from your browser DevFeed: [Announcing OAuth Device Authorization for the Appwrite CLI: Log in from your browser]() Original publisher: [Read original article]() Author: Chirag Aggarwal Published: 2026-07-29T00:00:00Z Content type: release Language: en Sources: [Appwrite Blog]() Topics: [Appwrite](), [OAuth](), [OAuth 2.0](), [Command-line interface](), [Authentication](), [Authorization](), [browser]() Tags: [announcements](), [authentication](), [authorization](), [browser](), [cli](), [oauth](), [oauth-2-0](), [sign-in](), [trust]() ### AI overview Appwrite announces OAuth Device Authorization for the Appwrite CLI. The CLI opens or provides a browser URL where users confirm a device code, review requested permissions, and authorize sign-in using their existing browser session instead of entering a password in the terminal. ### Source excerpt The Appwrite CLI now signs you in through your browser. Confirm a device code, review permissions, and authorize, without typing credentials into your terminal. ## Build a Flask App with Okta for Secure OIDC Login and Authorized API Calls DevFeed: [Build a Flask App with Okta for Secure OIDC Login and Authorized API Calls]() Original publisher: [Read original article]() Author: Akanksha Bhasin Published: 2026-07-28T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [Flask](), [OpenID connect (OIDC)](), [Tutorial](), [API](), [Authentication](), [Authorization](), [OAuth 2.0](), [Python](), [web applications]() Tags: [api](), [authentication](), [authorization](), [flask](), [oauth](), [oauth-2-0](), [oidc](), [pkce](), [python](), [security](), [tutorial](), [web-app]() ### AI overview This tutorial explains how to build a Flask dashboard that uses Okta OpenID Connect for user sign-in and OAuth 2.0 access tokens to call a protected backend API. It also covers PKCE, custom scopes, self-service registration, and validating scopes to control API responses. ### Source excerpt Python syntax and the flexibility of the Flask microframework make it a popular choice for quickly building web applications. While Flask provides the essentials to get you started, you'll need to tackle two critical pieces yourself: secure user authentication and authorization for your backend services. After all, how do you securely sign users into your application? And once they're signed in, how does your app fetch data from a backend service that only serves authorized requests? This tutorial shows you how to solve both. You'll build a Flask dashboard app that signs users in with Okta using OpenID Connect (OIDC). Once signed in, the app uses the resulting OAuth 2.0 access token to call a separate backend API that responds only to authorized requests. In this common pattern, a web app needs to fetch data from a protected backend service. You'll use Authlib, an OIDC client library, to configure the Authorization Code flow with Proof Key for Code Exchange (PKCE) automatically. You'll also learn how to add a custom scope to the access token and validate it on the backend to control what data the API returns. Check out the complete source code on GitHub and get started without setting it up from scratch. Table of Contents Build a Flask app with OIDC authentication Create an app integration in the Okta Admin Console Enable self-service user registration Add secure user login to a Flask application with Okta Create a basic Flask web application Configure Flask environment variables Implement the OIDC authentication logic Run the Flask OAuth web app Call a protected API with OAuth scoped tokens Build a protected users API Extend the Flask app to interact with the resource server Update the Flask UI to display protected data Test the protected API integration Learn more about OAuth and OIDC Build a Flask app with OIDC authentication In this tutorial, you'll build a simple dashboard application and learn how to: Securely sign users in to view their profile information us ## 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 ## 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 ## Keycloak 26.6.0 released DevFeed: [Keycloak 26.6.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-04-08T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [releases](), [JSON Web Tokens](), [Authentication](), [Authorization](), [OAuth 2.0](), [Security](), [openid](), [Kubernetes](), [SPIFFE]() Tags: [idm](), [jwt](), [kerberos](), [keycloak](), [keycloak-release](), [kubernetes](), [ldap](), [oauth](), [oauth-2-0](), [openid-connect](), [release](), [releases](), [saml](), [security](), [sso](), [test]() ### AI overview Keycloak 26.6.0 introduces JWT Authorization Grant, federated client authentication, workflows for realm administration, zero-downtime patch releases, and a new test framework. The release also includes a preview of Identity Brokering APIs V2 and a guide to OAuth 2.0 DPoP. ### 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: JWT Authorization Grant, enabling external-to-internal token exchange using externally signed JWT assertions. Federated client authentication, eliminating the need to manage individual client secrets in Keycloak. Workflows, enabling administrators to automate realm administrative tasks such as user and client lifecycle management. Zero-downtime patch releases, allowing rolling updates within a minor release stream without service downtime. The Keycloak Test Framework, replacing the previous Arquillian-based solution. All of these features are now fully supported and no longer in preview. 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 JWT Authorization Grant (supported) JWT Authorization Grant (RFC 7523) is designed to implement external-to-internal token exchange use cases. This grant allows using externally signed JWT assertions to request OAuth 2.0 access tokens. In this release, JWT Authorization Grant is promoted from preview to supported. See the JWT Authorization Grant guide for additional details. Federated client authentication (supported) Federated client authentication allows clients to leverage existing credentials once a trust relationship with another issuer exists. It eliminates the need to assign and manage individual secrets for each client in Keycloak. Federated client authentication is now promoted to supported, including support for client assertions issued by external OpenID Connect identity providers and Kubernetes Service Accounts. Since the OAuth SPIFFE Client Authentication specification is still in draft status, this feature remains a preview feature in Keycloak. New guide about Demonstrating Proof-of-Possession (DPoP) A new guide for OAuth 2.0 D ## Meet Keycloak at FOSDEM on Jan 30/Feb 01! DevFeed: [Meet Keycloak at FOSDEM on Jan 30/Feb 01!]() Original publisher: [Read original article]() Author: Alexander Schwartz Published: 2026-01-26T00:00:00Z Content type: news Language: en Sources: [Keycloak Blog]() Topics: [FOSDEM](), [Keycloak](), [identity and access management](), [Open Source](), [Authentication]() Tags: [2026](), [active-directory](), [authentication](), [fosdem](), [idm](), [kerberos](), [keycloak](), [ldap](), [oauth](), [oauth-2-0](), [open-source](), [openid](), [openid-connect](), [saml](), [sso]() ### AI overview Keycloak will participate in FOSDEM 2026 in Brussels through a co-hosted Sovereign Identity stand and related identity and access management talks. The article provides event, stand, and schedule details. ### Source excerpt FOSDEM is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event. Several Keycloak related talks happen at FOSDEM in Brussels on January 31st and February 1st, and meet us and help out at the stand. To get the latest updates, subscribe to our discussion on GitHub. Meet the community at the Sovereign Identity stand On Saturday, January 31st 2026, the Keycloak project will co-host the "Sovereign Identity for server, desktop, and a cloud" stand together with the FreeIPA, SSSD and OpenWallet project. We'll be open from 1000 in the morning until around 1800 in the early evening. We will be at K building on level 1 in group C. Visit this stand to interact with the teams of several popular solutions in this space. Keycloak Extensible self-hosted Single-Sign-On for your applications. Supporting Passkeys, OpenID Connect, OAuth 2.0, SAML 2.0 and Kerberos. Integrating with other Identity Providers through brokerage via SAML or OpenID Connect, or via LDAP. FreeIPA Manage Linux users and client hosts in your realm from one central location, define Kerberos authentication and authorization policies for your identities, create mutual trust with other Identity Management systems. Issue certificates to your users and services. SSSD Open Source Client for Enterprise Identity Management. Enroll your Linux machine into an Active Directory, FreeIPA or LDAP domain. Use remote identities, policies and various authentication and authorization mechanisms to access your computer. OpenWallet Foundation We drive global adoption of open, secure and interoperable digital wallet solutions. We set best practices for digital wallet technology through collaboration on standards-based OSS components that issuers, wallet providers and relying parties can use to bootstrap implementations that preserve user choice, security and privacy. Talks about Keycloak and related top ## JWT Authorization Grant and Identity Chaining in Keycloak 26.5 DevFeed: [JWT Authorization Grant and Identity Chaining in Keycloak 26.5]() Original publisher: [Read original article]() Author: Giuseppe Graziano Published: 2026-01-23T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [JSON Web Tokens](), [Keycloak](), [OAuth 2.0](), [OAuth](), [Authorization](), [Internet Engineering Task Force (IETF)]() Tags: [authorization](), [deprecated](), [external](), [identity](), [idm](), [jwt](), [kerberos](), [keycloak](), [ldap](), [oauth](), [oauth-2-0](), [openid-connect](), [preview](), [saml](), [sso](), [standard](), [trust]() ### AI overview Keycloak 26.5 introduces preview support for JWT Authorization Grant under RFC 7523. The feature lets clients exchange a signed JWT from an external issuer for a Keycloak access token. The article also explains how combining this grant with OAuth 2.0 Token Exchange can preserve identity and authorization context across multiple trust domains. ### Source excerpt Modern applications and AI agents increasingly operate across distributed trust domains, where each domain is protected by its own OAuth 2.0 Authorization Server. A single request may also traverse multiple resource servers to complete a task. This raises an important challenge: every protected resource must understand who initiated the request, which authorization was granted, and optionally which other resources were accessed before making an authorization decision. Preserving this information across domains is critical. Keycloak 26.5 introduces preview support for the new feature JWT Authorization Grant, implementing RFC 7523. This feature allows a client to present a signed JWT from an external issuer and obtain a Keycloak access token, providing a standard and secure way to authorize requests based on external assertions. However, exchanging a token alone does not fully solve the problem of propagating identity and authorization context across multiple trust domains. The IETF draft OAuth Identity and Authorization Chaining Across Domains defines a standardized flow that combines JWT Authorization Grant (RFC 7523) with OAuth 2.0 Token Exchange (RFC 8693), which Keycloak already supports, to preserve the original user's identity, claims, and authorization throughout the chain. JWT Authorization Grant The JWT Authorization Grant feature allows a client to present a signed JWT assertion to the token endpoint and obtain an access token without an interactive authorization step. To initiate this flow, the client sends a request to the token endpoint with the grant_type set to urn:ietf:params:oauth:grant-type:jwt-bearer and the external token passed in the assertion parameter. It provides a standard and secure alternative to the preview feature External-to-Internal Token Exchange V1 which will be deprecated. Trust relationships in Keycloak are defined through Identity Providers. The JWT Authorization Grant can be enabled and configured in a dedicated section of the ex ## Setting Up Keycloak as a Credential Issuer with OpenID4VCI DevFeed: [Setting Up Keycloak as a Credential Issuer with OpenID4VCI]() Original publisher: [Read original article]() Author: Rodrick Awambeng, Forkim Enjeckayang, Ingrid Kamga, Bertrand Ogen Published: 2026-01-16T00:00:00Z Content type: tutorial Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [OAuth 2.0](), [OpenID connect (OIDC)](), [Development]() Tags: [experimental](), [guide](), [idm](), [interoperability](), [kerberos](), [keycloak](), [ldap](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [privacy](), [saml](), [sso]() ### AI overview This guide explains how to configure Keycloak as an OpenID4VCI verifiable credential issuer. It introduces the relationship between OpenID4VCI and OpenID4VP, describes credential issuance and presentation flows, and discusses privacy and interoperability. The article notes that Keycloak's OpenID4VCI support is experimental and uses Keycloak 26.5.0. ### Source excerpt Before configuring Keycloak, it is helpful to understand its role in decentralized identity ecosystems. As a verifiable credential issuer, Keycloak can issue digitally signed credentials using the OpenID for Verifiable Credential Issuance (OpenID4VCI) protocol, allowing relying parties (also known as verifiers) to independently verify them without contacting the issuer. Keycloak implements OpenID4VCI, enabling the issuance of verifiable credentials (VCs) as digital proofs of identity or attributes. Configuring this functionality requires consistent setup across the realm, clients, and issuable credentials (client scopes). For example, consider the following scenario: The Keycloak OAuth SIG team wants to issue verifiable membership credentials to its members, including their name and email, which can later be presented at onsite or virtual events as proof of active membership. At the time of writing this blog, Keycloak's support for OpenID4VCI is still experimental. This guide uses the Keycloak 26.5.0 release. The feature is under active development and is expected to be promoted to preview in the future. Introduction to OpenID4VCI & OpenID4VP OpenID4VCI is a protocol developed by the OpenID Foundation that extends the OAuth 2.0 framework to support the secure and interoperable issuance of Verifiable Credentials (VCs). VCs are digital, tamper-evident representations of information, such as identity attributes or qualifications, which can be cryptographically verified without needing to contact the issuer at verification time. While this guide primarily focuses on OpenID for Verifiable Credential Issuance (OpenID4VCI), the overall trust architecture also includes OpenID for Verifiable Presentations (OpenID4VP), which governs how holders present credentials to verifiers. Together, these protocols enable decentralized identity ecosystems in which users (holders) retain control of their data and can share it selectively with verifiers. Figure 1. Triangle of trust or Issu ## Keycloak 26.5.0 released DevFeed: [Keycloak 26.5.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-01-06T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Authorization](), [JSON Web Tokens](), [Model Context Protocol](), [OpenTelemetry](), [Kubernetes](), [Cross-origin resource sharing (CORS)]() Tags: [authorization](), [cors](), [idm](), [jwt](), [kerberos](), [keycloak](), [keycloak-release](), [kubernetes](), [ldap](), [model-context-protocol](), [oauth](), [oauth-2-0](), [openid-connect](), [opentelemetry](), [release](), [saml](), [sso]() ### AI overview Keycloak 26.5.0 introduces workflows for realm administration, JWT Authorization Grants in preview, additional documentation for using Keycloak as an authorization server for MCP servers, Kubernetes service-account-token authentication, and OpenTelemetry support for metrics and logging. It also includes CORS enhancements and other identity-management changes. ### 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: Workflows to automate administrative tasks and process within a realm. JWT Authorization Grants, our recommended alternative to external to internal token exchange. Guide for using Keycloak as an authorization server for Model Context Protocol (MCP) servers. Authenticating clients with Kubernetes service account tokens to avoid static client secrets. OpenTelemetry support for metrics and logging, combining all observability information in this popular standard. Read on to learn more about each new feature. If you are upgrading from a previous release, review also the changes listed in the upgrading guide. Security and Standards JWT Authorization Grant (preview) Keycloak 26.5 introduces a new feature called JWT Authorization Grant, which adds support for RFC 7523 to use external signed JWT assertions to request OAuth 2.0 access tokens. To accept signed JWT assertions, a trust relationship must be established between the external provider and Keycloak. This trust relationship can be configured through an identity provider in a dedicated section of the OpenID Connect v1.0 identity provider, or through the new JWT Authorization Grant identity provider. JWT Authorization Grant is recommended as an alternative to External to internal token exchange V1. This feature is in preview, and additional details are available in the dedicated documentation. Using Keycloak as an authorization server for Model Context Protocol (MCP) servers Using Keycloak as an authorization server for Model Context Protocol (MCP) servers is becoming popular, so this release ships additional documentation on how to do this. See Integrating with Model Context Protocol (MCP) for the new guide. Many thanks to Takashi Norimatsu for the contribution. CORS enhancements CORS (Cross Origin Resource Sharing) is a browser security feat ## A Modern Guide to Using OAuth 2.0 with C# and Visual Studio Code DevFeed: [A Modern Guide to Using OAuth 2.0 with C# and Visual Studio Code]() Original publisher: [Read original article]() Author: Dean Hume Published: 2025-11-03T10:45:24Z Content type: tutorial Language: en Sources: [Dean Hume]() Topics: [OAuth 2.0](), [C#](), [Visual Studio Code](), [.NET](), [Entra ID](), [API](), [Authorization]() Tags: [api](), [best-practices](), [c-sharp](), [code](), [entra-id](), [net](), [oauth](), [oauth-2-0](), [tutorial](), [visual-studio-code]() ### AI overview A practical tutorial on implementing OAuth 2.0 authentication in C# with Visual Studio Code and modern .NET libraries. It covers creating a console application, configuring OAuth settings, acquiring access tokens with MSAL, and calling protected APIs such as Microsoft Graph. ### Source excerpt Master OAuth 2.0 in .NET 9.0! This tutorial covers using OAuth 2 to acquire tokens and access Microsoft Graph user data. ## Official Support for DPoP in Keycloak 26.4 DevFeed: [Official Support for DPoP in Keycloak 26.4]() Original publisher: [Read original article]() Author: Giuseppe Graziano Published: 2025-10-09T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [OAuth 2.0](), [Security](), [private key](), [OpenID connect (OIDC)](), [Authorization](), [REST API]() Tags: [documentation](), [idm](), [kerberos](), [keycloak](), [ldap](), [oauth-2-0](), [oidc](), [openid-connect](), [private-key](), [release](), [rest-api](), [saml](), [security](), [sso]() ### AI overview Keycloak 26.4 officially supports OAuth 2.0 Demonstrating Proof-of-Possession (DPoP), which binds access or refresh tokens to a client-controlled public/private key pair. The release adds support across bearer-token endpoints, optional refresh-token-only binding for public clients, and the dpop_jkt parameter in OIDC authorization requests. ### Source excerpt DPoP has been available in Keycloak since version 23.0.0, but only as a preview feature. With the release of Keycloak 26.4, we're happy to share that OAuth 2.0 Demonstrating Proof-of-Possession (DPoP) is now officially supported. What is DPoP? πŸ”‘ DPoP is a Proof-of-Possession mechanism that improves OAuth token security by binding a token (access or refresh) to a public/private key pair controlled by the client. By requiring a signed DPoP proof with each request, DPoP ensures that a stolen bearer token cannot be used without possession of the associated private key. This significantly improves token security in distributed systems. What's New for DPoP in 26.4 πŸ†• DPoP is now a supported feature and includes some improvements and minor capabilities: Support for all Keycloak endpoints that accept bearer tokens, including the Admin REST API and the Account API. Option to bind only refresh tokens for public clients, while leaving access tokens as bearer if required. Ability to request the dpop_jkt parameter in OIDC authorization requests. For full details, see the official documentation. How to enable and use DPoP in Keycloak πŸš€ If you want to force a client to use DPoP, you need to enable the Require DPoP bound tokens switch in the Admin Console Settings tab under Capability config. If Require DPoP bound tokens is off, the client can still send a DPoP proof in the token request. In that case, Keycloak verifies it and adds the thumbprint to the token, but DPoP binding is not enforced. Try It Out πŸ” If you want to experiment with DPoP in practice, you can try it out using the Keycloak FAPI Playground, which includes example client configurations and test flows that demonstrate how DPoP works end-to-end. We'd love to hear what you think about this feature and how we can improve it. Feedback and contributions from the community are always welcome. ## Keycloak 26.4.0 released DevFeed: [Keycloak 26.4.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2025-09-30T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Passkeys](), [Security](), [OAuth 2.0](), [Specifications](), [SPIFFE](), [Kubernetes](), [OpenID connect (OIDC)](), [REST API](), [Availability]() Tags: [authentication](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [kubernetes](), [ldap](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [release](), [rest-api](), [saml](), [security](), [specifications](), [spiffe](), [sso](), [version]() ### AI overview Keycloak 26.4.0 introduces passkeys, federated client authentication using SPIFFE or Kubernetes service account tokens, support for final FAPI 2.0 specifications, and full DPoP support. The release also includes availability and administration improvements. ### Source excerpt To download the release go to Keycloak downloads. Highlights This release features new capabilities focused on security enhancements, deeper integration, and improved server administration. The highlights of this release are: Passkeys for seamless, passwordless authentication of users. Federated Client Authentication to use SPIFFE or Kubernetes service account tokens for client authentication. Simplified deployments across multiple availability zones to boost availability. FAPI 2 Final: Keycloak now supports the final specifications of FAPI 2.0 Security Profile and FAPI 2.0 Message Signing. DPoP: The OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) is now fully supported. Improvements include the ability to bind only refresh tokens for public clients, and securing all Keycloak endpoints with DPoP tokens. Read on to learn more about each new feature. If you are upgrading from a previous release, review also the changes listed in the upgrading guide. Security and Standards Passkeys integration (supported) Passkeys are now seamlessly integrated in the Keycloak login forms using both conditional and modal UIs. To activate the integration in the realm, go to Authentication, Policies, Webauthn Passwordless Policy and switch Enable Passkeys to enabled. For more information, see Passkeys. FAPI 2 Final (supported) Keycloak has support for the latest versions of FAPI 2 specifications. Specifications FAPI 2.0 Security Profile and FAPI 2.0 Message Signing are already promoted to Final and Keycloak supports them. Keycloak client policies support the final versions and corresponding client profiles for FAPI 2 are passing the FAPI conformance test suite. Apart from some very minor polishing of existing policies, Keycloak has new client profiles (fapi-2-dpop-security-profile and fapi-2-dpop-message-signing) for the clients that use DPoP and are intended to be FAPI 2 compliant. Thank you to Takashi Norimatsu for contributing this. For more details, see the ## Keycloak 26.3.0 released DevFeed: [Keycloak 26.3.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2025-07-03T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [releases](), [Authentication](), [Logging](), [Passkeys](), [WebAuthn](), [migration](), [OAuth 2.0](), [openid](), [Latency]() Tags: [authentication](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [latency](), [ldap](), [logging](), [migration](), [new-feature](), [oauth-2-0](), [openid-connect](), [otp](), [release](), [releases](), [saml](), [sso]() ### AI overview Keycloak 26.3.0 is a software release that adds supported 2FA recovery codes, simplifies WebAuthn and Passkeys registration and account linking, expands OAuth 2.0 and OpenID Connect connectivity, improves logging throughput and latency, and introduces experimental rolling updates for patch releases. ### Source excerpt To download the release go to Keycloak downloads. Highlights This release delivers advancements to optimize your system and improve the experience of users, developers and administrators: Account recovery with 2FA recovery codes, protecting users from lockout. Simplified experiences for application developers with streamlined WebAuthn/Passkey registration and simplified account linking to identity providers via application initiated actions. Broader connectivity with the ability to broker with any OAuth 2.0 compliant authorization server, and enhanced trusted email verification for OpenID Connect providers. Asynchronous logging for higher throughput and lower latency, ensuring more efficient deployments. For administrators, experimental rolling updates for patch releases mean minimized downtime and smoother upgrades. Read on to learn more about each new feature, and find additional details in the upgrading guide if you are upgrading from a previous release of Keycloak. Recovering your account if you lose your 2FA credentials When using for example a one-time-password (OTP) generators as a second factor for authenticating users (2FA), a user can get locked out of their account when they, for example, lose their phone that contains the OTP generator. To prepare for such a case, the recovery codes feature allows users to print a set of recovery codes as an additional second factor. If the recovery codes are then allowed as an alternative 2FA in the login flow, they can be used instead of the OTP generated passwords. With this release, the recovery codes feature is promoted from preview to a supported feature. For newly created realms, the browser flow now includes the Recovery Authentication Code Form as Disabled, and it can be switched to Alternative by admins if they want to use this feature. For more information about this 2FA method, see the Recovery Codes chapter in the Server Administration Guide. Performance improvements to import, export and migration The time ## Heroku AI: Heroku Remote MCP Server DevFeed: [Heroku AI: Heroku Remote MCP Server]() Original publisher: [Read original article]() Author: Anush DSouza Published: 2025-06-24T22:47:09Z Content type: release Language: en Sources: [Heroku]() Topics: [Heroku](), [MCP Server](), [Heroku AI](), [Model Context Protocol (MCP)](), [OAuth 2.0](), [Authentication](), [Claude](), [cursor](), [Visual Studio Code]() Tags: [agentforce](), [ai](), [authentication](), [claude](), [cursor](), [developer-tools](), [heroku](), [heroku-ai](), [mcp](), [mcp-on-heroku](), [mcp-server](), [news](), [oauth](), [oauth-2-0](), [remote-mcp-server](), [visual-studio-code]() ### AI overview Heroku introduces the Heroku Remote MCP Server, extending its earlier stdio-based server with remote access and OAuth 2.0 authentication. The article explains how agents and clients such as Claude, Agentforce, Cursor, and Visual Studio Code can connect to Heroku and use platform tools. ### Source excerpt Developers can easily scale how autonomous agents interact with infrastructure using the Heroku Remote MCP Server at https://mcp.heroku.com/mcp. This new remote server expands our earlier stdio-based MCP server and comes with secure OAuth authentication. It's provides a secure, scalable, and incredibly simple way for agents to interact with the Heroku platform and use tools to [...] The post Heroku AI: Heroku Remote MCP Server appeared first on Heroku. ## Standard Token Exchange is now officially supported in Keycloak 26.2 DevFeed: [Standard Token Exchange is now officially supported in Keycloak 26.2]() Original publisher: [Read original article]() Author: Giuseppe Graziano Published: 2025-05-26T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [OAuth 2.0](), [releases]() Tags: [idm](), [kerberos](), [keycloak](), [ldap](), [oauth-2-0](), [openid-connect](), [preview](), [release](), [rules](), [saml](), [scopes](), [settings](), [sso](), [standard](), [token]() ### AI overview Keycloak 26.2 officially supports Standard Token Exchange and complies with OAuth 2.0 Token Exchange (RFC 8693). The feature lets clients exchange tokens, configure exchanges through the Admin Console, and enforce rules with Client Policies. ### Source excerpt The Token Exchange feature has been available in Keycloak for a long time, but only as a preview feature. With the release of Keycloak 26.2, we're happy to share that Standard Token Exchange is now officially supported and fully compliant with OAuth 2.0 Token Exchange (RFC 8693). What is Token Exchange? πŸ”„ Token Exchange is a mechanism that allows a client to exchange one token for another. In the context of Keycloak, this means a client can exchange a token originally issued for another client and receive a new token issued specifically for itself. Token Exchange is especially helpful in these scenarios: 🎯 Different Audience When a token was issued for one service but needs to be used to access another, Token Exchange can issue a new token with the appropriate audience. πŸ” Scoped Permissions If a client needs to access a service with more limited permissions, it can exchange its token for one with reduced or more specific scopes. What's new? πŸ†• βœ… Official support (no longer a preview feature) πŸ“˜ Compliance with RFC 8693 (OAuth 2.0 Token Exchange) πŸ–± Simple configuration via the Admin Console (just a switch in client settings) πŸ›‘ Integration with Client Policies to enforce custom rules. You can restrict exchanges to specific clients, or deny exchanges based on requested scopes. How to get started πŸš€ If you're using Keycloak 26.2 or later, there's nothing extra to enable. Token Exchange is ready to use, just open the client settings in the admin console and enable the dedicated switch. If you're still using the preview feature of token exchange, check the migration guide and the comparison to understand the differences and plan your migration. πŸ“„ For full setup instructions and configuration details, refer to the official documentation. What's next? πŸ” We're continuing to expand Token Exchange support with future enhancements such as: πŸ”„ Exchanging tokens issued by external identity providers πŸ‘€ Using token exchange to impersonate users Stay tuned for updates in upcoming rele ## Keycloak 25.0.0 released DevFeed: [Keycloak 25.0.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2024-06-10T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [releases](), [Release notes](), [version](), [upgrade](), [Java](), [OAuth 2.0](), [OpenID connect (OIDC)](), [Primer](), [saml](), [Security]() Tags: [deprecated](), [design-system](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [openjdk](), [release](), [release-notes](), [saml](), [security](), [sso](), [upgrade](), [version]() ### AI overview Keycloak 25.0.0 removes the Account Console v2 theme and most Java adapters, adds OpenJDK 21 support while deprecating OpenJDK 17, updates the consoles to PatternFly 5, and makes Argon2 the default password-hashing algorithm outside FIPS environments. ### Source excerpt To download the release go to Keycloak downloads. Highlights Account Console v2 theme removed The Account Console v2 theme has been removed from Keycloak. This theme was deprecated in Keycloak 24 and replaced by the Account Console v3 theme. If you are still using this theme, you should migrate to the Account Console v3 theme. Java 21 support Keycloak now supports OpenJDK 21, as we want to stick to the latest LTS OpenJDK versions. Java 17 support is deprecated OpenJDK 17 support is deprecated in Keycloak, and will be removed in a following release in favor of OpenJDK 21. Most of Java adapters removed As stated in the release notes of previous Keycloak version, the most of Java adapters are now removed from the Keycloak codebase and downloads pages. For OAuth 2.0/OIDC, this includes removal of the Tomcat adapter, WildFly/EAP adapter, Servlet Filter adapter, KeycloakInstalled desktop adapter, the jaxrs-oauth-client adapter, JAAS login modules, Spring adapter and SpringBoot adapters. You can check our older post for the list of some alternatives. For SAML, this includes removal of the Tomcat adapter and Servlet filter adapter. SAML adapters are still supported with WildFly and JBoss EAP. The generic Authorization Client library is still supported, and we still plan to support it. It aims to be used in combination with any other OAuth 2.0 or OpenID Connect libraries. You can check the quickstarts for some examples where this authorization client library is used together with the 3rd party Java adapters like Elytron OIDC or SpringBoot. You can check the quickstarts also for the example of SAML adapter used with WildFly. Upgrade to PatternFly 5 In Keycloak 24, the Welcome page is updated to use PatternFly 5, the latest version of the design system that underpins the user interface of Keycloak. In this release, the Admin Console and Account Console are also updated to use PatternFly 5. If you want to extend and customize the Admin Console and Account Console, review the ch [Next page]()