Single sign-on and SCIM

Sign in with your own identity provider

Connect Okta, Azure AD, Google, or any SAML or OIDC provider, and your team signs in with the credentials they already have. SCIM provisions and disables accounts automatically, so access always matches your directory.

Enable SSO See how it flows
SAML 2.0 and OIDC SCIM provisioning MFA via your IdP SOC 2 audit log
Identity the way security expects it SAML 2.0 and OIDC SCIM auto-provisioning SOC 2 Type II audited MFA enforced via your IdP
0
Identity providers, plus any SAML or OIDC
SCIM
Auto-create and disable, in sync with your directory
JIT
Just-in-time provisioning on first sign-in
0
Passwords for your team to manage
The account that outlives the person

Manual accounts drift out of your control

When people sign in with a separate username and password, your directory and your access list slowly diverge. Someone leaves and their account lingers, a new hire waits on a manual invite, and no one can prove that access matches who actually works here. That gap is exactly what a security review looks for.

Single sign-on closes it. Your team authenticates through the identity provider you already run, with the multi-factor you already enforce, and SCIM keeps the account list in lockstep with your directory: created on hire, updated on a role change, disabled the moment someone leaves.

Separate accounts
  • A password to manage outside your directory
  • Orphaned accounts after someone leaves
  • New hires wait on a manual invite
  • MFA is optional and uneven
  • No proof that access matches the org
With single sign-on
  • Sign in with the identity you already have
  • SCIM disables accounts the moment they leave
  • New hires provisioned automatically
  • MFA enforced by your own provider
  • Access always matches your directory
Sign-in and provisioning, end to end

Your directory is the source of truth

A user signs in through your provider, and access is scoped without a password ever touching us. SCIM keeps the roster in sync.

User signs in

With their work identity, at your login

Your IdP verifies

Okta or Azure AD checks identity and MFA

Scoped session

File.Business grants access by role, no password

SCIM provisioning, always in sync

Alex Vance provisioned as Member, scoped to Californiaon hire
Sam Okafor role updated to Admin from the directoryrole change
Priya Nair deprovisioned, disabled in Oktaon exit

No password ever reaches File.Business. Authentication stays with your provider, and the account list follows your directory automatically, so there is nothing to reconcile by hand.

Works with what you already run

Every major provider, plus any standard

If it speaks SAML 2.0 or OIDC, it connects. The big providers are ready out of the box.

OK

Okta

SAML and SCIM, ready to connect

AZ

Microsoft Entra ID

Azure AD sign-in and provisioning

G

Google Workspace

Sign in with Google identities

A0

Auth0

SAML and OIDC connections

1L

OneLogin

SAML sign-in and SCIM sync

PI

Ping Identity

Enterprise SAML and provisioning

S2

Any SAML 2.0

Connect any standards-based IdP

ID

Any OIDC

OpenID Connect providers welcome

How you turn it on

Connect, map, and enforce

Five steps, run with our team. Select one to see the detail.

Step 1

Connect your identity provider

Add File.Business as a SAML or OIDC application in Okta, Azure AD, Google, or any standards-based provider, and exchange metadata. Our team helps with the setup so the connection is right the first time.

SAML 2.0 or OIDC, connected with your provider's standard flow.
Provider: OKTA
SAML metadata exchanged
Connection verified
Step 2

Map attributes and roles

Map your directory's groups or attributes to File.Business roles, so a person's group in your IdP becomes their role and scope here. A change in the directory becomes a change in access, with no manual step.

Directory groups map to the four roles and per-entity scope.
Group Compliance-Admins to Admin
Region groups to entity scope
Attributes mapped
Step 3

Turn on SCIM provisioning

Enable SCIM and the account list stays in lockstep with your directory: users are auto-created on hire, updated on a role change, and disabled the moment they leave. Just-in-time provisioning also creates an account on a first successful sign-in.

Auto-create, update, and disable, plus just-in-time on first sign-in.
SCIM: ACTIVE
Auto-create and disable
JIT on first sign-in
Step 4

Enforce SSO for everyone

Require sign-in through your provider so there are no local passwords to phish or leak, and let your IdP enforce the multi-factor policy you already run. One place controls how everyone gets in.

