对于企业来说传统的方式是采用ADFS联合身份验证，企业内部的员工放在某个Domain中，针对Domain中的group对用户进行用户权限管理，在开发的角度来说可以针对这个Domain来搭建认证服务器来实现用户的统一管理，采用OAuth的方式实现SSO单点登录。
OAuth说白来就是一个RFC规范，在解释之前先来区分一下基本概念。认证和授权其实是两种相关但不相同的概念，OAuth本身来说做的是授权的事儿，因为利用他提供的access_token可以用来验证有没有权限去做一件事儿，而不能明确谁要去做一件事儿，那么如何去明确这个人是谁那？引入另外一个概念OpenID Connect，它能提供id_token其中就包含了用户的信息。接着说回OAuth，它有什么好处，当你去访问一个程序的时候，传统的方式你得注册一个这个程序下的用户，也就是说你会把你的个人隐私信息暴露出来，同时针对每个程序都注册用户也是很麻烦的事儿，现在用OAuth就可避免这步操作，直接用认证服务器/第三方应用(例如微信)来做sign in的操作，而针对用户只是需要去授权就可以了。下面用比较经典的授权码模式来说明完整的OAuth授权流程，其它模式大同小异不一一详述。
首先Azure AD和Azure AD B2C是两种功能，Azure AD更多的是用来存储和管理用户，用户权限管理等，更多的概念是租户，各种管理员，domain，group，user等，用来代替企业内ADFS，同时提供了很多的辅助工具，可以使跟踪监控批处理等操作更方便。
以上是spa中应用的流程，采用的是implicit flow模式，之所以采用这种模式是因为spa程序是不受信的，一切都是运行在浏览器中所以不能暴露敏感的信息，如果采用code模式，Azure AD B2C返回的code将直接返回给浏览器，同时对于client_secret也是无法维持隐秘的，但是在真正应用的时候一定要保证是https的通信，保证client和server彼此之间的信任。
我们都知道无论是id_token，还是access_token有效期都是很短的默认是1小时，正常code模式下我们可以用refresh token来保证token的有效性，但是在Implicit flow下出于安全的考虑是不会返回refresh token的，那我们该如何保证token的有效或者对于不同的user flow获取token的时候如何做到静默刷新那，其实是采用hidden iframe(认证服务器内部行为)如下访问形式如下
再说claim之前，先来介绍一下jwt，它是一种紧凑型，自包含的token串，它有三部分，头包含一些token的通用信息加密的算法等，载体包含的是具体的claim可以是规范内一些内置的也可以是你自己想要传递给前台的，最后一部分是签名，不可逆签名比如sha256保证token的一致性，没有被篡改过，签名的对象是前两部分，之后进行base64加密压缩然后传递，最终结构=头.载体.签名。
OAuth 即：Open Authrization(开放授权)， 它是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密资源，而无需将用户名和密码提供给第三方。比如我们熟知的通过qq/微信/微博等登录第三方平台。OAuth 1.0版本发布后有许多安全漏洞，所以在OAuth
.0里面完全废止了OAuth1.0，它关注客户端开发者的简易性，要么通过组织在资源拥有者和HTTP服务商之间的......
t不支持双活架构，可以采用暂存模式可以用于许多方案，包括：• 高可用性。• 测试和部署新的配置更改。• 引入新的服务器并解除旧服务器。使用处于暂存模式的服务器，可以在激活服务器之前更改配置和预览更改。 它还允许运行完全导入和完全同步，以便在生产环境中应用所有更改之前验证这些更改是否符合预期。可以在安装过程中选择将服务器置于暂存模式。 此操作可以激活服务器进......
