Single Sign-On (SSO)
Configure SAML 2.0, OpenID Connect, or social login (Google, GitHub, GitLab) for your Aira organization.
Overview
Aira supports three SSO methods:
- SAML 2.0 — Okta, Azure AD, Google Workspace, OneLogin, PingFederate, etc.
- OpenID Connect (OIDC) — any OIDC-compliant identity provider
- Social login — Google, GitHub, GitLab (optional, can be combined with SAML/OIDC)
SSO is available on Business, Enterprise, and Self-hosted plans.
SAML 2.0
Step 1: Create a SAML application in your IdP
In your identity provider (Okta, Azure AD, Google Workspace, etc.), create a new SAML 2.0 application with these values:
| Field | Value |
|---|---|
| ACS URL | Shown in Aira dashboard under Settings → SSO after selecting SAML |
| Entity ID | Same as ACS URL (Aira uses the same value) |
| Name ID format | emailAddress |
| Attribute mapping | Map email to the user's email address |
Step 2: Upload IdP metadata to Aira
From your IdP, download the SAML metadata XML (sometimes called "Federation Metadata"). Then in the Aira dashboard:
- Go to Settings → Single Sign-On
- Select SAML 2.0
- Paste the metadata XML
- Click Save
Aira will parse the metadata and display the ACS URL and Entity ID for you to copy back into your IdP if needed.
Step 3: Test and enforce
After saving, test with a user from your IdP. Once confirmed:
- Enable SSO — users can sign in with SSO or email/password
- Enforce SSO — all non-owner users must use SSO (email/password disabled except for the org owner as a break-glass)
OpenID Connect (OIDC)
Step 1: Create an OIDC application in your IdP
| Field | Value |
|---|---|
| Redirect URI | Shown in the Aira dashboard under Settings → SSO after selecting OIDC |
| Grant type | Authorization Code |
| Scopes | openid, email, profile |
Step 2: Configure in Aira
- Go to Settings → Single Sign-On
- Select OpenID Connect
- Enter:
- Issuer URL — e.g.
https://accounts.google.comorhttps://login.microsoftonline.com/{tenant}/v2.0 - Client ID — from your IdP
- Client Secret — from your IdP
- Issuer URL — e.g.
- Click Save
Step 3: Test and enforce
Same as SAML — test first, then enable or enforce.
Social Login (Google, GitHub, GitLab)
Social logins are configured via environment variables, not the dashboard. They work alongside SAML/OIDC — users see the social login buttons on the login page.
- Go to Google Cloud Console → Credentials
- Create an OAuth 2.0 Client ID (Web application)
- Add authorized redirect URI:
https://your-domain.com/api/auth/callback/google - Set environment variables:
AUTH_GOOGLE_ID=your-client-id
AUTH_GOOGLE_SECRET=your-client-secretGitHub
- Go to GitHub → Settings → Developer settings → OAuth Apps
- Create a new OAuth App
- Set callback URL:
https://your-domain.com/api/auth/callback/github - Set environment variables:
AUTH_GITHUB_ID=your-client-id
AUTH_GITHUB_SECRET=your-client-secretGitLab
- Go to GitLab → Preferences → Applications
- Create a new application with
read_userandopenidscopes - Set callback URL:
https://your-domain.com/api/auth/callback/gitlab - Set environment variables:
AUTH_GITLAB_ID=your-application-id
AUTH_GITLAB_SECRET=your-secretSocial login is optional. If no OAuth environment variables are set, only the email/password login form is shown. You can enable any combination — e.g. Google only, or Google + GitHub, or none.
Self-hosted SSO
Self-hosted deployments support all the same SSO options. The only difference is that redirect/callback URLs use your deployment domain instead of airaproof.com:
| Method | Callback URL |
|---|---|
| SAML ACS | https://api.your-domain.com/api/v1/sso/saml/acs |
| OIDC Redirect | https://api.your-domain.com/api/v1/sso/oidc/callback |
| Google OAuth | https://your-domain.com/api/auth/callback/google |
| GitHub OAuth | https://your-domain.com/api/auth/callback/github |
| GitLab OAuth | https://your-domain.com/api/auth/callback/gitlab |
The ACS URL and callback URLs are shown in the dashboard and are automatically derived from your deployment domain — no manual URL construction needed.
SSO enforcement
When SSO is enforced, all users except the organization owner must sign in via SSO. The owner retains email/password access as a break-glass mechanism.
To enforce SSO:
- Configure and test SSO (SAML or OIDC)
- In Settings → SSO, toggle Enforce SSO
- All non-owner users will be redirected to your IdP on login
Before enforcing SSO, ensure at least one admin can log in via the IdP. If SSO is misconfigured and enforced, only the org owner can log in with email/password to fix it.