ログイン機能を実装する際、どのようなやり取りが起きているのかあまりにも知らないことに気づき、ざっくりまとめました。
Auth0
アプリケーションに認証および認可サービスを追加するためのIDaaSを提供するプラットフォーム（クラウド経由でID, PASS、アクセスなど一元管理するサービス）
開発者がセキュアな認証機能を自前で構築する手間やコスト、リスクを回避し、サービス本来の価値創造に集中できるようにすることを目指しています。
認証と認可
「認証」と「認可」は、密接に関連しながらも異なるプロセスです。
1. 認証 (Authentication: AuthN)
「あなたは誰ですか？」を確認するプロセス
システムにアクセスしようとしているユーザーやデバイスが 「主張通りの本人であること」 を証明し、確認する行為です。身近な例だと、銀行の窓口で身分証明書や暗証番号を提示すること。
2. 認可 (Authorization: AuthZ)
「あなたは何をしてもいいか？」を確認するプロセス
認証に成功したユーザーに対し、特定のリソース(ファイル、機能、データなど)へのアクセス権限を与える行為です。さっきの例でいうと、認証（本人確認）が済んだ顧客に対し、口座残高の閲覧や振り込みを許可すること。
なお、認証は大きく3つにわけられます。
| 種類 | 内容 |
|---|---|
| 知識情報 (Something You Know) | パスワード、PIN、秘密の質問の答えなど |
| 所有情報 (Something You Have) | スマートフォン（SMS/TOTP）、セキュリティトークン、鍵など |
| 生体情報 (Something You Are) | 指紋、顔、虹彩など |
これら3つを組み合わせることで認証の安全性が高まるわけです（多要素認証）
パスワード（知識） + ワンタイムパスワード（所有）
パスワード（知識） + 指紋認証（生体）
パスワードレス認証のMFA（例：生体 + デバイス登録）
などなど...
OAuth 2.0（認可のための標準）
OAuthは「ユーザーに代わってサードパーティのアプリケーションが、ユーザーのリソース（データや機能）にアクセスするための許可を与える（認可する）」フレームワークです。よく複数のWebサービスを連携して動作させるために使われます。
AuthN（認証）ではなく、AuthZ（認可）のためのプロトコルです
発行されるものは「アクセストークン」で、これは「リソースにアクセスして良い」という許可証になります。
例えば「このアプリがあなたのSNSプロフィール情報を取得することを許可しますか？」とよく見るもので、連携アプリはユーザーのID/パスワードを知ることなく、アクセストークンを使ってAPI経由でデータにアクセスできます。
OpenID Connect（認証のための標準）
OIDCは、OAuth 2.0の仕組みを拡張し、認証（本人確認）の機能を追加したプロトコルです。
発行されるものは「ID Token」で、ユーザーが「誰であるか」「認証されたか」を証明するものです。JWT形式で、ユーザーのID情報（ユーザーID、名前、メールアドレスなど）が含まれます。
これは「Googleでログイン」「Yahoo! JAPAN IDでログイン」といったソーシャルログインやSSOなどに使用されています。
◆構成要素
・IDプロバイダー(IdP): ユーザーを認証するサービス（例：Auth0、Google、Okta）
・クライアント/証明書利用者: IdPによる認証結果を利用するアプリケーション（例：Webサイト、モバイルアプリ）。
認証プロセス
認証プロセスの具体的な流れは、Webアプリケーションやモバイルアプリケーションで最も一般的な OpenID Connect (OIDC) の「認可コードフロー (Authorization Code Flow)」 を例にします。
このフローは、クライアントアプリケーション（利用するサービス）が、ユーザーの資格情報（ID/パスワード）に触れることなく、安全に IDプロバイダー (IdP) による認証結果とアクセストークンを取得するための手順です。
このフローの鍵は、機密性の高い情報である「アクセストークン」や「IDトークン」を、ユーザーのブラウザを経由させず、クライアントのバックエンドサーバーとIdPの間で直接交換することです。
これにより、トークンが盗聴されるリスクを大幅に軽減し、安全な認証を実現しています。なお、SPAなどのクライアント側アプリケーションでは、このフローに PKCE (Proof Key for Code Exchange) という拡張機能を追加することで、安全性をさらに高めています。
認可プロセス
Auth0のようなシステムが関わる認可プロセスは、大きく分けて2つのフェーズで機能します。
リソースサーバーによるアクセス制御
アクセストークンを取得したクライアントが保護されたリソース（API）にアクセスする際のプロセスです。
A: トークンの提示と検証
-
アクセスリクエスト: クライアントは、保護されたAPI（リソースサーバー）に対し、リクエストヘッダーにアクセストークン（通常は
Authorization: Bearer <トークン>形式）を付けてアクセスを要求します -
トークンの検証: リソースサーバーは受け取ったアクセストークンを検証します
- トークンの有効期限が切れていないか
- トークンが認可サーバーによって正しく署名されているか（偽造されていないか）
- リクエスト元のクライアントIDがこのトークンの対象であるか
B: 権限（ポリシー）の適用
-
スコープの確認: リソースサーバーは、トークンに含まれるスコープ（例:
read:email）を確認し、クライアントが要求している操作（例: メールを削除する）が、付与されたスコープに含まれているかをチェックします -
認可ポリシーの適用: ユーザーに付与されているロール（役割）や属性に基づき、アクセスを許可するか拒否するかを決定します
-
ロールベースのアクセス制御 (RBAC):
- 例: ユーザーが「管理者」ロールを持つ場合、ファイルの編集を許可
- 例: ユーザーが「閲覧者」ロールを持つ場合、ファイルの閲覧のみを許可
- 属性ベースのアクセス制御 (ABAC): ユーザーの部門、役職、リソースの機密レベル、時間帯などの属性を考慮してアクセスを決定します
-
ロールベースのアクセス制御 (RBAC):
- アクセスの許可/拒否: ポリシーに合致すればリソースへのアクセスを許可し、そうでなければアクセスを拒否します
認可プロセス全体を通じて、最小権限の原則 が適用されシステム全体のセキュリティが確保されます。
OAuth 2.0/OIDCによる認可の委譲（アクセストークンの発行）
アプリケーションがリソースサーバー（API）にアクセスするための「許可証」であるアクセストークンを取得するプロセスです。
-
認可要求 (Authorization Request): クライアントアプリケーションは、ユーザー（リソースオーナー）に対し、「あなたのこのデータにアクセスする許可が欲しい」と要求します。このとき、具体的なアクセス範囲を スコープ (Scope) として指定します（例:
read:email、write:calendar） - ユーザーの同意 (User Consent): ユーザーは、IdP（認可サーバー）の画面で、クライアントアプリケーションが要求しているスコープを確認し、「許可」または「拒否」を選択します。
- アクセストークンの発行 (Access Token Issuance): ユーザーが許可すると、認可サーバーは、そのユーザーがそのスコープをクライアントに許可したことを証明するアクセストークンをクライアントに発行します。ID/パスワードそのものではなく、「限定された範囲の権限」を持つ許可証
以上です。 OpenID Connect についてめちゃめちゃわかりやすいので、こっちを読んでほしい