Just to confirm, are you saying that you’re seeing Skuid send a state parameter to the Authorize Endpoint URL (e.g. /authorize), or to the Token Endpoint URL (e.g. /token)? The OAuth 2 spec requires that a conformant server be able to accept a state parameter from its Authorize Endpoint URL, but does NOT indicate that a state parameter should be sent to the Token endpoint URL. If Skuid is sending a state parameter to your Token endpoint URL, that’s a problem and we will look into it.

It’s the authorize endpoint. I’ll see if I can track down more information on what our auth provider is not liking. I’m guessing it’s a config issue with the auth provider. Looks like it returns a 500 internal server error from disk cache only when the state is present. If I remove the value of that parameter and paste into a browser it reaches the authentication provider. Are you familiar with any issue like that?

Speaking with our internal teams, I’m hearing I also need the response_type parameter changed to code. I have the authentication provider set to Authorization Code - that should do that, right?

Re item 1: this is totally implementation-specific. Not sure what service you’re using, but for the service to be OAuth 2 compliant, its Authorize Endpoint MUST accept a state parameter, or it’s a non-compliant implementation. So I would definitely reach out to whoever owns the service and request that they support the state parameter in order to be OAuth 2 compliant.

Re item 2: yes, Skuid should be sending “response_type” = “code” when you’ve configured your Auth Provider to use the Authorization Code grant type.

Thanks Zach

Still trying to work with our team to identify the state issue.

I reconfigured the authentication provider and data source. However, I still found response_type set to token as opposed to code - screen capture attached. Any thoughts?

Have you specified a Token Endpoint URL?

Also want to confirm, your Data Source has “Use Proxy” set to true (checked), correct?

Went back and looked at your video — you need to check “Use Apex Proxy” on your Data Source.  We only support the Authorization Code grant flow if you are going through the proxy. What we do right now if you are NOT going through the Proxy is to switch to the “Implicit” grant type, which would explain why you’re seeing “response_type=token” because that’s what happens as part of the Implicit grant type.

We should probably try to make it impossible to select an Auth Provider that uses Authorization Code for a Data Source that has “Use Apex Proxy” disabled, as we technically don’t support this at all.

Awesome thanks - that did the trick.

Hopefully I can get the other issue worked out with the team then. Thanks again.