Overlooked this critical part of the post. Not quite so excited now.
"These changes only impact newly issued PATs. As of now we’re not making any changes to existing PATs. We know that of the 40k or so "
Should have had that extra cup of coffee first. 
I’m not sure you’re fully considering how capable malicious actors can be once they’re inside your network. Statements like this can downplay the issue—this is a significant security concern. SmartThings often echoes similar sentiments as ‘good enough,’ but in reality, this PAT discussion feels trivial by comparison.
I am, but would be convoluted given the restrictions and feels like there are ways with less effort needed to attack users (smartphone apps, computer malware, etc.).
Community drivers are optional and most don’t even require LAN permissions so can’t do anything in your local network. If you don’t trust a developer that used the LAN permission in a driver it’s better if you don’t install it from the channel and, instead, build it from the source if available. The channel is a way to simplify the installation and update after all.
The issue I see there is that those who are minded to change their PATs every so often will no longer be able to. I am minded to change mine every now and again. The reality is that I have some ridiculously old PATs because I only normally only change them when I delete them by accident (have I mentioned what a miserable experience the PATs page is in the last five seconds?). The chances of my changing them all in the next two weeks is near zero so I’ll be stuck with the things for months.
No argument. My point was merely that the fact that they were making no changes to the original PAT’s means I have time to work out a long-term solution—and not worry about it over the holidays.
I need to edit that previous post.
The same conclusion that I come to although it all seems so improvised.
Many 3rd party applications will be affected; in my case I use a Samsung application, the Samsung Automation Studio on Node-red, and the reply to my email to them yesterday is
“After the PATs update in SmartThings, there may be difficulties using Automation Studio with the new token.
Future updates will be applied after reviewing any changes in SmartThings’ PATs.”
I don’t feel very reassured.
I’d forgotten about Samsung Automation Studio. I use the Samsung web app rather than my own Node Red and I see there is an ‘under review due to security issues’ comment on the ‘About’ page. I’ve only ever toyed with it because it has never fostered any sense of permanence. Although I recall that it supports being plumbed in to a Location as a SmartApp I don’t know if it can cope with the idea of multiple SmartApps in the same flow and I don’t know if it can act as an OAuth app. The appeal to me was for cross-Location automation for which I used PATs. It is particularly unsympathetic to changes in PATs though.
Unfortunately no, and now even less.
It’s been useful to me to develop my skills in Node-red, using the node in the Node-red pallete, not the rather strange NR clone that Samsung developed. But taking into account that it is using the cloud in most cases, and everything else I have local, I am now thinking in terms of moving ST devices over to MQTT.
I use PATs to create shortcuts in the iOS Shortcuts app (using the “Get Contents of URL” action), which allow me to trigger scenes and control devices via Siri or in the new customizable Control Center on iOS 18.
I wouldn’t have to do that, of course, if the SmartThings app just supported Shortcuts, like Home Assistant, Homey, and tons of other apps do.
Having a problem with a OAuth 2.0 token scope that would allow for creation of virtual devices. It works fine with a PAT. @nayelyz do you know (or can find) what I should be asking for to allow this to work. Here is my current allowed scope with a OAuth flow.
["r:deviceprofiles","i:deviceprofiles:*","r:customcapability","r:hubs:*","r:installedapps:*","w:installedapps:*", "r:locations:*","w:locations:*","x:locations:*", "r:devices:*","w:devices:*","x:devices:*", "r:scenes:*","x:scenes:*", "r:rules:*","w:rules:*","x:rules:*", "x:notifications:*"]
Note: This doesn’t look to be a scope problem, but a creation problem using a OAuth token to create a Virtual Device. Is this supported? And if not, will this be fixed before the PAT expiration change happens?
Hi, @Bloodtick_Jones
I’ll ask the team about this since certain endpoints in the CLI use extra parameters and I’ll get back to you.
Thank you for sharing this.
About the only thing I could suggest is that i:deviceprofiles:* isn’t a thing in the API reference, it is i:deviceprofiles. However the API reference is sometimes contradictory or differs from the actual behaviour.
As that is associated with installing devices using app tokens it might be relevant. PATs seem to be able to create virtual devices with minimal read permissions.
Yea, that is what I am seeing too. It seems to be an internal error and not a scope/permission problem. A PAT can create just using r:devices:*,w:devices:*,x:devices:*.
Hopefully ST engineering can steer a direction.
I gotta say it’s really stupid to wait to announce something that will impact people until just two weeks before it happens, during Christmas.
Why give developers extra stress to hurriedly refactor their projects to OAuth during the holidays???
Making the kill date of new long-lived PATs March 1st or whatever would be reasonable, this is as far away from reasonable as it gets.
It’s so incompetent it borders on malice. Developers are people too.
Just to put it into contrast - while LG got their own in-house developers to develop an official ThingQ Home Assistant integration in order for it to work extra well, Samsung decided to purposefully and arbitrarily break the SmartThings Home Assistant integration for months.
You may not like it, but months is how long SmartThings will be broken in HA if this change is done on Dec 30. Changing major stuff like this there takes months, the notice of this destructive change hasn’t even been replied to yet. Grandfathering in PATs is a stupid excuse, “Don’t buy our products, they’ll only function correctly for previous buyers” is a horrible sales tactic.
I really hope you change course and don’t make SmartThings unusable for months in 10 days, otherwise this is the most self-destructive behavior I’ve seen in a long time.
It shouldn’t be so hard to set a proper changeover date months, instead of days, away from now. Moving away from long-lived PATs is fine, just not overnight.
Hi, @NewsGuyTor
Just to clarify, developers who already have an integration active using their PATs won’t be affected since this change will only impact new PATs, as stated in the announcement.
For the SmartThings HA integration it’s not one PAT per developer, it’s one PAT per end-user:
So everything I said was correct, especially your implied "Don’t buy our products, they’ll only function correctly for previous buyers”
Don’t get me wrong, the change to oAuth is a good thing overall, as it will ease setup and improve security, but the current timetable is insane. If you made a mistake that’s fine, its easy to fix, just set a new reasonable date, but if you don’t this comes across as deliberately malicious.
This is what I was thinking of when I commented about HA only seeming to need a PAT for a very brief period. I can see the PAT is being used to automate the set up of an OAUTH app in SmartThings. How long does that take? It seems like it ought to take seconds.
After that it seems like it is being saved for possible future use purely because it can be and because it would save the inconvenience of creating a new PAT if and when required. Is that not the case?
That is how I am reconfiguring HubiThings as well. You need the PAT to create and delete the ST app and as of current to build any virtual devices (flagged above).
The OAuth token appears to work for all other api functions.
@nayelyz Hi again 
I also have a question regarding this. I briefly looked into the the oAuth documentation mentioned in the post:
If you have an integration that requires generating new PATs for ongoing access, we’d encourage you to refactor that to use an OAuth flow so that it doesn’t rely on issuing new PATs to work in the future.
My main question is that weather its true that it seems that this would require me as the developer of an integration for home-assistant to create a “SmartApp” for all, and even then the “general” “SmartApp” only can be used by 500 users.
At least for me this is kinda unattractive because I’ll be more in the “provider” role than I was before. Beforehand I just “delivered code” and the user had to create the acccess for himself.
While I agree that switching to oAuth generally is more “end-user” friendly as they don’t need to provide knowledge of how to create a PAT, this only stays true if the developer would maintain the SmartApp used for authentication.
Would Samsung maybe at least consider to make creating “SmartApps” easier? Like not requiring a CLI usage or test system? Just like Spotify, Google or other oAuth Providers are doing it. Simply registering a new “Application” where you can retrieve the clientId and clientSecret.