PHP实现SSO SAML2.0：跨站单点登录的证书分发疑问

Great question—certificate management is one of the trickier parts of SAML 2.0, but once you map out the roles involved, it clicks pretty quickly. Let’s break this down based on your specific setup (building a flow from your site to a third-party for SSO) and clarify exactly who needs which certificates.

First, let’s lock in the roles: From your description, your website is the Service Provider (SP) (the app that needs users to authenticate) and the third-party site is the Identity Provider (IdP) (the app that handles user authentication and sends back proof of it). If this was reversed (you’re the one authenticating users for the third-party), just flip the roles below.

Core Rule to Remember #

Both you and the third-party will generate your own asymmetric key pair (a private key + matching public certificate). The private key stays 100% secret with its owner—never share this with anyone. Only the public certificate is exchanged between parties.

Your Role as the Service Provider (SP) #

Here’s the step-by-step certificate flow for your setup:

• You generate your SP key pair: Create a private key (e.g., sp-private.key) and a public certificate (e.g., sp-public.crt). Store the private key securely on your server—don’t commit it to version control, don’t email it, don’t share it.
• Send your SP public certificate to the third-party IdP: They need this for two key tasks:
  1. Verifying the signature on the SAML AuthnRequest messages you send them (you sign these with your private key; they use your public cert to confirm the signature is valid).
  2. Encrypting the SAML Assertions they send back to you (only your private key can decrypt these encrypted assertions, keeping user data secure).
• Receive the third-party IdP’s public certificate: They’ll send you their own public certificate (e.g., idp-public.crt). You’ll use this to:
  1. Verify the signature on the SAML Assertions they send you (they sign these with their private key; your app uses their public cert to confirm the assertion hasn’t been tampered with).
  2. (Optional) Encrypt any sensitive messages you send to them (though this is less common for AuthnRequests).

If You Were the Identity Provider (IdP) #

Just in case your setup is reversed (you’re authenticating users for the third-party’s app):

• You generate your IdP key pair: Keep the private key secret, share the public certificate with the third-party SP.
• Receive the third-party SP’s public certificate: Use it to verify their signed AuthnRequests and encrypt assertions you send to them.

Quick Real-World Example #

To make this concrete for your scenario:

1. You generate sp-private.key (stored securely on your server) and sp-public.crt (sent via secure channel to the third-party IdP).
2. The IdP generates idp-private.key (kept safe on their end) and idp-public.crt (sent to you).
3. When you send an AuthnRequest to the IdP: You sign it with sp-private.key; the IdP uses sp-public.crt to verify the signature is legitimate.
4. When the IdP sends an Assertion back: They sign it with idp-private.key; your app uses idp-public.crt to verify it. If encryption is enabled, the IdP encrypts the Assertion with sp-public.crt; your app decrypts it with sp-private.key.

Key Don’ts #

• Never share your private key with anyone—this is the cornerstone of SAML’s security.
• Don’t reuse key pairs across different environments (e.g., dev vs prod) if you can avoid it.
• Make sure to use strong key sizes (2048 bits or higher) for all key pairs.

内容的提问来源于stack exchange，提问作者Abradolf Lincler