This add-on makes Orangescrum an identity provider. Applications that speak OpenID Connect redirect people to Orangescrum to sign in and get a signed identity token back, so there is one account and one password instead of five. The authorisation code flow requires PKCE, refresh tokens rotate with replay detection, tokens can be revoked, and every authorisation and token event is written to an audit table.
- Installs
- Available
- Support
- Vendor Supported
- Trust
- Self-Hosted
Active deployments
Priority response
Your infra, your data
Screenshots
Key Features
Discovery and Key Set
A standard discovery document and a JSON web key set mean a client configures itself from one URL instead of six settings copied by hand into a config file.
Authorisation Code with PKCE
The only response type is code, and PKCE with S256 is required by default. An intercepted authorisation code is useless to whoever intercepted it.
Signed Identity Tokens
Identity tokens are RS256 signed with an RSA key pair held on your own server. Every consumer verifies them against the public key you publish.
Refresh Rotation With Replay Detection
Each refresh issues a new token in the same family. Presenting a token that was already rotated revokes the entire family, so a copied refresh token stops working rather than quietly persisting.
Token Revocation
An RFC 7009 revocation endpoint accepts both access and refresh tokens, so an application can hand a credential back instead of leaving it live until it expires.
Single Logout Chain
Signing out of Orangescrum can call each registered application's logout URL in turn, so one sign out ends the session everywhere rather than only where the button was.
Role Claim in the Token
The identity token and the userinfo response carry a role claim derived from the person's Orangescrum role, so the receiving application can grant the right level of access without a second directory.
Registered Clients
Each application is a client record with its own identifier, secret, redirect URIs, and post-logout URL. The seeder refuses to write a client it cannot build a working redirect for.
Audit Log
Codes issued, authorisations refused, tokens issued, tokens refused, replay detections, and revocations are each written with the client and the time, so a failed sign-in is a query rather than a guess.
Keys You Hold
The signing key pair lives in a directory on your server. Generate it out of band and mount it from your secret store, and no outside party ever holds the key that signs your identities.
Application Launcher
A nine-dot launcher in the user menu links across to the other applications in the group, so people move between them without retyping a URL or signing in again.
No Outbound Dependency
The provider runs on the same host as Orangescrum, behind whatever TLS termination and network controls you already operate. Sign-in does not depend on an outside service being up.
About this plugin
Why Single Sign-On for Orangescrum?
Most self-hosted rollouts end up with more than one application: the project workspace, a documentation portal, a reporting stack. Each one with its own accounts means people forget passwords, leavers keep access somewhere nobody checked, and every new starter needs setting up three times. This add-on gives all of them one place to sign in.
Orangescrum is the provider, not the client
It is worth being clear about the direction. Orangescrum becomes the identity provider and your other applications become its clients. People sign in with their Orangescrum credentials, and the other applications trust the identity token Orangescrum issues. It does not work the other way round: this add-on does not let an external directory sign people in to Orangescrum.
Codes and tokens that fail safe
The authorisation code flow with PKCE is the only path, so a code intercepted in a redirect cannot be exchanged without the verifier that was never sent over the wire. Refresh tokens rotate, and if a previously rotated token is ever presented the whole family is revoked, which turns a copied token into a detected incident instead of a silent one.
One sign out, not five
Registered clients can each declare a logout URL. When someone signs out of Orangescrum, the provider calls those URLs in turn, so the documentation portal and the reporting stack drop the session too. That is the part people forget to build, and it is the part that matters when a laptop goes missing.
What a consumer application needs
Any application that supports OpenID Connect with the authorisation code flow can be registered. It needs the discovery URL, a client identifier and secret, and a redirect URI, all of which you set when you register the client. Two consumers are already documented end to end: the documentation portal that backs the Wiki add-on, and an Apache Superset reporting stack.
Nothing leaves your network
The provider, the signing keys, the client records, and the audit log all live in your install and your database. Sign-in traffic never touches a third-party identity service, which is usually the whole reason for running self-hosted in the first place. Air-gapped deployments work exactly the same way.
What's included
- OpenID Connect discovery document served from your own install
- A published JSON web key set for token verification
- Authorisation endpoint using the authorisation code flow
- PKCE with the S256 challenge method, required by default
- Token endpoint covering code exchange and refresh exchange
- Userinfo endpoint authenticated with a bearer token
- RFC 7009 revocation endpoint for access and refresh tokens
- Logout endpoint with an optional post-logout redirect
- RS256 signed identity tokens from an RSA key pair you control
- Refresh token rotation with family-wide revocation on replay
- Role and group claims in the identity token and the userinfo response
- Client records with identifier, secret, redirect URIs, post-logout and front-channel logout URLs
- A console seeder for client registration that refuses to write unusable rows
- Single logout chain across every registered client that declares a logout URL
- Nine-dot application launcher in the user menu
- Audit log covering codes issued, authorisations refused, tokens issued, tokens refused, replay detections, and revocations
- Deployment and architecture runbooks covering development and production topologies
- Multi-tenant company-scoped data isolation
Compatibility
Requires the Orangescrum Self-Hosted edition running PHP 8.2+, CakePHP 4.6+, and PostgreSQL 16. The plugin folder is OAuthServer and it is gated by the OAUTH_SERVER_ENABLED flag in config/constants.php. Your install needs a stable public base URL, because that URL is stamped into every identity token as the issuer and every consumer checks it. An RSA key pair is required, and in production it should be generated out of band and mounted from your secret store rather than generated on the box. If Orangescrum sits behind a TLS-terminating proxy, the application must be configured to trust that proxy, otherwise redirects and session cookies break during sign-in.
Installation
A self-hosted install takes a few minutes. Buy the add-on, drop the plugin into your plugins/ directory, run the migrations, and you're live.
- 1
Buy the add-on
Purchase the Single Sign-On add-on from /self-hosted/pricing. Pricing for this add-on is being finalised, so confirm the current figure with sales before you budget.
- 2
Drop the plugin into your install
Copy the OAuthServer/ folder into plugins/ on your self-hosted Orangescrum server.
- 3
Enable the feature flag and register the plugin
Add `define('OAUTH_SERVER_ENABLED', true);` to config/constants.php and register `OAuthServer` in src/Application.php with `routes => true, bootstrap => true`.
- 4
Run the database migrations
Run `bin/cake migrations migrate --plugin OAuthServer` to create the client, authorisation code, access token, refresh token, and audit log tables.
- 5
Set the public base URL and generate the signing keys
Set the canonical public URL of your install so it can be stamped into tokens as the issuer, and place an RSA private and public key pair in the configured key directory. Generate the pair out of band in production.
- 6
Register your first client
Set the client identifier, secret, and redirect URI for the application you want to connect, then run the client seeder. It refuses to write a row it cannot build a working redirect for, and it is safe to re-run.
- 7
Point the application at Orangescrum
Give the consumer application the discovery URL, the client identifier, and the secret. Add its logout URL to the client record if you want it included in the single logout chain.
- 8
Test the round trip
Fetch the discovery document, then sign in to the consumer application and check the audit log shows a code issued followed by a token issued, with no refusals.
Frequently Asked Questions
Which applications can sign in through this?
▾
Any application that supports OpenID Connect with the authorisation code flow. Two are documented end to end because they ship alongside Orangescrum: the documentation portal behind the Wiki add-on, and an Apache Superset reporting stack. Anything else that can consume a discovery URL, a client identifier and secret, and a redirect URI will work the same way.
Can I sign in to Orangescrum with Okta, Entra ID, or Google?
▾
No, and this is the most important limit to understand. This add-on works in one direction only. Orangescrum is the identity provider and other applications are its clients. There is no inbound connector that lets an external directory authenticate people into Orangescrum, and SAML is not supported in either direction.
Which flows and grants are supported?
▾
Authorisation code and refresh token. The only response type is code, and PKCE with S256 is required by default. There is no implicit flow, no client credentials grant, no device flow, and no dynamic client registration. Clients are registered deliberately, by an administrator, from the console.
What happens if a refresh token is stolen?
▾
Refresh tokens rotate, so each use issues a new one in the same family. If a token that was already rotated is presented again, the provider treats that as a replay, revokes every token in the family, and writes a replay detection row to the audit log. The attacker and the legitimate client both lose access, which is the correct outcome, and you have a timestamped record of it.
How do I register an application?
▾
From the console. A seeder command creates the client record from environment values you set: identifier, secret, redirect URI, and optionally the post-logout and front-channel logout URLs. If it cannot build a usable redirect URI it refuses to write the row rather than register a client that will fail at sign-in. The command is idempotent, so re-running it is safe.
Does signing out of Orangescrum sign me out of everything?
▾
It can. Each client may declare a front-channel logout URL, and Orangescrum calls each of them when someone signs out. A client that does not declare one is simply left out of the chain, so you can decide per application whether it participates.
Where do the signing keys live and can I rotate them?
▾
In a directory on your server, holding a private and a public key. In production, generate the pair out of band and mount the directory from your secret store rather than leaving keys on the application image. Replacing the pair rotates the signing key, and consumers pick up the new public key from the published key set.
Ready to deploy Single Sign-On on your own infrastructure?
Talk to our team about Orangescrum Self-Hosted Enterprise: your data, your servers, full control.