Identity Server4学习笔记

学习参考资料

博文 学习前的预备知识https://www.cnblogs.com/cgzl/p/9221488.html

        OAuth 2.0 的一个简单解释 和 OAuth 2.0 的四种方式

       这个博主的文非常适合做课后总结

        https://www.yuque.com/yuejiangliu/dotnet/solenovex-identityserver4

视频请参考杨旭老师在b站的IdentityServer4的教学视频。

        笔记之前先吐槽一下自己。虽然登录简书等各种软件的时候会提示是否QQ登录等第三方软件是否登录，但我在看视频以及博文笔记教程的时候完全没考虑这个，因为平常都是一个前端一个后端，虽然不会想到把客户端，授权服务中心，受访问的资源服务器以及资源拥有者联系在一起。惭愧惭愧，以至于在我看了杨老师蛮久的视频之后也没有反应过来具体要怎么做。

        最后逼不得已把杨老师的源码下载下来打算一模一样拷贝一份，结果因为我在抄袭代码的时候因为我用的是新版本的，改了一些功能，然后百思不得其解，无奈啊，最后还是去github下的最新的IdentityServer4来进行的模仿。但是一旦你调通了程序，真的就豁然开朗。

         因为以上的博文其实已经很详细了，我也就记一下学习过程中老是误解的部分。

      OAuth 2.0 简介

          OAuth 2.0是一个委托协议, 它可以让那些控制资源的人允许某个应用以代表他们来访问他们控制的资源。 这个应用从资源的所有者（用户或第三方平台）那里获得到授权(Authorization)和access token, 随后就可以使用这个access token来访问资源.

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

          简单点说授权就是我能做什么。使用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是更高级的协议, 它扩展并替代了OAuth2. 尽管现在我们经常说我们在使用OAuth2来保护API, 其实更准确的说, 大多数情况下, 我们使用的是OpenID Connect.

关于为什么不用OAuth2.0来做身份认证的事

为什么不使用 OAuth 2.0 的 Acess Token 来解决身份认证的问题？
A：
• Access Token 不含有身份认证的信息
• Access Token 的生命周期有可能会很长，即使用户离开了，它仍然有效
• Access Token 可能被其它客户端借用
• Access Token 本来也不是为客户端准备的，它对客户端不透明，但是客户端可以从 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这种授权方式了.

 

事实上，弄清了1,2,4基本上就都懂了。主要是要区分浏览器，客户端，授权服务器，资源保护者四个的联系。