SSO Implementation: A Guide to Single Sign On Implementation

SSO implementation is the work of connecting your organization’s applications to one identity provider, so people sign in once and reach every app they are entitled to use. Single sign-on is the outcome. Implementation is the sequence of decisions and configuration that gets you there without locking anyone out. The work usually starts with a trigger: a new SaaS contract that requires SSO, an audit finding on shared passwords, or a device-trust requirement that per-app logins cannot meet.

This guide covers how to implement SSO for the IT or identity admin doing that work. If you own an application and need to add SSO support to it, the same steps apply from the other side of the handshake. We mark where the app team’s job starts. Throughout, we use Scalefusion OneIdP as the worked example, with the field names its dashboard uses.

SSO implementation steps, in order

1. Inventory the applications, the users and the identity provider you will build on.
2. Pick SAML or OIDC for each app, based on what the app supports.
3. Exchange identifiers, endpoints and certificates between the identity provider and each app.
4. Assign a small test group and agree on the attribute mappings.
5. Walk the sign-in round trip and confirm the app validates what it receives.
6. Decide how users are matched, created, grouped and removed.
7. Set session length, re-authentication and logout behavior.
8. Test the failure cases, pilot with one group, then expand.

What do you need before implementing SSO?

Identify the applications, users, identity provider, and existing accounts

List the applications people sign in to and mark which ones support SAML or OIDC natively. Vendors document this in their admin guides, and some limit it to specific plans. Record where identities live today: Google Workspace, Microsoft Entra ID, Okta, an on-premises Active Directory, or a mix. Then list the local accounts inside each app, since each will need matching to an identity later.

The last item is the identity provider (IdP) itself: the directory you already have, or an access layer in front of it that adds device checks. OneIdP offers both routes. Its Directory stores, verifies and manages user identities under a domain you own, and it federates to Google Workspace, Microsoft Entra ID, Okta, PingOne or on-premises Active Directory. The prerequisites are the same either way: OneIdP set up on the dashboard, a verified custom domain, users imported and migrated to OneIdP, and user-based device enrollment.

Map the sign-in flow between the identity provider and your app

A sign-in can start in two places. In the service-provider-initiated flow, the user opens the app first and is redirected to the identity provider. In the identity-provider-initiated flow, the user signs in at the IdP and picks the app from a portal. OneIdP’s User Portal is that portal, with tiles for Google Workspace, Microsoft Entra ID and Zoho present by default. One caveat: OIDC has no native IdP-initiated sign-in, so for OIDC apps OneIdP uses application shortcuts that send the user to the app’s login URL.

Decide which flow your users will meet day to day. It sets the URL you publish and the paths your test plan has to cover. The round trip itself is covered under implementing SSO in a web application, below.

Should your web app use SAML or OIDC?

Choose based on app support and customer requirements

In practice the application decides. SAML 2.0 is the common option in SaaS admin consoles, and OpenID Connect is what newer web and mobile apps tend to offer. If an app supports one, use that one. If it supports both, our OIDC vs SAML comparison covers the trade-offs.

“Requirements” means two lists. The vendor’s: a NameID format, particular claims, signed requests. Yours: MFA, device checks, session limits. OneIdP configures both protocols through one wizard. The Application Basics tab pre-selects SAML for a SAML app, and the Any OIDC/OAuth 2.0 configuration offers Client Secret or PKCE (Proof Key for Code Exchange). The scope, permissions, conditional access and user-facing message tabs are shared by both wizards, so the protocol changes the SSO Settings tab and little else.

Keep OAuth authorization separate from user authentication

OAuth 2.0 is an authorization framework (RFC 6749), and as the OAuth community’s own guidance puts it, “OAuth 2.0 is not an authentication protocol”. Possession of an access token proves nothing about the person holding it. OpenID Connect adds the signed ID Token that does identify the user. The rule for your implementation: sign users in with SAML or OIDC, and use OAuth scopes and access tokens only for API access. Our OAuth explainer has the background.

How do you configure the identity provider and application?

