Hello,
The scenario we have is that we want to swap from using SAML to using OIDC, whilst using the same upstream IdP (same set of users). This is to enable some extra features we get with our upstream when we use OIDC over SAML.
My understanding is that by doing so Auth0 will issue new user identifiers (as it generates subject identifiers from the type of connection, the connection name and finally the received subject identifier from the upstream) and that there is no way to normalise the subject identifier issued within Auth0.
There is support for the ability to link accounts together so a single user can be authenticated from multiple connections, but this requires the user to interact with the upstreams to be linked to their account - authenticating several times over. This doesn’t work for us as we are not challenging them with a different upstream IdP, its the same IdP but the protocol used for the transference of identity is different.
We cannot migrate from one style of subject identifier to another due to our architecture.
Are there any solutions to this?
Many thanks,
Philip.
1 Like
Hi Philip,
If you have sufficient confidence, then you can link user accounts programatically - i.e. without the additional authentication/UI steps - via use of the Management API (see Auth0 Management API v2 for more details). You can do this from a post_login Action (Login Flow), or from a Rule if you’re more familiar with legacy extensibility. And you will want to investigate using the variant of the POST where an API v2 Management API token containing the update:users scope is used.
Hope this helps 
1 Like
Hello Peter!
Thanks for the reply, I have just implemented the linking of the accounts together within the post login event.
Unfortunately this doesn’t seem to work as intended.
If I have a user who has previously authenticated via SAML, and has a user account within the auth0 database already, when that same user logs in via the OIDC route my post login script executes and joins the two accounts together correctly - with the SAML account as the primary.
The identity that gets used to issue the token in this login process is the OIDC account, not the new primary (SAML) account.
This process should issue the token from the new primary account in order for the subject identifier to remain unchanged.
I cannot run this process on the post user registration flow as these are federated users and this flow does not run when a new federated user is seen for the first time.
Many thanks,
Philip.
Thanks for the feedback Philip.
Sounds like you’re performing account linking in an Action; for your particular use case have you tried altering the primary user context as described in Account linking with Auth0 actions? I believe that should give you what you’re looking for
For additional reference Philip, this should be equivalent to setting context.primaryUser within a Rule (see Context Object Properties in Rules for more details).
Ah no, I swapped over to using a rule instead and got that working by setting the context.primaryUser value in there.
I couldn’t find any official documentation on how to do this in an action and I had assumed that the objects being sent into the action would be immutable (or at-least changes to them would be ignored). I made this assumption based on the fact that an api object is passed in and its primary purpose is to allow you to effect changes on the user/flow etc.
I wonder if it makes sense to extend this api object with a call that lets you explicitly set the user id in the same way as setting the user property on the event does?
Glad to hear you got a solution working Philip, and thank you for the feedback too 
There’s definitely still some disparity between our Actions extensibility and our Rules extensibility, however it’s through great customer feedback like yours that we can prioritise narrowing the gap between the two technologies. Thank you
1 Like