Moving a project to another org can leave the old org's API keys working

When transferring a project from one organization to another in SaaS products, there is a risk that the old organization's API keys and deploy tokens remain functional. This occurs because the API keys are tied to the project's ID rather than the organization's ID. The authentication middleware only verifies if the key belongs to the project, not the organization. Consequently, even after the transfer, the credentials built during the project's initial setup continue to function within the old organization.

For instance, if an agency constructs a project for a client and subsequently hands it over to the client, the agency's CI token remains active, attempting to push to the project even a month later. This token was issued under the agency's original organization, not the new one. Moreover, the transferred credential does not appear in the new organization's list of keys, as it was generated under the old organization.

To address this issue, organizations need to treat the transfer as a permission change for all credentials associated with the project. One approach is to revoke project-scoped keys during the transfer process. Alternatively, a unique identifier such as issued_by_org_id can be stored on each key. When the key fails to match the project's current organization, it should be rejected.

Following the transfer, the new organization's administrators should be notified of any keys that survived the transfer, along with the original creators of each key, enabling them to decide which ones to keep. To verify this process, one can create a project key in organization A, transfer the project to organization B, and attempt to use the old key with the API.

If the call is successful, it indicates that the old organization still retains access to the project.