JP2015005222A - 認可サーバーシステムおよびその制御方法、並びにプログラム - Google Patents

Abstract

【課題】ＯＡｕｔｈのような認可フローにおいて、アクセストークンの削除をすべきでない場合も存在する。例えば同一認証ドメインにおいて、サービス連携を行うためのトークンを削除できてしまうと、サービス間連携の際に不整合が発生する可能性がある。【解決手段】認証情報の入力を求めることなくサービスの提供を可能とするための認可情報を管理する認可サーバーシステムであって、前記認可情報を管理する管理手段と、前記管理手段にて管理する認可情報を削除するための削除画面の要求を受信したことに応じて、ユーザーの認可操作が行われたことで生成された認可情報を含み、前記ユーザーの認可操作が行われずに生成された認可情報を含まない削除画面を提供する提供手段と、前記削除画面を介して削除の指示を受信したことに応じて、前記管理手段にて管理された認可情報を削除する削除手段とを有する。【選択図】 図３

Description

本願発明は、認可サーバーシステムおよびその制御方法、並びにプログラムに関する。特に複数のサービスが連携する場合におけるアクセストークンの削除方法に関する。

近年、インターネット上で提供される複数のサービスが連携することで更なる付加価値をユーザーに提供できるようになってきている。その一方で、複数のサービスが連携することにより、いくつかの課題が生じている。例えば、ユーザーが望んだ以上の情報がサービス間で交換されることにより、ユーザーデータや個人情報の漏えいリスクがある。一方、サービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。

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

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

ＯＡｕｔｈ ２．０では、ユーザーがアクセストークンを無効化できる事が前提になっている（非特許文献２参照）。トークンリボケーションは、ＯＡｕｔｈ ２．０で定義されている各種トークン無効化のためのプロトコルの仕様である。これは、クライアント側からＯＡｕｔｈ ２．０に基づいて発行されたアクセストークンやリフレッシュトークンを無効化するためのリクエスト／レスポンスの定義がなされている。例えば、認可サーバーの実装に応じて、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔに紐づくセッションなどを一緒に切断するといった定義も可能である。本仕様は、例えばサービス連係解除時／ログアウト時／サービス退会時などにクライアントから各種トークンを無効化する、といったユースケースで使用されることを想定している。

Ｅ． Ｈａｍｍｅｒ−Ｌａｈａｖ、"Ｔｈｅ ＯＡｕｔｈ １．０ Ｐｒｏｔｏｃｏｌ"、［ｏｎｌｉｎｅ］、２０１０年４月、ＩＥＴＦ、［平成２５年６月６日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５８４９＞ Ｄ． Ｈａｒｄｔ、"Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ"、［ｏｎｌｉｎｅ］、２０１２年１０月、ＩＥＴＦ、［平成２５年６月６日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９＞

一方、ＯＡｕｔｈのような認可フローにおいて、アクセストークンの削除をすべきでない場合も存在する。例えばある認可フローで、同一認証ドメイン内でのサービス間連携のときに使用するトークンを、ユーザーの確認なしに生成した場合が該当する。ここでの同一認証ドメインとは、認証、認可機能を有するサーバーと、帳票サービスや印刷サービスなどを提供するクライアントアプリケーションサーバーとが同一のＬＡＮなどに接続され、各サービス間で情報漏洩などの問題が起きにくい構成のドメインを指す。同一認証ドメインにおいて、サービス間連携を行うためのトークンが削除できてしまうと、連携の際にデータ不整合が発生する可能性がある。例えば帳票サービスと印刷サービスとが連携している場合に印刷サービスへのアクセストークンのみ無効化されてしまうと、ユーザーは、帳票は作成できるが印刷が不可能になる、といった問題が生じる。

本願発明は上記課題を解決するために、以下の構成を有する。すなわち、認証情報の入力を求めることなくサービスの提供を可能とするための認可情報を管理する認可サーバーシステムであって、前記認可情報を管理する管理手段と、前記管理手段にて管理する認可情報を削除するための削除画面の要求を受信したことに応じて、ユーザーの認可操作が行われたことで生成された認可情報を含み、前記ユーザーの認可操作が行われずに生成された認可情報を含まない削除画面を提供する提供手段と、前記削除画面を介して削除の指示を受信したことに応じて、前記管理手段にて管理された認可情報を削除する削除手段と、
を有する。

本願発明により、同一認証ドメイン内で用いられるアクセストークンの削除を制限し、サービス間連携の際にデータ不整合が発生することを防止することができる。

システム構成例を示す図。 各装置のハードウェア構成例を示す図。 同一認証ドメイン内において認証トークンを用いて、リソースサービスを利用する場合の認可フローのシーケンスを示す図。 各装置のモジュール構成の例を示す図。 異なる認証ドメイン間において認可コードを用いて、リソースサービスを利用する場合の認可フローのシーケンスを示す図。 クライアント表示／非表示、クライアント連携解除可／不可の関係を示す図。 リボケーション選択画面の表示に係る処理のフローチャート。 リボケーション実行画面の表示に係る処理のフローチャート。 トークンリボケーションＷｅｂアプリケーションのＧＵＩの例を示す図。 認可サーバーが有する各種管理テーブルの構成例を示す図。 ログイン画面の構成例を示す図。 各種画面の構成例を示す図。 クライアントアプリケーションサーバー３００が有する各種管理テーブルの構成例を示す図。 クライアントアプリケーションサーバー３５０が有する各種管理テーブルの構成例を示す図。 第二の実施形態に係るシステム構成例を示す図。 第二の実施形態に係る認可トークン管理テーブルの構成例を示す図。

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

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

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

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

また、本実施形態では、複数の認証ドメイン（セキュリティドメイン）が存在するものとする。また、同一の認証ドメインに属する装置もしくはサービス間でデータ通信を行う場合と、異なる認証ドメインに属する装置もしくはサービス間でデータ通信を行う場合とでは、トークンの発行およびリソースサービスの利用の流れが異なる。詳細については後述する。

［同一認証ドメイン内にて、認証トークンを用いてリソースサービスを利用する場合］
まずは、同一の認証ドメインに属する装置もしくはサービス間で、認証トークンを用いてリソースサービスを利用する場合の構成について説明する。

［システム構成］
図１に、本実施形態に係る認可システムの構成例を示す。まず、同一の認証ドメインにおいて、認証トークンを用いてリソースサービスを利用する場合について説明する。ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１００は、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）システムが構築されたネットワークである。ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１、１０２は、各構成要素を接続するネットワークである。

認可サーバーシステムである認可サーバー５００は、ＯＡｕｔｈに対応し、認可サービスモジュールが設置される。クライアントアプリケーションサーバー３００は、ＯＡｕｔｈにおけるクライアントを実現するクライアントアプリケーションサーバーである。本実施形態ではクライアントアプリケーションサーバー３００に、リソースサービス連携アプリケーションとして、リソースサービスと連携可能なクライアントアプリケーションが設置される。ここでのクライアントアプリケーションは、印刷アプリケーションや帳票アプリケーションである。ユーザーは、クライアントアプリケーションを用いてリソースサービスを利用する。なお一台のクライアントアプリケーションサーバーに設置されるクライアントアプリケーションは１つでもよく、複数でもよい。

リソースサーバー４００には、印刷サービスや帳票サービスなどのリソースサービスを提供するアプリケーションが設置される。なお１台のリソースサーバーに設置されるリソースサービスは１つでもよく、複数でもよい。クライアントＰＣ２００は、ユーザーが操作する情報処理装置である。ユーザーは、クライアントＰＣ２００が備えるＷｅｂブラウザ２１０を用いてクライアントアプリケーションサーバー３００にアクセスし、リソースサーバー４００が提供するリソースを用いて印刷サービスや帳票サービスなどのサービスを利用する。本実施形態の特徴として、クライアントアプリケーションサーバー３００およびリソースサーバー４００が、認可サーバー５００と同一のＬＡＮ１０１に接続されていることが挙げられる。つまり、クライアントアプリケーションサーバー３００、リソースサーバー４００、および認可サーバー５００は、ＷＡＮ１００を介さずに互いに接続されている。このため、本実施形態においてはこれらを同一認証ドメインに属するとみなし、クライアントアプリケーションサーバー３００とリソースサーバー４００との間のサービス連携を、同一の認証で賄うことを特徴とする。

