SSO is available on Business plan and above.
OIDC PKCE (recommended)
The recommended approach uses standard OIDC with PKCE flow. This method works with any OIDC-compliant identity provider and has been tested with Microsoft Entra ID, Okta, Keycloak, and PingOne.Step 1: Create an OIDC application
Create a new OIDC/OAuth application in your identity provider. Configure it as a public client (SPA) with PKCE enabled. Set the redirect URI to:Step 2: Configure BRMS
Set these environment variables with values from your OIDC application:Provider examples
Additional options
| Variable | Description | Default |
|---|---|---|
SSO_OAUTH2_SCOPES | OAuth2 scopes to request | openid email profile |
SSO_OAUTH2_REDIRECT_URI | Callback path | /_callback |
SSO_OAUTH2_AUTHORITY_URL | Authority URL (if different from issuer) | - |
SSO_OAUTH2_IDENTITY_TOKEN_SOURCE | Token for identity claims | access_token |
SSO_OAUTH2_CUSTOM_CLAIM_NAME | JWT claim containing groups | groups |
Azure AD (legacy)
1. Create an Enterprise Application
- Log in to the Azure Portal and navigate to Entra ID
- Select Enterprise applications → New application
- Click Create your own application
- Choose Register an application to integrate with Microsoft Entra ID
- Name the application (e.g.,
GoRules BRMS) - Select Accounts in this organizational directory only (single tenant)
- Set Redirect URI to Web and enter
https://your-brms-url/oauth/azure - After creation, navigate to Single sign-on → Go to application
- Copy the Application (client) ID
2. Add group claims (optional)
- In App registrations, open Token configuration
- Click Add group claim
- Configure claims according to your requirements
- For Access and ID tokens, select sAMAccountName
- Save
3. Create credentials
- Open Certificates & secrets
- Under Client secrets, click New client secret
- Add description, set expiry, click Add
- Copy the secret value immediately (not visible after leaving the page)
4. Copy endpoints
- In the Overview section, click Endpoints
- Copy:
- OAuth 2.0 authorization endpoint (v2)
- OAuth 2.0 token endpoint (v2)
- Authority URL:
https://login.microsoftonline.com/TENANT_ID
5. Configure BRMS
Okta (legacy)
1. Create an application
- Log in to your Okta Admin dashboard
- Navigate to Applications → Create App Integration
- Select OIDC - OpenID Connect and Web Application
- Name the application (e.g.,
GoRules BRMS) - Set grant type to Authorization Code
- Set Sign-in redirect URI to
https://your-brms-url/oauth/okta - Leave Sign-out redirect URIs empty
- Assign to necessary user groups
- Save
2. Add group claims (optional)
- In the application, open Sign On tab
- In OpenID Connect ID Token, click Edit
- Set Group Claim Type to Filter
- Enter
groups, select Matches regex, enter.* - Save
3. Copy credentials
From the General tab, copy:- Client ID
- Client Secret
4. Configure BRMS
Group mapping
Map identity provider groups to BRMS roles usingSSO_OAUTH2_GROUPS_MAPPING. The format is {group}->{role} comma-separated.
Global roles
Four global roles are available:owner, admin, author, and member.
member permissions.
Provider-specific formats
Azure AD uses group UUIDs:Fine-grained per-project mapping
For granular control per project, enable role mapping in BRMS:- Navigate to Settings → Users & Roles → Roles
- Create or edit a role
- Configure:
- Role Name: Custom identifier
- IDP Groups: Map SSO groups to this role
- Project Access: Assign specific projects
- Permissions: Define granular permissions
Comparison
| Feature | Global mapping | Per-project mapping |
|---|---|---|
| Configuration | Environment variables | BRMS UI |
| Granularity | System-wide | Per-project |
| Use case | Simple admin/member split | Complex multi-project permissions |
| Required variable | SSO_OAUTH2_GROUPS_MAPPING | SSO_OAUTH2_ROLES_MAPPING_ENABLED=true |
Troubleshooting
Invalid redirect URI
The redirect URI must exactly match the one registered with your IdP:- OIDC PKCE (recommended):
https://your-brms-url/_callback - Azure (legacy):
https://your-brms-url/oauth/azure - Okta (legacy):
https://your-brms-url/oauth/okta
Groups not syncing
- Verify groups claim is included in tokens
- Check
SSO_OAUTH2_CUSTOM_CLAIM_NAMEmatches your IdP’s claim name - Ensure users are assigned to the mapped groups in your IdP