Early heads up: switching away from user API keys
FredZhao-at opened this issue · comments
Hi! I’m Fred, an engineer on the Airtable API team. I’m writing here to share some plans we have to move away from user API keys, with a goal of communicating it early so you have time to triage and prioritize work needed.
First, some context. As #208 mentioned, we recently published a new developer doc site, and announced two new authentication methods, as well as new endpoints and capabilities those methods support: https://airtable.com/developers/web/api/changelog#anchor-2022-11-15
Since these new authentication methods (personal access tokens and OAuth integration access tokens) are much more secure than the current user API key authentication method, we are limiting the new endpoints and capabilities to only be available to the new methods.
The medium term plan is to deprecate user API keys. We are still working on the exact details, but the deprecation period will last 1 year, and we expect it to begin at the start of next year (Jan 2023).
Based on this, we recommend preparing to support the new API token format:
- If you currently validate tokens (e.g. with a regex like
/^key[a-zA-Z0-9]{14}$/), start supporting the new personal access token key format as well (/^pat[a-zA-Z0-9]{14}\.[0-9a-f]{64}$/)- For pyairtable: No action needed. From a quick scan, I don't think this applies, so I'm mentioning this point more for completeness
- Update documentation mentions of “API key” to the more general “API key or access token”
- For pyairtable: This may apply to the article at https://pyairtable.readthedocs.io/en/latest/getting-started.html#api-key
Thanks for the details @FredZhao-at
I am pretty low on bandwidth at the this time. Happy to take PRs for this, otherwise I will tackle it on when time allows.
We can add the regex validations, and a deprecation warning for the soon old api key format.
We can add the regex validations, and a deprecation warning for the soon old api key format.
To clarify, regex validation is not actually necessary. The fact that you're treating it as an opaque string right now is actually great, since it means less work needed. :) Sorry for the noise in that bullet point, I'll edit it to say "no action needed"
Docs were taken care on #214
We could add regex check just for the purpose of emitting deprecation warning if you all think it's helpful
Looks like this was taken care of and no further action needed (yay), so I'm going to close the issue.