The demo project is out of date for decade, can we have the latest .NET 8 version? about active-directory-b2c-dotnet-webapp-and-webapi

[jmprieur]

@winzuus
the sample you are looking for is here: https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/master/4-WebApp-your-API/4-2-B2C/README.md and is fully functional and maintained.

This repo here is for OWIN, which is indeed old tech

[bgavrilMS]

1. Secrets should be rotated periodically and while the AAD portal helps you with that (e.g. you can set expiry on a secret), this is not enforced. Certificate expiration is something that is better handled - e.g. you can get KeyVault to rotate certs and your app just gets the latest cert from KV (by name). Just remember to update your app registration!

2. Secrets are like passwords - vulnerable to brute force or spraying attacks. It's hard to enforce a 'strong' password. The private key of a certificate is much more complex and not vulnerable to these type of attacks.

[winzuus]

@winzuus the sample you are looking for is here: https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/master/4-WebApp-your-API/4-2-B2C/README.md and is fully functional and maintained.

This repo here is for OWIN, which is indeed old tech

Hi @jmprieur thank you so much for providing the up to date code sample and glad to see a contributor replying my issue :)

I have read the Sample Code and found it uses the OpenID Connect Flow, but I need to use the "Client Credential Flow".

The reason for this is I need to test my endpoint being protected without the user interactions. I will test it first with Postman, later I would like to do the auto testing in Unit tests, so a flow which requires user interactions does not fit my purpose.

Does Microsoft have code sample for this scenario? Appreciated if you could provide a link.

Many thanks,

Winston

[bgavrilMS]

@winzuus - client credentials flow is for service principals not for users. If your web api acts on behalf of a user, then we recommend that you test with Username/Password flow:

https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/desktop-mobile/username-password-authentication

[winzuus]

@winzuus - client credentials flow is for service principals not for users. If your web api acts on behalf of a user, then we recommend that you test with Username/Password flow:

https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/desktop-mobile/username-password-authentication

Hi @bgavrilMS thanks for your update.
No our API does not act behalf of a user.

I have found the Client Credential Flow is the most suitable flow for our case.

I have checked its official document but have not found a Github demo.
Appreciated if you could share the link of demo code for Client Credential Flow ( if there was one).

Thanks

[winzuus]

@bgavrilMS @jmprieur
Also I have found a code example for Client Certificate Flow.

Is it the same flow as the Client Credential Flow?

[bgavrilMS]

Yes @winzuus

The OAuth2 spec mentions the client_credentials grant. There are several variants of this:

• based on a secret (we don't recommend this in production)
• based on a certificate (you found the right sample)
• based on a federated credential (I don't think this works for b2c)

[franva]

Yes @winzuus

The OAuth2 spec mentions the client_credentials grant. There are several variants of this:

* based on a secret (we don't recommend this in production)

* based on a certificate (you found the right sample)

* based on a federated credential (I don't think this works for b2c)

Hi @bgavrilMS
Thank you for your reply.

For the 1st option: based on a secret, what is the reason that it is not recommended in production?

[franva]

1. Secrets should be rotated periodically and while the AAD portal helps you with that (e.g. you can set expiry on a secret), this is not enforced. Certificate expiration is something that is better handled - e.g. you can get KeyVault to rotate certs and your app just gets the latest cert from KV (by name). Just remember to update your app registration!
2. Secrets are like passwords - vulnerable to brute force or spraying attacks. It's hard to enforce a 'strong' password. The private key of a certificate is much more complex and not vulnerable to these type of attacks.

Thank you all questions answered 😌