Guide to migrate from using the public key (& HMAC) to a Connect session.
If you use the Nango public key in your frontend, you are impacted by this migration.
To check if you are using the public key, inspect your frontend code where the Nango
object is instantiated. If the config
parameter includes publicKey
, you are affected. If it uses connectSessionToken
, you are already up-to-date.
Public keys and HMAC signatures will be supported until July 31, 2025 (six months from the announcement on January 31, 2025).
For security reasons.
If you were using the HMAC signature (strongly recommended in the docs), your authorization flow was already secure. However, not all users implemented HMAC, and we want to enforce best-in-class security practices by default.
For those not using HMAC, the risk of attack was minimal but theoretically possible. We have no reports of such attacks, but feel free to reach out for more details.
connection ID
+ integration ID
) to a single unique connection ID.The Connect session works with both the pre-built authorization UI and custom authorization UIs. Custom authorization UIs are not being deprecated; they remain a critical feature and fully supported.
The deprecated public key, however, was only compatible with custom authorization UIs and did not support the pre-built authorization UI.
Follow the steps in this guide, focusing on these key changes:
Finally, remove all usage of the public key and HMAC from your frontend.
Questions, problems, feedback? Please reach out in the Slack community.
Guide to migrate from using the public key (& HMAC) to a Connect session.
If you use the Nango public key in your frontend, you are impacted by this migration.
To check if you are using the public key, inspect your frontend code where the Nango
object is instantiated. If the config
parameter includes publicKey
, you are affected. If it uses connectSessionToken
, you are already up-to-date.
Public keys and HMAC signatures will be supported until July 31, 2025 (six months from the announcement on January 31, 2025).
For security reasons.
If you were using the HMAC signature (strongly recommended in the docs), your authorization flow was already secure. However, not all users implemented HMAC, and we want to enforce best-in-class security practices by default.
For those not using HMAC, the risk of attack was minimal but theoretically possible. We have no reports of such attacks, but feel free to reach out for more details.
connection ID
+ integration ID
) to a single unique connection ID.The Connect session works with both the pre-built authorization UI and custom authorization UIs. Custom authorization UIs are not being deprecated; they remain a critical feature and fully supported.
The deprecated public key, however, was only compatible with custom authorization UIs and did not support the pre-built authorization UI.
Follow the steps in this guide, focusing on these key changes:
Finally, remove all usage of the public key and HMAC from your frontend.
Questions, problems, feedback? Please reach out in the Slack community.