OAuth二、OpenID Connect简介

当咱们在登陆一些网站的时候，须要第三方的登陆。好比，如今咱们要登陆简书https://www.jianshu.com/sign_in，咱们使用微博登陆，点击下方的一个微博的小按钮，就会出现这么一个地址https://api.weibo.com/oauth2/authorize?client_id=1881139527&redirect_uri=http%3A%2F%2Fwww.jianshu.com%2Fusers%2Fauth%2Fweibo%2Fcallback&response_type=code&state=%257B%257D。乍一看，这是什么玩意啊。咱们来分解下：

https://api.weibo.com/oauth2/authorize?
client_id=1881139527&
redirect_uri=http%3A%2F%2Fwww.jianshu.com%2Fusers%2Fauth%2Fweibo%2Fcallback&
response_type=code&
state=%257B%257D

如今就要引出今天的主角了，OAuth2

那什么是OAuth2呢？

https://oauth.net/2/这是官网

https://open.weibo.com/wiki/受权机制，这是微博的受权机制

http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html，这是阮一峰老师写的一篇对于OAuth2的介绍。

OAuth2.0是一个委托协议，它可用让那些控制资源的人容许某个应用表明这些人，而不是假冒和模仿这喜人，这个应用从资源的全部者哪里获得受权（Authentication）和Access Token，随后就可使用这个Access Token来访问资源。（这里提到的假冒和模仿就是指在客户端复制一份用户名和密码，从而获取响应的权限）。是关于受权（Authentication）的，客户端应用能够请求Access Token，使用Tooken就能够访问API资源了。在上述的例子中，是微博给简书受权。

让客户端应用能够表明资源全部者（一般是用户）来访问被保护的资源，以下图：

 

 

 资源全部者（Resource Owner），他拥有访问API资源的权限，而且他还能够委派权限（delegate）给其余应用来访问API。资源全部者一般是可使用浏览器的人。

被保护的资源（Protected Resource）就是资源全部者拥有权限去访问的组件，它能够是不少种形式的，可是WebApi的形式仍是最多见的。

客户端（Client）应用就是表明资源全部者访问被保护资源的一个软件，注意它既不是浏览器，也不是给你钱让你开发软件的人，在OAuth2里面，它是指被保护的API资源的消费者。

受权服务器（AS）是被受保护的资源所信任的，它能够发行具备特定目的的安全凭据给客户端应用，这个凭据就叫作OAuth的Access Token。

 

 

 受权，以下图

 

 

 受权种类：

　　一、Authentication Code

　　二、Implicit

　　三、Resource Owner Password Credentials，直接使用密码凭据（用户名和密码）做为受权来得到Access Token，只有当资源全部者和客户端之间高度新人的时候而且其它受权方式不可用的时候才可使用这种受权方式。

　　四、Client Credentials，有时候，资源或者叫资源服务器，并不属于某个最终用户，也就是没有资源全部者对该资源负责，可是客户端应用确定仍是要访问这些资源，这时候就只能使用Client Credentials这种受权方式了。

其余重要角色和组件：

　　一、资源全部者Resource Owner　　

　　二、客户端Client

　　三、被保护资源 Protected Resource

　　四、受权服务器Authentication Server

　　五、Access Token，它是用来访问被保护资源的凭据，受权服务器只是方形Token，被保护资源验证Token，客户端队友Access Token应该是彻底健忘的。

　　六、Scopes，被保护资源那里的一套权限，具备叠加性

　　七、Refresh Token，用来得到Access Token的凭据，客户端是用Refresh Token来请求信的Access Token

经过refresh token来取得新的access token的流程

 

 

 

 

 

 重要端点：

　　一、受权端点（Authentication Endpoint）是用来和资源全部者交互的，资源全部者在这里进行登陆（身份认证），而后经过该端点能够对客户端进行受权（Authentication Grant）。受权服务器首先要验证资源全部者的身份，可是验证的方式并不在OAuth2的协议范围内。

　　二、Token端点（Token Endpoint），客户端经过向Token端点展现它的受权（Authorization Grant）或Refresh Token来获取Access Token。除了Implicit以外全部的受权类型都须要使用该端点，由于Implicit和Access Token是直接发行的。

OpenId Connect（OIDC）

身份认证和受权。OAuth2不是身份认证（Authorization）协议，OpenId Connect能够进行身份认证（Authorization）。

一个比喻，受权，就比如生牛奶（多用途原料）；身份认证，就比如奶茶（一个最终产品），以牛奶为主原料。OAuth2，是生牛奶，众多web安全架构的一种多用途的基本成分。OIDC，比如奶茶，基于OAuth2的身份认证协议，添加了一些组件来提供身份认证的能力。

更高级的协议，扩展并代替了OAuth2。OpenID Connect是创建在OAuth2协议上的一个简单的身份标识层，因此OpenID Connect兼容OAuth2。使用OpenID Connect，客户端应用能够请求Identity Token，它会和Access Token一同返回给客户端应用。这个Identity Token就能够被用来登陆客户端应用程序，而客户端应用还可使用Access Token来访问API资源。UserInfo端点，（OAuth2定义了Authorization端点和Token端点）它容许客户端应用和获取用户的额外信息。定义了不一样类型的应用如何从身份识别提供商（IDP）安全的获取到这些Token。

与OAuth 2.0之间的角色映射关系

　　一、身份供应商（Identity Provider，IdP）

　　二、依赖方（Relying Party，RP，能够理解Wie客户端）

　　三、OAuth2里面能够分为两部分

　　　　a、资源全部者/客户端应用

　　　　b、受权服务器/被保护资源

　　四、身份认证协议里也是两大不分

　　　　a、依赖方

　　　　b、身份提供商

　　五、映射OAuth2------OIDC

　　　受权服务器/被保护资源------身份提供商进行映射

　　　资源全部者--------最终用户

　　　客户端应用-----依赖方（RP）

Auth 2.0 与 OIDC 角色映射

 

 

 抽象流程：

 

 

 依赖方（RP）发送请求到OpenID提供商（OP，也就是身份提供商）。

OpenID提供商验证最终用户的身份，并得到了用户委派的受权

OpenID提供商返回响应，里面呆着ID Token，也一般带着Access Token

依赖方如今可使用Access Token发送请求到用户信息的端点

用户信息端点返回用户的声明（claims，至关因而用户的信息）。

OpenId Connect身份认证流程

Authorization Code Flow：　

　　在Authorization Code流程里，一个受权码（Authorization Code）会被返回给客户端，这个受权码能够被直接用来交换ID Token和Access Token。该流程也能够在客户端使用受权码兑换Access Token以前对其身份认证。可是该流程要求客户端的身份认证动做在后台使用Client 和Secret来得到Tokens，这样就不会把Tokens暴露给浏览器或者其余访问浏览器的恶意应用了。

　　要求客户端应用能够安全的在它和受权服务器之间维护客户端的Secret，也就是说只适合这样的客户端应用。它还适合于长时间的访问（经过Refresh Token）。受权码来自于受权端点，而全部的Tokens都来自于Token端点。

　　Authorization Code流程的步骤以下：

　　　　客户端准备身份认证请求，请求里包含所须要的参数

　　　　客户端发送请求到受权服务器

　　　　受权服务器对最红用户进行身份认证

　　　　受权服务得最终用户的统一/受权

　　　　受权服务器把最终用户发送回客户端，同时带着受权码

　　　　客户端使用受权码向Token端点请求一个响应

　　　　客户端接收到响应，响应的Body里面包含在和ID Token和Access Token

　　　　客户端验证ID Token，并得到用户的一些身份信息

Implicit Flow：

　　Implicit在请求Token的时候不须要明确的客户端身份认证，它使用重定向URI的方式来验证客户端的身份，由于这一点，Refresh Token也就没法使用了，这一样也不适合于长时间有效的Access Token。

　　全部的Tokens都来自于受权端点，而Token端点并无用到。

　　该流程主要用于浏览器内的应用，Access Token和ID To恩一同被直接返回给客户端，由于这个缘由，这些Tokens也会暴露于最终用户和跨域访问该浏览器的其余应用了。它并不适合于长时间的访问。

　　Implicit流程的步骤以下：

　　　　客户端准备身份认证请求，请求里包含所须要的参数

　　　　客户端发送请求到受权服务器

　　　　受权服务器对最终用户进行身份认证

　　　　受权服务器得到最终用户的赞成/受权

　　　　受权服务器把最终用户发送客户端，同事带着ID Token，若是也请求了Access Token的话，那么Access Token也会一同返回。

　　　　客户端验证ID Token，并得到用户的一些身份信息。

Hybrid Flow：

　　Hybrid Flow是前二者的混合，在该流程里。有一些Tokens和受权码来自于受权重点，而另一些Tokens则来自于Token端点。该流程容许客户端当即使用ID Token，而且只须要一次往返便可得到受权码。这种流程也要求客户端应用能够安全的维护Secret，它也适合于长时间的访问。

　　Hybrid Flow的步骤以下：

　　　　客户端准备身份认证请求，请求里包含所须要的参数

　　　　客户端发送请求到受权服务器

　　　　受权服务器对最终用户进行身份认证

　　　　受权服务器得到最终用户的统一/受权

　　　　受权服务器把最终用户发送回客户端，同事带着受权码，根据响应类型的不一样，也考嫩恶搞带着一个躲着多个其余的参数

　　　　客户端使用受权码向Token端点请求一个响应

　　　　客户端接收到响应，响应的body里面包含着ID Token和Access Token

　　　　客户端验证ID Token，并得到用户的一些身份信息。

三种流程特色的比较

 

 

 返回值类型的比较

 

 

 三种类型，根据response_type的不一样，分为：

　　response_type=code id_token、response_type=code token、response_type=code id_token token。

　　注意：为了代表是OpenID Connect协议的请求，scope参数里必须包含OpenID。

esponse_type=code id_token

 

 

response_type=code token

 

 

response_type=code id_token token

 

Identity Server：

创建Identity Provider项目

dentityServer4.Templateshttps://github.com/IdentityServer/IdentityServer4.Templates

安装工具:

dotnet new -i identityserver4.templates

重置 “dotnet new” 功能列表: dotnet new --debug:reinit

模板:

dotnet new is4empty、 dotnet new is4ui 、dotnet new is4inmem 、dotnet new is4aspid、 dotnet new is4ef 、dotnet new is4admin (收费)

 

使用Identity Server 创建Authorization Server：http://www.javashuo.com/article/p-csqeiuoa-de.html