背景信息
OIDC SSO相关文档总共4篇，主要内容为对OIDC实现SSO登录流程时的各个细节和相关技术的阐述：
这个文档主要讲述OIDC规范中认证、签名和加密等相关内容规范。
认证
该部分内容来自OIDC Core Section 9 - Client Authentication
https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentcation
This section defines a set of Client Authentication methods that are used by Clients to authenticate to the Authorization Server when using the Token Endpoint. During Client Registration, the RP (Client) MAY register a Client Authentication method. If no method is registered, the default method is client_secret_basic.
Relying Paty在OpenID Provider上注册Client的时候，需要指定在Token Endpoint的认证方法，如果不指定，默认是就是client_secret_basic。
OIDC规范中定义了5种认证方法：
- client_secret_basic
- client_secret_post
- client_secret_jwt
- private_key_jwt
- none
其中client_secret_basic和client_secret_post属于OAuth 2.0 规定的方法；
| 方法 | 实现方式 |
|---|---|
| client_secret_basic | HTTP Basic authentication scheme. 提供一个http header：Authorization， 其中内容是：Authorization: Basic Base64_Encoder(<client_id> + ":" + <client_secret>) |
| client_secret_post | 在http post body中指定client_id和client_secret 样例如下： POST /resource HTTP/1.1 Content-Type: application/x-www-form-urlencoded client_id=cnt_dsfasdf&client_secret=djsfladsf&... |
| client_secret_jwt | 使用client_secret为共享秘钥对JWT做HMAC SHA签名。 必须包含：iss、sub、aud、jti、exp、iat几个Claim。 其中jti必须是第一次出现；exp指定了过期时间； |
| private_key_jwt | Client向OP注册一个公钥用于验签JWT。 必须包含：iss、sub、aud、jti、exp、iat几个Claim。 其中jti必须是第一次出现；exp指定了过期时间； |
| none | Client在Token Endpoint无需认证；可能是隐式流， 或者对应的Client没有Secret， 或者已经被其它方式认证过了。 |
签名
Depending on the transport through which the messages are sent, the integrity of the message might not be guaranteed and the originator of the message might not be authenticated. To mitigate these risks, ID Token, UserInfo Response, Request Object, and Client Authentication JWT values can utilize JSON Web Signature (JWS) [JWS] to sign their contents. To achieve message confidentiality, these values can also use JSON Web Encryption (JWE) [JWE] to encrypt their contents.
涉及到签名和加密的对象有ID Token、UserInfo端点返回的用户信息、Request对象，以及Client认证中的JWT等。
| 签名方式 | 实现 |
|---|---|
| 非对称签名 | 当使用RSA和ECDSA签名算法时，JWT中的JOSE Header指定的算法必须是JWA所支持的算法。 验签使用的公钥必须在OP暴露的JWK集合中，如果有多个公私钥对，JWT头部中必须包含对应的key id。 |
| 对称签名 | 使用client_secret作为共享秘密做MAC-based签名。其中对称签名方式不能在公开的客户端中使用（因为没有能力保存client secret）。 |
非对称签名使用的公私钥对支持轮转，轮转方式为：
OP先在jwks_uri暴露的公钥列表信息包含多个公钥以及对应的kid，然后在JWT签名时指定使用的kid，以此来实现轮转。
加密
在签名的基础上支持加密，最终加密后的结果都是一个JWE；加密的算法可以分为三类：
| 加密方式 | 实现 |
|---|---|
| RSA非对称加密 | 使用的公钥必须在参与者（RP or OP）的JWK Set（jwks_uri暴露）中，如果存在多个公钥，必须指定kid。 使用RSA来加密随机生成的数据加密秘钥，通过数据加密秘钥来加密对应签名过的JWT。 |
| 椭圆曲线非对称加密 | 生成一个椭圆曲线临时公钥来协商数据加密秘钥，协商数据加密秘钥所需的其它信息已经包含在RP公开的jwks_uri中。 Create an ephemeral Elliptic Curve public key for the epk element of the JOSE Header. The other public key used for the key agreement computation MUST be a public key published by the recipient in its JWK Set document. If there are multiple keys in the referenced JWK Set document, a kid value MUST be provided in the JOSE Header. Use the ECDH-ES algorithm to agree upon a Content Encryption Key to be used for encrypting the signed JWT. The key usage of the respective keys MUST support encryption. |
| 对称加密 | 使用client_secret来派生共享秘密后做加密。因为client_secret不知道多长，且不能直接用于加密，所以需要对client_secret做一个Hash，然后左截断到对称加密算法所需的位数。SHA-2 hash包括SHA-256、SHA-384、SHA-512等六种算法标准，在这里使用上述三种。 The symmetric encryption key is derived from the client_secret value by using a left truncated SHA-2 hash of the octets of the UTF-8 representation of the client_secret. For keys of 256 or fewer bits, SHA-256 is used; for keys of 257-384 bits, SHA-384 is used; for keys of 385-512 bits, SHA-512 is used. The hash value MUST be left truncated to the appropriate bit length for the AES key wrapping or direct encryption algorithm used, for instance, truncating the SHA-256 hash to 128 bits for A128KW. If a symmetric key with greater than 512 bits is needed, a different method of deriving the key from the client_secret would have to be defined by an extension. Symmetric encryption MUST NOT be used by public (non-confidential) Clients because of their inability to keep secrets. |
其它
- 目前OIDC标准中不包含ID Token的单个敏感Claim加密方式，也就是目前各个OpenID Provider自己定义，根据客户需求来操作；
参考文档
- OIDC Core：https://openid.net/specs/openid-connect-core-1_0.html
- OAuth 2.0 Authorization Framework - RFC 6749: https://www.rfc-editor.org/rfc/pdfrfc/rfc6749.txt.pdf
