JP6335657B2 - 権限委譲システム、方法、認証サーバーシステム、およびプログラム - Google Patents

Description

ユーザーの権限を別の主体に移譲する認可を行う権限委譲システム、方法、認証サーバーシステム、およびプログラムに関する。

近年インターネット上でＰＤＦ形式の電子文書を作成するサービスや電子文書を蓄積するサービス等が提供されている。このようなサービスを利用することでユーザーは、自身が所有する端末自体にＰＤＦ作成機能がない場合でもＰＤＦを作成できるようになる他、端末の記憶容量以上に電子文書を保管できるようにもなる。さらに近年、クラウドが一般化するに伴い、前述のような複数のサービスを連携させて付加価値を創造する機会はますます増加している。サービスを連携させることでサービス提供者は、ユーザーに付加価値を提供することができる。例えば作成したＰＤＦ形式の電子文書を、ユーザーが所有する端末を経由することなく、直接インターネット上で保管できるようにもなる。その一方で、サービスが連携することにより、いくつかの課題が生まれる。

すなわち、ユーザーが望んだ以上の情報がサービス間で交換されるので、ユーザーデータや個人情報の漏えいリスクがある。例えばインターネット上には複数のサービスが存在し、様々なサービス間でサービス連携が実現されるが、ユーザーが望む結果を提供するサービス以外のサービスがユーザーデータ、個人情報等を取得することは望ましくない。一方で、サービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。

このような状況において、ＯＡｕｔｈ（非特許文献１）と呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈについては以降でさらに詳細に説明する。ＯＡｕｔｈによれば、例えばあるサービスＡが管理するユーザーのデータに、そのユーザーから認められた外部サービスＢがアクセスすることができる。このときサービスＡは、外部サービスＢからアクセスされる範囲を明らかにした上で、外部サービスＢによるアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを認可操作と称する。

ユーザーが認可操作を行うと、外部サービスＢはサービスＡからアクセスを認められたことを証明するトークン（以下、アクセストークンと称する）を受け取り、以降のアクセスはそのアクセストークンを用いて実現できる。ここでアクセストークンを用いると外部サービスＢは、ユーザーを認証したことを示す情報なしに、認可を行ったユーザーの権限でサービスＡにアクセスできる。またそのため、ユーザーから認可を受けアクセストークンを取得した外部サービスＢは、そのアクセストークンを厳重かつ適正に管理する責務を負う。

また近年の機器には、ＯＡｕｔｈを用いて、クラウドサービスと連携することでユーザーに付加価値を提供するものがある。例えばソーシャル・ネットワーキング・サービス（以下、ＳＮＳと呼ぶ）と呼ばれるサービスがある。これらのサービスはスマートフォンから利用することができる。ＳＮＳには様々なものがあるが、特定のアプリケーションをスマートフォンにインストールして利用することで、そのＳＮＳを利用しやすくなることがある。例えば定期的に自分の居場所をＳＮＳに投稿したいユーザーは、スマートフォンの測位機能を使い、定期的に測位とＳＮＳへの投稿を行うアプリケーションを利用すると、便利と感じるだろう。ここでスマートフォンにインストールされたアプリケーションは、ＳＮＳにユーザーの代理でアクセスすることになる。このような場合にＯＡｕｔｈが利用されることがある。ユーザーは、ＳＮＳを利用するのに必要な最小限の機能、例えば記事を投稿することをアプリケーションに許可することで、アプリケーションを介してＳＮＳを利用できるようになる。

ところでＯＡｕｔｈにおいては、ＪａｖａＳｃｒｉｐｔ（登録商標）の様なスクリプト言語によるブラウザー上で実行されるクライアントに最適化されている、インプリシットグラントと呼ばれるアクセストークン取得のフローが定義されている。インプリシットグラントタイプにおけるクライアントは、リソースオーナーの認可後、アクセストークン取得のための仲介のクレデンシャルである認可コードではなく、直接アクセストークンを受け取る。このグラントタイプは、認可コードのようなアクセストークン取得を仲介するクレデンシャルを利用しないため、インプリシットグラントと呼ばれる。現状Ｗｅｂブラウザーから上述したサービスを利用する場合、認証したことを示す情報をＣｏｏｋｉｅ等でログインセッションを引き回し、ＯＡｕｔｈのような認可確認を明示的に行わない実装もおこなわれている。さらに、現在ＷｅｂブラウザーからもｊＱｕｅｒｙ等を用いたＡＰＩアクセスで前記クラウドサービスと連携するサービスを利用する形態がデファクトスタンダードになりつつある。この背景としては、モバイルの普及やブラウザーＯＳの登場といったトレンドが影響している。

"Ｔｈｅ ＯＡｕｔｈ １．０ Ｐｒｏｔｏｃｏｌ"、［ｏｎｌｉｎｅ］ Ｅ． Ｈａｍｍｅｒ−Ｌａｈａｖ、２０１２年９月 ＜ＵＲＬ ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５８４９＞

現在スタンダードな手法になりつつあるｊＱｕｅｒｙを用いたＡＰＩアクセスによりクラウドサービスを利用する形態の場合、認可フローとしてＯＡｕｔｈを使用することになる。その場合、例え、クライアントアプリケーションとクラウド上のサーバーアプリケーションが共に自社製のアプリケーションでも、ユーザーの利便性を損なうような認可確認が必要になる。その他の課題として、Ｗｅｂブラウザーをクライアントとするようなアプリケーションにおいても同様に、ユーザーの利便性を損なうような認可確認が必要になる。

本発明の目的の１つは、上述した課題の少なくとも１つの課題を解決することが可能な権限移譲システムの提案である。

本発明の一実施形に係る権限移譲システムは、クライアントから利用可能なサービスを備えるサーバーシステムと、前記サービスを利用するクライアントとを含む権限移譲システムであって、前記クライアントにて表示される認証画面を介しユーザーから入力された認証情報を基に、前記ユーザーが正規なユーザーであるか否かを判断する認証手段と、前記認証手段により正規なユーザーであると判断された前記ユーザーが前記クライアントにて表示される認可確認画面を介し、前記サービスにおける前記ユーザーの権限を前記クライアントへ移譲することを許可する指示をした場合に、前記ユーザーの権限が前記クライアントへ移譲されたことを示す権限情報を発行する発行手段と、前記クライアントが前記サービスの利用を要求した際に送信する前記権限情報を基に、前記クライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可手段と、前記サービスのドメインと、前記権限情報を前記クライアントに取得させるためのエンドポイントのドメインとが同一のドメインであるか否かを判断する判断手段とを有し、前記発行手段は、前記判断手段により２つのドメインが同一のドメインであると判断されたことに応じて、前記サービスにおける前記ユーザーの権限を前記クライアントへ移譲することを許可する指示を受け付けることなく、前記ユーザーの権限が前記クライアントへ移譲されたことを示す権限情報を発行することを特徴とする。

ユーザーの利便性を損なうような認可確認を省略することができる。

実施例１のシステム構成図。 実施例１の各装置のハードウェア構成図。 実施例１の各装置のモジュール構成図。 実施例１の認可確認省略可能な認可フロー図。 実施例１の認可サーバー処理のフローチャート。 実施例１のログインおよび認可確認画面。 実施例１の認可クライアントのスクリプト処理のフローチャート。 実施例２のシステム構成図。 実施例２の核装置のモジュール構成図。 実施例２の認可確認省略可能な認可フロー図。 実施例２の認可クライアントのアプリケーション処理のフローチャート。 実施例３の認可確認省略可能な認可フロー図。 実施例３の認可サーバー処理のフローチャート。 実施例３のＷｅｂ−Ｈｏｓｔｅｄ Ｃｌｉｅｎｔ処理のフローチャート。 実施例３の認可クライアントのスクリプト処理のフローチャート。 実施例４の認可サーバー処理のフローチャート。 実施例４の各装置のモジュール構成図。 実施例４のＷｅｂ−Ｈｏｓｔｅｄ Ｃｌｉｅｎｔ処理のフローチャート。 実施例３の各装置のモジュール構成図。

以下、本発明を実施するための最良の形態について図面を用いて説明する。

本実施の形態においては、インターネット上で帳票データを生成する帳票サービスと、インターネット上のデータを取得して印刷する印刷サービスが、インターネット上のサーバーに設置されていることを想定している。以降、帳票サービスや印刷サービスのように、インターネット上で機能を提供しているサービスを、リソースサービスと呼ぶ。

また本実施の形態においては、画像形成装置上にインストールされた印刷アプリケーションおよび帳票アプリケーションがリソースサービスを利用することを想定している。以降、印刷アプリケーションや帳票アプリケーションのように、リソースサービスを利用するアプリケーションを、リソースサービス連携アプリケーションと呼ぶ。無論、リソースサービスは帳票サービス、印刷サービスには限られず、アプリケーションも帳票アプリケーション、印刷アプリケーションに限られるものではない。

さらに本実施の形態における権限の移譲ではＯＡｕｔｈの仕組みを利用する。ＯＡｕｔｈでは、ユーザーから移譲された権限の証明をするための情報として、トークンと呼ばれる情報を利用する。トークンは英数字から構成されるものであるがその表記方法は自由である。トークンを始めとする、ユーザーからクライアントに対して移譲された権限を示す情報を権限情報とここでは呼ぶ。

リダイレクトＵＲＩがサービスの利用元であるクライアントと同一ドメインの場合の認可確認画面スキップについて説明する。ＯＡｕｔｈにおけるクライアントが第三者のサービスではなくＷｅｂブラウザーであるため、Ｗｅｂブラウザーを介して認証操作さえ行われればサービスの利用元が明確になり、Ｗｅｂブラウザーとサービスのドメインが同一とみなすことができるので認可確認画面スキップを行う。

本実施の形態に係る権限移譲システムは、図１に示すような構成のネットワーク上に実現される。１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１、１０２は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１、ＬＡＮ１０２）である。

５００はＯＡｕｔｈを実現するための認可サーバーであり、認可サービスモジュールが設置されている。３００はＯＡｕｔｈにおけるＷｅｂ−Ｈｏｓｔｅｄクライアントリソースを実装するＷｅｂ−Ｈｏｓｔｅｄクライアントである。本実施例では、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００は認可サーバー５００からクライアントＰＣ２００向けのアクセストークンの応答先のリダイレクトＵＲＩとして指定される。４００はリソースサーバーであり、印刷サービスや帳票サービスといったリソースサービス連携アプリケーションが設置されている。なお１台のリソースサーバーに設置されるリソースサービス連携アプリケーションは１つでもよく、複数でもよい。２００はユーザーが操作するクライアントＰＣであり、クライアントＰＣ上のＷｅｂブラウザーを後述するクライアントスクリプトを実行し、４００のリソースサーバーのリソースを用いて印刷サービスや帳票サービスといったサービスを利用する。

本実施例の特徴として、本Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００、クライアントＰＣから利用可能なサービスを備えたリソースサーバー４００が、認可サーバー５００と同一のＬＡＮ１０１に接続されていることが挙げられる。Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００、リソースサーバー４００、認可サーバー５００がＷＡＮ１００を介さずに接続されている。このため、本実施例においてはこれらを同一ドメインとみなし、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００とリソースサーバー４００のサービス連携を同一の認証で賄うことを特徴とする。即ち、認可サーバー５００が、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００とリソースサーバー４００の両方の認証・認可を行うので、ユーザーは一度だけ認証・認可すれば両方を利用できるということになる。

またクライアントＰＣ２００、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００、リソースサーバー４００はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１、ＬＡＮ１０２を介して接続されている。なおクライアントＰＣ２００およびそれぞれのサービスはそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣ上に構成されていてもよい。また、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００、リソースサーバー４００、認可サーバー５００は夫々１台のサーバーとして実施例１では説明するが、夫々のサーバーが複数台のサーバー群で構成されていても良い。そこで、サーバーシステムと称した場合、サーバーが１台または複数台のサーバー群で構成される場合の両方を含むものとする。よって、認証サーバーシステムと称した場合、１台または複数台で構成される認証サーバーということになる。

図２は本実施の形態に係るクライアントＰＣ２００の構成を示す図である。またＷｅｂ−Ｈｏｓｔｅｄクライアント３００、リソースサーバー４００、認可サーバー５００のサーバーコンピューターの構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントＰＣ２００およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１である。また、モジュールやアプリケーションと言ったソフトウェア上の主体は、ハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムがＣＰＵ２０１により実行されることで実現するソフトウェア機能である。

図３は本実施の形態に係る、認可サーバー５００、リソースサーバー４００、クライアントＰＣ２００、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００の、それぞれのモジュール構成を示す図である。夫々のモジュールはＣＰＵ２０１により実行されることで実現するソフトウェア機能である。

認可サーバー５００は認可サーバーモジュール５１０を持ち、認可サーバーモジュール５１０はユーザー識別部６０１、クライアント検証部５２０、トークン発行部５３０、トークン検証部５４０を持つ。リソースサーバー４００はリソースサーバーモジュール４１０を持ち、リソースサーバーモジュール４００はトークン権限確認部４２０とリソース要求処理部４３０を持つ。クライアントＰＣ２００はＣＰＵ２０１がＲＯＭ２０２、或いは外部メモリ２０３に記憶されたＯＳを実行する事で各アプリケーションを制御する。

ここで２２０はそのＯＳであり、一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用される事もある。さらに、クライアントＰＣ２００はＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザー２３０を備える。Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００は、Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０を持つ。Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、クライアントＰＣ２００からのアクセストークン応答のリダイレクトＵＲＩリクエストを受信し、後述するアクセストークン取得とリソースリクエストを行うクライアントスクリプト３２０を返す機能を持つ。

以下に示すＴａｂｌｅ１、Ｔａｂｌｅ２、Ｔａｂｌｅ３は認可サーバー５００が外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー５００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。

