Does anyone know if the OAuth Client ID and OAuth Client Secret that are generated in the IDE are accessible to the SmartApp? In other words, can the SmartApp read those programmatically?
Never mind! Figured it out.
Would you mind sharing the solution just in case someone has the same question in the future? Thanks!
I want to know too! (20 chars)
Well folks, the problem I’ve been trying to solve was how to generate access tokens for custom SmartThings REST endpoints. The OAuth workflow described in various official docs and forum articles is either largely manual or it involves using external server to receive authorization code, etc. This is all fine and dandy if you really want to connect external web service to SmartThings, but it’s a huge pain in you know where if all you want is to connect your lowly home-brew Raspberry Pi, Netduino, or want not.
So I’ve been looking for ways to automate authentication process. And, lo and behold, the solution turned out to be easier than I thought. Long story short, there’s an undocumented API that generates authentication tokens, effectively allowing the SmartApp to authenticate itself. You can then pass this token to your device, e.g. through HubAction or by other means (copy/paste) and voila, your device can access your REST endpoint without all the hassle of going through the OAuth workflow. Ready? Set. Go!
def token = createAccessToken()
Wasn’t that easy? Note that this function also saves generated token in the state.accessToken variable.
Now, you need to pass two pieces of information to your device: the access token you’ve just generated and the base URL of your REST endpoint. The URL can be generated using this code:
def url = "https://graph.api.smartthings.com/api/smartapps/installations/${app.id}"
That’s all folks. Ta-ta…
1 Like
Ok, this is mentioned here:
http://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/building-cloud-connected-device-types/building-the-service-manager.html?highlight=createaccesstoken#cloud-connected-device-types-building-the-service-manager
1 Like
Shame on me. Should have RTFM. 
Although I’m pretty sure I did read that section. Was it updated recently?
No, I remembered because I came across this before.
API is the strongest point of ST, but the documentation is seriously lacking.
Yeah, I wish documentation were better organized. I must have just overlooked it then. But I did discover it by looking at the Ecobee implementation. Taking my “undocumented” label back.
Hi @geko,
I was under impression (very strong impression) that when you call createAccessToken() repeatedly, it invalidates the previous tokens. I had major functionality built around that assumption.
This doesn’t seem to be the case anymore. Old tokens remain valid.
Do you remember if this ever used to work the way I describe?
Yes, I believe that was the case before the October “upgrade”. Many things got broken or behave differently. Very frustrating…
Ok, at least I’m not crazy. This is very encouraging. I thought I’m crazy. 
How do we “downgrade” it? Since this is undocumented “feature” is there a new undocumented method to invalidate a token?
That’s a good question. Unfortunately, all I can say about ST lately is a bunch of four-letter words.
I hear you. I bet none of these words is “love”.
1 Like