2.4Identity federation and PKI

The mistake system designers fall into most easily when building identity federation is conflating "authorization" with "authentication." OAuth 2.0 is, at its core, an authorization protocol for "granting one service limited access to another service's resources," and using it alone for the purpose of "login (authentication)" is a design error. This section covers the correct division of roles among SSO-related protocols, and the decision axis for choosing a certificate revocation-checking method (CRL vs. OCSP) in PKI.

2.4.1SSO and SAML/OpenID Connect

• SSO (Single Sign-On) is a mechanism that lets a single authentication grant access to multiple services or systems. It improves user convenience, and, by removing the need to manage a separate password per service, also helps reduce the risk of password reuse.
• SAML is an XML-based standard for exchanging identity information (authentication results, attributes) to realize SSO. It is mainly used for enterprise web application federation (between an IdP, Identity Provider, and an SP, Service Provider).
• OpenID Connect (OIDC) extends OAuth 2.0 (described below) by adding authentication (verifying who someone is). It conveys the authentication result via a JSON-based ID token, and is widely used in mobile apps and consumer-facing services for features such as "Sign in with Google."

2.4.2OAuth 2.0 (authorization, not authentication)

• OAuth 2.0 is a standard exclusively for authorization: it issues a client application a limited access token to access resources held by another service (the resource server) on the user's behalf. It is not a mechanism for confirming "who someone is" (authentication).
• "Implementing a login feature using OAuth 2.0 alone" is a design error—successfully obtaining an access token merely means "access to a limited resource was granted," and does not, in a strict sense, guarantee that the user's identity was verified. To implement login (authentication), the correct design is to use OpenID Connect, which adds an authentication capability on top.

2.4.3PKI, digital certificates, CRL/OCSP, and GPKI

• PKI (public-key infrastructure) is the overall system that guarantees a public key truly belongs to its claimed owner (a server, organization, or individual). A Certificate Authority (CA) issues a digital certificate for a public key, binding the key to its owner. Certificates form a certificate chain from a root certificate down through server and client certificates.
• A Validation Authority (VA) examines the identity and legitimacy of certificate applicants (this function may also be implemented as part of the CA). After a certificate is issued, a mechanism is needed to continuously confirm whether that certificate has been revoked.
• CRL (Certificate Revocation List) is a list-based scheme in which the CA periodically publishes a list of revoked certificates. Because the entire list must be downloaded and checked, communication volume and processing load grow as the list becomes large, and the latest revocation status cannot be reflected during the time lag until the next publication.
• OCSP (Online Certificate Status Protocol) queries the revocation status of a specific single certificate in real time. It offers higher real-time accuracy than CRL and keeps communication volume down since only the one needed certificate is queried, but it requires a query to the OCSP responder each time, making it dependent on the responder's availability.
• GPKI (Government Public Key Infrastructure) is Japan's official authentication infrastructure for documents exchanged among government agencies. It serves as the trust anchor for digital signatures and certificates in the online delivery of administrative procedures.

Suppose an online payment provider's system designer is tackling three problems. Problem (1): a partner EC site's engineer wants to "implement a login feature using the user's payment account information," but mistakenly believes that "simply obtaining an access token via OAuth 2.0 is sufficient for login." Problem (2): deciding how to incorporate a certificate revocation-checking method into the TLS handshake of the payment API server. Problem (3): designing the trust anchor for digital signatures in a system that automatically sends invoices to government agencies. For problem (1), the designer explains that "OAuth 2.0 is strictly an authorization protocol; obtaining an access token merely means limited resource access was granted, and does not guarantee that the user's identity was confirmed (authentication)" and asks the partner to correct course by using OpenID Connect, which adds authentication, for the login feature—specifically, only by verifying OIDC's JSON-based ID token can "who was authenticated" be safely confirmed. For problem (2), since the payment API is a scenario demanding high real-time accuracy—checking a certificate's revocation status with near-real-time precision for each individual transaction—the designer adopts OCSP: with CRL, a certificate revoked during the time lag before the next list publication cannot be detected, which could be a fatal risk in a transaction involving money like a payment (this must be designed together with ensuring the OCSP responder's availability and redundancy). Finally, for problem (3), since the authenticity of documents exchanged among Japanese government agencies must be guaranteed, the designer builds in GPKI (Government PKI) as the trust anchor. In this way, the designer works through three decision axes against the business requirements one by one: "is authorization or authentication needed," "how much real-time accuracy is required for revocation checking," and "which authentication infrastructure should serve as the trust anchor."

2.4.4Section summary

• OAuth 2.0 is strictly for authorization (not authentication). Use OpenID Connect, which adds authentication, for login, and SAML for enterprise SSO
• PKI binds a public key to its owner via a digital certificate issued by a CA, and propagates trust through a certificate chain
• Choose between CRL (list-based, with a time lag) and OCSP (individual real-time query) for revocation checking, based on requirements