For SAML, exchange metadata, Entity ID, ACS URL, and certificates

SAML configuration is a two-way exchange. The protocol calls the shared configuration metadata: entity identifiers, service endpoints and the key material used to verify signatures (SAML V2.0 Technical Overview, sections 2.2 and 4.1).

From the identity provider to the app go the IdP’s entity ID (the issuer), its sign-in URL, its logout URL and its signing certificate. On OneIdP’s SSO Settings tab these are OneIdP Entity ID, OneIdP SSO URL, OneIdP SLO URL (single logout), OneIdP Change Password URL and a downloadable OneIdP Verification certificate.

From the app back to the IdP go the app’s entity ID and its assertion consumer service URL. OneIdP asks for Service Provider Entity ID and Service Provider ACS URL, and either can be left blank to be decoded from the incoming request. Two more settings sit alongside: SAML Subject Name Id Format, e-mail or username, and Session Duration, 5 to 90 days. The full field list is in the any SAML application guide. Note where the signing certificate lives and when it expires. The app checks every assertion against its copy, so a rotated certificate that is not re-uploaded stops sign-in.

For OIDC, configure the client, redirect URI, and required claims

With OIDC the application registers as a client of the identity provider and receives a client ID. Alongside it goes a client secret, or a PKCE challenge for apps that cannot keep a secret, such as mobile and single-page apps. PKCE protects the code exchange from interception (RFC 7636). The redirect URI is where the IdP returns the authorization code. It has to match a pre-registered value exactly, by simple string comparison (OpenID Connect Core, section 3.1.2.1). Check it character by character, scheme and trailing slash included.

In OneIdP’s Any OIDC/OAuth 2.0 configuration, the SSO Settings tab takes the authentication type, Client Secret or PKCE, and the Redirect URIs the app publishes. It also takes a back-channel Sign-Out URL if the app supports one. The grant types are Authorization Code by default, plus Refresh Token if the app needs it. Token expiry runs from 5 to 120 minutes, with a grace period of 0 to 5 minutes. A Custom Claims section takes a Scope, a Claim and a Claim value, and each claim can be made conditional on a user group.

Assign test users and agree on attribute mappings

Agree with the app owner which attribute identifies the user and which carry name, email, groups or role. For SAML that starts with the NameID format. For OIDC it starts with the sub claim and any custom claims the app reads. If the app creates users on first sign-in, it may need extra attributes, so agree on those too.

Then limit who can reach the configuration while you test. On OneIdP’s SSO Scope Management tab, choose Allow only assigned users to access the application and assign the test group. For testers who have not enrolled a device yet, the Conditional Access tab has an exception: Allow users to access the application till they enroll their first device. Set Maximum sessions allowed per user between 1 and 3 alongside it.

How do you implement SSO in a web application?

This is the app side of the handshake. A SaaS vendor has built it and you verify it. For an internal app your developers own it, and the sections below are what correct looks like.

Start sign-in and handle the return to your app

For SAML, the app checks for a session, saves the URL the user asked for, and redirects the browser to the IdP’s SSO URL with an authentication request. The IdP authenticates the user, or reuses its existing session, and returns a signed response by HTTP POST to the app’s ACS URL. The app validates it, creates a session and sends the user to the saved URL (SAML Technical Overview, section 5.1.2).

For OIDC, the app sends the browser to the IdP’s authorization endpoint with its client ID, the requested scopes, a state value and the redirect URI. The IdP returns an authorization code to that URI, and the app exchanges the code for an ID Token at the token endpoint (OpenID Connect Core, section 3.1). In OneIdP terms, Enter Login URL on Application Basics is where users start, and the ACS URL or Redirect URI you entered is where OneIdP sends them back.

Validate the returned assertion or token before creating an app session

For a SAML response, the app confirms five things before it reads the subject’s NameID (SAML Technical Overview, section 5.1.2):

• The signature verifies against the IdP certificate.
• The current time falls inside the assertion’s NotBefore and NotOnOrAfter window.
• The audience restriction names the app’s own entity ID.
• InResponseTo matches the request the app sent.
• Recipient is the app’s own ACS URL.