また、クライアントＰＣ２００と、クライアントアプリケーションサーバー３００およびリソースサーバー４００とは、ＷＡＮ１００およびＬＡＮ１０１、１０２を介して接続される。なおクライアントＰＣ２００および各サーバーは、それぞれ個別のＬＡＮ上に構成されていてもよいし、同一のＬＡＮ上に構成されていてもよい。また同一のＰＣ上に構成されていてもよい。

［ハードウェア構成］
図２は、本実施形態に係るクライアントＰＣ２００の構成を示す図である。また、クライアントアプリケーションサーバー３００、クライアントアプリケーションサーバー３５０、リソースサーバー４００のハードウェア構成も同様であるものとして説明する。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当し、本実施形態のクライアントＰＣ２００および各サーバー装置には一般的な情報処理装置のハードウェア構成を適用できる。

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

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

［モジュール構成］
図４は、本実施形態に係る図１に示した、認可サーバー５００、リソースサーバー４００、クライアントＰＣ２００、およびクライアントアプリケーションサーバー３００それぞれのモジュール構成の例を示す。認可サーバー５００は、認可サーバーモジュール５１０を有する。

リソースサーバー４００は、リソースサーバーモジュール４１０を有する。クライアントＰＣ２００において、ＣＰＵ２０１がＲＯＭ２０３、或いは外部メモリ２０４に記憶されたＯＳ２２０を実行することで各アプリケーションを制御する。ＯＳ２２０は、一般的にはリアルタイムＯＳが使用されるが、Ｌｉｎｕｘ（登録商標）等の汎用ＯＳが使用されてもよい。さらに、クライアントＰＣ２００はＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ２１０を備える。

クライアントアプリケーションサーバー３００は、クライアントアプリケーションサーバーモジュール３１０、およびトークンリボケーションＷｅｂアプリケーション３２０を備える。クライアントアプリケーションサーバーモジュール３１０は、認可サーバー５００およびリソースサーバー４００と通信し、アクセストークンの取得、リソース要求などを行う。トークンリボケーションＷｅｂアプリケーション３２０は、クライアントＰＣ２００からトークンリボケーション要求を受信する。更にトークンリボケーションＷｅｂアプリケーション３２０は、認可サーバー５００から、リボケーション対象のトークンを有する連携クライアント一覧の取得を行い、表示を行う機能を備える。また、トークンリボケーションＷｅｂアプリケーション３２０は、連携クライアント一覧からリボケーション対象のトークンを有するクライアントの選択、認可サーバー５００に対するリボケーション実行依頼、リボケーション結果の表示を行う機能を有する。

［テーブル構成］
図１０は、認可サーバー５００が外部メモリに記憶する管理テーブルの構成例を示す。なお、各管理テーブルは、認可サーバー５００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別の記憶領域に記憶するようにしてもよい。

図１０（ａ）は、ユーザー管理テーブル１４０１の構成例を示す。ユーザー管理テーブル１４０１は、ユーザーＩＤ１４０２、パスワード１４０３、およびユーザー種別１４０４を含む。ユーザーＩＤ１４０２はユーザーを一意に識別するための識別情報である。認可サーバー５００は、ユーザーＩＤ１４０２およびパスワード１４０３の組を検証し、その組み合わせが正しければ認証情報を生成することで、各ユーザーもしくはクライアントを認証する機能を有する。本実施形態に係る認証情報の詳細は後述する。

図１０（ｂ）は、クライアント管理テーブル１４０５の構成例を示す。クライアント管理テーブル１４０５は、クライアントＩＤ１４０６、クライアント名１４０７、リダイレクトＵＲＬ１４０８、およびシリアル番号１４０９を含む。クライアントＩＤ１４０６は、クライアントを一意に識別するための識別情報である。なお、クライアントＩＤ１４０６は、ユーザー管理テーブル１４０１のユーザーＩＤ１４０２と関連付いており、互いに参照可能となっている。クライアント名１４０７およびリダイレクトＵＲＬ１４０８は、後述のＯＡｕｔｈのシーケンスで利用される。

図１０（ｃ）は、トークン管理テーブル１４１０の構成例を示す。トークン管理テーブル１４１０は、トークンＩＤ１４１１、トークン種別１４１２、有効期限１４１３、スコープ１４１４、リフレッシュトークンＩＤ１４１５、リフレッシュ期限１４１６、クライアントＩＤ１４１７、ユーザーＩＤ１４１８、アプリケーションＩＤ１４１９、およびＧｒａｎｔＴｙｐｅ１４２０を含む。トークン管理テーブル１４１０の処理詳細については後述する。

図１３は、クライアントアプリケーションサーバー３００が外部メモリに記憶する管理テーブルの構成例を示す。また、本実施形態ではクライアントアプリケーションサーバー３００の外部メモリに記憶する構成としているが、クライアントアプリケーションサーバー３００がＬＡＮ１０１を介して通信可能な別の記憶領域に記憶するようにしてもよい。

図１３（ａ）は、クライアント管理テーブル１７００の構成例を示す。クライアント管理テーブル１７００は、クライアントＰＣ２００のみから参照、更新可能なように構成される。クライアント管理テーブル１７００は、クライアントＩＤ１７０１、クライアントシークレット１７０２、エンドポイントＵＲＬ１７０３、およびリダイレクトＵＲＬ１７０４を含む。ここで、クライアントＩＤ１７０１およびクライアントシークレット１７０２は、予め認可サーバー５００にて発行され記憶されたユーザーＩＤ１４０２およびパスワード１４０３にそれぞれ対応している。さらに、リダイレクトＵＲＬ１７０４も、認可サーバー５００のクライアント管理テーブル１４０５に、クライアントＩＤ１４０６およびクライアント名１４０７に対応付けて登録されている情報（リダイレクトＵＲＬ１４０８）と同様のデータが格納される。これら情報の登録方法としては、例えば、クライアントＰＣ２００がＬＡＮ１０１、ＷＡＮ１００を介してオンラインで登録する方法や、ユーザーを介して認可サーバー５００にて値を設定する方法でも良い。なお、エンドポイントＵＲＬ１７０３は、認可サーバー５００が公開するＯＡｕｔｈのためのエンドポイントのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）である。

図１３（ｂ）は、トークン管理テーブル１７０５の構成例を示す。トークン管理テーブル１７０５は、クライアントアプリケーションサーバー３００からのみ参照、更新可能なように構成される。トークン管理テーブル１７０５は、ユーザーＩＤ１７０６、トークンＩＤ１７０７、およびリフレッシュトークンＩＤ１７０８を含む。トークン管理テーブル１７０５の処理詳細については後述する。

［認可フローに係るシーケンス］
ここで、リソースサービス連携アプリケーションを用いてリソースサービスを利用するための、本実施形態に係る認可フローを表すシーケンスについて、図３を用いて説明する。ＯＡｕｔｈ ２．０の仕様では、多様なクライアントに応じた複数のプロトコルシーケンスを“ｇｒａｎｔ ｔｙｐｅ”と呼ぶ。図３の認可フローは、本実施形態に係る独自のｇｒａｎｔ ｔｙｐｅである。

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

次に、クライアントアプリケーションサーバー３００は、認可連携サービス開始要求を受け付けた場合、自らが保持する認可サーバー５００の認証エンドポイントのＵＲＬに対して、ＯＡｕｔｈの認可リクエストをするように、リダイレクト要求を行う（Ｓ３．２）。ここでのリダイレクト要求は、クライアントＰＣ２００のブラウザにＨＴＴＰ／１．１ ステータスコード“３０２”を用いて行われる。本リダイレクト要求のＨＴＴＰ Ｌｏｃａｔｉｏｎヘッダーにはクライアントアプリケーションサーバー３００のＩＤ、認可フローのタイプ、および認可サーバー５００の認証エンドポイントのＵＲＬが含まれる。具体的には、以下のようなリダイレクト要求となる。
ｈｔｔｐｓ：／／ａｕｔｈ．ａ０１．ｃ−ｘｘｘ．ｃｏｍ／ＣＡＵＴＨ／Ｉｄｐｓ．ａｓｐｘ？ＬＯＣＡＬＥ＝ｊａ＿ＪＰ
ＨＴＴＰメソッド： ＧＥＴ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ

リクエストパラメーターには、ｒｅｓｐｏｎｓｅ＿ｔｙｐｅとして、固定文字列「ｃｏｄｅ」が設定される。また、ｃｌｉｅｎｔ＿ｉｄとして、認可サーバー５００に予めクライアントアプリケーションとして登録したクライアントアプリケーションサーバー３００のアプリケーションＩＤが設定される。更に、ｒｅｄｉｒｅｃｔ＿ｕｒｉとして、予め認可サーバー５００に登録したクライアントアプリケーションサーバー３００のＵＲＬが指定される。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成する事もできる。本実施形態では、スコープとして「リソースＡ」がリクエストされたとして説明する。

