Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Early heads up: switching away from user API keys #58

Open
FredZhao-at opened this issue Dec 14, 2022 · 4 comments
Open

Early heads up: switching away from user API keys #58

FredZhao-at opened this issue Dec 14, 2022 · 4 comments

Comments

@FredZhao-at
Copy link

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. 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 airtable-php: From a quick scan, it looks like you are treating keys as an opaque string. This is perfect, so please keep doing that 😄
  • Update documentation mentions of “API key” to the more general “API key or access token”
@roderikpeeters
Copy link

Any updates on this?

@LucasRoquilly
Copy link

Also worried about this

@Maidomax
Copy link

Maidomax commented Jun 7, 2023

@LucasRoquilly @roderikpeeters I just went through the code, and I can see that the library adds whatever is set to the api_key field in the constructor config as the bearer token for all request.
Therefore, you can just generate the new personal access tokens and put them in place of the previous API keys, and it will work the same. I just tested it and it works. The documentation just needs to be changed to reflect that.

@twentyfortysix
Copy link

Tested and confirmed. The API key can be replaced by the Access token and it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants