Hello @Roald Heiwegen,

There is currently no way to provide a value for the ‘nonce’ parameter through the OAuth connectors that we offer in process flows. However, the nonce should not be considered mandatory by the Identity Provider if the grant type is Authorization Code or Client Credentials. In fact, the nonce should only be mandatory when using the Implicit or Hybrid grant type, neither of which we support because they are not useful from the context of a process flow while also being less secure.

Is it possible that you have selected the wrong grant type / authorization flow in your client configuration at Twinfield? I’m not familiar with the Twinfield client configuration myself, but I found the following screenshot online. It is important that Authorization flow is set to authorization code. If this is the case, then I would find it strange that Twinfield still expects the nonce parameter since the OpenID spec states that it should be optional. The only solution at that point would involve a change to Indicium.

Hi @Vincent Doppenberg ,

Thank you for your response. I have set the settings in Twinfield to "Authorization code." I contacted Twinfield and they indicate that it is mandatory to include this in the authorization. However, the "Nonce" does not need to be unique.

Should I create a ticket in TCP?

Hello @Roald Heiwegen,

You can create a ticket if you want to track the progress of our implementation, but since this is currently blocking you, I have already added this to our current sprint and I intend to deliver it in our next release either way.

@Vincent Doppenberg Thank you very much for your quick action! It is indeed blocking the integration now.

Hi @Vincent Doppenberg ,

Thank you for the update on Indicium! I can now log in to the external application from a Thinkwise application and receive a success message from Indicium.

The Indicium screen closes, but I still see the Thinkwise pop-up regarding the OAuth login.

I don't receive any keys in the variable, and in the error log of Indicium I see the following:

Process action "oauth_user_login_connector_twinfield" in process flow "twinfield_oauth_get_new_access_token" in application 14 returned the following message: "Bad Request"

Process action "oauth_user_login_connector_twinfield" in process flow "twinfield_oauth_get_new_access_token" in application 14 returned the following message: "invalid_client"

I suspect it has to do with the Grant type. When I do the same in Postman with Grant type “Authorization Code” it works. However, if I choose Grant type “Authorization Code (With PKCE)” it does not work. Is it correct that Thinkwise always uses PKCE, and that this might not work in this case?

Hi @Roald Heiwegen,

That is correct. At the moment, the OAuth User Login connector always uses PKCE. It is a little surprising that there are OAuth servers that still do not support PKCE.

I'm afraid that in the current version there is no way to configure whether PKCE should be used or not. Ideally, the solution would be that Twinfield adds support for PKCE, but I understand that this might take some time. It is possible for us to add a configuration setting to OAuth server in the SF, I would recommend creating an idea for this.