暗号応用技術
認証プロトコル
シングル・サインオン (Single Sign-on:SSO)
SSO とは
認証を集中的に行うサーバで一度ユーザ認証を受ければ,ユーザ認証が必要な他のサーバが提供するサービスも受けられるようにする仕組みである.すなわち,認証処理を一元化し集中的に行うシステムであり,一回の認証の頭文字をとってシングル・サインオン(Single Sign-on:SSO) と呼ばれる.
シングル・サインオンが実現された環境では,認証サーバで一旦認証を受ければ,サーバごとに認証を受けなくてもサービスを利用できるようになる.ユーザがサーバにアクセスすると,サーバ側が認証サーバに問い合わせを行い,認証済みユーザかどうかを判断する.
なお,Liberty Alliance(リバティアライアンス)というネットワーク上での認証連携サービスのための利用者技術の標準化を目的に結集された企業連合があり,SSO 規格の標準化が進められている.
SSO の実現方法
リバースプロキシ型
Web ブラウザからのアクセスを一度リバースプロキシサーバが受け,そのリクエストをバックエンドに置かれた Web サーバ,認証サーバに中継する構造を取る.リバースプロキシ型の SSO は,アプリケーションプロトコルレベルのゲートウェイと考えることが出来,ファイアウォールの一種とも言える.
この方式の SSO は,アプリケーションが稼働しているサーバに新たなソフトウェアの追加が不要であり,プラットフォームに依存せずに SSO を実現できる.ただし,導入時には SSO 環境に含める全てのアプリケーションへのアクセスがプロキシサーバを経由するように、ネットワーク構成を変更する必要がある.
エージェント型
各Web サーバに “エージェント”と呼ばれる認証を代行するソフトウェアを組み込む方式である.リクエストは Webサーバ自身で受け付け,呼び出されたエージェントがユーザのログイン状態とアクセス権限を認証サーバに問い合わせ,呼び出した Webサーバに結果を返す.
エージェント型の SSO は,ネットワーク構成を変更せずに導入でき,拡張性に優れているというメリットがあるが,プラットフォームによっては“エージェント”が対応していない場合もある.
その他
原則的にはエージェント型だが,非対応のアプリケーションをシングルサインオン環境に含める場合はリバースプロキシ型という方式もある.また,クライアント PC に導入してユーザのパスワード入力を代行することで SSO を実現する方式もある.
OAuth
OAuth とは
利用者端末,Webアプリケーションなどにセキュアな API 認可 (authorization) の標準的手段を提供するオープンプロトコルである. あるサービス(サービス A)上にエンドユーザが所有するリソースや,そのエンドユーザがアクセス権限を持つ各種機能に対し,エンドユーザの許可を受けた他のサービス(サービス B)がアクセスするための「アクセス権限の付与」を行うプロトコルである.
すなわち,エンドユーザがサービス B に対して許可を与え,サービス B がサービス A の提供する API にアクセスする許可を受けていることを証明する一連のフローをセキュアに実現するものである. (
OAuth 2.0 )
OAuth の構成
OAuth 認証では,以下の3者でプロトコルを構成する.
Service Provider (OAuth Server)
OAuth をサポートした API を提供しているサービス(Facebook や Twitter など).
Consumer (OAuth Client)
Service Provider が提供する API を利用する側のサービス.
User (Resource Owner)
アカウントを持ち,アクセス権限の付与を行うユーザ.
OAuth の認証手順
Consumer 登録 (事前準備)
事前に Provider に Consumer 登録を行う.登録すると,Consumer Key と Consumer Secret が発行される.
OAuth 認証の要求
ユーザは,Consumer に OAuth認証を要求する.
Consumer は,Provider からリクエストトークンを取得する.
Consumer から Provider へ HTTP通信でリクエストトークンを要求する.リクエストトークンの要求では,事前に発行されている Consumer Key とリクエストパラメータを Consumer Secret で署名した値をパラメータとして付与する.Provider は,レスポンスとしてリクエストトークンを返す.
認証用 URLへのリダイレクトとユーザ承認
Consumer は,発行されたリクエストトークンを URL に付与して,Provider の認証用 URL へリダイレクトを行う.リダイレクト先で,Provider がユーザに対して Consumer が要求している OAuth認証による API 利用を許可するか否かを判断する.承認する場合は,Provider は Consumer 登録時に設定したコールバック URL へリダイクレトする.
アクセストークンの取得
コールバック URL へのリダイレクトで,Consumer はリクエストトークンをもとにアクセストークン取得を HTTP通信で Provider へ要求する.アクセストークン取得要求は,Consumer Key とリクエストトークンなどをパラメータに付与して呼び出す.アクセストークン取得要求のパラメータも Consumer Secretで署名した値を付与する.Provider は,レスポンスとしてアクセストークンを返す.
OAuth での API 呼び出し
実際の API 呼び出しは,取得したアクセストークンをパラメータに付与して呼び出す.アクセストークンと Consumer Key,およびパラメータを Consumer Secret で署名した値を Authorization ヘッダに設定して API を呼び出すことで OAuth認証を利用した API 呼び出しができる.
OpenID
OpenID とは
OpenID は,ユーザ認証関連の標準化を行なう OpenID 財団 (OpenID Foundation) が定める認証方式 (プロトコル) に関する規格であり,次のような仕様が公開されている. 様々な Webサイトで共通の ID 情報を利用できる認証方式であり,その ID 情報自体も OPenID と言われる (参照:OpenID ファウンデーション・ジャパン) .
OpenID Authentication 2.0
OpenID Connect (OAuth 2.0 仕様をベースにアイデンティティ層を拡張)
インターネット上のサービスを利用するには,通常個々のサイトごとに ID やパスワードの登録を行う必要があるが,OpenID に対応しているサイトでは自分の持つ OpenID でログインしてサービスを利用することができる. OpenID の発行はどこのサイトでも行うことができ,OpenID 対応サイトでは原則としてどこが発行した OpenID でも利用可能である.
OpenID は,従来の一元管理型の ID 共用システムと異なり,発行も利用も原則として自由に行うことができる点が特徴であり,異なるサービス間でユーザの認証情報を受け渡す方法を定義したプロトコルと言える.
OpenID 認証
OpenID では,個人のユーザ名に相当するデータは Webサイトの URL である.OpenID 対応サイトが認証を行うには,ユーザの提示した URL にアクセスし認証サーバにユーザが本人かどうかを問い合わせる. OpenID 2.0からは,固有の URL を提示する代わりに認証サーバのドメイン名を伝える方式も用意されている.ID としてドメイン名を提示するとその認証サーバのログイン画面が表示され,認証が完了すると自動的に対応サイトに移動する.
ユーザを識別するには,URI ベースの Claimed Identifier(主張識別子)を用いる.これは,ユーザが入力したものではなく,認証サーバが割り当てた再利用されない URI である.そのため,ユーザ識別子の使い回しによる旧ユーザのアカウントを新ユーザがのっとってしまう User Impersonation と呼ばれる問題が解決されるなどの特徴を持っている.
また,OpenID の拡張仕様を利用することにより,ユーザの属性情報と連携することができる他,どのような本人確認や認証手段(パスワード,ICカードなど)を使ったかなどの 認証コンテキストも同時に連携可能になる.
OpenID の使い方
ある OpenID 対応サイト A (URL : sampleA.co.jp) に ID とパスワードを登録している場合に,他の OpenID 対応サイト B にログインする場合,次のような操作になる.
OpenID 対応サイト B で,OpenID アイコンのある入力欄に「sampleA.co.jp」と入力して次の画面へ進む.
サイト A のログイン画面が表示されるので,サイト A の ID とパスワードを入力してログインする.
OpenID 対応サイト B へログインを続けるかを確認する画面が表示されるので,確認したうえで「同意する」ボタンを押す.