For an ID Token, OpenID Connect Core section 3.1.3.7 lists the equivalent checks:

• iss exactly matches the provider.
• aud contains the app’s client ID.
• The signature verifies with the algorithm named in the token header.
• The current time is before exp.
• nonce equals the one the app sent.

For a vendor’s app, ask which of these they perform if your review needs evidence. For your own app, the two lists are the developer’s acceptance test.

Check what happens on first login and subsequent visits

Two moments need a decision before the pilot. The first is the first login of a user the app has never seen. The app can create an account from the assertion, match an existing one, or reject the user. Salesforce, for example, can create users just in time from custom attributes such as ProfileId, but existing users still need a Federation ID set by hand (Salesforce configuration).

The second is the return visit. Once the IdP holds a session, it finds the existing security context and skips the credential challenge (SAML Technical Overview, section 5.1.2, step 3). How long that lasts is your setting: in OneIdP, the Session Duration or token expiry you set on the SSO Settings tab. On managed devices you can also enable Skip Password on Scalefusion managed devices, because the device state is part of the decision.

How should you handle users, organizations, and access removal?

Match existing users and decide when to create new accounts

Matching needs a stable key. In OIDC, the sub claim is defined as “locally unique and never reassigned” within the issuer (OpenID Connect Core, section 5.1). Email addresses change, so our recommendation is to key on sub, or an equivalent immutable identifier in SAML, and treat email as a display attribute where the app allows it. Where the app keys on email, pick one NameID format and keep it consistent across apps.

Creation happens in one of two ways. Just-in-time provisioning creates the account at first sign-in. Pre-provisioning creates and updates accounts ahead of time over SCIM, an HTTP protocol for creating, updating and deleting users and groups across domains (RFC 7644). OneIdP supports SCIM inbound and outbound provisioning alongside just-in-time attributes, so you can choose per app. Reconcile the local accounts from your inventory before enforcing SSO, or the first sign-in creates a duplicate next to the old account.

Route B2B users to the correct organization and identity provider

Your users may need partner applications, and partners’ users may need yours. Federation handles this by letting one identity provider trust another. OneIdP federates to the providers listed earlier and to any other SAML 2.0 identity provider.

The Okta configuration shows the shape. The two sides exchange sign-in URLs, identifiers and a certificate, and users are assigned to the Scalefusion application inside Okta. A user who enters their email at the app is redirected to OneIdP and then to Okta. In OneIdP the external identity provider is set per verified domain in the Directory as the default authentication source, which is how a user lands with the right provider.

If an application serves multiple organizations using different identity providers (IdPs), an identity broker can help manage the federation relationships between those IdPs and the application. The appropriate IdP can be identified using information such as the user’s email domain or an organization-specific URL. How this routing is implemented depends on the application’s identity architecture, as discussed in federated identity vs. SSO.

Define role mapping and what happens when access is removed

Roles travel as SAML attributes or OIDC claims. In OneIdP the Custom Claims section described above carries them, and a claim can apply only to a chosen user group. A finance group can carry an approver role, for example, that the app maps to its own permission set. Agree on the mapping with the app owner and record it with the attribute list.

Removal is where assumptions break. Un-assigning a user at the IdP stops new sign-ins. It does not end a session the app already holds. OneIdP’s SSO Scope Management tab has enforcement rules that invalidate the OneIdP session Immediately on User Un-Assignment and Immediately on Deleting this configuration. The any-SAML guide states these rules can be applied only on Google Workspace users, and the Salesforce guide adds that users are not logged out of the service provider itself. For every other app, pair IdP removal with SCIM deprovisioning or deactivation in the app, and test what an open session does after removal.

How do you secure sessions and logout?

Set session expiration, reauthentication, and cookie protections

After SSO there are at least two sessions, and often three: the identity provider’s, each application’s, and the portal’s. Each has its own lifetime, set in a different place.

