Janssen is a Linux Foundation open source identity and access management project for teams that need to run OAuth 2.0/OpenID Connect single sign-on, low-code authentication flows, and policy-based authorization on infrastructure they control.

What it is

Janssen is a collection of open source IAM components developed under the Linux Foundation, with the Gluu team driving day-to-day priorities under a community Technical Steering Committee. Its three headline components are Auth Server, which implements the OAuth 2.0 and OpenID Connect protocols; Agama, a low-code framework for identity orchestration; and Cedarling, a policy decision point. The "Janssen Server" distributions bundle these components together under a single control plane, and the project ships binaries, cloud-native deployment assets and documentation alongside the code.

The concrete problem it addresses is that organizations implementing digital identity and access management typically have to assemble and stitch together a token issuer, a login flow builder, and a policy engine as separate pieces of software. Janssen replaces that patchwork with components distributed together and governed by a common maturity-stage process, so a self-hoster obtains an authorization server, low-code orchestration layer, and policy decision point from one project rather than three unrelated ones. The repository lives in the Java ecosystem and covers the access-management, api, identity, oauth2, openid-connect, sso and kubernetes topics.

Key capabilities

• Auth Server issues and validates tokens under the OAuth 2.0 and OpenID Connect protocols, providing API-scoped access management and single sign-on.
• Agama provides low-code identity orchestration, letting teams define authentication flows declaratively rather than writing each flow in code.
• Cedarling operates as a policy decision point, evaluating authorization policy alongside the authentication stack.
• The "Janssen Server" distribution bundles the components under one control plane instead of requiring separate administration of each service.
• Cloud-native deployment assets are provided, including a janssen-auth-server Helm chart published on Artifact Hub for Kubernetes.
• Each component is published with an explicit lifecycle stage, so adopters can see which parts are stable versus still demos.
• Releases, all release tags, documentation, contribution guides and developer guides are published, with builds carrying SLSA 3 provenance and OpenSSF scorecard and best-practices badges.

Who uses it and how

• Enterprises running a production deployment can take the open source components and self-manage them, or take Gluu's commercial distribution for supported operations.
• Platform teams deploy it onto Kubernetes using the published Helm chart from Artifact Hub rather than installing from binaries.
• Integrators building products or mission-critical cybersecurity services assemble Auth Server, Agama and Cedarling into a single sign-on and policy stack.
• Contributors participate through GitHub Discussions and the project's chat room, with priorities guided by the Technical Steering Committee.
• New adopters and administrators use the documentation at docs.jans.io and Gluu Academy to learn the deployment and administration workflow.

Getting started

Install the janssen-auth-server Helm chart from Artifact Hub to deploy on Kubernetes, or take the latest release from the project's GitHub releases page, following the deployment documentation at docs.jans.io.

How it compares

Janssen is Apache-2.0 licensed and self-hostable, so operators keep the software, the deployment and the identity data under their own control with no licence fee; Gluu Flex and Gluu Solo are Gluu's commercial distributions of the same Janssen Project components, sold as supported products for production use. The practical difference is therefore the cost model and support relationship rather than the underlying capability: the same components are available either as open source you operate yourself or as a commercial offering.

When to use it — and when not

A self-hoster must operate the cloud-native deployment assets, which in practice means running Kubernetes and administering the bundled control plane for Auth Server, Agama and Cedarling. It is a poor fit for teams that want a hosted identity service with no infrastructure to run, or who need everything polished immediately, since the project itself notes its components sit at different maturity stages and the repository currently carries 489 open issues.