firebase-auth-basics
Firebase の認証を入れる。CLI で有効にできる方式は 3 つだけで、残りは管理画面
npx skills add firebase/agent-skills/firebase-auth-basics入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 177,829
- 実用度
- 36
- GitHub star
- 505
- 最終更新
- 2026/11/5
頼み方の例
そのままコピーして使えますfirebase-auth-basicsを使って、このアプリに Google サインインを入れる手順を整理してください。CLI で有効にできる範囲と、管理画面でしかできない設定を分けて示してください。設定の適用はまだしないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- シェルコマンドを実行する記述があります
- パッケージを導入する記述があります
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
コードブロックの言語: bash
いつ使うか
アプリに利用者のサインインが要るときです。
- CLI で有効にできる方式
- 3 つ
- ID トークンの寿命
- 1 時間
- 同梱ファイル（2026-10-09 確認）
- 5 件
もう 1 つの用途は、認証の規則を使ったデータの読み書き
説明文はもう 1 つの用途も挙げています。認証の規則を使った安全なデータの読み書き。つまり Firestore の規則で「本人のデータだけ読ませる」を実現する土台になります。
用語の整理から始まる
本文は概念の説明に紙幅を使っています。この順序は読みやすいです。
- 利用者
uidで一意に識別される。提供元をまたいで一意 - 提供元メール／パスワード、Google などの連携、電話番号、匿名、独自
- 証票ID トークン（1 時間）と更新トークン
uid が提供元をまたいで一意である、という性質が重要です。Google で入った人と電話番号で入った人を、同じ土台で扱えます。
匿名の口座は、あとから恒久的な口座に紐付けられる
匿名の扱いが実用的です。一時的な客用の口座を作り、あとから恒久的な口座に紐付けられる。「まず試してもらって、気に入ったら登録」という流れが作れます。
CLI で有効にできるのは 3 つだけ
ここが最も実務的な情報です。本文がはっきり書いています。
CLI で有効にできるのは Google サインイン・匿名・メール／パスワードだけ。他の提供元は Firebase の管理画面を使え。
| 方式 | CLI |
|---|---|
| Google サインイン | ○ |
| 匿名 | ○ |
| メール／パスワード | ○ |
| Facebook・GitHub・Apple ほか | 管理画面のみ |
| 電話番号 | 管理画面 |
知らないと「CLI でできるはず」と探し続けます。最初に線が引かれているのは助かります。
設定は firebase.json の auth のブロックに書く
設定は firebase.json に auth のブロックを書く形です。提供元をそこに並べ、Google サインインには転送先の URI（authorizedRedirectUris）を書きます。authorizedDomains の欄は、本文の例にはありません（2026-10-09 確認）。
書いたら deploy --only auth で反映する
本文は必ず反映せよと書いています。firebase.json を書いただけでは効きません。npx -y firebase-tools@latest deploy --only auth で送ると、Google サインインなどに要る OAuth のクライアントが各プラットフォーム向けに作られます。
手元で試すなら、localhost にポート番号を付けない
手元で試すなら http://localhost を足します。本文はポート番号を付けるなと強く書いています。付けると firebase deploy --only auth が INVALID_AUTHORIZED_DOMAIN で失敗するためです。
管理画面の「承認済みドメイン」に足す場合は、プロトコルも付けず localhost とします。
Google サインインを既定として勧めている
本文に「Google サインインが、良くて安全な既定の提供元」とあります。
公開元が Google なので割り引いて読む必要はありますが、メール／パスワードを自前で扱うより運用が軽いのは事実です。
証票の寿命を明記している
ID トークンは 1 時間、更新トークンは長期。この 2 つを混同すると、サーバー側の検証を間違えます。
自前のバックエンドに繋ぐなら、どちらを受け取って何を検証するかを先に決めてください。
使わないほうがいいとき
CLI の導入やプロジェクトの選択は別です
そちらは firebase-basics の担当です。
規則そのものを点検したいなら別物です
書いた規則に穴が無いかを見るのは firebase-security-rules-auditor です。入れるのと点検するのは別の工程と考えてください。
データの保存の設計には使えません
そちらは firebase-firestore です。
Firebase 以外の認証基盤と、CLI で扱えない提供元
Firebase 以外の認証基盤には使えません。 CLI で扱えない提供元を使うなら、途中で管理画面に移ります。自動化しきれないことは先に織り込んでください。
注意点
解析で見つかった記述
SKILL.md の解析では、シェルコマンドを実行する記述とパッケージを導入する記述が見つかっています。同梱ファイルは 5 件で、Web・Android・iOS・Flutter の書き方と、認証を使った規則の資料です（2026-10-09 確認）。
本番の認証設定を変更します。ここが最大の注意点です
入れる前の確かめ方はスキルを入れる前に確認することにあります。
許可する転送先の扱いに注意してください
authorizedRedirectUris や承認済みドメインに広すぎる値を入れると、意図しない場所からのサインインを許すことになります。
匿名の口座は増え続けます
便利ですが、放っておくと使われない口座が溜まります。掃除の方針を先に決めてください。
証票の検証は自分の責任です
自前のバックエンドに繋ぐ場合、ID トークンの検証を正しく行う必要があります。このスキルは設定までを扱います。
ライセンス
Apache-2.0。再配布や商用利用の前に公開元の表記を確認してください。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
よくある質問
CLI で全部の提供元を有効にできますか
できません。Google サインイン・匿名・メール／パスワードの 3 つだけです。
Facebook、GitHub、Apple、電話番号などは管理画面を使います。ここは自動化できないと先に織り込んでください。
どの提供元を選べばいいですか
本文は Google サインインを既定として勧めています。運用の手間はメール／パスワードより軽くなります。
ただし利用者の層によります。Google の口座を持たない相手が多いなら、メール／パスワードも並べる判断になります。
匿名で始めてあとから登録できますか
できます。一時的な客用の口座を作り、あとから恒久的な口座に紐付ける流れが本文にあります。
「まず試してもらう」導線を作るときに効きます。
ID トークンの寿命は
1 時間です。更新トークンは長期で、新しい ID トークンを取るために使います。
自前のバックエンドでは ID トークンを検証します。
規則の点検もしてくれますか
しません。書いた規則に穴が無いかを見るのは firebase-security-rules-auditor の担当です。
対応しているエージェントはどれですか
Claude Code と Codex です。公開元のリポジトリに Claude Code 向けと Codex 向けのプラグインの定義があり、README も Codex のプラグインとしての入れ方を案内しています（2026-10-09 確認）。compatibility の欄には「Firebase CLI と併せて使うのが最良だが、必須ではない」とあります。
当サイトは公開元が明記しているものだけを「対応」として表示する方針なので、このスキルのページには両方が対応として出ます（指標の意味と限界）。