JP2016115260A - 権限移譲システム、権限移譲システムに用いられる認可サーバー、リソースサーバー、クライアント、媒介装置、権限移譲方法およびプログラム - Google Patents

Abstract

【課題】クライアント権限の変更により権限に紐付く非機能要件を変更できる権限移譲システムを提供する。【解決手段】リソースサーバーはクライアント要求に対し認証識別子を発行し、認可サーバーは認証識別子、及び媒介装置の宛先情報をクライアントから受信し、認可サーバーに予め登録した情報に基いて、クライアント権限を証明する証明情報を発行する。媒介装置はクライアントから証明情報が送られた場合、認証識別子と認可サーバーに予め登録した情報に基いて証明情報を発行し、リソースサーバーは媒介装置が発行した証明情報をクライアントから受信し、認証識別子に基いてリソースをクライアントに提供する。認可サーバーは、同じリソースについて性能の異なる複数のリソースサーバーに対応する複数の媒介装置の宛先情報を予め登録し、いずれかの宛先情報をクライアントにより選択可能とする。【選択図】図６

Description

認可フローにおける権限選択方法に関し、特にOAuth implicit grantにおけるクライアント権限による機能、リソース選択方法に関する。

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

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

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

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

また近年の機器には、OAuthを用いて、クラウドサービスと連携することでユーザーに付加価値を提供するものがある。例えばソーシャル・ネットワーキング・サービス（以下「SNS」と呼ぶ）と呼ばれるサービスがある。これらのサービスはスマートフォンから利用することができる。SNSには様々なものがあるが、特定のアプリケーションをスマートフォンにインストールして利用することで、そのSNSを利用しやすくなることがある。例えば定期的に自分の居場所をSNSに投稿したいユーザーは、スマートフォンの測位機能を使い、定期的に測位とSNSへの投稿を行うアプリケーションを利用すると、便利と感じるだろう。

ここでスマートフォンにインストールされたアプリケーションは、SNSにユーザーの代理でアクセスすることになる。このような場合にOAuthが利用されることがある。ユーザーは、SNSを利用するのに必要な最小限の機能、例えば記事を投稿することをアプリケーションに許可することで、アプリケーションを介してSNSを利用できるようになる。

ところでOAuthにおいては、JavaScript（登録商標）の様なスクリプト言語によるブラウザー上で実行されるクライアントに最適化されている、「インプリシットグラント」と呼ばれるアクセストークン取得のフローが定義されている。上記のようなクライアントは、リソースオーナーの認可後、アクセストークン取得のための仲介のクレデンシャルである認可コードではなく、直接アクセストークンを受け取る。このグラントタイプは、認可コードのようなアクセストークン取得を仲介するクレデンシャルを利用しないため、インプリシットグラントと呼ばれる。

インプリシットグラントの特徴として、アクセス主体であるクライアントのクレデンシャルの認可サーバーへの提示が必要ない、ということがある。したがって、インプリシットグラントでは、クライアントの権限による非機能要件の違いを出すことができない。すなわち、クライアントクレデンシャルの提示がないため、権限に基づく非機能要件の変更ができない。また、インプリシットグラントでは、アクセストークンがユーザー (リソース所有者) に容易に傍受されうる。なお、「非機能要件」とは、システム設計や情報システム開発上の要求分析において、要件、システム要件といった機能面以外の全般を指すものである。

現状Webブラウザーから上記のようなクラウドサービスと連携するサービスを利用する場合、認証情報をCookie等でログインセッションを引き回し、OAuthのような認可確認を明示的に行わない実装もおこなわれている。

ところで、現在Webブラウザーからも jQuery 等を用いたAPIアクセスで前記クラウドサービスと連携するサービスを利用する形態がデファクトスタンダードになりつつある。この背景としては、モバイルの普及やブラウザーOSの登場といったトレンドが影響している。

上記ソリューションのメリットとしては以下がある。
（１）サーバーサイドをRESTfulなJSON APIに統一することで、UIを伴うWebブラウザーからの呼び出しだけでなく、UIを伴わない他アプリケーションからの呼び出し（サービス公開）にも対応できる。
（２）サーバーサイドのテンプレート、レンダリング処理が不要となり、サーバーサイドの処理負荷を軽減できる。

アーキテクチャ的な裏付けとしては、以下がある。
（１）サーバー側：クライアントからの大量の同時アクセス（処理リクエスト）に応えられる、Nodeのような非同期にNon Blocking 処理を行うサーバー側アーキテクチャ。（大量のI/O処理を同期で処理し、ネットワークI/Oを伴わないCPUバウンドな処理は非同期処理に回す）
（２）クライアント側：非同期処理ライブラリのAJAX、リッチなUI処理を可能にするJQuery。多言語対応を可能にするGlobalizeプラグイン（JQueryのプラグイン）などのJavascript（登録商標）ライブラリ。クライアント側でライブラリを高速で実行できるJavascript（登録商標）エンジン。

"The OAuth 1.0 Protocol"、[online] E. Hammer-Lahav、2012年9月 ＜URL http://tools.ietf.org/html/rfc5849＞ "The OAuth 2.0 Authorization Framework"、[online] D. Hardt、2013年5月 ＜URL http://tools.ietf.org/html/rfc6749＞

現在スタンダードな手法になりつつあるjQuery を用いたAPIアクセスによりクラウドサービスを利用する形態の場合、認可フローとしてOAuthを使用することになる。その際、サービス利用のクライアントがWebブラウザーの場合等、OAuth のインプリシットグラントを用いる場合がある。インプリシットグラントを用いた場合、クライアントの権限を変更することで、権限に紐付く非機能要件（パフォーマンス）を変更することができない。

OAuthインプリシットグラントを用いた場合、オーソライゼーションコードグラントと異なり、クライアント認証が存在しない。よって、クライアントの権限を変更することで非機能要件（例えばパフォーマンス等）を変更することができない。（例えクライアント権限を変更したとしても、クライアント認証せずにクライアント権限チェックすることはセキュリティ上行うことができない）

クライアント権限チェックが必要な理由としては以下を挙げることができる。クライアントが契約サービスを利用するためには、権限（に紐付くロール）が必要。サービス提供者は、ユーザー（クライアント）に対し、権限確認なしに自分が契約しているサービスを利用されてはいけない。

