@trevorr,

Based on what I am seeing here, I don't believe this is an issue with FusionAuth, but if you discover something else, please let us know and we can file a bug report.

As you might have indicated, my instincts are telling me you had a popup rule blocking the required dialogs or that something in Privacy Badger does not like a combination of the "post" and something else about that URL. You could try disabling certain "privacy rules/settings" (not very familiar with Privacy Badger) to see if that alleviates your problem.

Let me know if you find anything further!

Thanks,
Josh

First did I miss a good doc/post somewhere explaining how to use slack as an Identity Provider ?

Nope, sorry, we haven't documented that yet.

Second what I could have done wrong, how to correct it ?

I'm unsure. In fact, I'm sorry, from reading this it sounds like you've got it working (except having to give permissions multiple times). What am I missing?

Then does someone manage to get it work with slack's oauth v2 api ?

I have not heard of anyone doing this successfully.

Last why do I have to give permission again & again when I login ?

I'm not sure why Slack would require that again and again. Is the token being stored in the registration object? You can see this if you look at the user and then look at the source tab.

Do you have the docs for the slack OIDC identity provider handy? Have you seen if anyone else is seeing this behavior?

You would have to add a hook in your IdP to make an API call to delete the user in FusionAuth. However, because the SoR will no longer have this user, the use will not be able to log in via FusionAuth either unless their password is reset.

We have discussed adding support for SCIM which may provide some of these types of features assuming other IdPs also support this standard. This is on the roadmap: https://github.com/FusionAuth/fusionauth-issues/issues/106

We don’t currently support IdP initiated login.

This has come up a few times, we’ll likely end up adding it, but for now it is not possible. We have an open feature for this in GitHub.

Please feel free to upvote it or otherwise communicate your desire for this work to be done.

As far as I know it is not possible, I believe Google builds that text based upon the redirect_uri. I would assume you'd only see the fusionauth.io domain listed if you're using our hosted URL. If you are using an enterprise plan with a custom domain (login.example.com) you shouldn't see fusionauth.io mentioned.

I know in the Google cloud console where you configure your credentials there is a customization option for the consent screen, but I do not know if that will modify this account chooser or not.