身份认证与授权

OAuth2.0

OAuth2.0 是一种授权协议。在这个协议中有四个参与方，资源拥有者（resource owner）、资源服务器（resource server）、鉴权服务器（authorization server）、客户端应用程序（client application），客户端程序向鉴权服务器请求获取资源访问权限凭据，鉴权服务器协调资源拥有者向该客户端授权，并负责鉴定受权客户端后续对资源访问的范围有效性、时间有效性，资源服务器主要协调鉴权和响应客户端对其的访问请求，协调鉴权主要是转达客户端所访问资源范围以及所提供的权限凭据给鉴权服务器，由鉴权服务器判断该凭据是否有效。

身份认证与授权场景示例：我们做了一个小游戏程序，为让玩家在平台能跟更多朋友互动，准备接入玩家的微信、微博或推特等社交平台好友，并且社交平台支持对外提供信息访问，此时我们需要获得玩家的许可让游戏程序访问玩家的在该社交平台上的好友信息，因此我们在游戏界面上提供一个“我要接入好友”按钮的类似入口，由用户点击之后调用社交平台鉴权服务器的身份认证与授权服务，跳转到社交平台提供的用户登录界面（一般会提示用户是哪个客户端，在这里是游戏程序，准备申请的哪些信息范围，在这里是好友信息），用户登录社交账号确认授权后跳转到游戏程序界面，该跳转携带了社交平台提供的授权码，游戏程序根据获得授权码向好友信息资源服务器发起访问请求，并提供授权码，资源服务器向社交平台鉴权服务器询问该授权码是否符合策略，若是则返回游戏程序所请求的好友信息资源，若不是则告知其无权限（或是授权码错误或是过期等）。这里游戏程序是客户端应用程序（client application），玩家是资源拥有者（resource owner），社交平台提供登录授权以及验证资源服务器转达游戏程序授权码有效性的服务是鉴权服务器，提供好友信息的服务是资源服务器。

另外的例子是某些程序或网站在登录页面时提供的“使用某某登录”，如用微信、微博登录等，道理相似，其资源变成了用户的基本信息，如最基本的身份识别码（ID）、或头像、性别、电话等，然后将其微信/微博ID与自身程序网站内的ID进行绑定，省去了用户在程序网站内需要再次输入ID密码的繁琐。

在上述例子中，鉴权服务器和资源服务器似乎没有完全分开，都在一个平台内，其原因是，从数据隔离性角度看， 鉴权服务有用户标识和授权记录信息，没有“资源”（如好友、朋友圈动态）数据，因此视为分开的服务器，从现实角度看，在市场上，一个鉴权平台被大家所支持（愿意提供入口让用户用其登录）往往或是为用户提供登录便捷性或是想要用户的数据价值。对于数据价值，一般是先出现一个面向数据的内容平台积累了大量用户，然后才提供鉴权服务器，而不是先出现一个中立机构做鉴权服务器，然后大量数据内容平台机构（资源服务器）去支持它；对于便捷性，是针对被大量用户使用的平台，大量用户的积累往往也来源于数据运营。因此，在市场上常常出现鉴权服务器和资源服务器在同一个机构的情况。

术语 Terminology

authorization： 授权，赋予指定目标指定权限的过程。

authentication：鉴权，验证资源访问者是否有权限访问或其提供的访问权限凭据是否有效的过程。

resource owner：资源拥有者，是授权过程中客户端应用程序想要访问的资源的拥有者（权属人）。

scope: 资源的类别、范畴，或客户端请求访问资源的范畴。

role: 资源拥有者的角色，用于基于角色的访问控制（role based access control, RBAC）。

client：即client application，指准备访问资源的应用程序。

resource owner：资源拥有者，一般是生成资源的人，在授权过程中也一般是client的使用者（users）。

resource server：提供资源访问的程序。

authorization server：鉴权服务器，协调client、resource owner(i.e. user)和resource server。

permission：权限，一种可被允许访问范围的抽象，根据权限模型具象。

session, sso session, client session：一般一个session是指一个围绕某个用户目标展开的连续活动过程，不需要该目标显式操作干预。如client session是用户授权后该client不再需要用户操作就可以其名义进行相关接口调用的过程，session过期后需要用户再次显式操作允许。

access token：用于访问资源时提供的权限凭据。

