Skip to main content
Orgo can act as an OAuth 2.0 provider. This means your members can use their Orgo credentials to log in to your website, internal tools, or partner applications — “Login with Orgo” — without creating separate accounts. OAuth application settings

​
When to use this

You want to…OAuth Server?
Let members log in to your website with their Orgo accountYes
Authenticate users in a custom mobile appYes
Provide SSO for internal tools (wiki, project manager)Yes
Give partner services access to member data (with consent)Yes
Let external people log in to Orgo using Google/MicrosoftNo — that’s SSO Authentication (inbound), not OAuth Server (outbound)

​
How it works

1. User clicks "Login with Orgo" on your app
   ↓
2. User is redirected to Orgo's login page
   ↓
3. User authenticates and approves access
   ↓
4. Orgo redirects back with an authorization code
   ↓
5. Your app exchanges the code for an access token
   ↓
6. Your app uses the token to get user info
This is the standard OAuth 2.0 Authorization Code flow.

​
Setting up an OAuth application

Settings → Developers → OAuth Applications → Create Application OAuth Apps management page showing configured applications
FieldWhat to enter
NameWhat users see during authorization — “My Organization Website”
DescriptionWhat the app does (for your reference)
Redirect URIsWhere Orgo sends users after authorization — must match exactly
ScopesWhat data the app can request
After creating the app, you’ll receive a Client ID and Client Secret. Store the secret securely — it’s shown only once.

​
OAuth endpoints

EndpointPurpose
/oauth/authorizeWhere you send users to log in
/oauth/tokenWhere your server exchanges the code for a token
/oauth/userinfoWhere your server retrieves the authenticated user’s data
Orgo includes a built-in OAuth documentation page that developers can reference when building integrations: Built-in OAuth developer documentation page

​
Implementation

​
Step 1: Redirect to authorization

Send users to Orgo’s authorization endpoint: 
GET /oauth/authorize?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=YOUR_REDIRECT_URI&
  response_type=code&
  scope=profile email

​
Step 2: Exchange code for token

After the user authorizes, Orgo redirects to your URI with a code. Exchange it server-side: 
POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTHORIZATION_CODE&
client_id=YOUR_CLIENT_ID&
client_secret=YOUR_CLIENT_SECRET&
redirect_uri=YOUR_REDIRECT_URI

​
Step 3: Get user info

Use the access token to retrieve the user’s profile: 
GET /oauth/userinfo
Authorization: Bearer ACCESS_TOKEN
Response: 
{
  "sub": "user-uuid",
  "name": "John Doe",
  "email": "john@example.com",
  "picture": "https://...",
  "groups": ["main-group", "local-center"],
  "roles": ["ROLE_USER"]
}

​
Available scopes

ScopeWhat it grants access to
profileName, profile picture
emailEmail address
groupsGroup memberships
rolesUser roles and permissions
Request only the scopes your app needs — fewer scopes means less data exposure and a simpler consent screen for users.

​
Common scenarios

The redirect URI in your authorization request must exactly match one of the URIs registered in the OAuth app settings. Watch for trailing slashes, http vs https, and port numbers.
Access tokens have a limited lifetime. Use refresh tokens to get new access tokens without requiring the user to log in again.
SPAs can’t safely store the Client Secret. Use the PKCE extension of the Authorization Code flow for browser-based apps, or handle the token exchange on your backend.
Use the roles scope to get the user’s Orgo roles. In your app, map these roles to your permission system — e.g., Orgo ADMIN_TENANT → your app’s admin role.
Never expose the Client Secret in client-side code (JavaScript, mobile apps). The secret must stay on your server. All token exchanges should happen server-to-server.
  • Integrations — Connect third-party services to Orgo
  • Members — User data that OAuth provides access to