本発明は前述の課題を鑑みてなされたものであり、リソースを提供するリソースサーバーと、クライアントの認証及びリソースの認可を行なう認可サーバーと、クライアントと認可サーバーとの間の通信を媒介する媒介装置とを有する、ネットワークにおいて用いられる権限移譲システムであって、リソースサーバーは、保護されたリソースに対するクライアントからの要求に対し、クライアントの認証に用いられる認証識別子をクライアントに発行し、認可サーバーは、クライアントを識別する識別情報、リソースサーバーが発行した認証識別子、媒介装置の宛先を示す宛先情報をクライアントから受信し、認可サーバーに予め登録した情報に基づいて、クライアントを認証し、認証に成功した場合、クライアントが保護されたリソースに対して権限を有するかどうか検証し、検証に成功した場合、権限を有することを証明する証明情報をクライアントに発行し、媒介装置は、クライアントから宛先情報が示す宛先に認可サーバーが発行した証明情報が送られた場合、認証識別子と認可サーバーに予め登録した情報に基づいて、クライアントが保護されたリソースに対して権限を有するかどうか検証し、検証が成功した場合、権限を有することを証明する証明情報をクライアントに発行し、リソースサーバーは、媒介装置が発行した証明情報をクライアントから受信し、認証識別子に基づいて、クライアントからの要求を許可するかどうか検証し、検証に成功した場合、保護されたリソースをクライアントに提供し、認可サーバーは、同じリソースについて性能の異なる複数のリソースサーバーに対応する複数の媒介装置の宛先情報を予め登録し、そのうちのいずれかの宛先情報をクライアントにより選択可能とすることを特徴とする権限移譲システムを提供する。

Web API を通じて印刷サービスなどを提供し、OAuthのImplicitフローを利用するようなクラウドサービスにおいて、Client登録時、契約により複数のリダイレクトURLのうちの一つを選択できる。クライアントが動作する際、非機能要件（パフォーマンス等）の異なるリソースサーバーのエンドポイントのどれを使用するか指定できる。また、クライアント登録時に一つのクライアントに複数のリダイレクトURIを対応付けて登録することにより、リソースサーバーのエンドポイントを選択でき、ユーザーの利便性が向上する。

実施例１のシステム構成図。 実施例１の各装置のハードウェア構成図。 実施例１の各装置のモジュール構成図。 実施例１の認可クライアント登録処理シーケンス図。 実施例１の認可クライアント登録画面。 実施例１の認証認可フローのシーケンス図。 実施例１の認可サーバー処理のフローチャート。 実施例１の認可確認画面。 実施例１のWeb-Hostedクライアント処理のフローチャート。 実施例１の認可サーバーのWeb-Hostedクライアントnonce値検証処理のフローチャート。 実施例１の認可クライアントのクライアントスクリプト処理のフローチャート。 実施例１の認可サーバーのリソースサーバーnonce値検証処理のフローチャート。 実施例２の認可クライアント登録画面。 実施例２の認証認可フローのシーケンス図。

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

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

さらに本実施の形態における権限の移譲ではOAuthの仕組みを利用する。OAuthでは、ユーザーから移譲された権限を証明するための情報として、「トークン」と呼ばれる証明情報を利用する。

＜実施例１＞（単数リダイレクトURIによるリソースサーバー非機能要件選択）
本実施例に係る権限移譲システムは、図１に示すような構成のネットワーク上に実現される。100はWide Area Network（WAN100）であり、本実施例ではWorld Wide Web（WWW）システムが構築されている。101、102は、各構成要素を接続するLocal Area Network（LAN101、LAN102）である。

認可サーバー500はOAuthを実現するためのサーバーであり、認可サービスモジュールが設置されている。Web-Hostedクライアント300、301、302は、OAuthにおけるWeb-Hostedクライアントリソースを実装するクライアントである。本実施例ではWeb-Hostedクライアント300、301、302は認可サーバー500とクライアントPC200の間の通信を媒介する媒介装置として機能する。具体的には、Web-Hostedクライアント300、301、302は認可サーバー500からクライアントPC200向けのアクセストークンの応答先のリダイレクトURIとして指定される。また、後述する異なる非機能要件を持つリソースサーバー400、401、402の各々に対応する。

リソースサーバー400、401、402は、印刷サービスや帳票サービスといったリソースサービス連携アプリケーションが設置されるサーバーである。なお１台のリソースサーバーに設置されるリソースサービス連携アプリケーションは１つでもよく、複数でもよい。またリソースサーバー400、401、402は、同じリソースサービス連携アプリケーションを提供するが、各々CPUの処理速度、メモリ容量、ディスク容量、許容同時接続数等の非機能要件に関わる仕様の異なるサーバー群である。本実施例においては、リソースサーバーの仕様は400が高スペック、401が中間スペック、402が低スペックである。本実施例においては、リソースサーバー400、401、402のスペックの違いは、リソースサーバー連携アプリケーションの能力の違いを表す。例えば印刷サービスにおいて、無償提供のサービスについては低スペックのリソースサーバー402に誘導する。有償提供の性能保証が必要なサービスについては契約するサービス性能に応じて中間性能のリソースサーバー401や高性能のリソースサーバー400に誘導する。

クライアントPC200はユーザーが操作するPCである。クライアントPC200はPC上のWebブラウザーで後述するクライアントスクリプトを実行し、後述するクライアント登録の選択により、いずれかのリソースサーバーのリソースを用いて、印刷サービスや帳票サービスといったサービスを利用する。なお、本実施例の特徴として、Web-Hostedクライアント300、301、302とリソースサーバー400、401、402が、認可サーバー500と同一のLAN101に接続されている。また、Web-Hostedクライアント300、301、302と、リソースサーバー400、401、402と、認可サーバー500がWAN100を介さずに接続されている。このため本実施例においてはこれらを同一セキュリティドメインとみなし、Web-Hostedクライアント300、301、302とリソースサーバー400、401、402のサービス連携を、同一の認証で賄うことを特徴とする。

またクライアントPC200、Web-Hostedクライアント300、301、302、リソースサーバー400、401、402は、それぞれWAN100およびLAN101、LAN102を介して接続されている。なおクライアントPC200およびそれぞれのサービスはそれぞれ個別のLAN上に構成されていてもよいし同一のLAN上に構成されていてもよい。また同一のPC上に構成されていてもよい。

図２は本実施例に係るクライアントPC200の構成を示す図である。Web-Hostedクライアント300、301、302、リソースサーバー400、401、402、認可サーバー500のサーバーコンピューターの構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施例のクライアントPC200およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。

図２において、CPU201は、ROM203のプログラムROMに記憶された、或いはハードディスク（HD）211からRAM202にロードされたOSやアプリケーション等のプログラムを実行する。なおOSはコンピュータ上で稼動するオペレーティングシステムである。後述する各フローチャートの処理はこのプログラムの実行により実現できる。RAM202はCPU201の主メモリ、ワークエリア等として機能する。キーボードコントローラ（KBC）205はキーボード（KB）209や不図示のポインティングデバイスからのキー入力を制御する。CRTコントローラ（CRTC）206は、CRTディスプレイ210の表示を制御する。ディスクコントローラ（DKC）207は各種データを記憶するハードディスク（HD）211やフロッピー（登録商標）ディスク（FD）等におけるデータアクセスを制御する。NC212はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。

なお、後述の説明において、特に断りのない限り実行のハード上の主体はCPU201であり、ソフトウェア上の主体はハードディスク（HD）211にインストールされたアプリケーションプログラムである。

図３は本実施例に係る認可サーバー500、リソースサーバー400、401、402、クライアントPC200、Web-Hostedクライアント300、301、302の、それぞれのモジュール構成を示す図である。なお認可サーバー500、リソースサーバー400、401、402、クライアントPC200、Web-Hostedクライアント300、301、302は、図１のものと同一である。

