Files.com supports Single Sign-On with Okta using either SAML or OpenID Connect (OIDC). We recommend using SAML if possible, because it is a more robust integration technology that supports more use cases, and it also offers seamless user and group provisioning using SCIM. Both sets of instructions are presented here. You can connect more than one Okta instance or app to your Files.com site.

Okta SSO via SAML

Below are the instructions for 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):

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 3 ways to connect to your SAML provider. Choosing the correct 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 in 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 metadata XML file to connect to Okta via SAML, as a Okta administrator, save the content of 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. Once the Certificate is downloaded on 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

Once you save the changes, the Okta SSO method will now be available when assigning an authentication method for a user in Files.com, and the Sign in with Okta button will be displayed on your site's login page.

Users and groups need to be assigned to the Files.com application in Okta before they can be authorized to access the Files.com application.

It is strongly recommended to keep at least one site administrator with the password option as the authentication method, rather than assigning all to SSO, to prevent being locked out of Files.com in case of IdP or SSO issues.

Okta SSO via OAuth or OpenID Connect

Below are the instructions for adding Files.com as an application in Okta via OAuth or OpenID connect (OIDC). If you plan to use SCIM for user and group provisioning, note that SCIM provisioning is only compatible with SAML-based integration, not with OAuth or OpenID Connect (OIDC).

Adding Files.com in Okta

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

Select OIDC - OpenID Connect as sign-in method, and select Web Application as the Application type, and then click the Next button.

In the form, enter Files.com in the App Integration Name field, and enter the following URL in the Sign-in redirect URIs field. You can use the same URL for Sign-out redirect URIs.

https://app.files.com/login_from_oauth?provider=okta

Select the appropriate option under Controlled access in the Assignments section based on your requirements.

Click the Save button to finish adding the application. In the integration summary page, find the Client Credentials box. Click the clipboard icon next to the Client ID to copy it. Keep this browser tab open, as you'll be returning here to copy the Client Secret later.

Adding Okta in Files.com

A site administrator can add a new SSO Provider to your site. Select Okta provider for the type of provider and select Use OAuth.

You should provide a Display Name for your new provider; this will be shown on the login page of your Files.com site.

Enter your Okta subdomain into the Subdomain field, and paste the Client ID you copied in the previous step into the Client ID field.

Copy your Client secret from Okta, and paste it into the Client secret field in Files.com.

The Okta SSO method will now be available when assigning an authentication method for a user in Files.com, and the Sign in with Okta button will be displayed on your site's login page.

It is strongly recommended to keep at least one site administrator with the password option as the authentication method, rather than assigning all to SSO, to prevent being locked out of Files.com in case of IdP or SSO issues.

Provisioning Users Automatically

There are two ways to automatically provision users via Okta.

SCIM Provisioning

SCIM Provisioning is a standard that allows your Users to be automatically provisioned in Files.com from Okta. Note that SCIM provisioning is only compatible with SAML-based integration, not OAuth or OpenID Connect (OIDC).

First, you'll need to select the "SCIM" provisioning method in Okta at Applications -> Files.com -> App Settings -> Provisioning.

Then use the following settings in Okta at Applications -> Files.com -> Provisioning -> SCIM Connection:

If Authentication Mode is set to Basic Auth, generate the Basic Auth username and password in Files.com by navigating to the advanced settings in the Add/Edit SSO provider form. Under the Enable automatic user provisioning via SCIM? section, select Basic, then click Generate SCIM Username and Password. Copy both values and enter them in Okta for SCIM provisioning. Note that the credentials will only become active after saving the Add/Edit SSO provider form.

If Authentication Mode is set to HTTP Header, generate the bearer token by selecting Token in the same section, then click Save to generate the token. Copy the token and enter it in Okta for SCIM provisioning setup.

In Okta at Applications -> Files.com -> Provisioning -> To App, ensure that the Create Users, Update User Attributes, and Deactivate Users are in checked state.

After setting the above, your Okta users assigned to the Files.com application in Okta will be provisioned to Files.com and should be able to log in to Files.com via SSO.

Files.com offers numerous configuration options for SCIM provisioning, detailed in the Configuration Options section under our SCIM provisioning documentation.

Just-In-Time (JIT) Provisioning

JIT Provisioning operates by generating user records on Files.com upon their initial successful login. While this method is simpler than SCIM, it does have limitations. For instance, JIT can provision users but lacks the ability to delete or disable them. Files.com will automatically use Just-In-Time (JIT) Provisioning if you don't set up SCIM.

Troubleshooting

If you encounter issues with authentication or provisioning between Okta and Files.com, review the following troubleshooting steps to identify and resolve the problem. You can also check the History Logs and SCIM Logs for details related to authentication and provisioning activity.

Users and Groups Assignment in Okta

If users encounter authentication issues during SSO login to Files.com, such as receiving an error stating that the user is not assigned to the application, check the user and group assignment settings in your Files.com application in Okta. By default, Okta requires users or groups to be explicitly assigned to an application before they can access it.

In this case, authentication may succeed but authorization fails if the user is not assigned to the application. To resolve the issue, go to the Assignments tab of the Files.com application in Okta and ensure that the required users or groups are assigned. Note that Okta does not support nested groups within its own platform. Users must be assigned either individually or through direct groups. If no users or groups are assigned, no one will be able to access the application. If you are syncing groups from an external directory like Active Directory, Okta flattens any nested group structures, treating users as direct members of the parent group for application assignment purposes.

Provisioning updates from Okta to Files.com may not appear immediately if multiple user or group changes occur close together. Okta processes these updates sequentially, and pending jobs can delay when changes are reflected in Files.com. This is expected behavior when many provisioning events are queued. If the status in Okta remains pending for an extended time, review the provisioning logs and trigger a re-push or force provisioning action to complete the update.

Users Provisioned but Missing from Groups

In some cases, users may be successfully provisioned to Files.com via SCIM but not added to the expected group. This occurs because of a known limitation in Okta’s provisioning process. When the same group in Okta is used for both application assignment and Group Push, Okta may process the group membership update before the user profile provisioning is complete. This creates a race condition in which the user account appears in Files.com, but the group membership update fails to apply.

To prevent this behavior, maintain separate groups for each purpose, one for application assignment and another exclusively for Group Push. This ensures user profiles are created before membership updates occur and keeps group data consistent in Files.com. Okta does not support using the same group for both app assignment and Group Push. To maintain reliable and predictable provisioning, always create and manage a dedicated group in Okta for Group Push.

Group Push Errors and Mapping Failures

Group Push from Okta to Files.com can occasionally fail, show a pending status, or result in incorrect membership data. These issues often occur when the link between the pushed group in Okta and the corresponding group in Files.com becomes misaligned. The most common causes include deleting or renaming a pushed group in Files.com or making manual changes that break the mapping between Okta and the target group. Once this connection is disrupted, Okta cannot correctly update or remove members during provisioning.

To fix this issue, review the affected groups in the Push Groups section of the Okta admin console and check the error details. After correcting any configuration or mapping problems, click Retry All Groups to re-push the affected items. If the problem persists, remove the existing group push configuration in Okta and push the group again to recreate the connection with Files.com.

If errors continue, create a new group in Okta and push it to Files.com. Successful provisioning with a new group confirms that the issue is tied to the original mapping rather than the integration itself. Regularly monitoring group push activity and avoiding manual group changes in Files.com helps maintain consistent provisioning and prevent future failures.