プロトコル
実装ではなく、みんなが従う「約束事」そのもの
ツールやサービスが互いにつながるための共通の決まり。自分で実装せず、用語を知るために読む。
いつこの種別を選ぶか
選ぶものではなく、知るもの。「Google でログイン」の裏側を説明できるようになれば十分で、自分で実装しない
他の種別との関係
この種別を理解する
実装が別にある。 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節に基づく単純な文字列比較) |