認可サーバー500は認可サーバーモジュール510を備え、同モジュールはユーザー識別部610、クライアント登録部620、nonce値検証部630、クライアント検証部520、トークン検証部530、トークン発行部540を備える。なお、「nonce」（ノンス）とは、暗号通信で用いられる使い捨てのランダムな値のことであり、通常は認証の過程で使われ、リプレイ攻撃を行えないようにする働きを担っている。以下、使い捨ての認証識別子の意で用いる。

リソースサーバー400、401、402は同一のモジュール構成を持つ。以下、代表してリソースサーバー400について説明する。リソースサーバー400はリソースサーバーモジュール410を備え、同モジュールはトークン権限確認部420、リソース要求処理部430、後述するnonce値確認部440を備える。

クライアントPC200は、CPU201がROM203、或いは外部メモリ211に記憶されたOS220を実行する事で各アプリケーションを制御する。OSとしては一般的にはリアルタイムOSが使用されるが、昨今ではLinux（登録商標）等の汎用OSが使用される事もある。さらに、クライアントPC200はWWWを利用するためのユーザーエージェントであるWebブラウザー230を備える。

Web-Hostedクライアント300、301、302は同一のモジュール構成を持つ。以下、代表してWeb-Hostedクライアント300について説明する。Web-Hostedクライアント300はWeb-Hostedクライアントモジュール310を備え、同モジュールは後述するnonce値確認部330を備える。また、同モジュールは、クライアントPC200からのアクセストークン応答のリダイレクトURIリクエストを受信し、後述するアクセストークン取得とリソースリクエストを行うクライアントスクリプト320を返す機能を持つ。

以下の表１〜表５は認可サーバー500が外部メモリに記憶するデータテーブルを示す。これらのデータテーブルは、認可サーバー500の外部メモリではなく、LAN101を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。

表１のユーザー管理テーブルは、ユーザーID（識別情報）、パスワード、ユーザー種別から成る。認可サーバー500は、ユーザーID、パスワードの情報の組を検証し、正しければ認証情報を生成することで、各ユーザーもしくはクライアントを認証する機能を備える。

表２のクライアント管理テーブルは、クライアントID、クライアント名、リダイレクトURIから成る。クライアントID、クライアント名、リダイレクトURIは後述のOAuthのシーケンスで利用される値である。

表３のトークン管理テーブルはトークンID、有効期限、スコープ、クライアントID、ユーザーIDから成る。トークン管理テーブルの処理詳細については後述する。

表４のnonce値管理テーブルは、nonce値、トークンID、有効期限から成る。nonce値管理テーブルの処理詳細については後述する。

表５のクライアント、リソースサーバー管理テーブルはWeb-Hosted Client URIとリソースサーバーURI から成る。この管理テーブルは、Web-Hostedクライアント300、301、302、リソースサーバー400、401、402、認可サーバー500のサーバーシステム構築者がサーバーシステム構築時に予め登録する。Web-Hostedクライアント300に対してリソースサーバー400を対応付けて登録する。さらにWeb-Hostedクライアント301、302に対しても同様に、リソースサーバー401、402を各々対応付けて登録する。もしリソースサーバーを増設する場合には、対応するWeb-Hostedクライアントも同じ台数増設し、前記と同様に表５の管理テーブルに登録する。クライアント、リソースサーバー管理テーブルの処理詳細については後述する。

ここで、非機能要件の異なるリソースサーバーを選択可能にするために必要なクライアント登録処理を行うための、本実施例に係るクライアント登録フローを表すシーケンスについて図４、５を用いて説明する。図４のクライアント登録フローは、OAuth2.0で一般的なOAuth2.0仕様におけるクライアント登録に関して、本実施例独自の拡張を加えたフローである。

図４のフローにおいて、まず、クライアント登録者1001が、本実施例におけるリソースアクセスに必要なOAuth2.0仕様で言うところのクライアントについて、クライアント登録を行う。後述するリソースオーナー1000は、本フローにより事前登録されたクライアントを用いてリソースアクセスを行うことになる。クライアント登録者1001は、Webブラウザー230を用いて認可サーバー500に対してクライアント登録画面を要求する（S4.1）。認可サーバー500は、S4.1の要求に応じて、図５に示すようなクライアント登録画面を返す（S4.2）。

図５はOAuth2.0仕様におけるクライアントについて登録を行うためのクライアント登録画面である。クライアント登録画面は、認可サーバー500がクライアント登録に必要なパラメーターを表示、選択するクライアント登録パラメーター表示5000と、以下の２つのボタンから成る。即ち、クライアント登録パラメーターを確定して認可サーバー500に登録するためのOKボタン5005と、クライアント登録パラメーター表示5000をキャンセルするキャンセルボタン5006である。

クライアント登録パラメーター表示5000は、クライアント名入力行5007、クライアントID表示行5001、リダイレクトURI選択行5002、5003、5004から成る。クライアントID表示行5001には、クライアント登録画面要求（S4.1）を受けた認可サーバー500が、クライアント登録画面返却時（S4.2）に、UUID形式のランダムかつユニークな値を生成して表示する。例えば、’9237ee87-1d58-4b0d-a7ed-a4042402df52’のような値である。クライアント名入力行5007には、クライアント登録者1001がクライアント登録時に任意のクライアント名を入力する。リダイレクトURI選択行5002、5003、5004は、本クライアント登録の際に有効となる、OAuth2.0仕様で言うところのリダイレクトURIの予め用意された選択肢を表示する。さらに、クライアント登録者1001が複数のリダイレクトURI選択肢の中から一つを選択して認可サーバー500に登録するように、リダイレクトURI選択行5002、5003、5004の各々の行にラジオボタンを表示し、一つを選択可能とする。

リダイレクトURIの複数の選択行5002、5003、5004は、非機能要件の異なるリソースサーバー400、401、402にクライアントを誘導するためのリダイレクトURIである。このうち、5002のリダイレクトURIはリソースサーバー400にアクセスするためのURIである。同様に、5003のリダイレクトURIはリソースサーバー401にアクセスするためのリダイレクトURIであり、5004は402にアクセスするためのリダイレクトURIである。これらの関係は、表５に示すクライアント、リソースサーバー管理テーブルにより予め定義されている。

図４のフローに戻り、クライアント登録者1001は、S4.2にて認可サーバー500から返された図５のクライアント登録画面を参照し、クライアント登録内容を入力する（S4.3）。具体的には、クライアントIDを確認し、リダイレクトURIを図５に示す選択肢（リダイレクトURI5002、5003、5004）の中から一つを、ラジオボタンを選択することにより選択して、OKボタン5006を押下する。クライアント登録者1001がOKボタン5006を押下すると、Webブラウザー230は認可サーバー500に対してクライアント登録処理要求を送信する（S4.4）。

