Custom claims included in implicit flow, but not included in PKCE flow

Question

For some reason my token configuration is not respected when using authorization code flow (response_type=code). organization, and displayName are missing from the both the id and auth tokens.

When I use implicit grant flow (response_type=id_token) it works as expected (organization, and displayName are present in the id token).

The configuration is included below. What is the reason?

  <UserJourneys>
    <UserJourney Id="DefaultSignin">
      <OrchestrationSteps>
        <OrchestrationStep Order="5" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
    </UserJourney>
  </UserJourneys>

  <RelyingParty>
    <DefaultUserJourney ReferenceId="DefaultSignin" />
    <TechnicalProfile Id="JWTSignin">
      <DisplayName>JWT Sign In</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="organization" />
      </OutputClaims>
      <SubjectNamingInfo ClaimType="sub" />
    </TechnicalProfile>
  </RelyingParty>

Answer 1

The reason for this was that I had Protocol=None and I should've had Protocol=OpenIdConnect

Two strange things:

• why does it work for implicit flow at all then?
• I'm sure I didn't invent this, it must come from one of the "custom policy starter packs" or other MSFT examples

       <TechnicalProfiles>
         <TechnicalProfile Id="JwtIssuer">
           <DisplayName>JSON Web Token Issuer</DisplayName>
-          <Protocol Name="None" />
+          <Protocol Name="OpenIdConnect" />
           <OutputTokenFormat>JWT</OutputTokenFormat>
           <Metadata>
             <Item Key="client_id">{service:te}</Item>

Answer 2

• When you are using authorization code flow, i.e., response_type=code, the organization and display name are missing in the client_id and the authorization token because in authorization code flow, the access token is passed over a secure connection with HTTPS SSL and TLS encryption as it is issued by the OAuth provider which us a mandate since, it is not possible to pass an access token directly in a URL parameter because URL parameters are part of the HTTP Request, which in turn could possibly be a prey of the Man-in-the-middle attacks. Thus, when you use authorization code flow to pass the token, an intermediary one-time-use "authorization code" is provided that only the legitimate receiver will be able to exchange (because you need the client secret) and that the code will be useless to potential hackers intercepting the requests over unencrypted transactions (because they don't know the client secret).

• Similarly, in implicit flow, the communication regarding the authorization token is less secure where there may be potential attack vectors like spoofing the domain upon redirect by hijacking the IP address of the client’s website since the access token in implicit flow is passed directly as a hash fragment which is not a part of the URL parameter though they can be read by running java scripts on the client side in the browser due to which you are able to read the issuer’s data by accessing the token hash through implicit flow while in authorization code flow, the data to be read is intended to read by the client possessing the private key of the HTTPS SSL connection certificate because even though you access the token, it is secured by the authorization code which should be decrypted by the client ID/client secret and then decrypted over a HTTPS SSL connection only.

• Thus, the details are not shown in authorization code flow as the token is intercepted in between wherein it is meant for authorizing the access connection at the client side over HTTPS.

Please find the below links for more information: -

Why is there an "Authorization Code" flow in OAuth2 when "Implicit" flow works so well?

https://aaronparecki.com/oauth-2-simplified/