JP6937280B2 - 情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラム - Google Patents

Description

本発明の実施の形態は、情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラムに関する。

近年、クライアント側でウェブサービスを実現するためのブラウザアプリケーションが注目されている。このようなブラウザアプリケーションを用いたシステムにおいて、クライアントとサーバとの間の認証に、ＯＡｕｔｈ２．０（ＲＦＣ ６７４９）と称される標準プロトコルを用いる事が知られている。ＯＡｕｔｈ２．０には、インプリシットフロー（Ｉｍｐｌｉｃｔ Ｆｌｏｗ）と称される認可フローが定義されている。インプリシットフローは、認可サーバに認可リクエストを送信した応答として、直接アクセストークンを受け取るフローである。

しかし、インプリシットフローを用いたプロトコルでは、サーバ側で発行可能なアクセストークンの形式が持参式トークン（Ｂｅａｒｅｒ Ｔｏｋｅｎ）であり、アクセストークンの漏洩によるセキュリティ低下が問題であった。

特開２０１６−１１５２６０号公報

本発明が解決しようとする課題は、アクセストークンのセキュリティ向上を図ることができる、情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラムを提供することである。

実施形態の情報処理装置は、クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する。情報処理装置は、受信部と、送信部と、発行部と、を備える。受信部は、前記クライアントに対して発行されたｎｏｎｃｅと、前記クライアントが生成した第１公開鍵と、前記ｎｏｎｃｅを含むクライアント情報に対する第１署名と、を含む前記トークン発行要求を前記クライアントから受信する。送信部は、前記トークン発行要求に含まれる前記第１署名の前記第１公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第１識別情報を含むログイン要求を前記クライアントへ送信する。発行部は、前記クライアントを利用するユーザの認証情報および前記第１識別情報を含む認可許諾要求を前記クライアントから受信したときに、前記第１公開鍵を用いて生成した記名式トークンを前記アクセストークンとして発行する。

情報処理システムの模式図。 情報処理のシーケンス図。 情報処理システムの模式図。 情報処理のシーケンス図。 ハードウェア構成図。

以下に添付図面を参照して、情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラムを詳細に説明する。

（第１の実施の形態）
図１は、本実施の形態の情報処理システム１の一例を示す模式図である。

情報処理システム１は、情報処理装置１０と、クライアント端末１２と、サービス提供装置１４と、リソース提供装置１６と、を備える。情報処理装置１０と、クライアント端末１２と、サービス提供装置１４と、リソース提供装置１６とはネットワーク１８を介して通信可能に接続されている。情報処理システム１は、１または複数のクライアント端末１２と、１または複数のサービス提供装置１４と、１または複数のリソース提供装置１６と、１または複数の情報処理装置１０と、を備えた構成であればよい。

情報処理装置１０は、ＯＡｕｔｈにおける認可サーバとして機能する。

クライアント端末１２は、ユーザが操作する端末装置である。クライアント端末１２は、クライアント端末１２上のウェブブラウザ１２Ｂでクライアントスクリプトを実行し、リソース提供装置１６で提供されるリソースを利用する。リソースは、例えば、印刷サービスや帳票サービスなどを実行するためのリソースアプリケーションである。

サービス提供装置１４は、ＯＡｕｔｈにおける、Ｗｅｂ上にホストされ、ウェブブラウザ上で実行されるクライアント（Ｃｌｉｅｎｔ）である。

リソース提供装置１６は、ＯＡｕｔｈにおける、ウェブ上にホストされたクライアントプログラムが実装されたリソースサーバ（Ｒｅｓｏｕｒｃｅ Ｓｅｒｖｅｒ）である。リソース提供装置１６は、クライアント端末１２からのリソースリクエストに応じて、クライアント端末１２へリソースを提供する。

次に、情報処理システム１を構成する各装置の機能的構成を詳細に説明する。

クライアント端末１２は、通信部１２Ａと、ウェブブラウザ１２Ｂと、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１２Ｅと、を備える。通信部１２Ａは、ネットワーク１８を介して他の装置とデータを通信する。

クライアント端末１２では、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）がＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）や外部メモリなどに記憶されたＯＳ１２Ｅを実行することで、各アプリケーションを制御する。ＯＳ１２Ｅは、例えば、リアルタイムＯＳや、Ｌｉｎｕｘ（登録商標）等の汎用ＯＳである。

ウェブブラウザ１２Ｂは、ＷＷＷ（ｗｏｒｌｄ ｗｉｄｅ ｗｅｂ）を利用するためのユーザーエージェントである。ウェブブラウザ１２Ｂは、サービス提供ページ１２Ｃおよび認証ページ１２Ｄを、それぞれサービス提供装置、情報処理装置から読み込んで実行する。

サービス提供ページ１２Ｃは、サービス提供装置１４から提供されたウェブサイトのページであり、ＯＡｕｔｈ Ｃｌｉｅｎｔの実体である。

本実施の形態では、サービス提供ページ１２Ｃは、クライアント端末１２毎に、オリジン（Ｗｅｂサイトの提供元を識別するプロトコル、ホスト、ポート番号の組み合わせ。ここではサービス提供装置）ごとに第１公開鍵と第１秘密鍵とのペアを生成する。第１公開鍵と第１秘密鍵とのペアの生成には、公知の方法を用いればよい。例えば、サービス提供ページ１２Ｃは、Ｗ３Ｃ Ｗｅｂ Ｃｒｙｐｔｏｇｒａｐｈｙ ＡＰＩを用いて、第１公開鍵と第１秘密鍵とのペアを生成する。

また、サービス提供ページ１２Ｃは、トークン発行要求を情報処理装置１０へ送信する。トークン発行要求は、ＯＡｕｔｈ２．０の認可リクエストに相当する。但し、本実施の形態では、トークン発行要求は、記名式トークンの発行要求である。記名式トークンは、ＰｏＰ（Ｐｒｏｏｆ−ｏｆ−Ｐｏｓｓｅｓｓｉｏｎ）トークンと称される場合がある。

具体的には、本実施の形態では、トークン発行要求は、クライアント端末１２に対して情報処理装置１０から発行されたｎｏｎｃｅ（ｎｕｍｂｅｒ ｕｓｅｄ ｏｎｃｅ）と、第１公開鍵と、ｎｏｎｃｅを含むクライアント情報に対する第１署名と、を含む。また、トークン発行要求は、記名式トークンの発行要求を示す情報を含む。

ｎｏｎｃｅは、１回のみ用いられる、ランダム生成された数値または文字列である。

サービス提供ページ１２Ｃは、情報処理装置１０からｎｏｎｃｅを取得することで、ｎｏｎｃｅを含むトークン発行要求を情報処理装置１０へ送信してもよい。また、サービス提供ページ１２Ｃは、ｎｏｎｃｅの記憶場所を示す情報を情報処理装置１０から受信し、該記憶場所へアクセスすることで、ｎｏｎｃｅを取得してもよい。

サービス提供ページ１２Ｃは、取得したｎｏｎｃｅに第１秘密鍵を用いて第１署名を付与する。第１署名は、ｎｏｎｃｅ、あるいは、ｎｏｎｃｅに第１公開鍵などのクライアント情報を合わせたデータに対する署名である。第１秘密鍵を用いたｎｏｎｃｅへの第１署名の付与には、公知の方法を用いればよい。なお、ｎｏｎｃｅ単体ではなく、第１公開鍵などのクライアント情報にｎｏｎｃｅを合わせたデータに署名を付与するように構成してもよい。

また、サービス提供ページ１２Ｃは、情報処理装置１０への上記トークン発行要求の送信に対する応答として、情報処理装置１０からアクセストークン応答情報を受信する。

アクセストークン応答情報は、情報処理装置１０で発行されたアクセストークンの特定情報を含む。アクセストークン特定情報は、アクセストークンを一意に特定可能な情報であればよい。特定情報は、例えば、情報処理装置１０からクライアント端末１２に対して発行されたアクセストークン、該アクセストークンの記憶場所を示す情報、該アクセストークンの識別情報（第３識別情報）、などである。本実施の形態では、特定情報がアクセストークンである場合を一例として説明する。

サービス提供ページ１２Ｃは、情報処理装置１０から受信したアクセストークン応答情報に含まれるアクセストークンを、第１公開鍵に対応付けて記憶する。

そして、サービス提供ページ１２Ｃは、受信したアクセストークンを含むリソースリクエストを、リソース提供装置１６へ送信する。本実施の形態では、サービス提供ページ１２Ｃは、リソース提供装置１６で発行されたｎｏｎｃｅと、情報処理装置１０から受信したアクセストークンと、を含むリソースリクエストをリソース提供装置１６へ送信する。

該アクセストークンがリソース提供装置１６で検証され、検証が成功すると、リソース提供装置１６からサービス提供ページ１２Ｃへリソースが提供される。

認証ページ１２Ｄは、情報処理装置１０が、サービス提供ページ１２Ｃが情報処理装置１０へ送信したトークン発行要求の結果、表示されるＷｅｂページである。ログイン要求は、具体的には、認証ページ１２Ｄへのリダイレクト要求であり、この認証ページ１２ＤへのリダイレクトＵＲＬには、トークン発行要求の第１識別情報が含まれる。第１識別情報の詳細は後述する。

認証ページ１２Ｄは、情報処理装置１０からのリダイレクトの結果、ウェブブラウザ１２Ｂ上に読み込まれ、情報処理装置１０へログインするための認証画面を表示する。ユーザは、認証画面を参照しながらクライアント端末１２を操作することで、認証情報を入力する。認証情報は、例えば、ログインに用いるユーザＩＤおよびパスワード、ログイン認証後に払い出されるセッションＩＤ、などである。ユーザＩＤは、ユーザの識別情報である。

そして、認証ページ１２Ｄは、入力された認証情報（ユーザＩＤ、パスワード）と、トークン発行要求の第１識別情報と、を含む認可許諾要求を情報処理装置１０へ送信する。

次に、情報処理装置１０の機能的構成を説明する。

情報処理装置１０は、クライアントから受信したトークン発行要求に対する応答として、アクセストークンを発行する。すなわち、情報処理装置１０は、ＯＡｕｔｈ ２．０のインプリシットフローと同様に、受信したトークン発行要求に対する応答として、直接、アクセストークンを該トークン発行要求の送信元のクライアントへ返信する。

なお、クライアントとは、クライアント端末１２およびクライアント端末１２にインストールされたウェブブラウザ１２Ｂ上に読み込まれたサービス提供ページ１２Ｃを示す。本実施の形態では、クライアントを、クライアント端末１２と称して説明する。

情報処理装置１０は、受信部１０Ａと、送信部１０Ｂと、ｎｏｎｃｅ発行部１０Ｃと、署名検証部１０Ｄと、発行部１０Ｅと、を備える。

受信部１０Ａ、送信部１０Ｂ、ｎｏｎｃｅ発行部１０Ｃ、署名検証部１０Ｄ、および発行部１０Ｅは、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。これらの各部は、専用のＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち１つを実現してもよいし、各部のうち２以上を実現してもよい。

受信部１０Ａは、他の装置（クライアント端末１２、サービス提供装置１４、リソース提供装置１６）から各種情報を受信する。本実施の形態では、受信部１０Ａは、クライアント端末１２に対して発行したｎｏｎｃｅと、クライアント端末１２が生成した第１公開鍵と、ｎｏｎｃｅ（あるいは、ｎｏｎｃｅに第1公開鍵などクライアント情報を合わせたデータ）に対する第１署名と、を含むトークン発行要求を、クライアント端末１２から受信する。上述したように、本実施の形態では、このトークン発行要求は、記名式トークンの発行要求である。

ｎｏｎｃｅ発行部１０Ｃは、クライアント端末１２に対してｎｏｎｃｅを発行する。ｎｏｎｃｅ発行部１０Ｃは、乱数生成器などを用いて乱数を生成し、生成した乱数を、クライアント端末１２に対するｎｏｎｃｅとして発行する。

送信部１０Ｂは、他の装置（クライアント端末１２、サービス提供装置１４、リソース提供装置１６）へ各種情報を送信する。本実施の形態では、送信部１０Ｂは、ｎｏｎｃｅを示すｎｏｎｃｅ情報を、サービス提供ページ１２Ｃへ送信する。ｎｏｎｃｅ情報は、ｎｏｎｃｅ、ｎｏｎｃｅの識別情報、または、ｎｏｎｃｅの記憶場所を示す情報である。本実施の形態では、ｎｏｎｃｅ情報は、ｎｏｎｃｅ発行部１０Ｃで発行したｎｏｎｃｅである場合を一例として説明する。

署名検証部１０Ｄは、サービス提供ページ１２Ｃから受信したトークン発行要求に含まれる第１署名を、該トークン発行要求に含まれる第１公開鍵を用いて検証する。すなわち、署名検証部１０Ｄは、第１公開鍵に対応する秘密鍵で署名されているか否か、署名対象データが換算されていないか否かを、第１公開鍵を用いて検証する。第１署名の検証には、公知の方法を用いればよい。

送信部１０Ｂは、サービス提供ページ１２Ｃから受信したトークン発行要求に含まれる第１署名の第１公開鍵を用いた検証結果が成功を示す場合、ログイン要求を認証ページ１２Ｄへ送信する。検証結果が成功を示す、とは、署名検証部１０Ｄによる検証によって、第１署名の対象データが非改竄であり、かつ、第１公開鍵に対応する秘密鍵で署名されていると検証されたことを示す。

ログイン要求は、クライアント端末１２を操作するユーザに対する、明示的な認可操作を促す要求である。ログイン要求は、上述したように、トークン発行要求の第１識別情報を含む。具体的には、ログイン要求は、リダイレクト応答（例えば、３０２ Ｆｏｕｎｄ応答）であり、リダイレクト先を示すＬｏｃａｔｉｏｎヘッダ値（ＵＲＬ）に、第１識別情報が含まれる。なお、便宜上「ログイン要求」としているが、実質は認可要求であり、認証画面に表示されるのは、サービス提供装置（クライアント）からリソース提供装置上のリソースへのアクセス認可を促す画面である。リダイレクトされた時点で、すでにログイン済みであれば、ログインＩＤ、パスワードを入力するログインインタフェースを表示する必要はなく、単に、認可を求める画面が表示される。

第１識別情報は、サービス提供ページ１２Ｃから受信した、第１公開鍵、第１署名、およびｎｏｎｃｅを含むトークン発行要求と、認証ページ１２Ｄから受信した認証情報（ユーザＩＤ、パスワード）（あるいは、すでにログイン済みであれば、ログインセッション情報）と、を対応付けるための識別情報であればよい。例えば、第１識別情報は、ｎｏｎｃｅ発行部１０Ｃがクライアント端末１２に対して発行したｎｏｎｃｅ、該ｎｏｎｃｅを識別する第２識別情報、または、サービス提供ページ１２Ｃから受信したトークン発行要求のセッション識別情報、などである。

発行部１０Ｅは、クライアントを利用するユーザの認証情報および第１識別情報を含む認可許諾要求をクライアントから受信したときに、第１公開鍵を用いて生成した記名式トークンを、該クライアントに対するアクセストークンとして発行する。

すなわち、発行部１０Ｅは、クライアント端末１２で生成された第１公開鍵を用いて記名式トークンを生成することで、クライアント端末１２でのみ使用可能なアクセストークンを発行する。

そして、発行部１０Ｅは、発行したアクセストークンに、情報処理装置１０による発行を証明するための証明書を用いて、生成した記名式トークンに第２署名を付与し、第２署名付きのアクセストークンを発行する。なお、この証明書には、情報処理装置１０で予め生成した第２公開鍵を用いればよい。

情報処理装置１０は、第２公開鍵と第２秘密鍵とのペアを予め生成すればよい。これらの第２公開鍵と第２秘密鍵とのペアの生成には、公知の方法を用いればよい。

なお、第２署名の付与時に、発行部１０Ｅは、生成した記名式トークンのハッシュ値に第２署名を付与することで、第２署名付きのアクセストークンを発行してもよい。