認可サーバー500は、クライアント登録処理要求（S4.4）を受信したらクライアント登録処理を行う（S4.5）。具体的には、認可サーバー500のクライアント登録部620により、受信したクライアント登録処理要求（S4.4）からクライアント名とクライアントIDとリダイレクトURIを、認可サーバー500上のクライアント管理テーブル（表２）に登録する。認可サーバー500は、クライアント管理テーブルへのクライアント名、クライアントID、リダイレクトURIの登録が完了したら、登録内容（不図示）をWebブラウザー230に返却して処理を終了する（S4.6）。なお、本実施例ではクライアント登録者による認可サーバーへのクライアント登録処理についてWebブラウザーを用いた処理としているが、認可サーバーへの登録処理は専用登録アプリなどを用いても良い。

ここで、図６を用いて、クライアントPC200上のブラウザーアプリケーションを用いてリソースサービスを利用するための、本実施例に係る認可フローを表すシーケンスについて説明する。OAuth2.0の仕様では、多様なクライアントに応じた複数のプロトコルシーケンスをgrant typeと呼ぶ。図６の認可フローは、OAuth2.0仕様のimplicit grantに本実施例独自の拡張を加えたgrant typeである。

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

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

リソースサーバー400は、認可連携サービス開始要求（S6.1）により認可連携の開始を受け付けたら、次のように処理する。即ち、リソースサーバー400の持つ認可サーバー500の認証エンドポイントのURLに対して、Cookieとしてリソースサーバー400で算出した乱数に基づき16進数値文字列で表されるnonce値をセットする（S6.2）。このnonce値はUUID（Universally Unique Identifier）で表現され、例えば、以下のような値である。
nonce=7172f4bd-b332-4cfe-85cf-e4a73fe6ff98

そしてリソースサーバー400は、OAuthの認可リクエストをするように、クライアントPC200のWebブラウザー230にHTTP/1.1 ステータスコード302のリダイレクトを要求する（S6.3）。本リダイレクト要求のHTTP Locationヘッダーにはリソースサーバー400のID、認証フローのタイプ、認可サーバー500の認証エンドポイントのURLが含まれ、以下のようなリダイレクト要求となる。

https://auth.a01.example.com/authorize?response_type=token&client_id=ztr1JhRGa5
&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=scopeA
HTTPメソッド： GET
Content-Type： application/x-www-form-urlencoded

リクエストパラメーターには、response_typeとして、”token”固定文字列を指定する。また、client_idとして、予めクライアントアプリケーションとして認可サーバー500に登録したリソースサーバー400上のクライアントアプリケーションのアプリケーションIDを指定する。さらに、redirect_uriとして予めクライアントアプリケーションとして認可サーバー500に登録したWeb-Hostedクライアント300のURL（宛先情報）を指定する。また、OAuthでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むように構成する事もできる。本実施例ではスコープとしてスコープAがリクエストされたとして説明する。

リダイレクト要求を受信したクライアントPC200は、要求に従い認可サーバー500に対してユーザー認証、認可の要求を行う（S6.5）。認可リクエストを受け付けた認可サーバー500は、ユーザーを認証するために、図８（ａ）に示すログイン画面2000をクライアントPC200上のWebブラウザー230に応答する（S6.6）。リソースオーナー1000であるユーザーはWebブラウザー230に示されたログイン画面2000に対して、ユーザーID（2001）とパスワード（2002）を入力し、ログイン（2003）を実行する（S6.7）。認可サーバー500は受け付けたユーザーID、パスワードの組が表１のユーザー管理テーブルに登録されている情報と合っているかを検証する（S6.8）。

ここで図７（ａ）、（ｂ）のフローチャートを用いて、ユーザー認証画面表示（S6.6）、ユーザー認証（S6.7）、リダイレクトURIとCookieのドメインパラメーター比較（S6.8）について説明する。また、本実施例の特徴である、認可確認画面表示（S6.9）、認可確認（S6.10）について、およびアクセストークン応答（S6.11）について説明する。

図７（ａ）は、認可サーバー500がユーザー認証、認可の要求を受け付けた際の、認可サーバー500上の認可サーバーモジュール510の処理フローチャートである。本フローは認可サーバーモジュール510がクライアントPC200からリダイレクト要求を受信することで始まる（S7.1）。認可サーバー500は、クライアントPC200から受信したリダイレクト要求に含まれるCookieからnonce値を取得する（S7.2）。

認可サーバーモジュール510は、ユーザーを認証するために図８（ａ）に示すログイン画面2000をクライアントPC200上のWebブラウザー230に応答する。リソースオーナー1000であるユーザーはWebブラウザー230に示されたログイン画面2000に対して、ユーザーID、パスワードを入力しログインを実行する（S6.7）。認可サーバー500は受け付けたユーザーID、パスワードの組が表１のユーザー管理テーブルに登録されている情報と合っているかを検証する（S7.3）。

検証の結果、ユーザーID、パスワードの組が表１のユーザー管理テーブルに登録されていなければ（S7.4）、クライアントPC200にユーザー認証エラー画面（図示せず）を通知して処理を終了する（S7.10）。もし検証の結果、ユーザーID、パスワードの組がユーザー管理テーブルに登録されていれば（S7.4）、認可確認処理（S7.5）を行う。

図７（ｂ）は図７（ａ）の認可確認処理（S7.5）の詳細を示すフローチャートである。まず、認可サーバーモジュール510は、S7.1にて受信したクライアントPC200からのリダイレクト要求のリクエストパラメーターを確認する（S7.11）。またリクエストに含まれるCookieのnonce値パラメーター、例えばnonce=7172f4bd-b332-4cfe-85cf-e4a73fe6ff98を取得する（S7.12）。

次に、認可サーバーモジュール510は、表２のクライアント管理テーブルを参照し、リダイレクト要求のリクエストパラメーターのclient_id、redirect_uriの値がクライアント管理テーブルに含まれるかどうかを確認する（S7.13）。この値がクライアント管理テーブルに含まれなければ、認可サーバーモジュール510は図８（ｃ）に示す認可確認失敗を返却して処理を終了する（S7.17）。一方、リクエストパラメーターのclient_id、redirect_uriの値がクライアント管理テーブルに含まれていれば、サーバーモジュール510はクライアントPC200に図８（ｂ）に示す認可確認画面を返却する（S7.14）。

ここで認可サーバーモジュール510は、クライアントPC200からの応答を待ち、認可確認に失敗したならば（S7.15）、認可確認失敗を返却して処理を終了する（S7.17）。一方、認可確認に成功したならば（S7.15）、認可確認成功を返却して処理を終了する（S7.16）。

図７（ａ）のフローに戻る。図７（ｂ）の認可確認処理（S7.5）の後、認可確認が失敗したならば（S7.6）、認可サーバーモジュール510は、クライアントPC200にユーザー認証エラー画面（図示せず）を通知して処理を終了する（S7.10）。一方、認可確認処理が成功したならば（S7.6）、認可サーバーモジュール510は、リソースサーバー400へのアクセスを可能にするアクセストークンを生成するアクセストークン発行処理（S7.7）を行う。

