Running into an issue with our Open ID Connect Authentication Provider. The current way our registration page has been implemented requires a unique identifier to be passed through the state parameter - which if returned when the user is redirected to the redirect uri causes an error:


I've noticed the following:

  • Salesforce injects a state parameter in the URL of the auth provider when navigating to it from a communities login page - not sure how this is encoded so can't decode it; tried base64. Not sure what the contents of that state is.
  • If the state parameter is blanked; I receive the above error
  • If the state parameter is removed all together, it appears to work

From my analysis, it looks like Salesforce has an optional strictly formatted state parameter used on authentication provider login pages.

Again, the problem is that my companies current authentication provider implementation requires the use of the state parameter for registration. When the registration page redirects the user the user if given the error above. My assumption is that error is due to the fact that the state does not meet Salesforce's syntax.

Can anyone provide insight on what that syntax is, if I can add attributes within the state, or how to configure our SF environment to disregard the state when we pass it over?

  • On top of that, I'm finding the error thrown IS NOT preventing the user from authenticating. If I receive that error and navigate to my community I can access it just fine. It appears the state is how Salesforce knows to redirect the user into the community.
    – zainogj
    Jan 15, 2018 at 14:20
  • Curious are you using the OOTB Auth Provider or writing a custom one leveraging the AuthProviderPluginClass?
    – compski
    Apr 14, 2023 at 3:25
  • If I remember, OOTB.
    – zainogj
    Apr 15, 2023 at 11:38

1 Answer 1


Not an ideal solution, but it does solve the issue.

Given the user is authenticated, the user can be redirected into the application. Given Salesforce directs the user to the error page, the error URL can be set as the application URL. This leaves them in an authenticated state on the correct page of the application.

The downside is, you are leveraging the error URL as a redirect... which sounds like something that should not be done. Also, if it is a legitimate error and the user is not authenticated, they will get the 404 - Page Not Found error page which is very misleading and a bad experience for the user.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .