cloudparts

Janssen

A self-hosted identity and access management server: a certified OpenID Connect provider and OAuth 2.0 authorization server with FIDO2, SCIM and a self-service portal, plus Cedarling, an embeddable policy engine built on Cedar.

Linux Foundation project
What it is
Authentication
Type
Open source
Made by
Janssen Project (Linux Foundation), based on the Gluu Server
Foundation
The Linux Foundation, joined December 2020. A self-funded project chartered directly under the Linux Foundation; Gluu leads day-to-day development
License
Apache 2.0
Facts checked
28 October 2026

What it is

At the centre of Janssen is the Auth Server, a Java OAuth 2.0 authorization server and certified OpenID Connect provider. Applications send users to its /jans-auth/restv1/authorize endpoint, discover the rest from /.well-known/openid-configuration, and receive ID and access tokens; it also implements UMA 2.0 for user-managed access. Around it sit a FIDO2 server for passkeys and security keys, a SCIM server for provisioning users from other systems, Casa, a self-service portal where users enrol second factors, reset passwords and manage consent, and Agama, a designer for multi-step login flows such as identity proofing or step-up authentication. The Config API, a command-line client and a terminal UI configure all of it. Together these are packaged as the Janssen Server.

Data lives in MySQL, the default for production on Kubernetes, PostgreSQL or Amazon Aurora. Production deployments use Helm charts on Kubernetes; Docker images and VM packages for Ubuntu, SUSE and Red Hat are meant for testing. For authorization inside applications Janssen adds Cedarling, a policy decision point written in Rust on Amazon’s Cedar engine: it validates the JWTs an app already holds, maps their claims to Cedar entities and decides in under a millisecond whether an action is allowed, embedded in a browser through WebAssembly or in Java, Go, Python, iOS and Android apps. Gluu, the company that leads development, sells Gluu Flex and Gluu Solo, commercial distributions built on Janssen components.

Why teams pick it

  • One self-hosted server for OpenID Connect, OAuth 2.0, UMA, FIDO2 passkeys and SCIM provisioning, with a self-service portal for users
  • OpenID certified, inheriting the Gluu Server’s record of passing more OpenID self-certification tests than any other platform
  • Built for Kubernetes: Helm charts, horizontal scaling and a stated throughput above a billion authentications a day for Gluu-based deployments
  • Cedarling brings token-based, policy-as-code authorization into the app itself, even into the browser

Watch out for

  • A large Java system with many services to run, configure and upgrade; Docker and VM installs are documented as for testing only
  • A small community for a project of this scope: the main repository had about 650 GitHub stars in October 2026, and day-to-day development is led by one company, Gluu
  • Some parts are still incubating, such as Jans Lock (central authorization built on Cedarling) and the Tarp test client
  • Running your own identity provider means owning its security patches, key rotation and availability, work a hosted service such as Auth0 does for you

Alternatives

What all authentication have in common →Compare side by side →

How it fits with other technologies

Install a test server, then read its OpenID Connect discovery document · bash

# VM install for testing (production runs on Kubernetes with Helm)
curl https://raw.githubusercontent.com/JanssenProject/jans/v2.5.0/jans-linux-setup/jans_setup/install.py > install.py
sudo python3 install.py

# Any OpenID Connect client finds the endpoints here
curl -s https://auth.example.com/.well-known/openid-configuration \
  | jq '.authorization_endpoint, .token_endpoint, .jwks_uri'
# "https://auth.example.com/jans-auth/restv1/authorize"
# ...

What’s in the Janssen Server#

The project marks most components as graduated; Jans Lock and Tarp are incubating.

Auth Server

OAuth, OpenID Connect, UMA

The authorization server and OpenID provider, written in Java, and the upstream core of Gluu Flex.

FIDO2 and SCIM

passkeys, provisioning

Separate services for registering and checking FIDO2 authenticators and for creating and updating users over the SCIM standard.

Casa and Agama

users, login flows

Casa is a self-service portal for second factors, password reset and consent; Agama is a drag-and-drop designer for complex authentication flows.

Cedarling

authorization

An embeddable policy decision point in Rust on the Cedar engine, under 2 MB, with WebAssembly, Java, Go, Python, C, iOS and Android bindings; it can also run as a sidecar or central service.

See it in a real stack

No architecture uses Janssen yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2020–2026

Gluu built the Gluu Server, an open-source identity platform, and by 2020 it had passed more OpenID self-certification tests than any other, and Gluu-based software had shown throughput of more than a billion authentications a day. Its CEO, Mike Schwartz, explained handing the code to a neutral foundation with the line “trust and security are not competitive advantages”.

On December 8, 2020 the Linux Foundation announced the Janssen Project, built on the code that powers the Gluu Server, with a Technical Steering Committee chaired by Schwartz and including engineers from F5 (NGINX), Santander, IDEMIA, Couchbase and BioID. The project is self-funded and chartered directly under the Linux Foundation, while Gluu leads day-to-day development and sells commercial distributions, Gluu Flex and Gluu Solo, built on it.

Since then the project has moved beyond login. Cedarling, a policy decision point on Amazon’s Cedar language, brings authorization into applications, and v2.5.0 came out on October 7, 2026.

Why it’s built this way

Move the code to the Linux Foundation, keep the product at Gluu
A neutral home lets competitors and customers contribute to shared identity infrastructure, while Gluu earns money from supported distributions built on it.
Cloud native by default
The project relies on Kubernetes autoscaling and newer persistence options to handle concurrency, so Helm is the production deployment and VM installs are for testing.
Authorization from tokens, at the app
Cedarling evaluates Cedar policies against the JWTs an application already has, without fetching data during a decision, so checks are fast enough to run inside the app or browser.

Timeline

  1. 2020

    Linux Foundation announces the Janssen Project on December 8, built on the Gluu Server’s code

  2. 2026

    Janssen v2.5.0 released on October 7

Sources7 · facts checked 28 October 2026

Improve this page on GitHub