We are using Azure B2C to provide Single Sign-On to our clients for a few systems. Currently, we offer Azure AD, Microsoft Account and Google as social account / external IDP options and local account with the Azure B2C tenancy for clients who are with neither.

One of our clients uses Okta as their identity provider and they have asked to have Okta set up as a Single Sign-On option.

I've looked at a few questions in the Okta Helper Center regarding Azure B2C integration and the articles referenced tend to assume that Azure AD or Azure AD B2C directories are being integrated into Okta.

The answer to this question provides a reference to setting up Azure B2C policies (https://support.okta.com/help/s/question/0D51Y00005wCKdeSAG/azure-b2c-intergration-with-okta?language=en_US). I'm fairly comfortable with that side of things, as it's likely to look similar to the Azure AD policy that uses OpenID Connect.

The answer to this question references articles for adding Azure B2C as an IDP for Okta, which is not quite what I'm after (https://support.okta.com/help/s/question/0D51Y00009QXXQLSA5/how-to-integrate-okta-as-idp-in-azure-b2c?language=en_US).

I've also been reading the various guides on creating Authorization Servers, building a Single Sign-On integration and requesting user consent, but it's hard to track which parts are required for a B2C integration, given that Azure AD and Google integrations are well documented somewhat seamless.

The goal is that any Okta client would be able to select the Okta sign-in option, grant consent and this would allow claims to be passed back to Azure B2C.

I understand that individual Okta tenancies may have to grant consent to allow their users to connect to the application. If that is a correct assumption, could you forward me to an article that describes how that is done.

Given that the Azure B2C policies will need to target an individual Okta tenancy, I'm assuming that we would need a tenancy that other Okta members are added to as B2C members as they provide consent for the application and individuals add authorize consent as a part of the login. An equivalency for Azure AD is to add a global / common discovery URL (https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) and a ValidTokenIssuerPrefix (https://login.microsoftonline.com/) and which tenancy the login actually comes from is neither here nor there. Initially, an administrator for their tenancy is required to sign in via the same method and grant consent to the application (the process in the previous paragraph). Since I've only seen references to individual tenancies, I'm assuming that the Okta tenancy would be ours and B2C users would be added to that.

I'm also after information on which components would be required to set up such a scenario based on the pricing models available. This scenario probably doesn't fall into the One App Edition as listed at https://www.okta.com/au/pricing/*customer-identity-pricing. But we would probably require at least API Access Management, perhaps SSO Integrations and perhaps Workflows.

In such a B2C situation, would MFA options defer to the policies of the consumer tenancy, similar to what Azure AD, Google and Microsoft Account have at the moment? i.e. People using social accounts are can set up MFA as they want to (or don't want to).

We would probably want to do a setup for development / proof of concept purposes initially and then so a full setup for production. Would the developer account be able to provide enough functionality for a proof of concept, perhaps limited via a whitelist of email addresses that can be used for authentication (similar to Google) and does not require full publishing?

Regards

Reuben Helms