OAuth flow changed?


#1

Hi All,

I have documented the steps to go through the OAuth flow here:

  1. Get the code
    https://graph.api.smartthings.com/oauth/authorize?
    response_type=code&
    client_id=MY CLIENT ID&
    scope=app&
    redirect_uri=https%3A%2F%2Fgraph.api.smartthings.com%2Foauth%2Fcallback

  2. Use the code returned to get the Access Token
    https://graph.api.smartthings.com/oauth/token?
    grant_type=authorization_code&
    client_id=MY CLIENT ID&
    client_secret=MY CLIENT SECRET&
    code=THE CODE&
    scope=app&
    redirect_uri=https%3A%2F%2Fgraph.api.smartthings.com%2Foauth%2Fcallback

But this call fails with the following response:
{“error”:“invalid_client”,“error_description”:“Bad client credentials”}

I’m sure this used to work, but now it fails can anyone tell me why?

(Incidentally I have managed to get OAuth2 to work in Postman using the same Client ID and Secret).

Thanks,
Jason


(Joshua Lyon (SharpTools.io Dashboard)) #2

Once you get the code, try swapping out the code for a token using Incognito mode in whatever browser you are logged in with. It seems that if the browser maintains session state (eg. you being logged in), it will throw the bad client credentials message you are seeing on the second step where you swap out the code for a token.

Based on your example, you might run step 1 from a normal Chrome window, then open up Chrome Incognito (Ctrl+Shift+N) and execute step 2.


Alternatively, you could open up your Chrome Developer tools, open the Resources tab, expand Cookies and select the SmartThings entry, and delete the JSESSIONID cookie between each call.


(Brice; SmartRulesApp.com) #3

After talking with a SmartThings engineer, the solution that we are using for SmartRules is that when you have the code and are requesting the token, you need to add a basic authorization header, using the client ID and client secret as username and password, respectively.


(Tim Slagle) #4

Hey guys!

Yep, the process did change a little. Official documentation coming soon to a documentation site near you.


(Joshua Lyon (SharpTools.io Dashboard)) #5

It seems odd that you would need to do that and I am curious what the reasoning is. I tested this with various tools last night and found that as long the request to swap out the code for a token is sent without the session information, then it would work every time.

Even issuing a basic HTTP GET request via raw TCP connection works fine:

GET /oauth/token?grant_type=authorization_code&client_id=CLIENTID&client_secret=CLIENTSECRET&code=THECODE&scope=app&redirect_uri=https%3A%2F%2Fgraph.api.smartthings.com%2Foauth%2Fcallback HTTP/1.1
Host: graph.api.smartthings.com
Cache-Control: no-cache

PS. I don’t recall having to open up a fresh browser session to get this to work in the past, so it does seem like something has changed. The OAuth workflow has worked for 9+ months with my Android app, SharpTools - I am effectively using fresh HTTP connections each time only adding the necessary headers when needed.


#6

Haha - the Cookie Monster strikes again!

So I tried by closing all browser instances first, then launch a fresh one and I still got the credentials error.

Then I took your advice @joshua_lyon and created an incognito tab and this time it worked!

This is definitely something I didn’t used to have to do.


(Tim Slagle) #7

I’ll just leave this here :smile: