9

I can get these tokens after setting up keys/secrets, but I don't know if or how I can rely on the sub claim in my app.

For more background, my app is actually a B2C registered app and I'm going to the v2 endpoint in the B2C tenant, but with no policy specified in order to use the client credentials flow (probably resulting in a regular AAD, non-B2C token -- I had to load multiple keysets on the back end for token validation to work since we're basically using multiple token sources doing it this way). In our app we use middleware to validate the JWT Bearer token and look up valid callers by sub/oid to add any appropriate claims to the contextual claims identity.

In this client_credentials case, I am trying to figure out if the oid is related to some service principal, my app, a GUID representing the client secret used, or something else entirely - and whether I can rely on it enough to just add it to my expected "users" database with appropriate application privileges. Ideally there would be an easier way to identify tokens that were being used for service-to-service calls.

Here is an example of retrieving these tokens using Postman: using Postman to get a client_credentials token

resulting in:

{
    "token_type": "Bearer",
    "expires_in": 3599,
    "ext_expires_in": 0,
    "access_token": "eyJ...pcQ"
}

The token contents, from jwt.io:

enter image description here

sprobean
  • 171
  • 1
  • 2
  • 7

2 Answers2

5

@juunas had the right answer (it's the service principal). The difficulty was in verifying the answer.

In my case I am getting tokens for an appId which is defined in an Azure AD B2C tenant. The tenant was created using my main (enterprise) logon. The service principals are difficult to find in Azure, and I followed some red herrings using the AzureAD Powershell extensions. Ultimately I found that I had the same kind of problem as this guy, so I created an admin in my tenant to use when logging in through Powershell using the MSOnline extensions. Once I had that setup and was logged in through Powershell under the right account, I was able to run Get-MsolServicePrincipal -TenantId 88...e9 -AppPrincipalId 0a...23 to see the info for my application. The resulting displayed AppPrincipalId is the application id that is visible in the portal. The ObjectId returned matches the oid (and sub) I see in client credentials grant tokens issued for this app.

Powershell output

sprobean
  • 171
  • 1
  • 2
  • 7
  • 5
    In typical fashion, after struggling to find the hard solution, I found the easy one: in the B2C tenant (after switching to the tenant directory), I went to the Azure Active Directory blade, selected 'enterprise applications', changed the filter to 'All Applications', then my app showed up displaying both Object ID and Application ID. – sprobean Aug 07 '18 at 23:44
  • Another way to find it is the following. In your application registration, select overview, and find the Managed Application in local Directory field, which has a link to the Enterprise Application registration. In there, the object id is the SP id you are looking for. – Sayak Mukhopadhyay Nov 10 '20 at 08:32
2

The OID is the Object ID of the user. This can be viewed under Azure Active Directory > All Users > click into user > User Overview.

Please see this blog post that explains these values.

enter image description here

The sub is the user that is identified in the token: 

<Subject>
<NameID>S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
</Subject>

Example JWT Value: 

"sub":"92d0312b-26b9-4887-a338-7b00fb3c5eab"

See this reference.

Marilee Turscak - MSFT
  • 7,367
  • 3
  • 18
  • 28
  • Perhaps I could have phrased this as "what user"? In my azure configuration I'm getting JWT tokens with matching oid and sub claims. For our SPA using implicit flow this is working just fine. I map oid/sub to application users. In this case in question, though, I'm getting tokens using client_credentials grant and secret. It's still setting an oid (and matching sub, as show above). I have deployed a separate app to get these by calling the token endpoint within azure and get the same oid shown above. I was hoping it might give a different result than Postman, but it doesn't – sprobean Aug 07 '18 at 19:59