この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本記事はDevelopers.IO 2019 Tokyo 「アイデンティティジャーニー 〜アイデンティティの世界を俯瞰して見てみよう〜」 のセッションレポートとなります。
セッション概要
アイデンティティについて様々な手法がどのような背景でできたかの歴史を追っていき、アイデンティティの世界を俯瞰しながら確認していく。
登壇者
中島りか 様（Auth0社）
目的
- Auth0でどのような問題が解決できるかを理解する
- 基本的なアイデンティティの概念と用語を理解する
アイデンティティはなぜ複雑か
- アイデンティティの世界を簡潔に考えると、ユーザとリソースといった2つのアイコンのみが存在する
- シンプルに考えられるはずだがなぜアイデンティティがここまで複雑になるのか
- ミッションクリティカルである
- インシデントが発生した時の二次災害が非常に大きい
- 考慮すべき変数が非常に多い
- API経由でのプログラムアクセスのために様々な言語でのSDKの準備が必要になる
- 異なるリソースへの保存先によってアイデンティティの対処方法が異なる
- Facebookや社内システムのようなリソースにはどこかにアイデンティティが保存されている
- しかし、アイデンティティの取り出し方が異なる
- 情報の出力元に合わせて、アイデンティティの抽出先を考慮する必要がある
- ミッションクリティカルである
Auth0が解決すること
認証における複雑さを解決
- すでにセットアップされたIdPやエンタープライズディレクトリの提供
- セットアップ済みのIdPが豊富にある
- 設定もAuth0のダッシュボードからフリップだけで設定可能
- 豊富なSDKやサンプル
- 様々な言語でのSDKを提供しており、開発スタックに合わせての利用が可能
- 顧客体験に合わせた調整
- ビジネスニーズに合わせてた拡張機能の提供
次項からはアイディンティティのテクノロジーがどのように発展していったかを時系列で確認していきます。
ユーザネーム/パスワードの時代
- ユーザとリソースがアイコンとして存在してこれらが1対1の関係になっている
- この時代でのアイデンティティはシチュエーションによって異なる
デジタルアイデンティティ
- ユーザに関する情報の集合
- ユーザなどをシステムが処理する情報と紐づけるもの
- 例） Amazonにおけるはユーザのクレジットカード番号や住所、注文履歴などがアイデンティティ
- 例） ネットバンクにおける銀行口座番号や預金残高はアイデンティティだが、Amazonの注文履歴はアイデンティティではなく、保持もしてない
考え方
- ユーザとリソースの間で何かしらの秘密を共有する
- ユーザはリソースに対して秘密を提出することでユーザであることを証明する
- リソースは提出された秘密からユーザであることを確認する
- 確認するためにDBに保存されている情報と秘密を照らし合わせる
問題点
- いつ、どの情報を持ってくるか
- シンプルな考え方ではあるが、流出などの問題が絶えない
- 古くからある考えではあるがこの方式をなくすことはまだできていない
- パスワードが一種のビルディングブロックのようなものであり、その上に高度なプロトコルとして様々な処理をするように実装するのが実情
ディレクトリの時代
- 時代が進むとともにユーザが複数のアプリケーションを使うようになる
- 「ユーザネーム/パスワードの時代」の考えだとユーザとリソースが1対1の関係になるため、リソース単位でパスワードを設定、入力する必要がある
- リソースごとにパスワードを設定するのでユーザは同じパスワードを設定することも問題になる
- 自動化もまだまだ進んでいない時代だったので管理者もリソース単位で登録、削除をする必要があるため、オペレーションミスが発生しやすく作業自体も非常に辛い
- これらの問題を解決するために考案された考え方が「ディレクトリ」
ディレクトリとは
- ユーザ情報やクレデンシャルを1箇所に集める
- ユーザとディレクトリは1対1の関係を築ける（ディレクトリとリソースが1対Nの関係になる）
- リソースからするとディレクトリがユーザ情報を管理しているのでアプリ側で独自の認証ロジックの実装は不要になる
- ユーザからすると一度の認証手続きで全てのサービスにアクセスすることができる（SSOと呼ばれる）
問題点
- 業務委託や共同開発などで組織がまたがる時に別組織のリソースに対してアクセスできない
- Aという組織のユーザがAのサービスにAのディレクトリを使用してアクセスできたとしても、Bの組織のサービスにはアクセスできない
- 初めはシャドーユーザを外部ディレクトリに作成することで解消していた
- 単純に外部ディレクトリに対してユーザを発行してユーザを渡すだけ
- ユーザとディレクトリが1対Nの関係になるので「ユーザネーム/パスワードの時代」に発生した問題が再発する
クロスドメインSSO SAML（Security Assertion Markup Language）の登場
- リソースが外部ディレクトリと信頼関係を結ぶことでSSOを実現する
- ユーザとディレクトリが1対1の関係になる
- プロトコルとしてケルベロス認証を使用している
- サービス側ではSAMLリクエストを生成できるように準備が必要
- ディレクトリとサービスで信頼関係を結ぶことで実現できる
クロスドメインSSOの認証までの流れ
- ユーザがディレクトリ外のサービスに対してアクセスをする
- 外部サービスがユーザの属するディレクトリに対してSAMLリクエストを渡す
- ケルベロス認証を行いセキュリティートークン（電子署名）を発行する
- 1の過程でユーザは認証情報を渡しているので再度入力する必要がない
- 電子署名なので改ざんは不可能
- 信頼できるかどうかの判断材料となる、現実世界のパスポートのような重要な情報である
- セキュリティトークンの改ざんチェックなどを起こってからセッションクッキーを発行して外部サービスに渡す
- セッションクッキーがあるのでユーザが外部サービスにアクセスできるようになる
クレデンシャルの共有の時代
- コンシューマでもサービスを使うことが増えてくると、サービスから別サービスを扱いたいといった要件も出てくる
- 例えばSpotifyからFacebookアカウントの友達を見て、Spotifyに招待をするなどのユースケースが起きる
- SpotifyにFacebookを操作するためのクレデンシャル情報が必要になる
- このことでやりたいことは実現できるが今までの考えだとFacebookのユーザネームとパスワードをSpotifyに渡す必要が出る
- 全権限を渡しているため、仮に流出した際に致命的な問題になる
- パスワードを使いまわしている場合などに2次災害が起きる可能性も十分にある
OAuth
- 渡すべき権限を絞り混んで権限委任を行うためのプロトコル
- サービスの全権限ではなくて、「ユーザ情報を確認する権限」などといった形で一部の権限だけを渡せる
- ユーザとサービスに加え認可サーバが登場し、権限委任に関する処理を行う
- 認可サーバには「認可エンドポイント」と「トークンエンドポイント」の2種類のエンドポインが存在する
- 認可エンドポイント: サービスと認可サーバがやりとりをする
- トークンエンドポイント: 認可コードを元にアクセストークンを発行する
権限委任までの流れ
- 先ほどの例を用いて説明する
- SpotifyがFacebookに必要権限リクエストのために認可エンドポイントにリクエストを渡しユーザをFacebookのページにリダイレクトさせる
- Facebookへのアクセス権限をSpotifyに対して委任することの承認をユーザに求める
- Facebookでログインが済んでいない場合はここでログインが求められる
- 認可サーバはSpotifyのエンドポイントに対して認可コードを渡す
- Spotifyは認可コードと様々な情報をFacebookのトークンエンドポイントに対して渡す
- 認可サーバはアクセストークンを発行し、Spotifyに返す
- Spotifyはアクセストークンを使用してAPIをコールする
問題点
- OAuthが認可のためのプロトコルであるのにそれ以上のこと（認証など）を担わされる可能性がある
- トークン置換攻撃の可能性がある
- アクセストークンを元にAPIに対してリクエストを投げてレスポンスを返すので、API側の標準化が難しい
OpenID Connect
- OAuthでは認証ができないことと、API標準化の問題を解決するための仕様
- OAuthで使用するアクセストークンに加えてIDトークンを返す
- JWTであるのでユーザが誰であるかの特定ができ、署名がなされるので認証に使用できる
- 「jwt.io」ではJWTのデコードができる（Auth0社でホスティングしている
Auth0 Day 2019
Auth0社初の自社イベントを東京で開催されます。
Auth0を実際にどのように活用しているか、プロダクトの歴史からこれから目指す方向について聞くことができます。
もしアイデンティティ周りに悩みがございましたら参加してみてください。
- 開催日時: 2019/11/19（火） 12:45
- 開催場所: Nagatacho GRiD
- 申し込みページ: Auth0 Day 2019
さいごに
ユーザとサービスのみから始まるシンプルなアイデンティティからIdPなどが登場するSAMLやOAuth、OpenID Connectがどのような経由で発展したのかを歴史から捉えることができました。 また認証や認可については一歩間違えれば重大な事故に繋がる要素ですので今後も理解を深めていきたいと思いました。
関連資料
本セッションには出てきていませんが、Auth0社が公開しているブログの中で関連があるものを一部抜粋しました。
2