次に、クライアントＰＣ２００は、受信したリダイレクト要求に従い認可サーバー５００に対してユーザー認証、認可の要求を行う（Ｓ３．３）。認可サーバー５００は、認可リクエストを受け付けた後、ユーザーを認証するために図１１に示すログイン画面１５０１をクライアントＰＣ２００のＷｅｂブラウザ２１０に表示させる（Ｓ３．４）。リソースオーナー３０００は、クライアントＰＣ２００のＷｅｂブラウザ２１０に示されたログイン画面１５０１に対して、ユーザーＩＤおよびパスワードを入力し、ログインを実行する（Ｓ３．５）。

認可サーバー５００は、受け付けたユーザーＩＤおよびパスワードの組がユーザー管理テーブル１４０１に登録されている情報と一致するかを検証し、一致する場合にはユーザーＩＤと紐づいた認証情報を生成する。生成された認証情報は、トークン管理テーブル１４１０に格納される。具体的には、認証情報としてトークンＩＤ「ＡＨ＿００００００」がトークンＩＤ１４１１に格納される。またトークン種別として文字列「認証トークン」がトークン種別１４１２に格納される。

また認可サーバー５００は、予め定められた認証トークンの有効期限を有効期限１４１３に格納する。またリクエストパラメーターに含まれるスコープ情報（ここでは「リソースＡ」）がスコープ１４１４に格納される。またログイン時に入力されたユーザーＩＤがユーザーＩＤ１４１８に格納される。またｇｒａｎｔ ｔｙｐｅとして文字列「ＡｕｔｈｎＴｏｋｅｎ」がＧｒａｎｔＴｙｐｅ１４２０に格納される。認可サーバー５００は、トークン管理テーブル１４１０へ認証情報を格納して次の処理に進む。

認可サーバー５００は、本セッションに対して一意となるトークンＩＤ（以下、「認証トークン」と呼ぶ）をクライアントＰＣ２００のＷｅｂブラウザ２１０に対してＣｏｏｋｉｅ情報として格納する。そして、認可サーバー５００は、Ｓ３．２のリダイレクト要求に含まれたクライアントアプリケーションサーバー３００のＵＲＬに対するリダイレクト要求を返す（Ｓ３．６）。

クライアントＰＣ２００のＷｅｂブラウザ２１０は、認可サーバー５００からリダイレクト要求を受け取った後、認証トークンをリクエストパラメーターに含め、リダイレクト先に指定されたクライアントアプリケーションサーバー３００に認可応答としてリダイレクトする（Ｓ３．７）。

クライアントアプリケーションサーバー３００は、クライアントＰＣ２００から認可応答を受けた後、認可サーバー５００に対してトークン要求を行う（Ｓ３．８）。このトークン要求には、認可応答で取得した認証トークン、クライアント管理テーブル１７００のクライアントＩＤ１７０１、クライアントシークレット１７０２、およびリダイレクトＵＲＬ１７０４が含まれる。

認可サーバー５００は、クライアントアプリケーションサーバー３００からトークン要求を受けた後、トークン管理テーブル１４１０のトークンＩＤ１４１１に、トークン要求に含まれる認証トークンが含まれるか否かを検証する。認証トークンがトークン管理テーブル１４１０に含まれている場合、認可サーバー５００は、リソースサーバー４００へのアクセスを可能にするアクセストークンを生成する（Ｓ３．９）。

生成したアクセストークンは、トークン管理テーブル１４１０に登録される。すなわち、トークンＩＤ「ＡＴ＿０００００１」がトークンＩＤ１４１１に格納される。また、トークン種別として文字列「アクセストークン」がトークン種別１４１２に格納される。また、認可サーバー５００で予め定められたアクセストークンの有効期限が有効期限１４１３に格納される。またトークン管理テーブル１４１０に登録済みの認証トークンのレコードに含まれるスコープ情報と同様の値がスコープ１４１４に登録される。登録済みの認証トークンに対応するユーザーＩＤがユーザーＩＤ１４１８に登録される。ｇｒａｎｔ ｔｙｐｅとして文字列「ＡｕｔｈｎＴｏｋｅｎ」がＧｒａｎｔＴｙｐｅ１４２０に格納される。

このように、認可サーバー５００は、クライアントアプリケーションサーバー３００から認証トークンを受け取ると、ユーザーに対する明示的な認可確認を行わない。その一方で、認可サーバー５００は、リソースサーバー４００へのリソースアクセスを可能にするアクセストークン（トークンＩＤ「ＡＴ＿０００００１」）を発行する。これはクライアントアプリケーションサーバー３００、リソースサーバー４００、および認可サーバー５００が、ＷＡＮ１００を介さずに、同一認証ドメイン内で接続されているためである。なお、本実施形態においては、ＬＡＮ１０１内の範囲を同一認証ドメインとみなす。

認可サーバー５００は、アクセストークン生成およびトークン管理テーブル１４１０へのトークン情報の確認後、トークンＩＤ「ＡＴ＿０００００１」およびスコープ「リソースＡ」をパラメーターに含めてクライアントアプリケーションサーバー３００に応答する（Ｓ３．１０）。

クライアントアプリケーションサーバー３００は、Ｓ３．１０においてトークンＩＤ「ＡＴ＿０００００１」およびスコープ「リソースＡ」を認可サーバー５００から受信する。そして、クライアントアプリケーションサーバー３００は、リソースサーバー４００に対してトークンＩＤ「ＡＴ＿０００００１」およびスコープ「リソースＡ」をリクエストパラメーターに含め、リソースアクセス要求を行う（Ｓ３．１１）。

リソースサーバー４００は、トークンＩＤ「ＡＴ＿０００００１」およびスコープ「リソースＡ」を取得後、その情報を元に要求を受け付けたリソースに対するアクセスを許可するか否かを判定する。ここでは、リソースサーバー４００に予めアクセス可能なアプリケーションＩＤが設定されているものとする。リソースサーバー４００は、その設定されているアプリケーションＩＤと、トークンＩＤ「ＡＴ＿０００００１」に基づいて取得されたアプリケーションＩＤとを比較することでアクセスを許可するかを検証する。本検証は、リソースサーバー４００が、トークンＩＤ「ＡＴ＿０００００１」およびスコープ「リソースＡ」を引数にして認可サーバー５００からトークン情報を取得することで行われる。認可サーバー５００は、取得したアクセストークンの有効期間が切れていないこと、および要求されているスコープがスコープ範囲内であることを検証し、その結果を返す。

検証によりアクセス許可と判定された場合、リソースサーバー４００は、クライアントアプリケーションサーバー３００に対して、リソースを応答する（Ｓ３．１２）。ここでのリソースは、例えば、リソースサーバー４００が印刷サービスである場合は印刷可能な文書のリストであり、帳票サービスである場合は作成可能な帳票のリストである。

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

リソース応答を受け付けたクライアントアプリケーションサーバー３００は、受信したデータに基づいて前述のアプリケーション画面を構成し、リソースオーナー３０００に応答する（Ｓ３．１３）。

［他認証ドメイン間において、認可コードを用いてリソースサービスを利用する場合］
続いて、異なる認証ドメインに属する装置もしくはサービス間で、認可コードを用いてリソースサービスを利用する場合の構成について説明する。

［システム構成］
図１を用いて、更に他認証ドメイン間において認可コードを用いてリソースサービス利用する場合の構成例について説明する。

図１において、ＬＡＮ１０３には、クライアントアプリケーションサーバー３５０が接続され、更にＷＡＮ１００に接続されている。

クライアントアプリケーションサーバー３５０は、ＯＡｕｔｈにおけるクライアントを実現する。本実施形態では、クライアントアプリケーションサーバー３５０には、リソースサービス連携アプリケーションとして、リソースサービスと連携するクライアントアプリケーションが設置される。ここでのクライアントアプリケーションは、印刷アプリケーションおよび帳票アプリケーションである。ユーザーは、リソースサービス連携アプリケーションを用いてリソースサービスを利用する。ユーザーは、Ｗｅｂブラウザ２１０を用いてクライアントアプリケーションサーバー３５０のクライアントアプリケーションにアクセスする。そして、ユーザーは、リソースサーバー４００のリソースサービスが提供するリソースを用いて印刷サービスや帳票サービスといったサービスを利用する。

