フェデレーションアイデンティティとは？図を使って説明
はじめに
社内の勉強会で認証について学習する機会があり、アウトプットのため記事にまとめます。
フェデレーションアイデンティティを選んだのは、名前がかっこいいからです。
この記事で書くこと
- フェデレーションアイデンティティの概要
- フェデレーションアイデンティティによる認証の流れの一例
フェデレーションアイデンティティとは
平均的な従業員は、191個のパスワードを持ち[1]、これらを使い分ける必要があるそうです。
衝撃的な数字ですね。（弊社もやたらといろんなアカウントを作ってる気がする）
筆者はパスワードを同じファイルにメモしていますが、メモし忘れたり、そもそも探すのも大変でアカウント管理ってめんどうだなぁとつくづく思ったりしています。
そこで活躍するのがフェデレーションアイデンティティです！
フェデレーションアイデンティティは、異なるサービス間でユーザー情報を共有する仕組みです。
これにより、同一の認証情報（ユーザー名やパスワード）を用いて異なるサービスにアクセスできるようになります。
アイデンティティとは
ユーザーの身元情報のことです。
これにはユーザー名、パスワード、メールアドレスなど、ユーザーを特定するためのデータが含まれます。
フェデレーションアイデンティティの利点
セキュリティの強化: 単一の認証システムを使用することで、セキュリティの一貫性を保ち、潜在的リスクを減少させることができます。
利便性の向上: ユーザーは異なるサービスに対して、複数のログイン情報を覚える必要がなくなり、利便性を向上させられます。
使用されている代表的な規格
フェデレーションアイデンティティに使われる規格として、「SAML」「OpenID Connect」が挙げられます。
どちらも認証と認可を分離し、ユーザー情報を安全に受け渡すことを目的に使われます。
違いはユーザー情報の記述フォーマットです。
SAMLはXML形式に対し、OpenID ConnectはJSON形式です。
SAML（Security Assertion Markup Language）
異なるサービスでユーザー情報を一元化するための規格です。
2002年に策定され、国内サービスだと、「トラスト・ログインbyGMO」や「HENNGE One」などで使用されています。
OpenID Connect
SAMLと同じく、異なるサービスでユーザー情報を一元化するための規格です。
JSON形式でやりとりをするため、APIを使ってユーザー情報を連携したい場合に使える技術として注目されています。
フェデレーション認証の流れ
ユーザー目線の流れ
Gooleログインを例にします。
サイトにアクセスし 「Googleログイン」ボタンを押下すると、下の図のような確認モーダルが表示されます。
「確認」を押すと、ログイン完了です。
ユーザーは裏側の出来事を意識せずに少ないパスワードで、ログインすることができます。
システム目線の流れ
流れがわかりやすいように具体的なサービスを例に使用しています。ここでの例としては、アイデンティティプロバイダーにGoogleを、認可サーバーにAuth０を想定します。
登場人物
- アイデンティティプロバイダー
- IDを識別し、ユーザーが本人であるかを確認するシステム。
- Google,X(旧twitter),facebookなど。
- 認可サーバー
- 認証情報（アクセストークンなど）を発行してくれるサーバー
- Auth0やAWS Cognitoなど。
- リソースサーバー
- リソース（API、画面など）にアクセスするために認証が必要なサーバー
- はてなブログ、Qiitaなど。
一般的なフェデレーションアイデンティティの処理の流れ
- ユーザーが認証が必要なリソースサーバーへアクセス。
- ユーザーはまだ認証情報を持っていないため、認可サーバーへリダイレクトされる。
- 認可サーバーにより、ユーザーはアイデンティティプロバイダーのログイン画面にリダイレクトされる。ユーザーはログインを行う。
- 正常にログインすると、認可サーバーにリダイレクトされる。認可サーバーは、リソースサーバーが要求する認証情報をユーザーに渡す。
- 認可サーバーによってユーザーはリソースサーバーにリダイレクトされる。
- ユーザーは認証情報をもっているため、リソースサーバーに正常にアクセスできる。
まとめ
フェデレーションアイデンティティについて、その概要と流れを解説しました。
参考文献
jwt ハンドブック
Discussion