OpenID Connect：OAuth 2.0协议之上的简单身份层

时间 2019-11-26

标签 openid connect oauth 2.0 协议之上简单身份繁體版

原文原文链接

OpenID Connect是什么？OpenID Connect(目前版本是1.0)是OAuth 2.0协议(可参考本人此篇：OAuth 2.0 / RCF6749 协议解读)之上的简单身份层，用 API 进行身份交互的框架，容许客户端根据受权服务器的认证结果最终确认用户的身份，以及获取基本的用户信息；它支持包括Web、移动、JavaScript在内的全部客户端类型；它是可扩展的协议，容许你使用某些可选功能，如身份数据加密、OpenID提供商发现、会话管理
OpenID Connect vs OpenID 2.0：OpenID Connect完成不少与OpenID 2.0相同的任务，是API-friendly，定义了可选的签名和加密的机制；OAuth 1.0a和OpenID 2.0的集成须要扩展，而OpenID Connect协议自己就创建在OAuth 2.0之上

部分名词解释：

1. Relying Party(RP)：依赖方，一般是第三方应用程序(客户端)
2. OpenID Provider(OP)：OpenID 提供方，一般是一个 OpenID 认证服务器，它能为依赖方提供断言以证明用户拥有某个标识
3. End-User(EU)：终端用户，指持有帐号的人

OpenID Connect协议构成：
1. Core – 定义 OpenID Connect 核心功能: 认证创建在OAuth 2.0之上，使用声明与终端用户进行信息交互
2. Discovery – (Optional) Defines how Clients dynamically discover information about OpenID Providers
3. Dynamic Registration – (Optional) Defines how clients dynamically register with OpenID Providers
4. OAuth 2.0 Multiple Response Types – 定义了几种新的OAuth 2.0响应类型
5. OAuth 2.0 Form Post Response Mode – (Optional) Defines how to return OAuth 2.0 Authorization Response parameters (including OpenID Connect Authentication Response parameters) using HTML form values that are auto-submitted by the User Agent using HTTP POST
6. Session Management – (Optional) Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality
7. Front-Channel Logout – (Optional) Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
8. Back-Channel Logout – (Optional) Defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out
下边两条是 Web RPs 实现者的独立参考指南:html
1. Basic Client Implementer’s Guide – Simple subset of the Core functionality for a web-based Relying Party using the OAuth code flow
2. Implicit Client Implementer’s Guide – Simple subset of the Core functionality for a web-based Relying Party using the OAuth implicit flow
协议迁移规范:web
1. OpenID 2.0 to OpenID Connect Migration 1.0 – Defines how to migrate from OpenID 2.0 to OpenID Connect
OpenID Connect 工做组已启动新的工做计划:数组
1. OpenID Connect Profile for SCIM Services – (Optional) Defines how to use SCIM with OpenID Connect
2. OpenID Connect Federation – (Optional) Defines how sets of OPs and RPs can establish trust by utilizing a Federation Operator

OpenID Connect的工做流程：下以EU获取UserInfo为例来讲明，

1. RP(客户端)发送一个认证请求给OP；
2. OP对EU进行身份认证并得到受权；
3. OP发送ID Token给RP，一般也同时发送Access Token(为兼容OAuth 2.0。ID Token其实能够取代Access Token用来完成受权)；
4. RP使用Access Token发送一个请求UserInfo EndPoint；
5. UserInfo EndPoint返回EU的Claims。

下边是关于“ID Token 与 Access Token”的描述来自 User Authentication with OAuth 2.0 [UserInfo Endpoint]：安全

It should be noted that clients are not required to use the access token, since the ID Token contains all the necessary information for processing the authentication event. However, in order to provide compatibility with OAuth and match the general tendency for authorizing identity and other API access in parallel, OpenID Connect always issues the ID token along side an OAuth access token.

ID Token：它是一种JWT(JSON Web Token)格式数据，主要由如下几部分构成：

1. iss：必须。Issuer Identifier，OP的惟一标识，一个区分大小写的https URL，不包含query和fragment组件
2. sub：必须。Subject Identifier，iss提供的EU的标识，在iss范围内惟一，最长为255个ASCII个字符，区分大小写
3. aud：必须。Audience(s)，标识ID Token的受众，必须包含OAuth2的client_id，分大小写的字符串数组
4. exp：必须。Expiration time，超过此时间的ID Token会做废
5. iat：必须。Issued At Time，JWT的构建的时间
6. auth_time：AuthenticationTime，EU完成认证的时间。若是RP发送AuthN请求的时候携带max_age的参数，则此Claim是必须的
7. nonce：RP发送认证请求的时候提供的随机字符串，用来减缓重放攻击，也能够用来关联客户端Session。若是nonce存在，客户端必须验证nonce
8. acr：可选。Authentication Context Class Reference，表示一个认证上下文引用值，能够用来标识认证上下文类
9. amr：可选。Authentication Methods References，表示一组认证方法
10. azp：可选。Authorized party，结合aud使用。只有在被认证的一方和受众（aud）不一致时才使用此值，通常状况下不多使用

形如：服务器

{
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "auth_time": 1311280969,
   "acr": "urn:mace:incommon:iap:silver"
}

关于协议定义Claims的更多信息参考：http://openid.net/specs/openid-connect-core-1_0.html#Claims。ID Token必须使用JWS进行签名，若是要用JWE加密也必须先进行JWS签名session

JSON Web Signature (JWS)：JSON数据进行数字签名或MACed后再经base64url编码。

JWS Compact Serialization以下链接序列：Header.Payload.Signature数据结构

BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)

1. JWS Protected Header
    {"typ":"JWT",
      "alg":"HS256"}
    编码后：
    eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
