Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) are two relatively common authentication protocols and identity standards, with their own advantages, disadvantages and differences. This article compares the two protocols, SAML and OIDC, exploring their respective enterprise use cases and how each contributes to identity and access management (IAM). Both protocols support single sign-on (SSO), but technical and conceptual differences between the two need to be clarified before deployment: SAML focuses on securely granting access to cross-domain websites, while OIDC provides additional context.
1. Differences between SAML and OIDC
Before comparing the SAML 2.0 and OIDC protocols, it is necessary to compare the SAML and OAuth protocols first. OAuth is the basis of OIDC, and OIDC expands on this basis through the identity layer to realize decentralized identity verification services. The OpenID open source community started the OpenID development project in 2005. According to the foundation, more than 1 billion user accounts from more than 50,000 websites are now enabled with OpenID, managing the infrastructure supporting OIDC authentication, OIDC community and compliance operations.
In contrast, SAML 2.0 is an open standard that has provided authentication and authorization capabilities for commercial and private Identity Providers (IdPs) and Service Providers (SPs) since 2003. SAML originally used an Extensible Markup Language (XML)-based framework to implement single sign-on, allowing IdPs and SPs to be independent of each other and enabling centralized user management. The next section describes how SAML works, exploring each component in the protocol.
2. Implementation principle of SAML
As mentioned above, SAML is an open standard for authentication and authorization that provides single sign-on access to web applications through identity federation. SAML relays user credentials from the IdP to authenticate access and the SP, where the Service Provider (SP) needs to authenticate before granting the user access. Each user or group has its own attributes that summarize profile information and declare specific access rights.
SAML uses XML metadata documents, that is, SAML tokens, to make assertions and authenticate user identities and access rights.
SAML plug-ins are usually used in applications or resources to implement single sign-on to ensure compliance with security requirements. Credentials and assertions in the protocol clarify the identity of access access. In addition, SAML can be used to control the access of identities in the application. The core components of SAML include IdP, SP, client and attributes, which can exchange user information to control admission.
1) Identity Provider (IdP)
IdP is a service that maintains and manages digital identities. It verifies user credentials throughout applications, networks, and Web services. Its main role is to protect the integrity of user credentials and provide user identity federation where single sign-on is required.
2) client
A client is a user who authenticates to a service using credentials managed by the IdP. For example, an enterprise can authorize employees to use corporate email addresses and passwords to complete single sign-on to access required services through the SAML protocol.
3) attributes
SAML is also responsible for transferring messages called assertions from the IdP to the SP. These assertions set all relevant security requirements for accessing events by authenticating, authorizing, and determining the client's privilege level. During this process, attributes such as "department", "mail" and "role" are used to implement access management and admission control. Sometimes the SAML protocol is extended with custom attributes to support custom software.
4) Service Provider (SP)
The SP is the resource to which the user authenticates using SAML for single sign-on, usually a private website or application. The SP accepts or rejects the assertion sent by the IdP against the client profile before granting the user access. The SP sends an authentication request to the IdP, and the client sends an assertion to the IdP in response. This process is sometimes reversed, and the IdP can start the login process in either order.
3. The realization principle of OIDC
OIDC has been extended on the OAuth protocol, and its main components include the basic framework of the OAuth protocol plus a unique user workflow. OIDC enables client services, that is, applications, to authenticate users with an OpenID authentication server and exchange profile information through RESTful APIs that dispatch JSON Web Tokens (JWTs) for information sharing during the authentication process. This approach is highly scalable, cross-platform flexible, and relatively simple to implement, attracting many developers.
4. User Authentication
用户是资源所有者，通过授权服务器的身份验证后获取客户端应用的访问权限，授权服务器会授予用户访问令牌，允许应用从用户信息(UserInfo)端点接收同意信息，用户信息端点受到 OpenID 服务器的保护，服务器中的 JSON 对象包含了有关每个用户的断言。随后服务器将身份验证信息编码在应用接收的 ID 令牌中，信息缓存后就能实现可扩展性以及个性化的终端用户体验。
5. 基于 OAuth 2.0 协议
OIDC 建立在 OAuth 2.0 框架的基础上，OAuth 2.0 标准可授予第三方应用和服务访问用户 ID 资源的权限。用户凭证并不是通过网络发送，也不会存储在第三方服务器上，因此提高了资源安全性，也方便了管理员操作。
6. SAML 和 OIDC 的相似性与差异性
相似性
-
SAML 和 OIDC 都是实现单点登录的身份协议。
-
SAML 和 OIDC 都是安全成熟、有据可查的技术。
-
用户都通过 IdP 进行一次身份验证后就可以访问“信任”IdP 的其他应用。部分零信任服务都会在信任链的每个节点进行身份验证，并使用另一种验证方法定期验证访问。
-
登录工作流对于终端用户似乎都一样，但后台的技术实现却有着千差万别。
差异性
-
很多开发人员认为 OIDC 的实现更简单，不需要 XML 处理。
-
OIDC 缺乏权限等用户授权数据，重点关注身份断言。SAML 是身份数据的交换，功能更加丰富
-
OIDC 支持去中心化的身份验证。
-
SAML 使用断言，OIDC 和 OAuth 使用 ID 令牌。
-
OIDC 专为 API 工作负载而设计，可用于保护 API。
7. 用例
开发人员和企业应选择最适合自身特定用例的解决方案，部分情况也可以采用组合方案。OIDC要用于需要请求访问令牌的反向通道网站和移动应用。
SAML 几乎都用于前向通道网站访问，这类访问中用户会触发应用的身份验证，并且假定客户端应用(Web 服务)在与用户设备以外的其他设备上运行。以下是针对两种协议用例的一些通用提示：
-
移动应用通常使用 OIDC 类型的轻量化服务，开发人员使用的工具很大一部分都是预构建工具，也可以从插件库中获得。
-
内置 SAML 的应用使用很简单，只涉及 SAML。
-
使用 SAML 从门户访问企业应用。
-
使用 OAuth 2.0 或 OIDC 服务保护 API 或公开 API。
-
企业有时更喜欢用 SAML，因为可以自定义，而且优先交换安全数据。有监管要求的行业几乎都会用 SAML 保护用户敏感信息。
OIDC 和 SAML 协议之间不会相互排斥，企业可以考虑将 SAML 用于单点登录，保护资源访问，对于具有高可扩展性要求的移动化用例则可以使用 OIDC。总的来说，两者各有其优点，都支持单点登录服务。