Oauth2.0/OIDC
OIDC解决了OAuth 2.0的认证问题
OIDC是基于OAuth2+OpenID整合的新的认证授权协议；OAuth2是一个授权(authorization)的开放协议, 在全世界得到广泛使用，但在实际使用中，OAuth2只解决了授权问题，没有实现认证部分，往往需要添加额外的API来实现认证；而OpenID呢，是一个认证(authentication )的协议，二者在实际使用过程中都有其局限性；
综合二者，即是OIDC；通过OIDC，既能有OAUTH2的功能，也有OpenID的功能；恰到好处…
OIDC将是替换(或升级)OAuth2，OpenID的不二选择..
OIDC在OAuth2的access_tokeryn的基础上增加了身份认证信息；通过公钥私钥配合校验获取身份等其他信息——即idToken;
什么是 OAuth 2.0
OAuth 2.0 是一个行业的标准授权协议。OAuth 2.0 专注于简化客户端开发人员，同时为 Web 应用程序，桌面应用程序，手机和客厅设备提供特定的授权流程。
它的最终目的是为第三方应用颁发一个有时效性的令牌 token。使得第三方应用能够通过该令牌获取相关的资源。常见的场景就是：第三方登录。当你想要登录某个论坛，但没有账号，而这个论坛接入了如 QQ、Facebook 等登录功能，在你使用 QQ 登录的过程中就使用的 OAuth 2.0 协议。
如果你想了解更多，其官方网址为：https://oauth.net/2/。下面我们来了解下 OAuth 协议的基本原理
角色
首先需要介绍的是 OAuth 2.0 协议中的一些角色，整个授权协议的流程都将围绕着这些角色：
resource owner，资源所有者，能够允许访问受保护资源的实体。如果是个人，被称为 end-user。resource server，资源服务器，托管受保护资源的服务器。client，客户端，使用资源所有者的授权代表资源所有者发起对受保护资源的请求的应用程序。如：web网站，移动应用等。authorization server，授权服务器，能够向客户端颁发令牌。user-agent，用户代理，帮助资源所有者与客户端沟通的工具，一般为 web 浏览器，移动 APP 等。
可能有些朋友依然不太理解，这里举例说明：假如我想要在 coding.net 这个网站上用 github.com 的账号登录。那么 coding 相对于 github 就是一个客户端。而我们用什么操作的呢？浏览器，这就是一个用户代理。当从 github 的授权服务器获得 token 后，coding 是需要请求 github 账号信息的，从哪请求？从 github 的资源服务器。
协议流程
上图详细的描述了这四个角色之间的步骤流程：
- (A) Client 请求 Resource Owner 的授权。授权请求可以直接向 Resource Owner 请求，也可以通过 Authorization Server 间接的进行。
- (B) Client 获得授权许可。
- © Client 向 Authorization Server 请求访问令牌。
- (D) Authorization Server 验证授权许可，如果有效则颁发访问令牌。
- (E) Client 通过访问令牌从 Resource Server 请求受保护资源。
- (F) Resource Server 验证访问令牌，有效则响应请求。
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow授权
一个客户端想要获得授权，就需要先到服务商那注册你的应用。一般需要你提供下面这些信息：
- 应用名称
- 应用网站
- 重定向 URI 或回调 URL（redirect_uri）
重定向 URI 是服务商在用户授权（或拒绝）应用程序之后重定向用户的地址，因此也是用于处理授权代码或访问令牌的应用程序的一部分。在你注册成功之后，你会从服务商那获取到你的应用相关的信息：
- 客户端标识 client_id
- 客户端密钥 client_secret
client_id 用来表识客户端（公开），client_secret 用来验证客户端身份（保密）。
授权类型
OAuth 2.0 列举了四种授权类型，分别用于不同的场景：
- Authorization Code（授权码 code）：服务器与客户端配合使用。
- Implicit（隐式 token）：用于移动应用程序或 Web 应用程序（在用户设备上运行的应用程序）。
- Resource Owner Password Credentials（资源所有者密码凭证 password）：资源所有者和客户端之间具有高度信任时（例如，客户端是设备的操作系统的一部分，或者是一个高度特权应用程序），以及当其他授权许可类型（例如授权码）不可用时被使用。
- Client Credentials（客户端证书 client_credentials）：当客户端代表自己表演（客户端也是资源所有者）或者基于与授权服务器事先商定的授权请求对受保护资源的访问权限时，客户端凭据被用作为授权许可。
下面来具体说说这四种授权。注意重定向一定要用 302。
授权码模式
该方式需要资源服务器的参与，应用场景大概是：
- 资源拥有者（用户）需要登录客户端（APP），他选择了第三方登录。
- 客户端（APP）重定向到第三方授权服务器。此时客户端携带了客户端标识（client_id），那么第三方就知道这是哪个客户端，资源拥有者确定（拒绝）授权后需要重定向到哪里。
- 用户确认授权，客户端（APP）被重定向到注册时给定的 URI，并携带了第三方给定的 code。
- 在重定向的过程中，客户端拿到 code 与
client_id、client_secret去授权服务器请求令牌，如果成功，直接请求资源服务器获取资源，整个过程，用户代理是不会拿到令牌 token 的。 - 客户端（APP）拿到令牌 token 后就可以向第三方的资源服务器请求资源了。
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
Figure 3: Authorization Code Flow具体说明，这里以 coding 和 github 为例。当我想在 coding 上通过 github 账号登录时：
1、GET 请求 点击登录，重定向到 github 的授权端点：
https://github.com/login/oauth/authorize?
response_type=code&
client_id=a5ce5a6c7e8c39567ca0&
redirect_uri=https://coding.net/api/oauth/github/callback&
scope=user:email| 字段 | 描述 |
|---|---|
| response_type | 必须，固定为 code，表示这是一个授权码请求。 |
| client_id | 必须，在 github 注册获得的客户端 ID。 |
| redirect_uri | 可选，通过客户端注册的重定向 URI（一般要求且与注册时一致）。 |
| scope | 可选，请求资源范围，多个空格隔开。 |
| state | 可选（推荐），如果存在，原样返回给客户端。 |
返回值：
https://coding.net/api/oauth/github/callback?code=fb6a88dc09e843b33f| 字段 | 描述 |
|---|---|
| code | 必须。授权码 |
| state | 如果出现在请求中，必须包含。 |
授权错误
第一种，客户端没有被识别或错误的重定向 URI，授权服务器没有必要重定向资源拥有者到重定向URI，而是通知资源拥有者发生了错误。
第二种，客户端被正确地授权了，但是其他某些事情失败了。这种情况下下面地错误响应会被发送到客户端，包括在重定向 URI 中。
https://coding.net/api/oauth/github/callback?
error=redirect_uri_mismatch&
error_description=The+redirect_uri+MUST+match+the+registered+callback+URL+for+this+application.&
error_uri=https%3A%2F%2Fdeveloper.github.com%2Fapps%2Fmanaging-oauth-apps%2Ftroubleshooting-authorization-request-errors%2F%23redirect-uri-mismatch| 字段 | 描述 |
|---|---|
| error | 必须，必须是预先定义的错误码: 错误码。 |
| error_description | 可选，错误描述 |
| error_uri | 可选，指向可解读错误的 URI |
| state | 必须，如果出现在授权请求中 |
2、POST 请求 获取令牌 token，当获取到授权码 code 后，客户端需要用它获取访问令牌：
https://github.com/login/oauth/access_token?
client_id=a5ce5a6c7e8c39567ca0&
client_secret=xxxx&
grant_type=authorization_code&
code=fb6a88dc09e843b33f&
redirect_uri=https://coding.net/api/oauth/github/callback出于安全考虑 client_id 和 client_secret 可以通过 HTTP Basic 认证：Authorization: Basic YTVjZTVhNmM3ZThjMzk1NjdjYTA6eHh4eA==
| 字段 | 描述 |
|---|---|
| grant_type | 必须，固定为 authorization_code／refresh_token。 |
| code | 必须，上一步获取到的授权码。 |
| redirect_uri | 必须（如果请求/authorize接口有），完成授权后的回调地址，与注册时一致。 |
| client_id | 必须，客户端标识。 |
| client_secret | 必须，客户端密钥。 |
返回值：
{
"access_token":"a14afef0f66fcffce3e0fcd2e34f6ff4",
"token_type":"bearer",
"expires_in":3920,
"refresh_token":"5d633d136b6d56a41829b73a424803ec"
}| 字段 | 描述 |
|---|---|
| access_token | 这个就是最终获取到的令牌。 |
| token_type | 令牌类型，常见有 bearer/mac/token（可自定义）。 |
| expires_in | 失效时间。 |
| refresh_token | 刷新令牌，用来刷新 access_token。 |
3、获取资源服务器资源，拿着 access_token 就可以获取账号的相关信息了：
curl -H "Authorization: token a14afef0f66fcffce3e0fcd2e34f6ff4" https://api.github.com/user4、POST 请求 刷新令牌
我们的 access_token 是有时效性的，当在获取 github 用户信息时，如果返回 token 过期：
https://github.com/login/oauth/access_token?
client_id=a5ce5a6c7e8c39567ca0&
client_secret=xxxx&
redirect_uri=https://coding.net/api/oauth/github/callback&
grant_type=refresh_token&
refresh_token=5d633d136b6d56a41829b73a424803ec| 字段 | 描述 |
|---|---|
| redirect_uri | 必须 |
| grant_type | 必须，固定为 refresh_token |
| refresh_token | 必须，上面获取到的 refresh_token |
返回值：
{
"access_token":"a14afef0f66fcffce3e0fcd2e34f6ee4",
"token_type":"bearer",
"expires_in":3920,
"refresh_token":"4a633d136b6d56a41829b73a424803vd"
}refresh_token 只有在 access_token 过期时才能使用，并且只能使用一次。当换取到的 access_token 再次过期时，使用新的 refresh_token 来换取 access_token
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
Figure 2: Refreshing an Expired Access Token[旧版] 隐式模式
该方式一般用于移动客户端或网页客户端。隐式授权类似于授权码授权，但 token 被返回给用户代理再转发到客户端（APP），因此它可能会暴露给用户和用户设备上的其它客户端（APP）。此外，此流程不会对客户端（APP）的身份进行身份验证，并且依赖重定向 URI（已在服务商中注册）来实现此目的。
基本原理：要求用户授权应用程序，然后授权服务器将访问令牌传回给用户代理，用户代理将其传递给客户端。
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
Note: The lines illustrating steps (A) and (B) are broken into two
parts as they pass through the user-agent.
Figure 4: Implicit Grant Flow1、同样以 coding 和 github 为例：
https://github.com/login/oauth/authorize?
response_type=token&
client_id=a5ce5a6c7e8c39567ca0&
redirect_uri=https://coding.net/api/oauth/github/callback&
scope=user:email| 字段 | 描述 |
|---|---|
| response_type | 必须，固定为 token。 |
| client_id | 必须。当客户端被注册时，有授权服务器分配的客户端标识。 |
| redirect_uri | 可选。由客户端注册的重定向URI。 |
| scope | 可选。请求可能的作用域。 |
| state | 可选(推荐)。任何需要被传递到客户端请求的URI客户端的状态。 |
返回值：
https://coding.net/api/oauth/github/callback#
access_token=a14afef0f66fcffce3e0fcd2e34f6ff4&
token_type=token&
expires_in=3600| 字段 | 描述 |
|---|---|
| access_token | 必须。授权服务器分配的访问令牌。 |
| token_type | 必须。令牌类型。 |
| expires_in | 推荐，访问令牌过期的秒数。 |
| scope | 可选，访问令牌的作用域。 |
| state | 必须，如果出现在授权请求期间，和请求中的 state 参数一样。 |
授权错误和上面一样
2、用户代理提取令牌 token 并提交给 coding
3、coding 拿到 token 就可以获取用户信息了
curl -H "Authorization: token a14afef0f66fcffce3e0fcd2e34f6ff4" https://api.github.com/user[旧版] 资源所有者密码模式
用户将其服务凭证（用户名和密码）直接提供给客户端，该客户端使用凭据从服务获取访问令牌。如果其它方式不可行，则只应在授权服务器上启用该授权类型。此外，只有在客户端受到用户信任时才能使用它（例如，它由服务商自有，或用户的桌面操作系统）。
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
Figure 5: Resource Owner Password Credentials FlowPOST 请求 密码凭证流程
https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID| 字段 | 描述 |
|---|---|
| grant_type | 必须，固定为 password。 |
| username | 必须，UTF-8 编码的资源拥有者用户名。 |
| password | 必须，UTF-8 编码的资源拥有者密码。 |
| scope | 可选，授权范围。 |
返回值：
{
"access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
"refresh_token" : "...",
}如果授权服务器验证成功，那么将直接返回令牌 token，改客户端已被授权。
客户端模式
这种模式只需要提供 client_id 和 client_secret 即可获取授权。一般用于后端 API 的相关操作。
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
Figure 6: Client Credentials FlowPOST 请求 客户端凭证流程：
https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET| 字段 | 描述 |
|---|---|
| grant_type | 必须。必须设置到客户端证书中。 |
| scope | 可选。授权的作用域。 |
返回值
{
"access_token" : "...",
"token_type" : "...",
"expires_in" : "...",
}如果授权服务器验证成功，那么将直接返回令牌 token，改客户端已被授权。
参考网站
[1] https://developers.douban.com/wiki/?title=oauth2
[2] https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
[3] https://tools.ietf.org/html/rfc6749
本文链接：https://deepzz.com/post/what-is-oauth2-protocol.html，
什么是 OIDC
OIDC是一个OAuth2上层的简单身份层协议。它允许客户端验证用户的身份并获取基本的用户配置信息。OIDC使用JSON Web Token（JWT）作为信息返回，通过符合OAuth2的流程来获取，更多详细 10 分钟理解什么是 OAuth 2.0 协议。
OAuth2与资源访问和共享有关，而OIDC与用户身份验证有关。
其目的是为您提供多个站点的登录名。每次需要使用OIDC登录网站时，都会被重定向到登录的OpenID网站，然后再回到该网站。例如，如果选择使用Google帐户登录Auth0，这就使用了OIDC。成功通过Google身份验证并授权Auth0访问您的信息后，Google会将有关用户和执行的身份验证的信息发送回Auth0。此信息在JWT中返回，包含ID Token或者Access Token。
JWT包含Claims，它们是有关实体（通常是用户）的Claims（例如名称或电子邮件地址）和其他元数据。OIDC规范定义了一组标准的权利要求。这组标准声明包括姓名，电子邮件，性别，出生日期等。但是，如果要获取有关用户的信息，并且当前没有最能反映此信息的标准声明，则可以创建自定义声明并将其添加到令牌中。
较OAuth2，OIDC有一些不同的概念：
- OpenID Provider（OP），实现OIDC的OAuth2授权服务器
- Relying Party（RP），使用OIDC的OAuth2客户端
- End-User（EU），用户
- ID Token，JWT格式的授权Claims
- UserInfo Endpoint，用户信息接口，通过ID Token访问时返回用户信息，此端点必须为HTTPS
协议流程
从理论上来讲，OIDC协议遵循以下步骤：
- RP发送认证请求到OP
- OP验证End-User并颁发授权
- OP用ID Token（通常是Access Token）进行响应
- RP携带Access Token发送请求到UserInfo Endpoint
- UserInfo Endpoint返回End-User的Claims
+--------+ +--------+
| | | |
| |---------(1) AuthN Request-------->| |
| | | |
| | +--------+ | |
| | | | | |
| | | End- |<--(2) AuthN & AuthZ-->| |
| | | User | | |
| RP | | | | OP |
| | +--------+ | |
| | | |
| |<--------(3) AuthN Response--------| |
| | | |
| |---------(4) UserInfo Request----->| |
| | | |
| |<--------(5) UserInfo Response-----| |
| | | |
+--------+ +--------+ID Token
这里预先解释ID Token的含义，OIDC对OAuth2进行的主要扩展（用户用户身份验证）就是ID Token，为JWT格式。其中包含授权服务器对用户验证的Claims和其它请求的Claims。
在ID Token中，以下Clams适用于使用OIDC的所有OAuth2：
- iss，必须，发行机构Issuer，大小写敏感的URL，不能包含query参数
- sub，必须，用户身份Subject，Issuer为End-User分配的唯一标识符，大小写敏感不超过255 ASCII自符
- aud，必须，特别的身份Audience，必须包含OAuth2的client_id，大小写敏感的字符串/数组
- exp，必须，iat到期时间Expire，参数要求当前时间在该时间之前，通常可以时钟偏差几分钟，unix时间戳
- iat，必须，JWT颁发时间Issuer at time，unix时间戳
- auth_time，End-User验证时间，unix时间戳。当发出max_age或auth_time Claims时，必须。
- nonce，用于将Client session和ID Token关联，减轻重放攻击，大小写敏感字符串
- acr，可选，Authentication Context Class Reference，0 End-User不符合ISO/IEC 28115 level 1，不应该授权对任何货币价值的资源访问。大小写敏感的字符串。
- amr，可选，Authentication Methods References，JSON字符串数组，身份验证的表示符，如可能使用了密码和OTP身份验证方式
- azp，可选，Authorized party，被授权方。如果存在必须包含OAuth2的Client ID，仅当ID Token有单个Audience且与授权方不同时，才需要此Claim
ID Token可能包含其它Claims，任何未知的Claims都必须忽略。ID Token必须使用JWS进行签名，并分别使用JWS和JWE进行可选的签名和加密，从而提供身份验证、完整性、不可抵赖性和可选的机密性。如果对ID Token进行了加密，则必须先对其签名，结果是一个嵌套的JWT。ID Token不能使用nonce作为alg值，除非所使用的响应类型没有从Authorization Endpoint返回任何ID Token（如Authorization Code Flow），并且客户端在注册时显示请求使用nonce。
授权
身份验证遵循以下三种方式；授权码方式（response_type=code）、隐式方式（response_type=id_token token或response_type=id_token）、混合方式。
下表是三种方式的特征：
| 属性 | 授权码 | 隐式 | 混合 |
|---|---|---|---|
| Token从authorization端点返回 | no | yes | no |
| Token从token端点返回 | yes | no | no |
| Token未显示给浏览器 | yes | no | no |
| 能够验证客户端 | yes | no | yes |
| 可以刷新Token | yes | no | yes |
| 一次交流 | no | yes | no |
| 服务器到服务器 | yes | no | no |
response_type对应的身份验证方式：
| response_type | 方式 |
|---|---|
| code | 授权码 |
| id_token | 隐式 |
| id_token token | 隐式 |
| code id_token | 混合 |
| code token | 混合 |
| code id_token token | 混合 |
除了由OAuth2定义的“response_type”之外，所有code均在 OAuth2多种响应类型编码实践。
注意OAuth2为隐式类型定义token的响应类型，但OIDC不会使用此响应类型，因为不会返回ID Token。
授权码方式
使用授权码方式时，所有Token从Token端点返回。授权码将授权code返回给客户端，然后客户端可以将其直接交换为ID Token和Access Token。这样的好处是不会向User-Agent及可能访问User-Agent的其它恶意应用公开任何Token。授权服务器还可以在交换Access Token的授权code之前对客户端进行身份验证。授权code适用于可以安全的维护其自身和授权服务器之间的客户端机密的客户端。
执行以下步骤：
- 客户端（RP）准备一个包含所需请求参数的身份验证请求
- 客户端将（RP）请求发送到授权服务器（OP）
- 授权服务器（OP）对用户（EU）进行身份验证
- 授权服务器（OP）获得用户同意/或授权
- 授权服务器（OP）使用授权码将用户发送回客户端（RP）
- 客户端（RP）使用Token Endpoint的授权码来请求响应
- 客户端（RP）收到响应，该响应Body中包含ID Token和Access Token
- 客户端（RP）验证ID Token并检索用户的标识符
授权请求
授权服务器（OP）的authorization端点需要支持GET和POST方法，GET采用Query String序列化，POST采用Form序列化。OIDC采用OAuth2的授权码流程参数：
- scope，必须，OIDC必须包含openid的scope参数
- response_type，必须，同OAuth2
- client_id，必须，同OAuth2
- redirect_uri，必须，同OAuth2
- state，可选，同OAuth2
如：
HTTP/1.1 302 Found
Location: https://openid.c2id.com/login?
response_type=code
&scope=openid
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb授权响应
OP收到验证请求后，需要对请求参数做严格的验证：
- 验证OAuth2的相关参数
- 验证scope是否有openid参数，如果没有则为OAuth2请求
- 验证所有必须的参数是否都存在
- 如果sub是被要求了，必须尽在由子值标识的最终用户与活动session通过身份验证的情况下积极响应。不得使用不用用户的ID Token或Access Token响应，即使这些用户与授权服务器由活动session。如果支持claims，则可以使用id_token_hint发出请求。
验证通过后引导EU进行身份认证并同意授权。完成后，会重定向到RP指定的回调地址，并携带code和state相关参数：
HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj获取Token
RP使用上一步获得的code请求token端点，然后就可以获得响应Token，其中除了OAuth2规定的数据外，还会附加一个id_token的字段，如：
POST /token HTTP/1.1
Host: openid.c2id.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
成功后，OP会返回带有ID Token的JSON数据：
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}在拿到这些信息后，需要对id_token及access_token进行验证。验证成功就可以通过UserInfo端点获取用户信息了。
验证Token
授权服务器必须验证Token的有效性：
- 根据RFC6749
- 验证ID Token规则
- 验证Access Token规则
UserInfo
获取用户信息，客户端（RP）可以通过GET或POST请求通过UserInfo Endpoint获取用户信息。
GET /userinfo HTTP/1.1
Host: openid.c2id.com
Authorization: Bearer SlAV32hkKG请求成功：
{
"sub" : "alice",
"email" : "alice@wonderland.net",
"email_verified" : true,
"name" : "Alice Adams",
"given_name" : "Alice",
"family_name" : "Adams",
"phone_number" : "+359 (99) 100200305",
"profile" : "https://c2id.com/users/alice",
"https://c2id.com/groups" : [ "audit", "admin" ]
}隐式授权
隐式授权，所有Token都从授权端点返回。主要由浏览器中使用脚本语言实现的客户机使用。访问Token和ID Token直接返回给客户端，授权服务器不执行客户端身份验证。
- 客户端（RP）携带认证参数发送请求到授权服务器（OP）
- 授权服务器（OP）验证用户并得到用户批准
- 授权服务器（OP）携带用户相关信息+ID Token/Access Token返回到客户端（RP）
- 客户端（RP）验证ID Token和检索用户标识符
授权请求
- response_type，必须，’id_token token’或’id_token’。无Access Token使用’id_token’
- redirect_uri，必须，OP处登记的重定向地址
- nonce，必须，隐式授权必须
授权响应
- access_token，如果response_type是id_token可以不反回
- token_type，固定为Bearer，
- id_token，必须，ID Token
- state
- expires_in，可选，Access Token到期时间（s）
之后就可以拿着ID Token
混合授权
是上面两种模式的混合。可选response_type有：code id_token，code token，code id_token token。
参考资料
[1] https://openid.net/specs/openid-connect-core-1_0.html
[2] https://www.jianshu.com/p/be7cc032a4e9
[3] https://demo.c2id.com/oidc-client/
