Ok, I found the problem.

I was sending an Authorization header, because that was the default option in Postman. Now I tried it with the other option which is "Send client credentials in body" and it works.

The documentation about the token endpoint had me a bit confused, that's why I kept sending an (invalid) Authorization header. Now that I post an empty client_secret parameter in the body and NO Authorization header to the token endpoint, things are working fine.

Thanks for pointing me in the right direction, @robotdan and @dan.

Ok, I found the problem.

I was sending an Authorization header, because that was the default option in Postman. Now I tried it with the other option which is "Send client credentials in body" and it works.

The documentation about the token endpoint had me a bit confused, that's why I kept sending an (invalid) Authorization header. Now that I post an empty client_secret parameter in the body and NO Authorization header to the token endpoint, things are working fine.

Thanks for pointing me in the right direction, @robotdan and @dan.

@dan, I have tried every possible combination of Client Authentication and PKCE settings. Nothing seems to work. Currently I have this config:

I'm trying to get my browser extension to authenticate against FA using OAuth2. Authorization Code with PKCE seems to be the answer, but I keep getting stuck at the token endpoint.

I'm getting a 401 error:

{"error":"invalid_client","error_description":"Invalid client authentication credentials.","error_reason":"invalid_client_authentication"}

Authentication works great from Postman when adding the Client Secret to the Authentication options, but that defeats the purpose of PKCE.

Do you have a Postman example and FA Application setup to test?

@dan, thanks for the directions.

It looks lik you have a way to make the SSO redirect work for their widget, but not for the portal version of their solution. The portal works with a "redirect" URL parameter that the authenticating party receives and needs to send back after authentication.

I don't think FA supports arbitrary URL parameter forwarding, so this is pretty much a no go directly out of the box.

I'll have a look at the widget, maybe that's a better solution for us anyway.

I'm trying to use the SSO feature of Canny (User feedback tool) with FA and I'm new to this kind of setup. I was wondering if their SSO Redirect approach is something that can be done using FA natively or if I still need to create pages in my web app to handle the login redirects.

My gut feeling steers me towards an Application with JWT populate, but I've never done anything like that. More info about the Canny SSO Redirect is at https://help.canny.io/en/articles/1961021-setting-up-single-sign-on-sso-redirect. Any help would be appreciated.

BTW, another tool I looked at uses the same setup (SSO Redirect), so I guess this is a thing...

Setting the "Allowed origins" in the Application settings did the trick.

To clarify my current MFA delivery setup (v1.25), I have it configured with "delivery": "None" and this enables the Authenticator and backup codes via the Twilio integration.

Will this keep working? Or do I have to update each user and enable the "sms" method? Is it even possible to enable the "sms" method without having a code that was sent to the mobilePhone of the user?