ログインと認証

OAuth 2.0 は、利用者がパスワードをアプリに渡さずに、別のサービス（認可サーバー。Google や自社の ID 基盤など）でログインして、アプリにアクセストークン（API を使ってよいという許可証）を渡すための決まりです。「誰がログインしたか」を伝える部分は、OAuth の上に作られた OpenID Connect（OIDC）が受け持ちます。

作り方を間違えると、トークンを盗まれて他人になりすまされる事故につながるので、アプリでの正しい作り方を押さえておきます。

アプリで「Google でログイン」や自社の ID 基盤でのログインを作るときは、OAuth 2.0 の認可コードフローに PKCE を付けたものを使います。アプリは中身を解析されるので、秘密の値（クライアントシークレット）を安全に持てません。PKCE はその代わりに、ログインのたびに使い捨ての合言葉を作る仕組みです。

• アプリがランダムな文字列 code_verifier を作り、そのハッシュ code_challenge（S256）をつけてログイン画面を開く。
• 利用者がログインすると、決めておいた戻り先（リダイレクト URI）に認可コードが返る。
• アプリは認可コードと元の code_verifier をトークンの窓口に送り、アクセストークンとリフレッシュトークンを受け取る。

途中で認可コードを盗まれても、code_verifier を知らなければトークンに交換できません。

（SRE）認証と状態管理（Cookie・セッション・トークン・OAuth）

下の「ブラウザで試す」の図は、Web サービスのサーバーが「Google でログイン」を受け持つ場合の流れです。認可サーバーへリダイレクト → ログインと同意 → 認可コードを持って戻る → コードを code_verifier と一緒にトークンに交換、という順番はアプリでも同じです。違うのは交換する側で、図ではサーバーがクライアントシークレットも付けて交換しますが、アプリではアプリ自身がシークレットなしで code_verifier を付けて交換します。

OAuth のログイン画面をどこで開くかは、安全性に直結します。

ログイン画面は、アプリの中の WebView ではなくシステムのブラウザーで開きます。WebView ではアプリが入力されたパスワードを盗み見られるので、多くの ID 基盤（Google など）は WebView でのログインを断っています。iOS は ASWebAuthenticationSession、Android は Custom Tabs を使います。ブラウザーのログイン状態を共有できるので、利用者がパスワードを打たずに済む利点もあります。自分で作るより、AppAuth などの実績のあるライブラリを使うのが安全です。

アクセストークンは漏れたときの被害を小さくするため短い期限にし、切れたらリフレッシュトークンで取り直します。ここでの失敗は「突然ログアウトされる」という分かりやすい不具合になります。

• アクセストークンは短い期限（数分〜1時間ほど）にし、切れたらリフレッシュトークンで取り直します。どちらも Keychain・Keystore に保存します。
• API が 401 を返したら、リフレッシュして1回だけ元の通信をやり直します。何度も繰り返さないようにします。
• 複数の通信が同時に 401 になったとき、リフレッシュは1回だけにまとめます（排他制御）。リフレッシュトークンを使うたびに新しいものに変わる方式（ローテーション）では、同時に2回使うと片方が無効になり、ログアウトされてしまいます。

Face ID・Touch ID・指紋認証などの生体認証は、「今この端末を持っているのが持ち主か」を端末の中で確かめる仕組みです。顔や指紋のデータは端末の安全な領域から出ず、アプリにもサーバーにも渡りません。アプリが受け取れるのは「確認できた／できなかった」だけです。

生体認証の位置づけ

なので生体認証は、サーバーへのログインそのものではなく、端末に保存した秘密を取り出すときの鍵として使います。

• iOS：LocalAuthentication の結果の true／false だけで判断すると、改造した端末では結果を書き換えられます。Keychain の項目に SecAccessControl（.biometryCurrentSet など）を付けると、生体認証が通らないと OS が中身を渡しません。Info.plist に NSFaceIDUsageDescription が必要です。
• Android：BiometricPrompt に Keystore の鍵（利用者の認証が必要な設定の鍵）を使う CryptoObject を渡し、認証が通ったときだけ鍵が使えるようにします。

指紋や顔の登録が変わったら鍵を無効にする設定もでき、他人の指紋を追加されて開かれるのを防げます。

（SRE）認証の種類と強化（MFA・SSO・パスキー）

パスキーは、パスワードの代わりに公開鍵の仕組みで本人を確かめる方法です。Web とアプリで同じパスキーを使え、利用者は生体認証や画面ロックを解くだけでログインできます。

パスキーは、パスワードの代わりに公開鍵の仕組みで本人を確かめる方法です。秘密鍵は端末（や iCloud キーチェーン・Google パスワードマネージャーで同期された端末）にあり、サーバーには公開鍵だけを置きます。使うときは生体認証や画面ロックで確かめるだけです。秘密鍵はそのサイト（ドメイン）でしか使えないので、偽のサイトに入力させるフィッシングに強いのが最大の利点です。

アプリで使うには、アプリとドメインを結びつける設定が要ります。iOS は Associated Domains の webcredentials: と apple-app-site-association、Android は Credential Manager と assetlinks.json（Digital Asset Links）を使います。Web と同じパスキーをアプリでも使えるようになります。

生体認証（端末の中の確認）

「Google でログイン」のような外部のアカウントでのログインは、アプリでは審査の決まりにも関わります。App Store の審査ガイドライン（4.8）では、外部やソーシャルのログインを使うアプリは、集める情報を名前とメールに限り、メールを隠せて、同意なく広告の追跡に使わないログインの方法も同じように選べるようにすることが求められます。Sign in with Apple はこの条件を満たす代表です。自社のアカウントだけでログインするアプリなどには例外があるので、最新のガイドラインを確かめます。

ソーシャルログインでも、ログイン画面の開き方（システムのブラウザーや OS の専用の画面）と、トークンの保存先の考え方は同じです。

ログアウトは「トークンを消すだけ」と思われがちですが、片付けが足りないと、次にログインした別の人に前の人の通知やデータが見えるという深刻な不具合になります。

また App Store では、アカウントを作れるアプリはアプリの中からアカウントの削除を始められるようにする必要があります。Google Play でも、アカウントの削除を頼める方法（アプリの中と Web）を用意して申告する決まりがあります。削除は、ログアウトの片付けに加えて、サーバー側でデータを消す流れまで含めて設計します。