On the OneIdP side, the lifetimes are the Session Duration and token expiry set on the SSO Settings tab. A User Portal timeout of 1 to 60 minutes applies to the portal only. Conditional Access decides whether the device state at sign-in is acceptable. Extended Access Policies (XAP) go further on Android, iOS and iPadOS, macOS and Windows. They evaluate signals such as OS updates and patches, jailbreak or root status, geofence location, IP address range, installed applications and, on Windows, domain join status. A device that fails the policy can be blocked from SSO-integrated services, or its user logged out.

On the application side, the OWASP Session Management Cheat Sheet sets the bar. Session cookies carry the Secure, HttpOnly and SameSite attributes. An idle timeout applies, which OWASP puts at 2 to 5 minutes for high-value applications and 15 to 30 minutes for low-risk ones. An absolute timeout sits behind it, typically 4 to 8 hours. The session ID is renewed after authentication, and sensitive actions such as a password change ask the user to re-authenticate. Ask SaaS vendors which of these are configurable per tenant.

Define whether logout ends the app session, IdP session, or both

Three outcomes are possible when a user logs out. Ending the app session alone leaves the IdP session alive, so the next visit signs them straight back in. Ending the IdP session alone leaves open app tabs working until their own timeouts. Ending both is what people expect on a shared device, and it takes coordination. OpenID Connect RP-Initiated Logout is explicit that logging out at one party does not automatically log the user out elsewhere.

In OIDC, an app requests IdP logout by redirecting to the provider’s end_session_endpoint with an id_token_hint. In the other direction, Back-Channel Logout lets the provider POST a logout token to each app’s registered URI, and the app clears the matching session. OneIdP’s OIDC configuration accepts that back-channel Sign-Out URL when the app supports it. SAML has Single Logout, which the Technical Overview describes in section 5.3 as near real-time logout of a user from all participants in a session. OneIdP provides its OneIdP SLO URL for it. Decide the behavior for shared devices, kiosks and personal laptops separately, and test each.

How do you test and troubleshoot SSO before rollout?

Test successful login and rejected, expired, or misdirected responses

An SSO implementation test plan is a short list of sign-ins that should work and a longer list that should fail in a specific way. Successes first: a service-provider-initiated sign-in from the app’s login URL, and an IdP-initiated sign-in from the portal if you use it. Then a return visit inside the session window, and a logout that behaves as you decided.

Then the deliberate failures, each with the outcome you expect:

• An unassigned user is refused and sees your configured message.
• An unmanaged device, against a policy of Only if the device is managed by Scalefusion, sees your non-compliant-device instructions rather than a blank error.
• An unsupported browser is caught by the browser policy.
• An expired token is rejected. Setting OIDC token expiry to its 5-minute minimum makes this quick to test.
• A misdirected response, meaning an ACS URL or redirect URI that differs from the registered value by a single character, fails. OIDC requires an exact string match at the provider (OpenID Connect Core, section 3.1.2.1). For SAML, the app’s own Recipient check catches a wrong ACS URL. Enter the Service Provider ACS URL explicitly rather than leaving it to be decoded, and test the mismatch from the app side.

Run the matrix on two device states and two browsers, and keep the results as your baseline.

Check assignments, claims, endpoints, certificates, and session behavior when login fails

When a sign-in fails, work through five things in order.

Assignment. Is the user inside the SSO scope and assigned to the configuration? In OneIdP, is the domain verified, is the user migrated to OneIdP, and is the app set to allow only assigned users?

Claims and attributes. Does the NameID format match what the app keys on, e-mail or username? Are the expected custom claims present, and are any of them conditional on a group the user is not in?

Endpoints. Compare the Service Provider Entity ID and ACS URL, or the Redirect URIs, against what the app publishes, one character at a time. Check the Login URL too.

Certificates and clocks. Does the app hold the current OneIdP Verification certificate? A clock that is off on either side can push a valid assertion outside its NotBefore and NotOnOrAfter window, or make an ID Token look expired.

Session behavior. Is an old app session or portal session masking the result? Did conditional access deny the device, so the user saw the access-denied message rather than a protocol error?

