Single sign-on

It often starts with a tender requirement: staff must be able to log in to your service with their work account. Connecting to the customer’s accounts is rarely the hard part. What takes time is the users you already have, their permissions and what happens when someone leaves.

How does a customer’s organisation connect?

Your customer keeps its work accounts with an identity provider, such as Microsoft Entra ID, Google Workspace or Okta. We build login on OpenID Connect, which Entra ID, Google Workspace and Okta all support. If the customer requires SAML, that is separate work. With Entra ID, the customer’s IT team connects the whole organisation through a link and an approval in Microsoft. You decide which organisations get to connect.

Employees get access the first time they log in with their work account, and an existing account can be linked by email address once the customer’s domain is verified. One permission model controls which services and features each customer and user can use.

Not everyone has a work account to log in with. The same login can also handle email and password, or a licence key for shared access. If users need to identify themselves with Swedish e-ID, we also build BankID login.

Does single sign-on take care of people who leave?

No. Single sign-on decides how users get in, not which users should exist in your service. That’s what SCIM 2.0 is for, an open standard for automatic user provisioning: the customer’s directory creates, updates and removes users in your service. New starters get access and leavers lose it, without anyone changing anything by hand.

The customer’s own admins can also manage their users themselves, and every change is logged with who made it.

What happens to the accounts you already have?

They move to the new login when each user logs in. Whether passwords can come along depends on how they are stored today. We look at that before we promise anything. It happens one user at a time, so you don’t have to move everyone at once.

We build the login in Java and Spring, and the login flows are covered by automated tests. If more of your systems need to share user data, we build API integrations that let them fetch and update it.