Set up single sign-on (SSO)

SSO lets your team sign in with the accounts they already have, through your identity provider, instead of a DepreciationPro password.

Changing SSO settings is Technical Admin work and needs someone with access to your identity provider's admin console. A Manager can view the configuration and domain badges but cannot change them.

Go to Settings → Users & Security → Single Sign-On.

There is a Setup guide button at the top of the tab with step-by-step instructions for Azure AD, Okta, and Google Workspace. If you use one of those three, start there rather than here.

Email Domain(s). The email domains that trigger SSO login, like yourfirm.com. This is what tells the sign-in page to send your people to your identity provider instead of asking for a password.

Add each domain with Add domain — the part after the @ in your firm's email addresses, so just yourfirm.com, not a web address and not a whole email address. Capitals and extra spaces do not matter. Three claims are refused, each with a message saying what to do instead:

Adding a domain is a claim. Before SSO will run on it, you have to show the domain is yours — otherwise anyone who typed yourfirm.com into their own account could send your people to their identity provider.

Each domain shows a badge: Pending until it is proven, Verified once it is.

You cannot type your own address to receive the code, and that is the point of the whole step: a code sent to an address you chose freely would only prove you control that one mailbox. A code sent to [email protected] proves somebody at your firm controls the domain. The panel always shows which address it used.

The code is good for 72 hours. Sending a new one replaces the old one, so use the most recent email.

If the code does not arrive. These are standard mailbox names, but plenty of firms have never set one up, and mail sent to an address that does not exist is silently discarded. Try another address from the list — one of the five is usually routed to somebody. Check spam. If none of them work, contact support and we can verify the domain for you; a domain verified that way is recorded separately and the panel says so.

If the site says email delivery is not configured, no code was sent and none is coming. That is a setting on our side, not something you can fix from this screen — contact support.

Removing a domain. Remove releases the claim and frees the domain to be set up again, by you or by another firm. Verification does not survive removal — re-adding it means verifying it again.

Authentication Protocol. SAML 2.0 or OpenID Connect (OIDC). Your identity provider decides this, not you. Pick whichever your provider is set up for.

If you chose OpenID Connect, you paste a Client Secret from your identity provider. Once it is
saved, we never display it again — not to you, not to anyone else at your firm, not to us.

So when you come back to this tab later, the Client Secret box is empty, and beside it you will
see Secret saved with the date it was last updated. That is what a saved secret looks like. It
does not mean the secret was lost.

Leave the box blank to keep the secret you already have. You can change the domains, switch
Enforce SSO on or off, and save as often as you like — a blank box always means "keep it". Type in
the box only when you actually want to replace the secret, for example after rotating it at your
identity provider.

Your firm's audit log records that the secret was changed and when. It never records the value.

Then Save configuration.

The Service Provider Details panel gives you the values to paste into your identity provider. They are shown on the tab, grouped by protocol, with a Copy button beside each one:

If you chose SAML 2.0:

If you chose OpenID Connect:

Copy these from your own screen, not from a setup guide or another firm's configuration. The ACS URL, the metadata URL and the OIDC Redirect URI all contain your firm's own identifier, so a value copied from anywhere else will not work.

Test connection sits under the Save button once a configuration is saved. It sends you to your
identity provider, brings you back, and reports whether the handshake worked and which protocol was
used.

The result page does not repeat the email address back to you. You typed it, so you already know it
— and an address shown on that page would have travelled there in the web address, which is not a
private place to put one.

It is a test, not a sign-in. It does not change who you are signed in as, and it does not create an
account for the address your provider returns. If the address that comes back is not one your
configuration covers, the test says so rather than letting that person in.

Run it before you turn on Enforce SSO. Once enforcement is on, a broken configuration locks
your firm out of password login as well.

Single sign-on enabled is a switch above Enforce SSO. Turn it off and your people sign in with
passwords again, immediately — your identity provider settings, certificate and email domains all
stay where they are, so turning it back on is one click rather than a re-entry.

Use this rather than Delete configuration if you are troubleshooting, or if your identity
provider is down. Deleting throws the settings away.

SSO controls who can sign in. It does not decide what they can do once they are in. Roles and client access are still set on the Users tab. See User roles, and what each one can do.

Deactivate their account in Settings → Users & Security as well as disabling their identity
provider account. Disabling the directory account prevents a new SSO sign-in; it does not revoke
an existing DepreciationPro session or deactivate the application account. DepreciationPro checks
application revocation periodically, with a configured five-minute interval. SSO does not synchronize
directory offboarding into DepreciationPro.