本実施形態の特徴として、クライアントアプリケーションサーバー３５０は、リソースサーバー４００が、認可サーバー５００と異なるＬＡＮ１０３に接続されていることが挙げられる。クライアントアプリケーションサーバー３５０は、リソースサーバー４００、認可サーバー５００とＷＡＮ１００を介して接続されている。本実施形態では、これらが異なる認証ドメインに属するとみなし、クライアントアプリケーションサーバー３５０とリソースサーバー４００との間のサービス連携を、通常のＯＡｕｔｈプロトコルのＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ ｇｒａｎｔ ｔｙｐｅを用いて行う。

その他のシステム構成の例として、クライアントアプリケーションサーバー３５０が、認可サーバー５００と同じＬＡＮ１０１に存在し、リソースサーバー４００がＬＡＮ１０３に存在する構成にしてもよい。この場合、リソースサーバー４００が認可サーバー５００とＷＡＮ１００を介して通信することとなる。また、クライアントＰＣ２００、クライアントアプリケーションサーバー３５０、リソースサーバー４００はそれぞれ、ＷＡＮ１００およびＬＡＮ１０１、１０２を介して接続されている。

［テーブル構成］
図１４は、クライアントアプリケーションサーバー３５０が外部メモリに記憶する管理テーブルの構成例を示す。なお、本実施形態では、各管理テーブルは、クライアントアプリケーションサーバー３５０の外部メモリに記憶する構成としているが、ＬＡＮ１０３を介して通信可能な別の記憶領域にて記憶されるように構成してもよい。

図１４（ａ）は、クライアント管理テーブル１８００の構成例を示す。クライアント管理テーブル１８００は、クライアントＰＣ２００のみから参照、更新可能なように構成されている。クライアント管理テーブル１８００は、クライアントＩＤ１８０１、クライアントシークレット１８０２、エンドポイントＵＲＬ１８０３、およびリダイレクトＵＲＬ１８０４を含む。ここで、クライアントＩＤ１８０１およびクライアントシークレット１８０２は、予め認可サーバー５００にて発行され記憶されたユーザーＩＤ１４０２およびパスワード１４０３にそれぞれ対応している。さらに、リダイレクトＵＲＬ１８０４は、認可サーバー５００のクライアント管理テーブル１４０５にクライアントＩＤ１４０６およびクライアント名１４０７と共に登録されている情報（リダイレクトＵＲＬ１４０８）と同様のデータが格納される。これら情報の登録方法としては、例えば、クライアントＰＣ２００がオンラインで登録する方法でも良いし、認可サーバー５００にて値を設定する方法でも良い。エンドポイントＵＲＬ１８０３は、認可サーバー５００が公開するＯＡｕｔｈのためのエンドポイントのＵＲＬである。

図１４（ｂ）は、親トークン管理テーブル１８０５の構成例を示す。親トークン管理テーブル１８０５は、クライアントアプリケーションサーバー３５０からのみ参照、更新可能なよう構成されている。親トークン管理テーブル１８０５は、ユーザーＩＤ１８０６、トークンＩＤ１８０７、およびリフレッシュトークンＩＤ１８０８を含む。親トークン管理テーブル１８０５の処理詳細については後述する。

［処理シーケンス］
リソースサービス連携アプリケーションを用いてリソースサービスを利用するための、本実施形態に係る認可フローを表すシーケンスについて、図５を用いて説明する。上述したように、ＯＡｕｔｈ ２．０の仕様では、多様なクライアントに応じた複数のプロトコルシーケンスを“ｇｒａｎｔ ｔｙｐｅ”と呼ぶ。図５の認可フローは、図３の認可フローとは異なり、ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ ｃｏｄｅ ｇｒａｎｔ ｔｙｐｅである。

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

アプリケーション画面については図３と同様である。ここでアプリケーション画面にアクセスするとは、例えば、Ｗｅｂブラウザ２１０上にアプリケーション画面が選択可能に表示されており、アプリケーションを選択する事を指す。アプリケーションを選択することにより、リソースオーナー３０００はクライアントアプリケーションサーバー３５０に対して認可連携サービス開始要求を送信する（Ｓ５．１）。

次に、クライアントアプリケーションサーバー３５０は、認可連携サービス開始要求を受け付けた場合、自らが保持する認可サーバー５００の認証エンドポイントのＵＲＬに対して、ＯＡｕｔｈの認可リクエストをするようにリダイレクト要求を行う（Ｓ５．２）。ここでのリダイレクト要求は、クライアントＰＣ２００のブラウザにＨＴＴＰ／１．１ ステータスコード“３０２”を用いて行われる。リダイレクト要求のＨＴＴＰ Ｌｏｃａｔｉｏｎヘッダーには、クライアントアプリケーションサーバー３５０のＩＤ、認可フローのタイプ、および認可サーバー５００の認証エンドポイントのＵＲＬが含まれる。具体的には、以下のようなリダイレクト要求となる。
ｈｔｔｐｓ：／／ａｕｔｈ．ａ０１．ｃ−ｘｘｘ．ｃｏｍ／ＣＡＵＴＨ／Ｉｄｐｓ．ａｓｐｘ？ＬＯＣＡＬＥ＝ｊａ＿ＪＰ
ＨＴＴＰメソッド： ＧＥＴ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ

リクエストパラメーターには、ｒｅｓｐｏｎｓｅ＿ｔｙｐｅとして固定文字列「ｃｏｄｅ」が設定される。また、ｃｌｉｅｎｔ＿ｉｄとして予めクライアントアプリケーションとして認可サーバー５００に登録したクライアントアプリケーションサーバー３５０のアプリケーションＩＤが設定される。更に、ｒｅｄｉｒｅｃｔ＿ｕｒｉとして予めクライアントアプリケーションとして認可サーバー５００に登録したクライアントアプリケーションサーバー３５０のＵＲＬが指定される。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成する事もできる。本実施形態では、スコープとして「リソースＡ」がリクエストされたとして説明する。

次に、クライアントＰＣ２００は、受信したリダイレクト要求に従い、認可サーバー５００に対してユーザー認証、認可の要求を行う（Ｓ５．３）。認可サーバー５００は、認可リクエストを受け付けた後、ユーザーを認証するために図１２（ａ）に示すログイン画面１６０２をクライアントＰＣ２００のＷｅｂブラウザ２１０に表示させる（Ｓ５．４）。リソースオーナー３０００は、Ｗｅｂブラウザ２１０に示されたログイン画面１６０２に対して、ユーザーＩＤおよびパスワードを入力しログインを実行する（Ｓ５．５）。

認可サーバー５００は、受け付けたユーザーＩＤおよびパスワードの組がユーザー管理テーブル１４０１に登録されている情報に一致するか否かを検証する。検証の結果、一致している場合、認可サーバー５００は、ユーザーＩＤと紐づいた認証情報を生成する。生成した認証情報は、トークン管理テーブル１４１０に格納される。すなわち、認証情報としてトークンＩＤ「ＡＨ＿０００００２」がトークンＩＤ１４１１に格納される。またトークン種別として文字列「認証トークン」がトークン種別１４１２に格納される。また認可サーバー５００で予め定められた認証トークンの有効期限が有効期限１４１３に格納される。またリクエストパラメーターに含まれるスコープ情報（ここでは「リソースＡ」）がスコープ１４１４に格納される。またログイン時に入力されたユーザーＩＤがユーザーＩＤ１４１８に格納される。またｇｒａｎｔ ｔｙｐｅとして文字列「ＡｕｔｈｎＴｏｋｅｎ」がＧｒａｎｔＴｙｐｅ１４２０に格納される。トークン管理テーブル１４１０へ認証情報が格納された後、次の処理が実行される。

認可サーバー５００は、認可リクエストに含まれているクライアントＩＤおよびリダイレクトＵＲＬの組が、クライアント管理テーブル１４０５に登録されている情報に一致しているか否かを検証する。検証の結果、一致している場合は、認可サーバー５００は、クライアント管理テーブル１４０５のクライアント名１４０７を取得し、図１２（ｂ）に示す認可確認画面１６０３を生成して、クライアントＰＣ２００のＷｅｂブラウザ２１０に表示させる（Ｓ５．６）。その際、認可サーバー５００は、認証情報をＷｅｂブラウザ２１０に対してＣｏｏｋｉｅ情報として格納して応答する。なお、本実施形態では、認可確認画面１６０３にクライアント名１４０７をアクセス元として表示している。しかしこの画面構成に限定するものではなく、例えば、クライアントの詳細な説明を追加して表示する構成や、ログインしているユーザーの情報を表示するような構成であってもよい。また認可リクエストにスコープ情報を含む場合は、スコープの範囲を説明する情報を認可確認画面１６０３に表示するような構成であってもよい。

