OAuth（Open Authorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，通过这个标准，第三方无需知道用户的账号和密码，就可获取到用户的授权信息。
OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。
OpenID是一个去中心化的网上身份认证系统。对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者（identity provider, IdP）的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。OpenID既解决了问题而又不需要依赖于中心性的网站来确认数字身份。
老系统的现状
每个老系统都起源自新系统，用的久了，就慢慢变老了！
刚开始设计网站的时候，仅仅是一个用户登录；然后加入了角色，最后加入了鉴权，后来又增加了限次密码失败，后来的后来，再增加白名单，最后，增加了二次验证…，最后的最后，加入了第三方的账号登录。 等等，好像没有最后，还有开发api呢，还有许多功能呢… …
是时候上统一登录授权了吧，最好符合Oauth2.0… …
Oauth的授权四模式：
- 授权码模式（authorization code）
是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。 - 简化模式（implicit）
不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。 - 密码模式（resource owner password credentials）
用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。 - 客户端模式（client credentials）
指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。
.net core的支持
ASP.NET Core 标识是支持用户界面（UI）登录功能的成员资格系统。 用户可以创建一个具有存储在标识中的登录信息的帐户，也可以使用外部登录提供程序。 支持的外部登录提供程序包括Facebook、Google、Microsoft 帐户和 Twitter。
若要保护 web Api 和 Spa，请使用IdentityServer4。 IdentityServer4 是 ASP.NET Core 3.0 的 OpenID Connect 和 OAuth 2.0 framework。 IdentityServer4 支持以下安全功能：
- 身份验证即服务 (AaaS)
- 跨多个应用程序类型的单一登录/注销 (SSO)
- API 的访问控制
- Federation Gateway
再来看看IdentityServer4
OpenID Connect和OAuth 2.0非常相似-实际上，OpenID Connect是OAuth 2.0的扩展。身份验证和API访问这两个基本的安全问题被组合成一个协议-通常只需一次往返于安全令牌服务。
我们相信OpenID Connect和OAuth 2.0的结合是在可预见的将来保护现代应用程序的最佳方法。IdentityServer4是这两个协议的实现，并且经过高度优化，可以解决当今移动，本机和Web应用程序中的典型安全问题。
实际上，按照教程，花费2个小时，你就可以手撸一个登录服务了。
搞定了登录，但是授权怎么办呢？
相信撸到这一步的你也会有同样的困惑。
拆分设计
先理解下概念：
- 授权（authorization）：授权，批准;批准（或授权）的证书；
- 认证（authentication）：认证;身份验证;证明，鉴定;密押。
- 资源（Resource），在系统中定义的第一件事就是要保护的资源。这可能是您的用户的身份信息，例如个人资料数据或电子邮件地址，或对API的访问，id要求资源必须有 openid。
因此结合途中的5，6，7步骤，所做的下一步授权，应该结合资源服务进行设计。
当然可以设计用户中心，资源中心等分开设计，主要是综合业务的需求。
总结
撸一个登录服务很easy，但想设计一套综合旧项目的统一登录认证鉴权授权平台是比较复杂的过程，不可能是几天搞定。但只要你分析清除每个环节，逐步实现，当可在1人月内完成设计和编码。