2. JWS Payload
    {"iss":"joe",
      "exp":1300819380,
      "http://example.com/is_root":true}
    编码后：
    eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
3. JWS Signature
    Signing Input value：
    eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
     .
     eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
    HMAC SHA-256 key：
    {"kty":"oct",
      "k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
     }
    JWS Signature：
    dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
4. JWS Compact Serialization
    eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
     .  
    eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
     cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
     .
     dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

JWS JSON Serialization包含以下几个部分：框架

1. "protected", with the value BASE64URL(UTF8(JWS Protected Header))
2. "header", with the value JWS Unprotected Header
3. "payload", with the value BASE64URL(JWS Payload)
4. "signature", with the value BASE64URL(JWS Signature)

General JWS JSON Serialization：ide

{
      "payload":"<payload contents>",
      "signatures":[
       {"protected":"<integrity-protected header 1 contents>",
        "header":<non-integrity-protected header 1 contents>,
        "signature":"<signature 1 contents>"},
       ...
       {"protected":"<integrity-protected header N contents>",
        "header":<non-integrity-protected header N contents>,
        "signature":"<signature N contents>"}]
}

Flattened JWS JSON Serialization：post

{
      "payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
      "protected":"eyJhbGciOiJFUzI1NiJ9",
      "header": {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
      "signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q"
}

JSON Web Encryption (JWE)：

JWE Compact Serialization以下链接序列：

      BASE64URL(UTF8(JWE Protected Header)) || '.' ||
      BASE64URL(JWE Encrypted Key) || '.' ||
      BASE64URL(JWE Initialization Vector) || '.' ||
      BASE64URL(JWE Ciphertext) || '.' ||
      BASE64URL(JWE Authentication Tag)

JWE JSON Serialization包含以下几个部分：

      1. "protected", with the value BASE64URL(UTF8(JWE Protected Header))
      2. "unprotected", with the value JWE Shared Unprotected Header
      3. "header", with the value JWE Per-Recipient Unprotected Header
      4. "encrypted_key", with the value BASE64URL(JWE Encrypted Key)
      5. "iv", with the value BASE64URL(JWE Initialization Vector)
      6. "ciphertext", with the value BASE64URL(JWE Ciphertext)
      7. "tag", with the value BASE64URL(JWE Authentication Tag)
      8. "aad", with the value BASE64URL(JWE AAD)

General JWE JSON Serialization：

{
      "protected":"<integrity-protected shared header contents>",
      "unprotected":<non-integrity-protected shared header contents>,
      "recipients":[
       {"header":<per-recipient unprotected header 1 contents>,
        "encrypted_key":"<encrypted key 1 contents>"},
       ...
       {"header":<per-recipient unprotected header N contents>,
        "encrypted_key":"<encrypted key N contents>"}],
      "aad":"<additional authenticated data contents>",
      "iv":"<initialization vector contents>",
      "ciphertext":"<ciphertext contents>",
      "tag":"<authentication tag contents>"
}

Flattened JWE JSON Serialization：

{
      "protected":"<integrity-protected header contents>",
      "unprotected":<non-integrity-protected header contents>,
      "header":<more non-integrity-protected header contents>,
      "encrypted_key":"<encrypted key contents>",
      "aad":"<additional authenticated data contents>",
      "iv":"<initialization vector contents>",
      "ciphertext":"<ciphertext contents>",
      "tag":"<authentication tag contents>"
}

JSON Web Key (JWK)：JWK用于JWS和JWE中，也是一种JSON数据结构，其包含了以下几项：

1. "kty" (Key Type) Parameter
2. "use" (Public Key Use) Parameter
3. "key_ops" (Key Operations) Parameter
4. "alg" (Algorithm) Parameter
5. "kid" (Key ID) Parameter
6. "x5u" (X.509 URL) Parameter
7. "x5c" (X.509 Certificate Chain) Parameter
8. "x5t" (X.509 Certificate SHA-1 Thumbprint) Parameter
9. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint)

形如：
```
     {"kty":"EC",
      "crv":"P-256",
      "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
      "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
      "kid":"Public key used in JWS spec Appendix A.3 example"
     }
```

Base64编码：Base64是基于64个可打印字母表(Table 1: The Base64 Alphabet)来表示数据的方法，可用于二进制数据如图片、视频、音频数据的转换表示，可查看RFC2045～RFC2049，上面有MIME(Multipurpose Internet Mail Extensions)的详细规范：

1. 每3个字节一组，再按6bits(2 ^ 6 = 64)为一组分红4组，即3 * 8bits = 4 * 6bits；
2. 以6bits的值为索引查找字母表中对应的字符。最后3字节变成4字节，长度增长33%；
3. 对于不足3字节的状况用\x00字节补足，最后用尾部加“=”的个数来表示缺乏的字节数，即Base64编码的尾部最多有1~2个“=”。

在RFC 2045中还规定，输出每行不超过76字符(CRLF结尾)：

The encoded output stream must be represented in lines of no more than 76 characters each. All line breaks or other characters not found in Table 1 must be ignored by decoding software.

因为+和/字符在URL中传递是不安全的，所以又出现了以-和_来替换+和/的Base64URL编码：

因为“=”字符也可能出如今Base64编码中，但“=”用在URL、Cookie里面会形成歧义，因此不少Base64编码把“=”去掉。至于去掉“=”后如何解码呢？正常Base64编码后的序列字符数必定是4的倍数，若是结果不是，则可反推去掉了多少个“=”

相关参考：
1. OIDC(OpenId Connect)身份认证受权(核心部分)

2. RFC 7515 - JSON Web Signature (JWS)
3. RFC 7516 - JSON Web Encryption (JWE)

4. RFC 7517 - JSON Web Key (JWK)