我受Azure AD B2C保护的API服务器应将哪个策略(用户流)视为授权? [英] Which policy (user flow) should my Azure AD B2C-protected API server expect as the authority?
问题描述
这是我第一次在任何项目中使用Azure AD B2C作为用户身份验证后端.我是这些概念的新手，正在努力加深对这些概念的理解.
This is my first time using Azure 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.
我正在使用Azure AD B2C服务.我正在开发一组最终将全部使用B2C作为用户身份验证引擎的应用程序.例如，我有一台ASP.NET Core API服务器，它将我的后端SQL数据公开给最终用户.我有一个JavaScript React应用程序，该应用程序使用B2C隐式工作流程进行身份验证并从中获取令牌.最后，我有一个使用资源的C#桌面应用程序所有者密码凭证流以获取我的B2C令牌.
I'm using the Azure AD B2C service. I'm developing a set of applications that all will ultimately use B2C as the user authentication engine. For example, 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工作流程来获取令牌.我有需要验证令牌的Web服务器.
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. I have the web server that I need to verify the tokens.
我的困惑在于我的后端API服务器以及它自己对用户提供的B2C承载令牌的验证.
My confusion 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 use the same policy as the issuer / authority.
我的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?
推荐答案
同一租户中所有策略的发行者URL应该相同.
The issuer URL should be same for all policies in the same tenant.
https://{tenant-name}.b2clogin.com/{tenant-id}/v2.0/
示例:
https://fabrikamb2c.b2clogin.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/
这意味着您可以使用API服务器配置任何权限，并且它应该验证为任何策略发出的令牌.
This means that you can configure any authority with the API server and it should validate tokens that are issued for any policy.
这篇关于我受Azure AD B2C保护的API服务器应将哪个策略(用户流)视为授权?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
