[B2C]帮助我了解-受B2C保护的API服务器应将哪个策略(用户流)视为授权? [英] [B2C] Help me understand - Which policy (user flow) should my B2C-protected API server expect as the authority?

问题描述

您好，

这是我第一次在任何项目中使用AD(B2C)作为用户身份验证后端.我对这些概念是全新的，并且正在努力加深对这些概念的理解.我正在使用Azure AD B2C服务器.我正在开发一组应用程序 最终所有人都将使用B2C作为用户身份验证引擎.我有一台ASP.NET Core API服务器，它将我的后端SQL数据公开给最终用户.我有一个JavaScript React应用程序，该应用程序使用B2C隐式工作流程进行身份验证并从中获取令牌. 最后，我有一个使用的C#桌面应用程序 资源所有者密码凭据流以获取我的B2C令牌.

This is my first time using AD (B2C) as the user authentication back-end in any of my projects. I'm brand new to the concepts and am trying to piece together my understanding of them. I'm using the Azure AD B2C server. I'm developing a set of applications that all will ultimately use B2C as the user authentication engine. I have an ASP.NET Core API server that exposes my back-end SQL data to end-users. I have a JavaScript React application that uses the B2C implicit workflow to authenticate and get tokens from. Last, I have a C# desktop application that uses the resource owner password credentials flow to obtain my B2C tokens.

因此，如您所见，我有几种不同类型的B2C应用程序.我有一个可以利用隐式交互式工作流的Web应用程序.我有一个桌面应用程序，可以利用ROPC工作流程来获取令牌.

So, as you can see, I have several different B2C applications of different types. I have a web app that can leverage the implicit interactive workflow. I have a desktop application that can leverage the ROPC workflow to get the tokens.

我的困惑在于我的后端API服务器以及它自己对用户提供的B2C承载令牌的验证.

My confusion though is regarding my back-end API server and its own validation of the provided B2C bearer tokens from users.

据我了解，我需要配置我的API服务器，以便它需要特定的策略(作为权限)来颁发令牌.这很简单-我目前只希望它具有交互式，默认的B2C提供的登录策略.

It's my understanding that I need to configure my API server so that it requires a particular policy, as the authority, to have issued the token. That's simple enough - I currently just have it expect the interactive, default B2C-provided sign in policy.

我的Web应用程序(基于浏览器的React应用程序)可以简单地使用相同的登录策略用户流，并将访问令牌提供给API服务器，并且一切正常，因为这两个令牌都是通过同一策略授予的.

My web application, the browser-based React application, can simply use that same sign in policy user flow and provide the access token to the API server and everything works because both have been granted tokens via the same policy.

我的GUI应用程序虽然未使用相同的登录策略，但它使用的ROPC策略未能通过API服务器的权限检查，因为服务器希望登录策略已授予令牌

My GUI application though does not use that same sign in policy, it uses the ROPC policy which fails to pass the API server's authority check because the server expects the sign in policy to have granted the token.

我的问题是...

如何协调所有这些政策?我是否认为自己的各种客户端应用程序"正确?应该可以通过对他们有意义的任何策略(用户流)自由生成令牌?但是，然后我的API服务器应使用哪种策略作为 权限，因为它只需要使用一个策略即可?

How do I reconcile all these policies? Am I correct in thinking that my various "client applications" should be free to generate tokens via whichever policy (user flow) makes sense for them? But then which policy should my API server use as the authority since it requires one single policy to have been used?

谢谢！

推荐答案

在Azure AD中B2C，AuthN和AuthZ是根据运行策略后获得的令牌而不是根据策略类型来完成的.这是因为您的所有应用程序都将相同的B2C Azure AD租户与其IDP信任在一起.

In Azure AD  B2C, AuthN and AuthZ are done based on the token obtained after running the policy and not by the type of policy. This is because all your applications are trusting the same B2C Azure AD tenant as their IDP.

当您说应用程序应该能够使用任何策略并获得令牌时，您是正确的.

You are correct when you say that apps should be able to use whatever policy and obtain the token. 

您可以确保在两个应用程序(隐式和ROPC)的请求中都发送了相同的作用域吗?

Can you make sure you have the same scopes sent in the requests for both the applications (Implicit and ROPC) ?

您可以解码在https://jwt.ms中获得的令牌并比较范围.

You can decode the token you obtained in https://jwt.ms and compare the scopes.

这篇关于[B2C]帮助我了解-受B2C保护的API服务器应将哪个策略(用户流)视为授权?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！