Azure B2C-将查询参数接受到OAuth2 JWT中 [英] Azure B2C - Accept query params into OAuth2 JWT

查看:56
本文介绍了Azure B2C-将查询参数接受到OAuth2 JWT中的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我很好奇,通过Azure请求OAuth2令牌时是否可以读取查询参数?

I was curious if it was possible to read query parameters when requesting an OAuth2 token through Azure?

基本上,当使用我创建的策略进行测试调用时,我希望从调用中读取其他查询参数,并且业务流程(用户旅程)步骤应读取这些值并将该值注入到自定义声明中(用于JWT或ID令牌).

Essentially, when making a test call with a policy that I created, I would like to have an additional query parameters read from the call and the orchestration (user journey) steps should read these values and inject that value into a custom claim (for the JWT or ID token).

我从以下链接中知道,Azure B2C服务是否可能*?但是我找不到任何好的具体例子.

I know from the follow links that it may* be possible with Azure B2C service? But I can't find any good concrete examples.

注册政策-通过代码设置用户属性

添加自定义属性不在注册或修改政策中使用

我如何执行我的自定义SignUpSignIn策略后返回PolicyId声明?

我如何包含电子邮件在重定向到AZURE AD B2C

然后我尝试了很多配置,但是有太多选择可供选择,我不知道该选择哪个.此外,我找不到任何描述配置这些策略时使用的选项的Azure文档.无论如何,这就是我所拥有的.

I then proceeded in trying a bunch of configurations out but there are so many options to choose from, I don't know which to choose. In addition, I haven't been able to find any Azure docs that describe the options used when configuring these policies. In any case, here is what I have.

我从此处.我从此

I downloaded the TrustFrameworkBase.xml and TrustFrameworkExtensions.xml from here. I got this Github link from this Azure doc, which I also followed the steps on setting up policy keys and added an app registration with delegated permissions. For my relying party configuration, I simply made a custom policy through the Azure B2C portal and downloaded it as a starting point to explore what it looks like in a basic form.

这是我的自定义声明,该声明已添加到 ClaimsSchema 标记内的基本策略中. extension_Test是我要从查询参数中插入值的声明:

Here is my custom claim added to the base policy within the ClaimsSchema tag. extension_Test is the claim where I want to inject the value from a query param:

  <ClaimType Id="extension_Test">
    <DisplayName>Test value</DisplayName>
    <DataType>string</DataType>
    <DefaultPartnerClaimTypes>
      <Protocol Name="OAuth2" PartnerClaimType="extension_Test" />
      <Protocol Name="OpenIdConnect" PartnerClaimType="extension_Test" />
    </DefaultPartnerClaimTypes>
    <UserInputType>Readonly</UserInputType>
  </ClaimType>
</ClaimsSchema>

在同一基本策略中,这是我为登录添加的用户旅程:

In the same base policy, here's the userjourney that I added for SignIn:

<UserJourney Id="SignIn">
        <OrchestrationSteps>
            <OrchestrationSteps>
            <!-- The following orchestration step is always executed. -->
            <OrchestrationStep Order="1" Type="ClaimsProviderSelection" ContentDefinitionReferenceId="api.idpselection.signupsignin">
                <ClaimsProviderSelections>
                    <ClaimsProviderSelection TargetClaimsExchangeId="LocalAccountRegistrationExchange" />
                </ClaimsProviderSelections>
            </OrchestrationStep>
            <OrchestrationStep Order="2" Type="ClaimsExchange">
              <ClaimsExchanges>
                <ClaimsExchange Id="LocalAccountRegistrationExchange" TechnicalProfileReferenceId="LocalAccount-Registration-VerifiedEmail" />
              </ClaimsExchanges>
            </OrchestrationStep>
            <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
        </OrchestrationSteps>

    </UserJourney>

这是我依赖的配置XML:

Here's my relying config XML:

 <RelyingParty>
    <DefaultUserJourney ReferenceId="SignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="extension_Test" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="extension_Test" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub" />
      </OutputClaims>
      <SubjectNamingInfo ClaimType="sub" />
    </TechnicalProfile>
  </RelyingParty>

我认为按此顺序上传了基本,扩展和RP策略XML文件.我正在发送的GET请求如下所示(从自定义策略的立即运行"按钮中获得了):

I think uploaded the base, extensions and RP policies XML files in that order. The GET request that I'm sending looking like this (got from the "Run now" button for the custom policy):

https://login.microsoftonline.com/<TENANT>/oauth2/v2.0/authorize?p=B2C_1A_test&client_id=<TENANTID>&nonce=defaultNonce&redirect_uri=http%3A%2F%2Flocalhost%2Fredirect&scope=openid&response_type=id_token&prompt=login&extension_Test=aaa

任何帮助将不胜感激,谢谢!还是说明这些配置文件中更多选项的Azure文档-CpimIssuerTechnicalProfileReferenceId ="JwtIssuer"是什么意思?还是AzureFunction-WrapWebHook是什么意思?

Any help would be greatly appreciated, thanks! Or Azure documents that explain more options within these config files - as in what does CpimIssuerTechnicalProfileReferenceId="JwtIssuer" mean? Or AzureFunction-WrapWebHook mean?

推荐答案

您很亲密.

(我是作者).

高级解决方案是:

1)在设计时,使用输入的声明配置依赖方策略.

1) At design-time, configure the relying party policy with the input claim.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <InputTokenFormat>JWT</InputTokenFormat>
    <CryptographicKeys>
      <Key Id="client_secret" StorageReferenceId="B2C_1A_MySharedSecret" />
    </CryptographicKeys>
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_Test" />
    </InputClaims>
    <OutputClaims>
      ...
      <OutputClaim ClaimTypeReferenceId="extension_Test" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

您必须创建一个策略密钥(在上面的示例中,它称为"MySharedSecret",但可以称为任何东西),其中包含调用此策略的应用程序已知的共享密钥(其中的客户端密钥用于此应用程序可以是此共享机密).

You must create a policy key (in the above example, this is called "MySharedSecret", but it can be called anything) containing a shared secret that is known to the application that is invoking this policy (where the client secret for this application can be this shared secret).

2)在运行时,创建一个包含输入声明的自发行JWT,使用共享密钥对此JWT签名,然后使用"client_assertion_type"和"client_assertion"参数将JWT添加到身份验证请求中.

2) At runtime, create a self-issued JWT containing the input claim, sign this JWT with the shared secret, and then add the JWT to the authentication request using the "client_assertion_type" and "client_assertion" parameters.

此代码示例可在身份验证请求的示例是:

An example of the authentication request is:

https://login.microsoftonline.com/b2ctechready.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1a_invitation&...&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=eyJhbGci...7m9s&state=CfDJ8EPk...Et0w

这篇关于Azure B2C-将查询参数接受到OAuth2 JWT中的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