Azure AD B2C

目录

1. 什么是OAuth

2. 什么是OpenID Connect

3. 什么是Azure AD B2C

4.SPA中应用Azure AD B2C进行授权

5. 重要的claim讲解

---

对于企业来说传统的方式是采用ADFS联合身份验证，企业内部的员工放在某个Domain中，针对Domain中的group对用户进行用户权限管理，在开发的角度来说可以针对这个Domain来搭建认证服务器来实现用户的统一管理，采用OAuth的方式实现SSO单点登录。

 

1. 什么是OAuth

OAuth说白来就是一个RFC规范，在解释之前先来区分一下基本概念。认证和授权其实是两种相关但不相同的概念，OAuth本身来说做的是授权的事儿，因为利用他提供的access_token可以用来验证有没有权限去做一件事儿，而不能明确谁要去做一件事儿，那么如何去明确这个人是谁那？引入另外一个概念OpenID Connect，它能提供id_token其中就包含了用户的信息。接着说回OAuth，它有什么好处，当你去访问一个程序的时候，传统的方式你得注册一个这个程序下的用户，也就是说你会把你的个人隐私信息暴露出来，同时针对每个程序都注册用户也是很麻烦的事儿，现在用OAuth就可避免这步操作，直接用认证服务器/第三方应用(例如微信)来做sign in的操作，而针对用户只是需要去授权就可以了。下面用比较经典的授权码模式来说明完整的OAuth授权流程，其它模式大同小异不一一详述。

 

2. 什么是OpenID Connect

OpenID Connect是在OAuth基础上的协议，协议地址 https://openid.net/specs/openid-connect-core-1_0.html， 他最重要的特点是可以识别当前的终端用户，用户信息以Claim的形式通过JWT(Json Web Token)的形式被包含在id_token中，相比于OAuth的授权码(code)，简约(implicit)，密码(password)，客户端(client credential)这四种模式的基础上，又添加了implicit flow(id_token token)，hybrid flow(code id_token token)这些组合的形式。如果要构建一个authentication server可以使用identity server http://docs.identityserver.io/en/latest/quickstarts/0_overview.html ，提供了很多类库和demo。

 

3. 什么是Azure AD B2C

首先Azure AD和Azure AD B2C是两种功能，Azure AD更多的是用来存储和管理用户，用户权限管理等，更多的概念是租户，各种管理员，domain，group，user等，用来代替企业内ADFS，同时提供了很多的辅助工具，可以使跟踪监控批处理等操作更方便。

而Azure AD B2C更多的是提供认证服务的概念，全称Azure Active Directory Business To Customer。Azure AD B2C也是基于Oauth和OpenID Connect协议的，同时对此进行了扩展，如果某个client需要使用B2C进行授权的话，需要先将client注册到Azure AD tenant中， 然后将Sign-on URL地址设置为Azure AD B2C 对应的登录url，之后保存会生成application id/client id，之后的所有操作都是基于此参数来进行的。在Azure AD B2C中创建identity provider，选择OIDC把Metadata url替换为你Azure AD对应的url，比如 https://login.microsoftonline.com/your-ad-tenant-domian/.well-know/openid0configuration， 这样操作之后相当于Azure AD和Azure AD B2C的两个tenant进行了绑定，不过在真正应用之前，需要更改user flow，说白了就是针对没api程序的权限流，在客户端发起请求的时候需要调用，根据不同的user flow办法不同的token进而做不同的事儿。

 

4.SPA中应用Azure AD B2C进行授权

 

 

 

GET https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/oauth2/v2.0/authorize? client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 &response_type=id_token+token &redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F &response_mode=fragment &scope=openid%20offline_access &state=arbitrary_data_you_can_receive_in_the_response &nonce=12345 &p=b2c_1_sign_in

 

以上是spa中应用的流程，采用的是implicit flow模式，之所以采用这种模式是因为spa程序是不受信的，一切都是运行在浏览器中所以不能暴露敏感的信息，如果采用code模式，Azure AD B2C返回的code将直接返回给浏览器，同时对于client_secret也是无法维持隐秘的，但是在真正应用的时候一定要保证是https的通信，保证client和server彼此之间的信任。

上面参数中的response_mode有四种模式的，该模式下使用的是fragment(#id_token=xxx)而不是经典的form-query，nonce参数为随机数就可以好处是避免重复攻击，p 参数为user flow，使用时一定要明确user flow的名字。

 

 

我们都知道无论是id_token，还是access_token有效期都是很短的默认是1小时，正常code模式下我们可以用refresh token来保证token的有效性，但是在Implicit flow下出于安全的考虑是不会返回refresh token的，那我们该如何保证token的有效或者对于不同的user flow获取token的时候如何做到静默刷新那，其实是采用hidden iframe(认证服务器内部行为)如下访问形式如下

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/oauth2/v2.0/authorize? client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 &response_type=token &redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F &scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read &response_mode=fragment &state=arbitrary_data_you_can_receive_in_the_response &nonce=12345 &prompt=none &domain_hint=organizations &login_hint=myuser@mycompany.com &p=b2c_1_sign_in

 

Domain_hint参数可以为consumer和organizations, 可以提取id_token中的tid来判断之前的与要访问的是不是相同，相同为consumer

login_hint参数为用户名可以从id_token中提取 preferred_username

prompt=none，确保不返回登录页而直接返回想要的token

Refresh token维持token有效性是同理的只是response_type设置为你具体想要的

 

5. 重要的claim讲解

再说claim之前，先来介绍一下jwt，它是一种紧凑型，自包含的token串，它有三部分，头包含一些token的通用信息加密的算法等，载体包含的是具体的claim可以是规范内一些内置的也可以是你自己想要传递给前台的，最后一部分是签名，不可逆签名比如sha256保证token的一致性，没有被篡改过，签名的对象是前两部分，之后进行base64加密压缩然后传递，最终结构=>头.载体.签名。

 

Name	Claim	描述
Audience	Aud	颁发给谁也就是你的application id/client id
Issuer	Iss	颁发者是谁也就是你的aad tenant name
Issued at	Iat	颁发时间
Expiration time	Exp	过期时间
Alg	Alg	加密算法
Kid	Kid	加密公钥