Identity Server 4 预备知识 -- OAuth 2.0 简介

OAuth 2.0 简介

OAuth有一些定义:

OAuth 2.0是一个委托协议, 它可以让那些控制资源的人允许某个应用以代表他们来访问他们控制的资源, 注意是代表这些人, 而不是假冒或模仿这些人. 这个应用从资源的所有者那里获得到授权(Authorization)和access token, 随后就可以使用这个access token来访问资源.

(这里提到的假冒或模仿就是指在客户端复制一份用户名和密码，从而获取相应的权限)。

OAuth 2.0是一个开放的协议, 它允许使用简单和标准的方法从Web, 移动或桌面应用来进行安全的授权(Authorization).

从这些定义可以看出来, OAuth2 是关于授权(Authorization)的,  客户端应用可以请求access token, 使用这个token就可以访问API资源了.

因为有很多种类客户端应用的存在, 例如ASP.NET Core MVC, Angular, WPF 等等, 它们都是不同的应用类型, 所以, OAuth2 定义了不同类型的客户端应用应该如何安全的完成授权. OAuth2标准还定义了一些端点, 并且定义了针对不同类型的客户端应用如何使用这些端点.

Identity Server 4 和 Azure AD 都实现了OAuth 2.0 标准.

但是上面提到的access token只能用来访问资源, 它无法被用来登录客户端应用. 登录这种操作叫做认证/身份验证(Authentication), 而OpenID Connect则可以完成这项工作.

OpenID Connect 简介

OpenID Connect是建立在OAuth2协议上的一个简单的身份标识层, 所以OpenID Connect兼容OAuth2.

使用OpenID Connect, 客户端应用可以请求一个叫identity token的token, 它会和access token一同返回给客户端应用. 这个identity token就可以被用来登录客户端应用程序, 而这个客户端应用还可以使用access token来访问API资源.

OpenID Connect还定义了一个UserInfo端点, (OAuth2定义了Authorization端点和Token端点)它允许客户端应用获取用户的额外信息.

此外它还定义了不同类型的应用如何从身份识别提供商(IDP)安全的获取这些token.

综上, OpenID Connect是更高级的协议, 它扩展并替代了OAuth2. 尽管现在我们经常说我们在使用OAuth2来保护API, 其实更准确的说, 大多数情况下, 我们使用的是OpenID Connect.

如果到现在还是不明白OAuth2和OpenID Connect也没关系, 这不是几句话就能描述清楚的东西. 本文我进一步介绍OAuth 2.0.

OAuth 2.0 进一步介绍

OAuth2的目标就是让客户端应用可以代表资源所有者(通常是用户)来访问被保护的资源:

• 这里的资源所有者(Resource Owner), 他拥有访问API资源的权限, 并且他还可以委派权限(delegate)给其他应用来访问API. 资源所有者通常是可以使用浏览器的人.
• 被保护的资源(Protected Resource)就是资源所有者拥有权限去访问的组件, 它可以是很多种形式的, 但是web API的形式还是最常见的.
• 客户端(Client)应用就是代表资源所有者访问被保护资源的一个软件. 注意它既不是指浏览器, 也不是指给你钱让你开发软件的人. 在OAuth2里面, 它是指被保护的API资源的消费者.

委拖/委派权限

前面提到OAuth2里面, 最终用户可以委派他的一部分权限给客户端应用来代表最终用户来访问被保护的资源. 但是要完成这件事, 还需要一个桥梁来连接客户端应用和被保护资源. 这个组件叫做授权服务器(Authorization Server, AS). 这个授权服务器也许就是资源服务器, 但是大多数情况下它们是不同的服务器.

授权服务器(AS)是被受保护的资源所信任的, 它可以发行具有特定目的的安全凭据给客户端应用, 这个凭据叫做OAuth的 access token.

想要获得access token, 客户端应用首先要把资源所有者发送给授权服务器

首先客户端需要获得权限, 它可能有两种方式来获得权限: 可以从资源所有者那里直接获得权限, 也可以让授权服务器作为中介, 从授权服务器那里间接的获得权限. (上面这个图中描述的是从资源授权者直接获得权限的流程).

如果使用授权服务器作为中介的话, 客户端需要把资源所有者发送到授权服务器(可以理解为最终用户使用的浏览器被重定向到了授权服务器), 然后资源所有者在这可以对客户端应用进行授权.

这时资源所有者要通过身份认证进入授权服务器, 通常还会有一个是否同意授权客户端应用请求的选项, 点击同意后就授权了. 而从客户端应用的角度讲呢, 它可以向资源所有者请求他一部分的功能和范围(scope), 在将来, 资源所有者可能会逐渐减少它所拥有的功能和范围.

到这里, 上面写的这个动作/东西叫做授权(authorization grant).

一旦执行了授权动作也就是客户端得到了授权(这个授权是一个可以代表资源所有者权限的凭据), 客户端便可以从授权服务器请求access token了. 这个access token就可以被用来访问被保护的资源了.

下图是使用授权服务器作为中介的流程图, 除了授权, 其它部分和上图表达的都是一个意思:

授权 Authorization Grant

授权 (authorization grant) 是一个代表着资源所有者权限的凭据, 它可以被客户端应用来获取access token. OAuth2里面定义了4种类型的授权, 分别是: auhtorization code, implicit, resource owner password credentials, client credentials. OAuth2还定义了一个扩展机制以便定义其它的授权类型.

用一句话描述就是, 授权(Authorization Grant)就是获取token的方法.

1. Authorization Code

Authorization Code是使用授权服务器作为客户端和资源所有者的中介来获取的. 所以这里不是采用直接从资源所有者获得授权的方式, 而是采用授权服务器作为中介的方式. 在授权服务器把资源所有者送回到(重定向)客户端的时候带着这个临时的凭据: authorization code (我暂时叫它授权码吧), 它就代表着资源所有者委托给客户端应用的权限.

Authorization code在安全方面有一些重要的优点: 可以对客户端应用进行身份认证; access token是直接发送到客户端应用的, 不经过资源所有者的浏览器, 所以不会暴露access token给外界, 包括资源所有者.

2. Implicit

Implicit, 我叫它隐式授权吧. 它是Authorization Code的一个简化版本, 它针对浏览器内的客户端应用(例如js, angular的应用)进行了优化. 在implicit流程里, 没有给客户端发送授权码(authorization code), 而是直接给它发送了access token. 之所以叫这种授权类型implicit, 是因为流程里并没有发行任何中间凭据.

在implicit流程里发行access token的时候, 授权服务器并没有对客户端应用进行身份认证. 某些情况下, 客户端的身份可以通过带着access token重定向回客户端的URI来验证. acces token可能会暴露给任何使用该浏览器的人或者应用.

Implicit授权确实可以提高浏览器内应用的响应性和效率, 毕竟它减少了来回往返的次数. 但是方便可能会带来风险, 建议如果可以的话尽量使用Authorization Code, 当然这个需要自己去权衡.

3. Resource Owner Password Credentials

Resource Owner Password Credentials, 资源所有者密码凭据. 顾名思义, 可以直接使用密码凭据(用户名和密码)作为授权来获得access token. 只有当资源所有者和客户端之间高度信任的时候并且其它授权方式不可用的时候才可以使用这种授权方式.

这里资源所有者的凭据只应该用于一次请求并用于交换access token. 这种授权方式可以让客户端免于存储资源所有者的凭据(如果以后还需要使用的话), 通过交换一个长期有效的access token或refresh token都可以达到这种效果.

4. Client Credentials

Client Credentials. 有时候, 资源或者叫资源服务器并不属于某个最终用户, 也就是没有资源所有者对该资源负责. 但是客户端应用肯定还是要访问这些资源, 这时候就只能使用Client Credentials这种授权方式了.

OAuth 2.0 的角色和组件

OAuth2的4个角色前面已经介绍过, 分别是: 资源所有者 Resource Owner, 客户端 Client, 被保护资源 Protected Resource, 和 授权服务器 Authorization Server.

而OAuth2的组件, 前面也都有提到过, 它们是: Access Token, Refresh Token 和 Scope (范围).

下面简单介绍下这几个组件.

Access Token: 有时候只被叫做token, 它是用来访问被保护资源的凭据. 它是一个字符串, 它代表了给客户颁发的授权, 也就是委托给客户的权限. OAuth2本身并没有对access token的格式或内容进行定义. 但是access token里面要描述出资源所有者授予的访问权限的范围和持续时间.

Access Token 通常对客户端应用是不透明的, 也就是说客户端无需去查看access token. 客户端的任务就是把它展示给被保护的资源. 其实access token在整个OAuth2系统里对任何角色都是不透明的, 授权服务器的任务只是发行token, 而被保护资源的任务是验证token. 但是它们都必须理解access token的构成, 并知道access token代表了什么. 而客户端对于access token应该是完全健忘的.

Scopes: OAuth2的scope表示被保护资源那里的一套权限. 在OAuth2里面, scope用区分大小写的字符串表示, 可以用空格作为分隔符来表示多个scope. 这些字符串由授权服务器来定义. 而scope字符串的格式和结构在OAuth2里并没有定义.

Scope对于限制客户端应用的访问权限有很重要的作用. 客户端应用可以请求一些scopes, 而授权服务器可以允许资源所有者授权或者拒绝特定的scopes. Scope还具有叠加性.

Refresh Token: Refresh Token是用来获得Access Token的凭据. 和acces token差不多, refresh token也是由授权服务器发行给客户端应用的, 客户端不知道也不关心refresh token里面有啥. 但与access token不同的是, refresh token不会被发送给被保护的资源. 客户端是用refresh token来请求新的access token (尤其是当现在的access token过期或者失效时), 但这个过程就不需要资源所有者的参与了. Refresh Token是可选的, 授权服务器会酌情发行refresh token, 如果需要的话, refresh token是在发行access token一同返回的.

此外refresh token还具备让客户端应用逐渐降低访问权限的能力.

通过refresh token来取得新的access token的流程如下:

另外一张彩色图:

这张彩图的中文意思是: 客户端使用当前access token访问被保护资源的时候, access token失效或者过期了, 这是从被保护资源返回了一个错误响应; 然后客户端使用refresh token向授权服务器请求了一个新的access token; 得到新的access token后, 客户端使用新的access token请求被保护资源, 这时资源就可以被正常的返回给客户端了.

OAuth 2.0的端点

OAuth2定义了一套端点(Endpoint), 端点就是web服务器的一个访问路径URI.

OAuth2定义的端点有授权端点, Token端点, 它们都在授权服务器上.

OAuth2没有定义这些端点URI应该如何被发现和文档的结构.

授权端点(authorization endpoint)是用来和资源所有者交互的, 资源所有者在这里进行登录(身份认证), 然后通过该端点可以对客户端进行授权(authorization grant). 授权服务器首先要验证资源所有者的身份, 但是验证的方式并不在OAuth2的协议范围内.

Token端点(token endpoint), 客户端通过向token端点展示它的授权(auhtorization grant)或refresh token来获取access token. 除了implicit之外所有的授权类型都需要使用该端点, 因为implicit的access token是直接发行的.

本篇文章先到这. 下篇文章再简单介绍一下OpenId Connect.

那四种授权类型具体的详细流程将在介绍Identity Server 4的时候一同介绍.