いまどきのシングルサインオン事情 (第3回 コンシューマ編)

IT・IT製品TOP > Key Conductors > 野村 健太郎(オープンソース・ソリューション・テクノロジ株式会社 ) > いまどきのシングルサインオン事情 (第3回 コンシューマ編)
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

いまどきのシングルサインオン事情 (第3回 コンシューマ編)

エンドポイントセキュリティ 2013/06/18

 本連載の第1回では企業向けシングルサインオンの動向について解説し、第2回では文教分野(主に大学向け)におけるシングルサインオンの動向を解説した。今回はコンシューマ向けシングルサインオンの動向について解説する。コンシューマ向けシングルサインオンで旬な話題といえばOAuth 2.0やOpenID Connectだろう。今回はこの2つのプロトコルについて概要を解説する。

アクセス権限の委譲に利用されるOAuth 2.0

 OAuthは簡単に言うと、「ユーザの同意に基づいたアクセス権限の委譲」のためのプロトコルである。インターネット上のサービス間や、インターネット上のサービスとスマートフォンアプリケーション間でユーザに関する情報(例えば、メールアドレスなど)を、APIを通じて連携するために利用される。

 OAuthが登場する以前は、インターネット上のサービス間でユーザ情報を連携するためには、ユーザ情報を提供するサービス(図1のWebアプリSV)のID/パスワードを、ユーザ情報を利用するサービス(図1のWebアプリCL)に直接渡し、そのID/パスワードを利用することでサービス間のユーザ情報連携を行なっていた。

図1.ID/パスワードを直接利用したサービス間連携

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図1.ID/パスワードを直接利用したサービス間連携

 しかし、このような方法では以下のような問題が存在した。

■ユーザのID/パスワードを必要に応じて複数のサービスに渡す必要がある。ID/パスワードの提供を受けたサービスは、平文、もしくは復号化可能な形式でID/パスワードを保存する必要がある。

■ユーザ情報を利用するサービス(図1のWebアプリCL)でID/パスワードが漏洩すると、ユーザ情報を提供するサービス(図1のWebアプリSV)の情報漏洩にもつながる。

■ID/パスワードを直接渡してしまうので、ユーザ本人と同等の権限を与えることになり、アクセス権限を細かく管理できない。

 そこで、これらの問題を解決するためにOAuthが考案された。OAuthではID/パスワードを直接渡す代わりに「アクセストークン」を利用する。アクセストークンとは、簡単に言うとWebサービスのAPIから取得できる情報や取得可能な期間などを制限したアクセス権限を表す情報である。OAuthの最新バージョンがOAuth 2.0であり、RFCとして仕様が策定されている。OAuth 2.0に関する情報はインターネット上にも数多く存在するため、ここでは用語や詳細な処理シーケンスなどの解説は割愛させて頂く。

図2.OAuth 2.0のAuthorization code flowを利用したユーザ情報の取得(簡略化したシーケンス)

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図2.OAuth 2.0のAuthorization code flowを利用したユーザ情報の取得(簡略化したシーケンス)

 まれにOAuthが「認可のためのプロトコル」と説明されていることがあるが、こような表現には注意して頂きたい。OAuthの場合の認可という言葉の裏には「ユーザ(Resource Owner)の同意に基づいて、サードパーティのアプリケーション(OAuth 2.0 Client)がユーザ情報を提供するAPI(Resource Server)にアクセスすることを許可する」という意味が含まれている。企業や大学などでは連携先アプリケーションに渡す情報の管理は管理者が行うことがほとんどであると思われるが、OAuthの場合は連携先アプリケーションに渡す情報の管理はユーザ自身が行う。そのため、ID管理/アクセス管理の分野で一般的に使われる認可という言葉とは少し意味が異なるということを覚えておいて頂きたい。

 OAuthはアクセス権限委譲のための仕組みだが、アクセス権限を付与されたアプリケーション(OAuth 2.0 Client)がメールアドレスなどのユーザ識別情報を取得することができれば、アプリケーション側でその情報から本人確認を行うこともできる。つまり認証を行うことも可能ということである。実際に、OAuthを利用した認証の仕組みは既に多くのサービスやアプリケーションで実装されており、「OAuth認証」などと呼ばれることもある。

認証情報の連携に利用されるOpenID Connect

 OpenID ConnectはOAuth 2.0の拡張というかたちで仕様の策定が進んでいる、認証情報を連携するためのプロトコルである。OAuth 2.0がアクセス権限委譲のための情報であるアクセストークンを連携先のアプリケーション(OAuth  2.0 Client)に渡すのに対し、OpenID Connectではユーザ識別情報である「IDトークン」を連携先のアプリケーション(OpenID Relying Party)に渡す。必要に応じて、OAuth 2.0のアクセストークンとOpenID ConnectのIDトークンを同時に取得し、ユーザ認証後にその他のユーザ情報を取得することもできる。

 単純に認証だけを行いたいのであれば、OAuth 2.0のアクセストークンを利用してユーザ情報を取得するよりも、OpenID ConnectのIDトークンを利用することが推奨される。認証情報を連携するという意味では、OpenID Connectが果たす役割はSAMLに似ている。

図3.OpneID ConnectのBasic Client Profileを利用したユーザ認証(簡略化したシーケンス)

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図3.OpneID ConnectのBasic Client Profileを利用したユーザ認証(簡略化したシーケンス)

 次回(最終回)は、これまで解説した動向を踏まえて、本連載のタイトルでもある“いまどきのシングルサインオン環境”に求められる要件についてまとめる。

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30006213


IT・IT製品TOP > Key Conductors > 野村 健太郎(オープンソース・ソリューション・テクノロジ株式会社 ) > いまどきのシングルサインオン事情 (第3回 コンシューマ編)

このページの先頭へ

キーマンズネットとは
Open Standard Cloud Association(OSCA)所属。某SIerでのID管理/アクセス管理製品のプリセールスを経て、2009年にOSSTechに入社。オープンソースソフトウェアであるOpenAMやOpenLDAPを利用したシングルサインオンシステムの構築を担当している。

ページトップへ