Ｔａｂｌｅ１はユーザー管理テーブルである。Ｔａｂｌｅ１ユーザー管理テーブルは、ユーザーＩＤ、パスワード、ユーザー種別から成る。認可サーバー５００は、ユーザーＩＤ、パスワードの情報の組、即ち認証情報を検証し、正規の組み合わせであれば認証したことを示す情報を生成することで、各ユーザーもしくはクライアントを認証する機能を備える。

Ｔａｂｌｅ２はクライアント管理テーブルである。Ｔａｂｌｅ２クライアント管理テーブルはクライアントＩＤ、クライアント名、リダイレクトＵＲＩから成る。クライアントＩＤ、クライアント名、リダイレクトＵＲＩは後述のＯＡｕｔｈのシーケンスで利用される値である。

Ｔａｂｌｅ３はトークン管理テーブルである。Ｔａｂｌｅ３トークン管理テーブルは、トークンＩＤ、有効期限、スコープ、クライアントＩＤ、ユーザーＩＤから成る。これらＴａｂｌｅ３トークン管理テーブルの処理詳細については後述する。

ここで、クライアントＰＣ２００上のブラウザープリケーションを用いてリソースサービスを利用する際に行われる認可フローのシーケンスについて、図４を用いて説明する。ＯＡｕｔｈ２．０の仕様では、多様なクライアントに応じた複数のプロトコルシーケンスをｇｒａｎｔ ｔｙｐｅと呼ぶ。図４の認可フローは、ＯＡｕｔｈ２．０仕様のｉｍｐｌｉｃｉｔ ｇｒａｎｔに本実施例独自の拡張を加えたｇｒａｎｔ ｔｙｐｅである。

まず、保護されたリソースへのアクセスが必要になるユーザーからの認可連携サービス開始要求が発生する（Ｓ４．１）。本サービス要求は、リソースオーナー１０００であるユーザーがリソースサーバー４００に対し、リソースオーナー１０００が操作するユーザーエージェントたるクライアントＰＣ２００上のブラウザーアプリケーションを介してＨＴＴＰプロトコルを用いて行う。具体的には、リソースオーナー１０００たるユーザーはクライアントＰＣ２００を操作してリソースサーバー４００のアプリケーション画面（不図示）にアクセスする（Ｓ４．１）。このアプリケーション画面は例えば、リソースサーバー４００のリソース連携アプリケーションが印刷アプリケーションであった場合は印刷する文書を選択する画面である。帳票アプリケーションであった場合は、作成する帳票を選択する画面である。ここでアプリケーション画面にアクセスするとは、例えば、クライアントＰＣ２００上のブラウザー上に前記アプリケーション画面が選択可能に表示されており、当該アプリケーションを選択する事を指す。当該アプリケーションを選択することにより、リソースオーナー１０００はリソースサーバー４００に対して認可連携サービス開始要求を送信する（Ｓ４．１）。

なお本実施例においてはリソース連携アプリケーションをリソースサーバー４００上としている。しかし一般に、リソース連携アプリケーションはリソースサーバー４００とは別の、クライアントアプリケーションサーバーなどに存在しても良い。本実施例ではリソースサービス連携アプリケーションとして印刷Ｗｅｂアプリケーション、帳票Ｗｅｂアプリケーションといったリソースサービスと連携するクライアントアプリケーションが設置されている。なお１台のリソースサーバーに設置されるリソースサービス連携アプリケーションは１つでもよく、複数でもよい。

次に、リソースサーバー４００は、前記認可連携サービス開始要求（Ｓ４．１）により認可連携の開始を受け付けたる。受け付けたことに応じて、リソースサーバー４００の持つ認可サーバー５００の認証エンドポイントのＵＲＬに対して、Ｃｏｏｋｉｅとしてリソースサーバー４００のＦＱＤＮのドメイン名であるドメインをｄｏｍａｉｎ＝ｅｘａｍｐｌｅ．ｃｏｍのようにセットする（Ｓ４．２）。そしてＯＡｕｔｈの認可リクエストをするよう、クライアントＰＣ２００のブラウザーにＨＴＴＰ／１．１ステータスコード３０２のリダイレクト要求する（Ｓ４．３）。本リダイレクト要求のＨＴＴＰ Ｌｏｃａｔｉｏｎヘッダーにはリソースサーバー４００のＩＤ、認証フローのタイプ、認可サーバー５００の認証エンドポイントのＵＲＬが含まれ、以下のようなリダイレクト要求となる。
ｈｔｔｐｓ：／／ａｕｔｈ．ａ０１．ｅｘａｍｐｌｅ．ｃｏｍ／ａｕｔｈｏｒｉｚｅ？ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ＝ｔｏｋｅｎ＆ｃｌｉｅｎｔ＿ｉｄ＝ｚｔｒ１ＪｈＲＧａ５＆ｓｔａｔｅ＝ｘｙｚ＆ｒｅｄｉｒｅｃｔ＿ｕｒｉ＝ｈｔｔｐｓ％３Ａ％２Ｆ％２Ｆｃｌｉｅｎｔ％２Ｅｅｘａｍｐｌｅ％２Ｅｃｏｍ％２Ｆｃｂ
＆ｓｃｏｐｅ＝ｓｃｏｐｅＡ
ＨＴＴＰメソッド： ＧＥＴ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ
リクエストパラメーターには、ｒｅｓｐｏｎｓｅ＿ｔｙｐｅとして“ｔｏｋｅｎ”固定文字列、ｃｌｉｅｎｔ＿ｉｄとして予めクライアントアプリケーションとして認可サーバー５００に登録したリソースサーバー４００上のクライアントアプリケーションのアプリケーションＩＤを指定する。さらに、ｒｅｄｉｒｅｃｔ＿ｕｒｉとして予めクライアントアプリケーションとして認可サーバー５００に登録したＷｅｂ−Ｈｏｓｔｅｄクライアント３００のＵＲＬを指定する。即ち、このｒｅｄｉｒｅｃｔ＿ｕｒｉのエンドポイントが、権限情報であるアクセストークンをクライアントに取得させるためのスクリプトを生成するＷｅｂ−Ｈｏｔｅｓｔｅｄクライアント３００のアドレスと言える。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成する事もできる。本実施例では、スコープとしてスコープＡがリクエストされたとして説明する。

次に、リダイレクト要求を受信したクライアントＰＣ２００は、上記リダイレクト要求に従い認可サーバー５００に対してユーザー認証、認可の要求を行う（Ｓ４．５）。認可リクエストを受け付けた認可サーバー５００は、ユーザーを認証するために図６ａに示すログイン画面２０００をクライアントＰＣ２００上のブラウザーに応答する（Ｓ４．６）。リソースオーナー１０００であるユーザーはクライアントＰＣ２００上のブラウザーに示されたログイン画面２０００に対して、ユーザーＩＤ、パスワードを入力しログインを実行する（Ｓ４．７）。認可サーバー５００は受け付けたユーザーＩＤ、パスワードの組が前記Ｔａｂｌｅ１ユーザー管理テーブルに登録されている情報と合っているかを検証する。ここで以下に示す図５ａ、５ｂのフローチャートを用いて、ユーザー認証画面表示（Ｓ４．６）、ユーザー認証（Ｓ４．７）、リダイレクトＵＲＩとＣｏｏｋｉｅのドメインパラメーター比較（Ｓ４．８）について説明する。また本実施例の特徴である、認可確認画面表示（Ｓ４．９）、認可確認（Ｓ４．１０）の省略について、およびアクセストークン応答（Ｓ４．１１）について説明する。

図５ａは、前記認可サーバー５００がユーザー認証、認可の要求を受け付けた際の、認可サーバー５００上の認可サーバーモジュール５１０の処理フローチャートである。本フローチャートは、認可サーバーモジュール５１０が前記クライアントＰＣ２００からの前記リダイレクト要求を受信することで始まる（ステップＳ５．１）。認可サーバーモジュール５１０は、ユーザーを認証するために図６ａに示すログイン画面２０００をクライアントＰＣ２００上のブラウザーに応答する。リソースオーナー１０００であるユーザーはクライアントＰＣ２００上のブラウザーに示されたログイン画面２０００に対して、ユーザーＩＤ、パスワードを入力しログインを実行する（Ｓ４．７）。認可サーバー５００は受け付けたユーザーＩＤ、パスワードの組が前記Ｔａｂｌｅ１ユーザー管理テーブルに登録されている情報と合っているかを検証する。（ステップＳ５．２）検証の結果、ユーザーＩＤ、パスワードの組がＴａｂｌｅ１ユーザー管理テーブルに登録されていなければ（ステップＳ５．３）、クライアントＰＣ２００にユーザー認証エラー画面（図示せず）を通知して処理を終了する（ステップＳ５．８）。もし前記検証の結果ユーザーＩＤ、パスワードの組がＴａｂｌｅ１ユーザー管理テーブルに登録されていれば（ステップＳ５．３）、次に認可確認処理（ステップＳ５．４）を行う。

図５ｂは、本実施例における認可サーバー５００上の認可サーバーモジュール５１０の認可確認処理のフローチャートである。認可サーバーモジュール５１０は、本認可確認処理においてステップＳ５．１にて受信した前記クライアントＰＣ２００からの前記リダイレクト要求のリクエストパラメーターを確認する（ステップＳ５．９）。またリクエストに含まれるＣｏｏｋｉｅのドメインパラメーター、例えばｄｏｍａｉｎ＝ｅｘａｍｐｌｅ．ｃｏｍを取得する（ステップＳ５．１０）。ここで認可サーバーモジュール５１０は、Ｔａｂｌｅ２クライアント管理テーブルを参照し、リダイレクト要求のリクエストパラメーターのｃｌｉｅｎｔ＿ｉｄ、ｒｅｄｉｒｅｃｔ＿ｕｒｉの値が前記Ｔａｂｌｅ２クライアント管理テーブルに含まれるかどうかを確認する（ステップＳ５．１１）。

ここでもし、前記リダイレクト要求のリクエストパラメーターのｃｌｉｅｎｔ＿ｉｄ、ｒｅｄｉｒｅｃｔ＿ｕｒｉの値が前記Ｔａｂｌｅ２クライアント管理テーブルに含まれなければ、認可サーバーモジュール５１０は認可確認失敗を返却して処理を終了する（ステップＳ５．１６）。もし前記リダイレクト要求のリクエストパラメーターのｃｌｉｅｎｔ＿ｉｄ、ｒｅｄｉｒｅｃｔ＿ｕｒｉの値が前記Ｔａｂｌｅ２クライアント管理テーブルに含まれていれば、認可サーバーモジュール５１０は次に前記ステップＳ５．１０で取得したＣｏｏｋｉｅのドメインパラメーターを参照し、前記リクエストパラメーターのｒｅｄｉｒｅｃｔ＿ｕｒｉのドメインと一致するかどうかを比較する（Ｓ５．１２）。

本実施例の場合、Ｃｏｏｋｉｅのドメインパラメーターがｄｏｍｉａｎ＝ｅｘａｍｐｌｅ．ｃｏｍよりｅｘａｍｐｌｅ．ｃｏｍがドメインとなる。また、前記リクエストパラメーターのｒｅｄｉｒｅｃｔ＿ｕｒｉはＵＲＬデコードを行うとｒｅｄｉｒｅｃｔ＿ｕｒｉ＝ｈｔｔｐｓ：／／ｃｌｉｅｎｔ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｂよりｅｘａｍｐｌｅ．ｃｏｍがドメインとなる。よって認可確認画面をクライアントＰＣ２００に返却せず、認可確認成功を返す（ステップＳ５．１３）。

Ｃｏｏｋｉｅのドメインパラメーターのドメインと、リクエストパラメーターのｒｅｄｉｒｅｃｔ＿ｕｒｉのドメインが異なっていた場合（ステップＳ５．１２）、前記認可サーバーモジュール５１０は前記クライアントＰＣ２００に図６ｂに示す認可確認画面を返却する（ステップＳ５．１４）。ここで前記認可サーバーモジュール５１０は、前記クライアントＰＣ２００からの応答を待ち、もし認可確認に失敗したならば（ステップＳ５．１５）、認可確認失敗を返却して処理を終了する（ステップＳ５．１６）。またもし認可確認に成功したならば（ステップＳ５．１５）、認可確認成功を返却して処理を終了する（ステップＳ５．１３）。

図５ａにて、図５ｂに示される前記認可確認処理（ステップＳ５．４）が終了した後、認可確認が失敗したならば（ステップＳ５．５）、クライアントＰＣ２００にユーザー認証エラー画面（図示せず）を通知して処理を終了する（ステップＳ５．８）。もし前記認可確認処理（ステップＳ５．４）が成功したならば（ステップＳ５．５）、認可サーバーモジュール５１０は、リソースサーバー４００へのアクセスを可能にするアクセストークンを生成するアクセストークン発行処理（ステップＳ５．６）を行う。

生成したアクセストークンは、前記Ｔａｂｌｅ３トークン管理テーブルに登録する。即ち、アクセストークン文字列「ＡＴ＿０００００１」をトークンＩＤに格納する。また認可サーバーで予め定められたアクセストークンの有効期限を有効期限に格納する。また前記トークンテーブルに登録済みの認証トークンのレコードに含まれるスコープ情報をスコープに、ユーザーＩＤをユーザーＩＤに格納する。このように、認可サーバー５００は、ユーザーによる明示的な認可確認を行わず、リソースサーバー４００へのリソースアクセスを可能にするアクセストークン「ＡＴ＿０００００１」を発行する（ステップＳ５．７）。これはＷｅｂ−Ｈｏｓｔｅｄクライアント３００、リソースサーバー４００、認可サーバー５００がＷＡＮ１００を介さずに接続されているためである。本実施例においてはＬＡＮ１０１を校内とみなし、これらを同一セキュリティドメインとみなす。

