# openid Published articles for openid. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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 ## 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 ## 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 ## 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 ## Recap from KubeCon + CloudNativeCon Europe 2024 DevFeed: [Recap from KubeCon + CloudNativeCon Europe 2024]() Original publisher: [Read original article]() Author: Thomas Darimont Published: 2024-04-15T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Cloud Native Ecosystem](), [IAM](), [Kubernetes](), [OAuth 2.0](), [Passkeys](), [Open Policy Agent]() Tags: [cloud-native-ecosystem](), [iam](), [idm](), [kerberos](), [keycloak](), [kubecon](), [kubernetes](), [ldap](), [oauth2](), [open-policy-agent](), [openid](), [openid-connect](), [recap](), [saml](), [security](), [sso]() ### AI overview A recap of Keycloak's presence at KubeCon + CloudNativeCon Europe 2024, covering talks on OAuth2 Token Exchange for microservice API security, Keycloak's use in CERN's IAM infrastructure, federated IAM for Kubernetes with OpenFGA, and recent support for Passkeys, OAuth 2.1, and OpenID for Verifiable Credentials. ### Source excerpt After a packed week of fantastic talks at KubeCon + CloudNativeCon Europe 2024 in Paris, we're delighted to share our impressions with the rest of the Keycloak community. Keycloak and OAuth2 Token Exchange for Microservice API Security The presence of Keycloak in many presentations highlighted its importance in the cloud-native ecosystem. Notably, the talk "OAuth2 Token Exchange for Microservice API Security" by Ahmet Soormally & Letz Yaara on OAuth2 Token Exchange (RFC 8693) underscored its application in microservice security and pinpointed areas for Keycloak's enhancement. Efforts to advance the support for Token Exchange are underway, and community feedback is invaluable. Please join the discussion on the current usage of Token Exchange to help us out. Keycloak and the Secrets of the Universe at CERN A standout moment was learning about Keycloak's role at CERN in the talk "The Hard Life of Securing a Particle Accelerator", as shared by Antonio Nappi and Sebastian Lopienski, emphasizing its contribution to securing the particle accelerator's IAM infrastructure. Keycloak supports research on the nature of the universe. How cool is that :) Keycloak, OpenFGA, and Kubernetes Authorizer Jonathan Whitaker's talk "Federated IAM for Kubernetes with OpenFGA" on federated IAM with OpenFGA showcased innovative approaches for managing access to Kubernetes resources through the combination of Keycloak, OpenFGA and a custom Kubernetes Authorizer Web Hook. In particular, the demonstration of temporarily elevated access to Kubernetes resources was very well received. Keycloak: The Leading Edge of AuthN and AuthZ Last but not least, our session, "The Leading Edge of AuthN and AuthZ by Keycloak", presented by Takashi Norimatsu and Thomas Darimont, introduced the latest Keycloak advancements, including support for Passkeys, OAuth 2.1, and OpenID for Verifiable Credentials (OpenID4VC). As part of our talk, we showed the current support for Passkeys and some integration options with ## Keycloak 24.0.2 released DevFeed: [Keycloak 24.0.2 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2024-03-25T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [upgrade](), [version](), [Quarkus](), [kerberos](), [LDAP](), [OAuth](), [openid]() Tags: [bugs](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oauth](), [openid](), [openid-connect](), [quarkus](), [release](), [resolved](), [saml](), [sso](), [test](), [upgrade]() ### AI overview Keycloak 24.0.2 is released with enhancements, documentation updates, dependency upgrades, and fixes for issues affecting authentication, administration, account management, imports and exports, clustering, and OpenID Connect services. ### Source excerpt To download the release go to Keycloak downloads. Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Enhancements #25057 Inconsistent behaviour on getting user permissions using authorization authorization-services #27433 Clarify format of keys in `additionalOptions` field in the Keycloak CR docs #27481 Edit High Availability guide #27484 Edit 23.0 changes part of Upgrading Guide #27632 Integrate downstream Upgrading Guide changes into upstream #27696 Upgrade to Quarkus 3.8.2 dist/quarkus #27867 Corrections to Securing Apps Guide #27871 Upgrade to Infinispan 14.0.26 core #27953 Address feedback to Keycloak Server guide docs #27955 Address term Keycloak in Server Administration Guide docs #28009 Address edits to the Operator Guide #28033 Upgrade Infinispan to 14.0.27.Final #28084 Upgrade to Quarkus 3.8.3 dist/quarkus Bugs #14501 Getting failed to initialize js message if consent is rejected by user account/ui #15403 No email send on TOTP/Authenticator app removal core #20637 Reset password flow fails with "Page has expired" error when Kerberos authentication is enabled in the browser flow authentication #22644 Flaky test: org.keycloak.testsuite.forms.BrowserFlowTest#testAlternativeNonInteractiveExecutorInSubflow core #23701 Attribute search does not work with federated users with ldap. admin/ui #23980 Keycloak Operator fails to install realm authentication flow because "flow is null" import-export #25490 Partial export/import is not mentioned in Keycloak's Server Administration Guide docs #25687 A java.lang.NullPointerException occurs when sending a Multipart/form-data request to any file upload interface. admin/api #26396 How do you update a custom user storage provider jar that includes a version number? dist/quarkus #27117 user sessions not accessible in all cluster nodes infinispan #27180 Grant type "urn:ietf:params:oauth:grant-type:uma-ticket" openid-connect/token service endpoint is returning refresh toke ## 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 ## What is SAML? A practical guide to the authentication protocol DevFeed: [What is SAML? A practical guide to the authentication protocol]() Original publisher: [Read original article]() Author: Kang Ming Tay Published: 2024-01-17T07:00:00Z Content type: tutorial Language: en Sources: [Supabase Blog]() Topics: [Authentication](), [Protocol (disambiguation)](), [Single sign-on (SSO)](), [XML](), [Authorization](), [Provisioning](), [Security](), [OAuth]() Tags: [active-directory](), [authentication](), [authorization](), [guide](), [oauth](), [openid](), [openid-connect](), [protocol](), [provisioning](), [saml](), [sso](), [xml]() ### AI overview This practical guide explains SAML authentication and how SAML enables single sign-on between identity providers and service providers. It covers employee provisioning, XML-based SAML assertions, X.509 certificate exchange, and the distinction between SAML and broader SSO approaches such as OAuth and OpenID Connect. ### Source excerpt Learn what is SAML authentication, how it differentiates from SSO, SAML with Postgres, and more. ## 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 ## OpenID Connect DevFeed: [OpenID Connect]() Original publisher: [Read original article]() Author: Keith Richards Published: 2023-07-18T19:59:50Z Content type: tutorial Language: en Sources: [Clever]() Topics: [OpenID connect (OIDC)](), [Authentication](), [OAuth 2.0](), [Protocol (disambiguation)]() Tags: [auth](), [authentication](), [authorization](), [oauth](), [oauth-2-0](), [oauth2](), [oidc](), [openid](), [openid-connect](), [protocol]() ### AI overview This article explains how OpenID Connect adds user authentication and identity information to OAuth 2.0's authorization framework. It compares the roles of OAuth 2.0 and OIDC, describes OIDC's background, and introduces the relying party and OpenID provider. ### Source excerpt Adding AuthN to OAuth2.0 OpenID Connect (OIDC) is an authentication protocol that sits on top of the OAuth2.0 protocol. It provides a standardized way for clients to authenticate users and obtain information about their identity. In simple terms, OpenID Connect allows users to log in to different applications using a single set of credentials. It [...] The post OpenID Connect appeared first on Clever Engineering Blog. ## 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. ## 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 ## 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 ## Keycloak, Apache and OpenID Connect DevFeed: [Keycloak, Apache and OpenID Connect]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2018-01-04T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [openid](), [Single sign-on (SSO)](), [web applications](), [proxy]() Tags: [idm](), [kerberos](), [ldap](), [openid](), [openid-connect](), [proxy](), [reverse-proxy](), [saml](), [sso](), [web-applications]() ### AI overview This article explains that mod_auth_openidc can secure applications running in Apache or Apache used as a reverse proxy. It supports single sign-on for web applications and securing RESTful services. ### Source excerpt mod_auth_openidc makes it easy to secure your applications running in Apache or when Apache is used as a reverse proxy. It can be used both for enabling SSO to web applications as well as to secure RESTful services. For more details check out our documentation as well as the guides from mod_auth_openidc. ## Teleport 1.0 Release Announcement DevFeed: [Teleport 1.0 Release Announcement]() Original publisher: [Read original article]() Author: taylor@goteleport.com (Taylor Wakefield) Published: 2016-06-23T00:00:00Z Content type: release Language: en Sources: [Teleport]() Topics: [ssh](), [Security](), [Authentication](), [OAuth 2.0](), [openid](), [browser](), [real-time](), [GUI]() Tags: [announcement](), [audit](), [authentication](), [bastion](), [browser](), [gui](), [oauth2](), [openid](), [real-time](), [release](), [security](), [ssh]() ### AI overview Teleport 1.0 is released as a modern SSH server for server clusters, adding certificate-based authentication, session recording and replay, reverse tunneling, identity-provider integration, real-time session sharing, dynamic node labeling, and a browser-based GUI. The release also reports a completed security audit and penetration testing, with issues addressed before production recommendation. ### Source excerpt We are announcing the official 1.0 version of Teleport:\ SSH server with built-in bastion and audit! ## Securing your Internal Organization with OpenID DevFeed: [Securing your Internal Organization with OpenID]() Original publisher: [Read original article]() Author: Map Published: 2012-01-23T20:55:56Z Content type: tutorial Language: en Sources: [Craig Kerstiens]() Topics: [openid](), [OAuth](), [passwords](), [Django](), [Rails](), [Virtual Private Network]() Tags: [business](), [database](), [engineering](), [oauth](), [openid](), [password](), [startup](), [vpn]() ### AI overview The article explains how organizations can use OpenID and Google authentication to secure internal applications, documentation, wikis, and tools. It describes the domain setup required for OpenID discovery and provides Django and Rails examples, with mentions of Flask and Sinatra. ### Source excerpt I've recently been amazed at the number of companies that are still using a VPN or other means to manage their apps/network. Not just large enterprisey companies, but small agile startups. I fully understand that it works, but 95% of these places are also using another key tool for access inside their company... Google Apps. I fully expect companies to use google apps, its more of the former that surprises me most. For a long time OpenID wasn't at a usable point, even today it still isn't without its faults. However, it does make for a much cleaner workflow once in place than having your users login to something with they're used to using elsewhere. In our personal lives we use email as our keys to the kingdom. In fact I now almost refuse to sign up for any service that doesn't let me use oauth, so why should a work place be much different. So I inquired with a few companies to see if they were fine with securing things like documentation or wiki's being google auth, they indeed were. Yet they still seem to have users keep one more username and password for their VPN to be able to login to access internal docs/tools. Most tech centric companies grow their own apps for many things they do within a company. Even the heavier adopters of SaaS still end up building a lot of internal systems. So why not secure them with your email domain just as you commonly would if it were a public service? The problem comes in that OpenId with google has an initial setup overhead, but after that works unbelievably well. The catch In some cases you currently have to identify your domain as an OpenId provider. This means that @yourname.com is an OpenId provider. This simply means creating a url route for openid in your base site similar to the below: http://specs.openid.net/auth/2.0/signon https://www.google.com/a/craigkerstiens.com/o8/ud?be ## App Engine Boilerplate 2.0 - Using html5-boilerplate v2 on Google App Engine DevFeed: [App Engine Boilerplate 2.0 - Using html5-boilerplate v2 on Google App Engine]() Original publisher: [Read original article]() Author: Chris Hager Published: 2011-08-12T00:00:00Z Content type: tutorial Language: en Sources: [Chris Hager]() Topics: [Boilerplate](), [HTML5](), [Front end](), [Web Development](), [Google](), [Tutorial](), [Authentication](), [Caching]() Tags: [android](), [authentication](), [boilerplate](), [caching](), [css](), [front-end](), [github](), [google](), [html](), [html5](), [js](), [openid](), [release](), [repository]() ### AI overview This tutorial introduces App Engine Boilerplate 2.0, a startup kit that combines html5-boilerplate 2.0 with App Engine-specific resources and best practices. It describes features including OpenID authentication, memcaching, templates, build tools, and deployment steps. ### Source excerpt Just a year ago Paul Irish and several contributors started working on html5-boilerplate, a popular repository of boilerplate and best practices for creating cross-browser compatible, html5-enabled websites. Thanks to the efforts of many front-end developers and researchers who have spent countless hours on developing and evolving best practices, html5 boilerplate is rapidly maturing and establishing itself as the de-facto standard html boilerplate. The authors just celebrated the one-year anniversary with the release of version 2. ## App Engine Boilerplate DevFeed: [App Engine Boilerplate]() Original publisher: [Read original article]() Author: Chris Hager Published: 2011-04-05T00:00:00Z Content type: tutorial Language: en Sources: [Chris Hager]() Topics: [Boilerplate](), [Code](), [Google](), [HTML5](), [jQuery](), [openid](), [Authentication](), [Caching](), [datasets]() Tags: [authentication](), [boilerplate](), [cache](), [code](), [google](), [html5](), [openid](), [template]() ### AI overview The article introduces appengine-boilerplate, a BSD-licensed repository of reusable boilerplate code for Google's App Engine. It describes included HTML5 and jQuery resources, OpenID authentication, user preference data, memcached datastore objects, request handlers, template tags, development tools, and configuration for different access levels. ### Source excerpt I recently started appengine-boilerplate, a repository of often used boilerplate code for Google's App Engine, which allows to quickly setup new projects without having to re-invent the most common wheels. All code is released under the BSD license, and It comes with the following goodies: html5-boilerplate (incl. jQuery) OpenID authentication User preferences data model (with gravatar image link) Memcache for datastore objects Handlers for /, /profile, /login and /logout Custom template tags Various tools such as is_testenv(), decode(input) and slugify(title) app. ## BarCampLondon2 Recap: Offline Web Applications, Amazon EC2, and OpenID DevFeed: [BarCampLondon2 Recap: Offline Web Applications, Amazon EC2, and OpenID]() Original publisher: [Read original article]() Author: Graham King Published: 2007-02-25T13:05:28Z Content type: article Language: en Sources: [Graham King]() Topics: [web applications](), [Amazon EC2](), [JavaScript](), [Rails](), [Amazon S3](), [Google Calendar](), [openid](), [Firefox]() Tags: [amazon-ec2](), [conference](), [firefox](), [javascript](), [openid](), [rails](), [recap](), [s3](), [society](), [software]() ### AI overview A recap of BarCampLondon2 highlights sessions on offline web applications, including a proxy-based approach for using Google Calendar without a network connection; running Rails applications on Amazon EC2 with persistent storage in Amazon S3; and an explanation of OpenID. ### Source excerpt "Unconvention-al Conversations: A BarCampLondon2 Recap."