発行部１０Ｅは、クライアント端末１２用に発行したアクセストークンと、クライアント端末１２の識別に用いるための第１公開鍵と、クライアント端末１２から受信した認証情報（ログインＩＤとパスワード、あるいは、ログインの結果払い出されるセッションＩＤ）と、を対応付けて記憶する。そして、発行部１０Ｅは、送信部１０Ｂを介してサービス提供ページ１２Ｃへ、クライアント端末１２用に発行したアクセストークンの特定情報を含むアクセストークン応答情報を、クライアント端末１２へ送信する。

次に、リソース提供装置１６の機能的構成を説明する。

リソース提供装置１６は、通信部１６Ａと、ｎｏｎｃｅ発行部１６Ｂと、アクセストークン検証部１６Ｃと、応答部１６Ｄと、を備える。

通信部１６Ａ、ｎｏｎｃｅ発行部１６Ｂ、アクセストークン検証部１６Ｃ、および応答部１６Ｄは、ＣＰＵなどのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。これらの各部は、専用のＩＣなどのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち１つを実現してもよいし、各部のうち２以上を実現してもよい。

通信部１６Ａは、ネットワーク１８を介して他の装置（クライアント端末１２、サービス提供装置１４、リソース提供装置１６、情報処理装置１０）と通信する。

ｎｏｎｃｅ発行部１６Ｂは、ｎｏｎｃｅを発行する。ｎｏｎｃｅ発行部１６Ｂは、情報処理装置１０のｎｏｎｃｅ発行部１０Ｃと同様にしてｎｏｎｃｅを発行する。但し、ｎｏｎｃｅ発行部１６Ｂは、情報処理装置１０と連動することなく、一意の乱数を発行し、ｎｏｎｃｅとして用いる。

アクセストークン検証部１６Ｃは、クライアント端末１２から通信部１６Ａを介して受信したリソースリクエストに含まれるアクセストークンを検証する。例えば、アクセストークン検証部１６Ｃは、ｎｏｎｃｅ発行部１６Ｂで発行したｎｏｎｃｅと、情報処理装置１０がクライアント端末１２用に発行したアクセストークンと、を含むリソースリクエストを、通信部１６Ａを介して受信する。そして、アクセストークン検証部１６Ｃは、該リソースリクエストに含まれるアクセストークンが、該アクセストークンの送信元のクライアント端末１２に発行されたものであるか否かを、情報処理装置１０に問い合わせる（具体的には、トークン検証エンドポイントに、アクセストークンを送信し、有効か否かを判定する）。情報処理装置１０に、該アクセストークンと該クライアント端末１２の認証情報または第１公開鍵が対応付けて記憶されている場合、かつ、トークンの有効期限が切れておらず、トークンがリボーク（無効化）されていない場合、リソース提供装置１６は、該アクセストークンがクライアント端末１２に発行されたものであるし、検証成功と判断する。

アクセストークン検証部１６Ｃが検証成功と判断すると、応答部１６Ｄは、サービス提供ページ１２Ｃへリソースを提供する。

次に、情報処理システム１で実行される情報処理の手順の一例を説明する。

図２は、情報処理システム１で実行される情報処理の手順の一例を示す、シーケンス図である。

まず、情報処理装置１０が、第２公開鍵と第２秘密鍵とのペアを生成する（ステップＳ１００）。一方、クライアント端末１２のサービス提供ページ１２Ｃは、第１公開鍵と第１秘密鍵とのペアを生成する（ステップＳ１０２）。

次に、サービス提供ページ１２Ｃは、トークン発行要求を情報処理装置１０へ送信する（ステップＳ１０４）。本実施の形態では、サービス提供ページ１２Ｃは、記名式トークンの発行要求を示す、トークン発行要求を情報処理装置１０へ送信する。ステップＳ１０４のトークン発行要求は、例えば、“ＰＯＳＴ ／ａｕｔｈｏｒｉｚｅｒｅｓｐｏｎｓｅ＿ｔｙｐｅ＝ｔｏｋｅｎ＆ｃｌｉｅｎｔ＿ｉｄ＝ｘ＆ｔｏｋｅｎ＿ｔｙｐｅ＝ｐｏｐ＆ｒｅｄｉｒｅｃｔ＿ｕｒｉ＝ｈｔｔｐｓ：／／ｒｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｂ”と表される。

ステップＳ１０４で、サービス提供ページ１２Ｃからトークン発行要求を受信した情報処理装置１０のｎｏｎｃｅ発行部１０Ｃは、クライアント端末１２に対するｎｏｎｃｅを発行する（ステップＳ１０６）。

そして、ｎｏｎｃｅ発行部１０Ｃは、ステップＳ１０６で発行したｎｏｎｃｅを示すｎｏｎｃｅ情報を、送信部１０Ｂを介してサービス提供ページ１２Ｃへ送信する（ステップＳ１０８）。具体的には、ｎｏｎｃｅ発行部１０Ｃは、応答ヘッダにｎｏｎｃｅを含む“４０１ Ｕｎａｕｔｈｏｒｉｚｅｄｎｏｎｃｅ”応答を、サービス提供ページ１２Ｃへ送信する。

ｎｏｎｃｅ情報は、ステップＳ１０６で発行したｎｏｎｃｅを示す情報であればよい。具体的には、ｎｏｎｃｅ情報は、ｎｏｎｃｅ、ｎｏｎｃｅの識別情報、またはｎｏｎｃｅの記憶場所を示す情報である。本実施の形態では、ｎｏｎｃｅ情報が、ｎｏｎｃｅである場合を一例として説明する。

クライアント端末１２のサービス提供ページ１２Ｃは、情報処理装置１０から受信したｎｏｎｃｅに第１秘密鍵を用いて第１署名を付与する（ステップＳ１１０）。なお、署名は、ｎｏｎｃｅのみを対象にする必要はなく、第１公開鍵などクライアント情報を含めたデータを署名対象としてもよい。

そして、クライアント端末１２のサービス提供ページ１２Ｃは、第１公開鍵と、ステップＳ１０８で受信したｎｏｎｃｅと、ステップＳ１１０で付与した第１署名と、を含むトークン発行要求を、情報処理装置１０へ送信する（ステップＳ１１２）。

ステップＳ１１２で送信するトークン発行要求は、例えば、“ＰＯＳＴ ／ａｕｔｈｏｒｉｚｅ？ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ＝ｔｏｋｅｎ＆ｃｌｉｅｎｔ＿ｉｄ＝ｘ＆ｔｏｋｅｎ＿ｔｙｐｅ＝ｐｏｐ＆ａｌｇ＝ＲＳ２５６＆ｋｅｙ＝ＫＲｐｕｂ＆ｒｅｄｉｒｅｃｔ＿ｕｒｉ＝ｈｔｔｐｓ：／／ｒｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｂ”と表される。ＲＳ２５６は、第１署名を示す。ＫＲｐｕｂは、第１公開鍵を示す。ｐｏｐは、記名式トークンの発行要求を示す。

情報処理装置１０の署名検証部１０Ｄは、ステップＳ１１２でクライアント端末１２の認証ページ１２Ｄから受信したトークン発行要求に含まれる第１署名を、該トークン発行要求に含まれる第１公開鍵を用いて検証する（ステップＳ１１４）。ここでは、検証成功したとして、説明を続ける。

そして、情報処理装置１０の送信部１０Ｂは、第１識別情報を含むログイン要求を、クライアント端末１２の認証ページ１２Ｄへ送信する（ステップＳ１１６）。ステップＳ１１６では、送信部１０Ｂは、ステップＳ１０６で発行したｎｏｎｃｅ、該ｎｏｎｃｅの第２識別情報、ステップＳ１０４およびステップＳ１１２で受信したトーク発行要求の少なくとも一方の通信セッション識別情報、の何れかを、第１識別情報として用いる。

ログイン要求は、例えば、“３０２ Ｆｏｕｎｄ”応答、すなわち、リダイレクト応答として表される。Ｌｏｃａｔｉｏｎヘッダに、認可画面のＵＲＬが含まれる。

