Aira

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:

  1. SAML 2.0 — Okta, Azure AD, Google Workspace, OneLogin, PingFederate, etc.
  2. OpenID Connect (OIDC) — any OIDC-compliant identity provider
  3. 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:

FieldValue
ACS URLShown in Aira dashboard under Settings → SSO after selecting SAML
Entity IDSame as ACS URL (Aira uses the same value)
Name ID formatemailAddress
Attribute mappingMap 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:

  1. Go to Settings → Single Sign-On
  2. Select SAML 2.0
  3. Paste the metadata XML
  4. 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

FieldValue
Redirect URIShown in the Aira dashboard under Settings → SSO after selecting OIDC
Grant typeAuthorization Code
Scopesopenid, email, profile

Step 2: Configure in Aira

  1. Go to Settings → Single Sign-On
  2. Select OpenID Connect
  3. Enter:
    • Issuer URL — e.g. https://accounts.google.com or https://login.microsoftonline.com/{tenant}/v2.0
    • Client ID — from your IdP
    • Client Secret — from your IdP
  4. 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.

Google

  1. Go to Google Cloud Console → Credentials
  2. Create an OAuth 2.0 Client ID (Web application)
  3. Add authorized redirect URI: https://your-domain.com/api/auth/callback/google
  4. Set environment variables:
AUTH_GOOGLE_ID=your-client-id
AUTH_GOOGLE_SECRET=your-client-secret

GitHub

  1. Go to GitHub → Settings → Developer settings → OAuth Apps
  2. Create a new OAuth App
  3. Set callback URL: https://your-domain.com/api/auth/callback/github
  4. Set environment variables:
AUTH_GITHUB_ID=your-client-id
AUTH_GITHUB_SECRET=your-client-secret

GitLab

  1. Go to GitLab → Preferences → Applications
  2. Create a new application with read_user and openid scopes
  3. Set callback URL: https://your-domain.com/api/auth/callback/gitlab
  4. Set environment variables:
AUTH_GITLAB_ID=your-application-id
AUTH_GITLAB_SECRET=your-secret

Social 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:

MethodCallback URL
SAML ACShttps://api.your-domain.com/api/v1/sso/saml/acs
OIDC Redirecthttps://api.your-domain.com/api/v1/sso/oidc/callback
Google OAuthhttps://your-domain.com/api/auth/callback/google
GitHub OAuthhttps://your-domain.com/api/auth/callback/github
GitLab OAuthhttps://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:

  1. Configure and test SSO (SAML or OIDC)
  2. In Settings → SSO, toggle Enforce SSO
  3. 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.

On this page