资源所有者密码凭据流现在在Azure B2C的预览中可用:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/configure-ropc
然而,我想修改一下声明(具体来说:将用户名作为“email”声明)。我试着用文档中的流在IEF中调用我现有的自定义策略,但他们不喜欢这样(令人惊讶)
AADB2C:发生异常。
有没有办法影响这个流程中的索赔?
实现Chris的答案时更新我遇到了以下错误:
无法上载策略。原因:验证失败:在租户“xxx.onmicrosoft.com”的策略“B2C\u 1A\u ROPC”中发现1个验证错误。索赔类型“email”是依赖方技术配置文件的输出索赔,但它不是用户旅程“SignIn ROPC”的任何步骤中的输出索赔。
我发布了一个实验解决方案作为单独的答案。
这是我使用Chris有用的答案制定的完整政策。我认为它是实验性的,因为我不完全理解索赔流程,但它运行得很好。
<ClaimsProviders>
<ClaimsProvider>
<DisplayName>Override some profiles</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="login-NonInteractive">
<DisplayName>Local Account SignIn</DisplayName>
<Protocol Name="OpenIdConnect" />
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName"
PartnerClaimType="username"
Required="true"
DefaultValue="{OIDC:Username}" />
<InputClaim ClaimTypeReferenceId="password"
Required="true"
DefaultValue="{OIDC:Password}" />
</InputClaims>
</TechnicalProfile>
<TechnicalProfile Id="AAD-UserReadUsingObjectId">
<OutputClaims>
<!-- This user journey does not have any other step that provides this -->
<OutputClaim ClaimTypeReferenceId="signInName" />
</OutputClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
</ClaimsProviders>
<UserJourneys>
<UserJourney Id="SignIn-ROPC">
<PreserveOriginalAssertion>false</PreserveOriginalAssertion>
<OrchestrationSteps>
<OrchestrationStep Order="1"
Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="LoginNonInteractiveExchange"
TechnicalProfileReferenceId="login-NonInteractive" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="2"
Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReadWithObjectId"
TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="3"
Type="SendClaims"
CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
</OrchestrationSteps>
</UserJourney>
</UserJourneys>
<RelyingParty>
<DefaultUserJourney ReferenceId="SignIn-ROPC" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId"
PartnerClaimType="sub"/>
<!-- This works for accounts that were created via the azure portal -->
<OutputClaim ClaimTypeReferenceId="signInName"
PartnerClaimType="email" />
<!-- This works for accounts that signed up themselves -->
<OutputClaim ClaimTypeReferenceId="signInNames.emailAddress"
PartnerClaimType="email" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
您必须在自定义策略中实现ROPC流,以便在ID令牌中发出“电子邮件”声明。
要在自定义策略中实现ROPC流,请执行以下操作:
1: 将DefaultValue属性添加到每个“signInName”和“password”
<TechnicalProfile Id="login-NonInteractive">
<DisplayName>Local Account SignIn</DisplayName>
<Protocol Name="OpenIdConnect" />
...
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="username" Required="true" DefaultValue="{OIDC:Username}" />
<InputClaim ClaimTypeReferenceId="password" Required="true" DefaultValue="{OIDC:Password}" />
...
</InputClaims>
...
</TechnicalProfile>
2: 创建“ROPC”用户旅程:
<UserJourney Id="SignIn-ROPC">
<PreserveOriginalAssertion>false</PreserveOriginalAssertion>
<OrchestrationSteps>
<OrchestrationStep Order="1" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="LoginNonInteractiveExchange" TechnicalProfileReferenceId="login-NonInteractive" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
</OrchestrationSteps>
</UserJourney>
3: 创建“ROPC”依赖方技术档案:
<RelyingParty>
<DefaultUserJourney ReferenceId="SignIn-ROPC" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="email" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
资源所有者密码凭据(即用户名和密码),可以直接作为获取访问令牌的授权许可。这种凭据只能应该当资源所有者和客户端之间具有高度信任时(例如,客户端是设备的操作系统的一部分,或者是一个高度特权应用程序),以及当其他授权许可类型(例如授权码)不可用时被使用。 尽管本授权类型需要对资源所有者凭据直接的客户端访问权限,但资源所有者凭据仅被用于一次请求并被交换为访问令牌。通过凭据和长期有效的访问令牌或刷新令牌的
资源所有者密码凭据许可类型适合于资源所有者与客户端具有信任关系的情况,如设备操作系统或高级特权应用。当启用这种许可类型时授权服务器应该特别关照且只有当其他流程都不可用时才可以。 这种许可类型适合于能够获得资源所有者凭据(用户名和密码,通常使用交互的形式)的客户端。通过转换已存储的凭据至访问令牌,它也用于迁移现存的使用如HTTP基本或摘要身份验证的直接身份验证方案的客户端至OAuth。 +----
资源所有者密码凭据仅包含一个请求和一个响应。 当没有可用的授权授权类型时,此授权类型在资源所有者与客户端具有良好关系的情况下非常有用。 资源所有者密码凭证可用于授予访问令牌的授权。 此类型的授权类型通过使用访问令牌或刷新令牌交换凭据来删除资源所有者凭据的存储以供将来使用。 资源所有者密码凭据授予请求包含以下参数 - grant_type - 这是用于设置密码的必需参数。 username - 这是
10.7. 资源所有者密码凭据 资源所有者密码凭据许可类型通常用于遗留或迁移原因。它降低了由客户端存储用户名和密码的整体风险,但并没有消除泄露高度特权的凭证给客户端的需求。 这种许可类型比其他许可类型承载了更高的风险,因为它保留了本协议寻求避免的密码反模式。客户端可能滥用密码或密码可能会无意中被泄露给攻击者(例如,通过客户端保存的日志文件或其他记录)。 此外,由于资源拥有者对授权过程没有控制权(在
本文向大家介绍oauth 资源所有者密码凭证授予,包括了oauth 资源所有者密码凭证授予的使用技巧和注意事项,需要的朋友参考一下 示例 资源
应用程序需要连接到仅支持OAuth2资源所有者密码凭据授予的API。我尝试使用下面的代码,但得到的响应代码为400“错误请求”。使用相同的代码,我可以连接到一个正常的网站并检索内容。 我知道API代码是工作,因为使用邮递员工作。在邮递员中,我只是发出一个帖子请求,提供用户名、密码和grant_type,并使用x-www. form-urlencoded 连接的返回是一个json。 你知道怎么了吗?