ログイン要求を受信したクライアント端末１２の認証ページ１２Ｄは、情報処理装置１０へログインするための認証画面を表示する（ステップＳ１１８）。クライアント端末１２を操作するユーザは、認証画面を参照しながらクライアント端末１２を操作することで、認証情報（ユーザＩＤ、パスワード）を入力する。なお、前述の通り、既にログインが行われている場合、認証情報の入力はスキップされ、サービス提供装置からリソース提供装置上のリソースへのアクセス認可を促すインタフェースのみが表示される（これはＯＡｕｔｈの認可画面における一般的な実装である）。

そして、クライアント端末１２の認証ページ１２Ｄは、入力された認証情報（ユーザＩＤ、パスワード、あるいは、認証後に発行されるセッションＩＤ）と、ステップＳ１１６で受信したログイン要求に含まれる第１識別情報と、を含む認可許諾要求を、情報処理装置１０へ送信する（ステップＳ１２０）。

認可許諾要求は、例えば、“ＰＯＳＴ ／ｇｒａｎｔ”と表される。

情報処理装置１０の発行部１０Ｅは、認可許諾要求を受信すると、認可許諾要求に含まれる認証情報が、情報処理装置１０に予め登録されているか否かを判別することで、クライアント端末１２を操作するユーザの情報処理装置１０へのログインを許可するか否かを判断する。ここでは、許可すると判断したと想定し、説明を続ける。

そして、情報処理装置１０の発行部１０Ｅは、ステップＳ１１２で受信したトークン発行要求に含まれる第１公開鍵を用いて記名式トークンを生成することで、クライアント端末１２に対するアクセストークンを発行する（ステップＳ１２２）。

次に、発行部１０Ｅは、ステップＳ１２２で発行したアクセストークンに、ステップＳ１００で生成した第２秘密鍵を用いて第２署名を付与する（ステップＳ１２４）。

そして、発行部１０Ｅは、クライアント端末１２用に発行したアクセストークンと、クライアント端末１２の識別に用いるための第１公開鍵と、クライアント端末１２から受信した認証情報（ログインＩＤとパスワード）と、を対応付けて記憶する（ステップＳ１２６）。

情報処理装置１０の送信部１０Ｂは、ステップＳ１２２およびステップＳ１２４で発行した、第２署名の付与されたアクセストークンを含むアクセストークン応答情報を、クライアント端末１２へ送信する（ステップＳ１２８）。

アクセストークン応答情報は、例えば、“３０２ Ｆｏｕｎｄ”リダイレクト応答であり、Ｌｏｃａｔｉｏｎヘッダの値は、ｈｔｔｐｓ：／／ｒｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｂ＃ａｃｃｅｓｓ＿ｔｏｋｅｎ＝ＰｏＰＴｏｋｅｎと表される。ｒｐ．ｅｘａｍｐｌｅ．ｃｏｍは、サービス提供装置１４のホストを示す。ＰｏＰＴｏｋｅｎは、第２署名の付与されたアクセストークンを示す。

クライアント端末１２のサービス提供ページ１２Ｃは、ステップＳ１２８で受信したアクセストークン応答情報に含まれる、アクセストークンの特定情報によって特定されるアクセストークンと、第１公開鍵と、を対応付けて記憶する（ステップＳ１３０）。ステップＳ１３０で記憶するアクセストークンは、ステップＳ１２２の処理によって情報処理装置１０によって発行され、ステップＳ１２４の処理によって第２署名の付与されたアクセストークンである。

次に、クライアント端末１２のサービス提供ページ１２Ｃは、ステップＳ１３０で記憶した、第２署名付きのアクセストークンを含むリソースリクエストを、リソース提供装置１６へ送信する（ステップＳ１３２）。

ステップＳ１３２のリソースリクエストは、例えば、“ＧＥＴ ／ｓｏｍｅ−ｒｅｓｏｕｒｃｅ”と表される。

ステップＳ１３２でリソースリクエストを受信したリソース提供装置１６のｎｏｎｃｅ発行部１６Ｂは、クライアント端末１２用のｎｏｎｃｅを発行する（ステップＳ１３４）。そして、ｎｏｎｃｅ発行部１６Ｂは、ステップＳ１３４で発行したｎｏｎｃｅを示すｎｏｎｃｅ情報を、クライアント端末１２へ送信する（ステップＳ１３６）。ステップＳ１３６のｎｏｎｃｅ情報は、例えば、“４０１ Ｕｎａｕｔｈｏｒｉｚｅｄ”エラー応答のヘッダに設定される。本実施の形態では、ｎｏｎｃｅ発行部１６Ｂは、ｎｏｎｃｅをクライアント端末１２へ送信する場合を一例として説明する。

ステップＳ１３６でｎｏｎｃｅを受信したクライアント端末１２のサービス提供ページ１２Ｃは、ステップＳ１３０で記憶した、第２署名付きのアクセストークンと、ステップＳ１３６で受信したｎｏｎｃｅと、を含むリソースリクエストを、リソース提供装置１６へ送信する（ステップＳ１３８）。

ステップＳ１３８のリソースリクエストは、例えば、“ＧＥＴ ／ｓｏｍｅ−ｒｅｓｏｕｒｃｅ”となる。署名付きのアクセストークンとｎｏｎｃｅは、Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダに指定され、例えば、”Ａｕｔｈｏｒｉｚａｔｉｏｎ： Ｊｐｏｐ ａｔ＝“ＪＷＳ”，ｓ＝“ｎｏｎｃｅ””と表される。ＪＷＳは、署名付きアクセストークンを示す。

リソース提供装置１６のアクセストークン検証部１６Ｃは、ステップＳ１３８で受信したリソースリクエストに含まれる、第２署名付きのアクセストークン検証する（ステップＳ１４０、ステップＳ１４２）。このとき、アクセストークン検証部１６Ｃは、該第２署名によって証明される情報処理装置１０が発行したアクセストークンであるか否かを、情報処理装置１０に問い合わせることで、該アクセストークンを検証する。ここでは、検証成功と判断したものと想定し、説明を続ける。

次に、リソース提供装置１６の応答部１６Ｄは、サービス提供ページ１２Ｃへリソースを提供する（ステップＳ１４４）。例えば、応答部１６Ｄは、“２００ ＯＫ”をサービス提供ページ１２Ｃへ送信する。

以上説明したように、本実施の形態の情報処理装置１０は、クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する。情報処理装置１０は、受信部１０Ａと、送信部１０Ｂと、発行部１０Ｅと、を備える。受信部１０Ａは、クライアントに対して発行されたｎｏｎｃｅと、クライアントが生成した第１公開鍵と、ｎｏｎｃｅを含むクライアント情報に対する第１署名と、を含むトークン発行要求をクライアントから受信する。送信部１０Ｂは、トークン発行要求に含まれる第１署名の第１公開鍵を用いた検証結果が成功を示す場合、トークン発行要求の第１識別情報を含むログイン要求を前記クライアントへ送信する。発行部１０Ｅは、クライアントを利用するユーザの認証情報および第１識別情報を含む認可許諾要求をクライアントから受信したときに、第１公開鍵を用いて生成した記名式トークンをアクセストークンとして発行する。

このように、本実施の形態の情報処理装置１０は、クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する。このため、情報処理装置１０は、ＯＡｕｔｈ２．０で定義されているインプリシットフローと称されるフローに沿った認可フローを実行する。但し、情報処理装置１０では、クライアントの認証情報および第１識別情報を含む認可許諾要求をクライアントから受信したときに、クライアントが生成した第１公開鍵を用いて記名式トークンを生成し、該記名式トークンをアクセストークンとして発行する。

このため、本実施の形態の情報処理装置１０は、クライアントでのみ利用可能な記名式トークンを生成することで、セキュリティの高いアクセストークンを発行することができる。

従って、本実施の形態の情報処理装置１０は、アクセストークンのセキュリティ向上を図ることができる。

また、本実施の形態の情報処理装置１０は、クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する。すなわち、情報処理装置１０は、ＯＡｕｔｈ２．０で定義されているインプリシットフローと称されるフローに沿った認可フローを実行する。このため、情報処理装置１０は、シンプルな通信方式で、クライアント端末１２に対してリソースへアクセスするためのアクセストークンを発行することができる。

（第２の実施の形態）
本実施の形態では、リソース提供装置がアクセストークンの生成およびアクセストークへの署名の付与の少なくとも一方を行う場合を説明する。

図３は、本実施の形態の情報処理システム１Ａの一例を示す模式図である。なお、上記実施の形態と同じ機能および構成については、同じ符号を付与し、詳細な説明を省略する。

情報処理システム１Ａは、情報処理装置１１と、クライアント端末１２と、サービス提供装置１４と、リソース提供装置１７と、を備える。クライアント端末１２およびサービス提供装置１４は、第１の実施の形態と同様である。情報処理装置１１と、クライアント端末１２と、サービス提供装置１４と、リソース提供装置１７と、はネットワーク１８を介して通信可能に接続されている。情報処理システム１Ａは、１または複数のクライアント端末１２と、１または複数のサービス提供装置１４と、１または複数のリソース提供装置１７と、１または複数の情報処理装置１１と、を備えた構成であればよい。

情報処理装置１１は、第１の実施の形態の情報処理装置１０と同様に、ＯＡｕｔｈを実現するためのサーバであり、認可サーバとして機能する。情報処理装置１１は、第１の実施の形態の情報処理装置１０と同様に、クライアントから受信したトークン発行要求に対する応答として、アクセストークンを発行する。すなわち、情報処理装置１１は、ＯＡｕｔｈ ２．０のインプリシットフローと同様に、受信したトークン発行要求に対する応答として、直接、アクセストークンを該トークン発行要求の送信元のクライアントへ返信する。

情報処理装置１１は、受信部１０Ａと、送信部１０Ｂと、ｎｏｎｃｅ発行部１０Ｃと、署名検証部１０Ｄと、アクセス検証部１１Ｅと、発行部１１Ｆと、を備える。受信部１０Ａ、送信部１０Ｂ、ｎｏｎｃｅ発行部１０Ｃ、および署名検証部１０Ｄは、第１の実施の形態と同様である。

アクセス検証部１１Ｅは、クライアント端末１２によるリソース提供要求対象のリソース提供装置１７の第３識別情報を含むトークン発行要求を受信したときに、トークン発行要求の送信元のクライアントが第３識別情報によって識別されるリソース提供装置１７へのアクセス権を有するか否かを検証する。

詳細には、本実施の形態では、受信部１０Ａは、クライアント端末１２で生成された第１公開鍵と、クライアント端末１２で付与された第１署名と、情報処理装置１１がクライアント端末１２に対して発行したｎｏｎｃｅと、第３識別情報と、を含むトークン発行要求を受信する。

第３識別情報は、クライアント端末１２によるリソース提供要求対象のリソース提供装置１７の識別情報である。言い換えると、第３識別情報は、クライアント端末１２がリソース提供を要求する、リソース提供装置１７の識別情報である。

アクセス検証部１１Ｅは、情報処理システム１Ａに含まれるリソース提供装置１７の各々ごとに、アクセスを許可するクライアント端末１２の識別情報を予め記憶すればよい。クライアント端末１２の識別情報には、例えば、クライアント端末１２で生成された第１公開鍵を用いればよい。すなわち、アクセス検証部１１Ｅは、リソース提供装置１７の第３識別情報と、該第３識別情報によって識別されるリソース提供装置１７で許可するクライアント端末１２で生成した第１公開鍵と、を対応付けて予め記憶する。そして、アクセス検証部１１Ｅは、受信したトークン発行要求に含まれる第３識別情報に対応付けて、該トークン発行要求に含まれる第１公開鍵が記憶されている場合に、アクセス権を有すると検証すればよい。

発行部１１Ｆは、アクセス検証部１１Ｅがアクセス権を有すると検証した場合、第３識別情報によって識別されるリソース提供装置１７で利用可能なアクセストークンを発行する。

なお、発行部１１Ｆは、リソース提供装置１７にアクセストークンの発行要求を依頼してもよい。本実施の形態では、リソース提供装置１７が、アクセストークンの発行および署名付与を行う場合を説明する。

例えば、発行部１１Ｆは、アクセストークン発行時に、クライアント端末１２から受信したトークン発行要求に含まれる第３識別情報によって識別されるリソース提供装置１７へ、トークン発行要求の送信元のクライアント（クライアント端末１２）からのアクセス許可要求を送信する。アクセス許可要求を受信したリソース提供装置１７は、該クライアント端末１２へのアクセスを許可すればよい。但し、この段階では、リソース提供装置１７は、該クライアント端末１２へのリソース提供はまだ許可していない状態である。

そして、発行部１１Ｆは、アクセス検証部１１Ｅがアクセス権を有すると検証した場合、クライアント端末１２から受信したトークン発行要求に含まれる第３識別情報によって識別されるリソース提供装置１７へ、該クライアント端末１２で生成した第１公開鍵を用いた記名式トークンの生成を依頼する。例えば、発行部１１Ｆは、クライアント端末１２から受信したトークン発行要求に含まれる第１公開鍵を含むアクセストークン生成要求を、リソース提供装置１７へ送信する。

また、発行部１１Ｆは、クライアント端末１２から受信したトークン発行要求に含まれる第３識別情報によって識別されるリソース提供装置１７へ、該リソース提供装置１７による発行を証明するための証明書を用いた、記名式トークンへの第３署名の付与を要求する。例えば、発行部１１Ｆは、リソース提供装置１７へ、署名付与要求を送信する。

そして、発行部１１Ｆは、リソース提供装置１７から第３署名の付与された記名式トークン（アクセストークン）を受信することで、アクセストークンを発行してもよい。

なお、発行部１１Ｆは、アクセストークンの生成を実行し、署名の付与のみ、リソース提供装置１７へ依頼してもよい。

次に、リソース提供装置１７の機能について説明する。

リソース提供装置１７は、通信部１６Ａと、ｎｏｎｃｅ発行部１６Ｂと、アクセストークン検証部１６Ｃと、応答部１６Ｄと、アクセス許可部１７Ｅと、生成部１７Ｆと、署名付与部１７Ｇと、を備える。通信部１６Ａ、ｎｏｎｃｅ発行部１６Ｂ、アクセストークン検証部１６Ｃ、および応答部１６Ｄは、第１の実施の形態のリソース提供装置１６と同様である。

アクセス許可部１７Ｅは、情報処理装置１１からアクセス許可要求を受信すると、該アクセス許可要求に含まれるクライアント端末１２の識別情報を、アクセス許可対象のクライアントの識別情報として記憶する。クライアント端末１２の識別情報には、例えば、クライアント端末１２を操作するユーザの認証情報（ユーザＩＤ、パスワード）、クライアント端末１２を一意に識別する識別情報、クライアント端末１２で生成した第１公開鍵、などを用いればよい。

この記憶処理により、アクセス許可部１７Ｅは、該クライアント端末１２からのアクセスを許可する。なお、このアクセス許可は、上述したように、クライアント端末１２へのリソース提供を許可した状態ではなく、単に、アクセスを許可することを意味する。

生成部１７Ｆは、クライアント端末１２の第１公開鍵を含むアクセストークン生成要求を情報処理装置１１から受信すると、該第１公開鍵を用いて、該クライアント端末１２用の記名式トークン（アクセストークン）を生成する。

署名付与部１７Ｇは、署名付与要求を情報処理装置１１から受信すると、生成部１７Ｆで生成した記名式トークン（アクセストークン）に、リソース提供装置１７による発行を証明するための証明書を用いて、第３署名を付与する。この証明書には、リソース提供装置１７で予め生成した第３秘密鍵を用いればよい。

なお、リソース提供装置１７は、第３公開鍵と第３秘密鍵とのペアを予め生成すればよい。これらの第３公開鍵と第３秘密鍵とのペアの生成には、公知の方法を用いればよい。そして、署名付与部１７Ｇは、予め生成した第３秘密鍵を用いて、アクセストークンに第３署名を付与すればよい。

