認証サバイバルガイド by Auth0
コンセプト
- 認証
- 人物のアイデンティティを特定するプロセス
- 認可
- 人物が権限を持っているかを判断するプロセス
- アイデンティティプロバイダ
- アイデンティティ情報を作成、維持、および管理するエンティティ
- e.g. Google, Facebook, Github
- デジタル署名
- 改ざんがないことを保証するための技術
- e.g. 「これは間違いなく Google が作ったデータだな」
- フレームワークとプロトコル
- フレームワーク=>仕様のみ
- プロトコル=>仕様と実装
OAuth 2.0
- 認可のためのフレームワーク
- サード(しばしばファーストも)パーティアプリケーションによる HTTP サービスへの限定的なアクセスを可能にする認可フレームワーク
- HTTP ベースのリソース(≒REST API)へのアクセス権(認可)を取得できるようにするためのもの
- ユーザ認証は OAuth の目的ではない
- アクセストークンの発行ルールとも言える
- パスワード等のクレデンシャルの共有が不要
- 登場人物(名もない画像編集アプリが、ユーザが Google Photo に保存しているファイルに対して編集を加える場合を想定)
- クライアントアプリケーション
- e.g. 名もない画像編集アプリ
- リソースサーバー
- e.g. Google Photo
- リソースオーナー
- e.g. Google ユーザー(かつ、名もない画像編集アプリのユーザー)
- 認可サーバー
- e.g. Google の認証サーバー
- クライアントアプリケーション
- 余談
- 誰が API を呼び出しているか知りたいだけなら、OAuth2 じゃなくても、API キーを使うだけで事足りる場合もあるので検討してみてね
- 認可サーバを自前で実装しようなどというバカな試みはやめておけ
- 脆弱性もあるし認証には使うな。認証には OIDC を使え。
OpenID Connect
- 認証のためのプロトコル
- ユーザ認証という特定の問題の解決に初めから重点を置いている
- ID トークンを発行する
- OAuth2 の曖昧な部分をはっきりさせている。例えば:
- OAuth2 ではトークンのフォーマットは規定されていないが、OpenID Connect では JWT と規定されている
- ユーザ情報を提供するための UserInfo エンドポイントについて規定されている
- まだ新しく発展途上である
エンタープライズプロトコル
- 企業内の問題は Active Directory などで解決してきたものの、
- ネットワークの外にあるアプリのために、SAML と WS-Federation という 2 つのプロトコルが作られた
SAML
- 異なるドメインをまたがるウェブブラウザベースの SSO
- 2 つのシステム感で必要な Web のやり取りを定義している
- 認証が済むと、真正性を検証可能な「トークン」が発行される
- ややこしいが、SAML といったときには、SAML で定義されているトークンのフォーマットだけを指す場合がある
- SAML のトークン部分だけが別のプロトコルで流用されることがある
WS-Federation
- ウェブブラウザベースの SSO
WS-***
というシリーズがいくつもあってどれもクソだが、その中でも FS-Federation はマシなプロトコル- 2 つのシステム感で必要な Web のやり取りを定義している
- SAML よりもはるかにシンプル
- トークンのフォーマットは事前に定義されていないが、多くの場合 SAML が使われる(ややこしい)
過去のプロトコル
過去のことは忘れて良い。互換性もまったくないし。
- OpenID 🪦
- OpenID 2.0 🪦
- OpenID Connect (現行)
- OAuth 1.0a 🪦
- OAuth 2.0 (現行)
トークンについての詳細
- 参照によるトークン(by-reference)
- Cookie ベースの認証
- ユーザ情報をサーバ側で Lookup する必要がある
- 値によるトークン(by-value)
- JWT ベースの認証
- 自己完結型トークンともいう
- トークン自体にユーザ情報が含まれている