Single Sign On and Identity Integration

Why identity comes first when you connect business systems

Every system you connect has to answer the same question before it does anything useful: who is this person, and what are they allowed to do. When each app keeps its own usernames and passwords, the answers drift. People reuse passwords, former employees keep working logins for months, and IT spends its week resetting accounts. Tepia starts most integration programs by putting one identity provider in charge and connecting everything else to it.

There are two common situations. Internal teams want staff to sign in once with their Microsoft or Google account and reach the CRM, the operations portal and the field app without another password. Software companies hear the same request from their customers, because enterprise buyers expect SAML single sign on and automatic provisioning before they sign, and their security questionnaires ask about both. The protocols overlap, but the design work differs, so Tepia scopes the two separately.

SAML, OpenID Connect, OAuth and SCIM side by side

The acronyms describe different jobs. Tepia usually combines two or three of them in a single project:

For native mobile apps, Tepia follows RFC 8252, the IETF best practice for OAuth in native apps, which means signing in through the system browser instead of an embedded web view. That lets the identity provider enforce MFA and conditional access without the app ever seeing the password.

Adding SSO to a product you sell to other companies

When your customers bring their own identity providers, every tenant needs its own connection. Tepia builds an admin screen where a customer’s IT team uploads SAML metadata or enters OpenID Connect details, verifies its email domain, and tests the connection before switching it on. Sign in then starts with an email address, and the app routes the user to the right provider based on the domain.

The details that matter come after the first login:

• Just in time provisioning creates an account on first sign in, while SCIM keeps it current afterward.
• Group to role mapping lets the customer decide who is an admin from their own directory.
• Enforced SSO turns off passwords for that tenant, with a documented break glass account for outages.
• Session rules such as idle timeout and forced sign out when SCIM deactivates a user.

These pieces sit on top of the tenant model described on our multi tenant SaaS architecture page, and they answer many of the access control questions in a SOC 2 aligned review.

Connecting internal tools to one identity provider

For internal systems, Tepia registers each app in Microsoft Entra ID, Okta or Google Workspace, assigns access by group, and lets conditional access policies require MFA or a managed device. Custom tools Tepia builds use OpenID Connect from day one. Older apps that only understand their own login can sit behind an identity aware proxy such as Microsoft Entra application proxy, which adds single sign on without rewriting the app.

Offboarding is where the payoff shows. When HR terminates someone, the directory disables the account, SCIM removes it from every connected app, and API tokens issued to that user are revoked. Tepia writes that chain down and tests it end to end, because a gap in it is how former employees keep access a year later. More on protecting connected systems is on our security and compliance page.

How Tepia approaches identity integration

1. Discovery: an inventory of every app, how users sign in today, which identity providers your staff or customers use, and how accounts are removed. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as an IT admin connecting Okta to your product.
2. Design: a design questionnaire, style guide and wireframes for the sign in screen, the domain discovery step, the tenant SSO setup page and error states that tell users what to do next.
3. Development and Testing: an Alpha against test tenants in Entra ID, Okta and Google Workspace, then a Beta with one real customer, with test plans for expired certificates, clock drift, deprovisioning and user acceptance.
4. Training: sessions for your support and IT teams on onboarding a customer’s identity provider and diagnosing failed sign ins from the logs.
5. Launch: migration of existing accounts by matching emails, a period where both password and SSO work, then enforcement tenant by tenant.
6. Support: issue resolution, certificate expiry monitoring and feature requests such as passkeys or a new identity provider.

Typically Discovery runs 1 to 3 months, development and QA 2 to 6 months, and launch about a month, with SSO for a single existing app at the short end. Read more about our process.

Hosted identity service or your own login code

Tepia rarely recommends writing authentication from scratch. Hosted services such as Auth0, Amazon Cognito, Firebase Authentication and Microsoft Entra External ID handle password storage, MFA, breached password checks and protocol edge cases, and they ship security fixes faster than a single product team can. The custom work is everything around them: tenant configuration, role mapping, provisioning and the sign in experience.

Owning more of the stack makes sense when contracts require everything to run inside your own cloud account, when your user model does not fit a hosted service, or when you need a sign in flow the service cannot customize. Even then, Tepia builds on well reviewed open source libraries for the protocols rather than new code. Talk to Tepia about the systems you want behind one sign in.

Frequently asked questions