Organization API token deprecation

We would like to understand the reasoning behind the deprecation of the organization API token as mentioned in the documentation.

How do other organizations manage the lifecycle of the API token used in their applications? As we are now forced to use user API tokens, instead or organization API tokens, how does one manage renewal of that token if that person is unavailable or leaves the company?

Hi @frisokingma, we plan on shipping scoped tokens soon, and only after that we will completely remove support for org tokens. Scoped tokens will allow any user to create an access token that:

  • only works for a specific namespace (such as an org they’re part of)
  • has specific rights (only read, for instance)

Regarding the problematic you’re raising about a user leaving the org and their personal token becoming invalid as a result, a common solution is to create a machineuser user or similar (not tied to any specific employee), and use a token from this “user”. Would that solution work for you?

Hi @pierric, thanks for your swift reaction. The scoped tokens sound promising for us.

Regarding the machineuser, that would work in most cases. The cases where it might not work is where model authors require the user accessing the model has to have a “real name”, i.e. Llama requires you to request access both on HF and on their website (Llama access request form - Meta AI), where the email has to match.
What do you suggest in such a case?

hey @frisokingma ,

my concern, is that RE the recent security incident, where do these old org-level API tokens since the organization has no visibility of these?

did HF revoke these upon the migration from org to user-based tokens, or at worst have they been migrated to the users-api tokens and only therefore visible within their UI?

if the latter, what is huggingface’s response to this? this makes org-api-token management extremely difficult and seems nonsensical from a security perspective