This article is for Fixably administrators who want their team to sign in to Fixably with the company identity provider through OpenID Connect (OIDC). It uses Okta as the worked example, but the Fixably side is the same for any OIDC provider such as Auth0, Keycloak or Microsoft Entra ID.

What OIDC sign-in does

With an OIDC provider configured, your employees sign in to Fixably by clicking a Sign in with {Provider Name} button on the login page. The button hands them to your identity provider, they authenticate there (including any multi-factor rules you enforce), and they land back in Fixably signed in.

Fixably only needs three values from your identity provider: an Issuer URL, a Client ID and a Client Secret. Everything else (authorization endpoint, token endpoint, signing keys) is discovered automatically from your provider's standard OIDC discovery document. There are no endpoints to type in by hand.

Optionally, Fixably can also create accounts for new employees the first time they sign in (just-in-time provisioning) and keep their Fixably roles in sync with the groups they belong to at your identity provider.

Before you start

• Third-party authentication must be enabled on your account. It is not included in every subscription plan. If you do not see an OpenID Connect Providers section under System Settings > Security > General, contact Fixably Support or your Customer Success Manager to have it enabled.
• You need to be a Fixably administrator to manage sign-in providers, and an administrator of your identity provider to register the application there.
• Only one sign-in provider can be active at a time. Enabling an OIDC provider automatically disables Azure AD, Google SSO or any other OIDC provider you had enabled. You can configure several OIDC providers, but only the enabled one shows a button on the login page.
• Keep a password login available while you set things up. A new OIDC provider is saved as disabled, and the standard username and password form stays on the login page unless you turn it off, so you cannot lock yourself out by following the steps below. If you ever need the password form while a provider is enabled, open https://<your-tenant>.fixably.com/login?default=1.
• Users are matched by email address. When someone signs in through the identity provider, Fixably looks for a user whose username equals the email address the identity provider returns. Before you roll SSO out, check that your employees' Fixably usernames are their work email addresses.

Step 1: Register Fixably as an application in Okta

The example below is for Northstar Device Services in Austin, whose Okta organization is https://northstar.okta.com. In another identity provider the screens differ, but you are always creating a server-side web application that uses the Authorization Code grant, and you will come back to it once with Fixably's redirect URIs.

1. In the Okta Admin Console, go to Applications > Applications and click Create App Integration.
2. Choose OIDC - OpenID Connect as the sign-in method and Web Application as the application type, then click Next.
3. Give the integration a name your admins will recognize, for example Fixably.
4. Under Grant type, leave Authorization Code checked. Fixably does not use any other grant type.
5. Under Sign-in redirect URIs and Sign-out redirect URIs, enter a placeholder such as https://example.com/callback for now. Fixably only generates the real values once the provider has been saved; you will replace the placeholders in Step 3.
6. Under Controlled access, assign the groups or users who should be able to sign in to Fixably, then click Save.
7. On the integration's General tab, under Client Credentials, note the Client ID and the Client secret. You will paste both into Fixably.

Where to find the Issuer URL

The Issuer URL is the base address your identity provider publishes its OIDC discovery document under. Enter it exactly as your provider documents it, without adding /.well-known/openid-configuration yourself; Fixably appends that automatically.

• Okta, org authorization server: your Okta org URL, for example https://northstar.okta.com.
• Okta, custom authorization server: https://northstar.okta.com/oauth2/<authorization-server-id>. In the Okta Admin Console, open Security > API > Authorization Servers, pick the server, and copy the Metadata URI without its /.well-known/openid-configuration suffix.
• Auth0: https://<your-tenant>.us.auth0.com.
• Keycloak: https://<your-keycloak-host>/realms/<realm>.

The Issuer URL must start with https:// and be reachable from the internet. Providers that are only reachable inside your own network cannot be used.

Step 2: Add the provider in Fixably

