APIを設計・運用するうえで避けて通れないのが認証方式の選定です。Basic認証、APIキー、OAuth 2.0、JWTなど選択肢は数多くあり、それぞれセキュリティ強度や実装コストが異なります。方式ごとの違いを正しく把握しないまま導入すると、トークン漏洩や不正アクセスといった深刻なインシデントにつながりかねません。
ここでは7つの主要なAPI認証方式について、仕組み・セキュリティ特性・適した用途を横断的に整理し、プロジェクト要件から最適な方式を選ぶための判断基準を提示します。
API認証の基本 – 認証と認可はなぜ区別すべきか
API認証を理解するには、まず 認証（Authentication） と 認可（Authorization） の違いを明確にしておく必要があります。
- 認証: リクエスト送信者が「誰であるか」を検証するプロセスです。ユーザー名とパスワード、証明書、トークンなどを用いて本人確認を行います。
- 認可: 認証済みのユーザーやアプリケーションが「何を実行できるか」を制御するプロセスです。APIエンドポイントごとのアクセス権限、リソースの読み取り・書き込み権限などが該当します。
OAuth 2.0は本来「認可」のためのプロトコルですが、「OAuth認証」という呼び方が広まっています。この混同が「OAuth認証 危険」という検索キーワードが生まれる一因です。OAuth 2.0単体では認証を保証しないため、認証レイヤーが必要な場合はOpenID Connect（OIDC）を組み合わせる設計が正しいアプローチとなります。
API認証が不可欠な3つの理由
- 不正アクセスの防止: 認証なしのAPIは、外部からの無制限なデータ取得・改ざんを許してしまいます
- レート制限とアクセス監査: 認証によりリクエスト元を特定できるため、DDoS対策や不正利用の追跡が可能になります
- コンプライアンス要件への対応: 金融（FAPI）、医療（HIPAA）、個人情報保護（GDPR）など各種規制は適切なAPI認証を求めています
主要なAPI認証方式7つの仕組みと特徴
Basic認証 – HTTPヘッダーで資格情報を送る最も原始的な方式
Basic認証は、HTTPの標準仕様（RFC 7617）に定義された認証スキームです。ユーザー名とパスワードをコロンで結合し、Base64でエンコードした文字列をAuthorizationヘッダーに付与します。
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
重要な注意点として、Base64はエンコードであり暗号化ではありません。 デコードすれば元の資格情報が即座に復元されるため、HTTPS（TLS）なしでのBasic認証は、ネットワーク上で平文パスワードを送信しているのと実質的に同じです。
メリット:
- 実装が極めて簡単で、ほぼすべてのHTTPクライアントが標準対応
- 開発・テスト環境での迅速なプロトタイピングに適する
デメリット:
- リクエストごとに資格情報を送信するため、漏洩リスクが高い
- セッション管理やトークンの無効化といった概念がない
- 権限の粒度制御（スコープ）の仕組みがない
APIキー認証 – リクエスト元を識別するシンプルな文字列
APIキー認証は、サーバーが発行した一意の文字列（APIキー）をリクエストに含めて送信する方式です。ヘッダー、クエリパラメータ、リクエストボディのいずれかで送信されます。
# ヘッダーで送信するパターン
curl -H "X-API-Key: sk_live_abc123def456" https://api.example.com/data
# クエリパラメータで送信するパターン
curl "https://api.example.com/data?api_key=sk_live_abc123def456"
APIキーは厳密には「認証」というよりも「識別」の手段です。リクエスト元がどのアプリケーションであるかを特定しますが、そのアプリケーションを操作しているユーザーが誰であるかは検証しません。
Stripeの決済APIがAPIキー認証を採用しているのは代表的な例です。Stripeでは公開可能キー（pk_プレフィックス）とシークレットキー（sk_プレフィックス）を使い分け、さらに制限付きキー（rk_プレフィックス）で権限をエンドポイント単位に絞り込めます（出典: Stripe API Reference）。
メリット:
- 実装と管理が容易
- 課金やレート制限との組み合わせに適している
デメリット:
- キーの漏洩が即座に不正アクセスに直結する
- ユーザー単位のアクセス制御ができない
- キーのローテーション運用が煩雑になりがち
Bearerトークン認証（JWT含む） – ステートレスなトークンベース認証
Bearerトークン認証は、事前に発行されたトークンをAuthorizationヘッダーのBearerスキームで送信する方式です。トークンを「持っている（bear）」こと自体がアクセス権の証明となります。
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Bearerトークンの代表格がJWT（JSON Web Token）です。JWTは3つのパートで構成されます。
- ヘッダー（Header）: 署名アルゴリズムとトークン種別を宣言するJSON
- ペイロード（Payload）: ユーザーID、権限、有効期限（
exp）などの「クレーム」を含むJSON - 署名（Signature）: ヘッダーとペイロードを秘密鍵で署名したハッシュ値
これら3つのパートがドット（.）で連結され、Base64URLエンコードされた文字列がJWTです。サーバー側はトークン自体に含まれる情報で検証が完結するため、セッションストアへの問い合わせが不要になります。これがJWTのステートレス性であり、マイクロサービスアーキテクチャで重宝される理由です。
「JWT認証 使うな」と言われる背景
「JWT 使うな」という検索が一定数存在するのは、JWTの設計上の特性に起因する以下のリスクがあるためです。
alg: none攻撃: ヘッダーのアルゴリズムをnoneに改ざんし、署名検証をバイパスする手法です。2025年だけで、JWT実装の脆弱性に関する重大なCVEが6件報告されています（出典: Red Sentry）- アルゴリズム混同攻撃: RS256（非対称鍵）で署名されたトークンのアルゴリズムをHS256（対称鍵）に書き換え、公開鍵をHMAC鍵として署名を偽造する手法です
- トークン失効の困難さ: ステートレスであるがゆえに、発行済みトークンを即座に無効化する標準的な手段がありません
ただし、これらは「JWTを使うべきでない」のではなく、「正しく実装しなければ危険」という意味です。許可するアルゴリズムをホワイトリストで明示的に制限し、適切な有効期限を設定すれば、JWTは依然として有効な選択肢です。
OAuth 2.0 – 権限委譲のための標準プロトコル
OAuth 2.0（RFC 6749）は、ユーザーの資格情報をサードパーティに渡すことなく、限定的なアクセス権限を委譲するための認可フレームワークです。「GoogleアカウントでログインしてXアプリにカレンダーへのアクセスを許可する」といったフローの基盤技術となっています。
OAuth 2.0には用途に応じた複数の認可フローが定義されています。
| フロー名 | 主な用途 | 特徴 |
|---|---|---|
| Authorization Code | サーバーサイドWebアプリ | クライアントシークレットをサーバー側で安全に保持できる |
| Authorization Code + PKCE | SPA・モバイルアプリ | コード横取り攻撃を防ぐ追加の検証ステップを含む |
| Client Credentials | サーバー間（M2M）通信 | ユーザー不在でアプリ自身が認証する |
| Device Code | スマートTV・IoT端末 | 入力が制限されたデバイス向け |
GitHubのAPI認証はOAuth 2.0を基盤としています。OAuth Appによるユーザー認可に加え、Personal Access Token（PAT）やGitHub Appによる認証方式を提供し、スコープによる権限の細粒度制御を実現しています（出典: GitHub Docs）。
「OAuth認証 危険」は誤解に基づく
「OAuth認証 危険」という検索が存在しますが、これはOAuth 2.0の仕様に対する誤解に起因しています。OAuth 2.0は認可のプロトコルであり、アクセストークンを取得できたことが本人確認を意味するわけではありません。認証を安全に行うには、後述するOpenID Connectを組み合わせる必要があります。OAuth 2.0自体が危険なのではなく、認可プロトコルを認証目的で誤用することが危険なのです。
HMAC認証 – リクエスト署名による改ざん検知
HMAC（Hash-based Message Authentication Code）認証は、リクエスト内容から署名を生成してサーバーに送信し、サーバー側で同一の署名を再計算して一致を検証する方式です。トークンを直接送信しないため、中間者がリクエストを傍受しても再利用が困難になります。
この方式の代表的な実装が**AWS Signature Version 4（SigV4）**です。AWSの全サービスAPIがこの方式を採用しており、以下の手順で署名を生成します（出典: AWS Documentation）。
- 正規リクエストの生成: HTTPメソッド、URI、クエリ文字列、ヘッダーを正規化した文字列を作成
- 署名対象文字列の生成: 日付、リージョン、サービス名と正規リクエストのハッシュを結合
- 署名鍵の導出: シークレットアクセスキーを起点に、日付・リージョン・サービスごとのHMAC-SHA256を段階的に計算
- 最終署名の計算: 導出した署名鍵で署名対象文字列のHMAC-SHA256を計算
Authorization: AWS4-HMAC-SHA256
Credential=AKIAIOSFODNN7EXAMPLE/20260225/ap-northeast-1/s3/aws4_request,
SignedHeaders=host;x-amz-date,
Signature=fe5f80f77d5fa3beca038a248ff027...
メリット:
- リクエスト内容の改ざんを検知できる（本体のハッシュも署名に含まれる）
- シークレットキー自体がネットワークを流れない
- リプレイ攻撃に強い（タイムスタンプを署名に含む）
デメリット:
- 実装の複雑さが高い（正規化ロジック、署名計算のステップが多い）
- クライアント側の時刻同期が必須（5分以上のずれでリクエストが拒否される）
- デバッグが難しい（署名不一致時の原因特定が困難）
mTLS（相互TLS認証） – 証明書ベースの双方向認証
通常のTLS通信ではクライアントがサーバーの証明書を検証しますが、mTLS（mutual TLS）ではサーバーもクライアントの証明書を検証します。双方向の証明書検証により、通信相手の真正性を暗号学的に保証する方式です。
mTLSはゼロトラストセキュリティモデルの中核技術として、マイクロサービス間通信で広く採用されています。IstioやLinkerdなどのサービスメッシュは、各マイクロサービスに「サイドカー」プロキシを配置し、mTLSのハンドシェイク・証明書の検証・通信の暗号化を自動的に処理します。これにより、アプリケーションコードを変更せずにmTLSを導入できます（出典: GitGuardian Blog）。
2025年11月にAmazon CloudFrontがビューアー向けのmTLS認証をサポートし、その後オリジンサーバー向けmTLSも追加されたことで、ビューアーからバックエンドまでのエンドツーエンドなゼロトラスト認証が実現されています（出典: AWS、出典: InfoQ）。
メリット:
- 暗号学的に強固な相互認証を実現
- パスワードやトークンのような秘密情報をネットワーク上で送信しない
- サービスメッシュとの統合でアプリケーション透過的に導入可能
デメリット:
- 証明書の発行・配布・更新（ローテーション）の運用負荷が高い
- クライアント数が多い場合のスケーラビリティに課題がある
- ブラウザベースのアプリケーションとの相性が悪い
OpenID Connect（OIDC） – OAuth 2.0の上に構築された認証レイヤー
OpenID Connectは、OAuth 2.0の認可フローの上にIDトークン（JWT形式）を追加した認証プロトコルです。OAuth 2.0だけでは「誰がアクセスしているか」を保証できない問題を解決します。
Google Cloud APIの認証はOAuth 2.0とOpenID Connectを基盤としています。ユーザー認証にはOAuth 2.0 + OIDCフロー、サーバー間通信にはサービスアカウント（秘密鍵による自己署名JWTでOAuth 2.0アクセストークンを取得）を使用します。アクセストークンのデフォルト有効期限は1時間に設定されており、短寿命トークン戦略を徹底しています（出典: Google Cloud Documentation）。
IDトークンに含まれる主な情報:
sub: ユーザーの一意識別子iss: トークンの発行者aud: トークンの対象（クライアントID）exp: 有効期限nonce: リプレイ攻撃防止用の値
メリット:
- OAuth 2.0の認可機能と本人認証を統合できる
- Google、Microsoft、LINEなどの大手IDプロバイダが対応
- SSO（シングルサインオン）の基盤として利用可能
デメリット:
- OAuth 2.0単体よりも仕様が複雑
- IDプロバイダへの依存が生じる
- IDトークンの検証処理（署名検証・クレーム検証）を正しく実装する必要がある
認証方式の横断比較 – セキュリティ・コスト・拡張性の3軸で評価
7つの方式を横断的に比較した表を示します。プロジェクトの要件に合わせて参照してください。
| 方式 | セキュリティ強度 | 実装難易度 | スケーラビリティ | 状態管理 | 適したユースケース |
|---|---|---|---|---|---|
| Basic認証 | 低（TLS必須） | 極めて容易 | 低 | ステートレス | 開発環境、社内ツール |
| APIキー | 低〜中 | 容易 | 中 | ステートレス | 外部API提供、課金制御 |
| Bearer/JWT | 中〜高 | 中程度 | 高 | ステートレス | マイクロサービス、SPA |
| OAuth 2.0 | 高 | やや高い | 高 | ステートフル/レス | サードパーティ連携 |
| HMAC署名 | 高 | 高い | 高 | ステートレス | クラウドAPI（AWS等） |
| mTLS | 極めて高い | 高い | 中 | ステートレス | サービス間通信、金融 |
| OIDC | 高 | やや高い | 高 | ステートフル/レス | ユーザー認証、SSO |
補足: セキュリティ強度は方式自体の設計に基づく評価であり、実装品質によって大きく変動します。Basic認証であってもTLS + IP制限 + レート制限を組み合わせれば、社内利用には十分な場合があります。
用途別の選定ガイド – プロジェクト要件から逆引きする
社内ツール・管理画面のAPI
外部に公開せず、限られた開発者やオペレーターだけがアクセスする管理系APIの場合です。
- 推奨: Basic認証（TLS必須）またはAPIキー
- 理由: 実装・運用コストを最小化でき、IP制限やVPN併用でセキュリティを補強可能
- 注意: 管理画面であっても、個人情報や決済データを扱う場合はOAuth 2.0以上を検討
外部公開REST API
サードパーティの開発者に提供するパブリックAPIの場合です。
- 推奨: OAuth 2.0 + JWT（Bearerトークン）
- 理由: ユーザーの資格情報を第三者に渡さずに権限を委譲でき、スコープで細粒度の制御が可能
- 補足: API利用量の管理にはAPIキーを併用するケースが多い（GitHubやGoogle APIがこのパターン）
マイクロサービス間通信
Kubernetes上のサービス間やバックエンドシステム間のAPI呼び出しの場合です。
- 推奨: mTLS（サービスメッシュ経由）またはHMAC署名
- 理由: サービス間通信はユーザーの介在がなく、証明書や署名鍵によるサービスアイデンティティの検証が適する
- 補足: Istio/Linkerdのサービスメッシュ導入済みならmTLSが最も低コスト。未導入ならOAuth 2.0 Client Credentialsフローも選択肢
モバイルアプリ・SPA（シングルページアプリケーション）
ブラウザやネイティブアプリからAPIを呼び出す場合です。
- 推奨: OAuth 2.0 Authorization Code + PKCE
- 理由: モバイルアプリやSPAは「パブリッククライアント」であり、クライアントシークレットを安全に保持できません。PKCE（Proof Key for Code Exchange）は認可コードの横取り攻撃を防止する仕組みで、OAuth 2.1ではPKCEが全クライアントで必須化されています（出典: Auth0 Docs）
- 補足: リフレッシュトークンにはローテーション（使い捨て + 前トークンの即時無効化）を必ず適用
金融・医療など高セキュリティ要件
銀行API、決済、医療データ連携など規制対象のAPIの場合です。
- 推奨: FAPI 2.0（Financial-grade API）セキュリティプロファイル + mTLS
- 理由: FAPI 2.0はOAuth 2.0のセキュリティを金融グレードに強化した仕様で、2025年2月にFinal仕様として承認されました（出典: OpenID Foundation）。送信者制約付きアクセストークン、mTLSクライアント認証、リクエスト/レスポンスの署名が含まれます
- 補足: コロンビアでは中央銀行がFAPI 2.0の実装を義務化しており、グローバルで採用が拡大中
著名APIサービスの認証方式と設計意図
実際のAPIサービスがどの認証方式を採用し、なぜその選択に至ったかを知ることは、自身のプロジェクトの設計判断に役立ちます。
| サービス | 主な認証方式 | 設計上の狙い |
|---|---|---|
| GitHub | OAuth 2.0 + PAT + GitHub App | サードパーティ連携（OAuth）、個人利用（PAT）、組織管理（GitHub App）と用途を分離 |
| Stripe | APIキー（公開/シークレット/制限付き） | 決済APIの高い可用性を確保しつつ、制限付きキーで権限を最小化 |
| AWS | HMAC署名（SigV4）+ IAMロール | リクエスト改ざん検知とシークレットキーの非送信を両立。IAMで権限を細粒度制御 |
| Google Cloud | OAuth 2.0 + サービスアカウント + Workload Identity | ユーザー向けにはOAuth/OIDC、サーバー間にはサービスアカウントJWT、マルチクラウドにはWorkload Identity |
| Slack | OAuth 2.0 + Bot Token | ボットトークン（xoxb-プレフィックス）でユーザーに依存しないアプリ稼働を実現 |
注目すべきパターン: 大規模APIサービスは単一の認証方式に依存していません。ユーザー向け・サーバー間・サードパーティ連携など、用途ごとに異なる方式を使い分けています。SlackのBot Tokenは有効期限が設定されておらず、不要になった時点で明示的に失効させる運用です（出典: Slack Developer Docs）。
API認証で避けるべきアンチパターンと実際のインシデント
理論だけではリスクの深刻さは伝わりにくいため、実際に発生したインシデントとともに解説します。
APIキーをソースコードにハードコード – Toyota T-Connectの事例
2022年10月、トヨタはT-Connectサービスのソースコードが2017年12月からGitHub上の公開リポジトリに誤ってアップロードされていたことを公表しました。そのソースコードにはデータサーバーへのアクセスキーが含まれており、約29万6千人の顧客メールアドレスと管理番号が5年間にわたり外部からアクセス可能な状態でした（出典: BleepingComputer）。
根本原因: 開発委託先がAPIキーをソースコードに直接埋め込み、そのリポジトリの公開設定を誤ったことです。5年間キーがローテーションされなかったという運用面の問題も被害を拡大させました。
対策:
- APIキーやシークレットは環境変数またはシークレット管理サービス（AWS Secrets Manager、HashiCorp Vault等）で管理する
- GitGuardianやtrivyなどのシークレットスキャンツールをCI/CDパイプラインに組み込む
- キーのローテーションポリシーを策定し、定期的に更新する
セッションCookie窃取によるトークン漏洩 – CircleCIの事例
2023年1月、CircleCIはエンジニアの端末がマルウェアに感染し、2FA認証済みのセッションCookieが窃取されたことで、顧客の環境変数・OAuthトークン・SSHキーが漏洩したと報告しました。攻撃者は窃取したセッションで正規ユーザーとしてログインし、権限を昇格させてデータベースに不正アクセスしました（出典: CircleCI Blog）。
教訓: 多要素認証（MFA）を導入していても、セッション管理が不十分であれば突破されます。トークンやCookieのバインディング（デバイスやIPアドレスとの紐づけ）、異常検知による早期のセッション無効化が重要です。
HTTPS未使用でのBasic認証
Basic認証をHTTP（非TLS）で使用した場合、ネットワーク経路上の任意の箇所でBase64デコードにより資格情報が復元されます。カフェのWi-Fiなどの共有ネットワークでは中間者攻撃（MITM）のリスクが高くなります。
対策: Basic認証を使用する場合は、TLSの強制をサーバー設定で必ず行い、HSTS（HTTP Strict Transport Security）ヘッダーも設定します。
CORSの過剰許可
Access-Control-Allow-Origin: *を安易に設定すると、任意のオリジンからのリクエストを許可してしまい、認証トークンの窃取やCSRF攻撃の経路となります。
対策: 許可するオリジンを明示的にホワイトリストで指定し、Access-Control-Allow-Credentials: trueと*を併用しないようにします。
トークン管理のベストプラクティス
APIトークンは発行して終わりではなく、ライフサイクル全体を通じた管理が求められます。
リフレッシュトークン戦略
アクセストークンの有効期限を短く設定し（例: 15分〜1時間）、リフレッシュトークンで新しいアクセストークンを取得する方式が標準的です。
アクセストークン: 有効期限 15分〜1時間（短寿命）
リフレッシュトークン: 有効期限 7日〜30日（長寿命）
リフレッシュトークンが漏洩した場合の被害を最小化するために、リフレッシュトークンローテーションを導入します。リフレッシュトークンを使用するたびに新しいトークンを発行し、使用済みのトークンを即座に無効化する仕組みです。同じリフレッシュトークンが2回使用された場合は、トークンファミリー全体を失効させることで、盗取された可能性を検知できます。
トークン失効管理の2つのアプローチ
| アプローチ | 仕組み | メリット | デメリット |
|---|---|---|---|
| 短寿命トークン | 有効期限を極端に短く（5〜15分）設定 | ブラックリスト管理が不要 | リフレッシュ頻度が高くなりUXに影響 |
| ブラックリスト方式 | 失効トークンのリストをRedis等で管理 | 即座に無効化可能 | ステートフルになりJWTのメリットが減少 |
実務的には、アクセストークンを短寿命に設定し、どうしても即時失効が必要な場合（アカウント停止、権限変更等）にのみブラックリストを併用するハイブリッドアプローチが現実的です。
トークン保存場所の選択
ブラウザ環境でのトークン保存には注意が必要です。
- localStorage: XSS攻撃で窃取可能。長寿命トークンの保存は非推奨
- sessionStorage: タブを閉じると消えるが、XSSには同様に脆弱
- HttpOnly Cookie: JavaScriptからアクセス不可だがCSRFのリスクあり。
SameSite=StrictまたはSameSite=Laxと併用 - BFF（Backend for Frontend）パターン: トークンをサーバー側に保持し、ブラウザにはセッションIDのみ返す。最もセキュアなアプローチ
よくある質問（FAQ）
APIの認証方式にはどんな種類がありますか？
主要な方式として、Basic認証、APIキー認証、Bearerトークン認証（JWT）、OAuth 2.0、HMAC署名認証、mTLS（相互TLS認証）、OpenID Connect（OIDC）の7種類があります。それぞれセキュリティ強度、実装コスト、適したユースケースが異なるため、プロジェクトの要件に応じて選定する必要があります。小規模な社内APIならAPIキー、外部公開APIならOAuth 2.0 + JWT、サービス間通信ならmTLSが一般的な選択です。
JWTとOAuth 2.0の違いは何ですか？
JWTはトークンのフォーマットであり、OAuth 2.0は認可のプロトコルです。両者は同じレイヤーの技術ではなく、OAuth 2.0のフロー内でアクセストークンやIDトークンとしてJWTが使用されるという関係にあります。OAuth 2.0はトークンの発行・更新・失効のフロー全体を定義しますが、トークン自体の形式は規定していません。JWTはそのトークンの実装形式の一つです。
APIキーとAPIトークンの違いは？
APIキーはアプリケーションを識別するための静的な文字列です。一方、APIトークン（アクセストークン）はユーザーやアプリケーションが認証された結果として動的に発行される文字列で、通常は有効期限が設定されています。APIキーは「どのアプリか」を示し、トークンは「誰がどの権限でアクセスしているか」を示すものと考えると整理しやすくなります。
モダン認証とレガシー認証の違いは？
レガシー認証はユーザー名・パスワードをアプリケーションに直接渡す方式（Basic認証、LDAP認証など）を指します。モダン認証はOAuth 2.0やOIDCなどのトークンベースのプロトコルを用い、ユーザーの資格情報をアプリケーションに渡さずに認証・認可を行います。Microsoft 365が2022年10月にBasic認証を廃止しOAuth 2.0ベースの「モダン認証」に移行したのは、この流れを象徴する出来事です。モダン認証の利点は、MFA（多要素認証）との統合が容易なこと、トークンのスコープで権限を最小化できること、セッション管理の柔軟性が高いことです。
REST APIの認証にはどの方式が適していますか？
REST APIの認証方式はAPIの公開範囲と利用者によって異なります。外部開発者向けの公開APIであればOAuth 2.0 + JWTが標準的で、内部のマイクロサービス間であればmTLSまたはClient Credentialsフロー、管理画面やバッチ処理であればAPIキーやBasic認証が候補になります。いずれの場合もTLSによる通信の暗号化は必須です。
PAP認証とCHAP認証はどちらが安全ですか？
PAP（Password Authentication Protocol）はパスワードを平文で送信するため、現在のネットワークセキュリティ基準では使用すべきではありません。CHAP（Challenge-Handshake Authentication Protocol）はチャレンジ・レスポンス方式でパスワードを直接送信しないため、PAPより安全です。ただし、これらは主にPPP（Point-to-Point Protocol）接続で使用されるプロトコルであり、API認証の文脈ではOAuth 2.0やJWTなどのトークンベース方式が推奨されます。