なお、署名付与部１７Ｇは、生成部１７Ｆで生成した記名式トークンのハッシュ値に第３署名を付与することで、第３署名付きのアクセストークンを生成してもよい。

次に、情報処理システム１Ａで実行される情報処理の手順の一例を説明する。

図４は、情報処理システム１Ａで実行される情報処理の手順の一例を示す、シーケンス図である。

まず、リソース提供装置１７が、第３公開鍵と第３秘密鍵とのペアを生成する（ステップＳ２００）。一方、クライアント端末１２のサービス提供ページ１２Ｃは、第１公開鍵と第１秘密鍵とのペアを生成する（ステップＳ２０２）。

次に、クライアント端末１２のサービス提供ページ１２Ｃは、トークン発行要求を情報処理装置１１へ送信する（ステップＳ２０４）。本実施の形態では、サービス提供ページ１２Ｃは、記名式トークンの発行要求を示す、トークン発行要求を情報処理装置１１へ送信する。

ステップＳ２０４で、サービス提供ページ１２Ｃからトークン発行要求を受信した情報処理装置１１のｎｏｎｃｅ発行部１０Ｃは、クライアント端末１２に対するｎｏｎｃｅを発行する（ステップＳ２０６）。そして、ｎｏｎｃｅ発行部１０Ｃは、ステップＳ２０６で発行したｎｏｎｃｅを示すｎｏｎｃｅ情報を、送信部１０Ｂを介してサービス提供ページ１２Ｃへ送信する（ステップＳ２０８）。ｎｏｎｃｅ情報は、ステップＳ２０６で発行したｎｏｎｃｅを示す情報であればよい。本実施の形態では、ｎｏｎｃｅ情報が、ｎｏｎｃｅである場合を一例として説明する。

クライアント端末１２のサービス提供ページ１２Ｃは、情報処理装置１１から受信したｎｏｎｃｅに第１秘密鍵を用いて第１署名を付与する（ステップＳ２１０）。

ステップＳ２０２〜ステップＳ２１０の処理は、上記実施の形態のステップＳ１０２〜ステップＳ１１０と同様である（図２参照）。

そして、クライアント端末１２のサービス提供ページ１２Ｃは、第１公開鍵と、ステップＳ２０８で受信したｎｏｎｃｅと、ステップＳ２１０で付与した第１署名と、を含むトークン発行要求と、クライアント端末１２がリソースの提供を要求する対象のリソース提供装置１７の第３識別情報と、情報処理装置１１へ送信する（ステップＳ２１２）。

すなわち、本実施の形態では、サービス提供ページ１２Ｃは、第３識別情報を更に含むトークン発行要求を情報処理装置１０へ送信する点が、上記実施の形態のステップＳ１１２の処理と異なる（図２参照）。

なお、クライアント端末１２のサービス提供ページ１２Ｃは、情報処理システム１Ａに接続された複数のリソース提供装置１７の一覧を示す情報を表示する。クライアント端末１２を操作するユーザは、クライアント端末１２を操作することで、リソース提供を要求する対象のリソース提供装置１７を選択する。この選択操作により、サービス提供ページ１２Ｃは、リソースの提供を要求する対象のリソース提供装置１７の第３識別情報を受付ける。そして、サービス提供ページ１２Ｃは、該第３識別情報を含むトークン発行要求を、情報処理装置１１へ送信すればよい。

情報処理装置１１の署名検証部１０Ｄは、ステップＳ２１２でクライアント端末１２の認証ページ１２Ｄから受信したトークン発行要求に含まれる第１署名を、該トークン発行要求に含まれる第１公開鍵を用いて検証する（ステップＳ２１４）。ステップＳ２１４の処理は、上記実施の形態のステップＳ１１４（図２参照）と同様である。ここでは、検証成功したとして、説明を続ける。

そして、情報処理装置１１のアクセス検証部１１Ｅは、ステップＳ２１２のトークン発行要求の送信元のクライアント端末１２が第３識別情報によって識別されるリソース提供装置１７へのアクセス権を有するか否かを検証する（ステップＳ２１６）。ここでは、アクセス権を有すると検証したと想定し、説明を続ける。

アクセス権を有すると検証すると、情報処理装置１１の送信部１０Ｂは、第１識別情報を含むログイン要求を、クライアント端末１２の認証ページ１２Ｄへ送信する（ステップＳ２１８）。ステップＳ２１８では、送信部１０Ｂは、ステップＳ２０６で発行したｎｏｎｃｅ、該ｎｏｎｃｅの第２識別情報、ステップＳ２０４およびステップＳ２１２で受信したトーク発行要求の少なくとも一方の通信セッション識別情報、の何れかを、第１識別情報として用いる。

ログイン要求を受信したクライアント端末１２の認証ページ１２Ｄは、情報処理装置１１へログインするための認証画面を表示する（ステップＳ２２０）。クライアント端末１２を操作するユーザは、認証画面を参照しながらクライアント端末１２を操作することで、認証情報（ユーザＩＤ、パスワード）を入力する。

そして、クライアント端末１２の認証ページ１２Ｄは、入力された認証情報（ユーザＩＤ、パスワード）と、ステップＳ２１８で受信したログイン要求に含まれる第１識別情報と、を含む認可許諾要求を、情報処理装置１１へ送信する（ステップＳ２２２）。

ステップＳ２１８〜ステップＳ２２２の処理は、上記実施の形態のステップＳ１１６〜ステップＳ１２０と同様である（図２参照）。

情報処理装置１１の発行部１１Ｆは、ステップＳ２１２でクライアント端末１２から受信したトークン発行要求に含まれる第１公開鍵を含むアクセストークン生成要求と、署名付与要求と、をリソース提供装置１７へ送信する(ステップＳ２２４)。このとき、情報処理装置１１からリソース提供装置１７への通信は、特にリソース提供装置がホームネットワークなどのプライベートネットワーク上のデバイスであることを想定した場合、ファイアウォールなどの影響で普通にはアクセスできない場合が多い。このため、リソース提供装置１７は、ＷｅｂＳｏｃｋｅｔ等の常時接続通信プロトコルを用いて、情報処理装置１１との間に通信チャネルをあらかじめ（電源ＯＮをトリガとして常時）構築しておき、このＷｅｂＳｏｃｋｅｔ接続を介して、アクセストークン生成要求を行うように構成してもよい。あるいは、トークン発行要求（ステップＳ２０４）前の段階で、Ｗｅｂブラウザに読み込まれたサービス提供ページ１２Ｃ（ＯＡｕｔｈクライアント）が、いったんアクセス対象のリソース提供装置１７にアクセスを試行し、この時点ではアクセストークンを持っていないので、リソース提供装置１７が、情報処理装置の認可エンドポイント（／ａｕｔｈｏｒｉｚｅ）にリダイレクトするように構成し、上記アクセス試行をトリガとして、ＷｅｂＳｏｃｋｅｔ接続を構築し、アクセストークン生成要求を受信するように構成してもよい。

リソース提供装置１７の生成部１７Ｆは、ステップＳ２２４で受信したアクセストークン生成要求に含まれる第１公開鍵を用いて、クライアント端末１２用の記名式トークン（アクセストークン）を生成する（ステップＳ２２６）。

そして、リソース提供装置１７の署名付与部１７Ｇは、ステップＳ２２６で生成した記名式トークン（アクセストークン）に、ステップＳ２００で生成した第３秘密鍵を用いて第３署名を付与する。

そして、署名付与部１７Ｇは、生成したアクセストークンと、ステップＳ２２４で受信したアクセストークン生成要求に含まれる第１公開鍵と、を対応付けて記憶する（ステップＳ２３０）。

そして、リソース提供装置１７の通信部１６Ａは、ステップＳ２２６およびステップＳ２２８で生成した、第３署名の付与されたアクセストークンを、情報処理装置１１へ送信する（ステップＳ２３１）。情報処理装置１１の発行部１１Ｆは、リソース提供装置１７から第３署名の付与されたアクセストークンを受信することで、アクセストークンを発行する（ステップＳ２３２）。