アクセストークン発行処理（S7.7）で生成したアクセストークンは、表３のトークン管理テーブルに登録する。すなわち、アクセストークン文字列「AT_000001」をトークンID欄に、認可サーバーで予め定められたアクセストークンの有効期限を有効期限欄に格納する。またトークンテーブルに登録済みの認証トークンのレコードに含まれるスコープ情報をスコープ欄に、ユーザーIDをユーザーID欄に格納する。

さらに認可サーバーモジュール510は、アクセストークン発行部540を用いて、表４の nonce値管理テーブルに、取得したnonce値、発行したアクセストークンのアクセストークン文字列、トークン有効期限を紐付けて保存する（S7.8）。この場合、nonce値はnonce=7172f4bd-b332-4cfe-85cf-e4a73fe6ff98、アクセストークン文字列は「AT_000001」である。保存処理が終了したら、認可サーバーモジュール510はアクセストークン発行部540を用い、アクセストークン応答（S6.11）としてクライアントにアクセストークンを送信する（S7.9）。

ここで図６のフローに戻る。認可サーバーモジュール510がクライアントPC200に送信するアクセストークンの応答（S6.11）は、以下のようにOAuth2.0仕様に従う。すなわちapplication/x-www-form-urlencoded フォーマットを用いてリダイレクトURIのフラグメントコンポーネントに、例えば以下のようなパラメーターを付与してクライアントPC200に応答を送信する。なお、下記のようにアクセストークン応答に付与されるパラメーターは、OAuth2.0仕様によると、access_token、token_type、expires_in、scope、stateである。

HTTP/1.1 302 Found
Location: http://client.example.com/cb#access_token=AT_000001&state=xyz
&token_type=example&expires_in=3600

上述したように、本実施例のようなImplicit grant認可フローのアクセストークン応答（S6.11）は、クライアントPC200のWebブラウザー230にアクセストークンを取得させる。そのため、アクセストークンをWeb-Hostedクライアント300に向けて一旦リダイレクトするようになる。アクセストークン応答を受信したクライアントPC200上のWebブラウザー230は、Web-Hostedクライアント300にアクセストークン応答をリダイレクトする（S6.12）。ここで、S6.12のリダイレクトは、HTTPの仕様によりフラグメントコンポーネントのパラメーターを含まない。

リダイレクトを受信したWeb-Hostedクライアント300のWeb-Hostedクライアントモジュール310は、認可サーバー500に対してnonce値検証要求を行う（S6.13）。nonce値検証要求を受けた認可サーバー500はリダイレクトURIとnonce値の比較を行ってnonce値の検証を行う（S6.14）。そして上記検証結果の応答をWeb-Hostedクライアント300に返す（S6.15）。ここで検証に成功した場合、Web-Hostedクライアント300はアクセストークン取得スクリプト応答をWebブラウザー230に返す（S6.16）。

以下、図９、１０を用いて、上記Web-Hostedクライアント処理について説明する。図９は、Web-Hostedクライアント処理を示すフローチャートである。本フローチャートは、Web-Hostedクライアント300のWeb-Hostedクライアントモジュール310が、クライアントPC200上のWebブラウザー230から、アクセストークンリダイレクト応答を受信する（S9.1）ことから始まる。Web-Hostedクライアントモジュール310は、リダイレクト応答のCookieに含まれるnonce値を取得する（S9.2）。

次にWeb-Hostedクライアントモジュール310は、nonce値確認部330を用いて、取得したnonce値とWeb-Hostedクライアント自身のURIを引数にして、認可サーバー500にnonce値検証処理を要求する（S9.3）。nonce値検証処理（S9.3）の認可サーバー500側の処理については、後述する図１０のフローチャートを用いて説明する。nonce値検証処理に成功したならば（S9.4）、Web-Hostedクライアントモジュール310は、クライアントPC200上のWebブラウザー230上で実行可能な、アクセストークンを取得するためのスクリプトを生成する（S9.5）。そして、上記スクリプトを含む応答を返す（S9.6）。一方、nonce値検証処理に失敗したならば（S9.4）、Web-Hostedクライアントモジュール310は、アクセストークンリダイレクト応答に対して認可エラーを示す画面（不図示）を返す。

図１０は図９のnonce値検証処理（S9.3）に対応した認可サーバー500におけるnonce値検証処理のフローチャートである。本フローチャートは認可サーバー500の認可サーバーモジュール510により、nonce値検証部630を用いて実行される。

まず、上述の引数として渡されたWeb-HostedクライアントのURIとnonce値を取得する（S10.1）。認可サーバーモジュール510は、表２のクライアント管理テーブルを参照して、取得したnonce値がクライアント管理テーブルのnonce値に存在するかどうかを確認する（S10.2）。nonce値が存在しなければ、認可サーバーモジュール510は、本処理の呼び出し元のWeb-Hostedクライアント300に対して失敗を返して処理を終了する（S10.5）。

一方、S10.2でnonce値が存在するならば、認可サーバーモジュール510はクライアント管理テーブルの、マッチしたnonce値に対応するリダイレクトURIを参照する。そして上記リダイレクトURIが、取得したWeb-HostedクライアントのURIにマッチするかどうか確認する（S10.3）。Web-HostedクライアントのURIにマッチしなければ、認可サーバーモジュール510は、本処理の呼び出し元のWeb-Hostedクライアント300に失敗を返し（S10.5）、処理を終了する。一方、Web-HostedクライアントのURIにマッチするならば、認可サーバーモジュール510は、呼び出し元のWeb-Hostedクライアント300に成功を返し（S10.4）、処理を終了する。

ここで図６のフローに戻る。以上のように、Web-Hostedクライアント300は、図９、１０によるWeb-Hostedクライアント処理を行い、nonce値検証に成功すると、アクセストークン取得スクリプト応答（S6.16）をクライアントPC200に返す。このようにして、Web-Hostedクライアント300、301、302が、正常なリダイレクトURIリクエスト（S6.12）以外の不正なリクエストを、nonce値を検証することで防止している。

上述のアクセストークン取得スクリプト応答（S6.16）に含まれるスクリプトは、一般にはWebブラウザー230で実行可能なJavascript（登録商標）であるが、その他ブラウザー上で実行可能なスクリプトであっても良い。アクセストークン取得スクリプトを受信したWebブラウザー230上で動作するクライアントスクリプト320は、当該スクリプトを実行することによりアクセストークンを取得する（S6.17）。これにより、リソースサーバー400にアクセスすることができる（S6.18）。

図１１は、アクセストークンを取得しリソースサーバーにアクセスするためのスクリプトのフローチャートである。Web-Hostedクライアントからスクリプトを受信したクライアントPC200上のWebブラウザー230が本処理を実行する。まずWebブラウザー230は、アクセストークン応答（S6.11）のリダイレクト先であるURIに紐付くquery string をパースし、フラグメントの値を取得する（S11.1）。本実施例のJavascript（登録商標）においては、例えばlocation.hash関数を用いて、Web-Hostedクライアント300にリダイレクトされたアクセストークン応答のフラグメントコンポーネントの値を取得する。さらに、取得したフラグメントコンポーネントに含まれるアクセストークンaccess_token=AT_000001を取得する（S11.2）。そして、本スクリプトの実行によりWebブラウザー230は、取得したアクセストークンを用いてリソースサーバー400にアクセスする（S11.3）。

