OAuth2 authentication no longer accepting client_id and client_secret as form fields?

Seth Battis

I've been working with a student on an iOS app, and we noticed recently that when we attempt to authenticate to the SKY API via OAuth 2 using the authorization code flow with a client secret, we were suddenly getting a bunch of errors this week – all `invalid_client` errors.

This hadn't been the case on Monday (same code, same credentials, same app).

After a bit of tinkering, it seems like – empirically, at least – the authorization code flow is only working with a client secret if the client ID and secret are based as a base64-encoded Basic Authorization header. They are seen – I think – but are only generating errors if we send them as form fields in the `application/x-www-form-urlencoded` body of the token request POST.

I haven't played with this in any of our department's existing integrations that interact with SKY API via PHP or Node scripts, so maybe this is just some weirdness of a native iOS app… but I'm perplexed.

My example code (updated to deal with all this) is here:

Has anyone else seen anything like this? Any ideas?

Michael Tims

Hi @Seth Battis - sorry to hear that exchanging tokens with credentials in the body isn't working for you anymore. There haven't been any changes to the OAuth authorization server this week. In general I notice I'm able to successfully generate a token using credentials in the body (via Postman test).

I took a look through our logs and did notice a few of the “invalid_client” errors. The logs indicate the secret is detected in the body (I cannot see the secret of course, but the authorization server detects something is populated in client_secret). I don't notice anything obvious in your code either… So the best I can tell is that the client secret value being passed to the authorization server doesn't correlate with the SKY application being authorized.

Sorry, this probably doesn't help too much, but I did want to at least note that the server does receive some value of “client_secret” when you were sending it in the body.

Seth Battis

@Michael Tims Thank you for that backend insight. I'm going to keep poking at it, and will post if I figure out more!