次に、リソースオーナー３０００は、Ｗｅｂブラウザ２１０に表示された認可確認画面１６０３で許可を実行する（Ｓ５．７）。例えば、ユーザーは、認可確認画面１６０３のボタン１６０４を押下することで許可を指示することができる。認可サーバー５００は、許可の指示を受けた後、次の処理を実行する。認可サーバー５００は、トークン管理テーブル１４１０に認可コードを発行し、登録する。その際、発行したトークンのトークンＩＤ「ＡＴ＿０００００３」がトークンＩＤ１４１１に登録され、文字列「認可コード」がトークン種別１４１２に登録される。更に、予め定義された有効期限の値が有効期限１４１３に登録される。また、認可リクエスト時に受け付けたクライアントＩＤがクライアントＩＤ１４１７に登録される。ブラウザ９００からＣｏｏｋｉｅ情報として送信された認証情報に紐づくユーザーＩＤがユーザーＩＤ１４１８に登録される。そして、認可サーバー５００は、認可応答として、認可コードのトークンＩＤ「ＡＴ＿０００００３」を付与したリダイレクトＵＲＬへ、Ｗｅｂブラウザ２１０をリダイレクトするように要求する（Ｓ５．８、Ｓ５．９）。

クライアントアプリケーションサーバー３５０は、認可応答を受けた後、認可サーバー５００に対してアクセストークン要求を行う（Ｓ５．１０）。アクセストークン要求には、認可応答で取得した認可コードのトークンＩＤ「ＡＴ＿０００００３」、クライアント管理テーブル１８００のクライアントＩＤ１８０１、クライアントシークレット１８０２、およびリダイレクトＵＲＬ１８０４が含まれる。

認可サーバー５００は、アクセストークン要求を受けた後、以下の検証を行い、検証結果が正しい場合はアクセストークンを生成する（Ｓ５．１１）。認可サーバー５００は、アクセストークン要求で受けつけたクライアントＩＤおよびクライアントシークレットの組が、ユーザー管理テーブル１４０１に登録されているユーザーＩＤ１４０２およびパスワード１４０３の組に一致しているか否かを検証する。次に、認可サーバー５００は、アクセストークン要求にて受けつけた認可コードのトークンＩＤ「ＡＨ＿０００００３」が、トークン管理テーブル１４１０に登録されているか、および、設定された有効期限が有効期限内かを検証する。そして、認可サーバー５００は、アクセストークン要求で受けつけたクライアントＩＤおよびリダイレクトＵＲＬがそれぞれ、トークン管理テーブル１４１０のトークンＩＤ１４１１で特定されるクライアントＩＤ１４１７およびクライアント管理テーブル１４０５のリダイレクトＵＲＬ１４０８と一致しているかを検証する。なお、リダイレクトＵＲＬ１４０８は、クライアント管理テーブル１４０５ではなく、トークン管理テーブル１４１０にカラムを追加する構成とし、認可コードの発行時に登録して追加カラムと検証されるような構成であってもよい。

これらすべての検証が正しい場合、認可サーバー５００は、アクセストークンを生成する。生成したアクセストークンは、トークン管理テーブル１４１０に登録される。すなわち、トークンＩＤ「ＡＴ＿０００００４」がトークンＩＤ１４１１に格納される。またトークン種別として文字列「アクセストークン」がトークン種別１４１２に格納される。また認可サーバー５００で予め定められたアクセストークンの有効期限が有効期限１４１３に格納される。またトークンテーブルに登録済みの認証トークンのレコードに含まれるスコープ情報（ここでは「リソースＡ」）がスコープ１４１４に格納される。さらに、ユーザーＩＤがユーザーＩＤ１４１８に格納され、ｇｒａｎｔ ｔｙｐｅとして文字列「ＡｕｔｈｚＣｏｄｅ」がＧｒａｎｔＴｙｐｅ１４２０に格納される。

認可サーバー５００は、アクセストークン生成、およびトークン管理テーブル１４１０へのアクセストークン情報の確認が終了した後、トークンＩＤ「ＡＴ＿０００００４」およびスコープ「リソースＡ」をパラメーターに含めてクライアントアプリケーションサーバー３５０に応答する。この際、応答内容には、同時に発行したリフレッシュトークンＩＤも含まれる（Ｓ５．１２）。アクセストークンとして、発行したトークンのトークンＩＤがトークンＩＤ１４１１に、文字列「アクセストークン」がトークン種別１４１２に、有効期限１４１３が登録される。さらに、認可コード（ここではトークンＩＤ「ＡＴ＿０００００３」）から引き継ぐ情報として、クライアントＩＤ１４１７およびユーザーＩＤ１４１８が登録される。この際、アクセストークンをリフレッシュするためのリフレッシュトークンが発行され、リフレッシュトークンＩＤ１４１５およびリフレッシュ期限１４１６にその情報が登録される。

クライアントアプリケーションサーバー３５０は、アクセストークンのトークンＩＤおよびリフレッシュトークンＩＤを取得した後、トークン管理テーブル１４１０に、アクセストークンのトークンＩＤおよびリフレッシュトークンＩＤを保存する。そして、認可サーバー５００は、認可連携完了の旨を示す画面（不図示）をクライアントＰＣ２００のＷｅｂブラウザ２１０に表示させる。

クライアントアプリケーションサーバー３５０は、Ｓ５．１２においてトークンＩＤ「ＡＴ＿０００００４」およびスコープ「リソースＡ」を受け取る。そして、クライアントアプリケーションサーバー３５０は、リソースサーバー４００に対してこれらの情報をリクエストパラメーターに含めてリソースアクセス要求を行う（Ｓ５．１３）。

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

認可サーバー５００では、取得したアクセストークン（トークンＩＤ「ＡＴ＿００００４」）の有効期間が切れていないこと、および、要求されているスコープ「リソースＡ」がスコープ範囲内であることを検証し、検証の結果を返す。検証の結果、アクセス許可と判定された場合、リソースサーバー４００は、クライアントアプリケーションサーバー３５０に対して、リソースを応答する（Ｓ３．１２）。ここで、リソースは例えば、リソースサーバー４００が印刷サービスである場合は印刷可能な文書のリストであり、帳票サービスである場合は作成可能な帳票のリストである。

なお、Ｓ５．１３およびＳ５．１４にて、トークンの検証を、認可サーバー５００およびリソースサーバー４００のそれぞれで行うよう説明した。しかし、その他のシステム構成として、リソースに対するアクセス可能なアプリケーションを認可サーバー５００で管理し、全ての検証を認可サーバー５００で行うように構成してもよい。また、本実施形態ではアクセス可能なアプリケーションの判定についてアプリケーションＩＤを用いて実施するよう説明した。しかし、トークン情報から取得できるシリアル番号やクライアントＩＤを元にクライアントアプリケーションサーバー３５０を識別し、アクセスの可否を判定するように構成してもよい。また、同様に、トークン情報から取得できるスコープやユーザーＩＤを元にアクセスの可否を判定するように構成してもよい。

クライアントアプリケーションサーバー３５０は、リソース応答を受け付けた後、受信したデータを元に前述のアプリケーション画面を構成し、リソースオーナー３０００に応答する（Ｓ５．１５）。

［トークンリボケーション］
続いて本実施形態に係るトークンリボケーションについて、図６〜図９を用いて説明する。

トークンリボケーションとは、ＯＡｕｔｈ ２．０で定義された各種トークン無効化のためのプロトコルの仕様である。クライアント側からＯＡｕｔｈ ２．０で発行されたアクセストークンやリフレッシュトークンを無効化するためのリクエスト／レスポンスを定義することができる。例えば、認可サーバーの実装によってはＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔに紐づくセッションなどを一緒に切断するなどの設定も可能としている。本仕様は、例えばサービス連係解除時／ログアウト時／サービス退会時などにクライアントから各種トークンを無効化する、といったユースケースで使用されることを想定している。