図１１の処理により、Webブラウザー230上で動作するスクリプトは、S6.16、S6.17においてアクセストークン「AT_000001」、スコープ「リソースA」を受け取る。そして、リソースサーバー400に対してアクセストークン「AT_000001」、スコープ「リソースA」をリクエストパラメーターに含めてリソースアクセス要求を行う（S6.18）。また本リソースアクセス要求の際、先にWeb-Hostedクライアント300へのリダイレクトURIリクエスト（S6.12）のCookieに含まれたnonce値を、同様に本リソースアクセス要求に含まれるようにする。リソースアクセス要求を受信したリソースサーバー400は、認可サーバー500に対してnonce値検証要求を行ない（S6.19）、その応答を受信する（S6.21）。

図１２は、リソースサーバー400のnonce値検証処理（S6.20）に対応した認可サーバー500におけるnonce値検証処理のフローチャートである。本処理は認可サーバー500の認可サーバーモジュール510により、nonce値検証部630を用いて実行される。まず、認可サーバーモジュール510は、前述の引数として渡されたリソースサーバーのURIとnonce値を取得する（S12.1）。認可サーバーモジュール510は、表２のクライアント管理テーブルを参照し、取得したnonce値がクライアント管理テーブルのnonce値に存在するかどうかを確認する（S12.2）。nonce値が存在しなければ、認可サーバーモジュール510は、本処理の呼び出し元のWeb-Hostedクライアント300に対して失敗を返して（S12.5）、処理を終了する。一方、nonce値が存在するならば、S12.3の処理に進む。

S12.3において、認可サーバーモジュール510はクライアント管理テーブルの、マッチしたnonce値に対応するリダイレクトURIを参照し、さらに表５のクライアント、リソースサーバー管理テーブルを参照する。その結果により、リダイレクトURIに対応するリソースサーバーURIが取得したリソースサーバー400のURIにマッチするかどうかを確認する（S12.3）。リソースサーバーのURIにマッチしなければ、認可サーバーモジュール510は、本処理の呼び出し元のWeb-Hostedクライアント300に対して失敗を返し（S12.5）、処理を終了する。一方、Web-HostedクライアントのURIにマッチするならば、認可サーバーモジュール510は呼び出し元のリソースサーバー400に対して成功を返し（S12.4）、処理を終了する。

ここで図６のフローに戻る。アクセストークン情報「AT_000001」、スコープ「リソースA」を取得したリソースサーバー400は、取得した情報を元に要求を受け付けたリソースに対するアクセスを許可するか拒否するかを判断する。ここでは、リソースサーバー400に予めアクセス可能なアプリケーションIDが設定されているものとする。そして、その設定されているアプリケーションIDと、アクセストークン情報「AT_000001」から取得されたアプリケーションIDを比較することでアクセスを許可するかを検証する。この検証は、リソースサーバー400が認可サーバー500に対し、アクセストークン「AT_000001」、スコープ「リソースA」を引数にしてトークン情報を取得することで行われる（S6.22）。

認可サーバー500は、表３のトークン管理テーブルを参照し、取得したアクセストークン「AT_00001」の有効期間が切れていないこと、要求されているスコープ「リソースA」がスコープ範囲内であることを検証する。検証の結果、問題がなければ検証の成功を返す（S6.23）。この結果、アクセス許可と判断された場合は、リソースサーバー400は、Webブラウザー230に対して、リソースを応答する（S6.24）。ここで、リソースは例えば、リソースサーバー400が印刷サービスであった場合は印刷可能な文書のリストであり、帳票サービスであった場合は、作成可能な帳票のリストである。

なお、上述の実施例では、S6.22からS6.23までの処理を、トークンの検証を認可サーバー500、リソースサーバー400それぞれで行なうよう説明した。しかし、リソースに対するアクセス可能なアプリケーションを認可サーバー500で管理し、全ての検証を認可サーバー500で行うよう構成する事も可能である。また、本実施例ではアクセス可能なアプリケーションの判断をアプリケーションIDを用いて実施するよう説明した。しかし、トークン情報から取得できるシリアル番号やクライアントIDを元にクライアントPC200上のWebブラウザー230を識別し、アクセスの可否を判断するよう構成する事もできる。また、同様に、トークン情報から取得できるスコープやユーザーIDを元にアクセスの可否を判断するよう構成する事もできる。

リソース応答（S6.24）を受け付けたクライアントPC200上のWebブラウザー230は、受信したデータを元に前述のアプリケーション画面を構成し、リソースオーナー1000たるユーザーに応答する。

＜実施例２＞ （複数リダイレクトURIによるリソースサーバー非機能要件選択）
実施例１に示した方法では、非機能要件の異なるリソースサーバーを選択可能にするために必要なクライアント登録処理において、クライアント登録時に選択できるリダイレクトURIは一つであった。実施例２においては、クライアント登録時にクライアントIDに対して複数のリダイレクトURIを選択可能な方法を具体的に示す。

ここで、非機能要件の異なるリソースサーバーを選択可能にするために必要なクライアント登録処理を行うための、本実施例に係るクライアント登録フローを表すシーケンスについて図４、１３を用いて説明する。図４のクライアント登録フローは、OAuth2.0で一般的なOAuth2.0仕様におけるクライアント登録に関して、本実施例独自の拡張を加えたフローである。実施例２においても、図４に示すクライアント登録フロー自体は実施例１と同様である。

図４のフローにおいて、まず、クライアント登録者1001が、本実施例におけるリソースアクセスに必要なOAuth2.0仕様で言うところのクライアントについて、クライアント登録を行う。後述するリソースオーナー1000は、本フローにより事前登録されたクライアントを用いてリソースアクセスを行うことになる。クライアント登録者1001は、Webブラウザー230を用いて認可サーバー500に対してクライアント登録画面を要求する（S4.1）。認可サーバー500は、S4.1の要求に応じて図１３に示すようなクライアント登録画面を返す（S4.2）。

図１３はOAuth2.0仕様におけるクライアントについて登録を行うためのクライアント登録画面である。クライアント登録画面は、認可サーバー500がクライアント登録に必要なパラメーターを表示、選択するクライアント登録パラメーター表示13000と、以下の２つのボタンから成る。即ち、クライアント登録パラメーターを確定して認可サーバー500に登録するためのOKボタン13005と、クライアント登録パラメーター表示13000をキャンセルするキャンセルボタン13006である。

クライアント登録パラメーター表示13000は、クライアント名入力行13007と、クライアントID表示行13001と、リダイレクトURI選択行13002、13003、13004からなる。クライアントID表示行13001には、クライアント登録画面要求（S4.1）を受けた認可サーバー500が、クライアント登録画面返却（S4.2）時に、UUID形式のランダムかつユニークな値を生成して表示する。例えば、’9237ee87-1d58-4b0d-a7ed-a4042402df52’のような値である。クライアント名入力行13007にはクライアント登録者1001がクライアント登録時に任意のクライアント名を入力する。リダイレクトURI選択行13002、13003、13004には、本クライアント登録の際に有効となる、OAuth2.0仕様で言うところのリダイレクトURIの予め用意された選択肢を表示する。さらに、クライアント登録者1001が複数のリダイレクトURI選択肢の中から一つまたは複数を選択して認可サーバー500に登録するように、リダイレクトURI選択行の各行に複数選択可能なチェックボタンを表示し、一つまたは複数を選択可能とする。

リダイレクトURIの複数の選択行13002、13003、13004は、非機能要件の異なるリソースサーバー400、401、402にクライアントを誘導するためのリダイレクトURIである。このうち、13002のリダイレクトURIはリソースサーバー400にアクセスするためのURIである。同様に、13003のリダイレクトURIはリソースサーバー401にアクセスするためのリダイレクトURIであり、13004は402にアクセスするためのリダイレクトURIである。これらの関係は、表５に示すクライアント、リソースサーバー管理テーブルにより予め定義されている。

図４のフローに戻り、クライアント登録者1001は、S4.2にて認可サーバー500から返された図１３のクライアント登録画面を参照し、クライアント登録内容を入力する（S4.3）。具体的には、クライアントIDを確認して、リダイレクトURIを図１３の選択肢（リダイレクトURI13002〜13004）の中から一つまたは複数を、複数選択可能なチェックボタンを選択することにより選択して、OKボタン13005を押下する。クライアント登録者1001がOKボタン13005を押下すると、Webブラウザー230は、認可サーバー500に対してクライアント登録処理要求を送信する（S4.4）。

認可サーバー500はクライアント登録処理要求（S4.4）を受信したらクライアント登録処理を行う（S4.5）。具体的には、認可サーバー500の前記クライアント登録部620により、受信したクライアント登録処理要求（S4.4）からクライアント名とクライアントIDとリダイレクトURIを、認可サーバー500上のクライアント管理テーブル（表２）に登録する。認可サーバー500は、クライアント管理テーブルへのクライアント名、クライアントID、リダイレクトURIの登録が完了したら、登録内容（不図示）をWebブラウザー230に返却して処理を終了する（S4.6）。なお、本実施例ではクライアント登録者による認可サーバーへのクライアント登録処理についてWebブラウザーを用いた処理としているが、認可サーバーへの登録処理は専用登録アプリなどを用いても良い。

ここで、図１４を用いて、クライアントPC200上のブラウザープリケーションを用いてリソースサービスを利用するための、本実施例に係る認可フローを表すシーケンスについて説明する。OAuth2.0の仕様では、多様なクライアントに応じた複数のプロトコルシーケンスをgrant typeと呼ぶ。図１４の認可フローは、OAuth2.0仕様のimplicit grantに本実施例独自の拡張を加えたgrant typeである。なお、S14.2〜S14.22については、図６のS6.2〜S6.22と同様であるので説明を割愛する。

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

なお、本実施例では、上記アプリケーション画面でリソースサーバーの選択が可能である。選択可能なリソースサーバーとは、図１３に示したクライアント登録画面で選択した複数のリダイレクトURIに対応したリソースサーバーURIで示されるリソースサーバーである。

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

上述のように、本発明においては、Web-Hostedクライアントモジュール310、リソースサーバーモジュール410にてnonce値を確認する。このことにより、前記のような一連の処理に無関係なブラウザーなどに、アクセストークン取得スクリプト、リソース要求の応答をしないようにすることができる。これにより、例え前記のようなブラウザーなどでアクセストークンが詐取されたとしても、Web-Hostedクライアント300やリソースサーバー400へのアクセスがエラーとなり、詐取されたアクセストークンの使用を防止することができる。このようにして、リソースサーバー400への不正アクセスを防止することができる。

＜その他の実施例＞
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

200 クライアントPC
300 Web-Hostedクライアント
400 リソースサーバー
500 認可サーバー

Claims (13)

1. リソースを提供するリソースサーバーと、クライアントの認証及びリソースの認可を行なう認可サーバーと、クライアントと認可サーバーとの間の通信を媒介する媒介装置とを有する、ネットワークにおいて用いられる権限移譲システムであって、
   前記リソースサーバーは、保護されたリソースに対するクライアントからの要求に対し、クライアントの認証に用いられる認証識別子を前記クライアントに発行し、
   前記認可サーバーは、前記クライアントを識別する識別情報、前記リソースサーバーが発行した前記認証識別子、前記媒介装置の宛先を示す宛先情報を前記クライアントから受信し、前記認可サーバーに予め登録した情報に基づいて、前記クライアントを認証し、認証に成功した場合、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証に成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記媒介装置は、前記クライアントから前記宛先情報が示す宛先に前記認可サーバーが発行した前記証明情報が送られた場合、前記認証識別子と前記認可サーバーに予め登録した情報に基づいて、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証が成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記リソースサーバーは、前記媒介装置が発行した前記証明情報を前記クライアントから受信し、前記認証識別子に基づいて、前記クライアントからの前記要求を許可するかどうか検証し、検証に成功した場合、前記保護されたリソースを前記クライアントに提供し、
   前記認可サーバーは、同じリソースについて性能の異なる複数のリソースサーバーに対応する複数の媒介装置の宛先情報を予め登録し、そのうちのいずれかの宛先情報を前記クライアントにより選択可能とすることを特徴とする権限移譲システム。
2. 前記クライアントが前記複数のリソースサーバーのいずれかにアクセスする際に、前記複数の宛先情報に基づき当該リソースサーバーを選択することを可能とすることを特徴とする請求項１に記載の権限移譲システム。
3. 前記複数の宛先情報のうちのいずれか１つまたは複数を前記クライアントにより選択可能とすることを特徴とする、請求項１または２に記載の権限移譲システム。
4. リソースを提供するリソースサーバーと、クライアントの認証及びリソースの認可を行なう認可サーバーと、クライアントと認可サーバーとの間の通信を媒介する媒介装置とを有する、ネットワークにおいて用いられる権限移譲システムにおいて、
   前記リソースサーバーは、保護されたリソースに対するクライアントからの要求に対し、クライアントの認証に用いられる認証識別子を前記クライアントに発行し、
   前記認可サーバーは、前記クライアントを識別する識別情報、前記リソースサーバーが発行した前記認証識別子、前記媒介装置の宛先を示す宛先情報を前記クライアントから受信し、前記認可サーバーに予め登録した情報に基づいて、前記クライアントを認証し、認証に成功した場合、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証に成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記媒介装置は、前記クライアントから前記宛先情報が示す宛先に前記認可サーバーが発行した前記証明情報が送られた場合、前記認証識別子と前記認可サーバーに予め登録した情報に基づいて、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証が成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記リソースサーバーは、前記媒介装置が発行した前記証明情報を前記クライアントから受信し、前記認証識別子に基づいて、前記クライアントからの前記要求を許可するかどうか検証し、検証に成功した場合、前記保護されたリソースを前記クライアントに提供し、
   前記認可サーバーは、同じリソースについて性能の異なる複数のリソースサーバーに対応する複数の媒介装置の宛先情報を予め登録し、そのうちのいずれかの宛先情報を前記クライアントにより選択可能とすることを特徴とする認可サーバー。