1. In Fixably, open your user menu > System Settings, then Security > General.
2. Scroll to the OpenID Connect Providers section and click Add OIDC Provider.
   
   
   
    
3. Fill in the Provider connection section:
   • Provider Name: the text your employees see on the login button, as in "Sign in with Northstar Okta". Up to 50 characters.
   • Issuer URL: the value from Step 1, for example https://northstar.okta.com.
   • Client ID and Client Secret: from the Okta integration's Client Credentials. Fixably stores both encrypted and never shows the secret again; when you edit the provider later, leave the secret blank to keep the stored one.
   • ID Token Signing Algorithm: leave at RS256 unless your identity provider is configured to sign ID tokens with a different algorithm. See Choosing the signing algorithm below.
   • API Audience: leave blank. This field is only needed when a separate system calls the Fixably API with tokens issued by your identity provider, and has no effect on employee sign-in.
4. Leave Enable Provider and Enable Just-in-Time Provisioning switched off for now and click Save settings. The provider appears in the list with a Disabled badge.
   
   
   
    

Step 3: Copy the redirect URIs back to Okta

The Redirect URI and Sign-out Redirect URI are generated when the provider is saved, because each one is unique to that provider. That is why they are not shown on the Add page.

1. Back in the OpenID Connect Providers list, click Edit on the provider you just saved.
2. Copy the Redirect URI and the Sign-out Redirect URI shown in the Provider connection section. Copy them rather than typing them: the exact values depend on your tenant address and default language, and Okta rejects anything that does not match character for character.
   
   
   
    
3. In the Okta Admin Console, open the Fixably integration's General tab and click Edit under General Settings.
4. Replace the placeholder Sign-in redirect URI with Fixably's Redirect URI.
5. Replace the placeholder Sign-out redirect URI with Fixably's Sign-out Redirect URI. This is what lets Fixably end the Okta session when a user logs out (see Signing out below); if it is missing, users see an Okta error page after logging out of Fixably.
6. Click Save in Okta.

Step 4: Test the connection

On the provider's edit page in Fixably, click Test Connection. A green result confirms that Fixably could reach the Issuer URL and read a valid OpenID configuration from it.

Test Connection does not verify the Client ID or Client Secret, and it does not check that the redirect URIs are registered at your identity provider. Those are only exercised by a real sign-in, so a passing test followed by a failing sign-in is a normal combination; see Troubleshooting below.

Step 5: Enable the provider and sign in

1. On the provider's edit page, switch on Enable Provider in the Sign-in behaviour section and click Save settings. The provider's badge changes to Enabled, and any other sign-in provider (Azure AD, Google, another OIDC provider) is disabled at the same time.
   
   
   
    
2. Open your Fixably login page in a private browser window. The Sign in with {Provider Name} button now appears above the username and password form.
   
   
   
    
3. Click the button, sign in with an Okta account whose email address matches an existing Fixably username, and confirm that you land in Fixably.

If you want to hide the username and password form once SSO works, the Disables default login method option is in the Third-party authentication section of Security > General. The password form always remains reachable at /login?default=1 for administrators.

Choosing how accounts and roles are handled

How much Fixably should do automatically depends on how you manage your staff. Pick the scenario that matches your shop.

Scenario A: Every employee already has a Fixably account

You create Fixably users yourself (for example in Austin, where the store manager adds each new hire under System Settings > Users) and only want SSO to replace passwords.

• Leave Enable Just-in-Time Provisioning off.
• Make sure each user's Fixably username is the same email address Okta holds for them. A user whose email is not found in Fixably sees "Something went wrong" when they try to sign in.
• Roles and permissions keep working exactly as you set them in Fixably.

Scenario B: Let Okta create Fixably accounts on first sign-in

You assign the Fixably integration to Okta groups and want anyone in those groups to get a Fixably account the first time they sign in, without an administrator creating it first.

• Switch on Enable Just-in-Time Provisioning on the provider and save.
• Fixably creates the user with the email address as username, with first and last name copied from the identity provider, as a regular user (not an administrator) and without a password. If Roles & Permissions is enabled on your account, the new user gets the basic User role until you assign more, or until group to role mapping (Scenario C) assigns them.
• The identity provider must report the email address as verified. If Okta sends the account's email as unverified, Fixably refuses the sign-in with "Your email address has not been verified by the identity provider". The user needs to verify their email at the identity provider; Fixably cannot override this.
• Who can be provisioned is controlled by the access you assign in Okta (Controlled access on the integration), so keep that assignment tight.
• First and last name are refreshed from the identity provider on every sign-in, not just the first.

Scenario C: Let Okta groups decide Fixably roles

