Kindly follow the below steps, I hope it helps
1. Leverage Cross-Domain Authentication
For SSO to work across different websites (yours and the third-party site), both websites must be able to share the session or access tokens. This can be achieved through a combination of authentication tokens and browser mechanisms like cookies or local storage.
Here’s the flow:
- Authenticate the User: The user logs in to your website (via iframe, as you already have set up). Once authenticated, Azure AD B2C will issue an ID token (and optionally an access token if needed).
- Access Third-Party Website: When the user clicks on a link to the third-party site, the third-party site should recognize the user as already authenticated. This is where the SSO magic happens.
2. Enable Cross-Domain Authentication
Azure AD B2C uses OAuth 2.0 and OpenID Connect for authentication. For SSO, the authentication flow should allow the same token to be passed between your domain and the third-party domain.
To enable SSO, follow these steps:
a. Enable Azure AD B2C as an Identity Provider for the Third-Party Site
You need to configure the third-party website to trust your Azure AD B2C tenant as an Identity Provider (IdP). This can be done via OAuth 2.0 or OpenID Connect.
- The third-party website should configure Azure AD B2C as an OpenID Connect provider.
- Client ID and Secret: On the third-party site, configure the application to use the Client ID and Client Secret you get from Azure AD B2C.
- Redirect URIs: Ensure the third-party site registers the correct redirect URI in Azure AD B2C, so the user can be redirected back after authentication.
b. Configure Cross-Domain Authentication (CORS and Cookies)
For the SSO to work across domains, ensure that:
- CORS (Cross-Origin Resource Sharing) settings are properly configured in Azure AD B2C to allow your website and the third-party website to communicate with each other.
- Third-Party Cookies: Depending on the browser, third-party cookies might be blocked (especially in Chrome and Safari). This can cause issues with sharing authentication tokens. To work around this, consider:
- Using same-site cookies or JWT tokens to maintain the user’s session across different domains.
- If possible, both your website and the third-party site should be under the same top-level domain (for example,
www.yourdomain.com
andapp.yourdomain.com
). - Alternatively, use browser-based local storage or session storage to store the ID token on your website and pass it to the third-party website through URL parameters or POST requests.
c. Handling Token Sharing
After the user is authenticated on your site, you can send the ID token (or access token if needed) to the third-party website when the user clicks on the link. Here are the common ways to achieve this:
- Redirect with Token: On your website, when the user clicks the link to the third-party site, you can redirect them with the token as a query parameter:
https://third-party-site.com?access_token=<JWT_TOKEN> ```d. **Token Validation at the Third-Party Site**
Once the third-party site receives the token, it needs to validate it with Azure AD B2C. To do this:
- The third-party site should use the Azure AD B2C metadata endpoint to validate the token. This endpoint provides information such as the signing keys that can be used to validate the token's signature.
The endpoint URL is typically: **https://<tenant-name>.b2clogin.com/<tenant-id>/v2.0/.well-known/openid- configuration** ```- If the token is valid, the third-party site can consider the user authenticated and allow access.