Hi I have a setup where internal apps do some processing. i have customer facing frontends that connect to the internal apps. i have apps only facing internal employees that connect to the internal apps. currently the internal apps validate both azure b2c and azure ad tokens, depending on the method of entrance. is it possible to have those token types unified in to a single token types so i dont need 2 different validators at the internal app level?

Hi @Emil Skov Rasmussen , both Azure AD B2C and Azure AD use JSON web tokens (JWTs) that contain assertions of information about the bearer and the subject of the token. However, the tokens used in Azure AD B2C and Azure AD are different and cannot be unified into a single token type. Azure AD B2C emits different types of security tokens as it processes each authentication flow. The ID token is a JWT that contains claims that you can use to identify users in your application. This token is securely sent in HTTP requests for communication between two components of the same application or service. You can use the claims in an ID token as you see fit. They're commonly used to display account information or to make access control decisions in an application. On the other hand, Azure AD issues different types of tokens depending on the authentication flow used. The most common tokens are the ID token, access token, and refresh token. The ID token is a JWT that contains claims about the authenticated user, such as their name, email, and unique identifier. The access token is a JWT that contains the permissions granted to the authenticated user, and it is used to access protected resources. The refresh token is used to obtain a new access token when the current one expires. You can consider using a single authentication flow for both internal and external users to simplify the validation process at the internal app level. For example, you can use the OpenID Connect (OIDC) authentication flow, which is supported by both Azure AD B2C and Azure AD: https://learn.microsoft.com/en-us/entra/architecture/auth-oidc You can also look into B2C federation: https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-b2c-federation-customers Please let me know if you have any questions and I can help you further. If this answer helps you please mark "Accept Answer" so other users can reference it. Thank you, James

unifying azure ad and azure b2c tokens

Accepted answer

James Hamil 26,486 Reputation points Microsoft Employee

2024-12-18T00:22:26.23+00:00

Hi @Emil Skov Rasmussen , both Azure AD B2C and Azure AD use JSON web tokens (JWTs) that contain assertions of information about the bearer and the subject of the token. However, the tokens used in Azure AD B2C and Azure AD are different and cannot be unified into a single token type.

Azure AD B2C emits different types of security tokens as it processes each authentication flow. The ID token is a JWT that contains claims that you can use to identify users in your application. This token is securely sent in HTTP requests for communication between two components of the same application or service. You can use the claims in an ID token as you see fit. They're commonly used to display account information or to make access control decisions in an application.

On the other hand, Azure AD issues different types of tokens depending on the authentication flow used. The most common tokens are the ID token, access token, and refresh token. The ID token is a JWT that contains claims about the authenticated user, such as their name, email, and unique identifier. The access token is a JWT that contains the permissions granted to the authenticated user, and it is used to access protected resources. The refresh token is used to obtain a new access token when the current one expires.

You can consider using a single authentication flow for both internal and external users to simplify the validation process at the internal app level.

For example, you can use the OpenID Connect (OIDC) authentication flow, which is supported by both Azure AD B2C and Azure AD: https://learn.microsoft.com/en-us/entra/architecture/auth-oidc

You can also look into B2C federation: https://learn.microsoft.com/en-us/entra/external-id/customers/how-to-b2c-federation-customers

Please let me know if you have any questions and I can help you further.

If this answer helps you please mark "Accept Answer" so other users can reference it.

Thank you,

James
Please sign in to rate this answer.

1 person found this answer helpful.
Emil Skov Rasmussen 20 Reputation points

2024-12-18T12:09:43.1766667+00:00

Hi James

Thank you for the quick response.

As i understand the idea of federation here,

it would allow b2c users (customers) and

azure ad users (employees) to get access to their respective flows

for the same apps and result in b2c or ad tokens respectively.

this means as you said that there is no unified token.

Maybe i have a more fundamental misunderstanding with regards to handling both customers and employees.

Below i have tried to describe my issue more specifically, hopefully you can help me in the right direction.

If you think the answer is in some documentation, please let me know.

BACKGROUND:

For this setup

CFE->BE1->BE2

EFE->BE1->BE2

where

CFE= customer facing frontend

EFE= employee facing frontend

for 2. i could use an obo token flow

this would allow BE1 to exchange the incoming obo for an outgoing obo to BE2

this allows BE2 to be sure that the call originated from some particular

employee (employeeA) and that BE1 has been allowed to act on behalf of employeeA

MY QUESTION:

for 1.

