3種類のキー
公開キー、シークレットキー、アクセストークンの用途と、どれをブラウザに置いてはいけないか。
3種類のキー
get_project_keys が3つすべてを返します。用途が異なり、置き場所を間違えると事故になります。
| キー | どこに | 何ができるか |
|---|---|---|
| 公開キー(publishable) | ブラウザやアプリに入れてもよい | アクセスルールが許すことだけ |
| シークレットキー(secret) | サーバーだけ | アクセスルールをすべて迂回 |
| アクセストークン(PAT) | この MCP サーバーと管理 API | プロジェクトを作成・削除 |
用途別のキー
get_project_keys の2つのキーはひと組になっているため、ひとつが漏れたら両方を替える必要があります。
サーバーごと、アプリごとに分けて使うには、create_api_key で名前付きのキーを作ってください。
bw_publishable_… は公開キーと、bw_secret_… はシークレットキーと同じ権限です。
list_api_keys で最後に使われた日時がわかるので、使っていないキーは revoke_api_key でひとつずつ失効させてください。
キーが漏れたとき
get_jwt_signing 署名方式(HS256 | ES256)と、まだ受け付けている古いキー
rotate_signing_key 公開キーとシークレットキーに署名するキーを新しく (grace_hours: 0, 1, 24, 168)
retire_signing_key 猶予期間中の古いキーを今すぐ終了
set_jwt_signing ログイントークンを ES256 に (他のサーバーが公開鍵で検証)rotate_signing_key は get_project_keys の2つのキーを両方とも変更します。アプリに入れたキーをすべて移し替える必要があるため、
漏れたときは grace_hours: 0、計画的な交換なら移し替えにかかる時間だけ猶予を設けてください。オーナーと管理者だけが実行できます。
grace_hours: 0(または空)のときは confirm にプロジェクト名をそのまま入れます。
フロントエンドのコードに入れる値だけが必要なら、get_project_keys { ref, only: "publishable" } でアドレスと公開キーだけを受け取ってください。
絶対にしないこと
シークレットキーをブラウザのコード、モバイルアプリ、公開リポジトリに入れないでください。 そのキーは、そのプロジェクトのすべてのテーブルをルールなしで読み書きします。 フロントエンドのコードにキーを入れる必要があるなら、それは常に公開キーです。
アドレス
プロジェクトの API は https://<ref>.<zone> です。get_project_keys も一緒に教えてくれます。
GET https://<ref>.<zone>/rest/v1/notes?select=* apikey: <公開キー>
POST https://<ref>.<zone>/auth/v1/signup apikey: <公開キー>