ここで認可サーバーモジュール５１０がクライアントＰＣ２００に送信するアクセストークンの応答（Ｓ４．１１）は、以下のようにＯＡｕｔｈ２．０仕様に従う。すなわちａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄフォーマットを用いてリダイレクトＵＲＩのフラグメントコンポーネントに例えば以下のようなパラメーターを付与してクライアントＰＣ２００に応答を送信する。
ＨＴＴＰ／１．１ ３０２ Ｆｏｕｎｄ
Ｌｏｃａｔｉｏｎ： ｈｔｔｐ：／／ｃｌｉｅｎｔ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｂ＃ａｃｃｅｓｓ＿ｔｏｋｅｎ＝ＡＴ＿０００００１＆ｓｔａｔｅ＝ｘｙｚ
＆ｔｏｋｅｎ＿ｔｙｐｅ＝ｅｘａｍｐｌｅ＆ｅｘｐｉｒｅｓ＿ｉｎ＝３６００
上記のようにアクセストークン応答に付与されるパラメーターは、ＯＡｕｔｈ２．０仕様によるとａｃｃｅｓｓ＿ｔｏｋｅｎ、ｔｏｋｅｎ＿ｔｙｐｅ、ｅｘｐｉｒｅｓ＿ｉｎ、ｓｃｏｐｅ、ｓｔａｔｅである。本実施例のようなＩｍｐｌｉｃｉｔ ｇｒａｎｔ認可フローのアクセストークン応答（Ｓ４．１１）は、クライアントＰＣ２００のＷｅｂブラウザー２３０にアクセストークンを取得させるため、ホスト機能として実現されるＷｅｂ−Ｈｏｓｔｅｄクライアント３００に向けて一旦リダイレクトするようになる。アクセストークン応答を受信した前記クライアントＰＣ２００上のＷｅｂブラウザー２３０は、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００に前記アクセストークン応答をリダイレクトする（Ｓ４．１２）。ここで、Ｓ４．１２のリダイレクトは、ＨＴＴＰの仕様によりフラグメントコンポーネントのパラメーターを含まない。

リダイレクトを受信したＷｅｂ−Ｈｏｓｔｅｄクライアント３００のＷｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記クライアントＰＣ２００上の前記Ｗｅｂブラウザー２３０にて前記アクセストークンを取得するためのスクリプトを含む応答を返す（Ｓ４．１３）。上記スクリプトは一般に、Ｗｅｂブラウザー２３０で実行可能なＪａｖａＳｃｒｉｐｔ（登録商標）であるが、その他ブラウザー上で実行可能なスクリプトであっても良い。上記アクセストークン取得スクリプトを受信した前記Ｗｅｂブラウザー２３０上で動作するクライアントスクリプト２２０は、スクリプトを実行することでアクセストークンを取得し（Ｓ４．１４）、リソースサーバー４００にアクセスすることができる（Ｓ４．１５）。

図７は、上記アクセストークンを取得しリソースサーバーにアクセスするためのスクリプトのフローチャートである。前記Ｗｅｂ−Ｈｏｓｔｅｄクライアントからスクリプトを受信したクライアントＰＣ２００上のＷｅｂブラウザー２３０が本フローチャートを実行する。まず上記Ｗｅｂブラウザー２３０は、前記アクセストークン応答（Ｓ４．７）のリダイレクト先であるＵＲＩに紐付くｑｕｅｒｙ ｓｔｒｉｎｇをパースし、フラグメントの値を取得する（ステップＳ７．４）。例えば本実施例のＪａｖａＳｃｒｉｐｔ（登録商標）においては、ｌｏｃａｔｉｏｎ．ｈａｓｈ関数を用いてＷｅｂ−Ｈｏｓｔｅｄクライアント３００にリダイレクトされた前記アクセストークン応答のフラグメントコンポーネントの値を取得する。さらに上記取得したフラグメントコンポーネントに含まれるアクセストークンａｃｃｅｓｓ＿ｔｏｋｅｎ＝ＡＴ＿０００００１を取得する（ステップＳ７．５）。そして、本スクリプトの実行により前記Ｗｅｂブラウザー２３０は、上記取得したアクセストークンを用いてリソースサーバー４００にアクセスする（ステップＳ７．６）。

図７のフローチャートにより前記Ｗｅｂブラウザー２３０上で動作する前記スクリプトは、前記Ｓ４．１３、Ｓ４．１４において前記アクセストークン「ＡＴ＿０００００１」、スコープ「リソースＡ」を受け取る。そして、リソースサーバー４００に対して前記アクセストークン「ＡＴ＿０００００１」、スコープ「リソースＡ」をリクエストパラメーターに含めてリソースアクセス要求を行う（Ｓ４．１５）。

アクセストークン情報「ＡＴ＿０００００１」、スコープ「リソースＡ」を取得したリソースサーバー４００は、取得した情報を元に要求を受け付けたリソースに対するアクセスを許可するか拒否するかを判断する。ここでは、リソースサーバー４００に予めアクセス可能なアプリケーションＩＤが設定されているとし、その設定されているアプリケーションＩＤと、アクセストークン情報「ＡＴ＿０００００１」から取得されたアプリケーションＩＤを比較することでアクセスを許可するかを検証する。本検証は、リソースサーバー４００が認可サーバー５００に対し、アクセストークン「ＡＴ＿０００００１」、スコープ「リソースＡ」を引数にしてトークン情報を取得することで行われる（Ｓ４．１６）。認可サーバー５００では、Ｔａｂｌｅ３トークン管理テーブルを参照し、取得したアクセストークン「ＡＴ＿００００１」の有効期間が切れていないこと、要求されているスコープ「リソースＡ」がスコープ範囲内であることを検証し、問題がなければ検証の成功を返す（Ｓ４．１７）。この結果、アクセス許可と判断された場合は、リソースサーバー４００は、Ｗｅｂブラウザー２３０に対して、リソースを応答する（Ｓ４．１８）。ここで、リソースは例えば、リソースサーバー４００が印刷サービスであった場合は印刷可能な文書のリストであり、帳票サービスであった場合は、作成可能な帳票のリストである。

ここで、Ｓ４．１６から、Ｓ４．１７まで、トークンの検証を認可サーバー５００、リソースサーバー４００それぞれで行うよう説明したが、リソースに対するアクセス可能なアプリケーションを認可サーバー５００で管理し、全ての検証を認可サーバー５００で行うよう構成する事も可能である。また、本実施例ではアクセス可能なアプリケーションの判断をアプリケーションＩＤを用いて実施するよう説明したが、トークン情報から取得できるシリアル番号やクライアントＩＤを元にクライアントＰＣ２００上のＷｅｂブラウザー２３０を識別し、アクセスの可否を判断するよう構成する事もできる。また、同様に、トークン情報から特定できるスコープやユーザーＩＤを元にアクセスの可否を判断するよう構成する事もできる。リソース応答を受け付けたクライアントＰＣ２００上のＷｅｂブラウザー２３０は、受信したデータを元に前述のアプリケーション画面を構成し、リソースオーナー１０００たるユーザーに応答する（Ｓ４．１８）。

以上が実施例１の説明となる。本実施例により、Ｗｅｂブラウザーがサービスと連携するクライアントとなる場合であって、そのＷｅｂブラウザーがＪＱｕｅｒｙを利用することによりサービスとＡＰＩを介した通信を行う権限移譲システムにおいて、認可操作を省略することが可能になる。

リダイレクトＵＲＩが同一ドメインの場合の認可確認画面スキップにおいて、クライアントアプリケーションがアクセストークンを奪取する場合の形態について説明する。実施例１に示した方法と構成が異なり、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００を用いずクライアントＰＣ２００上のＷｅｂアプリケーション２４０でアクセストークンを取得する例を以下に詳述する。なお実施例１と同一の構成となる部分については実施例１の参照部分を示す。Ｗｅｂアプリケーション２４０は汎用的なＷｅｂブラウザーではなく、実施例２ではリソースサーバー４００を提供するベンダーが制作したＷｅｂアプリケーション２４０を想定している。即ち、Ｗｅｂアプリケーション２４０とリソースサーバー４００は同一ドメインであるとみなせる。よって、Ｗｅｂアプリケーション２４０を介して認証さえされれば、前記Ｗｅｂアプリケーション２４０にユーザーの権限を移譲することを許可する指示、即ち、認可操作を省略しても良いことになる。

本実施の形態に係る権限移譲システムは、図８に示すような構成のネットワーク上に実現される。１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１、１０２は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１、ＬＡＮ１０２）である。

５００はＯＡｕｔｈを実現するための認可サーバーであり、認可サービスモジュールが設置されている。４００はリソースサーバーであり、印刷サービスや帳票サービスといったリソースサービス連携アプリケーションが設置されている。なお１台のリソースサーバーに設置されるリソースサービス連携アプリケーションは１つでもよく、複数でもよい。２００はユーザーが操作するクライアントＰＣであり、クライアントＰＣ上のＷｅｂアプリケーション２４０を実行し、４００のリソースサーバーのリソースを用いて印刷サービスや帳票サービスといったサービスを利用する。本実施例の特徴として、リソースサーバー４００が、認可サーバー５００と同一のＬＡＮ１０１に接続されていることが挙げられる。リソースサーバー４００、認可サーバー５００がＷＡＮ１００を介さずに接続されている。
またクライアントＰＣ２００、リソースサーバー４００はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１、ＬＡＮ１０２を介して接続されている。なおクライアントＰＣ２００およびそれぞれのサービスはそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣ上に構成されていてもよい。
図２は本実施の形態に係るクライアントＰＣ２００の構成を示す図である。またリソースサーバー４００、認可サーバー５００のサーバーコンピューターの構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントＰＣ２００およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。図２の詳細については実施例１と同様である。

図９は本実施の形態に係る、認可サーバー５００、リソースサーバー４００、クライアントＰＣ２００の、それぞれのモジュール構成を示す図である。なお認可サーバー５００、リソースサーバー４００、クライアントＰＣ２００は、図８のものと同一である。認可サーバー５００は認可サーバーモジュール５１０を持ち、認可サーバーモジュール５１０はユーザー識別部６０１、クライアント検証部５２０、トークン発行部５３０、トークン検証部５４０を持つ。リソースサーバー４００はリソースサーバーモジュール４１０を持ち、リソースサーバーモジュール４００はトークン権限確認部４２０とリソース要求処理部４３０を持つ。クライアントＰＣ２００はＣＰＵ２０１がＲＯＭ２０２、或いは外部メモリ２０３に記憶されたＯＳを実行する事で各アプリケーションを制御する。ここで２２０はそのＯＳであり、一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用される事もある。さらに、クライアントＰＣ２００はＷＷＷを利用するためのユーザーエージェントであるＷｅｂアプリケーション２４０を備える。Ｗｅｂアプリケーション２４０は、認可サーバー５００からのアクセストークン応答のリダイレクトＵＲＩリクエストを受信し、後述するアクセストークン取得＆リソースリクエストを実行する機能を持つ。

実施例１で示したユーザー管理テーブルＴａｂｌｅ１、クライアント管理テーブルＴａｂｌｅ２、トークン管理テーブルＴａｂｌｅ３は、実施例２においても同様に認可サーバー５００が外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー５００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。

ここで、リソースサービス連携アプリケーションを用いてリソースサービスを利用する際に行われる認可フローのシーケンスについて、図１０を用いて説明する。ＯＡｕｔｈ２．０の仕様では、多様なクライアントに応じた複数のプロトコルシーケンスをｇｒａｎｔｔｙｐｅと呼ぶ。図１０の認可フローは、ＯＡｕｔｈ２．０仕様のｉｍｐｌｉｃｉｔ ｇｒａｎｔに本実施例独自の拡張を加えたｇｒａｎｔ ｔｙｐｅである。

まず、保護されたリソースへのアクセスが必要になるユーザーからの認可連携サービス開始要求が発生する（Ｓ１０．１）。本サービス要求は、リソースオーナー１０００であるユーザーがリソースサーバー４００に対し、リソースオーナー１０００が操作するユーザーエージェントたるクライアントＰＣ２００上のＷｅｂアプリケーション２４０を介してＨＴＴＰプロトコルを用いて行う。具体的には、リソースオーナー１０００たるユーザーはクライアントＰＣ２００上のＷｅｂアプリケーション２４０を操作してリソースサーバー４００のアプリケーション画面（不図示）にアクセスする（Ｓ１０．１）。

このアプリケーション画面は、例えば、リソースサーバー４００のリソース連携アプリケーションが印刷アプリケーションであった場合は印刷する文書を選択する画面であり、帳票アプリケーションであった場合は、作成する帳票を選択する画面である。ここでアプリケーション画面にアクセスするとは、例えば、クライアントＰＣ２００上のＷｅｂアプリケーション２４０上に前記アプリケーション画面が選択可能に表示されており、当該アプリケーションを選択する事を指す。当該アプリケーションを選択することにより、リソースオーナー１０００はリソースサーバー４００に対して認可連携サービス開始要求を送信する（Ｓ１０．１）。なお本実施例においてはリソース連携アプリケーションをリソースサーバー４００上としている。しかし一般に、リソース連携アプリケーションはリソースサーバー４００とは別の、クライアントアプリケーションサーバーなどに存在しても良い。本実施例ではリソースサービス連携アプリケーションとして印刷Ｗｅｂアプリケーション、帳票Ｗｅｂアプリケーションといったリソースサービスと連携するクライアントアプリケーションが設置されている。なお１台のリソースサーバーに設置されるリソースサービス連携アプリケーションは１つでもよく、複数でもよい。

次に、リソースサーバー４００は、前記認可連携サービス開始要求（Ｓ１０．１）により認可連携の開始を受け付けたら、リソースサーバー４００の持つ認可サーバー５００の認証エンドポイントのＵＲＬに対して、Ｃｏｏｋｉｅとしてリソースサーバー４００のＦＱＤＮのドメイン名であるドメインをｄｏｍａｉｎ＝ｅｘａｍｐｌｅ．ｃｏｍのようにセットする（Ｓ１０．２）。そしてＯＡｕｔｈの認可リクエストをするよう、クライアントＰＣ２００上のＷｅｂアプリケーション２４０にＨＴＴＰ／１．１ステータスコード３０２のリダイレクト要求する（Ｓ１０．３）。本リダイレクト要求のＨＴＴＰ Ｌｏｃａｔｉｏｎヘッダーにはリソースサーバー４００のＩＤ、認証フローのタイプ、認可サーバー５００の認証エンドポイントのＵＲＬが含まれ、以下のようなリダイレクト要求となる。
ｈｔｔｐｓ：／／ａｕｔｈ．ａ０１．ｅｘａｍｐｌｅ．ｃｏｍ／ａｕｔｈｏｒｉｚｅ？ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ＝ｔｏｋｅｎ＆ｃｌｉｅｎｔ＿ｉｄ＝ｓ６ＢｈｄＲｋｑｔ３＆ｓｔａｔｅ＝ｘｙｚ＆ｒｅｄｉｒｅｃｔ＿ｕｒｉ＝ｈｔｔｐｓ％３Ａ％２Ｆ％２Ｆｃｌｉｅｎｔ％２Ｅｅｘａｍｐｌｅ％２Ｅｃｏｍ％２Ｆｃｂ
＆ｓｃｏｐｅ＝ｓｃｏｐｅＡ
ＨＴＴＰメソッド： ＧＥＴ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ
リクエストパラメーターには、ｒｅｓｐｏｎｓｅ＿ｔｙｐｅとして“ｔｏｋｅｎ”固定文字列、ｃｌｉｅｎｔ＿ｉｄとして予めクライアントアプリケーションとして認可サーバー５００に登録したリソースサーバー４００上のクライアントアプリケーションのアプリケーションＩＤ、ｒｅｄｉｒｅｃｔ＿ｕｒｉとして予めクライアントアプリケーションとして認可サーバー５００に登録したＵＲＬを指定する。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成する事もできる。本実施例では、スコープとしてスコープＡがリクエストされたとして説明する。

次に、リダイレクト要求を受信したクライアントＰＣ２００上のＷｅｂアプリケーション２４０は、上記リダイレクト要求のｒｅｓｐｏｎｓｅ＿ｔｙｐｅ、ｃｌｉｅｎｔ＿ｉｄ、ｓｔａｔｅ、ｒｅｄｉｒｅｃｔ＿ｕｒｉ、ｓｃｏｐｅの各パラメーターを保存する。そして上記リダイレクト要求に従い認可サーバー５００に対してユーザー認証、認可の要求を行う（Ｓ１０．５）。認可リクエストを受け付けた認可サーバー５００は、ユーザーを認証するためにログイン画面（図示せず）をクライアントＰＣ２００上のＷｅｂアプリケーション２４０に応答する（Ｓ１０．６）。リソースオーナー１０００であるユーザーはクライアントＰＣ２００上のＷｅｂアプリケーション２４０に示されたログイン画面に対して、ユーザーＩＤ、パスワードを入力しログインを実行する（Ｓ１０．７）。認可サーバー５００は受け付けたユーザーＩＤ、パスワードの組が前記Ｔａｂｌｅ１ユーザー管理テーブルに登録されている情報と合っているかを検証する。

ここで以下のユーザー認証画面表示（Ｓ１０．６）、ユーザー認証（Ｓ１０．７）、リダイレクトＵＲＩとＣｏｏｋｉｅのドメインパラメーター比較（Ｓ１０．８）については実施例１で示した図５ａ、５ｂのフローチャートと同様のフローとなるので説明を省略する。また本実施例の特徴である、認可確認画面表示（Ｓ１０．９）、認可確認（Ｓ１０．１０）の省略について、およびアクセストークン応答（Ｓ１０．１１）についても、実施例１で示した図５ａ、５ｂのフローチャートと同様のフローとなる。

ここで認可サーバーモジュール５１０がクライアントＰＣ２００に送信するアクセストークンの応答（Ｓ１０．１１）は、以下のようにＯＡｕｔｈ２．０仕様に従う。すなわちａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄフォーマットを用いてリダイレクトＵＲＩのフラグメントコンポーネントに例えば以下のようなパラメーターを付与してクライアントＰＣ２００に応答を送信する。
ＨＴＴＰ／１．１ ３０２ Ｆｏｕｎｄ
Ｌｏｃａｔｉｏｎ： ｈｔｔｐ：／／ｃｌｉｅｎｔ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｂ＃ａｃｃｅｓｓ＿ｔｏｋｅｎ＝ＡＴ＿０００００１＆ｓｔａｔｅ＝ｘｙｚ
＆ｔｏｋｅｎ＿ｔｙｐｅ＝ｅｘａｍｐｌｅ＆ｅｘｐｉｒｅｓ＿ｉｎ＝３６００
上記のようにアクセストークン応答に付与されるパラメーターは、ＯＡｕｔｈ２．０仕様によるとａｃｃｅｓｓ＿ｔｏｋｅｎ、ｔｏｋｅｎ＿ｔｙｐｅ、ｅｘｐｉｒｅｓ＿ｉｎ、ｓｃｏｐｅ、ｓｔａｔｅである。上記に示したように、本実施例のようなＩｍｐｌｉｃｉｔ ｇｒａｎｔ認可フローのアクセストークン応答（Ｓ１０．１１）は、一般にクライアントＰＣ２００のＷｅｂブラウザー２３０にアクセストークンを取得させるため、予め認可サーバー５００に登録したリダイレクトＵＲＩに向けて一旦リダイレクトすることになる。しかし本実施例においては、このリダイレクト応答をＷｅｂアプリケーション２４０がリダイレクト応答をキャンセルして書き換えることで、後述するようにリソースサーバー４００にアクセスするためのアクセストークン、スコープ等を直接取得する（Ｓ１０．１２）。

図１１は、上記Ｗｅｂアプリケーション２４０の上記挙動を示すフローチャートである。Ｗｅｂアプリケーション２４０は、認可サーバー５００からのアクセストークン応答を待ち受ける（ステップＳ１１．１）。前記Ｓ１０．１１において認可サーバー５００からアクセストークン応答（Ｓ１０．１１）を受信したら、Ｗｅｂアプリケーション２４０は、前記アクセストークン応答のＨＴＴＰレスポンス３０２ＮｏｔＦｏｕｎｄをクリアして２００ＯＫをセットする（ステップＳ１１．２）。

ここで、前記Ｗｅｂアプリケーション２４０が、前記Ｓ１０．１のアクセス試行時に保持したリクエストパラメーターに含むｒｅｄｉｒｅｃｔ＿ｕｒｉと、前記アクセストークン応答のＬｏｃａｔｉｏｎヘッダーに含まれるリダイレクト先が一致しているかどうか確認しても良い。さらに前記Ｗｅｂアプリケーション２４０は、前記アクセストークン応答のＵＲＬフラグメントコンポーネントからａｃｃｅｓｓ＿ｔｏｋｅｎ、ｓｔａｔｅ、ｔｏｋｅｎ＿ｔｙｐｅ、ｅｘｐｉｒｅｓ＿ｉｎパラメーターを取得する（ステップＳ１１．３）。そして前記Ｗｅｂアプリケーション２４０は上記取得したアクセストークンＡＴ＿０００００１を使用して、リソースサーバー４００にリソースリクエストを送信する（ステップＳ１１．４）。

上記図１１のフローチャートにより前記Ｗｅｂアプリケーション２４０は、前記Ｓ１０．１１、Ｓ１０．１２において前記アクセストークン「ＡＴ＿０００００１」を受け取る。そして、リソースサーバー４００に対して前記アクセストークン「ＡＴ＿０００００１」、Ｓ１０．５で保存したスコープ「リソースＡ」をリクエストパラメーターに含めてリソースアクセス要求を行う（Ｓ１０．１３）。

アクセストークン情報「ＡＴ＿０００００１」、スコープ「リソースＡ」を取得したリソースサーバー４００は、取得した情報を元に要求を受け付けたリソースに対するアクセスを許可するか拒否するかを判断する。ここでは、リソースサーバー４００に予めアクセス可能なアプリケーションＩＤが設定されているとている。その設定されているアプリケーションＩＤと、アクセストークン情報「ＡＴ＿０００００１」から取得されたアプリケーションＩＤを比較することでアクセスを許可するかを検証する。本検証は、リソースサーバー４００が認可サーバー５００に対し、アクセストークン「ＡＴ＿０００００１」、スコープ「リソースＡ」を引数にしてトークン情報を取得することで行われる（Ｓ１０．１４）。認可サーバー５００では、Ｔａｂｌｅ３トークン管理テーブルを参照し、取得したアクセストークン「ＡＴ＿００００１」の有効期間が切れていないこと、要求されているスコープ「リソースＡ」がスコープ範囲内であることを検証し、問題がなければ検証の成功を返す（Ｓ１０．１５）。この結果、アクセス許可と判断された場合は、リソースサーバー４００は、Ｗｅｂアプリケーション２４０に対して、リソースを応答する（Ｓ１０．１６）。ここで、リソースは例えば、リソースサーバー４００が印刷サービスであった場合は印刷可能な文書のリストであり、帳票サービスであった場合は、作成可能な帳票のリストである。

ここで、Ｓ１０．１４から、Ｓ１０．１５まで、トークンの検証を認可サーバー５００、リソースサーバー４００それぞれで行うよう説明したが、リソースに対するアクセス可能なアプリケーションを認可サーバー５００で管理し、全ての検証を認可サーバー５００で行うよう構成する事も可能である。また、本実施例ではアクセス可能なアプリケーションの判断をアプリケーションＩＤを用いて実施するよう説明したが、トークン情報から取得できるシリアル番号やクライアントＩＤを元にクライアントＰＣ２００上のＷｅｂアプリケーション２４０を識別し、アクセスの可否を判断するよう構成する事もできる。また、同様に、トークン情報から取得できるスコープやユーザーＩＤを元にアクセスの可否を判断するよう構成する事もできる。リソース応答を受け付けたクライアントＰＣ２００上のＷｅｂアプリケーション２４０は、受信したデータを元に前述のアプリケーション画面を構成し、リソースオーナー１０００たるユーザーに応答する（Ｓ１０．１６）。

以上が実施例２の説明となる。実施例１の処理との差異は、クライアントであるＷｅｂアプリケーション２４０が、権限情報をクライアントに取得させるためのエンドポイントであるＷｅｂ−Ｈｏｓｔｅｄクライアント３００にアクセスすることなく、権限情報を取得する点にある。汎用的な動作に制限されたＷｅｂブラウザーとは異なり、特別な動作を実行出来るクライアントアプリケーションであれば実施例２を実行することが可能になる。わざわざ、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００にアクセスする必要がないことが実施例２のメリットである。

リダイレクトＵＲＩが同一ドメインの場合の認可確認画面スキップにおいて、アクセストークンを暗号化する場合の形態について説明する。本実施例は、実施例１におけるアクセストークンを暗号化する例である。ＯＡｕｔｈ２．０のＩｍｐｌｉｃｉｔ ｇｒａｎｔにおいては、認可サーバー５００で発行されたアクセストークンがクライアントＰＣ２００に直接わたってしまうため、トークン詐取等の問題を起こす可能性がある。実施例１の特徴はアクセストークンの応答先であるＷｅｂ−Ｈｏｓｔｅｄクライアント３００が、認可サーバー５００と同じセキュリティドメインであることを理由にユーザー１０００に対して明示的な認可確認を省略することにあった。本実施例３においては、実施例１にアクセストークンの暗号化を加えて、より安全なリソースサーバー４００へのアクセスを実現する。なお本実施例は実施例１にトークン暗号化を加えた実施例であるので、実施例１と同様の構成、フローの説明は割愛する。

本実施の形態に係る権限移譲システムは、実施例１と同様に、図１に示すような構成のネットワーク上に実現される。本実施の形態に係るクライアントＰＣ２００の構成は、実施例１と同様に、図２をもって示される。またＷｅｂ−Ｈｏｓｔｅｄクライアント３００、リソースサーバー４００、認可サーバー５００のサーバーコンピューターの構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントＰＣ２００およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。

図１９は、本実施の形態に係る、認可サーバー５００、リソースサーバー４００、クライアントＰＣ２００、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００の、それぞれのモジュール構成図である。なお認可サーバー５００、リソースサーバー４００、クライアントＰＣ２００、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００は、実施例１の図３と同様であるので説明は割愛する。認可サーバー５００も図３と同様に認可サーバーモジュール５１０を持ち、認可サーバーモジュール５１０はユーザー識別部６１０、クライアント検証部５２０、トークン発行部５３０、トークン検証部５４０を持つ。加えて、本実施例の特徴として、暗号処理部５５０を持つ。

本実施例の認可サーバー５００は、外部メモリに記憶するデータテーブルＴａｂｌｅ１ユーザー管理テーブル、Ｔａｂｌｅ２クライアント管理テーブル、Ｔａｂｌｅ３トークン管理テーブルを持つ。これらデータテーブルは、認可サーバー５００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。これらテーブルは実施例１のＴａｂｌｅ１、Ｔａｂｌｅ２、Ｔａｂｌｅ３と同一なので説明は割愛する。

