ecobee api changes, effective dec 1 2020
crackers8199 opened this issue · 9 comments
just got this e-mail, figured i would share here since the client will obviously need some changes to work with the new token format...
Upcoming API Changes Effective December 1, 2020
The following changes will go into effect on December 1, 2020. If you are unsure whether these changes will have an impact on your solution today, we encourage you to discuss it with your technology team, program manager, other stakeholders and ecobee partners.
Access/Refresh Token Format Changes
Starting from December 1, 2020, ecobee access tokens will no longer be returned as opaque 32-character strings. Access tokens will now be JWTs, which are considerably longer and uses a wider character set. Our JWTs follow the RFC7575 standard for JSON Web Signature tokens.
To ensure your application will continue to work, you will need to ensure that your application supports the following changes: Access tokens will be up to 7KB in length, and includes upper/lower case alphanumeric characters, hyphens, underscores, and periods.
Refresh tokens can be of varying lengths and can contain non-alphanumeric characters.
Authorization Code Changes
The Redirect URI associated with your registered application should be a semi-colon separated list of absolute URLs that start with https://. We do not accept http:// protocol links.
PIN Authorization Changes
PINs will become 10 character alphanumeric strings.
This flow is only recommended in situations where a user is interacting with a device that cannot easily use a web-based login form; we recommend migrating to the Authorization Code strategy for a better user experience.
Thanks for the heads-up. The changes seem trivial but unless there's a test server to test this on I won't be able to push any code changes until it goes live and I'm able to test it.
There is supposed to be a way of getting access to a test server, but I am not having much success with this - regular support gave me a different email address to contact, but there has been no response to my message to that address. I have raised another ticket and will report back if/when I get a more useful response. Assuming that the keys are held as regular Python strings and that no assumptions are made about their contents, there should be no need to change anything.
I also emailed their support last week to get access to the test server but they haven't gotten back to me
I've just been notified that for those using PIN authentication, there is now an early access program available. I've just been added to the program and will report back after some testing regarding the longer PIN codes and access tokens.
FWIW...After re-authorizing my app and testing under the early access program, the authentication process works fine with no further code changes (as stated previously, I'm using PIN authentication). The service now returns a longer PIN code (9 digits in the form xxxx-xxxx) a much longer access token, and refresh and authorization tokens of varying lengths.
FWIW...After re-authorizing my app and testing under the early access program, the authentication process works fine with no further code changes (as stated previously, I'm using PIN authentication). The service now returns a longer PIN code (9 digits in the form xxxx-xxxx) a much longer access token, and refresh and authorization tokens of varying lengths.
Well, that's good to know!! I thought there might be some minor changes required specifically to pass the query parameter ecobee_type=jwt when requesting the access/refresh tokens but it seems the following will take care of everything
"After December 1, 2020, all access tokens returned will be JWTs, regardless of whether or not the ecobee_type param is specified. The format for refresh tokens will also be changing. Please see here for more information."
Yes, agreed re: the ecobee_type param. Not sure precisely what the transition plan is regarding already authorized apps though, i.e, whether they will continue to work as per the old authorization mechanism or will require re-authorization to get the longer PIN and JWT tokens. I had to "force" re-authorization for my test app in order to see the changes, otherwise I still received the "older" style PIN/tokens. I also found it curious that though the migration strategy statement states the PINs will be 10-characters or longer, they actually are only 9.
I think if you don't re-authorize your app will continue to work using the old style tokens
This is the documentation regarding ecoeee_type
"Optional. Specify "jwt" to have the API return access tokens as JWTs. If not specified, the API will return opaque access tokens."
Interesting thing I just saw, is that the refresh key using JWT will never expire (i.e. You won't ever need to refresh it)
"Refresh tokens will also never expire (they used to have an expiry of 1 year). It is important that refresh tokens are treated like secrets and are kept safe and secure."
Congrats to fowlerk for getting access to the trial server. I am still waiting for a response from the relevant people!!
The refresh key not expiring is of extremely limited relevance to most applications since (AFAIK) the access key still only lasts an hour, and (again AFAIK) you still get a new refresh key when you renew the access key - or is it now the same refresh key that is returned?