本実施形態においては、図１の認可サーバー５００に存在するトークン管理テーブル１４１０が参照可能なクライアントアプリケーションサーバー３００上にトークンリボケーションＷｅｂアプリケーション３２０を配備する。そして、リソースオーナー３０００がクライアントＰＣ２００のブラウザ画面から、自身の関係するクライアント間の連携表示、および連携解除を行えるように構成する。

上述の図３と図５の認可フローに示したように、認証ドメイン間の連携に応じて、生成して管理される情報に違いがある。具体的には、認可サーバー５００で管理されるＧｒａｎｔＴｙｐｅやトークン種別の情報などである。本実施形態では、これらの情報を用いて、トークンリボケーションを制御する。

トークンリボケーションＷｅｂアプリケーション３２０は、認可サーバー５００の提供する認可クライアントの一覧取得ＡＰＩと、指定されたトークンに紐付くクライアントのトークンを消去するＡＰＩを利用して、トークンリボケーションを行う。本実施形態において、これらのＡＰＩは、クライアントアプリケーションサーバー３００のトークンリボケーションＷｅｂアプリケーション３２０からコールされるように構成している。しかし、ＡＰＩをＨＴＴＰＳによりコール可能なように構成することで、クライアントアプリケーションサーバー３５０上にトークンリボケーションＷｅｂアプリケーション３２０を配備してトークンリボケーションを行う構成としてもよい。

（リボケーション選択画面表示処理）
図７（ａ）は、トークンリボケーションＷｅｂアプリケーション３２０が、認可サーバー５００の認可クライアント一覧表示ＡＰＩをコールし、認可クライアント一覧を表示するリボケーション選択画面表示を行う際のフローチャートである。本フローは、リソースオーナー３０００であるユーザーが、クライアントＰＣ２００のＷｅｂブラウザ２１０を介してトークンリボケーションＷｅｂアプリケーション３２０にアクセスすることで開始される。本アクセスには、図３のＳ３．６や図５のＳ５．８で取得した認可トークンの情報がリクエストパラメーターとして必要となる。ここでの認可トークンの情報とは、認証トークンや認可コードのトークンＩＤなどが該当する。

トークンリボケーションＷｅｂアプリケーション３２０は、先に受信した認可トークンの情報を引数として、認可サーバー５００の認可クライアント一覧取得ＡＰＩを呼び出す（Ｓ８０１）。ここでの処理については、図７（ｂ）を用いて詳述する。トークンリボケーションＷｅｂアプリケーション３２０は、認可クライアントの一覧を取得した後、その一覧を表示する（Ｓ８０２）。そして、本処理フローを終了する。

図７（ｂ）は、認可サーバー５００における、リボケーション候補クライアントリスト作成のフローチャートである。トークンリボケーションＷｅｂアプリケーション３２０は、クライアントＰＣ２００から受信した認可トークンの情報をパラメーターとして、認可サーバー５００の認可クライアント一覧取得ＡＰＩを呼び出す。

認可サーバー５００は、受信した認可トークンが有効であるか否かを確認する（Ｓ８０３）。ここでの有効確認では、認可サーバー５００の認可サーバーモジュール５１０が、図１０（ｃ）に示すトークン管理テーブル１４１０を参照し、受信した認可トークンが含まれるか否かを判定することによりその有効性が確認される。トークンの有効確認が失敗した場合（Ｓ８０４にてＮＯ）、認可サーバーモジュール５１０は、エラーを通知し（Ｓ８０８）、本処理フローを終了する。トークンの有効確認に成功した場合（Ｓ８０４にてＹＥＳ）、認可サーバーモジュール５１０は、トークン管理テーブル１４１０の認可トークンに対応する行のユーザーＩＤ１４１８の値を参照する。そして、認可サーバーモジュール５１０は同一ユーザーＩＤにてＧｒａｎｔＴｙｐｅ１４２０が「ＡｕｔｈｚＣｏｄｅ」である行の存在を確認する（Ｓ８０５）。

ＧｒａｎｔＴｙｐｅ１４２０が「ＡｕｔｈｚＣｏｄｅ」である行が存在しない場合（Ｓ８０６にてＮＯ）、認可サーバーモジュール５１０は、空のリストを返却し（Ｓ８０９）、本処理フローを終了する。ＧｒａｎｔＴｙｐｅが“ＡｕｔｈｚＣｏｄｅ”の行が存在する場合（Ｓ８０６にてＹＥＳ）、認可サーバーモジュール５１０は、図１０（ｃ）のトークンＩＤ１４１１と、クライアントＩＤ１４１７を取得する。さらに認可サーバーモジュール５１０は、クライアント管理テーブル１４０５を参照して取得したクライアントＩＤに対応するクライアント名１４０７を取得する。そして認可サーバーモジュール５１０は、取得したトークンＩＤ、クライアントＩＤ、およびクライアント名をリストにし、トークンリボケーションＷｅｂアプリケーション３２０に返却する（Ｓ８０７）。そして、本処理フローを終了する。

本発明の特徴は、トークン管理テーブル１４１０のＧｒａｎｔＴｙｐｅを参照して「ＡｕｔｈｚＣｏｄｅ」以外のトークンを、リボケーション対象としないことである。つまり、「ＡｕｔｈｚＣｏｄｅ」に手示される異なる認証ドメイン間にて用いられているトークンについては削除し、それ以外のトークンを削除しないことで同一認証ドメイン内での不整合を防ぐ。

図９は、クライアントＰＣ２００のＷｅｂブラウザ２１０上に表示された、トークンリボケーションＷｅｂアプリケーション３２０のＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）１０００の例である。表１００１は、トークンリボケーションＷｅｂアプリケーション３２０が図７（ｂ）に示すフローチャートにより認可サーバー５００から取得したトークンＩＤ、クライアントＩＤ、およびクライアント名のリストを表示している。表１００１は、クライアントＩＤ１００２、クライアント名１００３、およびＡｃｔｉｏｎ１００４を含む。Ａｃｔｉｏｎ１００４には、取得したトークンＩＤに対してリボケーションを実行するためのリボケーションボタン１００５が表示される。つまり、リボケーションボタン１００５が選択可能に表示された状態では、対応するトークンを削除可能となる。リボケーションボタン１００５は、後述するトークンリボケーションが成功するとグレーアウトされる。この場合には、対応するトークンは削除不可となる。ＧＵＩ１０００により、アクセストークンを削除する指示を可能とする削除画面を提供する。

（リボケーション実行画面表示処理）
図８（ａ）は、トークンリボケーションＷｅｂアプリケーション３２０が、認可サーバー５００の指定されたトークンに紐付くクライアントのトークンを消去するＡＰＩをコールし、トークンリボケーションを実行する際のフローチャートである。本フローチャートは、リソースオーナー３０００が、図９に示すＧＵＩ１０００上でリボケーションボタン１００５を押下することにより開始される。

リボケーションボタン１００５が押下されると、トークンリボケーションＷｅｂアプリケーション３２０は、リボケーションを実行するために、認可サーバー５００の指定されたトークンに紐付くクライアントのトークンを消去するＡＰＩをコールする（Ｓ９０１）。ここでは、本工程の詳細については、図８（ｂ）を用いて詳述する。トークンリボケーションＷｅｂアプリケーション３２０は、トークンリボケーションを行った後のクライアントの一覧を取得し、その一覧を表示する（Ｓ９０２）。そして、本処理フローを終了する。

図８（ｂ）は、認可サーバー５００における、指定されたトークンに紐付くクライアントのトークンを消去のフローチャートである。トークンリボケーションＷｅｂアプリケーション３２０は、認可トークンの情報をパラメーターにして、認可サーバー５００の指定されたトークンに紐付くクライアントのトークンを消去するＡＰＩを呼び出す。

認可サーバー５００は、受信した認可トークンが有効であるか否かを確認する（Ｓ９０３）。ここでの有効確認は、認可サーバー５００の認可サーバーモジュール５１０が、図１０（ｃ）のトークン管理テーブル１４１０を参照し、受信した認可トークンが含まれるか否かを確認することにより行われる。

トークンの有効確認に失敗した場合（Ｓ９０４にてＮＯ）、認可サーバーモジュール５１０はエラーを通知し（Ｓ９１１）、本処理フローを終了する。トークンの有効確認に成功した場合（Ｓ９０４にてＹＥＳ）、認可サーバーモジュール５１０は、トークン管理テーブル１４１０にて認可トークンに対応する行のユーザーＩＤ１４１８の値を参照する。そして、認可サーバーモジュール５１０は、同一ユーザーＩＤのトークンから受信した認可トークンに紐付くクライアントＩＤを抽出する（Ｓ９０５）。さらに認可サーバーモジュール５１０は、クライアントＩＤが一致するトークンを抽出する（Ｓ９０６）。