ここで、クライアントＰＣ２００上のブラウザープリケーションを用いてリソースサービスを利用するための、本実施例の形態に係る認可フローを表すシーケンスについて、図１２を用いて説明する。ＯＡｕｔｈ２．０の仕様では、多様なクライアントに応じた複数のプロトコルシーケンスをｇｒａｎｔ ｔｙｐｅと呼ぶ。図１２の認可フローは、ＯＡｕｔｈ２．０仕様のｉｍｐｌｉｃｉｔ ｇｒａｎｔに本実施例独自の拡張を加えたｇｒａｎｔ ｔｙｐｅである。

まず、保護されたリソースへのアクセスが必要になるユーザーからの認可連携サービス開始要求が発生する（Ｓ１２．１）。本サービス要求は、リソースオーナー１０００であるユーザーがリソースサーバー４００に対し、リソースオーナー１０００が操作するユーザーエージェントたるクライアントＰＣ２００上のブラウザープリケーションを介してＨＴＴＰプロトコルを用いて行う。具体的には、リソースオーナー１０００たるユーザーはクライアントＰＣ２００を操作してリソースサーバー４００のアプリケーション画面（不図示）にアクセスする（Ｓ１２．１）。このアプリケーション画面は例えば、リソースサーバー４００のリソース連携アプリケーションが印刷アプリケーションであった場合は印刷する文書を選択する画面であり、帳票アプリケーションであった場合は、作成する帳票を選択する画面である。

ここでアプリケーション画面にアクセスするとは、例えば、クライアントＰＣ２００上のブラウザー上に前記アプリケーション画面が選択可能に表示されており、当該アプリケーションを選択する事を指す。当該アプリケーションを選択することにより、リソースオーナー１０００はリソースサーバー４００に対して認可連携サービス開始要求を送信する（Ｓ１２．１）。なお本実施例においてはリソース連携アプリケーションをリソースサーバー４００上としている。しかし一般に、リソース連携アプリケーションはリソースサーバー４００とは別の、クライアントアプリケーションサーバーなどに存在しても良い。本実施例ではリソースサービス連携アプリケーションとして印刷Ｗｅｂアプリケーション、帳票Ｗｅｂアプリケーションといったリソースサービスと連携するクライアントアプリケーションが設置されている。なお１台のリソースサーバーに設置されるリソースサービス連携アプリケーションは１つでもよく、複数でもよい。

次に、リソースサーバー４００は、前記認可連携サービス開始要求（Ｓ１２．１）により認可連携の開始を受け付けたら、リソースサーバー４００の持つ認可サーバー５００の認証エンドポイントのＵＲＬに対して、Ｃｏｏｋｉｅとしてリソースサーバー４００のＦＱＤＮのドメイン名であるドメインをｄｏｍａｉｎ＝ｅｘａｍｐｌｅ．ｃｏｍのようにセットする。さらに乱数に基づき１６進数値文字列で表されるＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）のようなユニークＩＤで表現されるｎｏｎｃｅ値をドメインと同様にＣｏｏｋｉｅとしてｎｏｎｃｅ＝ｅｄ６７０７８４−２ａｅａ−４ａ３２−８８ｄ６−６ｅ４９ｃ５ｄｄ９ｅ６ｂのようにセットする（Ｓ１２．２）。そしてＯＡｕｔｈの認可リクエストをするよう、クライアントＰＣ２００のブラウザーにＨＴＴＰ／１．１ ステータスコード３０２のリダイレクト要求する（Ｓ１２．３）。本リダイレクト要求のＨＴＴＰ Ｌｏｃａｔｉｏｎヘッダーにはリソースサーバー４００のＩＤ、認証フローのタイプ、認可サーバー５００の認証エンドポイントのＵＲＬが含まれ、以下のようなリダイレクト要求となる。
ｈｔｔｐｓ：／／ａｕｔｈ．ａ０１．ｅｘａｍｐｌｅ．ｃｏｍ／ａｕｔｈｏｒｉｚｅ？ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ＝ｔｏｋｅｎ＆ｃｌｉｅｎｔ＿ｉｄ＝ｓ６ＢｈｄＲｋｑｔ３＆ｓｔａｔｅ＝ｘｙｚ＆ｒｅｄｉｒｅｃｔ＿ｕｒｉ＝ｈｔｔｐｓ％３Ａ％２Ｆ％２Ｆｃｌｉｅｎｔ％２Ｅｅｘａｍｐｌｅ％２Ｅｃｏｍ％２Ｆｃｂ
＆ｓｃｏｐｅ＝ｓｃｏｐｅＡ
ＨＴＴＰメソッド： ＧＥＴ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ
リクエストパラメーターには、ｒｅｓｐｏｎｓｅ＿ｔｙｐｅとして“ｔｏｋｅｎ”固定文字列、ｃｌｉｅｎｔ＿ｉｄとして予めクライアントアプリケーションとして認可サーバー５００に登録したリソースサーバー４００上のクライアントアプリケーションのアプリケーションＩＤ、ｒｅｄｉｒｅｃｔ＿ｕｒｉとして予めクライアントアプリケーションとして認可サーバー５００に登録したＷｅｂ−Ｈｏｓｔｅｄクライアント３００のＵＲＬを指定する。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成する事もできる。本実施例では、スコープとしてスコープＡがリクエストされたとして説明する。

次に、リダイレクト要求を受信したクライアントＰＣ２００は、上記リダイレクト要求に従い認可サーバー５００に対してユーザー認証、認可の要求を行う（Ｓ１２．５）。認可リクエストを受け付けた認可サーバー５００は、ユーザーを認証するために図６ａに示すログイン画面２０００をクライアントＰＣ２００上のブラウザーに応答する（Ｓ１２．６）。リソースオーナー１０００であるユーザーはクライアントＰＣ２００上のブラウザーに示されたログイン画面２０００に対して、ユーザーＩＤ、パスワードを入力しログインを実行する（Ｓ１２．７）。認可サーバー５００は受け付けたユーザーＩＤ、パスワードの組が前記Ｔａｂｌｅ１ユーザー管理テーブルに登録されている情報と合っているかを検証する。ここで以下に示す図１３のフローチャートを用いて、ユーザー認証画面表示（Ｓ１２．６）、ユーザー認証（Ｓ１２．７）、暗号鍵生成（Ｓ１２．８）、ｎｏｎｃｅと暗号鍵のペアを保存（Ｓ１２．９）、リダイレクトＵＲＩとＣｏｏｋｉｅのドメインパラメーター比較（Ｓ１２．１０）について説明する。また本実施例の特徴である、認可確認画面表示（Ｓ１２．１１）、認可確認（Ｓ１２．１２）の省略について、およびアクセストークン応答（Ｓ１２．１３）について説明する。

図１３ａ、１３ｂは、前記認可サーバー５００がユーザー認証、認可の要求を受け付けた際の、認可サーバー５００上の認可サーバーモジュール５１０の処理フローチャートである。本フローチャートは、認可サーバーモジュール５１０が前記クライアントＰＣ２００からの前記リダイレクト要求を受信することで始まる（ステップＳ１３．１）。認可サーバーモジュール５１０は、ユーザーを認証するために図６ａに示すログイン画面２０００をクライアントＰＣ２００上のブラウザーに応答する。リソースオーナー１０００であるユーザーはクライアントＰＣ２００上のブラウザーに示されたログイン画面２０００に対して、ユーザーＩＤ、パスワードを入力しログインを実行する（Ｓ１２．７）。認可サーバー５００は、前記クライアントＰＣ２００から受信した前記リダイレクト要求に含まれるＣｏｏｋｉｅからｎｏｎｃｅ値とドメイン名を取得する（ステップＳ１３．２）。
さらに前記認可サーバー５００は、受け付けたユーザーＩＤ、パスワードの組が前記Ｔａｂｌｅ１ユーザー管理テーブルに登録されている情報と合っているかを検証する（ステップＳ１３．３）。前記検証の結果ユーザーＩＤ、パスワードの組がＴａｂｌｅ１ユーザー管理テーブルに登録されていなければ（ステップＳ１３．４）、クライアントＰＣ２００にユーザー認証エラー画面（図示せず）を通知して処理を終了する（ステップＳ１３．１２）。もし前記検証の結果ユーザーＩＤ、パスワードの組がＴａｂｌｅ１ユーザー管理テーブルに登録されていれば（ステップＳ１３．４）、次に暗号鍵生成処理（ステップＳ１３．５、ステップＳ１３．６、ステップＳ１３．７）を行う。

認可サーバーモジュール５１０は、まず暗号鍵の生成に用いるＳａｌｔを取得する（ステップＳ１３．５）。本実施例のＳａｌｔは、予め前記認可サーバーモジュール５１０内に保存された８バイトの文字列”ａｂｃｄｅｆｇｈ”とする。より撹乱された鍵を生成されるようにするために、前記認可サーバーモジュール５１０は、前記Ｓａｌｔを使用する。すなわち、暗号鍵の元として使用する、先にステップＳ１３．２にて取得したｎｏｎｃｅ値のダイジェスト値を求める前に、ｎｏｎｃｅ値に前もって８バイトのデータ（Ｓａｌｔ）を追加してからダイジェスト値を求める。Ｓａｌｔの長さについては必ずしも固定でなく、８バイト程度であればよい。

次に認可サーバーモジュール５１０は、上記ステップＳ１３．４にて取得したＳａｌｔと前記ステップＳ１３．２で取得したｎｏｎｃｅ値を結合してＳＨＡ−２５６ハッシュアルゴリズムによりハッシュ値を計算し、暗号鍵とする（ステップＳ１３．６）。本実施例の場合、ｓａｌｔをｎｏｎｃｅの前に結合した文字列「ａｂｃｄｅｆｇｈｅｄ６７０７８４２ａｅａ４ａ３２−８８ｄ６−６ｅ４９ｃ５ｄｄ９ｅ６ｂ」をＳＨＡ−２５６アルゴリズムでハッシュ化した「２９６７４ｆｅａｄ５ｅ３８ａｄ１ｂ９ｆ３７ｂ２ｂｅ２８３５８ｂ１５ｃ８ｆｄ３５３１０ｄ２９ｅｂ７ｅ５５９４ｅ９ａ５ｆ３０ｄ７ｅ０」を暗号鍵とする。そして、以下に示すように前記ｎｏｎｃｅ値と上記生成した暗号鍵を、Ｔａｂｌｅ４ ｎｏｎｃｅ−暗号鍵管理テーブルに保存する（ステップＳ１３．７）。また本実施例においては暗号化アルゴリズムにＡＥＳ（２５６ｂｉｔ）ＣＢＣモードを使用するため、ＣＢＣモードに必要な初期ベクター（ｉｖ）が必要となる。ｉｖは前記暗号鍵と同時に、認可サーバーモジュール５１０がランダムに生成する。本実施例ではｉｖを「３７２９Ａ７Ｆ０３６２３５ＦＢＡ２６Ｃ１３８Ｄ４ＢＢ５５６１７２」とする（ステップ＄１３．７）。

以下に示すＴａｂｌｅ４は認可サーバー５００が外部メモリに記憶するデータテーブルである。このデータテーブルは、認可サーバー５００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。本実施例においては、同一のＬＡＮ１０１に接続されている認可サーバー５００とＷｅｂ−Ｈｏｓｔｅｄクライアント３００において、認可サーバー５００がＴａｂｌｅ４を作成、参照、更新、削除可能、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００がＴａｂｌｅ４を参照可能なように構成する。

Ｔａｂｌｅ４はｎｏｎｃｅ−暗号鍵管理テーブルである。本テーブルは、ｎｏｎｃｅ値、暗号鍵、ｉｖから成る。図１３ｂは、本実施例における認可サーバー５００上の認可サーバーモジュール５１０の認可確認処理のフローチャートである。認可サーバーモジュール５１０は、本認可確認処理においてステップＳ１３．１にて受信した前記クライアントＰＣ２００からの前記リダイレクト要求のリクエストパラメーターを確認する（ステップＳ１３．１２）。また前記リクエストに含まれるＣｏｏｋｉｅのドメインパラメーター、例えばｄｏｍａｉｎ＝ｅｘａｍｐｌｅ．ｃｏｍを取得する（ステップＳ１３．１３）。ここで認可サーバーモジュール５１０は、前記Ｔａｂｌｅ２クライアント管理テーブルを参照し、前記リダイレクト要求のリクエストパラメーターのｃｌｉｅｎｔ＿ｉｄ、ｒｅｄｉｒｅｃｔ＿ｕｒｉの値が前記Ｔａｂｌｅ２クライアント管理テーブルに含まれるかどうかを確認する（ステップＳ１３．１４）。

ここでもし、前記リダイレクト要求のリクエストパラメーターのｃｌｉｅｎｔ＿ｉｄ、ｒｅｄｉｒｅｃｔ＿ｕｒｉの値が前記Ｔａｂｌｅ２クライアント管理テーブルに含まれなければ、認可サーバーモジュール５１０は認可確認失敗を返却して処理を終了する（ステップＳ１３．１９）。もし前記リダイレクト要求のリクエストパラメーターのｃｌｉｅｎｔ＿ｉｄ、ｒｅｄｉｒｅｃｔ＿ｕｒｉの値が前記Ｔａｂｌｅ２クライアント管理テーブルに含まれていれば、認可サーバーモジュール５１０は次に前記ステップＳ１３．１３で取得したＣｏｏｋｉｅのドメインパラメーターを参照し、前記リクエストパラメーターのｒｅｄｉｒｅｃｔ＿ｕｒｉのドメインと一致するかどうかを比較する（Ｓ１３．１５）。本実施例の場合、Ｃｏｏｋｉｅのドメインパラメーターがｄｏｍｉａｎ＝ｅｘａｍｐｌｅ．ｃｏｍよりｅｘａｍｐｌｅ．ｃｏｍがドメインとなる。また、前記リクエストパラメーターのｒｅｄｉｒｅｃｔ＿ｕｒｉはＵＲＬデコードを行うとｒｅｄｉｒｅｃｔ＿ｕｒｉ＝ｈｔｔｐｓ：／／ｃｌｉｅｎｔ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｂよりｅｘａｍｐｌｅ．ｃｏｍがドメインとなる。よって認可確認画面をクライアントＰＣ２００に返却せず、認可確認成功を返す（ステップＳ１３．１６）。

