401 & scoped packages

Update: We rolled back this change around 2pm PST today, but will be rolling it out again soon.

Did you recently get a 401 or an EINVALIDNPMTOKEN error when trying to interact with scoped packages? This is the result of some recent changes we made and is not related to any security incidents. Yesterday we deployed a change to the Registry that made invalid tokens return 401 responses when used to lookup scoped packages, whether they are publicly visible or not.

There was also a bug that caused the tokens created via npm token create to report EAUTHIP errors when used, but it was fixed last night. Note that tokens created via npm login or the website were not affected by this issue. You may also recall that we invalidated all user tokens in July, so that may be the reason you are getting a 401.

How to fix the issue

First, you can verify your token by running npm whoami. If it’s invalid or you got the 401 previously mentioned, run npm login to create a new token and you are good to go.

What’s next

This change is part of many we plan to bring to our authorization flow to help us scale the Registry and make invalid tokens clearer for users. We are planning to roll this behaviour out to all package reads — scoped and unscoped. Additionally, we will no longer support Basic auth used in conjunction with 2FA (two-factor authentication). Our recommendation is to use tokens, which are safer and support usage restrictions.

Watch this space for future updates about our infrastructure changes.