Azure AD B2C OpenID Connect single logout with WS-Federation and SAML claims provider - azure-ad-b2c

AD FS is configured with custom policies as a claims provider on Azure AD B2C using WS-Federation and SAML. The relying party on Azure AD B2C is using OpenID Connect.
Is it possible to do front-channel single logout initiated through OpenID Connect?
OpenID Connect Front-Channel Logout 1.0 - draft 02: http://openid.net/specs/openid-connect-frontchannel-1_0-ID1.html
Single logout is initiated from the relying party using OpenID Connect and continued through Azure AD B2C using WS-Federation and reaching the AD FS. Thereby terminating the session in both the relying party, Azure AD B2C and AD FS.
If so, how is that configured in Azure AD B2C with custom policies?

Azure AD B2C does not support signing you out from the external identity provider, be it Facebook, Google or a custom OIDC/SAML/WS-Fed identity provider. It only signs you out from Azure AD B2C.
That practice is highly discouraged as it's quite invasive on the end user and risks discouraging the user from doing SSO, rather opting for local accounts.
For example, if the user signed in using Facebook and then signs out of your application, they'll probably be very annoyed by the fact that they've also been signed out of Facebook and after enough times of this happening, might give up on SSO using Facebook and just create a local account that doesn't messes up their experiences elsewhere. A similar case could be made for business customers that, by signing out of your app, also get signed out of all of their other business apps.
All that said, you can still request support for this via the Azure AD B2C feedback forum.

Related

Can the MSAL API be used with B2C only - or B2B application too?

We're considering to use Azure AD B2B OR B2C for SSO service. We will not be using Azure B2B built-in SSO login page OR B2C custom-policies based login page. We've our own custom login JSP page that we plan to use MSAL Graph APIs for calling Azure AD authentication services.
Questions:
Is this MSAL APIs applicable to B2C only, or can we use this with B2B tenant application as well? All the documents and guidance that I can take as an example uses B2C tenant app only.
If I am using MSAL OAuth 2.0 authentication services for my custom login page, I assume we don't need to rely on SAML SSO configuration. Or would it be possible to use mix of these services (i.e. SAML for basic login authentication, MSAL OAuth2.0 calls for self service account registration)?
I appreciate if anyone can shed some light on this.
Thanks.
B2B and B2C serve two different purposes. B2B is meant for you to use to invite external federated users to your directory using their own credentials whereby you can assign them access directly to your resources. On the other hand, B2C is a separate directory where you allow users to register, optionally using their own credentials from federated providers as well. If your aim is to SSO to a local AzureAD protected resource, then clearly you're going to have to tell that resource to use the B2C directory as an IdP as well. Hence, B2B is much simpler for SSO, but a big differentiator is scale. If you plan to invite a massive number of users, then this it is not a good idea to user B2B.
MSAL uses standard protocols such as OAuth 2.0 and OIDC to authenticate directly to any supported IdP, including Azure AD or Azure AD B2C. Being a guest user or not has no bearing on that process. It is also important to mention that B2C does require either a User Flow or a Custom Policy to function.
So to answer your questions to the best of my ability:
1- MSAL libraries work similarly for both Azure AD and Azure AD B2C. There may be some configuration differences in case of B2C to supply additional information regarding the policy name, etc. But they work all the same.
2- MSAL itself does not support SAML authentication. For that you'll need a library which can perform SAML authentication. While Azure AD supports SAML natively, Azure AD B2C requires you to setup a custom policy to configure SAML authentication.

Sign in to Azure B2C with a Google Service Account

I'd like to start with a Google Service Account credential (either opaque access token or ID JWT) and end with an Azure B2C credential. Is something like this possible with Azure? I'm not seeing any APIs for doing it: https://learn.microsoft.com/en-us/azure/active-directory-b2c/openid-connect
Note: this is conceptually similar (but different in terms of target identity) from another question I asked earlier:
Impersonate Azure Service Principal from a Google Service Account
EDIT: Our use case for this is exchanging Google Service Account credentials that represent an untrusted client (e.g. a user in the system), for a user token in Azure B2C. Unfortunately, this eliminates the client credentials flow, as mentioned in the comments.
Azure AD B2C only supports interactive federation flows with other identity providers.
Google service accounts are non interactive authentications. The only way AAD B2C can pass these credentials to Google would be through its REST API interface.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/restful-technical-profile
The credentials would need to be hard coded into the policy or through AAD B2C “policy keys”.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/secure-rest-api?tabs=windows&pivots=b2c-custom-policy
From what I can see, AAD B2C REST API interface doesn’t support an authentication method that Google needs. So I would conclude it’s not possible.