ここでもし前記Ｃｏｏｋｉｅのドメインパラメーターのドメインと、前記リクエストパラメーターのｒｅｄｉｒｅｃｔ＿ｕｒｉのドメインが異なっていた場合（ステップＳ１３．１５）、前記認可サーバーモジュール５１０は前記クライアントＰＣ２００に図６ｂに示す認可確認画面を返却する（ステップＳ１３．１７）。ここで前記認可サーバーモジュール５１０は、前記クライアントＰＣ２００からの応答を待ち、もし認可確認に失敗したならば（ステップＳ１３．１８）、認可確認失敗を返却して処理を終了する（ステップＳ１３．１９）。またもし認可確認に成功したならば（ステップＳ１３．１８）、認可確認成功を返却して処理を終了する（ステップＳ１３．１６）。

図１３ａにて、図１３ｂに示される前記認可確認処理（ステップＳ１３．８）が終了した後、もし認可確認が失敗したならば（ステップＳ１３．９）、クライアントＰＣ２００にユーザー認証エラー画面（図示せず）を通知して処理を終了する（ステップＳ１３．１２）。もし前記認可確認処理（ステップＳ１３．８）が成功したならば（ステップＳ１３．１２）、認可サーバーモジュール５１０は、リソースサーバー４００へのアクセスを可能にするアクセストークンを生成するアクセストークン発行処理（ステップＳ１３．１０）を行う。

生成したアクセストークンは、前記ステップＳ１３．６にて生成した暗号鍵による暗号化を行い、暗号化トークン文字列を生成して前記Ｔａｂｌｅ３トークン管理テーブルに登録する。すなわち、アクセストークン文字列「ＡＴ＿０００００１」を暗号鍵「２９６７４ｆｅａｄ５ｅ３８ａｄ１ｂ９ｆ３７ｂ２ｂｅ２８３５８ｂ１５ｃ８ｆｄ３５３１０ｄ２９ｅｂ７ｅ５５９４ｅ９ａ５ｆ３０ｄ７ｅ０」とｉｖ「３７２９Ａ７Ｆ０３６２３５ＦＢＡ２６Ｃ１３８Ｄ４ＢＢ５５６１７２」にて暗号化し、さらにＢＡＳＥ６４エンコード方式にて「ｍＰｆａＣＸａ３ｖＯｘＪＷ５Ｒ９ｃｕＢｑｍＱ＝＝」のように文字列化する。そして上記生成した暗号化トークン文字列「ｍＰｆａＣＸａ３ｖＯｘＪＷ５Ｒ９ｃｕＢｑｍＱ＝＝」をトークンＩＤとしてＴａｂｌｅ３のトークンＩＤに格納する。

また認可サーバーで予め定められたアクセストークンの有効期限を有効期限に格納する。また前記トークンテーブルに登録済みの認証トークンのレコードに含まれるスコープ情報をスコープに、ユーザーＩＤをユーザーＩＤに格納する。このように、認可サーバー５００は、ユーザーによる明示的な認可確認を行わず、リソースサーバー４００へのリソースアクセスを可能にする、暗号化したアクセストークン「ｍＰｆａＣＸａ３ｖＯｘＪＷ５Ｒ９ｃｕＢｑｍＱ＝＝」を発行する（ステップＳ１３．１２）。これはＷｅｂ−Ｈｏｓｔｅｄクライアント３００、リソースサーバー４００、認可サーバー５００がＷＡＮ１００を介さずに接続されているためである。本実施例においてはＬＡＮ１０１を校内とみなし、これらを同一セキュリティドメインとみなす。
ここで認可サーバーモジュール５１０がクライアントＰＣ２００に送信するアクセストークンの応答（Ｓ１２．１３）は、以下のようにＯＡｕｔｈ２．０仕様に従う。すなわちａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄフォーマットを用いてリダイレクトＵＲＩのフラグメントコンポーネントに例えば以下のようなパラメーターを付与してクライアントＰＣ２００に応答を送信する。
ＨＴＴＰ／１．１ ３０２ Ｆｏｕｎｄ
Ｌｏｃａｔｉｏｎ： ｈｔｔｐ：／／ｃｌｉｅｎｔ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｂ＃ａｃｃｅｓｓ＿ｔｏｋｅｎ＝ｍＰｆａＣＸａ３ｖＯｘＪＷ５Ｒ９ｃｕＢｑｍＱ＆ｓｔａｔｅ＝ｘｙｚ
＆ｔｏｋｅｎ＿ｔｙｐｅ＝ｅｘａｍｐｌｅ＆ｅｘｐｉｒｅｓ＿ｉｎ＝３６００
上記のようにアクセストークン応答に付与されるパラメーターは、ＯＡｕｔｈ２．０仕様によるとａｃｃｅｓｓ＿ｔｏｋｅｎ、ｔｏｋｅｎ＿ｔｙｐｅ、ｅｘｐｉｒｅｓ＿ｉｎ、ｓｃｏｐｅ、ｓｔａｔｅである。また前記アクセストークン応答（Ｓ１２．１３）は、Ｃｏｏｋｉｅにｎｏｎｃｅ値を設定する。このｎｏｎｃｅ値は、前記Ｔａｂｌｅ４に登録したｎｏｎｃｅ値を設定する。

上記に示したように、本実施例のようなＩｍｐｌｉｃｉｔ ｇｒａｎｔ認可フローのアクセストークン応答（Ｓ１２．１３）は、クライアントＰＣ２００のＷｅｂブラウザー２３０にアクセストークンを取得させるため、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００に向けて一旦リダイレクトするようになる。

前記アクセストークン応答を受信した前記クライアントＰＣ２００上のＷｅｂブラウザー２３０は、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００に前記アクセストークン応答をリダイレクトする（Ｓ１２．１４）。ここで、Ｓ１２．１４のリダイレクトは、ＨＴＴＰの仕様によりフラグメントコンポーネントのパラメーターを含まない。

前記リダイレクトを受信したＷｅｂ−Ｈｏｓｔｅｄクライアント３００のＷｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記リダイレクトのＨＴＴＰ通信に含まれるＣｏｏｋｉｅからｎｏｎｃｅ値を取得、確認する（Ｓ１２．１５）。そしてｎｏｎｃｅ値が存在すれば、前記クライアントＰＣ２００上の前記Ｗｅｂブラウザー２３０にて前記暗号化したアクセストークンを取得するためのスクリプトを含む応答を返す（Ｓ１２．１６）。上記スクリプトは一般に、Ｗｅｂブラウザー２３０で実行可能なＪａｖａＳｃｒｉｐｔ（登録商標）であるが、その他ブラウザー上で実行可能なスクリプトであっても良い。また前記Ｗｅｂサーバーが取得する前記暗号化したアクセストークンを復号化するために、前記Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００は、暗号鍵を含むＣｏｏｋｉｅを返す。
図１４に示すのは、上記Ｓ１２．１４からＳ１２．１６のＷｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０の処理を示すフローチャートである。前記Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記Ｗｅｂブラウザー２３０から前記リダイレクト応答を受信する（ステップＳ１４．１）。さらに前記Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記リダイレクトのＨＴＴＰ通信に含まれるＣｏｏｋｉｅパラメーターからｎｏｎｃｅ値を取得する（ステップＳ１４．２）。このｎｏｎｃｅ値は、Ｓ１２．１３にて設定した値である。ここで前記Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記Ｔａｂｌｅ４ ｎｏｎｃｅ−暗号鍵管理テーブルを参照し、前記取得したｎｏｎｃｅの値が存在するかどうか確認する（ステップＳ１４．３）。

もし前記ｎｏｎｃｅ値がＴａｂｌｅ４に存在しなければ、エラー画面を生成して（図示せず）前記Ｗｅｂブラウザー２３０に送信して処理を終了する。もし前記ｎｏｎｃｅ値がＴａｂｌｅ４に存在すれば、合致するｎｏｎｃｅに対応する暗号鍵とｉｖを取得し（ステップＳ１４．４）、Ｃｏｏｋｉｅにｋｅｙ＝２９６７４ｆｅａｄ５ｅ３８ａｄ１ｂ９ｆ３７ｂ２ｂｅ２８３５８ｂ１５ｃ８ｆｄ３５３１０ｄ２９ｅｂ７ｅ５５９４ｅ９ａ５ｆ３０ｄ７ｅ０、ｉｖ＝３７２９Ａ７Ｆ０３６２３５ＦＢＡ２６Ｃ１３８Ｄ４ＢＢ５５６１７２のように暗号鍵とｉｖを設定する（ステップＳ１４．５）。そして後述するアクセストークン取得、復号化スクリプトを取得し（ステップＳ１４．６）Ｗｅｂブラウザー２３０に返して処理を終了する（ステップＳ１４．７）。

このように、Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０にてｎｏｎｃｅ値を確認することにより、前記のような一連の処理に無関係なブラウザーなどに、トークン復号化に関連する暗号鍵、アクセストークン取得スクリプトの応答をしないようにすることができる。これにより、例え前記のようなブラウザーなどで前記暗号化したアクセストークンが詐取されたとしても、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００へのアクセスがエラーとなり、前記詐取された暗号化したアクセストークンの復号化を防止することができ、リソースサーバー４００への不正アクセスを防止することができる。

上記アクセストークン取得、復号化スクリプトを受信した前記Ｗｅｂブラウザー２３０は、前記Ｃｏｏｋｉｅから暗号鍵を取得する。そして前記アクセストークン取得、復号化スクリプトを実行することでアクセストークンを復号化、取得する（Ｓ１２．１７）。そして上記復号化したアクセストークンをもって、前記スクリプトはリソースサーバー４００にアクセスすることができる（Ｓ１２．１６）。

図１５は、上記アクセストークンを取得しリソースサーバーにアクセスするためのスクリプトのフローチャートである。前記Ｗｅｂ−Ｈｏｓｔｅｄクライアントからスクリプトを受信したクライアントＰＣ２００上のＷｅｂブラウザー２３０が本フローチャートを実行する。まず上記Ｗｅｂブラウザー２３０は、前記アクセストークン応答（Ｓ１２．１３）のリダイレクト先であるＵＲＩに紐付くｑｕｅｒｙ ｓｔｒｉｎｇをパースし、フラグメントの値を取得する（ステップＳ１５．１）。例えば本実施例のＪａｖａＳｃｒｉｐｔ（登録商標）においては、ｌｏｃａｔｉｏｎ．ｈａｓｈ関数を用いてＷｅｂ−Ｈｏｓｔｅｄクライアント３００にリダイレクトされた前記アクセストークン応答のフラグメントコンポーネントの値を取得する。

さらに上記取得したフラグメントコンポーネントに含まれる暗号化されたアクセストークンａｃｃｅｓｓ＿ｔｏｋｅｎ＝ｍＰｆａＣＸａ３ｖＯｘＪＷ５Ｒ９ｃｕＢｑｍＱを取得する。さらにＷｅｂブラウザー２３０は、前記アクセストークン取得スクリプト応答Ｓ１２．１６のＨＴＴＰ通信に含まれるＣｏｏｋｉｅパラメーターから暗号鍵ｋｅｙ＝２９６７４ｆｅａｄ５ｅ３８ａｄ１ｂ９ｆ３７ｂ２ｂｅ２８３５８ｂ１５ｃ８ｆｄ３５３１０ｄ２９ｅｂ７ｅ５５９４ｅ９ａ５ｆ３０ｄ７ｅ０、初期化ベクトルｉｖ＝３７２９Ａ７Ｆ０３６２３５ＦＢＡ２６Ｃ１３８Ｄ４ＢＢ５５６１７２を取得する（ステップＳ１５．２）。ここで先に取得した暗号化されたアクセストークンを、上記暗号鍵、初期化ベクトルを用いて復号化し、アクセストークンを取得する（ステップＳ１５．３）。そして、本スクリプトの実行により前記Ｗｅｂブラウザー２３０は、上記取得したアクセストークンを用いてリソースサーバー４００にアクセスする（ステップＳ１５．４）。

上記図１５のフローチャートにより前記Ｗｅｂブラウザー２３０上で動作する前記スクリプトは、前記Ｓ１５．３において前記アクセストークン「ＡＴ＿０００００１」、Ｓ１５．１、Ｓ１５．２においてスコープ「リソースＡ」を受け取る。そして、リソースサーバー４００に対して前記アクセストークン「ＡＴ＿０００００１」、スコープ「リソースＡ」をリクエストパラメーターに含めてリソースアクセス要求を行う（Ｓ１２．１８）。

アクセストークン情報「ＡＴ＿０００００１」、スコープ「リソースＡ」を取得したリソースサーバー４００は、取得した情報を元に要求を受け付けたリソースに対するアクセスを許可するか拒否するかを判断する。ここでは、リソースサーバー４００に予めアクセス可能なアプリケーションＩＤが設定されているとし、その設定されているアプリケーションＩＤと、アクセストークン情報「ＡＴ＿０００００１」から取得されたアプリケーションＩＤを比較することでアクセスを許可するかを検証する。本検証は、リソースサーバー４００が認可サーバー５００に対し、アクセストークン「ＡＴ＿０００００１」、スコープ「リソースＡ」を引数にしてトークン情報を取得することで行われる（Ｓ１２．１９）。

