How to maintain Oauth token in cloud to cloud connector

General Discussion
1

I am developing a cloud to cloud connector for a major hardware vendor. So far things are going ok, I’m able to use the configuration lifecycle to get an oauth token from the hardware vendor cloud, that expires in one day.

My question is around renewing the Oauth tokens. Are we responsible for doing this in some sort of cron like scenario? My code lives in lambda so that could be hard. Is there a ping event that will come in per app install and could be used to check the token state?

I really don’t want this app to end up being super annoying like most of the ecobee apps that can never maintain a valid token. Is there any documented strategy that ST recommends?

1 Like
2

Yes, your app can handle token management in whatever way works for you and with the vendor’s APIs. I’m assuming that the vendor also granted you a refresh token as part of the oauth flow. You could try and proactively refresh the token on a schedule like you discussed, or you could check if the token is still valid before making an API call (if the vendor’s token has an expires_in), or you could handle expired tokens by handling failed API calls for token expired reasons (if the vendor API returns a 401 for example, could refresh the token and try again).

3

Is there a regular event per app install id that could be hooked into?

4

There is an INSTALL lifecycle which occurs when the app is installed by a user.

5

That would be a more or less one time event. Im talking about a regular repeating event.

1 Like
6

Seems like maybe the Schedules API is what you’re looking for?

7

Maybe. So I register a schedule for every install and then use it to check/renew tokens.

That seems ok, but it seems like ST could avoid a lot of complexity by having a built in event. I could cron on my own without an event, but theres no guarantee what is in my db will really be “active” users, so I might be trying to renew all kinds of unneeded tokens.

8

I think I’m not understanding the type of event you’re interested in, perhaps you can describe the use case more?

If you don’t want to build in logic to check for “active” users before refreshing your tokens, you could consider other token refresh strategies.

9

By event I am referring to anything that can be hooked into with these traits:

regular intervals < 1 hr
per active app install (per user essentially)

I think it would be wise for smartthings to provide such an event, instead of expecting every app that uses oauth to implement its own schedule register/maintain logic. It would just be a lot easier on devs, and allow then to deploy on things like lambda with less hassle and less to potentially get out of sync. As far as I can tell the ping event only happens on app creating in the dev portal, so it is not useful.

Both Alexa and Google Actions handle 3rd party oauth token refreshes automatically.

1 Like
10

This is what schedules do; you can create a schedule of the interval you want, and your app will be called at that interval for each install.

That’s interesting - can you point me to some docs for this? I’d be interested in seeing that. Thanks!

1 Like
11

Thanks, I agree that schedules API seems to be the way to go for now, its just probably something that every dev who does oauth will have to do, instead of a built in process.

For Alexa/Google you enter you account linking oauth details in a form like this:

Then whenever there is a request that comes to your app, it comes with a valid access token for the linked account. The refresh happens behind the scenes. It could be days in between requests but you always get a valid token. If Alexa/google cannot get a valid token, they redisplay the “sign in” card in the app.

1 Like
12

They also do not expect the dev to do the “Access Token” part.

ST seems to only do the Authorization part, and then throw to the app to do the final “Access Token” request, with some sort of http library.

2 Likes