403 Forbidden when using OAuth authorize endpoint for API_ONLY SmartApp

[Pravin81 (Prav)]

SmartThings OAuth-In SmartApp returns 403 Forbidden during authorization

I’m trying to create a SmartThings OAuth integration so MacroDroid can automatically refresh access tokens and control my garage door through the SmartThings API.

My goal is:

MacroDroid geofence (55m) → SmartThings API → Open garage door

I already have this working using a Personal Access Token (PAT), but PATs expire after 24 hours, so I’m trying to use OAuth refresh tokens instead.

What I have done:

• Created an OAuth-In SmartApp using the SmartThings CLI.

• App Type: API_ONLY

• Classification: CONNECTED_SERVICE

• Redirect URI: http://localhost

• Generated OAuth Client ID and OAuth Client Secret successfully.

• Verified the Redirect URI is saved correctly using: smartthings apps:oauth <app-id>

Current problem:

When I open:

https://api.smartthings.com/oauth/authorize?client_id=<CLIENT_ID>&response_type=code&redirect_uri=http://localhost

SmartThings immediately returns:

403 Forbidden - Access forbidden to this app

I also receive the same error when running:

smartthings apps:oauth:generate <app-id>

Things already checked:

• Created a brand-new OAuth-In SmartApp from scratch.

• Verified Redirect URI is exactly http://localhost.

• Tried URL-encoded redirect URI.

• Tried multiple OAuth Client IDs.

• Same Samsung account owns the SmartThings devices and created the app.

• App is visible via the SmartThings CLI.

• OAuth Client ID and Secret are generated successfully.

Questions:

1. Is there an additional configuration step required before an OAuth-In SmartApp can use the authorization code flow?

2. Is http://localhost still supported as a redirect URI?

3. Is there a different authorization endpoint for CONNECTED_SERVICE / API_ONLY applications?

4. Why would both the authorization URL and apps:oauth:generate return 403 Forbidden - Access forbidden to this app?

Any guidance would be appreciated. My end goal is to obtain a refresh token so MacroDroid can automatically renew SmartThings access tokens without manual intervention.

[orangebucket (Graham)]

Is anything actually listening on http://localhost?

The redirect URL is intended to be where your app is running, but if you are just after the code you can use pretty much any website that won’t redirect you somewhere else before you can read the URL. Of course it is impolite to just pick a random website. I used https://httpbin.org/get in a demo as that is made available for public use.

[nayelyz (SmartThings Developer Support)]

Hi, @Pravin81

@Pravin81

1. Is there an additional configuration step required before an OAuth-In SmartApp can use the authorization code flow?

2. Is http://localhost still supported as a redirect URI?

We’ve seen other developers experience issues because they’re using a Localhost URL for the Redirect URI. So, we suggest you use a tool such as Ngrok to create a tunnel for the local port you open using an HTTPS URL.

If the issue is still happening after, we would need to check other details.

[Pravin81 (Prav)]

-Thanks for the information.

My use case is slightly different. I am not developing a SmartApp with a localhost redirect URI. I am using a Personal Access Token (PAT) to send SmartThings API commands from MacroDroid to a Meross MSG100 garage door opener.

Could you please clarify:

1. Are Personal Access Tokens intended to expire after 24 hours?

2. Is there a supported long-term authentication method for personal automations that does not require manually generating a new token every day?

3. For a non-SmartApp integration, would you recommend OAuth 2.0 with refresh tokens, or another approach?

My goal is a reliable long-term garage door automation that can trigger SmartThings API commands without requiring daily token replacement.

[Pravin81 (Prav)]

Thank you, that makes sense.

I was using “http://localhost” as the redirect URI because I was following the OAuth documentation examples and only needed to capture the authorization code manually.

Just to confirm, if I update my OAuth-In App redirect URI to a public HTTPS URL such as “https://httpbin.org/get”, should the standard authorization URL then allow me to obtain an authorization code and proceed with the authorization_code flow?