No local passwords; MFA enforced by your own provider.
SSO: ENFORCED
MFA via your IdP
No local passwords
Step 5

Prove it with the audit log

Every sign-in, provisioning event, and role change is written to a SOC 2 ready audit log. When a reviewer asks who has access and how they authenticate, the answer is a report, not a scramble across systems.

A SOC 2 ready audit log of sign-ins and provisioning events.
Audit log: SOC 2 READY
Sign-ins and provisioning logged
Export for a review
How SSO compares

Identity your security team can sign off on

The usual ways of managing access all leave a gap. Here is the difference.

Capability File.Business SSO Email and password Manual accounts Build your own
SAML 2.0 and OIDC sign-inNot availableNot availableHeavy build
SCIM auto-provision and disableNot availableManualCustom
MFA enforced by your IdPOptionalOptionalIf you build it
Directory groups map to rolesNot availableNot availableCustom
No orphaned accounts on exitCommonCommonIf you build it
SOC 2 ready audit logBasicBasicCustom

The point. Passwords and manual accounts always drift from the org chart, and closing that gap by hand never quite happens. SSO with SCIM makes your directory the single source of truth, so access is correct by construction. Compare the platform on the comparison hub.

From a team that connected its directory

Offboarding stopped being a checklist

We enforce MFA and manage everything from Okta, so a tool with its own passwords was a non-starter for us. With SSO and SCIM, people just sign in the way they sign in everywhere else, and when someone leaves Okta, their access here is gone the same second. Our reviewer loved it.
IT and security lead
Organization managing a large entity portfolio
1 IdP
controls how everyone signs in
SCIM
keeps the roster in sync automatically
0
orphaned accounts after a departure

Representative composite based on customer outcomes. Setup depends on your provider and directory.

Everything SSO connects to

Team roles, security, and enterprise

Where to go to pair identity with access and prove it.

Access

Team Permissions

The roles and per-entity scoping that SSO maps into.

See roles Security

Security overview

SOC 2, the audit log, and the review packet for your team.

Read the overview Legal

Data Processing Agreement

The DPA and subprocessor list for your legal team.

See the DPA Scale

Enterprise

SSO, SCIM, and a dedicated team, in one contract.

See enterprise
For the questions IT asks

Straight answers on protocols, provisioning, and proof

Which protocols do you support?
Both SAML 2.0 and OpenID Connect (OIDC). You connect File.Business as an application in your provider and exchange metadata, and users sign in through your provider rather than a local password.
Which identity providers work?
Okta, Microsoft Entra ID (Azure AD), Google Workspace, Auth0, OneLogin, and Ping Identity are ready out of the box, and any standards-based SAML 2.0 or OIDC provider connects as well, including a custom one.
Do you support SCIM provisioning?
Yes. SCIM keeps the account list in sync with your directory: users are auto-created on hire, updated when their role or group changes, and disabled the moment they leave. There is nothing to reconcile by hand.
Is just-in-time provisioning available?
Yes. In addition to SCIM, just-in-time provisioning can create an account on a user's first successful sign-in through your provider, so a new hire does not wait on a manual invite.
Can I map directory groups to roles?
Yes. Map your groups or attributes to the four roles and to per-entity scope, so a person's group in your IdP becomes their role and access here. A change in the directory becomes a change in access automatically.
How is multi-factor handled?
Multi-factor is enforced by your identity provider, so the policy you already run applies here too. Because authentication stays with your IdP, there is no separate MFA to configure and no local password to phish.
Is there an audit log?
Yes, and it is SOC 2 ready. Every sign-in, provisioning event, and role change is recorded with a timestamp, so when a reviewer asks who has access and how they authenticate, you can hand them a report. See the security overview.
Which plan includes SSO?
SSO and SCIM are on the enterprise tier, alongside role-based team permissions, a signed DPA, and an uptime SLA. See enterprise and the pricing page, or talk to sales.
Your identity provider, your rules

Put sign-in and provisioning where they belong

Connect your identity provider with SAML or OIDC and turn on SCIM, or talk with our team about enabling SSO for your organization.

Enable SSO See team roles
SAML 2.0 and OIDC · SCIM provisioning · MFA via your IdP · SOC 2 audit log