Hi @tl-fa,

You can view our Roadmap Guidance regarding how features are implemented into FusionAuth. A good snapshot of current development can be found here as well.

We will certainly update any related issue cards as development moves forward!

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?

That is an encoded (signed) JWT being sent in response to the user info request that the FusionAuth OIDC identity provider is making.

This is technically allowed in the OIDC spec, but we do not currently support this response type.

Per spec, the endpoint should support a JSON response which is the default unless the client requests a signed or encrypted response body.

I would look at how your client is registered and see if it is asking for a JWT userinfo response at that time, and change it to be a normal JSON response. You could also file an issue detailing your needs for FusionAuth to support this user info response type.

If that isn't an option, you could also look at using a SAML Identity Provider if the remote identity source supports that.

While FusionAuth supports both well, if you have the option to use SAMl v2 or OIDC, I would always recommend OIDC.

In general, it is much much simpler to use, debug, configure, etc.

It sounds like you're asking if you can modify the issuer claim.

You can control the "Issuer", or iss claim, in two different ways:

You can set it in the tenant config, where it will apply for all JWTs issued for that tenant. You'd modify that by navigating to "Tenants", then your tenant, then "General". Modify the "Issuer" field value to be login.example.com. You can set it at the individual JWT level by modifying the JWT populate lambda. You would do this if you wanted to have a different issuer based on some information from the user or registration data. (This does not appear to be the case here, just including this for completeness.)

I'm not clear if you have more than one tenant in your system; if you do, you can either change the "Issuer" setting for the default tenant (which is what is provided when no tenantId is on the URL) or request the endpoint with a tenantId appended, like this:

https://login.example.com/.well-known/openid-configuration?tenantId=<tenantid>

That should work ok. The only reason not to do it this way - is because you’re sort of emulating the OAuth frontend’s usage of this API which in theory is subject to change.

Re: state, additional key value pairs will be stored, however if our front end is consuming the URL, you won’t have access to the API response which will contain that state information.

We have users that have been successful in configuring with AD v2. We have not yet tested or updated the documentation.

This may be helpful. https://github.com/FusionAuth/fusionauth-issues/issues/855

The JWT TTL can be configured per application, so if you were using a different application for OIDC vs an API - then you could do it.

But if you don't want to use multiple applications, then it is not possible, at least currently.

I could see a use case for asking for a JWT with a TTL equal to or less than the configuration and that request being honored, that could be a feature request. But as of right now, the only option is different applications.

These are generated in the UI. So the values are not available from the API.

However you can derive them yourself as well. We just take the URL + /oauth2/authorize?... + redirect_uri etc.

Yea, that flexibility would be ideal IMO, although the registeredLogoutURLs should be workable for us at this point. FWIW that is actually the behavior I assumed before digging into the docs. I'll definitely add the issue to GitHub, as I think it's probably part of the path to getting OIDC Certification which appears to already have an issue.

Thanks!