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的时候一同介绍.