OpenID Connect

OAuth是关于授权（给予第三方应用访问你存放在某处的资料，例如让Gmem访问你的Github头像）的开放标准，目前版本是2.0。

只有得到用户的授权，Github才会允许Gmem访问你的头像。那么Github怎么样才能确认Gmem获得授权了呢？最简单的方法是把你的Github密码告诉Gmem，这显然是不安全的：

1. 你必须修改密码，才能取消授权
2. 如果Gmem泄漏了密码，你的Github账户将发生危险

OAuth协议就是为了解决这个安全问题而生。

术语	说明
Third-party App	第三方应用程序，OAuth的客户端，例如上面例子中的Gmem
HTTP service	服务提供商，例如上面例子中的Github
Resource Owner	资源所有者，用户，例如上面例子中的Github用户
User Agent	用户代理，通常是浏览器
Authorization server	专门处理授权请求的服务
Resource server	专门维护资源的服务，可以和Authorization server是同一服务，也可以是不同服务

OAuth提供一种机制，让Third-party App安全的获得User Agent的授权，然后和HTTP service交互。

OAuth在第三方应用和服务提供商之间，加入一个授权层（Authorization layer），第三方应用不直接登陆到服务提供商，而是登陆授权层。授权层给予第三方APP以令牌，令牌包含权限范围、有效期等关键信息。

第三方应用携带令牌，访问服务提供商，后者校验令牌并确定它能否访问目标资源。

OAuth协议的抽象工作流图：

其中A、B表示第三方APP获得资源所有者的授权的过程，有多种变体，对应了OAuth的授权模式。

客户端必须得到用户的授权（Authorization Grant），才能获得令牌（Access Token）。OAuth 2.0定义了四种授权方式：

1. 授权码模式（authorization code）
2. 简化模式（implicit）
3. 密码模式（resource owner password credentials）
4. 客户端模式（client credentials）

该模式功能最完整、流程最严密，它让第三方应用的后台，与授权服务进行交互：

步骤如下：

1. 用户访问第三方应用，后者将前者导向授权服务器，附带一个重定向URL（A）。导向授权服务器时，附带以下URL参数：
   1. response_type：表示授权类型，必须，此处的值固定为"code"
   2. client_id：表示客户端的ID，必须
   3. redirect_uri：表示重定向URI，可选
   4. scope：表示申请的权限范围，可选
   5. state：表示客户端的当前状态，可以指定任意值，授权服务器会原样返回
2. 认证服务器会询问资源所有者（通常就是上条的用户，坐在浏览器面前），是否授予权限（B）
3. 如果资源所有者点击允许，则认证服务器执行浏览器重定向，回到步骤A指定的URL，并且附带授权码（C）。授权服务器进行重定向时，在URL后附加参数：
   1. code：表示授权码，必须。授权码的有效期应该很短，例如10分钟，第三方应用只能使用该码一次，否则会被授权服务器拒绝。授权码和client_id + redirect_url的组合是一一对应的
   2. state：如果客户端的请求中包含这个参数，授权服务器原样返回