refresh token：根据鉴权服务器策略而存在，要求客户端周期性获取新的访问凭据，而获取新凭据的过程也需要提供凭据，后者即是refresh token。

OpenID Connect, OIDC

OIDC是一种身份认证与授权协议，授权高度依赖于OAuth2.

Client Types

两种类型：confidential, public.

支持confidential的机制，鉴权服务器为客户端颁发client_secret，该码被认为应当仅被client拥有者所知晓，其与client_id形成authorization_code授权方式的关键要素之二。

四种授权方式（grant_type）：

授权码(authorization code)、密码（password）、隐式（implicit type）、客户端凭证（client credentials）。

授权流程在服务器端的处理地址一般分为authorization endpoint和token endpoint，前者提供与用户登录授权相关的处理，后者提供token数据处理。

授权码方式

授权码方式是oauth2四种授权方式中最安全也最常用的。

授权码形式的过程：（1）获得code；（2）根据code获取access_token；（3）视情况刷新token。

时序图如下

（1）获取授权码code调用参数：

• grant_type=authorization_code，grant_type固定为authorization_code。
• client_id，标识客户端应用。
• response_type=code，参数固定为code表示进行authorization code flow阶段，服务器返回授权码。
• scope，准备访问的资源范畴，需要提前了解资源服务器有哪些范畴。
• redirect_uri，授权结束后的处理界面，相当于回调程序，这是因为授权一般由用户通过界面完成，授权结束后应当自动地进入下一步（通过回调程序实现自动），为了安全，该地址一般是注册制的，需先在鉴权平台上申报。

鉴权服务器响应授权码获取的可接受conntent-type一般为form而非json，且获取授权码客户端请求者一般是网页浏览器而非后台程序，因为鉴权服务器在响应授权码前需要资源拥有者（用户）登录知晓客户端应用的对其资源的请求并决定授权，这一过程一般由网页浏览器完成。

鉴权服务器返回的code一般被置于redirect_uri新增的参数中，新生成带有code的url被放在用于自动重定向的HTTP响应头中。

（2）获取访问凭据access_token调用参数：

• grant_type=authorization_code，参数固定，表示该调用属于授权阶段。
• client_id，标识客户端应用。
• client_secret，针对confidential类型的client。
• code，上一过程鉴权服务器返回的code。
• redirect_uri，该过程后的重定向地址，相当于回调程序。

响应返回：鉴权服务器返回access_token，根据鉴权平台策略，可能返回refresh_token，相关token存在时效。

如果鉴权服务器设置了凭据刷新机制，则需在刷新凭据（refresh token）过期前（事实上为了保证有权访问一般是在acess_token过期前）换取新的访问凭据access token和下次刷新凭据refresh token。

（3）刷新凭据refresh token：

• grant_type=refresh_token，参数固定，表示该调用属于刷新凭据。
• client_id，标识客户端应用。
• client_secret，针对confidential类型的client。
• refresh_token，用于表明本次调用是受权合规的，参数值来源于此前调用中服务器返回的信息。

响应返回：一般返回新的access_token和refresh_token。

隐式授权（implicit）

隐式授权在用户授权后直接返回访问凭据（access token），不像authorization code flow那样在用户操作授权后需要再次进行access token获取，在implicit flow中仅有向用户请求授权的过程，因此客户端信息仅需可公开的client id，无需私密的client secret。

请求参数：

• client_id，标识客户端应用。
• scope，准备访问的资源范畴。
• response_type=token，参数固定，表示implicit flow。
• redirect_uri，该过程后的重定向地址，相当于回调程序。

不需要client secret、grant type。

密码授权（password）

允许客户端携带用户的账号和密码获取访问凭据，较少用，用户得相当信任该客户端才可能告知其账户密码信息。

• grant_type=password，参数固定，表示密码方式授权。
• client_id，标识客户端应用。
• client_secret，针对confidential类型的client。
• username，账号。
• password，账户密码。
• scope，准备访问的资源范畴。

客户端凭据方式（client credentials）

grant_type参数固定为client_credentials，提供client_id, client_secret, scope信息，鉴权服务器返回访问凭据。

References:

• Client Types: https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-client-applications
• 授权code（authorization code flow）时序过程 https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow
• 微软oauth2案例 https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow