Skip to main content
Identity Authority
Category: Cloud Identity

Identity as a Service

Also known as: IDaaS, cloud-based IAM, identity-as-a-service platform
Simply put

Identity as a Service (IDaaS) is a cloud-based, subscription model in which a third-party provider delivers identity and access management (IAM) capabilities over the internet, rather than an organization running that software on its own servers. Organizations subscribe to the service and use it to manage who their users are and what those users are allowed to access.

Formal definition

Identity as a Service (IDaaS) is a cloud-based service model, typically offered on a subscription basis, in which a third-party provider delivers identity and access management (IAM) functions over the internet. Depending on the vendor and plan, these functions commonly span identification, authentication, and authorization services along with related capabilities; the specific set of features, supported standards (for example SAML 2.0, OAuth 2.0, OIDC, or SCIM), and governance functions varies by provider and configuration and should be confirmed against the offering rather than assumed. Because the platform is provider-operated, availability and operational guarantees are generally governed by a service level agreement (SLA), and the division of responsibility between provider and customer follows a shared-responsibility arrangement whose exact boundaries depend on the deployment.

Why it matters

Identity has become a primary control plane for security, and IDaaS lets organizations consume identity and access management capabilities without building and maintaining that infrastructure themselves. This shifts operational burden, patching, scaling, and keeping pace with evolving standards such as SAML 2.0, OAuth 2.0, OIDC, and SCIM, to a specialized provider, which can be attractive for teams that lack the staffing or expertise to run on-premises IAM software reliably. The trade-off is that identity, one of the most sensitive functions in an environment, is now delivered over the internet by a third party, making provider security posture, standards support, and contractual commitments matters of direct concern.

Because the platform is provider-operated, availability directly affects the customer's ability to authenticate and authorize users. As Microsoft's guidance notes, using an IDaaS with a service level agreement can increase confidence that the identity system remains operational when needed. Conversely, a provider outage or misconfiguration can broadly impede access, so architects should evaluate SLA terms, redundancy, and fallback options rather than assuming continuous availability.

The division of labor also introduces a shared-responsibility model whose boundaries vary by vendor and configuration. Subscribing to IDaaS does not transfer all accountability to the provider; customers typically remain responsible for aspects such as configuring policies, managing their own users and entitlements, and integrating applications. Understanding exactly where the provider's responsibility ends and the customer's begins is essential to avoid gaps in both security and governance.

Who it's relevant to

Security architects
Architects evaluating whether to adopt IDaaS must weigh the operational relief of a provider-run platform against the need to place a sensitive control plane in a third party's hands. They should confirm which standards (for example SAML 2.0, OAuth 2.0, OIDC, SCIM) the offering supports, examine SLA terms for availability, and map the shared-responsibility boundaries so that no security control falls into a gap between provider and customer.
IAM engineers
Engineers integrate applications and directories with the IDaaS using its supported protocols and connectors, configure authentication and authorization flows, and manage tenant settings. Because feature sets and supported profiles vary by vendor and plan, they should validate capabilities against the provider's documentation rather than assuming parity with on-premises tooling.
Compliance officers
Compliance leads need clarity on the shared-responsibility model to determine which obligations remain with the organization when identity services are outsourced. They should review the provider's SLA, security commitments, and any governance functions included, and confirm that customer-retained responsibilities, such as policy configuration and access management, are documented and met.
System administrators
Administrators handle day-to-day operations such as managing users, configuring policies, and monitoring service health. Because availability is governed by the provider's SLA and the platform is operated externally, they should understand escalation paths and any customer-side fallback options for periods when the service is degraded or unavailable.

Inside IDaaS

Authentication services
Cloud-delivered verification of who a principal is, typically supporting single sign-on, multi-factor authentication, and increasingly passwordless or passkey-based flows. This is distinct from authorization, which the platform may also facilitate but handles as a separate step.
Federation and SSO protocol support
Support for federation standards such as SAML 2.0 for XML-based web SSO and OpenID Connect (the authentication layer built on OAuth 2.0) for token-based sign-in. Delegated authorization is typically handled via OAuth 2.0, which is not itself an authentication protocol.
Directory and identity store
A hosted directory or identity repository that holds user and principal records. Depending on the offering, this may expose or integrate with LDAP directories and typically synchronizes with on-premises or third-party sources.
Provisioning and lifecycle (IGA capabilities)
User lifecycle management such as provisioning and deprovisioning, often via SCIM, plus governance functions like access reviews, certification, and segregation-of-duties controls in more complete offerings. These IGA concerns are distinct from runtime access enforcement.
Access management and enforcement
Runtime authorization and policy enforcement, potentially including PDP/PEP/PIP components and token validation. The specific access control model exposed (for example RBAC, ABAC, or PBAC) varies by vendor and deployment.
Token issuance and management
Issuance and handling of tokens such as ID tokens (OIDC authentication assertions), access tokens (for authorized resource access), and refresh tokens. Tokens may be opaque or self-contained (for example JWTs); a signed token proves integrity and origin but is not the same as an encrypted token.
Multi-tenant, subscription-based delivery
Delivered as a hosted, typically multi-tenant service on a subscription model, shifting infrastructure operation to the provider while the customer retains configuration and governance responsibilities depending on the shared-responsibility arrangement.

Common questions

