Company Sign-in for Your Portal

By default your customers sign in to their support portal with an emailed link or code. For a company that runs its own identity provider, such as Microsoft Entra ID, Okta or any other OpenID Connect provider, you can also offer Sign in with company account on that company's portal. Its people then sign in with the work account they already use, and the emailed link stays available beside the button.

It takes three steps:

1. Add a connection to the company's identity provider under Settings → Service Desk → Single sign-on, and register DevStride's return address with the provider.
2. Test the connection. A connection is switched on only once its test passes.
3. Offer it on the company's portal from the company record.

Before you start: what the company's IT team sets up

Ask the company's identity-provider administrator to register DevStride as an application in their directory and send you three things: the issuer, a client ID and a client secret. The return address they need to register is shown in DevStride once you've added the connection (step 1 below), so you may go back and forth once.

• Use the company's own directory. The issuer must be one organization's own, over https. DevStride refuses shared issuers that let anyone claim any address: personal Google accounts (accounts.google.com) and Microsoft's common, organizations and consumers endpoints. For Microsoft Entra the issuer looks like https://login.microsoftonline.com/<tenant-id>/v2.0.
• The provider must say the email is verified. DevStride matches a signed-in person to a contact by email address, so it only accepts an address the provider marks as verified. Most providers do this on their own. Microsoft Entra does not by default. In the app registration, open Token configuration → Add optional claim → ID, and add both email and xms_edov. Without them, every sign-in is refused.
• Single-tenant, web application. In Entra, choose "Accounts in this organizational directory only" and a Web platform.

1. Add a connection

Go to Settings → Service Desk → Single sign-on and choose Add connection:

A connection can belong to one company, or be shared by every portal of your desk.

After you save, the connection shows its return address, ending in /auth/oidc/callback. Add every address it lists to the application's redirect URIs at the provider.

2. Test the connection

Choose Test. DevStride contacts the provider and checks that it answers as an OpenID Connect provider at that issuer. When it does, you'll see The provider answered. The connection is on.

• Only a tested connection can be offered. A new connection stays a draft until its test passes.
• Changing the issuer, client ID or scopes switches it back to a draft. Test it again before any new company can use it. Pointing it at a different provider also needs the client secret entered again: the old secret is never sent to a new provider.
• A failed re-test doesn't cut anyone off. Portals already using the connection keep working, but no other company can be pointed at it until a test passes again.
• Disable a connection to stop it being used, and Enable it when you're ready. It comes back on only if its last test passed.
• A connection a company is using can't be deleted. Change that company's sign-in setting first.

3. Offer it on a company's portal

Open the company under Service Desk → Companies. In its Portal sign-in section, set Sign-in to Company sign-in beside email and pick the connection. The company needs a portal address first.

What customers see

On the portal's sign-in page, a Sign in with display name button appears above the email form. A customer clicks it, signs in at their company's provider, and comes back signed in to the portal.

• The first time, DevStride links the person to the contact with the same verified email address, or adds them as a new contact of the company if there is none.
• After that, they sign in through their provider each time. A company sign-in lasts about 12 hours, shorter than the week an emailed sign-in lasts, so access follows the company's own directory closely. Access is also re-checked on every visit, exactly as for emailed sign-in.
• If the sign-in fails (the provider refused it, the address wasn't verified, or the portal's access mode doesn't let them in), the customer sees a short message and can use the emailed link instead. The reason isn't shown to the customer.

Merging and erasing contacts

A contact's company sign-in follows them:

• Merging a contact into another moves their sign-in to the surviving contact. See Merging duplicate requesters.
• Anonymizing a contact removes their company sign-in along with everything else. If the same person signs in through their provider again later, they start as a new contact. See Erasing a requester.

Permissions

Company sign-in has its own permission, Manage Portal SSO. It covers adding, editing, testing and removing connections, and choosing which companies' portals offer company sign-in. It requires Access Settings. The Portal sign-in section on a company also needs Manage Requesters.

The Owner holds it, and so does the Admin role of an organization created from now on. Other roles, including existing Admin roles and the Service desk agent template, don't include it, so an administrator must add it to a role. Whoever holds it decides which identity provider can vouch for a company's people, so grant it as you would an administrator permission.

See Service Desk permissions.