Orbit can act as an OAuth2 / OpenID Connect (OIDC) identity provider for your external applications. This lets third-party apps authenticate users through Orbit and access membership data — useful for gating content, personalizing experiences, or building member-only tools that share a single login with your portal.
This is different from Third-Party Authentication
The Authentication page covers using an external identity provider (Auth0, Okta, etc.) to sign members into Orbit. This page covers the reverse — using Orbit itself as the identity provider for your other applications.
How It Works
Orbit implements the OAuth2 Authorization Code flow with PKCE via the OpenID Connect protocol.
- User clicks "Sign in with Orbit" in your external application
- Your app redirects to Orbit's authorization endpoint
- User authenticates on Orbit (or is already logged in)
- User consents to sharing the requested scopes
- Orbit redirects back to your app with an authorization code
- Your app exchanges the code for access and ID tokens (server-side)
- Your app reads user info from the ID token or the userinfo endpoint
Available Scopes
| Scope | What it returns |
|---|---|
openid |
Required. Enables OpenID Connect and returns a signed ID token |
profile |
User's name (name, given_name, family_name) |
email |
User's email address and email_verified flag |
orbit_membership |
Membership status (active, expired, none) and tier name |
The orbit_membership scope is unique to Orbit — it lets your application check whether the user is an active member and which membership level they hold, without needing to call a separate API.
Setting Up an OAuth2 Client
Step 1: Enable the OIDC Server
In the Orbit admin portal, go to Settings > General and enable the OIDC Server toggle. This makes the OIDC endpoints available on your portal's domain.
Step 2: Create a Client Application
- Go to Settings > OIDC Clients
- Click Create Client
- Enter a name for the application (e.g. "Members-Only Blog")
- Set the Redirect URI to your application's callback URL (e.g.
https://blog.example.com/auth/callback) - Save the client — Orbit generates a Client ID and Client Secret
Copy the Client ID and Client Secret into your application's configuration.
Step 3: Configure Your Application
Point your application's OAuth2 library at these endpoints (replace your-portal.example.com with your Orbit domain):
| Endpoint | URL |
|---|---|
| Discovery | https://your-portal.example.com/oidc/.well-known/openid-configuration |
| Authorization | https://your-portal.example.com/oidc/authorize/ |
| Token | https://your-portal.example.com/oidc/token/ |
| Userinfo | https://your-portal.example.com/oidc/userinfo/ |
| JWKS | https://your-portal.example.com/oidc/.well-known/jwks.json |
Most OAuth2 libraries can auto-configure from the Discovery URL alone.
Example: Userinfo Response
When your application calls the userinfo endpoint with scopes openid email profile orbit_membership, the response looks like:
{
"sub": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"email": "jane@example.com",
"email_verified": true,
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"membership_status": "active",
"membership_tier": "Professional"
}
Example: Integration with a Web App
Here's a typical setup using a generic OAuth2 client library:
# Example using Python (authlib)
from authlib.integrations.requests_client import OAuth2Session
client = OAuth2Session(
client_id='YOUR_CLIENT_ID',
client_secret='YOUR_CLIENT_SECRET',
scope='openid email profile orbit_membership',
redirect_uri='https://your-app.com/auth/callback',
)
# Step 1: Redirect user to Orbit
authorization_url, state = client.create_authorization_url(
'https://your-portal.example.com/oidc/authorize/'
)
# redirect user to authorization_url...
# Step 2: Exchange code for tokens (in your callback handler)
token = client.fetch_token(
'https://your-portal.example.com/oidc/token/',
authorization_response=request.url,
)
# Step 3: Get user info
userinfo = client.get('https://your-portal.example.com/oidc/userinfo/').json()
print(userinfo['membership_status']) # "active"
Use Cases
- Member-only content — gate blog posts, downloads, or tools behind Orbit login and check
membership_status - Tiered access — show different features based on
membership_tier(e.g. "Professional" vs "Student") - Single sign-on — let members access multiple related applications with one set of credentials
- Custom portals — build a fully custom member experience while relying on Orbit for identity and membership data
Security
- All flows use PKCE (Proof Key for Code Exchange) to prevent authorization code interception
- Token exchange happens server-side — client secrets are never exposed to the browser
- Access tokens expire after 1 hour by default
- ID tokens are signed with RSA (RS256) and can be verified using the published JWKS endpoint
- Each tenant has isolated OAuth2 clients — applications registered on one portal cannot authenticate users from another