OneIdP’s User Facing Messages tab lets you configure instructions for a non-compliant device, instructions for a non-compliant browser, and a message shown when access is denied. A message that says “enroll your device to continue” answers the question before it becomes a ticket. A generic error does not.

Should you build the integration or use an SSO provider?

Compare protocol maintenance, security ownership, and multi-organization needs

For the SaaS applications on your list, the vendor has built the service-provider side. The decision is about the identity provider: the directory you have, an access layer in front of it that adds device checks and policy, or both. Our comparison of SSO providers covers the options.

For internal applications the question is sharper, because someone has to implement the whole web-application section above. Three things decide it. Protocol maintenance: libraries need updating, certificates and secrets need rotating, and someone owns that calendar. Security ownership: the validation checks carry the security of the whole integration, and whoever writes them owns the review and the fix. Multi-organization needs: per-organization IdP configuration and routing is a product feature in its own right, and a common reason to choose a provider.

OneIdP sits on the identity-provider side of that line. It gives you a Directory or federation to the IdP you already run, and one wizard for any SAML or any OIDC application. Conditional access based on whether the device is managed comes with it. It does not write the service-provider code for an internal app. A library or your developers do that, and the validation lists above are their acceptance test.

Pilot with a limited group before expanding access

The SSO implementation best practices that matter most are the plain ones: one application, one group, both flows. Keep Allow only assigned users to access the application switched on and assign the pilot group. Turn on the User Facing Messages before the first tester signs in, not after the first ticket. Run the test matrix on managed and unmanaged devices, and let the group work normally long enough to hit a return visit, a logout and a password change.

Expand one variable at a time: more users on the same app, then the next app, then the stricter device policy. When something breaks, you know which change did it. Once the last app is on, retire the local accounts from your inventory that no longer have a reason to exist.

Where to go from here. If you are implementing SSO on managed devices, Scalefusion OneIdP configures SAML and OIDC apps in one flow and ties each app’s access to whether the device is managed. It also federates to the identity provider you already run, so an IT admin can require a managed device for app access without a second project. Start with What is OneIdP, then the setup guides for Okta, Microsoft Entra ID, Google Workspace and Salesforce.

FAQs

1. Can SSO work with an app that does not support SAML or OIDC?

No, not as federated single sign-on. SAML or OIDC single sign-on needs the application to act as a service provider or relying party, the two protocols’ terms for the app that trusts the identity provider. It has to redirect to the identity provider, receive a signed assertion or token, and validate it. An app without that support cannot take part in the exchange. Other access approaches exist for such apps, but they are not equivalent to the app supporting SAML or OIDC.

2. Does implementing SSO also enforce MFA?

No. Implementing SSO does not by itself enforce MFA: an SSO connection tells the app to trust the identity provider’s sign-in and says nothing about how strong that sign-in was. MFA is configured and enforced through the identity provider’s own policies. In OneIdP, MFA is enabled at the Directory level, and the Conditional Access tab and SSO General Settings decide when it applies. That includes Enforce MFA on managed devices and an OTP from an authenticator app, a registered phone number, another managed device or email. See SSO vs MFA for how the two fit together.

3. What happens if the identity provider is unavailable?

If the identity provider is unavailable, new sign-ins fail, because the application has nowhere to send the authentication request. Existing sessions are different. The app created its own session after validating the assertion, and that session lasts until the app’s own timeout. So an outage locks out people who are not signed in and leaves signed-in users working until their sessions expire. Define an outage and recovery policy before rollout: who is told, whether emergency (break-glass) local accounts exist for critical apps, and how sessions are handled when the IdP returns.

4. Can SSO replace application permissions?

No. SSO handles authentication, which establishes who the user is. Authorization, what they may do, stays with the application. Even in the SAML flow, the final step after sign-in is the service provider’s own access check. SSO can carry group or role attributes that the app maps onto its permission sets, so users who join, change roles or leave are handled in one place. The permissions themselves are still defined and enforced in the app.