🔐 SSO / OpenID Connect
OpenID Connect (OIDC) lets your team sign in to Docflo with the accounts you already manage - Microsoft Entra ID, Okta, Google Workspace, or any other OIDC-compliant provider. This is a two-sided setup: a few steps happen in Docflo, a few happen in your identity provider's admin console.
- Admin access to your identity provider, with permission to register a new application
- A Docflo account with the Admin role
- Your organization's email domain (e.g.
yourcompany.com), to route your users to this connection
Step 1: Copy your Reply URL
In Docflo, go to Settings → Security → Authentication → OpenID Connect. Before you configure anything, this page already shows a Reply URL - copy it. You'll need it in the next step.
Your identity provider needs this Reply URL before it can issue you a Client ID and Secret, so grab it first.
Step 2: Register Docflo as an application
In your identity provider, create a new confidential / web application (not single-page or native) and set its redirect/callback URI to the Reply URL from Step 1. Request these scopes:
| Scope | Purpose |
|---|---|
openid | Required - identifies the sign-in as OpenID Connect |
profile | Name and basic profile fields |
email | Email address, used to match your Docflo account |
offline_access | Keeps the connection working without repeated sign-ins |
When it's created, note down three things:
- Its Discovery URL (usually ending in
/.well-known/openid-configuration) - most providers publish one - The Client ID
- The Client Secret (shown once at creation - save it somewhere safe)
No Discovery URL available? Docflo also accepts the four endpoints individually - issuer, authorization, token, and JWKS URI - under Manual Configuration in the next step.
Step 3: Connect it in Docflo
Back on the OpenID Connect tab, choose Discovery URL or Manual Configuration, then fill in what you gathered in Step 2:
| Field | Example |
|---|---|
| Discovery URL | https://idp.example.com/.well-known/openid-configuration |
| Client ID | a1b2c3d4-e5f6-… |
| Client Secret | •••••••••••••••• |
| Domain Alias | yourcompany.com |
Save. Docflo will show the connection as active once it can reach your provider's Discovery URL.
Step 4: Map roles (optional)
If your identity provider includes a role or group claim in its tokens, use the Roles Mapping panel next to the connection to match each value to a Docflo role - for example, mapping a Finance-Admins group to Docflo's Admin role. Anyone without a match signs in with Docflo's default role.
Step 5: Test sign-in
Open Docflo in a private browser window and sign in. You should land on your identity provider's login page, then return to Docflo already signed in. Try this with one user before rolling it out to your whole team.
Example: Microsoft Entra ID (Azure AD)
Entra ID is the most common provider we see - here's exactly where each value lives.
Discovery URL = https://login.microsoftonline.com/<Directory (tenant) ID>/v2.0/.well-known/openid-configuration
| Item | Where to find it |
|---|---|
| Create the app | Microsoft Entra ID → App registrations → New registration |
| Client ID | Shown on the app's Overview page as "Application (client) ID" |
| Redirect URI | Authentication → Add a platform → Web → paste the Reply URL |
| Client Secret | Certificates & secrets → New client secret → copy the Value |
The Certificates & secrets page shows two similar-looking columns - Secret ID and Value. Copy the Value, not the Secret ID - it's the only one Docflo can actually authenticate with, and it stops being shown in full once you leave the page. If you're not sure which one you copied, create a new secret and copy the Value immediately.
Troubleshooting
Sign-in fails with a redirect/callback URI error (e.g. AADSTS50011)
The URI registered in your identity provider has to match the Reply URL from Docflo exactly - same case, no trailing slash, nothing added or removed. Re-copy it directly from the OpenID Connect tab rather than retyping it from memory or an older screenshot.
Can we run SAML and OpenID Connect at the same time?
Both can be configured, but role mapping is shared between them - whichever one you save last is the mapping that applies. We recommend fully moving to one before removing the other.
Our provider doesn't call it a "Discovery URL"
Look for terms like "OIDC metadata endpoint," "well-known configuration," or "OpenID configuration document" in your provider's SSO or OAuth settings - it's the same thing.
What happens to users who already have Docflo accounts?
Signing in through your identity provider matches on email address, so existing users keep their history, permissions, and data - they just authenticate differently going forward.
Questions while setting this up? Reach out to your Docflo contact or support@docflo.ai - we're happy to get on a call with your IT team.