なお、上述したように、情報処理装置１１の発行部１１Ｆが、記名式トークンを生成することでアクセストークンを発行してもよい。そして、第３署名の付与を、リソース提供装置１７へ依頼してもよい。

そして、情報処理装置１１の送信部１０Ｂは、ステップＳ２３２で受信した、第３署名の付与されたアクセストークンを含むアクセストークン応答情報を、クライアント端末１２へ送信する（ステップＳ２３４）。

クライアント端末１２のサービス提供ページ１２Ｃは、ステップＳ２３４で受信したアクセストークン応答情報に含まれる、アクセストークンと、第１公開鍵と、を対応付けて記憶する（ステップＳ２３６）。ステップＳ２３６で記憶するアクセストークンは、情報処理装置１１またはリソース提供装置１７によって生成され、リソース提供装置１７によって第３署名の付与された、アクセストークンである。

次に、クライアント端末１２のサービス提供ページ１２Ｃは、ステップＳ２３６で記憶した、第３署名付きのアクセストークンを含むリソースリクエストを、上記第３識別情報によって識別されるリソース提供装置１７へ送信する（ステップＳ２３８）。

ステップＳ２３８でリソースリクエストを受信したリソース提供装置１７のｎｏｎｃｅ発行部１６Ｂは、クライアント端末１２用のｎｏｎｃｅを発行する（ステップＳ２４０）。そして、ｎｏｎｃｅ発行部１６Ｂは、ステップＳ２４０で発行したｎｏｎｃｅを示すｎｏｎｃｅ情報を、クライアント端末１２へ送信する（ステップＳ２４２）。本実施の形態では、ｎｏｎｃｅ発行部１６Ｂは、ｎｏｎｃｅをクライアント端末１２へ送信する場合を一例として説明する。

ステップＳ２４２でｎｏｎｃｅを受信したクライアント端末１２のサービス提供ページ１２Ｃは、ステップＳ２３６で記憶した、第３署名付きのアクセストークンと、ステップＳ２４２で受信したｎｏｎｃｅと、を含むリソースリクエストを、上記第３識別情報によって識別されるリソース提供装置１７へ送信する（ステップＳ２４４）。

ステップＳ２３４〜ステップＳ２４４の処理は、上記実施の形態のステップＳ１２８〜ステップＳ１３８と同様である（図２参照）。

リソース提供装置１７のアクセストークン検証部１６Ｃは、ステップＳ２４４で受信したリソースリクエストに含まれる、第３署名付きのアクセストークン検証する（ステップＳ２４６）。このとき、アクセストークン検証部１６Ｃは、該第３署名を付与されたアクセストークンがステップＳ２３０の処理によって記憶されているか否かを判別することで、検証処理を行う。すなわち、本実施の形態では、アクセストークン検証部１６Ｃは、情報処理装置１１へ問い合わせることなく、アクセストークンを検証する。ここでは検証成功したものと想定し、説明を続ける。

そして、リソース提供装置１７の応答部１６Ｄは、クライアント端末１２のサービス提供ページ１２Ｃへリソースを提供する（ステップＳ２４８）。

以上説明したように、本実施の形態の情報処理装置１１は、リソース提供要求対象のリソース提供装置１７の第３識別情報を更に含むトークン発行要求を受信したときに、該第３識別情報によって識別されるリソース提供装置１７で利用可能なアクセストークンを発行する。すなわち、情報処理装置１１は、該トークン発行要求元のクライアント端末１２でのみ利用可能な記名式トークンであり、且つ、該クライアント端末１２がリソース提供を要求する対象のリソース提供装置１７でのみ利用可能な、アクセストークンを発行する。

このため、本実施の形態の情報処理装置１１は、上記実施の形態の効果に加えて、アクセストークンの用途を更に限定することができ、アクセストークンのセキュリティの更なる向上を図ることができる。

また、本実施の形態の情報処理装置１１では、トークン発行要求に含まれる第３識別情報によって識別されるリソース提供装置１７へ、該トークン発行要求の送信元のクライアント端末１２からのアクセス許可要求を送信する。そして、リソース提供装置１７では、アクセス許可要求に応じて、該アクセス許可要求に示されるクライアント端末１２からのアクセスを許可する。このため、情報処理装置１１は、該クライアント端末１２からのアクセスを選択的に許可するようにリソース提供装置１７を制御することができる。

このため、本実施の形態の情報処理装置１１は、上記効果に加えて、更なるセキュリティ向上を図ることができる。

また、本実施の形態では、クライアント端末１２がリソース提供を要求する対象のリソース提供装置１７が、アクセストークンに第３署名を付与する。このため、本実施の形態でクライアント端末１２に対して発行されるアクセストークンは、リソース提供装置１７によって第３署名の付与されたアクセストークンとなる。

すなわち、本実施の形態では、リソース提供装置１７は、クライアント端末１２から受信したリソースリクエストに含まれるアクセストークンの検証の度に、情報処理装置１１へ問合せを行う必要がない。また、情報処理装置１１は、リソース提供装置１７からのアクセストークンの検証に関する問い合わせを受信することがない。このため、本実施の形態の情報処理システム１Ａでは、上記効果に加えて、情報処理装置１１およびリソース提供装置１７の双方の負荷低減を図ることができる。

また、本実施の形態では、リソース提供装置１７がアクセストークンを管理する。このため、情報処理装置１１は、アクセストークンの管理負荷の低減や、運用および管理コストの低減を図ることができる。

（ハードウェア構成）
図５は、上記実施の形態の情報処理装置１０、情報処理装置１１、クライアント端末１２、サービス提供装置１４、リソース提供装置１６、およびリソース提供装置１７の主要部のハードウェア構成の例を示す図である。上記実施の形態の情報処理装置１０、情報処理装置１１、クライアント端末１２、サービス提供装置１４、リソース提供装置１６、およびリソース提供装置１７は、制御装置４０１、主記憶装置４０２、補助記憶装置４０３、表示装置４０４、入力装置４０５及び通信装置４０６を備える。制御装置４０１、主記憶装置４０２、補助記憶装置４０３、表示装置４０４、入力装置４０５及び通信装置４０６は、バス４１０を介して接続されている。

制御装置４０１は補助記憶装置４０３から主記憶装置４０２に読み出されたプログラムを実行する。制御装置４０１は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等の汎用のプロセッサである。主記憶装置４０２はＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、及び、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等のメモリである。補助記憶装置４０３はメモリカード、及び、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等である。

表示装置４０４は情報を表示する。表示装置４０４は、例えば液晶ディスプレイである。入力装置４０５は、情報の入力を受け付ける。入力装置４０５は、例えばハードウェアキー、キーボード及びマウス等である。なお表示装置４０４及び入力装置４０５は、表示機能と入力機能とを兼ねる液晶タッチパネル等でもよい。通信装置４０６は他の装置と通信する。

上記実施の形態の情報処理装置１０、情報処理装置１１、クライアント端末１２、サービス提供装置１４、リソース提供装置１６、およびリソース提供装置１７で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、メモリカード、ＣＤ−Ｒ、及び、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記憶媒体に記憶されてコンピュータ・プログラム・プロダクトとして提供される。

また、上記実施の形態の情報処理装置１０、情報処理装置１１、クライアント端末１２、サービス提供装置１４、リソース提供装置１６、およびリソース提供装置１７で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、該ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上記実施の形態の情報処理装置１０、情報処理装置１１、クライアント端末１２、サービス提供装置１４、リソース提供装置１６、およびリソース提供装置１７が実行するプログラムを、ダウンロードさせずにインターネット等のネットワーク経由で提供するように構成してもよい。

また、上記実施の形態の情報処理装置１０、情報処理装置１１、クライアント端末１２、サービス提供装置１４、リソース提供装置１６、およびリソース提供装置１７で実行されるプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

上記実施の形態の情報処理装置１０、情報処理装置１１、クライアント端末１２、サービス提供装置１４、リソース提供装置１６、およびリソース提供装置１７で実行されるプログラムは、これらの装置の各々の上記機能構成のうち、プログラムにより実現可能な機能を含むモジュール構成となっている。

プログラムにより実現される機能は、制御装置４０１が補助記憶装置４０３等の記憶媒体からプログラムを読み出して実行することにより主記憶装置４０２にロードされる。すなわちプログラムにより実現される機能は、主記憶装置４０２上に生成される。

上記実施の形態の情報処理装置１０、情報処理装置１１、クライアント端末１２、サービス提供装置１４、リソース提供装置１６、およびリソース提供装置１７の機能の一部を、ＩＣ等のハードウェアにより実現してもよい。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０、１１ 情報処理装置
１０Ａ 受信部
１０Ｂ 送信部
１０Ｅ 発行部
１６、１７ リソース提供装置
１７Ｆ 生成部
１７Ｇ 署名付与部

Claims (14)

1. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置であって、
   前記クライアントに対して発行されたｎｏｎｃｅと、前記クライアントが生成した第１公開鍵と、前記ｎｏｎｃｅを含むクライアント情報に対する第１署名と、を含む前記トークン発行要求を前記クライアントから受信する受信部と、
   前記トークン発行要求に含まれる前記第１署名の前記第１公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第１識別情報を含むログイン要求を前記クライアントへ送信する送信部と、
   前記クライアントを利用するユーザの認証情報および前記第１識別情報を含む認可許諾要求を前記クライアントから受信したときに、前記第１公開鍵を用いて生成した記名式トークンを前記アクセストークンとして発行する発行部と、
   を備える情報処理装置。
2. 前記第１識別情報は、
   前記ｎｏｎｃｅ、前記ｎｏｎｃｅの第２識別情報、または前記トークン発行要求の通信セッション識別情報、である、
   請求項１に記載の情報処理装置。
3. 前記送信部は、
   発行された前記アクセストークンの特定情報を含むアクセストークン応答情報を、前記クライアントへ送信する、
   請求項１または請求項２に記載の情報処理装置。
4. 前記特定情報は、
   発行された前記アクセストークン、または、該アクセストークンの識別情報である、
   請求項３に記載の情報処理装置。
5. 前記発行部は、
   当該情報処理装置による発行を証明するための証明書を用いて、前記記名式トークンに第２署名を付与し、該第２署名付きの前記アクセストークンを発行する、
   請求項１〜請求項４の何れか１項に記載の情報処理装置。
6. リソース提供要求対象のリソース提供装置の第３識別情報を含む前記トークン発行要求を受信したときに、前記トークン発行要求の送信元の前記クライアントが前記第３識別情報によって識別される前記リソース提供装置へのアクセス権を有するか否かを検証する検証部を備え、
   前記発行部は、
   前記検証部がアクセス権を有すると検証した場合、前記第３識別情報によって識別される前記リソース提供装置で利用可能な前記アクセストークンを発行する、
   請求項１〜請求項５の何れか１項に記載の情報処理装置。
7. 前記発行部は、
   前記第３識別情報によって識別される前記リソース提供装置へ、前記トークン発行要求の送信元の前記クライアントからのアクセス許可要求を送信する、
   請求項６に記載の情報処理装置。
8. 前記発行部は、
   前記検証部がアクセス権を有すると検証した場合、前記第３識別情報によって識別される前記リソース提供装置へ、前記第１公開鍵を用いた前記記名式トークンの生成を依頼し、該リソース提供装置で生成された前記記名式トークンを、前記アクセストークンとして発行する、
   請求項６または請求項７に記載の情報処理装置。
9. 前記発行部は、
   前記第３識別情報によって識別される前記リソース提供装置へ、該リソース提供装置による発行を証明するための証明書を用いた、前記記名式トークンへの第３署名の付与を要求し、該第３署名付きの前記記名式トークンを、前記アクセストークンとして発行する、
   請求項８に記載の情報処理装置。
10. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置と通信するリソース提供装置であって、
    前記情報処理装置は、
    前記クライアントに対して発行されたｎｏｎｃｅと、前記クライアントが生成した第１公開鍵と、前記ｎｏｎｃｅを含むクライアント情報に対する第１署名と、を含む前記トークン発行要求を前記クライアントから受信し、前記トークン発行要求に含まれる前記第１署名の前記第１公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第１識別情報を含むログイン要求を前記クライアントへ送信し、
    前記リソース提供装置は、
    前記クライアントを利用するユーザの認証情報および前記第１識別情報を含む認可許諾要求を前記情報処理装置が前記クライアントから受信したときに、前記情報処理装置から受信した、前記クライアントの第１公開鍵を含むアクセストークン生成要求に含まれる前記第１公開鍵を用いて、記名式トークンを生成する生成部と、
    前記記名式トークンに、当該リソース提供装置で生成した第３秘密鍵を用いた第３署名を付与する署名付与部と、
    を備えたリソース提供装置。
11. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置で実行される情報処理方法あって、
    前記クライアントに対して発行されたｎｏｎｃｅと、前記クライアントが生成した第１公開鍵と、前記ｎｏｎｃｅを含むクライアント情報に対する第１署名と、を含む前記トークン発行要求を前記クライアントから受信するステップと、
    前記トークン発行要求に含まれる前記第１署名の前記第１公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第１識別情報を含むログイン要求を前記クライアントへ送信するステップと、
    前記クライアントを利用するユーザの認証情報および前記第１識別情報を含む認可許諾要求を前記クライアントから受信したときに、前記第１公開鍵を用いて生成した記名式トークンを前記アクセストークンとして発行するステップと、
    を含む情報処理方法。
12. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行するコンピュータに、
    前記クライアントに対して発行されたｎｏｎｃｅと、前記クライアントが生成した第１公開鍵と、前記ｎｏｎｃｅを含むクライアント情報に対する第１署名と、を含む前記トークン発行要求を前記クライアントから受信するステップと、
    前記トークン発行要求に含まれる前記第１署名の前記第１公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第１識別情報を含むログイン要求を前記クライアントへ送信するステップと、
    前記クライアントを利用するユーザの認証情報および前記第１識別情報を含む認可許諾要求を前記クライアントから受信したときに、前記第１公開鍵を用いて生成した記名式トークンを前記アクセストークンとして発行するステップと、
    を実行させるための情報処理プログラム。
13. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置と通信するリソース提供装置で実行するリソース提供方法あって、
    前記情報処理装置は、
    前記クライアントに対して発行されたｎｏｎｃｅと、前記クライアントが生成した第１公開鍵と、前記ｎｏｎｃｅを含むクライアント情報に対する第１署名と、を含む前記トークン発行要求を前記クライアントから受信し、前記トークン発行要求に含まれる前記第１署名の前記第１公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第１識別情報を含むログイン要求を前記クライアントへ送信し、
    前記リソース提供方法は、
    前記クライアントを利用するユーザの認証情報および前記第１識別情報を含む認可許諾要求を前記情報処理装置が前記クライアントから受信したときに、前記情報処理装置から受信した、前記クライアントの第１公開鍵を含むアクセストークン生成要求に含まれる前記第１公開鍵を用いて、記名式トークンを生成するステップと、
    前記記名式トークンに、当該リソース提供装置で生成した第３秘密鍵を用いた第３署名を付与するステップと、
    を含むリソース提供方法。
14. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置と通信するコンピュータに実行させるためのリソース提供プログラムであって、
    前記情報処理装置は、
    前記クライアントに対して発行されたｎｏｎｃｅと、前記クライアントが生成した第１公開鍵と、前記ｎｏｎｃｅを含むクライアント情報に対する第１署名と、を含む前記トークン発行要求を前記クライアントから受信し、前記トークン発行要求に含まれる前記第１署名の前記第１公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第１識別情報を含むログイン要求を前記クライアントへ送信し、
    前記リソース提供プログラムは、
    前記クライアントを利用するユーザの認証情報および前記第１識別情報を含む認可許諾要求を前記情報処理装置が前記クライアントから受信したときに、前記情報処理装置から受信した、前記クライアントの第１公開鍵を含むアクセストークン生成要求に含まれる前記第１公開鍵を用いて、記名式トークンを生成するステップと、
    前記記名式トークンに、前記コンピュータで生成した第３秘密鍵を用いた第３署名を付与するステップと、
    を前記コンピュータに実行させるためのリソース提供プログラム。

Images