アーカイブ

第2章 2.ユーザ認証を外部化する場合

公開日:2007年6月28日

独立行政法人情報処理推進機構
セキュリティセンター

本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。

複数のWebアプリケーションがユーザ認証の機能を外部に一元化することによって、ユーザがパスワードを覚える負担を低減することができる。また、Webアプリケーションのオーナは、パーソナル情報の管理の負担とリスクを外部に転嫁することができる。

外部のユーザ認証サービスと連係動作するしくみ

パスワードを用いたユーザ認証機能として、Webアプリケーションから利用可能な外部サービスが、2005年頃から提供されるようになってきた。

  • Webアプリケーションを使用しパスワードを用いたユーザ認証機能サービスを示す図
    図2-2: ユーザ認証機能を外部化する

ユーザによるアクセス要求を遮断できるコードを開発して、そこから外部のユーザ認証サービスとアクセス認可判定の処理を順に呼び出すようにする。この要求を遮断できるコードは、PEP(Policy Enforcement Point)の役割を果たす。

ユーザ認証の結果をPEPに伝達するしくみとしては、「HTTPリダイレクト」の機能が応用されているものが多い。

ユーザ認証を外部化するメリット

複数のサイトが共通のユーザ認証サービスを利用する構図を示す。

  • 複数のサイトが共通のユーザ認証サービスを利用する構図
    図2-3:ユーザ認証を外部化するメリット

ユーザ側には下記のメリットがある。

  • サイトごとにパスワードを覚える必要が無くなり、「パスワードリスト攻撃」対策が軽減される。

Webアプリケーションのオーナ側には下記のメリットがある。

  • 法的責任を伴う面倒なパーソナルデータの管理を専門組織に委ねることができる。
  • アカウント登録の敷居を下げることによって、新規ユーザーを獲得し易くなる。
  • ユーザ認証機能をもたないことによって、開発資源をコンテンツやサービスに集中できる。

OpenID Connect の特徴

外部のユーザ認証サービスとして OpenID Connect によるサービスを利用することができる。基本的な「認可コードフロー(Authorization code flow)」の場合の構図を示す。

  • 基本的な認可コードフローの場合の構図
    図2-4: OpenID Connect の構図

ユーザ認証は「認可Endpoint」において行われる。そのユーザ認証の結果を伝達するにあたり、まずOpenID Connectプロバイダは「認可コード」を生成する。(注: ユーザ認証を行うにもかかわらず「認可Endpoint」と呼ばれる理由は、ベースとなったプロトコル(OAuth 2.0)の仕様に起因する。)

Webアプリケーションは認可コードを「トークンEndpoint」に送信する。同時にWebアプリケーションから「トークンEndpoint」宛には「Client Secret」が送られ、そのWebアプリケーションが本物であることが伝えられる。OpenID Connectプロバイダは、認可コードを「IDトークン」と交換し、Webアプリケーションにユーザ認証の結果を渡す。

「IDトークン」のフォーマットとしては JWT(JSON Web Token)仕様が使われる。JWT仕様は、デジタル署名や暗号化による防護機能を提供している。

「アクセストークン」も、Webアプリケーションに渡る。これは、ユーザ認証を行ったOpenID Connect プロバイダに対して、ユーザについての属性情報を取得する際に使われる。例えば、今回ユーザ認証が成功したユーザについての追加的な属性情報を求めてアクセス認可に利用することができる。追加的な属性情報の利用可能性は、OpenID Connectプロバイダがサポートしているスコープに拠ることになる。

参考資料: