# openid OpenID is a decentralized authentication protocol that lets users prove control of an identifier without sharing credentials with relying parties. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Ktor 3.6.0 Is Now Available! DevFeed: [Ktor 3.6.0 Is Now Available!]() Original publisher: [Read original article]() Author: Simon Vergauwen Published: 2026-09-18T10:45:56Z Content type: release Language: en Sources: [The JetBrains Blog]() Topics: [Ktor](), [Kotlin](), [Netty](), [Authentication](), [HTTP](), [openid](), [multiplatform](), [clients](), [Routing (disambiguation)]() Tags: [authentication](), [clients](), [http](), [http-3](), [kotlin](), [kotlin-multiplatform](), [ktor](), [news](), [openid](), [quic](), [release](), [releases](), [routing](), [server]() ### AI overview Ktor 3.6.0 introduces experimental typed authentication with OpenID Connect support and HTTP/3 over QUIC for the Netty engine. The release also improves routing, request handling, and Kotlin Multiplatform client defaults. ### Source excerpt Ktor 3.6.0 is here! This release is full of new experimental features, including typed authentication capabilities with specialized support for OpenID Connect and HTTP/3 support for the Netty engine. There are also a few quality-of-life improvements for routing and request handling, more convenient defaults for Kotlin Multiplatform clients, and more. Check out What's new in [...] ## 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 ## 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 ## From Contributor to Outreachy Intern: My Fedora Journey Begins DevFeed: [From Contributor to Outreachy Intern: My Fedora Journey Begins]() Original publisher: [Read original article]() Author: Aman . Published: 2026-06-16T12:00:00Z Content type: article Language: en Sources: [Fedora Community Blog]() Topics: [Fedora](), [FastAPI](), [API](), [release engineering](), [Authentication](), [CI/CD](), [forgejo](), [Pydantic](), [Swagger](), [Deployment](), [openid]() Tags: [apis](), [backend](), [blog](), [fedora-project-community](), [intern](), [journey](), [mentored-projects](), [open-source](), [outreachy]() ### AI overview Aman describes his first two weeks as an Outreachy intern with the Fedora community. He introduces the Fedora Release Schedule Planner API project and outlines planned work on testing, CI reliability, OpenID Connect authentication, Fedora infrastructure integration, and deployment preparation. ### Source excerpt Introduction Hi, I'm Aman, a software developer and open-source enthusiast who enjoys backend development, APIs, and building tools that are useful to others. I recently started my Outreachy internship with the Fedora community, and this is my first blog as an intern. In this post, I want to share what my first two weeks have [...] The post From Contributor to Outreachy Intern: My Fedora Journey Begins appeared first on Fedora Community Blog. ## Keycloak experimental AuthZEN Support DevFeed: [Keycloak experimental AuthZEN Support]() Original publisher: [Read original article]() Author: Ryan Emerson Published: 2026-05-20T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Authorization](), [openid](), [API](), [REST API](), [interoperability](), [vendor lock-in]() Tags: [authentication](), [changes](), [idm](), [interoperability](), [kerberos](), [keycloak](), [ldap](), [openid-connect](), [release](), [resource](), [rest-api](), [saml](), [sdks](), [sso](), [vendor-lock-in](), [works]() ### AI overview Keycloak announces experimental support for the OpenID AuthZEN Authorization API 1.0 specification starting with version 26.7.0. The feature lets Keycloak act as a Policy Decision Point and expose existing authorization policies through a standardized API for Policy Enforcement Points. ### Source excerpt We are excited to announce that from 26.7.0, Keycloak will include experimental support for the OpenID AuthZEN Authorization API 1.0 specification. This allows Keycloak to act as a Policy Decision Point (PDP), exposing its authorization capabilities through a standardized API that any Policy Enforcement Point (PEP) can consume. You can try this now with the Keycloak nightly release. Why AuthZEN? Authorization has long been fragmented, with competing systems defining their own protocols for answering the same fundamental question: "Can this subject perform this action on this resource?". This means applications are tightly coupled to whichever authorization backend they choose, and swapping providers requires rewriting integration code. AuthZEN changes this by defining a single, vendor-neutral API between the component that asks (the PEP) and the component that decides (the PDP). It is, in many ways, what OpenID Connect did for authentication -- but for authorization. With AuthZEN: No more vendor lock-in -- your application speaks one API regardless of the PDP behind it. RBAC, ABAC, and ReBAC under one roof -- different policy models can answer the same request format, enabling true interoperability across authorization paradigms. Centralized, externalized authorization -- policy logic lives in the PDP, not scattered across application code, making it easier to audit and update. Simpler integration -- a clean REST API with a minimal request/response model replaces complex, implementation-specific SDKs. A growing ecosystem OpenID AuthZEN Interop demonstrates that over a dozen independently-developed PDPs can be used interchangeably by the same PEP without changing a single line of application code. By adding AuthZEN support, Keycloak joins this ecosystem and lets you leverage your existing Keycloak policies through the same standardized API used by every other AuthZEN-compatible PDP. How it works The interaction between your application and Keycloak follows the standard PE ## 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 ## Keycloak Federated Client Authentication with External Identity Providers DevFeed: [Keycloak Federated Client Authentication with External Identity Providers]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2026-01-26T00:00:00Z Content type: tutorial Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Authentication](), [JSON Web Tokens](), [openid](), [SPIFFE](), [Kubernetes](), [trust]() Tags: [authentication](), [idm](), [jwt](), [kerberos](), [keycloak](), [kubernetes](), [ldap](), [lookup](), [openid](), [openid-connect](), [saml](), [signing](), [spiffe](), [sso](), [token](), [verify]() ### AI overview Keycloak's federated client authentication lets OpenID Connect clients authenticate through external identity providers such as OpenID Connect, SPIFFE, and Kubernetes. The article explains trust relationships, JWT claims, token verification, and how this can reduce the need for client-managed secrets in some environments. ### Source excerpt Keycloak has from day one supported identity brokering, allowing users to authenticate via an external OpenID Connect or SAML 2.0 identity provider. With federated client authentication it is now possible to authenticate OpenID Connect clients through external identity providers as well. Depending on the environment the clients is running in this can eliminate the need for managing secrets for clients altogether. A number of cloud vendors for example support injecting tokens automatically for workloads, Kubernetes have support for service accounts, and last but not least there is SPIFFE that can be leveraged in most environments. How does federated client authentication work? The first step to setting up federated client authentication is to define a trust relationship between Keycloak and the external identity providers. This is done by creating a new identity provider in the realm. Keycloak currently has three types of identity providers that support federated client authentication: OpenID Connect SPIFFE Kubernetes Clients can retrieve a token from the external identity providers that the client can then use to authenticate with Keycloak. In many cases clients can retrieve these tokens automatically through workload identity capabilities enabled for particular environments. Let's look at an example decoded JWT that can be used to authenticate a client: { "iss" : "https://my-external-idp" "aud" : [ "http://my-keycloak/realms/myrealm" ], "exp" : 1769149961, "iat" : 1769149661, "sub" : "client-id-in-my-external-idp" } The most relevant claims are iss, aud and sub. Keycloak uses the iss claim to identity the external party that issued the token as well as retrieving the external parties signing keys to verify the token. The aud claim is to make sure the token was issued to be used by Keycloak and not other applications. It is important that this contains a single audience that uniquely identifies Keycloak as the target audience, as leaking this token to other parties ## 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 ## Meet Keycloak at KubeCon India in August DevFeed: [Meet Keycloak at KubeCon India in August]() Original publisher: [Read original article]() Author: Alexander Schwartz Published: 2025-06-12T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Extension](), [Authentication](), [openid]() Tags: [2025](), [3](), [authentication](), [contributors](), [extensions](), [github](), [idm](), [india](), [kerberos](), [keycloak](), [kubecon](), [ldap](), [location](), [maintainers](), [openid-connect](), [saml](), [sso](), [table]() ### AI overview Keycloak will participate in KubeCon + CloudNativeCon India 2025 in Hyderabad. The article lists talks on custom access tokens and OpenID Connect, and gives times and location details for meeting Keycloak maintainers and contributors at the project table. ### Source excerpt Last year's KubeCon India was a great success, and Keycloak will be part of this year's edition in Hyderabad on August 7-8. Register today to get tickets for the standard rate. A lot of people use Keycloak and develop extensions in for Keycloak in India, so we are thrilled to connect with the community. Connect with me in this GitHub discussion to have your contributions or projects mentioned in the talk! & '' ## Keycloak at KubeCon EU 2025 DevFeed: [Keycloak at KubeCon EU 2025]() Original publisher: [Read original article]() Author: Ryan Emerson Published: 2025-04-16T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [identity and access management](), [observability](), [openid](), [Single sign-on (SSO)]() Tags: [2025](), [cncf](), [community](), [iam](), [identity-and-access-management](), [idm](), [kerberos](), [keycloak](), [kubecon](), [kubecon-eu](), [ldap](), [observability](), [openid](), [openid-connect](), [saml](), [sso]() ### AI overview Keycloak recaps its presence at KubeCon EU 2025 in London, including its project pavilion, conversations with users, and a talk on the evolution of OpenID Connect and observability in Keycloak. The post also invites user feedback and highlights upcoming Keycloak community events in Japan. ### Source excerpt Keycloak had a very active presence at this year's KubeCon EU in London. This blog presents a few of the highlights as well as ways you can contribute to Keycloak's CNCF journey. Project Pavilion Keycloak hosted a project pavilion stand during Wednesday, Thursday and Friday afternoon slots. Attending the booth were Keycloak contributors Takashi Norimatsu and Yoshiyuki Tabata from Hitachi, alongside Martin Bartos and Ryan Emerson from Red Hat. During these sessions, we had the opportunity to connect with both existing and prospective Keycloak users to talk all things related to Identity and Access Management. Keycloak stickers were as popular as ever, with both the CNCF sticker wall and our own stash completely emptied! It was fantastic to hear firsthand feedback - what's working well and where there's room for improvement. Insights like these are invaluable as we continue to grow the project and shape the future roadmap. If you weren't able to stop by the pavilion, we'd still love to hear from you, please feel free to share your thoughts via the online feedback form. Keycloak Talk Takashi Norimatsu and Ryan Emerson presented a talk titled "Evolving OpenID Connect and Observability in Keycloak". Watch the recording to hear about how OpenID Connect and observability have evolved over the past year in the Keycloak project. A video of the talk is linked below. Thank you to all who attended and asked questions, there were good follow-up conversations that continued well after our time was up. Keycloak Survey Are you a Keycloak user who is deploying in production or just considering starting with Keycloak? We would love to hear more from you about your success stories, what is crucial to your deployments and what can be done better. Please fill out the online Keycloak Survey so we can better understand your use cases. Your story maybe a candidate for a CNCF Case Study. If you would like to share your success story with our community, answer yes to the "Would you be intere ## Meet Keycloak at KubeCon EU, London in April 2025 DevFeed: [Meet Keycloak at KubeCon EU, London in April 2025]() Original publisher: [Read original article]() Author: Ryan Emerson Published: 2025-03-08T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [openid](), [observability]() Tags: [2025](), [idm](), [kerberos](), [keycloak](), [kubecon](), [kubecon-eu](), [ldap](), [london](), [observability](), [openid-connect](), [saml](), [sso]() ### AI overview Keycloak announces its participation in KubeCon Europe in London from April 1-4, 2025, including a Project Pavilion kiosk and a talk on evolving OpenID Connect and observability in Keycloak. ### Source excerpt We are thrilled to announce that Keycloak will be at KubeCon Europe, London April 1-4th 2025. Keycloak's presence at previous KubeCons was a huge success, and we are always eager to meet Keycloak enthusiasts, users and newcomers alike. At this year's event we will be hosting a Kiosk in the Project Pavilion, as well as presenting a talk about Evolving OpenID Connect and Observability. Keycloak community Meet & Greet at the Project Pavilion Takashi Norimatsu from Hitachi, Ryan Emerson and Martin Bartos from Red Hat, and other contributors will be hosting a Keycloak kiosk at the Project Pavilion. This is a great chance to meet people who use Keycloak, contribute to Keycloak, take our survey about new Keycloak features, and get some cool swag! Keycloak Kiosk (booth 17A) opening hours: Wednesday, April 2: 15:30 - 19:45 Thursday, April 3: 14:00 - 17:00 Friday, April 4: 12:30 - 14:00 Presenting evolving OpenID Connect and Keycloak Observability Takashi Norimatsu and Ryan Emerson will be presenting a talk on Evolving OpenID Connect and Observability in Keycloak. Friday, April 4, 14:30 - 15:00pm Evolving OpenID Connect and Observability in Keycloak By Takashi Norimatsu, Hitachi & Ryan Emerson, Red Hat. Related Talks Keycloak has a powerful community in Japan, and we have received several contributions in the past. One of Keycloak's maintainers, Takashi Norimatsu, is based in Japan. There is also a quite popular Japanese book about Keycloak Authentication and Authorization by Yuichi Nakamura and Japanese community colleagues that will soon appear in its second edition. To learn more about community activities in Japan, join the following talk: Thursday April 3, 2025 14:15 - 14:45 Cloud Native Communities in Action: How Japan Shaped Its Path To KubeCon By Ota Kohei, Apple; Shu Muto, NEC Solution Innovators, Ltd.; Yuichi Nakamura, Hitachi, Ltd.; Sunyanan Choochotkaew, IBM Research; Noriaki Fukuyasu, The Linux Foundation See you soon! We're preparing for KubeCon EU 2025 and can' ## New videos about OpenID Connect and Keycloak from FOSDEM 2025 DevFeed: [New videos about OpenID Connect and Keycloak from FOSDEM 2025]() Original publisher: [Read original article]() Author: Alexander Schwartz Published: 2025-02-25T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [FOSDEM](), [Keycloak](), [openid](), [IAM]() Tags: [2025](), [fosdem](), [idm](), [kerberos](), [keycloak](), [ldap](), [openid-connect](), [saml](), [sso](), [videos]() ### AI overview Keycloak announces that recordings of four FOSDEM 2025 talks related to Keycloak and OpenID Connect are available to watch online. The article also describes Keycloak's community presence at the event and highlights a talk on OAuth 2.0 Demonstrating Proof-of-Possession (DPoP), including its implementation with Keycloak and other open source components. ### 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 talks regarding OpenID Connect and Keycloak have been recorded, and are now available online to re-watch. See below for the links to the videos. Meeting the Keycloak community on-site As an incubating project of the Cloud Native Computing Foundation (CNCF), we were happy to share the space of their stand. During the two days, we met with hundreds of existing Keycloak users on-site, as well as with people new to the IAM and identity space. It was fun and exciting to learn what people are doing. We would love to hear more from you about your success stories, what is crucial to your deployments and what can be done better. Fill out the online Keycloak Survey, so we can better understand your use cases, and if you want to share your experience with the wider Keycloak community. ## Vulnerability in long deprecated OpenID authentication method in Flask AppBuilder DevFeed: [Vulnerability in long deprecated OpenID authentication method in Flask AppBuilder]() Original publisher: [Read original article]() Author: Apache Airflow Published: 2024-02-26T00:00:00Z Content type: article Language: en Sources: [Apache Airflow Blog]() Topics: [vulnerability](), [Authentication](), [airflow](), [Flask](), [openid](), [deprecated](), [OpenID connect (OIDC)]() Tags: [airflow](), [authentication](), [deprecated](), [flask](), [openid](), [upgrade](), [version](), [vulnerabilities](), [vulnerability]() ### AI overview This article describes a vulnerability in Flask AppBuilder's long-deprecated OpenID authentication method. Users with AUTH_OID configured could be exposed to identity takeover through a forged request and an attacker-controlled OpenID service. The article recommends switching authentication methods or upgrading to Apache Airflow 2.8.2, which uses Flask AppBuilder 4.3.11. ### Source excerpt Vulnerability in long deprecated OpenID authentication method in Flask AppBuilder Recently Islam Rzayev made us aware of a vulnerability in the long deprecated OpenID authentication method in Flask AppBuilder. This vulnerability allowed a malicious user to take over the identity of any Airflow UI user by forging a specially crafted request and implementing their own OpenID service. While this is an old, deprecated and almost not used authentication method, we still took the issue seriously. This issue ONLY affects users who have AUTH_OID set in their webserver_config.py file as AUTH_TYPE. This is a very old and deprecated authentication method that is unlikely to be used by anyone. We would like to advise even the small number of our users that still use this authentication method to take an immediate action and either upgrade to Apache Airflow 2.8.2 or switch to another authentication method (or apply a workaround we provide if they cannot do either of the above immediately). Important to stress, because many of the users might get confused by the name, OpenID is NOT the same as OpenID Connect. Those are completely different protocols and while OpenID Connect (also known as OIDC) is a modern, widely used protocol, OpenID is a legacy protocol that has been deprecated more than 10 years ago and since then has been abandoned by almost everyone in the community, including all services in Flask AppBuilder example services that supported it, so it is highly unlikely someone is still using it. Due to this highly unlikely configuration the Flask AppBuilder CVE is just "Moderate" not "Critical". It affects a very small (if any) number of users and it's not likely to be a target for an attack. However, we still advise our users who still use AUTH_OID to apply remediation. This vulnerability is fixed in Flask Appbuilder 4.3.11 and Apache Airflow 2.8.2 uses that version of Flask Application Builder. We advise users who still use this authentication method to either switch to a ## Keycloak 23.0.0 released DevFeed: [Keycloak 23.0.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2023-11-23T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [OAuth 2.0](), [openid](), [Passkeys](), [WebAuthn](), [Authentication](), [Security]() Tags: [idm](), [improvements](), [interoperability](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oauth](), [oauth-2-0](), [openid](), [openid-connect](), [release](), [saml](), [security](), [sso]() ### AI overview Keycloak 23.0.0 adds support for FAPI 2 draft client profiles, previews DPoP and Passkeys, expands introspection endpoint flexibility, adds a feature flag for the OAuth 2.0 device authorization grant, and improves WebAuthn interoperability. ### Source excerpt To download the release go to Keycloak downloads. Highlights OpenID Connect / OAuth 2.0 FAPI 2 drafts support Keycloak has new client profiles fapi-2-security-profile and fapi-2-message-signing, which ensure Keycloak enforces compliance with the latest FAPI 2 draft specifications when communicating with your clients. Thanks to Takashi Norimatsu for the contribution. DPoP preview support Keycloak has preview for support for OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP). Thanks to Takashi Norimatsu and Dmitry Telegin for their contributions. More flexibility for introspection endpoint In previous versions, introspection endpoint automatically returned most claims, which were available in the access token. Now there is new switch Add to token introspection on most of protocol mappers. This addition allows more flexibility as introspection endpoint can return different claims than access token. This is first step towards "Lightweight access tokens" support as access tokens can omit lots of the claims, which would be still returned by the introspection endpoint. When migrating from previous versions, the introspection endpoint should return same claims, which are returned from access token, so the behavior should be effectively the same by default after the migration. Thanks to Shigeyuki Kabano for the contribution. Feature flag for OAuth 2.0 device authorization grant flow The OAuth 2.0 device authorization grant flow now includes a feature flag, so you can easily disable this feature. This feature is still enabled by default. Thanks to Thomas Darimont for the contribution. Authentication Passkeys support Keycloak has preview support for Passkeys. Passkey registration and authentication are realized by the features of WebAuthn. Therefore, users of Keycloak can do passkey registration and authentication by existing WebAuthn registration and authentication. Both synced passkeys and device-bound passkeys can be used for both Same-Device and Cr ## FAPI-SIG - a Keycloak's community DevFeed: [FAPI-SIG - a Keycloak's community]() Original publisher: [Read original article]() Author: Takashi Norimatsu Published: 2022-07-01T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [API](), [OAuth 2.0](), [Security](), [openid](), [Specifications]() Tags: [api](), [banking](), [community](), [healthcare](), [idm](), [kerberos](), [keycloak](), [ldap](), [oauth-2-0](), [openid](), [openid-connect](), [saml](), [security](), [specifications](), [sso](), [standards](), [tests]() ### AI overview This article introduces FAPI-SIG, a Keycloak community focused on supporting and validating Financial-grade API security profiles. It describes automated conformance testing for FAPI and other OpenID Foundation standards, and notes Keycloak certifications in several profiles and regions. ### Source excerpt Hello everybody, I am Takashi Norimatsu, a keycloak maintainer. In this article, I would like to introduce you FAPI-SIG, a Keycloak's community. We welcome everyone to join FAPI-SIG. What is FAPI-SIG? The Financial-grade API Special Interest Group (FAPI-SIG) is a Keycloak's community whose aim is to support security features called Financial-grade API (FAPI) security profiles to Keycloak. FAPI-SIG was established in Aug 2020. FAPI security profiles are the open security specifications for secure API access using OAuth 2.0. They are standardized by OpenID Foundation (OID-F), the standardization organization about digital identity. For example, it standardized OpenID Connect. FAPI security profiles are for accessing an API that requires high security level. As its name suggests (Financial), they are originally intended to be used for securely accessing an API providing financial services (e.g., retrieving the balance of a user's bank account, initiating payment). However, also as its name suggests (Financial-grade), these can be used for other types of an API that requires the same security level (e.g., in healthcare industries, retrieving a user's medical records). By supporting FAPI security profiles, Keycloak can be applied in a wide range of use cases that requires high security level about API access (e.g., open banking). FAPI-SIG not only aim to support FAPI security profiles to Keycloak but confirm that Keycloak conforms to FAPI security profiles by using the conformance suite of FAPI security profiles officially provided by OID-F. FAPI-SIG has created the environment for automatically running FAPI security conformance tests. Whenever a new version of Keycloak is released, FAPI-SIG checks if it still complies with FAPI security profiles by using the environment. Therefore, FAPI-SIG contributes to keeping every version of Keycloak compliant to FAPI security profiles. FAPI-SIG start working on supporting security standards defined by OID-F other than FAPI securit ## New Keycloak certifications DevFeed: [New Keycloak certifications]() Original publisher: [Read original article]() Author: Marek Posolda Published: 2022-05-30T00:00:00Z Content type: news Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [openid](), [Protocol (disambiguation)]() Tags: [australia](), [idm](), [kerberos](), [keycloak](), [ldap](), [openid](), [openid-connect](), [protocol](), [saml](), [sso]() ### AI overview Keycloak announces new and renewed certifications for OpenID Connect, OpenID Connect Logout, FAPI, and Australia CDR. Keycloak 18.0.0 received renewed OpenID Connect Provider certification and new logout-provider certification, while Keycloak 15.0.2 received Australia CDR certification. ### Source excerpt We are glad to announce new certifications for Keycloak related to the OpenID Connect and FAPI! In the previous post, we announced certification of Keycloak 15.0.2 with the FAPI and Brazil Open Banking. This is a follow-up of this post with the announcement of the additional certifications. Here are the details: Keycloak 18.0.0 is re-certified as OpenID Connect Provider. We already obtained certification for the OpenID Connect protocol a long time ago with the Keycloak 2.3.0. We now re-certified all the existing configurations (Basic, Implicit, Hybrid, Config, Dynamic) with latest Keycloak 18.0.0 and added certification as a Form Post OP. See the OpenID Connect certifications page for the details. Keycloak 18.0.0 is certified as OpenID Connect Logout Provider with all logout profiles (RP-Initiated OP, Session OP, Front-Channel OP, Backchannel OP). See the OpenID Connect certifications page (logout section) for the details. Keycloak 15.0.2 is certified as Australia CDR, which is the extension based on existing FAPI 1 Advanced Final certification, which Keycloak already obtained before. See the FAPI certifications page for the details. This milestone was achieved due the hard work of the awesome Keycloak community, who contributed lots of features related to OpenID Connect Protocol, OpenID Connect Logout and FAPI. The special Thanks go to the FAPI-SIG, who helped a lot with the FAPI and OpenID Connect related features and especially to Takashi Norimatsu, who is doing an awesome job for the Keycloak project. ## Keycloak release plans for 2022 DevFeed: [Keycloak release plans for 2022]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2022-03-24T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [releases](), [Quarkus](), [Kubernetes](), [PostgreSQL](), [CockroachDB](), [openid](), [saml]() Tags: [cockroachdb](), [deprecated](), [end-of-life](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [kubernetes](), [ldap](), [openid-connect](), [postgresql](), [quarkus](), [release](), [releases](), [saml](), [sso]() ### AI overview Keycloak's provisional 2022 release plan aims for quarterly feature releases with more frequent patch releases. It outlines planned changes across Keycloak 18, 19, and 20, including Quarkus and Kubernetes Operator previews, console and store changes, migration support, and removal of deprecated components and adapters. ### Source excerpt December last year was a bit on the crazy side with 3 feature releases of Keycloak (15.1, 16.0, and 16.1). This was down to balancing WildFly upgrades with introduction of the Quarkus dist preview. This year we are planning to bring more predictability to Keycloak releases and are aiming for a quarterly release, with more frequent patch releases in-between. One thing worth highlighting is we have decided to extend the support of the WildFly distribution until September to give everyone more time to migrate. Subject to change: this is a provisional plan, which may change throughout the year. Keycloak 18 - March/April Highlights Enhancements and polishing for the Quarkus distribution Preview of the new Kubernetes Operator for the Quarkus distribution Preview of the new Admin Console Upgrade to Quarkus 2.8.0 Upgrade to WildFly 26.1.0 End of life Ability to upload custom JavaScript providers through REST APIs will be removed Keycloak 19 - June/July Highlights Preview of the new Store New Admin Console is graduated to the default console, while the old Admin Console is deprecated End of life Old Account Console will be removed, but the new Account Console will remain of course Text-based login flows and authenticators will be removed Some OpenID Connect adapters will be removed (adapter deprecation blog post), including: JBoss AS 7 and EAP 6 Fuse 6 and 7 Jetty 9.2 and 9.3 WildFly legacy WildFly Galleon feature pack Some SAML adapters will be removed, including: JBoss AS 7 and EAP 6 Jetty 9.2 and 9.3 WildFly legacy Keycloak 20 - September/October Highlights New store is graduated to the new default store for PostgreSQL and CockroachDB. We will come back with more details on what happens with the old store and support for other database vendors, but rest assured we will give everyone plenty of heads up, and at the minimum the old store will be supported at least until the middle of 2023. End of life WildFly distribution will be removed Legacy Kubernetes Operator will be re ## Authentication Best Practices DevFeed: [Authentication Best Practices]() Original publisher: [Read original article]() Author: sakshyam.shah@goteleport.com (Sakshyam Shah) Published: 2022-02-25T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Authentication](), [passwords](), [Security](), [Single sign-on (SSO)](), [OAuth 2.0](), [openid](), [saml](), [Vulnerabilities](), [WebAuthn](), [password reset]() Tags: [authentication](), [best-practices](), [blog](), [blog-post](), [hardware](), [oauth2](), [openid](), [saml](), [security](), [sso](), [tokens]() ### AI overview A guide to authentication best practices, including prioritizing passwordless authentication, using federated login and single sign-on, and hardening authentication functionality. It notes that security depends on correctly implementing the relevant standards and processes. ### Source excerpt Learn about authentication best practices such as prioritizing passwordless authentication and implementing federated login with 2fa in this comprehensive blog post. ## Deprecation of Keycloak adapters DevFeed: [Deprecation of Keycloak adapters]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2022-02-04T00:00:00Z Content type: opinion Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [OAuth 2.0](), [openid](), [migration](), [Node.js](), [Quarkus]() Tags: [deprecated](), [idm](), [integration](), [kerberos](), [keycloak](), [ldap](), [migration](), [node-js](), [oauth-2-0](), [openid](), [openid-connect](), [quarkus](), [saml](), [sso]() ### AI overview Keycloak announces the deprecation of its OpenID Connect Java and Node.js adapters and SAML Tomcat and Jetty adapters. The project will focus more on the Keycloak server while providing guidance on alternatives and migration. The client-side JavaScript adapter and selected SAML integrations are not being deprecated. ### Source excerpt Way back in 2013 when we started work on the Keycloak project there was a lack of client libraries that would help developers secure their applications with Keycloak. Fast forward to today and this situation has changed drastically with wide-spread availability of OAuth 2.0 and OpenID Connect libraries. In addition, Keycloak adapters has not received the love and attention they require, and are now significantly lagging behind the server on what features they supported. While Keycloak can be used to secure any application no matter the programming language and frameworks, we've only had adapters for a limited set of Java developers. Rather than continue to spreading ourselves thin we are going to deprecate the adapters, and focus more on the Keycloak server. In addition we are aiming to provide help and guidance on how to secure various applications with getting started guides, and advocating what we believe are better alternative options to Keycloak adapters. What is being deprecated: OpenID Connect Java adapters OpenID Connect Node.js adapters SAML Tomcat and Jetty adapters What is not being deprecated: OpenID Connect client-side JavaScript adapter SAML WildFly and servlet filter Alternatives WildFly WildFly 25 introduced native support for OpenID Connect with all the features from the Keycloak adapter and more. Migration to the WildFly native OpenID Connect is very easy as the WildFly team has taken great care to make this as simple as a move as possible. Check out this great blog post from Farah Juma for more details. Spring Spring Security has for a long time provided great support for OAuth 2.0 and OpenID Connect. We appreciate that migrating from the Keycloak adapters to Spring Security is not trivial, but in the exchange you get more features, a better maintained library, and better integration with Spring. Check out this great blog post from Ger Roza for more details. Quarkus Although not a direct replacement for existing Keycloak adapters it is worth highl ## Keycloak certified as FAPI and Brazil Open Banking provider DevFeed: [Keycloak certified as FAPI and Brazil Open Banking provider]() Original publisher: [Read original article]() Author: Marek Posolda Published: 2022-01-06T00:00:00Z Content type: news Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Authentication](), [openid](), [API]() Tags: [authentication](), [brazil](), [financial](), [idm](), [kerberos](), [keycloak](), [ldap](), [openid](), [openid-connect](), [saml](), [sso]() ### AI overview Keycloak 15.0.2 was officially certified as a Financial-grade API (FAPI) OpenID Provider and as a Brazil Open Banking provider. The article notes that DCR certification was not obtained for the Brazil Open Banking profile, while some RH-SSO 7.5 customers obtained it independently. ### Source excerpt We are glad to announce that Keycloak 15.0.2 was officially certified as FAPI OpenID Provider! FAPI is a shortcut for Financial-grade API and the FAPI compliance means that Keycloak is now officially able to be used in the highly confidential financial based deployments. Firstly, Keycloak is now certified as FAPI 1 Advanced Final (Generic) provider. For this generic profile, Keycloak is compliant with all the matrix combinations. This means that Keycloak clients are allowed to use PAR, JARM, and client authentication based on Mutual-TLS or JSON Web Token signed by Private Key. Keycloak is also certified as Brazil Open Banking provider. For this profile, Keycloak is also compliant with all the matrix combinations. We just did not obtain certification for the DCR, which requires more complicated setup including registration with official Brazil institutions. However some Brazil banks, which are customers of Keycloak based product RH-SSO 7.5, were able to obtain DCR certification. So technically, the certification with DCR for any institution using Keycloak or RH-SSO is completely fine. You can see the Official OpenID Page with the details about the certification. For more details about FAPI support, you can check the Keycloak documentation with the details to setup your own Keycloak deployment to be FAPI compliant. Keycloak 15.0.2 is also compliant with FAPI CIBA and we are working to officially obtain the certification for this. Moreover, We plan to re-certify Keycloak 15.0.2 with OpenID Connect Core, which Keycloak certified back in 2016. The FAPI certification was possible just due the awesome work of the FAPI Working Group. Members of this group contributed many features related to FAPI, like Client Policies, CIBA, PAR, JARM and others. I hope that year 2022 will be at least as successful as 2021 and there will be even more contributions related to the FAPI as there are more standards being made and more certifications to be obtained. If you are interested in cont ## How to Integrate Keycloak for Authentication with Apache APISIX DevFeed: [How to Integrate Keycloak for Authentication with Apache APISIX]() Original publisher: [Read original article]() Author: Xinxin Zhu & Yilin Zeng Published: 2021-12-21T00:00:00Z Content type: tutorial Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Authentication](), [gateway](), [API](), [openid](), [OAuth 2.0]() Tags: [api-gateway](), [authentication](), [how-to](), [idm](), [kerberos](), [keycloak](), [ldap](), [oauth-2-0](), [open-source](), [openid-connect](), [saml](), [sso]() ### AI overview A tutorial explains how to use Keycloak with Apache APISIX for centralized authentication through OpenID Connect. It covers Keycloak capabilities, APISIX's OpenID Connect plugin, required dependencies, and installation steps for several operating systems, Docker, and Helm. ### Source excerpt This article shows you how to use OpenID-Connect protocol and Keycloak for identity authentication in Apache APISIX through detailed steps. Keycloak is an open source identity and access management solution for modern applications and services. Keycloak supports Single-Sign On, which enables services to interface with Keycloak through protocols such as OpenID Connect, OAuth 2.0, etc. Keycloak also supports integrations with different authentication services, such as Github, Google and Facebook. In addition, Keycloak also supports user federation, and can import users through LDAP and Kerberos. For more information about Keycloak, please refer to the official documentation. Apache APISIX is a dynamic, real-time, high-performance API gateway, providing rich traffic management. The project offers load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and many useful plugins. In addition, the gateway supports dynamic plugin changes along with hot update. The OpenID Connect plugin for Apache APISIX allows users to replace traditional authentication mode with centralized identity authentication mode via OpenID Connect. How to use Install Apache APISIX Install dependencies The Apache APISIX runtime environment requires dependencies on NGINX and etcd. Before installing Apache APISIX, please install dependencies according to the operating system you are using. We provide the dependencies installation instructions for CentOS7, Fedora 31 and 32, Ubuntu 16.04 and 18.04, Debian 9 and 10, and macOS. Please refer to Install Dependencies for more details. Installation via RPM Package (CentOS 7) This installation method is suitable for CentOS 7; please run the following command to install Apache APISIX. sudo yum install -y https://github.com/apache/apisix/releases/download/2.7/apisix-2.7-0.x86_64.rpm Installation via Docker Please refer to Installing Apache APISIX with Docker. Installation via Helm Chart Please refer to Installing Apache A ## New Keycloak maintainer: Takashi Norimatsu DevFeed: [New Keycloak maintainer: Takashi Norimatsu]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2021-10-18T00:00:00Z Content type: news Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [OAuth 2.0](), [openid](), [Security](), [API](), [Authorization](), [pkce]() Tags: [api-security](), [authorization](), [idm](), [kerberos](), [keycloak](), [ldap](), [oauth-2-0](), [openid-connect](), [pkce](), [saml](), [security](), [sso]() ### AI overview Keycloak welcomes Takashi Norimatsu as an official maintainer. He will continue leading OAuth 2.0 and OpenID Connect security work, initially focusing on API security features for enterprise scenarios. ### Source excerpt We are extremely pleased to welcome Takashi Norimatsu as an official maintainer of Keycloak. Takashi has contributed to Keycloak since 2017, with a focus on security features of OAuth 2.0 and OpenID Connect, such as PKCE, strong signature algorithms, and Certificate Bound Access Tokens. More recently, he has been leading development related to Financial-grade API (FAPI) in the FAPI special interest group. In addition he has been helping other developers in the area of API authorization, including giving presentations at multiple conferences. Takashi will continue leading development of OAuth 2.0 and OpenID Connect security related features, with an initial focus on features needed to provide higher level of API security for enterprise scenarios. Takashi works for Hitachi, Ltd. in Japan, which sees the real value of Keycloak especially in the API management area, allowing him to invest a significant portion of his time to the Keycloak project. The Keycloak team is very exited about having Takashi join us as a maintainer, and we are looking forward to working more closely with Takashi going forward. ## Keycloak Community Newsletter #2 DevFeed: [Keycloak Community Newsletter #2]() Original publisher: [Read original article]() Author: Sébastien Blanc Published: 2019-05-06T00:00:00Z Content type: news Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Amazon API Gateway](), [gateway](), [Kubernetes](), [Python](), [deprecated](), [OAuth 2.0](), [openid](), [Cloud Native Ecosystem]() Tags: [api](), [api-gateway](), [community](), [deprecated](), [gateway](), [idm](), [kerberos](), [keycloak](), [kubernetes](), [ldap](), [news](), [oauth2](), [openid](), [openid-connect](), [python](), [saml](), [sso]() ### AI overview The second Keycloak community newsletter highlights integrations with API gateways, a Python adapter client, clustering configuration guidance, Helm Chart changes, login-theme customization, and Keycloak with MicroProfile. It also reports the Keycloak 6.0.1 release, a revised versioning discussion, and a proposal for CNCF acceptance. ### Source excerpt We have a lot of news to share in this second edition, so fasten your seatbelt and let's go! News from the community First of all, we would like to thank the whole community, which has contributed to this edition by sharing their links, tips, and so on. An increasing number of API Management/Gateway solutions can now be integrated with Keycloak. Recently, Ambassador, an Open Source Kubernetes-Native API Gateway built on the Envoy Proxy, has added support for Keycloak; it has also published a quickstart to show how Keycloak can be used to add Github as Identity provider. We have some good news for Python users. Akhil Lawrence has created a Python Keycloak Adapter Client. Be sure to check out the really nice documentation that comes with many usage examples. Like any other project, setting up clustering can be somehow complex. Liqiang has shared with us his setup and configuration tips. Thanks again for sharing your knowledge with the community! The existing Keycloak Helm Chart has now been deprecated and is now replaced by the one managed by CodeCentric. Dmitry Telegin has created a really nice example on how you can dynamically brand your login theme for Keycloak. Check out the repository here. Hayri Cicek has written a nice introductory article on how to use Keycloak and MicroProfile. It even shows the usage of the brand new Client Scope "microprofile-jwt," which has been added in Keycloak 6.0.0. News from the project Keycloak 6.0.1 has been released. We know that some people were a bit confused by our new versioning schema. We hope that this blog post will clear it up. We started the proposal process for Keycloak to be accepted into the Cloud Native Computing Foundation (CNCF). We hope that this effort will significantly boost our community adoption with our ultimate goal of becoming the de facto solution for OAuth2/OpenID Connect within Open Source and Cloud Native. You can watch the presentation to the CNCF TOC (Technical Oversight Committee) here and the slides ## Red Hat Single Sign-On in Keynote demo on Red Hat Summit! DevFeed: [Red Hat Single Sign-On in Keynote demo on Red Hat Summit!]() Original publisher: [Read original article]() Author: Marek Posolda Published: 2018-06-17T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Cloud](), [Mobile](), [JavaScript](), [openid](), [Replication](), [Architecture & Design](), [rdbms](), [Security](), [amazon](), [Azure]() Tags: [amazon](), [azure](), [cloud](), [idm](), [javascript](), [kerberos](), [keycloak](), [ldap](), [mobile](), [openid-connect](), [rdbms](), [red-hat-summit](), [replication](), [saml](), [security](), [sso]() ### AI overview This article describes a Red Hat Summit keynote demo using Red Hat Single Sign-On, based on Keycloak, to authenticate a mobile game deployed across Azure, Amazon, and a private cloud. It explains why independent instances with separate databases and caches create limitations for failover, session visibility, user changes, and security, motivating a replicated setup. ### Source excerpt Red Hat Summit is one of the most important events during the year. Many geeks, Red Hat employees and customers have great opportunity to meet, learn new things and attend lots of interesting presentations and trainings. During the summit this year, there were few breakout sessions, which were solely about Keycloak and Red Hat SSO. You can take a look at this blogpost for more details. One of the most important parts of Red Hat Summit are Keynote demos, which show the main bullet points and strategies going forward. Typically they also contain the demos of the most interesting technologies, which Red Hat uses. On the Thursday morning keynote, there was this demo to show the Hybrid Cloud with 3 clouds (Azure, Amazon, Private) in action! There were many technologies and interesting projects involved. Among others, let's name Red Hat JBoss Data Grid (JDG), OpenWhisk or Gluster FS. The RH-SSO (Red Hat product based on Keycloak project) had a honor to be used as well. Red Hat SSO setup details The frontend of the demo was the simple mobile game. RH-SSO was used at the very first stage to authenticate users to the mobile game. Each attendee had an opportunity to try it by yourself. In total, we had 1200 players of the game. There was loadbalancer up-front and every user was automatically forwarded to one of the 3 clouds. The mobile application used RH-SSO Javascript adapter (keycloak.js) to communicate with RH-SSO. With Javascript application, whole OpenID Connect login flow happens within browser and hence can rely on sticky session. So since Javascript adapter is used, you may think that we can do just "easy" setup and let the RH-SSO instances across all 3 clouds to be independent of each other and have each of them to use separate RDBMS and infinispan caches. See the image below for what such a setup would look like: With this setup, every cloud is aware just about the users and sessions created on itself. This is fine with sticky session, but it won't work for failove [Next page]()