is there a mechanism i can use that will allow

BE2 to also be sure that the call originated from some particular customer

(customerA) and that BE1 has been allowed to act on behalf of customerA?

- if not, how can BE2 be sure that some rogue app did not obtain a b2c token and uses it against BE2 even though the rogue app should not have permission to do that.

EXTRA:

If it helps, in my current setup i create b2c id tokens with a custom flow

which adds a number of business specific claims, thorugh calling my custom apps,

and then i use that along with

a client credential(CC) token from the azure ad tenant to send to BE1

BE1 then validates the id token, against azure b2c and the CC token, against azure ad, and creates a new CC token

for BE2 and passes the new CC token and the b2c id token to BE2, which validates

and so on.

when looking at oauth documentation i see this

https://oauth.net/id-tokens-vs-access-tokens/

which says

"ID tokens should never be sent to an API. Access tokens should never be read by the client."

if that is true is the recommendation that the CFE takes the claims from the b2c id token

and send them as regular json or similar to the relavant APIs in BE1?

Best Regards
Emil Skov Rasmussen

James Hamil 26,486 Reputation points Microsoft Employee

2024-12-20T00:54:41.0533333+00:00

Hi @Emil Skov Rasmussen , if I'm understanding correctly, you can use theOn-Behalf-Of (OBO) flow to allow BE1 to exchange the incoming OBO token for an outgoing OBO token to BE2. This allows BE2 to be sure that the call originated from some particular customer (customerA) and that BE1 has been allowed to act on behalf of customerA.

For your second question, you can use Conditional Access policies to restrict access to your APIs to only authorized applications. This will prevent rogue apps from obtaining B2C tokens and using them against BE2.

And yes, you should not send ID tokens to APIs. Instead, you should use access tokens to access APIs. Access tokens are short-lived tokens that are issued by an authorization server and are used to access protected resources. ID tokens are used to authenticate users and contain information about the user, such as their name and email address.

In your setup, the CFE should take the claims from the B2C ID token and send them as regular JSON or similar to the relevant APIs in BE1. The APIs in BE1 should then use the claims to authorize the request and return an access token to the CFE. The CFE can then use the access token to access the APIs in BE2.

I hope this helps!

Emil Skov Rasmussen 20 Reputation points

2024-12-23T10:30:52.55+00:00

Hi James

Thank you for your answer and thank you for taking the time to answer my follow up questions.

I understand your answers with the exception of the first.
As i understand the azure b2c tenant / identity provider does not currently support the on behalf of flow. i believe that due to this
https://learn.microsoft.com/en-us/azure/active-directory-b2c/access-tokens

if the above is true (azure b2c does not support OBO flow), how could i perform an
"On-Behalf-Of (OBO) flow to allow BE1 to exchange the incoming OBO token for an outgoing OBO token to BE2. This allows BE2 to be sure that the call originated from some particular customer (customerA) and that BE1 has been allowed to act on behalf of customerA"
where the tokens would be issued /signed by the b2c tenant / identity provider?

Am i misunderstanding that azure b2c does support on behalf of flow?

Regardless of your answer i am thankful for how helpful you have been and it is nice to get your confirmation that ID tokens should not be sent to APIs.
Thank you and hope you have a good Christmas or similar

Best Regards
Emil Skov Rasmussen

Emil Skov Rasmussen 20 Reputation points

2024-12-23T10:31:13.35+00:00

Hi James

Thank you for your answer and thank you for taking the time to answer my follow up questions.

I understand your answers with the exception of the first. As i understand the azure b2c tenant / identity provider does not currently support the on behalf of flow. i believe that due to this https://learn.microsoft.com/en-us/azure/active-directory-b2c/access-tokens

if the above is true (azure b2c does not support OBO flow), how could i perform an "On-Behalf-Of (OBO) flow to allow BE1 to exchange the incoming OBO token for an outgoing OBO token to BE2. This allows BE2 to be sure that the call originated from some particular customer (customerA) and that BE1 has been allowed to act on behalf of customerA" where the tokens would be issued /signed by the b2c tenant / identity provider?

Am i misunderstanding that azure b2c does support on behalf of flow?

Regardless of your answer i am thankful for how helpful you have been and it is nice to get your confirmation that id tokens should not be sent to APIs. Thank you and hope you have a good Christmas or similar

Best Regards Emil Skov Rasmussen
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

unifying azure ad and azure b2c tokens

0 additional answers

Your answer