Troubleshooting User Linking and Redirect Issues in FusionAuth Azure SAML Integration

wesley

We are setting up both SP-initiated and IdP-initiated login flows with Microsoft Azure SAML for the same users.

We configured two ACS URLs in Azure:

SP-initiated: samlv2/acs
IdP-initiated: samlv2/acs/4e98800a-7123-479f-ace7-92502a9a47dd/39ad6a2d-2559-4b14-9b3e-a611ec4da66a

This setup works but introduces two critical issues:

1. User Linking Issues Between SP-Initiated & IdP-Initiated Logins

When a user logs in via SP-initiated login, FusionAuth successfully creates a user link.

However, when the same user attempts to log in via IdP-initiated login, the system fails with an error:

"This account is already linked to another user. Unable to complete this login request."

The only way to resolve this is manually deleting the user link, after which the user can log in again via IdP-initiated flow.

Questions:

Is this behavior expected? Shouldn't FusionAuth allow a user to log in using both flows without requiring link deletion?
Why doesn't FusionAuth automatically retrieve the IdP user ID during IdP-initiated login to match the user correctly?
Is there a configuration option to change this behavior?

2. Controlling Redirect URLs in IdP-Initiated Logins

Our FusionAuth application has multiple OAuth redirect URLs configured.
During IdP-initiated login, FusionAuth always selects the first redirect URL from the list, ignoring RelayState from Azure.
We attempted to specify a RelayState parameter in the Azure configuration, but FusionAuth does not appear to recognize it.

Questions:

How can we ensure FusionAuth uses the correct redirect URL during IdP-initiated login?
Does RelayState work in FusionAuth for this purpose, and if so, what is the correct way to configure it?

wesley

1. User Linking Issues Between SP & IdP-Initiated Logins

No, this behavior is not expected—you should not need to drop and re-link users every time they switch login methods.

Troubleshooting Steps:

Are these configured as two separate Identity Providers in FusionAuth?
- If so, ensure they are both linked to the same FusionAuth user.
- If they are separate, FusionAuth may be treating them as different authentication sources, causing conflicts.
Is Azure using the same application for both login flows?
- If different applications are used in Azure, they may be sending different user identifiers to FusionAuth.
Enable Debug Logging in FusionAuth:
- Go to System > Event Log and enable Debug Mode in the Identity Provider settings.
- Compare the SAML attributes (claims) being sent in SP vs. IdP-initiated logins.
- If they differ, you may need to adjust Azure’s claim mappings to ensure consistency.

2. Ensuring Correct Redirect URL in IdP-Initiated Flow

Yes, RelayState works in FusionAuth, but there are specific requirements:

Check Your FusionAuth Version

RelayState support was added in FusionAuth 1.41.0+.
If you are on an older version, FusionAuth will default to the first redirect URL in the list.

Correct RelayState Configuration

Ensure the target redirect URL is listed as an "Authorized Redirect URL" in the FusionAuth application settings.
URL-encode the redirect URL before appending it to RelayState.
- Example: https://example.com/welcome → https%3A%2F%2Fexample.com%2Fwelcome
Append the encoded URL to the ACS URL in Azure.

Example ACS URL with RelayState:

https://your-fusionauth-instance/samlv2/acs?RelayState=https%3A%2F%2Fexample.com%2Fwelcome

Test by logging in via IdP-initiated flow and checking if FusionAuth respects the RelayState.

Additional References:

Summary:

User linking issues are likely caused by different SAML claims or separate Identity Provider configurations in FusionAuth. Enable debugging to check for mismatched attributes.
RelayState should work in IdP-initiated logins if you are on FusionAuth 1.41.0+, URL-encode the redirect URL, and ensure it is allowed in the application's settings.