If so, I’ll recreate or update the OAuth configuration and test -again./.

[nayelyz (SmartThings Developer Support)]

@Pravin81

Are Personal Access Tokens intended to expire after 24 hours?

Yes, this was applied in December 2024. Here’s the announcement about it:

Changes To Personal Access Tokens (PAT)

As part of SmartThings’ ongoing work to improve our platform and deliver a high-performing and secure smart home experience for our users, we’re making some changes to how personal access tokens (PATs) work. PATs were originally intended as a way to test and evaluate new integrations and SmartApps on the SmartThings platform. Since SmartThings provided an easy way to generate PATs over 10 years ago, they’ve been used extensively by our developer community to create and share new devices and unique integrations. Unfortunately, their very nature (easy to generate, very wide scopes/permissions, and basically anonymous) have also become a problem over the years. The use of PATs for long-lived integrations was never their intent and presents a problem for how we manage the platform going forw…

@Pravin81

2. Is there a supported long-term authentication method for personal automations that does not require manually generating a new token every day?

Not for now; the only way to bypass the manual generation is by using the API_ONLY app and the OAuth flow where you can schedule a request to refresh the token.

Here I’ll share some steps that we provide when working with OAuth Integrations:

1. The option to create OAuth integrations cannot be found in the Developer Workspace.
2. You need to use the SmartThings CLI to create this type of app

Command:
smartthings apps:create
---->The type you need to select is “OAuth-In App”
----> Target URL is the link where you want to receive the subscription events
----> These scopes are the permissions whitelisted from your app, if you use a scope in the “authorize URL” not included in your app’s scopes, you’ll get an error
-----> Add redirect URI because that’s where you’ll receive the authorization code once the user authorizes access to your app.3. 4.

3. You can also use the JSON in this sample as the input for the command.
   GitHub - SmartThingsCommunity/api-app-subscription-example-js: Example API Access SmartApp that shows the state and allows control of devices

4. Then, you need to start the OAuth 2.0 process which consists on:

5. Show the authorization page to the user by using this URL:
   https://api.smartthings.com/oauth/authorize?client_id=clientId_from_app&response_type=code&redirect_uri=redirect_uri_from_app&scope=scopes_from_whitelisted_inApp

6. Once the user authorizes access to your app, it’ll redirect you to the “Redirect URI” you configured with the Authorization Code.

7. You’ll exchange this code for an Access Token. This is an example of that request:
   curl -X POST "https://api.smartthings.com/oauth/token" -u "clientId_from_app":"clientSecret_from_app" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=authorization_code&client_id=clientId_from_app&code=codeReceived&redirect_uri=redirect_uri_from_app"

8. The Access Token you get expires in 24 hours.

9. The Refresh Token expires in 29 days if not used. We suggest you refresh the token before this time, otherwise, you’ll lose the Refresh token and the User will need to re-authorize.

NOTE: Remember the OAuth integration has a limit of 500 installations by default. Each time a user authorizes access to one of his/her locations, it will count as 1 installation. This means, if a user has 3 locations and authorizes access to each of them, he/she will use 3 installations.

7. To refresh the Access Token, you need to use the same endpoint but the grant_type is different, here’s an example about this:

8. curl -X POST “https://api.smartthings.com/oauth/token” -u “clientId_from_app”:“clientSecret_from_app” -H “Content-Type: application/x-www-form-urlencoded” -d “grant_type=refresh_token&client_id=clientId_from_app&refresh_token=latest_refresh_token”

Subscriptions in API_ONLY apps

Registering a targetURL isn’t mandatory in this type of application, but if you want to create subscriptions using its installedAppId, you need to include a value for it.

Note: If you have already created your API_ONLY app but didn’t register a value for it, take a look at this post to know how you must update your app to do so: SmartThings CLI apps:update Type Error (reading ‘url’)

Once you have finished creating the app, you will receive a POST request with a confirmation URL, which you need to copy and paste into your browser or make a GET request using it. This is to “verify” the app so it can receive requests with the subscription events.