Could any please explain the difference between Okta Social Microsoft IDP and Azure AD Enterprise IDP from the User Perspective point of view. The steps provided in Microsoft are similar to those required to register an application in Azure Portal. Social Microsoft only requires Client ID and Client Secret, while Azure AD requires Open ID end points information. is it case like users of azure ad idp cant use social microsoft and vice versa. Would be good if anyone can give use case for both IDPs
There are differences between the two, especially when it comes to the endpoints used.
If configuring Azure as an OIDC IdP in your Okta org, then you will be providing tenant specific endpoints for Okta to make requests to to log users into this IdP (as mentioned in our guide here). When using the Microsoft Social IdP, the endpoints are not tenant specific.
I assume that there are also going to be limitations on what users are able to log in via this IdP, where only users within your Azure tenant can use the Azure AD OIDC IDP, whereas the Microsoft Social provider will work for any Microsoft users, regardless of tenant. If you only want to allow internal users to use this IdP, you will likely want to set up an Azure AD OIDC IdP instead.
Honestly though, you’re going to find more thorough information from the Microsoft side about the difference between these two.
1 Like
So i am assuming because Social Microsoft IDP in Okta is for all Microsoft Accounts (Personal) it does not require any endpoints information and will work with Client Id and Client Secret. This will allow any tenant user right??
Okta already has the endpoint information when using the built-in Microsoft Social IdP within Okta, so, right, you only need the client credentials detail from the IdP to complete the connection. And yes, it is my understanding that the Social IdP would allow users from any Microsoft tenant (enterprise or personal) to access your org
1 Like
Can u give some information on how Okta has Endpoints information for Social IDPS, like any documentation where it has mentioned or mechanism by which it gets this information. Thank you for responses.
I don’t see any documentation that discusses this. Our Enterprise IdP connections are a lot like our OIN apps for SSO/LCM etc, where they have been added to Okta after having been configured and tested by Okta.
If you do encounter an issue with one of these Identity Providers, definitely let us know (by reaching out to support) so we can investigate this further.
I tried to create Open Id IDP using Common end points from my Azure Entra ID which has account type as (Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)) such that all users with a work or school, or personal Microsoft account can use your application or API. This includes Office 365 subscribers. so that it will take personal microsoft accounts as well tenant specific accounts as well but it gives error com.saasure.platform.services.idp.exception.IdpAuthenticationException: Issuer is invalid in id_token
What we want to achieve is single open id idp in Okta which will permit all types account which microsoft provides e.g. single tenant, multiple tenant.
Another thing i am failing to understand is when i am using Microsoft social idp instead of Open id and just provide client id, client secret it works
is their anything that i am missing, i have verified urls they are correct
Double check the “Issuer” value you set in the IdP config. I did a quick check in our logs and I’m seeing that the token validation is failing (when we go to validate the tokens we received from Entra), and it looks like the failure is because the issuer in the token does not match the one configured for the IdP, namely that the tenant ids are completely different.
Based on our logs, the ID token we received from Entra has an iss value of https://login.microsoftonline.com/9188040d-xxxxxxxxxxxxxx/v2.0, but the OIDC Identity Provider created in Okta says that the Issuer will instead be https://login.microsoftonline.com/62962632-xxxxxxxxxxxxxxx (both of these values have been masked), demonstrating that the tenant IDs are different AND the token’s iss value ends with /v2.0
I will say that for your use case, it sounds like the built in Microsoft Social IdP will be a better fit for you if you want to allow any user with a Microsoft account access to your org/apps and not just ones associated with your Microsoft tenant.
The validation I described above is going to cause you problems otherwise, as Okta will only accept tokens that were issued by the expected issuer.
i checked using token end point of microsoft application to see issuer in id Token,
and got issuer url from it and it does not use tenant-id that i was expecting it nor does it used common, bit surprising from micrsoft end.
Thanks for the help.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.