認可サーバー５００では、Ｔａｂｌｅ３トークン管理テーブルを参照し、取得したアクセストークン「ＡＴ＿００００１」の有効期間が切れていないこと、要求されているスコープ「リソースＡ」がスコープ範囲内であることを検証し、問題がなければ検証の成功を返す（Ｓ１２．２０）。この結果、アクセス許可と判断された場合は、リソースサーバー４００は、Ｗｅｂブラウザー２３０に対して、リソースを応答する（Ｓ１２．２１）。ここで、リソースは例えば、リソースサーバー４００が印刷サービスであった場合は印刷可能な文書のリストであり、帳票サービスであった場合は、作成可能な帳票のリストである。

ここで、Ｓ１２．１９から、Ｓ１２．２０まで、トークンの検証を認可サーバー５００、リソースサーバー４００それぞれで行うよう説明したが、リソースに対するアクセス可能なアプリケーションを認可サーバー５００で管理し、全ての検証を認可サーバー５００で行うよう構成する事も可能である。また、本実施例ではアクセス可能なアプリケーションの判断をアプリケーションＩＤを用いて実施するよう説明したが、トークン情報から取得できるシリアル番号やクライアントＩＤを元にクライアントＰＣ２００上のＷｅｂブラウザー２３０を識別し、アクセスの可否を判断するよう構成する事もできる。また、同様に、トークン情報から取得できるスコープやユーザーＩＤを元にアクセスの可否を判断するよう構成する事もできる。

リソース応答を受け付けたクライアントＰＣ２００上のＷｅｂブラウザー２３０は、受信したデータを元に前述のアプリケーション画面を構成し、リソースオーナー１０００たるユーザーに応答する（Ｓ１２．２１）。なお、実施例３は実施例２の形態に対しても適用可能である。その場合、Ｓ１０．１２においてリダイレクトをキャンセルせずに暗号化された権限情報を復号化するためのスクリプトを取得することになる。

実施例３により、アクセストークンが暗号化された状態でクライアントに送信されるので、一連の認可処理が終了する前にクライアントでアクセストークンが取得され搾取された場合であっても、セキュリティ性を維持することができる。

実施例４では、リダイレクトＵＲＩが同一ドメインの場合の認可確認画面スキップにおいて、アクセストークン暗号化・認可確認画面のスキップをする／しないをスコープにより判定する処理について説明する。本実施例は、実施例３における認可確認画面の省略する・しない、アクセストークンの暗号化をする・しないについて、認可サーバー５００において判定する例である。

実施例３において、同一セキュリティドメインにおけるユーザーの利便性を鑑み、認可確認画面を省略する方法について詳述した。しかし、認可サーバー５００の規定するスコープによっては、対象スコープに対するアクセスによりユーザーにリスクが発生する場合がある。例えば、ドキュメントを第三者に公開するスコープ、高い課金が発生するスコープ、サービスが一部使えなくなるスコープなどである。このような場合、本実施例のように認可確認画面を強制的に出すようなスコープを設定可能にする。

また実施例３において、ＯＡｕｔｈ２．０ Ｉｍｐｌｉｃｉｔ ｇｒａｎｔにおけるアクセストークンの安全性を鑑み、アクセストークンを暗号化する方法について詳述した。しかし、認可サーバー５００の規定するスコープによっては、対象スコープに対するアクセスについて保護よりもパフォーマンスを優先する場合がある。例えば、ユーザーに対して無課金で利用できるスコープで、大量のクライアントＰＣ２００からのアクセスにより、認可サーバー５００の処理パフォーマンスに影響が出る場合などである。このような場合、本実施例のように暗号化しないスコープを設定可能にする。

以下、上記のように認可確認画面の省略をする・しない、アクセストークンの暗号化をする・しないについて、スコープの種類を認可サーバー５００が判定することにより制御する方法について詳述する。なお本実施例は、基本的に実施例１、３に認可確認、暗号化のスコープ種類による判定処理を加えた実施例であるので、実施例１、３と同様の構成、フローの説明は割愛する。

本実施の形態に係る権限移譲システムは、実施例１と同様に、図１に示すような構成のネットワーク上に実現される。本実施の形態に係るクライアントＰＣ２００の構成は、実施例１と同様に、図２をもって示される。またＷｅｂ−Ｈｏｓｔｅｄクライアント３００、リソースサーバー４００、認可サーバー５００のサーバーコンピューターの構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントＰＣ２００およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。

図１７は、本実施の形態に係る、認可サーバー５００、リソースサーバー４００、クライアントＰＣ２００、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００の、それぞれのモジュール構成図である。なお認可サーバー５００、リソースサーバー４００、クライアントＰＣ２００、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００は、実施例１の図３と同様であるので説明は割愛する。認可サーバー５００も図３と同様に認可サーバーモジュール５１０を持ち、認可サーバーモジュール５１０はユーザー識別部６０１、クライアント検証部５２０、トークン発行部５３０、トークン検証部５４０、暗号処理部５５０を持つ。加えて、本実施例の特徴として、トークン判定処理部５６０を持つ。

本実施例の認可サーバー５００は、外部メモリに記憶するデータテーブルＴａｂｌｅ１ユーザー管理テーブル、Ｔａｂｌｅ２クライアント管理テーブル、Ｔａｂｌｅ３トークン管理テーブル、Ｔａｂｌｅ４ ｎｏｎｃｅ−暗号鍵管理テーブルを持つ。これらデータテーブルは、認可サーバー５００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。これらテーブルは実施例１、３のＴａｂｌｅ１、Ｔａｂｌｅ２、Ｔａｂｌｅ３、Ｔａｂｌｅ４と同一なので説明は割愛する。

ここで、クライアントＰＣ２００上のブラウザープリケーションを用いてリソースサービスを利用するための、本実施例の形態に係る認可フローを表すシーケンスについては、実施例３の図１２と同様である。本実施例においては、図１２のシーケンス中で説明した図１３ａ、１３ｂの認可サーバー処理、図１４のＷｅｂ−Ｈｏｓｔｅｄクライアント処理が実施例３と異なる。以下、本実施例の認可サーバー処理を図１６のフローチャートを用いて説明する。また、本実施例のＷｅｂ−Ｈｏｓｔｅｄクライアント処理について図１８のフローチャートを用いて説明する。

図１６ａ、１６ｂは、前記認可サーバー５００がユーザー認証、認可の要求を受け付けた際の、認可サーバー５００上の認可サーバーモジュール５１０の処理フローチャートである。本フローチャートは、認可サーバーモジュール５１０が前記クライアントＰＣ２００からの前記リダイレクト要求を受信することで始まる（ステップＳ１６．１）。認可サーバーモジュール５１０は、ユーザーを認証するために図６ａに示すログイン画面２０００をクライアントＰＣ２００上のブラウザーに応答する。リソースオーナー１０００であるユーザーはクライアントＰＣ２００上のブラウザーに示されたログイン画面２０００に対して、ユーザーＩＤ、パスワードを入力しログインを実行する（Ｓ１２．７）。

認可サーバー５００は、前記クライアントＰＣ２００から受信した前記リダイレクト要求に含まれるＣｏｏｋｉｅからｎｏｎｃｅ値とドメイン名を取得する。さらにリクエストパラメーターのＳｃｏｐｅを取得する（ステップＳ１６．２）。さらに前記認可サーバー５００は、受け付けたユーザーＩＤ、パスワードの組が前記Ｔａｂｌｅ１ユーザー管理テーブルに登録されている情報と合っているかを検証する（ステップＳ１６．３）。前記検証の結果ユーザーＩＤ、パスワードの組がＴａｂｌｅ１ユーザー管理テーブルに登録されていなければ（ステップＳ１６．４）、クライアントＰＣ２００にユーザー認証エラー画面（図示せず）を通知して処理を終了する（ステップＳ１６．１６）。もし前記検証の結果ユーザーＩＤ、パスワードの組がＴａｂｌｅ１ユーザー管理テーブルに登録されていれば（ステップＳ１６．４）、認可サーバーモジュール５１０は、先にステップＳ１６．２にて取得したｎｏｎｃｅ値と、Ｓｃｏｐｅを、後述するＴａｂｌｅ５ ｎｏｎｃｅ−ｓｃｏｐｅ管理テーブルに登録する（ステップＳ１６．５）。

以下に示すＴａｂｌｅ５は認可サーバー５００が外部メモリに記憶するデータテーブルである。このデータテーブルは、認可サーバー５００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。本実施例においては、同一のＬＡＮ１０１に接続されている認可サーバー５００とＷｅｂ−Ｈｏｓｔｅｄクライアント３００において、認可サーバー５００がＴａｂｌｅ５を作成、参照、更新、削除可能、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００がＴａｂｌｅ５を参照可能なように構成する。

Ｔａｂｌｅ５はｎｏｎｃｅ−ｓｃｏｐｅ管理テーブルである。本テーブルは、ｎｏｎｃｅ値、ｓｃｏｐｅから成る。

次に認可サーバーモジュール５１０は、後述する暗号化、認可確認管理テーブルを参照する（ステップＳ１６．６）。以下に示すＴａｂｌｅ６は認可サーバー５００が外部メモリに記憶するデータテーブルである。このデータテーブルは、認可サーバー５００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。本実施例においては、同一のＬＡＮ１０１に接続されている認可サーバー５００がＴａｂｌｅ６を作成、参照、更新、削除可能なように構成する。

Ｔａｂｌｅ６は暗号化、認可確認管理テーブルである。本テーブルは、ｓｃｏｐｅ、暗号化、認可確認から成る。Ｓｃｏｐｅ列にはＳｃｏｐｅ文字列、暗号化、認可確認にはＢｏｏｌ値を格納する。暗号化、認可確認列のＢｏｏｌ値は、各々Ｔｒｕｅが行う、Ｆａｌｓｅが行わないを示す。なおＴａｂｌｅ６については、予め認可サーバー５００の管理者により設定されているものとする。本設定については、外部より設定可能としてもよい。

本実施例の場合、上記ステップＳ１６．５にてＴａｂｌｅ５に設定したｓｃｏｐｅは「ｓｃｏｐｅＤ」とする。上記ステップＳ１６．６にて認可サーバーモジュール５１０は、Ｔａｂｌｅ６を参照し、暗号化、認可確認共にしないことが確認できる。ここで認可確認モジュール５１０は、Ｔａｂｌｅ６から暗号化しないことを確認したので（ステップＳ１６．７）、次に認可確認処理を行う（ステップＳ１６．１２）。ここでもし上記ステップＳ１６．７にて暗号化することを確認したとしたら（ステップＳ１６．７）、認可サーバーモジュール５１０は、実施例３の図１３ａのステップＳ１３．５からＳ１３．７に示したと同様のアクセストークン暗号化の一連の処理を行う。本実施例においては、ステップＳ１６．９からＳ１６．１１が、各々図１３ａのステップＳ１３．５からＳ１３．７に相当するため説明を割愛する。

図１６ｂは、上記ステップＳ１６．１２の本実施例における認可サーバーモジュール５１０による認可確認処理を示すフローチャートである。認可サーバーモジュール５１０は、本認可確認処理においてステップＳ１６．１にて受信した前記クライアントＰＣ２００からの前記リダイレクト要求のリクエストパラメーターを確認する（ステップＳ１６．１６）。また前記リクエストパラメーターに含まれるＳｃｏｐｅ、本実施例の場合「ｓｃｏｐｅＤ」を取得する（ステップＳ１６．１７）。ここで認可サーバーモジュール５１０は、前記Ｔａｂｌｅ６暗号化、認可確認管理テーブルを参照し、前記リダイレクト要求のリクエストパラメーターのｓｃｏｐｅの値が前記Ｔａｂｌｅ６暗号化、認可確認管理テーブルに含まれるかどうかを確認する（ステップＳ１６．１８）。

ここでもし、前記リダイレクト要求のリクエストパラメーターのｓｃｏｐｅの値が前記Ｔａｂｌｅ６暗号化、認可確認管理テーブルの認可確認の値がＦａｌｓｅの場合、認可確認画面をクライアントＰＣ２００に返却せず、認可確認成功を返す（ステップＳ１６．２０）。本実施例の場合、「ｓｃｏｐｅＤ」に対するＴａｂｌｅ６の認可確認の値がＦａｌｓｅなので、上記のように認可確認成功を返す。ここでもし前記リダイレクト要求のリクエストパラメーターのｓｃｏｐｅの値が前記Ｔａｂｌｅ６暗号化、認可確認管理テーブルに含まれない、あるいは認可確認の値がＴｒｕｅの場合（ステップＳ１６．１９）、前記認可サーバーモジュール５１０は前記クライアントＰＣ２００に図６ｂに示す認可確認画面を返却する（ステップＳ１６．２１）。ここで前記認可サーバーモジュール５１０は、前記クライアントＰＣ２００からの応答を待ち、もし認可確認に失敗したならば（ステップＳ１６．２２）、認可確認失敗を返却して処理を終了する（ステップＳ１６．２３）。またもし認可確認に成功したならば（ステップＳ１６．２２）、認可確認成功を返却して処理を終了する（ステップＳ１６．２３）。

図１６ａにて、図１６ｂに示される前記認可確認処理（ステップＳ１６．１２）が終了した後、もし認可確認が失敗したならば（ステップＳ１６．１３）、クライアントＰＣ２００にユーザー認証エラー画面（図示せず）を通知して処理を終了する（ステップＳ１６．１６）。もし前記認可確認処理（ステップＳ１６．１２）が成功したならば（ステップＳ１６．１３）、認可サーバーモジュール５１０は、リソースサーバー４００へのアクセスを可能にするアクセストークンを生成するアクセストークン発行処理（ステップＳ１６．１４）を行う。

