B2C - Impersonation Flow

trydis 0
Viewed 26

I'm testing the impersonation flow and I'm a bit confused regarding how it should work.

In the JWT the sub claim contains the ID of the impersonator and not the one being impersonated. I was kinda expecting this to be the latter, to avoid any special handling on the API side.

Let's say I want the user ID of the impersonated user in the impersonatedUser claim. Is the recommended way of handling this in the API to 1st check for the impersonatedUser claim (someone is being impersonated) and then use sid (no impersonation) if the former isn't present? What is the recommended way of doing this?

Example JWT created by the policy:

[Header].{
  "exp": 1662552679,
  "nbf": 1662549079,
  "ver": "1.0",
  "iss": "https://foo.b2clogin.com/39b9ad06-299d-43da-a960-5e07d3ca9c06/v2.0/",
  "sub": "0eebe778-5934-48f6-84a6-bf921f467877", <-- This is the ID of the impersonator
  "aud": "64cb0c7e-678d-477c-8efc-a011c3614e58",
  "acr": "b2c_1a_impersonation",
  "nonce": "defaultNonce",
  "iat": 1662549079,
  "auth_time": 1662549079,
  "name": "unknown",
  "impersonatedUser": "a@customer.com"
}.[Signature]
azure-ad-b2c-custom-policy azure-ad-b2c
1 Answers

This impersonation flow follows guidance for token exchange which states you should always maintain who is making the original request. This is why the sub should always be the person making the impersonation. This is an extra security layer for audit and control. This protects against abuse of the one who is doing the impersonation.

This design was explicitly done in this manner - yes you could switch and not follow this guidance, but this doesn't align with this open standard.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-10

Chad Hasbrook0
Related