4. 第三方应用的后台，使用授权码，向授权服务器申请访问令牌（D）。授权服务器的应答包含以下参数：
   
   JSON

   1 2 3 4 5 6 7

   {   "access_token":"2YotnFZFEjr1zCsicMWpAA", // 令牌   "token_type":"bearer",  // 令牌类型，例如bearer、mac   "expires_in":3600, // 令牌有效期，单位秒   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", // 用于刷新令牌   "scope":"..."  // 授权范围，如果和申请时一致，可省略 }

5. 授权服务器向第三方应用的后端发送访问令牌（E），此令牌第三方后端自己保存，不发给前端

该模式下，不需要经过第三方应用的后端，直接在浏览器中申请令牌，跳过授权码这个步骤。令牌对用户可见。

步骤如下：

1. 第三方应用将用户导向授权服务器
2.  用户决定是否给于第三方应用授权
3. 如果用户给予授权，授权服务器将用户导向第三方应用指定的重定向URL，并在URL的Hash部分包含了访问令牌
4. 浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值
5. 资源服务器返回一个脚本，其中包含的代码可以获取Hash值中的令牌
6. 浏览器执行上一步获得的脚本，提取出令牌
7. 浏览器将令牌传递给第三方应用客户的

在此模式下，用户向第三方应用提供自己的用户名和密码。第三方应用使用这些信息，向服务商提供商索要授权。

第三方应用以自己的身份，通过授权服务器，向服务提供商索取授权。

OpenID Connect目前已经成为单点登陆（single sign-on）、身份提供（identity provision）的领先标准。它的特点是：

1. 简单的基于JSON的身份令牌（identity tokens） —— JWT，JWT简单而具有可移植性（自我验证），支持大量签名算法、加密算法
2. 衍生自OAuth 2.0的工作流，对Web应用、基于Web的/原生的移动应用友好

OpenID Connect是2014年发布的标准，它不是IdP的第一个标准，但是却是最简单、好用的。

应用程序通常都需要识别（identify）其用户，简单的方式是，使用本地数据库，存储用户账户、凭证信息。这种方式的缺点是：

1. 注册、登陆很繁琐，导致用户反感
2. 具有很多应用的企业，维护多套用户信息很痛苦

解决方案就是引入独立的认证服务器，将身份验证（authentication）、用户创建（provisioning）的任务交给它统一处理。此认证服务器叫做Identity Provider（IdP）。

Github、Google、Wechat等互联网服务，都扮演IdP的身份。你的应用可以直接与之集成，有它们提供登陆功能。

除了用于单点登陆之外，ID Token还可以用于：

1. 无状态会话：将ID Token放入Cookie，可以实现简单的轻量级stateless session，而不需要服务器端记录任何信息。服务器通过检查ID Token校验会话有效性
2. 将身份信息传递给第三方应用
3. Token exchange：在那些需要出示你的身份，以获得访问的场景。例如在酒店Check in的时候获取房间钥匙

代表一个身份，标准的JWT格式，被OpenID Provider（OP）签名。

为了获得ID Token，第三方应用必须将终端用户导向（OP）提供的界面，进行身份验证操作，类似OAuth那样。

ID Token中包含以下字段：

1. 对用户身份的断言，用户身份在OpenID中叫做subject，也叫sub
2. 颁发此Token的权威机构（就是OP），issuing authority，也叫iss
3. 是否此Token仅限于特定应用（客户端）使用，audience，也叫aud
4. 可以包含一个nonce
5. 颁发时间iat、过期时间（exp）
6. 可以包含请求的关于subject的额外信息，例如名字、电子邮件地址
7. 签名信息
8. 可以加密

这些字段，也叫statements / claims，打包在JSON中：

ID Token头部 + claims JSON + 签名，被一起Base64编码，便于基于HTTP进行传递。 

第三方应用（客户端，Relying Party，RP）要获取ID Token，必须通过IdP，在IdP那里，终端用户的会话/凭证被检查。为了将终端用户引导到IdP那里，需要一个可靠的User Agent，这个角色通常由浏览器扮演：

1. 对于Web应用，可能是弹出对话框，在此对话框中重定向到IdP
2. 对于Native应用，客户端可能需要启动系统浏览器，因为内嵌的Web view不被信任（防止Native应用嗅探密码）

OIDC标准没有指定用户身份以何种方式确认，这完全由IdP自由决定，最简单的方式是基于口令。

请求ID Token的流程，遵循OAuth 2.0协议。可以使用：

1. 授权码模式：最常使用，兼容传统Web应用、原生应用、移动应用。最安全，因为浏览器/第三方客户端不会看到ID Token。流程概要：
   1. 浏览器到OP、从OP重定向回来，实现身份校验，得到授权码
   2. 第三方应用的后台，使用授权码再次请求OP，获得ID token
2. 简单模式：用于纯粹的JS应用，没有后端服务的那种。ID Token直接从OP的重定向中返回给客户端
3. 混合模式：很少使用，1+2组合

本节的后续内容，以授权码模式为例，阐述获取ID Token的完整流程。

本步骤的目的：

1. 确认最终用户的身份

实现方式：前端请求，浏览器重定向，请求Authorisation Endpoint。获得授权码

首先，RP触发浏览器重定向，重定向到OP的Authorisation Endpoint：

在OP的页面上，通常会：

1. 检查用户是否具有合法的session
2. 如果没有，则进入登陆页面，提示用户登陆
3. 登陆成功后，OP通常会询问用户，是否同意登陆到RP 

随后，OP会调用/login时指定的redirect_uri，在URL中提供授权码。如果失败（登陆失败、不同意登陆到RP、回调地址不正确等）则附带一个错误码：

RP必须校验state，确保和之前的/login请求指定的一致。 

本步骤的目的：

1. 确认第三方应用（客户端）的身份，可选
2. 获取ID Token 

实现方式：后端请求，第三方应用的后端服务器直接访问OP。获得ID Token（+ OAuth 2.0访问令牌）。

上一步骤中，OP将授权码发给RP，发送的方式是浏览器重定向。这时候，RP前端会将授权码传给后端，由后端请求RP获得ID Token。这种做法的意义是：

1. 获取ID Token之前，OP有机会校验RP的身份
2. 后端获得ID Token后不会返回给前端（不可靠），不会造成敏感信息泄漏

RP后端将发起下面的请求：

如果成功，OP将会返回一个JSON对象： 

其中id_token字段是Base64编码的JWT，包含claims、签名等信息。RP必须进行必要的校验。

OIDC规范提供了一系列标准的Claims（也就是用户属性）。 Claims提供用户的各种详细信息，例如电子邮件、头像。客户端要获取Claims，有两种方式。

第一种方式是，在/login请求的scope中，根据Claims所属的scope来获取。例如：

 所有Scope和Claims对应关系如下表：

Scope	关联的Claims
email	email, email_verified
phone	phone_number, phone_number_verified
profile	name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at
address	address

第二种方式是，单独使用claims参数。

dexidp/dex是一个开源项目，它是OIDC Provider、OAuth 2.0 Provider。支持可拔插的Connector。

作为身份验证服务，dex实现了框架部分，并且可以通过Connector适配到其它identity providers，这样，用户密码等信息就可以由LDAP服务器、SAML provider、AD之类的服务提供。

在前文中，我们了解到ID Tokens是OIDC对OAuth 2的扩展。ID Tokens是OAuth 2响应的一部分。它的格式是JWT，dex负责签名JWT，ID Tokens包含了标准的claims。

包括Kubernetes在内的第三方系统，都可以使用dex产生的ID Tokens。

dex在生产环境中的一个应用是，作为CoreOS的K8S解决方案，Tectonic的Authn加载项。

当用户通过dex进行登陆时，用户的身份信息通常存放在第三方用户管理系统中，例如LDAP。Dex作为客户端和第三方用户管理系统之间的垫片，其价值是，客户端仅仅需要理解OIDC，后端用户管理系统可以随时切换。

Connector是Dex联系第三方系统进行用户身份验证的策略接口，取决于这些第三方系统的特性，OIDC的某些功能可能无法支持。

Dex从一个配置文件中提取所有配置信息，阳历配置如下： 

执行下面的命令启动Dex服务：

Dex的工作方式类似于其他OAuth 2 Provider，用户被从客户端应用重定向到Dex，进行登陆。

Dex提供了一个示例客户端：  ./bin/example-app ，这是一个Web应用，你可以打开浏览器：

1. 打开http://localhost:5555/，进入此Web应用
2. 点击登陆按钮，重定向到Dex
3. 选择Login with Email，输入admin@example.com" 和 "password"进行登陆
4. 允许Web应用的登陆请求
5. 你可以在Web应用页面看到Token

应用程序和Dex的交互，可以分为两类：

1. 请求ODIC的ID Tokens，来认证最终用户的身份，必须基于Web进行
2. 从其它应用消费ID Token，需要验证客户端是代表用户进行操作 

客户端应该在初始化阶段，创建provider等对象：

这类用法中，应用是标准的OAuth2客户端。用户打开应用页面，应用期望知道用户的身份，做法就是导向Dex进行身份校验，然后检查得到的ID Token中的claims。

第一步，你需要将应用注册到Dex，最简单的方法是使用staticClients配置：

在登陆时，应用需要拼接合理的URL，重定向到Dex：

用户在Dex页面执行操作后， 应用需要处理Dex发回的回调：

这类用法中，应用将ID Token作为凭证使用。一个第三方的服务负责处理OAuth流程， 典型的例子是K8S的OpenID Connect Token支持。你可以将ID Token作为K8S API请求的bearer token使用，K8S负责通过数字证书校验此Token的合法性。

消费ID Token，就是去校验它的有效性。你需要创建一个校验器：

然后，校验ID Token，并从中读取可信任的claims： 

Scope	说明
openid	对于所有登陆请求必须
email email_verified	Dex扩展，非标准 ID Token claims应当包含终端用户的电子邮件信息、电子邮件是否被上游Provider验证过
profile	ID Token claims应当包含用户名
groups	Dex扩展，非标准 ID Token claims应当包含用户所属的组
federated:id	Dex扩展，非标准 ID token claims应当包含来自真实IdP的信息，包括connector ID、在IdP中用户的ID
name	Dex扩展，非标准 用户的显示名称
offline_access	Token响应中，应该包含一个刷新Token。对于某些Connector是不支持的，例如SAML，会忽略此scope
audience:server:client_id:( client-id )	动态的Scope，提示Dex，当前验证请求，是代表其它客户端（不是当前客户端）来获取ID Token

Dex支持向这样的客户端颁发ID Token：该客户是代表另外一个客户端来请求Token的。

在OIDC的术语中，这种情况意味着ID Token的aud（audience） claim，不是发起请求的那个客户端的client ID。

利用这个特性，一个Web应用可以代表一个命令行工具，来申请ID Token：

Web应用发起/auth请求时，可以设置下面的Scope，表示自己在代表命令行应用： audience:server:client_id:cli-app  

Dex返回的ID Token中，会包含如下字段：

可以将客户端标记为公共的：

则给应用强加了一个限制：不要尝试将Client Secret作为私有的。

对于公共客户端，它发起请求时指定的回调URL，必须以http://localhost开头，或者指定为一个特殊的out-of-browser地址 urn:ietf:wg:oauth:2.0:oob 。

out-of-browser会导致dex在浏览器中显示OAuth2 code，提示终端用户手工拷贝给其它APP。

Dex需要存储一些状态信息，以支持：跟踪刷新Token、防止replay、进行key轮换。 

如果在K8S中运行Dex，考虑这种方式。Dex会创建若干类型的CRD，并在CR中存储状态。配置：