生成したアクセストークンは、前記Ｔａｂｌｅ３トークン管理テーブルに登録する。すなわち、アクセストークン文字列「ＡＴ＿０００００２」をトークンＩＤに格納する。また認可サーバーで予め定められたアクセストークンの有効期限を有効期限に格納する。また前記トークンテーブルに登録済みの認証トークンのレコードに含まれるスコープ情報をスコープに、ユーザーＩＤをユーザーＩＤに格納する。このように、認可サーバー５００は、ユーザーによる明示的な認可確認を行わず、リソースサーバー４００へのリソースアクセスを可能にするアクセストークン「ＡＴ＿０００００２」を発行する（ステップＳ１６．１５）。これはＷｅｂ−Ｈｏｓｔｅｄクライアント３００、リソースサーバー４００、認可サーバー５００がＷＡＮ１００を介さずに接続されているためである。本実施例においてはＬＡＮ１０１を校内とみなし、これらを同一セキュリティドメインとみなす。

ここで認可サーバーモジュール５１０がクライアントＰＣ２００に送信するアクセストークンの応答（図１２のＳ１２．１３に相当）は、以下のようにＯＡｕｔｈ２．０仕様に従う。すなわちａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄフォーマットを用いてリダイレクトＵＲＩのフラグメントコンポーネントに例えば以下のようなパラメーターを付与してクライアントＰＣ２００に応答を送信する。
ＨＴＴＰ／１．１ ３０２ Ｆｏｕｎｄ
Ｌｏｃａｔｉｏｎ： ｈｔｔｐ：／／ｃｌｉｅｎｔ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｂ＃ａｃｃｅｓｓ＿ｔｏｋｅｎ＝ＡＴ＿０００００２＆ｓｔａｔｅ＝ｘｙｚ
＆ｔｏｋｅｎ＿ｔｙｐｅ＝ｅｘａｍｐｌｅ＆ｅｘｐｉｒｅｓ＿ｉｎ＝３６００
上記のようにアクセストークン応答に付与されるパラメーターは、ＯＡｕｔｈ２．０仕様によるとａｃｃｅｓｓ＿ｔｏｋｅｎ、ｔｏｋｅｎ＿ｔｙｐｅ、ｅｘｐｉｒｅｓ＿ｉｎ、ｓｃｏｐｅ、ｓｔａｔｅである。上記に示したように、本実施例のようなＩｍｐｌｉｃｉｔ ｇｒａｎｔ認可フローのアクセストークン応答（図１２のＳ１２．１３に相当）は、クライアントＰＣ２００のＷｅｂブラウザー２３０にアクセストークンを取得させるため、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００に向けて一旦リダイレクトするようになる。前記アクセストークン応答を受信した前記クライアントＰＣ２００上のＷｅｂブラウザー２３０は、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００に前記アクセストークン応答をリダイレクトする（図１２のＳ１２．１４に相当）。ここで、本リダイレクトは、ＨＴＴＰの仕様によりフラグメントコンポーネントのパラメーターを含まない。

前記リダイレクトを受信したＷｅｂ−Ｈｏｓｔｅｄクライアント３００のＷｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記クライアントＰＣ２００上の前記Ｗｅｂブラウザー２３０にて前記アクセストークンを取得するためのスクリプトを含む応答を返す（図１２のＳ１２．１６に相当）。上記スクリプトは一般に、Ｗｅｂブラウザー２３０で実行可能なＪａｖａＳｃｒｉｐｔ（登録商標）であるが、その他ブラウザー上で実行可能なスクリプトであっても良い。上記アクセストークン取得スクリプトを受信した前記Ｗｅｂブラウザー２３０は、スクリプトを実行することでアクセストークンを取得し（図１２のＳ１２．１７に相当。ただし後述するように、トークンが暗号化されていない場合は復号化せず。）、リソースサーバー４００にアクセスすることができる（図１２のＳ１２．１８に相当）。

図１８に示すのは、上記Ｓ１２．１４からＳ１２．１６のＷｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０の処理を示すフローチャートである。前記Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記Ｗｅｂブラウザー２３０から前記リダイレクト応答を受信する（ステップＳ１８．１）。さらに前記Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記リダイレクトのＨＴＴＰ通信に含まれるＣｏｏｋｉｅパラメーターからｎｏｎｃｅ値を取得する（ステップＳ１８．２）。このｎｏｎｃｅ値は、Ｓ１２．１３にて設定した値である。ここで前記Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記Ｔａｂｌｅ５ ｎｏｎｃｅ−ｓｃｏｐｅ管理テーブルを参照し、前記取得したｎｏｎｃｅの値が存在するかどうか確認する（ステップＳ１８．３）。もし前記ｎｏｎｃｅ値がＴａｂｌｅ５に存在しなければ、エラー画面を生成して（図示せず）前記Ｗｅｂブラウザー２３０に送信して処理を終了する（ステップＳ１８．１４）。もし前記ｎｏｎｃｅ値がＴａｂｌｅ５に存在すれば（ステップＳ１８．３）、合致するｎｏｎｃｅに対応するｓｃｏｐｅを取得する（ステップＳ１８．４）。ここでもし、前記Ｔａｂｌｅ５ ｎｏｎｃｅ−ｓｃｏｐｅ管理テーブルに前記ｎｏｎｃｅに対応するｓｃｏｐｅが存在しなければ（ステップＳ１８．５）、エラー画面を生成して（図示せず）前記Ｗｅｂブラウザー２３０に送信して処理を終了する（ステップＳ１８．１４）。もし前記Ｔａｂｌｅ５ ｎｏｎｃｅ−ｓｃｏｐｅ管理テーブルに前記ｎｏｎｃｅに対応するｓｃｏｐｅが存在すれば（ステップＳ１８．５）、Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、Ｔａｂｌｅ６暗号化、認可確認管理テーブルを参照し、上記ｓｃｏｐｅが存在するかどうか確認する（ステップＳ１８．６）。

ここでもし、前記ｓｃｏｐｅが前記Ｔａｂｌｅ６暗号化、認可確認管理テーブルに存在しない、あるいは前記ｓｃｏｐｅに相当するＴａｂｌｅ６暗号化列がＦａｌｓｅであれば（ステップＳ１８．７）、実施例１の図７のフローチャートで示したアクセストークンを取得しリソースサーバーにアクセスするためのスクリプトを選択し（ステップＳ１８．１３）、クライアントＰＣ２００に上記スクリプトを送信して（ステップＳ１８．１２）処理を終了する。本実施例の場合、上記シーケンスにおけるｓｃｏｐｅは「ｓｃｏｐｅＤ」なので、前記ステップＳ１８．１３にてトークン暗号化をしない場合のアクセストークンを取得しリソースサーバーにアクセスするためのスクリプトを送信する。

もし前記ｓｃｏｐｅが前記Ｔａｂｌｅ６暗号化、認可確認管理テーブルに存在しＴａｂｌｅ６暗号化列がＴｒｕｅであれば（ステップＳ１８．７）、前記Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０は、前記Ｔａｂｌｅ４ ｎｏｎｃｅ−暗号鍵管理テーブルを参照し、前記取得したｎｏｎｃｅの値が存在するかどうか確認する（ステップＳ１８．８）。以降、ステップＳ１８．９からステップＳ１８．１２およびステップＳ１８．１４については、図１４のステップＳ１４．３からステップＳ１４．７およびステップＳ１４．８と同様であるので説明を割愛する。

このように、Ｗｅｂ−Ｈｏｓｔｅｄクライアントモジュール３１０にてｎｏｎｃｅ値を確認することにより、前記のような一連の処理に無関係なブラウザーなどに、トークン復号化に関連する暗号鍵、アクセストークン取得スクリプトの応答をしないようにすることができる。これにより、例え前記のようなブラウザーなどで前記暗号化したアクセストークンが詐取されたとしても、Ｗｅｂ−Ｈｏｓｔｅｄクライアント３００へのアクセスがエラーとなり、前記詐取された暗号化したアクセストークンの復号化を防止することができ、リソースサーバー４００への不正アクセスを防止することができる。

（その他の実施例）
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

２００ クライアントＰＣ
３００ Ｗｅｂ−Ｈｏｓｔｅｄクライアント
４００ リソースサーバー
５００ 認可サーバー
１０００ リソースオーナー

Claims (7)

1. クライアントから利用可能なサービスを備えるサーバーシステムと、前記サービスを利用するクライアントとを含む権限移譲システムであって、
   前記クライアントにて表示される認証画面を介しユーザーから入力された認証情報を基に、前記ユーザーが正規なユーザーであるか否かを判断する認証手段と、
   前記認証手段により正規なユーザーであると判断された前記ユーザーが前記クライアントにて表示される認可確認画面を介し、前記サービスにおける前記ユーザーの権限を前記クライアントへ移譲することを許可する指示をした場合に、前記ユーザーの権限が前記クライアントへ移譲されたことを示す権限情報を発行する発行手段と、
   前記クライアントが前記サービスの利用を要求した際に送信する前記権限情報を基に、前記クライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可手段と、
   前記サービスのドメインと、前記権限情報を前記クライアントに取得させるためのエンドポイントのドメインとが同一のドメインであるか否かを判断する判断手段とを有し、
   前記発行手段は、前記判断手段により２つのドメインが同一のドメインであると判断されたことに応じて、前記サービスにおける前記ユーザーの権限を前記クライアントへ移譲することを許可する指示を受け付けることなく、前記ユーザーの権限が前記クライアントへ移譲されたことを示す権限情報を発行することを特徴とする権限移譲システム。
2. 前記クライアントとはＷｅｂブラウザーではないアプリケーションであり、前記エンドポイントは前記クライアントに前記権限情報を取得させるためのスクリプトを生成するホスト手段のアドレスを示す場合であって、
   前記アプリケーションは、前記ホスト手段にアクセスすることなく、前記権限情報を取得することを特徴とする請求項１に記載の権限移譲システム。
3. 前記クライアントとはＷｅｂブラウザーであり、前記エンドポイントは前記クライアントに前記権限情報を取得させるためのスクリプトを生成するホスト手段のアドレスを示す場合であって、
   前記Ｗｅｂブラウザーは、前記ホスト手段により生成されたスクリプトに従い、前記ホスト手段にアクセスする前に前記クライアントに備えられたメモリに保存をした前記権限情報を取得し前記サービスの利用を要求する際に前記サービスへ送信することを特徴とする請求項１に記載の権限移譲システム。
4. 前記発行手段は、ユニークＩＤを基に暗号鍵を生成し、生成された暗号鍵を基に前記権限情報を暗号化し、暗号化された前記権限情報と前記ユニークＩＤを前記クライアントへ送信し、
   前記ホスト手段は、前記クライアントから送信されるユニークＩＤが、前記発行手段により暗号化された前記権限情報に紐付くユニークＩＤであった場合、前記暗号化された前記権限情報を復号化するためのスクリプトを生成し前記クライアントへ送信することを特徴とする請求項２または３に記載の権限移譲システム。
5. 前記認可手段は、前記クライアントが要求する前記サービスを利用するために必要な権限が、前記権限情報から特定される前記クライアントに移譲された前記ユーザーの権限の範囲内ではないと判断した場合、前記クライアントが前記サービスを利用することを認可しないことを特徴とする請求項１乃至４の何れか１項に記載の権限移譲システム。
6. クライアントから利用可能なサービスを備えるサーバーシステムと、前記サービスを利用するクライアントと通信可能な認証サーバーシステムであって、
   前記クライアントにて表示される認証画面を介しユーザーから入力された認証情報を基に、前記ユーザーが正規なユーザーであるか否かを判断する認証手段と、
   前記認証手段により正規なユーザーであると判断された前記ユーザーが前記クライアントにて表示される認可確認画面を介し、前記サービスにおける前記ユーザーの権限を前記クライアントへ移譲することを許可する指示をした場合に、前記ユーザーの権限が前記クライアントへ移譲されたことを示す権限情報を発行する発行手段と、
   前記クライアントが前記サービスの利用を要求した際に送信する前記権限情報を基に、前記クライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可手段と、
   前記サービスのドメインと、前記権限情報を前記クライアントに取得させるためのエンドポイントのドメインとが同一のドメインであるか否かを判断する判断手段とを有し、
   前記発行手段は、前記判断手段により２つのドメインが同一のドメインであると判断されたことに応じて、前記サービスにおける前記ユーザーの権限を前記クライアントへ移譲することを許可する指示を受け付けることなく、前記ユーザーの権限が前記クライアントへ移譲されたことを示す権限情報を発行することを特徴とする認証サーバーシステム。
7. クライアントから利用可能なサービスを備えるサーバーシステムと、前記サービスを利用するクライアントと通信可能な認証サーバーシステムにて実行されるプログラムであって、
   前記クライアントにて表示される認証画面を介しユーザーから入力された認証情報を基に、前記ユーザーが正規なユーザーであるか否かを判断する認証ステップと、
   前記認証ステップにおいて正規なユーザーであると判断された前記ユーザーが前記クライアントにて表示される認可確認画面を介し、前記サービスにおける前記ユーザーの権限を前記クライアントへ移譲することを許可する指示をした場合に、前記ユーザーの権限が前記クライアントへ移譲されたことを示す権限情報を発行する発行ステップと、
   前記クライアントが前記サービスの利用を要求した際に送信する前記権限情報を基に、前記クライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可ステップと、
   前記サービスのドメインと、前記権限情報を前記クライアントに取得させるためのエンドポイントのドメインとが同一のドメインであるか否かを判断する判断ステップとを含み、
   前記発行ステップにおいて、前記判断ステップにて２つのドメインが同一のドメインであると判断されたことに応じて、前記サービスにおける前記ユーザーの権限を前記クライアントへ移譲することを許可する指示を受け付けることなく、前記ユーザーの権限が前記クライアントへ移譲されたことを示す権限情報を発行することを特徴とするプログラム。

Images