Has a way to enable Microsoft Authenticator in Azure AD B2C?

In my project, this a fundamental part of project. Windows Hello for Bussiness and MS Authenticator is secure and easily to use, the goal here is enable this in Azure B2C SUSI to increment safety and provide a fast way to SignIn for user.
The point is, has a way to do that in B2C? Replace normal password to a paswordless way authentiation
There is a possibility to achieve Multi factor authentication using Authenticator app. It is documented and a sample is provider here: Azure AD B2C: TOTP multi-factor authentication
With Azure Active Directory (Azure AD) B2C, you can integrate TOTP-based Multi-Factor Authentication so that you can add a second layer of security to sign-up and sign-in experiences in your consumer-facing applications. This requires using custom policy and custom REST API endpoint. If you already created sign-up and sign-in policies, you can still enable Multi-Factor Authentication.
Below is the user auth flow using TOTP:
At this time, MS does not support primary Auth using Authenticator for B2C. You can request this via the Azure AD B2C forum in feedback.azure.com
SMS and Phone verification are the options available as of now.

When should you use Azure Ad B2C

Is there something you cannot do with Azure Ad in which case you would use Azure Ad B2C?
One of the best use case of using Azure AD B2C is it allow users to sign in to your application with credentials from external social or enterprise identity providers (IdP). Azure AD B2C supports external identity providers like Facebook, Microsoft account, Google, Twitter, and any identity provider that supports OAuth 1.0, OAuth 2.0, OpenID Connect, and SAML protocols.
With external identity provider federation, you can offer your consumers the ability to sign in with their existing social or enterprise accounts, without having to create a new account just for your application.
Please refer these documents for more information.
Regarding technical comparisons between Azure ad b2b and azure ad b2c please refer Document
It’s very dependent on your user base. If you are serving an enterprise audience you would not use B2C but many public facing apps do not need you to login with your organisational email. Is there a use case that you have in mind, might be a good discussion if you do?
Azure AD now allows social logins via external identities.
Azure AD is typically for corporate customers that are mainly domain-joined e.g. email is joe#company.co.nz.
Azure AD B2C is for a non-corporate customer - not domain-joined e.g. email is joe#some-smtp.co.nz.
B2C also caters for people that don't have an email address e.g. via phone with an OTP.

Difference between adfs and azure AD

Differences between ADFS and Azure AD
I understand that ADFS is a STS (Secure Token Service) in the sense that it issues tokens to applications that helps applications establish user identity. At an organization level, our org uses ADFS with WS-Federation protocol to authenticate users across all internal application of organization and also implement SSO.
Also in our organization we have Azure AD account, and I have used Azure AD to register our custom apps, and whenever an unauthenticated user enters our app, the person will redirected to azure ad login page and will have to authenticate himself. After successful authentication Azure AD also issues token(ID Token, access token, Refresh Token)
My question is that can I consider Azure AD also a type of STS (Secure Token Service) just like ADFS because it issues tokens to establish client identity?
ADFS only handles authentication and authorisation. It does not handle user provisioning.
In that sense ADFS is not an Identity provider, It's just a STS.
You need separate instances of ADFS (auth.) and AD (user). AAD combines both.
As its name implies ADFS is a federation layer that sits on top of AD.
Also, ADFS is an R-STS in that it can be in the middle of a federation chain. It can handle upstream and downstream requests . AAD can't - it is always the endpoint.
ADFS has the power of claims rules, AAD has no such concept.
Both work as a secure token service.
These are two different services of course, and usually you are responsible for the ADFS infrastructure, while you are not responsible for AAD infrastructure.
Azure AD can also federate authentication to ADFS if you have user sync enabled with Azure AD Connect.
In that scenario Azure AD redirects the user to ADFS to authenticate, and trusts the answer ADFS provides.
From the point of view of apps it makes no difference how a user authenticates against AAD.

Resources