When a user is redirected back to the expected redirect_uri, they’re returned with state and code url parameters, but on refresh this causes issues, specifically a missing transaction: invalid state error. Is this expected behavior? The below is an example of the issue on the sample app found here.
The closest thing I’ve found to a solution to this issue feels like a monkey patch fix from another post here where they do something along the lines of html.window.history.pushState(null, 'home', '/'); (this is a Flutter translation from the original post answer) I’m hoping to find a more direct solution
Is there some additional set up I need to do on my tenant to enable this functionality: “This will log the user in without the login page displayed if the seamless SSO feature is enabled on the tenant.” - I do not see any settings similar to this in our tenant, from what I gathered, this is enabled by default for newer tenants, but is there a way for me to confirm that this is the case?
The 2nd work around, showing a pop up login, doesn’t seem like an ideal solution as the user just logged in and we’d be asking them to login for a second time almost immediately.
I don’t know if it’s worth mentioning, but when I remove “&state=…” from the url, the error does not show and the application renders as expected.
I had 2 causes of this error, from what I remember. Also should specify that my use case was only for Flutter Web.
The state parameter remaining in the url
The only way I was able to remove the appended state parameter was to add setPathUrlStrategy(); in my main() function and then on the MaterialApp I added
My application doesn’t make use of routes, so this worked for me, though I’m sure it can be further tailored if you have routing. But what it does for me is basically set all routes to / which got rid of the state parameter and allowed users to refresh without throwing the invalid state error.
Hosting the application on Firebase
When hosting on Firebase, you get 2 default URLs for the application. I noticed that when I clicked on 1 url from the UI it opened the app, did the redirecting, but what being returned to the 2nd url, so this was causing a mismatch from the initiator to the one that was consuming the callback. I had whitelisted both, so eventually just decided to stick to only clicking/whitelisting 1 of the default urls.