What Is a Service Provider (SP)? Understanding the Other Half of Single Sign-On
A ground-up, beginner-friendly explanation of what a Service Provider actually is, how it relates to Identity Providers like Keycloak or Okta, and how the two sides work together to log you in without ever seeing your password.
Imagine checking into a hotel using your passport. The hotel’s front desk doesn’t issue passports, doesn’t verify your citizenship, and doesn’t run background checks — that’s the government’s job. The hotel simply trusts the passport, checks that it looks genuine, and hands you a room key based on what it says. In the world of software logins, the “government” that issues and verifies identity is called the Identity Provider, and the “hotel” that trusts that identity and grants access to its own resources is called the Service Provider. This guide is entirely about that second role — the Service Provider — and how it fits into the bigger picture of Single Sign-On.
1What Is a Service Provider?
Let’s start with a plain-English definition before touching any protocol details.
The Simple Definition
A Service Provider (SP) is any application or system that offers a useful service to a user — like an email inbox, a payroll dashboard, or a file-sharing tool — but chooses not to handle login and password-checking itself. Instead, it delegates that responsibility to a separate, trusted system called an Identity Provider (IdP), such as Keycloak, Okta, or Microsoft Entra ID. The Service Provider’s whole job is to provide the actual service; proving who the user is gets outsourced elsewhere.
Think of an amusement park with dozens of rides. Each ride operator (a Service Provider) doesn’t check your ID card from scratch — they just glance at the wristband the main gate (the Identity Provider) already gave you when you entered the park. The ride operator trusts the wristband completely and never asks to see your actual ID again.
Why the Term Matters
The term “Service Provider” comes from federated identity standards like SAML (Security Assertion Markup Language) and, in slightly different phrasing, OpenID Connect (OIDC), where the equivalent role is often called a Relying Party (RP). Both terms describe the exact same concept: the application that relies on someone else’s proof of identity instead of managing its own login system.
Service Provider (SP)
The application offering the actual service, which trusts an outside system to verify who the user is.
Identity Provider (IdP)
The dedicated system, like Keycloak, responsible for checking credentials and issuing proof of identity.
Relying Party (RP)
The OIDC-world name for essentially the same role as a Service Provider — an application relying on an IdP’s verification.
Assertion / Token
The signed proof of identity the IdP hands to the Service Provider — a SAML Assertion or an OIDC token.
Every Single Sign-On setup needs at least two sides to make sense: one Identity Provider doing the verifying, and one or more Service Providers doing the trusting. Neither role is useful alone — an Identity Provider with no Service Providers has nothing to log people into, and a Service Provider with no Identity Provider has no way to know who’s using it.
2Why Applications Choose to Become Service Providers
Building your own login system is an option — but most applications deliberately choose not to. Here’s why.
Every application technically could store its own list of usernames and passwords and handle its own login page. Many older or smaller applications still do. But as organizations grow and start using dozens of different tools, this approach creates real pain — both for users, who must remember many passwords, and for IT teams, who must secure many separate password databases instead of just one.
Problems With Every App Managing Its Own Login
- Users must remember (or reuse, dangerously) a different password per tool
- Every application becomes its own potential point of a password leak
- Offboarding an employee means manually disabling accounts in every single tool
- Security features like MFA must be rebuilt, and re-secured, again and again
What Becoming a Service Provider Fixes
- One login, shared across every connected Service Provider (Single Sign-On)
- Passwords live in exactly one place — the Identity Provider — reducing exposure
- Disabling a user at the Identity Provider instantly removes access everywhere
- Security upgrades like MFA are inherited automatically from the Identity Provider
It’s like a large office building where every tenant company used to run its own separate front-desk security. Once the building installs one shared security desk and badge system, every tenant (Service Provider) simply trusts a badge issued by that one shared desk (Identity Provider) instead of re-checking IDs themselves.
This is precisely why so many SaaS products — from project management tools to expense trackers to video conferencing apps — proudly advertise “SSO support.” What they’re really announcing is that they are able to act as a Service Provider, ready to trust whichever Identity Provider a business customer already uses.
3Core Building Blocks of a Service Provider Setup
A working Service Provider relationship is built from a handful of core pieces that always appear together.
Entity ID
A unique identifier that names the Service Provider, so the Identity Provider knows exactly which application it’s talking to.
Assertion Consumer Service (ACS) URL
The specific web address on the Service Provider where the Identity Provider sends the proof of identity after a successful login.
Metadata
A document describing the Service Provider’s identity, certificates, and endpoints, exchanged with the Identity Provider to establish trust.
Signing Certificate
A cryptographic certificate used to verify that assertions or tokens really came from the trusted Identity Provider, not an impostor.
The Trust Relationship
Before any login can happen, the Service Provider and the Identity Provider must formally agree to trust each other. This is typically done by exchanging metadata — an XML or JSON document listing each side’s important details: where to send login requests, where to receive responses, and which cryptographic certificate to use for verifying signatures. Once this metadata exchange is complete, the two systems are said to be federated.
Setting up trust between a Service Provider and an Identity Provider is like two banks agreeing to honor each other’s checks. Before that agreement exists, a check from Bank A means nothing at Bank B’s counter. Once they exchange the right paperwork and verification details, Bank B can confidently cash checks it knows came from Bank A.
A Service Provider does not store or manage passwords for federated users at all. It only ever receives a signed assertion or token confirming “this user is authenticated,” and separately learns what that user is allowed to do based on roles or attributes included in that same message.
4Architecture: Where the Service Provider Sits
Let’s zoom out and see how a Service Provider fits among the other moving parts of a federated login system.
flowchart LR
U[User's Browser] -->|1 Requests Access| SP[Service Provider]
SP -->|2 Redirects for Login| IDP[Identity Provider]
IDP -->|3 Verifies Credentials| DB[(User Directory)]
IDP -->|4 Sends Signed Assertion| U
U -->|5 Delivers Assertion| SP
SP -->|6 Grants Access| U
The Service Provider Layer
This is the actual product the user came to use — a document editor, a CRM, a support ticketing tool. It contains business logic, data, and features, but deliberately contains no password database and no login-checking code of its own. Its only identity-related job is to redirect unauthenticated users to the Identity Provider and correctly interpret the signed response that comes back.
The Identity Provider Layer
This is the dedicated authentication system — Keycloak being one common example — that owns the actual user directory, checks passwords, may enforce multi-factor authentication, and issues the signed proof of identity that Service Providers rely on.
The User’s Browser
The browser acts as the messenger, being redirected back and forth between the Service Provider and the Identity Provider, carrying the login request one way and the signed proof of identity back the other way.
5Assertions and Tokens: What the SP Actually Receives
The message that arrives at the Service Provider after login is the single most important artifact in this whole system — worth examining closely.
In the older, widely used SAML standard, this message is called an Assertion — an XML document, digitally signed by the Identity Provider, stating facts like “this user is john.doe@company.com, they logged in successfully at this time, and here are their group memberships.” In the newer OpenID Connect standard, the equivalent is a signed ID Token and Access Token, usually formatted as a compact JSON Web Token (JWT) rather than XML.
Assertion
An XML document signed by the Identity Provider, delivered to the Service Provider’s Assertion Consumer Service URL.
ID Token / Access Token
A signed JWT delivered to the Service Provider, describing the user’s identity and often their permissions too.
An assertion or token is like a sealed, wax-stamped letter of recommendation. The Service Provider doesn’t need to call up the writer to double-check it’s genuine — it just examines the seal (the digital signature). If the seal matches a signature it already trusts, the letter’s contents are accepted as true.
What the Service Provider Must Verify
Receiving a signed message isn’t enough on its own — a properly built Service Provider must actively verify several things before trusting it: that the digital signature is valid and matches the expected Identity Provider’s certificate, that the message hasn’t expired, that it was genuinely intended for this specific Service Provider (checking the audience field), and that it hasn’t already been used once before, which guards against replay attacks.
A Service Provider that accepts an assertion or token without properly verifying its signature, expiry, and intended audience is not actually secure — it’s simply trusting anything that looks correctly formatted, which is exactly what attackers exploit with forged or replayed messages.
6The Two Ways a Login Can Start: SP-Initiated vs IdP-Initiated
There are two distinct paths a federated login can take, and Service Providers need to correctly support at least the first one.
User visits the Service Provider directly
The user types in the application’s own address bar or clicks a bookmark, landing on the Service Provider before any login has happened.
Service Provider notices there’s no valid session
Finding no existing login, the Service Provider builds an authentication request and redirects the browser to the Identity Provider.
Identity Provider authenticates the user
The user logs in (or is silently recognized via an existing session) at the Identity Provider.
Identity Provider redirects back with a signed assertion
The browser carries the signed proof of identity back to the Service Provider’s Assertion Consumer Service URL.
Service Provider validates and grants access
After verifying the signature and contents, the Service Provider creates its own local session and shows the requested page.
This first path is called SP-Initiated login, because the flow begins at the Service Provider. The alternative, IdP-Initiated login, happens when the user starts at a dashboard or portal on the Identity Provider itself, clicks an icon for a specific application, and is pushed straight to that Service Provider with an assertion already in hand — skipping the initial redirect step.
sequenceDiagram
participant Browser
participant SP as Service Provider
participant IDP as Identity Provider
Browser->>SP: Visit protected page
SP->>Browser: Redirect to Identity Provider
Browser->>IDP: Log in (or reuse session)
IDP->>Browser: Redirect back with signed assertion
Browser->>SP: Deliver assertion to ACS URL
SP->>SP: Validate signature, expiry, audience
SP->>Browser: Access granted, session created
SP-Initiated login is generally considered the safer and more predictable of the two patterns, since the Service Provider controls exactly what it’s asking for from the start. IdP-Initiated login is still widely supported for convenience, particularly for portal-style “app launcher” experiences.
7From Assertion to Access: How Roles and Attributes Flow Through
Logging someone in is only half the job — the Service Provider also needs to know what that person is allowed to do once inside.
Alongside basic identity facts like email address and name, Identity Providers can include extra pieces of information called attributes or claims inside the assertion or token — things like department, job title, or group membership. The Service Provider reads these values and uses them to decide what the user sees: a user tagged as “finance-admin” might unlock a billing section, while a plain “employee” tag would not.
Attributes are like the fine print stamped onto that hotel wristband — not just “this guest is verified,” but “this guest also has pool access” or “this guest is a VIP with lounge privileges.” The hotel staff (the Service Provider) read that fine print to decide exactly what to allow, without ever needing to re-check the guest’s original ID.
Attribute Mapping
Because different Identity Providers and Service Providers may use different internal names for the same concept, administrators typically configure an attribute mapping — for example, translating the Identity Provider’s internal field department into whatever field name the Service Provider expects for its own role logic. Getting this mapping wrong is one of the most common causes of “I logged in fine, but I can’t see anything” support tickets.
Assuming that a successful login automatically means correct permissions. Authentication (proving identity) and authorization (deciding access) are related but separate steps — a perfectly valid, correctly signed assertion can still leave a user with zero usable permissions if the attribute mapping on the Service Provider side is misconfigured.
8Advantages, Disadvantages, and Trade-offs
Becoming a Service Provider — outsourcing login instead of building it — has clear upsides, along with a few trade-offs worth knowing.
Advantages
- No need to build, secure, or maintain a password database
- Instantly inherits whatever security features the Identity Provider offers, like MFA
- Easier enterprise sales, since large customers often require SSO support
- Centralized offboarding — access disappears the moment the IdP disables the user
- Reduced liability, since sensitive credentials never touch the Service Provider’s systems
Disadvantages / Trade-offs
- Complete dependency on the Identity Provider’s uptime for every login
- Requires correctly implementing signature verification, or security is only illusionary
- Different customers may use different Identity Providers, adding integration overhead
- Debugging federated login issues spans two systems instead of one, complicating support
In practice, the trade-off is almost always worth it for anything beyond a small internal tool: the security and convenience benefits of federated login outweigh the added architectural complexity, which is why “Sign in with SSO” has become a standard expectation for enterprise software.
9Security Responsibilities of a Service Provider
Trusting an Identity Provider doesn’t remove all security work from the Service Provider’s plate — it shifts the responsibilities elsewhere.
Signature Verification
Must cryptographically confirm every assertion or token truly came from the expected, trusted Identity Provider.
Expiry Checking
Must reject assertions or tokens that have passed their valid time window, preventing stale credentials from being reused.
Audience Restriction
Must confirm the message was genuinely intended for this Service Provider, not accidentally or maliciously reused from another one.
Session Management
Must create and expire its own local session appropriately after a successful login, independent of the Identity Provider’s session.
Secure Redirect Handling
Must only redirect users to pre-registered, trusted Identity Provider addresses, avoiding open-redirect vulnerabilities.
Certificate Rotation Handling
Must be able to accept updated signing certificates when the Identity Provider periodically rotates them for security hygiene.
10Monitoring, Logging, and Metrics
Federated login failures are notoriously tricky to debug without good visibility, since they span two independent systems.
| What to Monitor | Why It Matters |
|---|---|
| Assertion/token validation failures | Spikes often indicate certificate mismatches, clock drift, or a misconfigured trust relationship |
| Redirect-to-IdP success rate | Confirms the Service Provider is correctly reaching and receiving replies from the Identity Provider |
| Attribute mapping errors | Users logging in but receiving unexpected or missing permissions signals mapping misconfiguration |
| Session creation latency | Slow session setup after a valid login directly hurts user experience |
| Certificate expiry dates | An expired signing certificate on either side breaks every single login until renewed |
Well-run Service Providers log every stage of the federation handshake — the outbound authentication request, the inbound assertion or token, the validation result, and the final session decision — making it possible to pinpoint exactly where a failed login broke down when a user reports a problem.
Certificate expiry is one of the most common, entirely preventable causes of sudden, company-wide login outages. Setting an automated alert well before a trusted signing certificate expires avoids a painful, all-hands-on-deck incident later.
11Design Patterns and Anti-Patterns
Real-world federated deployments reveal patterns worth repeating and mistakes worth avoiding.
Pattern: Support Multiple Identity Providers Cleanly
A well-designed Service Provider used by many business customers keeps its trust configuration per-customer, so each one can point at their own preferred Identity Provider without affecting others.
Pattern: Fail Closed, Not Open
When signature verification or any other security check fails, a properly built Service Provider denies access by default, rather than assuming the message is probably fine and letting the user through.
Pattern: Store Only What’s Needed Locally
Rather than copying an entire user profile from every login, mature Service Providers store only the minimal identifying information needed, re-reading updated attributes from each new assertion or token.
Problem
A Service Provider skips proper signature verification during development “to make testing easier” and this shortcut accidentally ships to production.
Why It’s Harmful
Without signature verification, any attacker who can reach the Assertion Consumer Service URL can submit a forged assertion and log in as any user, completely bypassing the Identity Provider’s protections.
Correct Approach
Always verify signatures against the trusted certificate in every environment, and use a separate, clearly-labeled test Identity Provider instance for development instead of disabling security checks.
Problem
Hardcoding a single Identity Provider’s details directly into application code instead of using configurable, per-tenant metadata.
Why It’s Harmful
This makes onboarding a new business customer with a different Identity Provider require a code change and redeployment, instead of a simple configuration update.
Correct Approach
Store trust relationships as configuration or database records, allowing new Identity Provider integrations to be added without touching application code.
12Best Practices and Common Mistakes
Practical habits that separate a smoothly running Service Provider integration from a fragile, support-ticket-generating one.
Always Use HTTPS End to End
Every leg of the redirect chain — Service Provider to Identity Provider and back — should run over encrypted connections, with no exceptions.
Log Validation Failures With Enough Detail
Capture why a signature check or expiry check failed, since vague logs turn a five-minute fix into a day-long investigation.
Set Clear Session Expiry Independent of the IdP
Decide how long a local session should last after login, rather than assuming it should match the Identity Provider’s own session length.
Document the Exact Attributes You Require
Clearly publish which attributes (like email or group) your Service Provider expects, so new Identity Provider integrations are configured correctly the first time.
Treating “SSO is configured” as the finish line. Many real production incidents happen weeks or months later, when a certificate quietly expires or an Identity Provider changes its metadata — ongoing monitoring matters just as much as the initial setup.
13Real-World and Industry Examples
The Service Provider role appears constantly across everyday software, even when the term itself stays behind the scenes.
Business SaaS Tools
Project management, CRM, and communication tools commonly act as Service Providers, letting large customers connect their own Identity Provider, like Keycloak or Okta, instead of managing a separate password for every employee.
Cloud Provider Consoles
Major cloud platforms support federated login, acting as a Service Provider so enterprise customers can sign in using their existing corporate identity system rather than a cloud-specific account.
Internal Enterprise Applications
Custom-built internal tools — expense systems, internal wikis, developer portals — are frequently configured as Service Providers trusting the company’s central Identity Provider for employee login.
Education Platforms
Universities often run learning platforms and library systems as Service Providers trusting a shared campus Identity Provider, letting students log into many separate academic tools with one set of credentials.
Wherever you see “Sign in with your organization” or “Continue with SSO” on a login screen, the application behind that button is acting as a Service Provider.
14Frequently Asked Questions
They describe essentially the same role. “Service Provider” is the term used in SAML, while “Relying Party” is the equivalent term used in OpenID Connect — both mean the application trusting an outside Identity Provider.
Yes. Some applications, like Keycloak’s identity brokering feature, can trust an upstream Identity Provider for some users while also acting as an Identity Provider themselves for other connected applications.
In a correctly designed federated setup, no. The password is entered only on the Identity Provider’s login page, and the Service Provider only ever receives a signed assertion or token, never the raw credentials.
New logins to the Service Provider will fail, since it has no independent way to verify identity — this dependency is why Identity Providers are typically run with high-availability infrastructure.
Often yes, especially once they start selling to businesses — many enterprise customers require SSO support as a condition of purchase, making Service Provider capability a common product requirement.
Neither is universally “better” — OIDC tends to be simpler for modern web and mobile apps, while SAML remains common in enterprise environments, so many production Service Providers end up supporting both.
15Summary and Key Takeaways
A Service Provider is any application that chooses to trust an outside Identity Provider instead of managing its own login system — a role that underpins nearly every “Sign in with SSO” experience across modern software. By outsourcing the hard, security-sensitive work of verifying identity, Service Providers gain stronger security, simpler user management, and easier enterprise adoption, in exchange for a clear set of ongoing responsibilities: verifying signatures, checking expiry, mapping attributes correctly, and monitoring the health of the trust relationship over time. Understanding this role — and how it pairs with an Identity Provider like Keycloak — is essential context for anyone working with modern authentication systems.
Key Takeaways
- A Service Provider offers a service but delegates login — it trusts a separate Identity Provider to verify who the user is.
- Trust is established through metadata and certificates, exchanged once before any real logins can happen.
- The Service Provider receives a signed assertion or token, never the user’s actual password.
- SP-Initiated login is the standard, safer flow, though IdP-Initiated login is also widely supported for convenience.
- Attributes and claims carry permissions, meaning correct attribute mapping is just as important as the login itself succeeding.
- Security responsibility doesn’t disappear — the Service Provider must still verify signatures, expiry, and audience on every message it receives.
- “Service Provider” and “Relying Party” describe the same role, just named differently in the SAML and OIDC worlds.