認可サーバーモジュール５１０は、Ｓ９０６で抽出したトークンのうち、トークン種別１４１２が「認可コード」であるトークンを削除する（Ｓ９０７）。そして、認可サーバーモジュール５１０は、Ｓ９０７にてトークンの削除が成功したか否かを判定する（Ｓ９０８）。トークン削除に失敗した場合（Ｓ９０８にてＮＯ）、認可サーバーモジュール５１０はエラーを通知し（Ｓ９１１）、本処理フローを終了する。トークン削除に成功した場合（Ｓ９０８にてＹＥＳ）、認可サーバーモジュール５１０は、更に抽出したトークンのうち、ＧｒａｎｔＴｙｐｅ１４２０が「ＡｕｔｈｚＣｏｄｅ」のトークンを削除する（Ｓ９０９）。そして、認可サーバーモジュール５１０は、Ｓ９０９にてトークンの削除が成功したか否かを判定する。トークンの削除に失敗した場合（Ｓ９１０にてＮＯ）、認可サーバーモジュール５１０はエラーを通知し（Ｓ９１１）、本処理フローを終了する。トークンの削除に成功した場合（Ｓ９１０にてＹＥＳ）、認可サーバーモジュール５１０はトークン削除の成功を通知し（Ｓ９１２）、本処理フローを終了する。

本実施形態のトークンリボケーションの特徴は、リソースオーナー３０００の指定したトークンに紐付くトークンをトークン管理テーブルから削除する際に、トークン種別が「認可コード」でなく、かつ、ＧｒａｎｔＴｙｐｅが「ＡｕｔｈｚＣｏｄｅ」でもないトークンを削除しない点である。先に詳述した、同一認証ドメイン内においてリソースサービスを利用する場合に用いられるトークンがこれに相当する。この場合、トークン種別１４１２としては「認証トークン」と「アクセストークン」が存在し、ｇｒａｎｔ ｔｙｐｅとしては「ＡｕｔｈｎＴｏｋｅｎ」のみが存在する。したがって、本願発明は、同一認証ドメインにおいてリソースサービスを利用する場合に用いられるトークンに対してはリボケーションが行われないことを特徴とする。

図６は、クライアント表示／非表示、クライアント連携解除可／不可のポリシーの対応関係を示す表である。表７０１は、トークンリボケーションＷｅｂアプリケーション３２０のＧＵＩ１０００に対応する。“クライアント連携解除”とは、認可サーバー５００が管理するトークン管理テーブル１４１０の中からトークンの情報を削除し、クライアントとサーバーとが連携できない状態にすることである。すなわち、クライアントアプリケーションサービスが有するアクセストークンを無効化し、クライアントアプリケーションサーバー３００、３５０からのリソースサーバー４００へのアクセスを不可にすることである。

表７０１の一行目は、例えば、トークン管理テーブル１４１０のクライアントＩＤ１４１７が「Ｃｌｉｅｎｔ＿Ｃ」の場合に相当する。「Ｃｌｉｅｎｔ＿Ｃ」は、ＧｒａｎｔＴｙｐｅ１４２０が「ＡｕｔｈｎＴｏｋｅｎ」のトークンと、「ＡｕｔｈｚＣｏｄｅ」のトークンの両者が存在する。この場合、Ｗｅｂブラウザ２１０に表示されたトークンリボケーションＷｅｂアプリケーション３２０のＧＵＩ１０００は、クライアントＩＤ「Ｃｌｉｅｎｔ＿Ｃ」の表示を行う。そして、表１００１にてＡｃｔｉｏｎ１００４のボタンが押下された場合、ＧｒａｎｔＴｙｐｅ１４２０が「ＡｕｔｈｚＣｏｄｅ」であるトークン「ＡＨ＿０００００７」、「ＡＴ＿０００００８」、「ＡＴ＿０００００９」が消去される。一方、ＧｒａｎｔＴｙｐｅ１４２０が「ＡｕｔｈｎＴｏｋｅｎ」の「ＡＨ＿０００００５」「ＡＴ＿０００００６」は消去されない。

表７０１の二行目は、クライアントＩＤ１４１７が「Ｃｌｉｅｎｔ＿Ｂ」の場合に相当する。「Ｃｌｉｅｎｔ＿Ｂ」は、ＧｒａｎｔＴｙｐｅ１４２０が「ＡｕｔｈｚＣｏｄｅ」のトークンのみが存在する。この場合、トークンリボケーションＷｅｂアプリケーション３２０のＧＵＩ１０００は、クライアントＩＤ「Ｃｌｉｅｎｔ＿Ｂ」の表示を行う。そして、Ａｃｔｉｏｎ１００４のボタンが押下された場合、トークン管理テーブル１４１０のＧｒａｎｔＴｙｐｅ１４２０が「ＡｕｔｈｚＣｏｄｅ」であるトークン「ＡＨ＿０００００２」、「ＡＴ＿０００００３」、「ＡＴ＿０００００４」が消去される。その結果、クライアントアプリケーションサーバー３００は、リソースサーバー４００のリソースを取得することができないようになり、クライアントアプリケーションサーバー３００とリソースサーバー４００の間の連携は解除されることになる。

表７０１の三行目は、トークン管理テーブル１４１０のクライアントＩＤ１４１７が「Ｃｌｉｅｎｔ＿Ａ」の場合に相当する。「Ｃｌｉｅｎｔ＿Ａ」は、ＧｒａｎｔＴｙｐｅ１４２０が「ＡｕｔｈｎＴｏｋｅｎ」のトークンのみが存在する。この場合、Ｗｅｂブラウザ２１０に表示された、トークンリボケーションＷｅｂアプリケーション３２０のＧＵＩ１０００は、クライアントＩＤ「Ｃｌｉｅｎｔ＿Ａ」の表示を行わない。なお、本実施形態では表示を行わないとしたが、表示は行うが図９のリボケーションボタン１００５をグレーアウトして押下できないようにしてもよいし、リボケーションボタン１００５を表示しないようにしてもよい。

表７０１の四行目は、トークン管理テーブル１４１０に何らトークンが登録されていないクライアントを示しており、この場合もＧＵＩ１０００には表示されないこととなる。

以上により、ユーザーによる同一認証ドメイン内で用いられるアクセストークンの削除を制限し、サービス間連携の際にデータ不整合が発生することを防止することができる。

＜第二の実施形態＞
続いて、ユーザーから画像形成装置等の装置に対して権限を一括して委譲した際に、トークンの削除制御に関する実施形態について説明する。なお、認可フローは第一の実施形態にて述べた内容と同様であるため、ここでは説明を省略する。

（サブセットトークンのリボケーション）
本明細書において、リソースオーナー３０００たるユーザーが、画像形成装置などの装置に対して権限委譲した場合のトークンを“親トークン”と称する。

まず、本実施形態に係る課題について説明する。例えば、画像形成装置上に印刷アプリケーションおよび帳票アプリケーションが存在する場合を考える。この構成において、ユーザーが印刷アプリケーションもしくは帳票アプリケーションからリソースサービスを利用する場合、リソースサービスを利用するための認可を各アプリケーションに個別に与える必要がある。その一方で、ユーザーの立場で考えると、同一の画像形成装置からリソースサービスを利用する場合には、例えば、一度の認可操作でそれぞれのアプリケーションでリソースサービスを利用できるようになった方が、利便性が高い。

そこで、アプリケーションに権限を委譲させる際、ユーザーに代わって画像形成装置がアプリケーションに権限を委譲することで、ユーザーの認可操作の回数を低減させる。即ち、ユーザーは画像形成装置に権限を委譲した段階で、アプリケーションにも権限を委譲することを認める構成とする。

なお、本実施形態では、画像形成装置に権限を委譲する際にユーザーに認可操作を行わせるが、画像形成装置が各アプリケーションに権限を委譲する際にはユーザーに認可操作を行わせない。ただし、認可操作を一度で済ませる手段として、画像形成装置が取得した親トークンを、画像形成装置上のアプリケーションで共有できるようにすると、親トークンを共有する全てのアプリケーションが全てのリソースサービスにアクセス可能となり好ましくない。また、各アプリケーションが共有された親トークンを用いてリソースサービスにアクセスした場合、リソースサービス側にてアクセス元のアプリケーションが特定できず、利用の可否を判定する事ができない。