5. リソースを提供するリソースサーバーと、クライアントの認証及びリソースの認可を行なう認可サーバーと、クライアントと認可サーバーとの間の通信を媒介する媒介装置とを有する、ネットワークにおいて用いられる権限移譲システムにおいて、
   前記リソースサーバーは、保護されたリソースに対するクライアントからの要求に対し、クライアントの認証に用いられる認証識別子を前記クライアントに発行し、
   前記認可サーバーは、前記クライアントを識別する識別情報、前記リソースサーバーが発行した前記認証識別子、前記媒介装置の宛先を示す宛先情報を前記クライアントから受信し、前記認可サーバーに予め登録した情報に基づいて、前記クライアントを認証し、認証に成功した場合、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証に成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記媒介装置は、前記クライアントから前記宛先情報が示す宛先に前記認可サーバーが発行した前記証明情報が送られた場合、前記認証識別子と前記認可サーバーに予め登録した情報に基づいて、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証が成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記認可サーバーは、同じリソースについて性能の異なる複数のリソースサーバーに対応する複数の媒介装置の宛先情報を予め登録し、そのうちのいずれかの宛先情報を前記クライアントにより選択可能とし、
   前記リソースサーバーは、前記媒介装置が発行した前記証明情報を前記クライアントから受信し、前記認証識別子に基づいて、前記クライアントからの前記要求を許可するかどうか検証し、検証に成功した場合、前記保護されたリソースを前記クライアントに提供することを特徴とするリソースサーバー。
6. リソースを提供するリソースサーバーと、クライアントの認証及びリソースの認可を行なう認可サーバーと、クライアントと認可サーバーとの間の通信を媒介する媒介装置とを有する、ネットワークにおいて用いられる権限移譲システムにおいて、
   前記クライアントは、保護されたリソースに対する要求を前記リソースサーバーに送信し、クライアントの認証に用いられる認証識別子を前記リソースサーバーから受信し、
   前記クライアントは、前記クライアントを識別する識別情報、前記リソースサーバーから受信した前記認証識別子、前記媒介装置の宛先を示す宛先情報を前記認可サーバーに送信し、前記クライアントが前記保護されたリソースに対して権限を有することを証明する証明情報を前記認可サーバーから受信し、
   前記クライアントは、前記媒介装置の前記宛先情報が示す宛先に前記認可サーバーから受信した前記証明情報を送信し、前記クライアントが前記保護されたリソースに対して権限を有することを証明する証明情報を前記媒介装置から受信し、
   前記クライアントは、前記媒介装置から受信した前記証明情報を前記リソースサーバーに送信し、前記保護されたリソースを前記リソースサーバーから受信し、
   前記クライアントは、同じリソースについて性能の異なる複数のリソースサーバーに対応して前記認可サーバーに予め登録される複数の媒介装置の宛先情報のうちのいずれかの宛先情報を選択可能であることを特徴とするクライアント。
7. リソースを提供するリソースサーバーと、クライアントの認証及びリソースの認可を行なう認可サーバーと、クライアントと認可サーバーとの間の通信を媒介する媒介装置とを有する、ネットワークにおいて用いられる権限移譲システムにおいて、
   前記リソースサーバーは、保護されたリソースに対するクライアントからの要求に対し、クライアントの認証に用いられる認証識別子を前記クライアントに発行し、
   前記認可サーバーは、前記クライアントを識別する識別情報、前記リソースサーバーが発行した前記認証識別子、前記媒介装置の宛先を示す宛先情報を前記クライアントから受信し、前記認可サーバーに予め登録した情報に基づいて、前記クライアントを認証し、認証に成功した場合、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証に成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記認可サーバーは、同じリソースについて性能の異なる複数のリソースサーバーに対応する複数の媒介装置の宛先情報を予め登録し、そのうちのいずれかの宛先情報を前記クライアントにより選択可能とし、
   前記媒介装置は、前記認可サーバーが発行した前記証明情報を前記クライアントから前記宛先情報が示す宛先に受信した場合、前記認証識別子と前記認可サーバーに予め登録した情報に基づいて、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証が成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記媒介装置は、前記媒介装置が発行した前記証明情報を前記クライアントから前記リソースサーバーに送信させ、前記保護されたリソースを前記リソースサーバーから前記クライアントに提供させることを特徴とする媒介装置。
8. リソースを提供するリソースサーバーと、クライアントの認証及びリソースの認可を行なう認可サーバーと、クライアントと認可サーバーとの間の通信を媒介する媒介装置とを有する、ネットワークにおいて用いられる権限移譲システムにおいて用いられる権限移譲方法であって、
   前記リソースサーバーにおいて、保護されたリソースに対するクライアントからの要求に対し、クライアントの認証に用いられる認証識別子を前記クライアントに発行し、
   前記認可サーバーにおいて、前記クライアントを識別する識別情報、前記リソースサーバーが発行した前記認証識別子、前記媒介装置の宛先を示す宛先情報を前記クライアントから受信し、前記認可サーバーに予め登録した情報に基づいて、前記クライアントを認証し、認証に成功した場合、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証に成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記媒介装置において、前記クライアントから前記宛先情報が示す宛先に前記認可サーバーが発行した前記証明情報が送られた場合、前記認証識別子と前記認可サーバーに予め登録した情報に基づいて、前記クライアントが前記保護されたリソースに対して権限を有するかどうか検証し、検証が成功した場合、権限を有することを証明する証明情報を前記クライアントに発行し、
   前記リソースサーバーにおいて、前記媒介装置が発行した前記証明情報を前記クライアントから受信し、前記認証識別子に基づいて、前記クライアントからの前記要求を許可するかどうか検証し、検証に成功した場合、前記保護されたリソースを前記クライアントに提供し、
   前記認可サーバーにおいて、同じリソースについて性能の異なる複数のリソースサーバーに対応する複数の媒介装置の宛先情報を予め登録し、そのうちのいずれかの宛先情報を 前記クライアントにより選択可能とすることを特徴とする権限移譲方法。
9. 請求項１〜３のいずれか１項に記載の権限移譲システムをコンピュータに実行させるためのプログラム。
10. 請求項４に記載の認可サーバーをコンピュータで実現させるためのプログラム。
11. 請求項５に記載のリソースサーバーをコンピュータで実現させるためのプログラム。
12. 請求項６に記載のクライアントをコンピュータで実現させるためのプログラム。
13. 請求項７に記載の媒介装置をコンピュータで実現させるためのプログラム。

Images