OAuth-in app and scopes

Apps & Clients
1

@nayelyz @Itati

I have a browser-based tool (with backend) much like the advanced MySmartThings app, but offering some additional capabilities. It was originally implemented to use PATs, which has worked great. I’m now converting it to use oauth, but am running into some issues that might be showstoppers. I’m hoping you can help me.

1) When creating an oauth-in app using the CLI, there is a very limited list of scopes to choose from. Specifically, here is the list available via the CLI prompts:

r:devices:*, w:devices:*, x:devices:*, r:hubs:*, r:locations:*, x:locations:*, r:scenes:*, x:scenes:*, r:rules:*, w:rules:*, r:installedapps

but here is the list I need, based on the various API calls my app can make for the user:

r:apps:*,r:channels:*,r:customcapability,r:deviceprofiles,l:devices,r:devices:*,w:devices:*,x:devices:*,r:drivers:*,w:drivers:*,r:installedapps:*,l:installedapps,r:invitations,r:locations:*,x:locations:*,r:rules:*,w:rules:*,x:rules:*,r:scenes:*,x:scenes:*,r:schedules

2) When redirecting to the SmartThings Login page, you present the user with a list of locations with only one to be selected. However I need to allow users to select from their list of locations from within my app and perform various API calls accordingly. I don’t want them to have to sign out and sign back in again every time they want to switch to a different location. (Using PATs, there’s no issue.).

Unfortunately the login page is returning a server error for me right now when a location is selected, but before the ‘Authorize’ button is even clicked, which is a whole other problem. Let’s deal with that separately.

Is the oauth process intentionally designed to limit API access as I found above? Is there a way to provide a more expansive list of scopes when creating an app with the CLI? And is the oauth login process always going to limit me to a specific location?

2

It may be possible to add some extra scopes via the CLI (it falls under the apps:oauth section) but I think the problem you will hit is the same one that has left me desperately clinging on to about three remaining PATs to avoid rendering an app I have been working with for seven years effectively useless. The issue is that PATs work at the USER level and you need that to a) access user account specific things such as apps and device profiles, and b) see all your Locations at once.

The OAuth-In apps work at the LOCATION level, giving you access to a single Location, but the API Reference implies you can opt to use the USER level too, and indeed that is what the CLI is using. However I had no joy with this. @nayelyz made some enquiries and it turned out that USER requires bespoke tweaks on the ST end and is more of an internal thing.

So that was me hosed. There doesn’t seem to be any way to get a renewable USER level token. Even being able to create a 24 hour PAT via an API call would be helpful.

I have also had many issues with scopes, though probably more with Webhook apps. The API reference, the CLI and the Developer Workspace are gloriously inconsistent about what is needed and what is available (things like w:devices versus w:devices:*) and bizarrely the API Reference mentions the mobile and service scopes as if they are public knowledge. On many occasions I have created an app with a list of scopes that couldn’t be authorised. If I split the list in half I could narrow down the problem scope. Then I could do it again and again and end up with no scopes left.

I have been known to ‘borrow’ the CLI token when doing stuff manually (it has its own scope that can occasionally do things a PAT can’t). Then I discovered a little while ago that if you logout and log back in to the CLI you get the same token back with it’s original expiry date, and indeed that it keeps working after logout anyway. So if you accidentally expose your CLI token (or someone reads it from the config file) it is squeaky bum time as you can’t disable it.

So if there is a path forward I’d be interested to hear about it too.

3

Like an AI agent?