Answers to the questions practitioners most commonly ask about IDaaS.

Does adopting IDaaS mean identity authentication and authorization are fully handled by the provider so we no longer manage access ourselves?
No. IDaaS typically provides the runtime services for authentication (verifying who a principal is) and often federation for SSO, but authorization decisions, determining what a principal may do, usually still depend on the policies, roles, attributes, or entitlements you configure. In most deployments the customer remains responsible for defining access policy, mapping identities to entitlements in downstream applications, and governing that access over time. The provider operates the infrastructure; it does not absolve you of access management accountability. The exact division of responsibility varies by vendor and service tier and should be confirmed against the provider's shared-responsibility model.
Is IDaaS the same thing as identity governance and administration (IGA), so it covers access reviews and certifications automatically?
Not necessarily. IDaaS is a delivery model for identity services and, depending on the offering, may emphasize runtime concerns such as authentication, SSO, and provisioning connectors. IGA concerns, such as access reviews, certification campaigns, and segregation-of-duties enforcement, are distinct capabilities. Some IDaaS platforms include IGA features, others focus on access and federation and leave governance to a separate product. Do not assume lifecycle governance is present simply because a service is delivered as IDaaS; verify which specific capabilities are in scope for the offering you are evaluating.
How does IDaaS typically integrate with our existing applications and directories?
Integration usually relies on standards-based connectors rather than proprietary mechanisms. For web SSO, providers commonly support SAML 2.0 and OpenID Connect (the authentication layer built on OAuth 2.0). For provisioning and deprovisioning of accounts, SCIM is frequently used where supported. Existing directories such as LDAP or on-premises directory services are often connected through a synchronization or agent-based bridge. The available protocols, profiles, and connector coverage vary by vendor and by the target application, so confirm that each application you need to onboard supports a protocol the IDaaS offering implements.
What should we consider about token handling and session behavior when deploying IDaaS?
Confirm which token types the service issues and how they are used: ID tokens convey authentication results, access tokens authorize API or resource access, and refresh tokens obtain new tokens. Many IDaaS offerings issue JWTs, which are typically signed for integrity but are not necessarily encrypted, signing is not the same as confidentiality, so avoid placing sensitive data in unencrypted token claims. Understand token lifetimes, refresh behavior, and how relying applications validate tokens, since validation responsibilities may sit with your applications depending on configuration. Session and single-logout behavior also varies by protocol profile and vendor.
How do we approach authentication factors and step-up authentication with an IDaaS provider?
Determine which factor types the service supports across possession, knowledge, and inherence, and distinguish the options: MFA (two or more factors), 2FA (specifically two), passwordless flows, and step-up authentication (requiring additional assurance for higher-risk actions). Many providers support FIDO2/WebAuthn-based authenticators and passkeys, though these are related but distinct concepts and their exact support differs by vendor. Verify which methods can be enforced, whether policies can be scoped per application or risk level, and how step-up is triggered, since these behaviors depend on the provider's policy engine and configuration.
What operational and continuity concerns arise from consuming identity as an externally hosted service?
Because authentication and often federation become dependent on an external service, availability of that service typically affects access to connected applications. Evaluate the provider's resilience posture, how outages are handled, and whether any fallback or cached authentication is available for your scenarios. Also assess where identity data resides, how it is protected, and how deprovisioning propagates to downstream systems. The specifics of uptime commitments, data handling, and failure modes vary by vendor and contract, so review the provider's documented service terms rather than assuming a particular behavior.

Common misconceptions

IDaaS handles authentication, so it also handles authorization by default.
Authentication (verifying who a principal is) and authorization (determining what a principal may do) are separate steps. An IDaaS platform may provide both, but the scope, access control model, and enforcement capabilities vary by vendor and configuration and should not be assumed.
Because IDaaS supports OAuth 2.0, it authenticates users with OAuth.
OAuth 2.0 is a delegated authorization framework, not an authentication protocol. User authentication in an IDaaS context is typically provided by OpenID Connect (built on OAuth 2.0) or by SAML 2.0 for web SSO.
Adopting IDaaS means the provider fully owns identity security and governance.
IDaaS shifts infrastructure operation to the provider, but customers typically retain responsibility for configuration, access governance (such as reviews, certification, and segregation of duties), and policy decisions under a shared-responsibility model.

Best practices

Separate authentication and authorization concerns explicitly in your configuration, using OpenID Connect or SAML 2.0 for sign-in and OAuth 2.0 only for delegated authorization, rather than treating any one protocol as covering both.
Confirm which access control model the platform enforces (for example RBAC, ABAC, or PBAC) and align it to your requirements rather than assuming a single model applies universally.
Automate lifecycle management with SCIM-based provisioning and deprovisioning, and keep these IGA functions distinct from runtime enforcement so that access reviews and certifications are auditable.
Enable strong authentication such as MFA, step-up, or passwordless/passkey options where supported, choosing factors across possession, knowledge, and inherence categories appropriate to risk.
Validate tokens correctly at enforcement points, verifying signatures and claims, and remember that a signed token is not encrypted; apply confidentiality controls separately where sensitive data is involved.
Clarify the shared-responsibility boundaries with the provider so that configuration, governance, and policy ownership are explicit, and document what is in and out of scope for the service.
Promotional banner for the Penetration Report Template Kit