Files.com supports Single Sign-On with Okta using either SAML or OpenID Connect (OIDC). SAML is recommended. It supports more use cases and works with user and group provisioning using SCIM. You can connect more than one Okta instance or app to your Files.com site.

For OAuth/OIDC setup, see Okta SSO via OAuth. For user and group provisioning, see Provisioning Users Automatically.

Okta SSO via SAML

The instructions below cover adding Files.com as an application in Okta for SAML integration.

Adding Files.com in Okta via SAML

After logging in to your Okta account as an administrator, navigate to Applications and click the Create App Integration button.

From the Create a new app integration window, select SAML 2.0 as Sign-in method and click Next.

In the form, enter "Files.com" in the App name field and click Next.

Complete the form using the following values (leave other fields at their defaults):

Field	Value
Single sign-on URL	`https://app.files.com/saml/consume`
Audience URI (SP Entity ID)	`https://app.files.com/saml/metadata`
Default RelayState	`[SUBDOMAIN].files.com` (Replace `[SUBDOMAIN]` with your Files.com subdomain).
Name ID format	EmailAddress
Application username	Email (This controls the value Okta sends as the SAML NameID. Files.com uses this value as the Files.com username. See How Files.com Matches Okta Users for details.)
Update application username on	Create and Update

Then click Next, choose I'm an Okta customer adding an internal app (leave other fields at their defaults), and click Finish.

On the App details Sign On page, copy the Identity Provider metadata URL. You will need this URL when adding Okta in Files.com.

Adding Okta in Files.com via SAML

Select Okta from the SSO providers list, then select Use SAML, and enter the Display Name.

Create a new SSO Provider entry using the Okta type and the SAML protocol.

You must provide a Display Name for your new provider. This is shown on login forms to let users choose the correct SSO Provider.

There are three ways to connect to your SAML provider. The right method depends on your requirements. The Metadata URL is the simplest option because it automatically handles updates like certificate renewals or changes to service provider URLs. If you don't need automatic updates, you can connect to your provider by authenticating with Metadata XML. We also support using a Certificate Fingerprint, which gives more control over updates but requires more effort to manage over the long term.

Using Metadata URL

Using Metadata URL to connect is the most straightforward option. Put the Identity Provider metadata URL you copied from Okta into the Metadata URL field.

Using Metadata XML file

If you need to use a metadata XML file to connect to Okta via SAML, log in to Okta as an administrator and save the content of the Identity Provider metadata URL to an XML file. In Files.com, select the option Metadata XML file and select the XML file you created from Okta.

Using Certificate Fingerprint

If you need to use Certificate Fingerprint to connect to Okta via SAML, download the certificate from Okta application dashboard. To get the certificate and issuer URL, go to the application you created in Okta and click on Sign On -> View Setup Instructions. After downloading the certificate to your local machine, run the following command using terminal to obtain the Certificate's Fingerprint.

openssl x509 -in [your_cert_file] -noout -sha256 -fingerprint

In Files.com, select the Certificate Fingerprint option and paste the fingerprint you obtained from the above command. Also, paste the Issuer URL you copied from Okta. You can use the same URL for SLO endpoint and SSO endpoint also.

Assigning Users and Groups

After you save the Okta SSO configuration, the Sign in with Okta button appears on your site's login page. The Okta SSO method is available when assigning an authentication method for a user in Files.com.

Before users can access the Files.com application, they must be assigned to it in Okta. Go to the Assignments tab of the Files.com application in Okta and assign the required users or groups. Okta does not support nested groups. Users must be assigned individually or through direct groups. If you sync groups from Active Directory, Okta flattens nested group structures and treats users as direct members of the top-level group for assignment purposes.

Keep at least one site administrator on password authentication rather than assigning every administrator to SSO. This prevents lockout if your IdP or SSO configuration has issues.

How Files.com Matches Okta Users

Files.com matches Okta users by the Files.com username field. The Application username format in your Okta SAML app controls what Okta sends as the SAML NameID, and Files.com uses that value as the Files.com username.

When set to Email, Okta always sends user.email as the NameID. Each Files.com user must have a username that matches their Okta email address. This is the recommended setting and the one used in the configuration above.

When set to Okta Username, Okta sends user.login as the NameID. In cloud-only tenants user.login is typically the email address. In tenants connected to Active Directory, user.login may be a SAMAccountName (e.g. jsmith) or UPN that differs from the email address. The Files.com username must match that value instead.

If you also use SCIM, the SAML NameID and the SCIM userName must resolve to the same Files.com username. Okta's SCIM configuration uses email as the identifier by default. If the Application username is set to Okta Username and user.login differs from the email in an AD-connected tenant, SCIM and SAML send different identifiers and Files.com creates a duplicate account. Setting the Application username to Email keeps SAML and SCIM aligned. Contact Files.com Support if you need help with an AD-connected tenant.

Support for Custom Domains

Files.com supports Okta custom domains when using SAML based SSO. To ensure the SSO login flow routes through the Okta custom domain rather than the default Okta domain, Files.com must be configured with a SAML Provider Connection Method that references the Okta custom domain. This includes using a Metadata URL, Metadata XML file, or certificate fingerprint generated from the Okta custom domain.

SAML authentication uses the domain that receives the initial request to determine the SSO endpoints and issuer. If the authentication request is sent to the default Okta domain, Okta uses the default domain even when a custom domain is configured.

You can also use a Files.com custom domain for your Files.com site. For SAML integrations, update the Okta Default RelayState so users are redirected to the Files.com custom domain after login.