その結果、例えば、リソースサーバーが特定のアプリケーションからの利用のみを許可したい場合であっても、アプリケーションを特定できず、利用の可否の判定ができない。これは、リソースサービスで管理している情報がユーザーの機密性が高い情報を取り扱うサービスである場合に、不特定のアプリケーションからの利用を許可すると情報の漏洩経路になるリスクがあるため望ましくない。

また、想定していないアプリケーションからの接続を許可するとしても、どのようなアプリケーションからのアクセスであったのかの記録を残したいという要求も存在する。これは、例えば、より利用頻度の高いアプリケーションを特定し、そのアプリケーションの利用シーンに合わせて機能を拡張していくといった、リソースサービスの機能拡張への対応を決める上で有用な情報である。

そこで本実施形態では、個々のリソースサービス連携アプリケーションは、親トークンを直接用いるのでなく、親トークンに含まれる情報を継承しつつ、再委譲においてアプリケーションを特定可能な情報を付与して発行されるトークンを用いる。ここで、画像形成装置が、親トークンの情報から派生して継承されたトークンであって、アプリケーションを特定可能な情報を付与して権限を再委譲した場合に発行されるトークンを“子トークン”と称する。また、複数の子トークンをまとめてサブセットトークンと記載する。

子トークンは、ユーザーによる認可処理を介さずに権限を委譲された画像形成装置等から発行されるが、この子トークンは、リボケーションにて処理の対象外とする。

［システム構成］
図１５は、本実施形態に係る認可システムの構成例を示す。ＷＡＮ１００ではＷＷＷシステムが構築されている。ＬＡＮ１０１は、各構成要素を接続する。

認可サーバー５００は、ＯＡｕｔｈを実現し、認可サービスモジュールが設置されている。リソースサーバー４００には、印刷サービスや帳票サービスに対応したリソースサービスが設置されている。画像形成装置６００には、１または複数のリソースサービス連携アプリケーションがインストールされている。ユーザーはリソースサービス連携アプリケーションを用いてリソースサービスを利用する。また認可サーバー５００、リソースサーバー４００、および画像形成装置６００は、それぞれＷＡＮ１００およびＬＡＮ１０１を介して接続されている。なお認可サーバー５００、リソースサーバー４００、および画像形成装置６００はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また、認可サーバー５００およびリソースサーバー４００は同一のサーバー上に構成されていてもよい。

ここで、画像形成装置６００は、図１に示したクライアントアプリケーションサーバー３００の機能とクライアントＰＣ２００の機能とを備えるものとする。そして、子トークンは、このような機能を備える画像形成装置６００にて用いられる。なお、クライアント側の装置は、画像形成装置に限定するものではなく、その他のデバイスであっても構わない。

［テーブル構成］
図１６は、認可サーバー５００の図１０（ｃ）に示すトークン管理テーブル１４１０に対し、親トークンおよび子トークンが発行された場合の例を示すトークン管理テーブル２０００である。トークン管理テーブル２０００は、トークンＩＤ２００１、トークン種別２００２、有効期限２００３、スコープ２００４、リフレッシュトークンＩＤ２００５、リフレッシュ期限２００６、クライアントＩＤ２００７、ユーザーＩＤ２００８、アプリケーションＩＤ２００９、およびｇｒａｎｔ ｔｙｐｅ２０１０を含む。本実施形態のトークン管理テーブル１４１０と、第一の実施形態にて説明した図１０（ｃ）と異なる点は、トークン種別２００２において、「親トークン」もしくは「子トークン」の情報を識別可能に設定する点である。したがって、リボケーションにおいても、この値を参照して制御を行う。

［トークンリボケーション］
本実施形態の場合のトークンリボケーションは、基本的に第一の実施形態と同様に行われる。しかし、クライアントが画像形成装置であると判定された場合、図８（ｂ）のＳ９０９においてトークンは削除されない。ここでの例の場合、トークン管理テーブル２０００のクライアントＩＤが「ｄｅｖ０００００００１」である場合には、たとえＧｒａｎｄＴｙｐｅが「ＡｕｔｈｚＣｏｄｅ」であってもそのトークンは削除されない。

これは、画像形成装置による印刷の定時実行などのような画像形成装置内のアプリケーションが子トークンを使用して処理を行っている場合などを想定し、このような場合に不用意にトークンを無効化してしまわないようにするためである。例えば、子トークンを削除できてしてしまう構成の場合には、ユーザーが関与しないうちに生成された子トークンを削除したことで、システム内にて不整合が生じる可能性があるためである。なお、子トークンを用いて行う処理は、印刷の提示実行に限定されるものではなく、ユーザーが直接関与せずに実行されるバックグラウンドの処理などを含んでも構わない。

これにより、第一の実施形態の効果に加え、不整合の生じない認可システムを柔軟に構成できる。

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

Claims (9)

1. 認証情報の入力を求めることなくサービスの提供を可能とするための認可情報を管理する認可サーバーシステムであって、
   前記認可情報を管理する管理手段と、
   前記管理手段にて管理する認可情報を削除するための削除画面の要求を受信したことに応じて、ユーザーの認可操作が行われたことで生成された認可情報を含み、前記ユーザーの認可操作が行われずに生成された認可情報を含まない削除画面を提供する提供手段と、
   前記削除画面を介して削除の指示を受信したことに応じて、前記管理手段にて管理された認可情報を削除する削除手段と、
   を有することを特徴とする認可サーバーシステム。
2. 前記管理手段は、前記認可情報を認可を受けたクライアントに対応付けて管理し、
   前記削除画面は、クライアントごとに認可情報の削除の指示が可能なように表示を行うことを特徴とする請求項１に記載の認可サーバーシステム。
3. 前記削除手段は、前記削除画面を介してクライアントに対する認可情報を削除する指示を受け付けた場合、当該クライアントに対応付けられた認可情報のうち、前記ユーザーの認可操作が行われたことで生成された認可情報を削除し、前記ユーザーの認可操作が行われずに生成された認可情報を削除しないことを特徴とする請求項２に記載の認可サーバーシステム。
4. 前記削除画面は、前記ユーザーの認可操作が行われずに生成された認可情報のみが対応付けられたクライアントは表示しないことを特徴とする請求項２または３に記載の認可サーバーシステム。
5. 前記管理手段は、クライアントがユーザーから委譲された第一の権限に対応する第一の認可情報と、前記第一の権限から派生して再委譲された第二の権限に対応して生成された第二の認可情報とを識別可能に管理し、
   前記削除手段は、前記削除画面を介して削除の指示を受け付けた場合、前記第二の認可情報は削除しないことを特徴とする請求項１乃至４のいずれか一項に記載の認可サーバーシステム。
6. 前記ユーザーの認可操作が行われたことで生成された認可情報は、当該認可情報を用いてサービスの提供を受ける装置と、当該サービスを提供する装置とが異なるセキュリティドメインに属している場合に生成されていることを特徴とする請求項１乃至５のいずれか一項に記載の認可サーバーシステム。
7. 前記ユーザーの認可操作が行われずに生成された認可情報は、認可情報を用いてサービスの提供を受ける装置と、当該サービスを提供する装置とが同一のセキュリティドメインに属する場合に生成されていることを特徴とする請求項１乃至６のいずれか一項に記載の認可サーバーシステム。
8. 認証情報の入力を求めることなくサービスの提供を可能とするための認可情報を管理する認可サーバーシステムの制御方法であって、
   前記認可情報を記憶部にて管理する管理工程と、
   前記記憶部にて管理する認可情報を削除するための削除画面の要求を受信したことに応じて、ユーザーの認可操作が行われたことで生成された認可情報を含み、前記ユーザーの認可操作が行われずに生成された認可情報を含まない削除画面を提供する提供工程と、
   前記削除画面を介して削除の指示を受信したことに応じて、前記記憶部にて管理された認可情報を削除する削除工程と、
   を有することを特徴とする制御方法。
9. コンピュータを、
   認証情報の入力を求めることなくサービスの提供を可能とするための認可情報を管理する管理手段、
   前記管理手段にて管理する認可情報を削除するための削除画面の要求を受信したことに応じて、ユーザーの認可操作が行われたことで生成された認可情報を含み、前記ユーザーの認可操作が行われずに生成された認可情報を含まない削除画面を提供する提供手段、
   前記削除画面を介して削除の指示を受信したことに応じて、前記管理手段にて管理された認可情報を削除する削除手段、
   として機能させるためのプログラム。

Images