学习Identity Server 4的预备知识 (误删, 重补)

我要使用asp.net core 2.0 web api 搭建一个基础框架并当即应用于一个实际的项目中去.

这里须要使用identity server 4 作单点登录.

下面就简单学习一下相关的预备知识.

基于Token的安全验证体系

这个比较简单, 简单来讲就是为了证实咱们有访问权限, 咱们首先须要得到一个token.

什么是token? 好比说: 能够访问某些大楼的门禁卡就是一种token, 回家开门的钥匙也是一种token.

为了获取到token, 首先你须要验证你的身份, 以证实你确实有权利得到token. 好比说, 你能够亮出身份证来证实本身, 或者使用密码.

好比说你想访问个人办公室, 你首先去安所有门亮出身份证, 而后安全办公室给你一个token, 而后使用这个token你就能够进入办公室去干事了.

使用基于token的安全体系有什么优势?

若是不使用token, 你可能须要处处使用密码来证实身份. 这样的话, 那每一个地方都会知道你的密码了.

若是token丢失了, 咱们能够吊销token.

而且token都有必定的时效性. 过时做废

总之, 使用这种方式, 你能够只在一个地方使用密码, 别的地方不会知道你的密码.

交换凭证获取token并使用token

有一个已注册用户, 她为了获取token, 就须要与authorization server进行通讯. 这个authorization server负责发放token, 而且确保token是否仍然有效. 它同时也负责跟踪用户的用户名和密码. 而这个authorization server能够存在于世界的任何地方, 它并非非得和咱们的web api或者网站放在一块儿. 它彻底是一个独立的系统, 跟踪着用户的用户名密码以及用户的访问权限.

这里这个用户就向authorization server提供了用户名和密码, 而后她就得到了token. 而后她就可使用这个token作一些事情了, 好比使用token访问api请求全部的订单信息, 这时api就会知道这个token是有效的.

甚至, 用户使用token能够访问第三方服务, 第三方服务再使用这个token来访问咱们的api.

向第三方服务提供token确定比提供用户名密码安全多了.

要把Token向密码同样对待

保护好token, 由于别人得到token后将会和你拥有同样的权限.

token是有时效性的, 具体有效期是多久是由authorization server决定的.

token是能够吊销的, 你能够告诉authorization server注销你的token, 可是要注意的是, 是由api决定是否向authorization server查询token的有效性, 若是你吊销token或api没有向authorization server进行查询, 那么你的token对api来讲依然有效.

如何保证token的安全

如图, 用户带着token向api发出请求, token是附带在header中, api收到请求后会返回一些数据.

若是有人查看了这个token, 并要篡改token里面的数据, 那可就很差了

那么如何保证token不被篡改呢? 这个工做是由api来作的, 它要确保没人篡改过token.

在基于token验证的情景中, 全部从authorization server获取的token都是使用一个private key签过名的. token包括一些信息: 用户自己(email, 权限等等), 也可能包括是谁发布了token.

任何一个服务想肯定没人篡改过token, 就须要使用public key.

private key 能够用于锁定 token.

针对token和它带的数据以及在token尾部的签名信息, 只要没人篡改数据, 那么token的签名就是必定的.

authorization server提供的public key是任何人均可以访问的, public key是用来确保没人篡改过数据.

Token

若是在api里面验证了token的完整性, 那么咱们就会知道token是ok的.

咱们这里研究的token是Json Web Token.

token是由authorization server签名发布的.

authorization server就是使用oauth和openid connect等协议, 而且用户可使用用户名密码等方式来换取token的服务, 这些token让咱们拥有了访问一些资源的权限.

private key 是用来签发token用的, 它只存在于authorization server, 永远不要让别人知道private key.

public key 是用来验证token的, authorization server 会让全部人都知道这个public key的.

api或者各类消费者应该一直检验token, 以确保它们没有被篡改. 它们能够向authorization server申请public key, 并使用它来验证token. 也能够把token传递给authorization server, 并让authorization server来进行验证.

Token同时也包含着authorization server的一些信息. 好比是由哪一个authorization server发布的token.

Token的信息是使用Base64编码的.

OAuth 和 OpenId Connect

他们都是安全协议.

如今使用的都是OAuth 2.0, 注意它与1.0不兼容.

OAuth 2.0是用于authorization的工业标准协议. 它关注的是为web应用, 桌面应用, 移动应用等提供特定的authorization流程并保证开发的简单性.

Authorization的意思是受权, 它表示咱们能够受权给某些用户, 以便他们能访问一些数据, 也就是提供访问权.

OAuth是基于token的协议.

有些人可能对Authorization和Authentication分不清, 上面讲了authorization, 而authentication则是证实我是谁, 例如使用用户名和密码进行登陆就是authentication.

OAuth只负责Authorization. 那么谁来负责Authentication呢?

那就是OpenId Connect, OpenId Connect是对OAuth的一种补充, 由于它能进行Authentication.

OpenId Connect 是位于OAuth 2.0上的一个简单的验证层, 它容许客户端使用authorization server的authentication操做来验证终端用户的身份, 同时也能够或缺终端客户的一些基本信息.

能够有多种方式来实现OAuth和OpenId Connect这套协议.

你能够本身去实现. 

我要使用的是Identity Server 4.

其实也可使用一些Saas/Paas服务, 例如Amazon Cognito, Auth0(这个用过, 有免费版), Stormpath.

OAuth 2.0 RFC 6794

想研究的比较透彻的话, 仍是要多读几遍 RC 6749文档: https://tools.ietf.org/html/rfc6749

OAuth一般有如下几种endpoint:

1. /authorize, 请求token(经过特定的流程flows)

2. /token, 请求token(经过特定的流程flows), 刷新token, 使用authorization code来换取token.

3. /revocation, 吊销token.

OpenId Connect 一般有如下几种 endpoints:

1. /userinfo, 获取用户信息

2. /checksession, 检查当前用户的session

3. /endsession, 终结当前用户的session

4. /.well-known/openid-configuration, 提供了authorization server的信息(endpoints列表和配置信息等)

5. /.well-known/jwks, 列出了JWT签名key的信息, 它们是用来验证token的.

获取Token的例子:

使用postman大约是这样发送请求.

请求返回的结果大约是这样的:

access_token就是token, expires_in是有效时间, 类型是 Bearer.

能够到jwt.io去解析token: http://jwt.io/

因为网络问题, 我今天没法使用这个网站.....之后作项目写文章的时候再介绍. 这里你能够试试把一个token的数据更改以后, token验证就出错了. 

下面这个图是如何使用token访问api:

Access Token (JWT)

红色的是Header, 橘色的是Payload, 蓝色的是签名Signature. 它们是用.分开的

Signature主要是来保证Payload的完整性. Header包含了token的结构信息.

Payload有时候也叫作Claims, 它一般包括发布者issuer(authorization server), Audience, 有效期, 有时也包括token应该是从何时开始有效, Client ID(这是那些注册于authorization server的应用), Scopes(限定访问的范围), 自定义数据.

Scopes

scopes能够限定访问的范围.

OpenId Connect为咱们指定了一些 Scopes, 包括: openid, profile, email, address, offline_access等等.

固然也能够自定义scope.

选择一个流程 Flow

Redirect Flows, 它能够这样解释: 有一个用户想要访问个人网站, 我想让他登陆, 但又不想让他把用户名和密码提供给我, 由于我没有用户的信息. 用户的信息都在authorization server上了. 因此我把用户重定向到authorization server, 提供他们的用户名和密码, 而后重定向返回到个人网站, 获取了token, 这时我就知道他们已经登陆好了.

 

Redirect Flows又分两种: 1 Implicit Grant(就是上面说的那个), 2 Authorization Code(它并无返回token, 而是返回了authorization code, 而网站可使用authorization code来换取token).

因此implicit grant适合于javascript客户端, 而其余应用更适合使用authorization code, 这些应用可使用authorization code刷新token.

Credential Flows: 1.Resource Owner Password Credentials(用户名密码). 2. Client Credentials(例如适用于没有用户参与的状况).