プロトコル

実装ではなく、みんなが従う「約束事」そのもの

ツールやサービスが互いにつながるための共通の決まり。自分で実装せず、用語を知るために読む。

いつこの種別を選ぶか

選ぶものではなく、知るもの。「Google でログイン」の裏側を説明できるようになれば十分で、自分で実装しない

他の種別との関係

種別 どういう関係か
ツール ツールはプロトコルに従って他とつながる。Git のプロトコル、HTTP、OAuth
マネージドサービス 認証サービスは OAuth 2.0 / OpenID Connect というプロトコルの実装。サービスを乗り換えても約束事は同じ
ツール (から見ると) ツールは何らかのプロトコル(約束事)に従って他とつながる。Git のプロトコル、OAuth の流れ

この種別を理解する

実装が別にある。 OAuth 2.0 は「他社のログインを借りる手順」を決めた文書で、Auth0 や Clerk や Supabase がそれを実装している。プロトコルそのものはダウンロードできないし、料金もない。

なぜ載せているか。 認証サービスを使うと、アクセストークン、リダイレクト URI、スコープといった用語が必ず出てくる。これらはサービス固有の言葉ではなく、プロトコルで決まった言葉である。約束事を知っていれば、サービスを乗り換えても同じ理解が使い回せる。

制約は「仕様がそう決めている」形で現れる。 認可コードは10分以内、リダイレクト先は完全一致、といった条項が制約にあたる。実装が守っていないと、つながらないか、安全でなくなる。

次に読む種別。 プロトコルを実装している「ツール」と「マネージドサービス」。

この種別のツール(1件)

分野ごとに並べている。「主要制約」は各ツールで最も先に当たる限界。

認証・セキュリティ 誰がアクセスできるかを決め、守る

ツール 学習 料金 成熟 主要制約 検証
OAuth 2.0 / OpenID Connect
認可・認証の標準仕様。実装はAuth0等の各サービスに委ねる
無料 安定 リダイレクトURIの一致要件: 完全な文字列一致が必須(RFC 6749 3.1.2.3節、RFC 3986 6.2.1節に基づく単純な文字列比較)