You already manage who is a technician, who works the front desk and so on as Okta groups, and want Fixably roles to follow those groups automatically. This works with or without just-in-time provisioning, and requires Roles & Permissions to be enabled on your Fixably account (System Settings > Security > General). Group to role mapping only assigns roles from Roles & Permissions; the legacy roles are not affected.

1. In Okta, make sure the Fixably integration can release a groups claim. On the org authorization server, grant the integration the built-in groups scope. On a custom authorization server, add a groups claim to the ID token, scoped to the groups scope, that lists the user's group names.
2. In Fixably, open the provider's edit page and scroll to Group to role mapping.
3. Switch on Set roles automatically from identity provider groups.
4. Optionally choose a Default role for users whose groups match none of your mappings.
5. Click Add mapping for each group, enter the Okta group name exactly as it appears in Okta (matching is not case-sensitive) and pick the Fixably role, then click Save settings under the mapping table.
   
   
   
    

Things to know before turning mapping on:

• Mapping runs on every sign-in, and the identity provider wins. Each time a user signs in, their Roles & Permissions roles are replaced by whatever their current groups map to. A role you granted by hand in Fixably is removed at the next sign-in unless a mapping or the default role also grants it.
• If a user belongs to several mapped groups, they get all of the mapped roles.
• If the identity provider sends a groups list that matches nothing and no default role is set, the user keeps no mapped role and may not be able to do anything until you fix the mapping.
• If the identity provider sends no groups claim at all (for example, because the scope is not granted yet), Fixably leaves the user's roles unchanged. Turning mapping on before Okta releases the claim is therefore safe; releasing an empty groups list is not, because an empty list revokes every mapped role.
• Fixably administrators are never re-roled by the mapping.

Choosing the signing algorithm

Fixably verifies the signature of every ID token your identity provider returns, and the ID Token Signing Algorithm tells it which algorithm to expect. The default, RS256, is what Okta, Auth0, Keycloak and Entra ID use unless you have changed it. The dropdown offers RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 and ES512; unsigned tokens and shared-secret algorithms are never accepted. Only change the value if your identity provider's application or authorization server is explicitly configured to sign ID tokens with a different algorithm. A mismatch makes every sign-in fail after the user has authenticated at the identity provider.

Signing out

When a user logs out of Fixably, Fixably also ends their session at the identity provider (single logout) and then returns them to the Fixably login page. This is what the Sign-out Redirect URI from Step 3 is for: the identity provider only sends the user back if that exact URL is registered. If it is not, the user is still logged out of Fixably, but lands on an error page at the identity provider instead of the login page.

Changing or removing the provider

• Switching to another provider: add and enable the new one. Enabling it disables the current one; existing users and their accounts are untouched.
• Temporarily turning SSO off: edit the provider, switch off Enable Provider and save. The login page goes back to username and password. If "Disables default login method" was on, Fixably switches it off automatically so nobody is locked out.
• Deleting a provider (the Delete provider button on its edit page) removes the sign-in method and its group mappings. User accounts, including ones created by just-in-time provisioning, are kept; those users just need another way to sign in.
• Rotating the client secret: create the new secret at the identity provider, paste it into Client Secret on the provider's edit page and save. Leaving the field blank keeps the old secret.

Troubleshooting

If you need to contact Fixably Support about a sign-in problem, include the provider name, the Issuer URL, the email address of the user, the time of the attempt and the exact message shown on the login page.

Frequently asked questions

Can we keep Azure AD or Google sign-in alongside OIDC?
No. One sign-in provider is active per account. Enabling an OIDC provider disables the one that was active before. Microsoft Entra ID can also be connected as an OIDC provider if you prefer the extra options described in this article.

Can different departments use different identity providers?
You can save several OIDC providers, but only one can be enabled at a time, and only the enabled one appears on the login page.

Does the identity provider push users or groups to Fixably?
No. Accounts and roles are only created or updated when the person signs in. Removing someone at the identity provider stops them signing in; it does not deactivate their Fixably user, so deactivate departed staff in Fixably as well.

What is the API Audience field for?
It is only used when another system calls the Fixably API with tokens issued by your identity provider. Leave it blank for employee sign-in; if you have that integration scenario, contact Fixably Support for guidance.