JP2017027459A - 権限委譲システム、その制御方法、認可サーバおよびプログラム - Google Patents

Abstract

【課題】クライアントＩＤや、シークレットを変更することなしに、漏えいしたリフレッシュトークンを無効にすることで、より安全性を高めた権限委譲システムを提供する。
【解決手段】権限委譲システムは、サービスを提供するリソースサーバ１０３と、リソースサーバ１０３が有するユーザのデータへのアクセスを、認可トークンに基づいてクライアント装置である連携サーバ１０４に認めるための権限委譲を行う認可サーバ１０２とを含む。認可サーバ１０２は、権限委譲を求める権限委譲要求を受信し、受信した権限委譲要求に基づいて、リフレッシュトークンを検索する。そして、検索したリフレッシュトークンが有効であるか否かを判断し、有効と判断された場合に、リフレッシュトークンを無効化する。
【選択図】図１

Description

本発明は、権限委譲システム、その制御方法、認可サーバおよびプログラムに関する。

近年、インターネット上に展開された所謂クラウドサービスの利用が拡大している。例えば、ＣＲＭ（Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ）サービスを利用して顧客関係を管理する事がビジネスの現場で拡大している。また、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）を利用して、リアルタイムに情報発信、情報収集を行う事が、個人だけでなく、ビジネスの現場でも拡大している。
また、これら多数のクラウドサービスは個々にＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を公開している。これにより、他のアプリケーションやクラウドサービスからＡＰＩを介してサービスが提供する機能を利用する事が可能となっている。これにより、複数のクラウドサービスが公開する複数のＡＰＩを組み合わせ、あたかも一つのＷｅｂサービスのように構成するマッシュアップという機能が広がりつつある。サービスの提供者からすると、クラウドサービス間の連携の仕組みは容易に実装できるものが好ましい。

その一方で、複数のクラウドサービスを連携するマッシュアップ機能の利用機会の増加によって、ユーザが望んだ以上の情報が複数のクラウドサービス間で交換され、ユーザデータや個人情報が漏えいするリスクが増加する。本来、各クラウドサービスにて必要以上にユーザデータ、個人情報等を取得することは望ましくない。さらには、ユーザが連携を望まないクラウドサービスに対してユーザデータ、個人情報が提供される恐れが高まる。
このような状況において、ＯＡｕｔｈ ２．０と呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈ ２．０の詳細については、以降で説明する。特許文献１にはＯＡｕｔｈ ２．０を利用した技術が開示されている。

特開２０１４−０６７３７９号公報

しかしながら、現状のＯＡｕｔｈ ２．０における認可トークンの有効期間が経過した後にユーザの認可操作なしにリフレッシュする構成には、セキュリティの面で課題がある。例えば、クライアントＩＤ、シークレットおよびリフレッシュトークンが漏えいした場合、悪意のあるクライアントによって、認可操作なしに認可トークンが取得され、ユーザのリソースが取得されてしまう。また、クライアントのクライアントＩＤ、シークレットおよびリフレッシュトークンの漏えいに対応するために、クライアント内で管理しているクライアントＩＤや、シークレットを変更することは、クライアントの実装や、運用に大きな影響を与えることになる。

本発明は、クライアントＩＤや、シークレットを変更することなしに、漏えいしたリフレッシュトークンを無効にすることで、より安全性を高めた権限委譲システムを提供することを目的とする。

上記課題を解決するために、本発明は、サービスを提供するリソースサーバと、前記リソースサーバが有するユーザのデータへのアクセスを認可情報に基づいてクライアント装置に認めるための権限委譲を行う認可サーバとを含む権限委譲システムであって、前記権限委譲を求める権限委譲要求を受信する受信手段と、前記権限委譲要求に基づいて、更新認可情報を検索する検索手段と、前記検索手段により検索された前記更新認可情報が有効であるか否かを判断する判断手段と、前記判断手段において有効と判断された場合、検索された前記更新認可情報を無効化する無効化手段とを備えることを特徴とする。

本発明によれば、クライアントＩＤや、シークレットを変更することなしに、漏えいしたリフレッシュトークンを無効にすることで、より安全性を高めた権限委譲システムを提供することが可能となる。

システム構成図である。 各装置のハードウェア構成図である。 各装置のソフトウェアモジュール構成図である。 ＯＡｕｔｈ ２．０を利用した認可のシーケンス図である。 ログイン画面の一例を示す図である。 ＯＡｕｔｈ ２．０を利用したリフレッシュのシーケンス図である。 認可確認処理を説明するフローチャートである。 認可確認処理を説明するフローチャートである。 認可確認画面の一例を示す図である。 第２実施形態における認可確認処理を説明するフローチャートである。 第２実施形態における認可確認処理を説明するフローチャートである。 第２実施形態における認可解除および拒否解除画面の一例を示す図である。 第２実施形態における認可確認画面の一例を示す図である。

まず、ＯＡｕｔｈ ２．０について説明する。ＯＡｕｔｈ ２．０によれば、あるサービスＡが管理するユーザのデータを保持するＡＰＩに対して、そのユーザから認められたサービスＢがアクセスすることができる。このときサービスＡは、サービスＢからアクセスされる範囲を明らかにした上で、サービスＢによるＡＰＩへのアクセスに対してユーザの明示的な認可を得ることになっている。ユーザが明示的に認可を行うことを認可操作と称する。
ユーザが認可操作を行うと、サービスＢはサービスＡからアクセスを認められたことを証明するトークン（以下、認可トークンと称する）を受け取り、以降のサービスＡのＡＰＩへのアクセスはその認可トークン（認可情報）を用いて実現できる。このユーザの認可操作によってユーザのリソースに対するアクセスをサービスＢに認める行為を権限委譲と称する。
ここで認可トークンを用いるとサービスＢは、ユーザの認証情報なしに、認可を行ったユーザの権限でサービスＡのＡＰＩにアクセスできる。そのため、ユーザから認可を受け認可トークンを取得したサービスＢは、その認可トークンを厳重かつ適正に管理する責務を負う。また、この認可トークンは有効期間が設定されており、その有効期間内であれば、ＡＰＩを利用することが可能である。

ＯＡｕｔｈ ２．０では、サービスＢの成り済ましを防ぐために、サービスＢを認証する必要がある。このサービスＢを認証するために、サービスＡは予めサービスＢの認証情報、より具体的にはクライアントＩＤおよびシークレットを発行、管理し、さらにはサービスＢにそれら認証情報を設定しておく必要がある。以降、サービスＡからみたサービスＢのことをクライアントと称する。

また、ＯＡｕｔｈ ２．０では、ユーザの認可操作、認可トークン発行、およびクライアントの認証を行う認可サーバと、ユーザのデータをリソースとして管理し、ＷｅｂサービスとしてＡＰＩを公開するリソースサーバを分けて構成する事が可能である。その場合、クライアントはユーザからの権限委譲を受け、認可サーバから認可トークンを取得し、その認可トークンを用いてリソースサーバのＡＰＩを利用する。そして、リソースサーバは、取得した認可トークンを認可サーバに検証依頼し、結果、アクセスの許可を得られた場合にのみリソースへのアクセスを許可し、クライアントにデータを応答するよう構成される。認可サーバでの検証としては、たとえば、上述の認可トークンが有効期間内であるかを検証する。

上述の通り、ＯＡｕｔｈ ２．０では、ユーザの認可操作を元に、認可トークンが発行され、その認可トークンを用いることにより、認可トークンの有効期間内であれば、他のサービスのＡＰＩを利用することが可能となる。つまり、認可トークンの有効期間が経過し、無効となった場合は、再度、認可トークンを発行しなければＡＰＩを利用することができない。しかしながら、認可トークンを再発行するために、毎回ユーザに認可操作を要求することは煩雑であり、利便性に欠ける。
そこで、ＯＡｕｔｈ ２．０では、認可トークンをユーザの認可操作なしで再発行する、つまりリフレッシュするためのプロトコルが策定されている。リフレッシュでは、認可トークンをリフレッシュするためリフレッシュトークン（更新認可情報）を用いる。このリフレッシュトークンは通常、認可トークンと比べて長期間有効である。クライアントは上述のクライアントＩＤ、シークレット、リフレッシュトークンを認可サーバに送信することでユーザの認可操作なしで新しい有効期間の認可トークンを取得することができる。

ＯＡｕｔｈ ２．０では、リフレッシュトークンの発行、管理について二つの方式が定義されており選択可能となっている。第一の方式は、認可操作の結果取得される認可コードを利用して認可トークンを取得する際にあわせて取得されるリフレッシュトークンが固定の方式である。その後、後述するリフレッシュフローが何度実行されても、リフレッシュトークンが変更されることがない。つまり、リフレッシュ対象が認可トークンのみの方式である。第二の方式は、リフレッシュトークンが動的の方式である。リフレッシュフローが実行されるたびに、新しいリフレッシュトークンが発行され、古いリフレッシュトークンが無効になる。つまり、認可トークンだけでなくリフレッシュトークンも更新される方式である。リプレイ攻撃を考慮すると、リフレッシュトークンもリフレッシュする第二の方式のほうがよりセキュアだと考えられる。
本願発明の各実施形態における権限委譲システムでは、リフレッシュトークンの発行、管理の方式として第二の方式に対してより有用であるため、第二の方式で説明する。しかしながら第二の方式に制限するものではなく、第一の方式においても、実施することは可能である。

初めに、本願発明の各実施例にて用いられる用語の定義について説明する。
サービスとは、サーバ上で起動するソフトウェアがクライアントからの要求に従い実行されることでそのクライアントに対して提供される機能のことを指す。なお、そのソフトウェアであるＷｅｂアプリケーションのこともサービスと呼ぶ場合もある。本実施の形態においては、クラウドサービスとして連携サーバが提供するサービスと、リソースサーバが提供するサービスの２つのサービスがあり、ユーザは、端末を介して連携サーバが提供するサービスを利用している想定で説明している。また、リソースサーバはＷｅｂサービスとしてＡＰＩを公開しており、連携サーバはこのＡＰＩを利用する事でユーザに対してマッシュアップ機能を提供している想定にて説明する。つまり、リソースサーバから見た場合、連携サーバはクライアントに相当する。

無論、これは本実施の形態を説明する上での想定であり、連携サーバ、リソースサーバ、および端末はおのおの単数で構成される事を限定しているわけではない。例えば、複数台から構成されたサーバ群がサービスを提供していても良い。よって、本願発明でサーバシステムと称した場合、１台または複数台から構成されるサーバを指すこととする。
なお、連携サーバが、リソースサーバのＡＰＩを利用するためには、後述するＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔによるユーザの認可操作を伴った権限委譲が必要となる。言い換えると、ユーザから権限委譲を受けた連携サーバは、リソースサーバのＡＰＩを利用する事ができるようになる。

（第１実施形態）
本実施の形態に係る権限委譲システムは、図１に示すような構成のネットワーク上に実現される。
ＷＡＮ１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋであり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋである。
認可サーバ１０２はＯＡｕｔｈ ２．０を実現するための認可サーバであり、認可サーバモジュールが設置されている。リソースサーバ１０３はリソースサーバであり、Ｗｅｂサービスとして公開されるＡＰＩを備えるリソースサーバモジュールが設置されている。連携サーバ１０４は連携サーバであり、連携サーバモジュールが設置されている。連携サーバモジュールは、リソースサーバ１０３が備えるリソースサーバモジュールが公開するＡＰＩを利用する事で、自身が提供するサービスと合わせてマッシュアップ機能をユーザに提供する。

端末１０５は端末であり、Ｗｅｂブラウザ１０６が設置されている。例えば、ＰＣやスマートフォンと呼ばれる携帯端末等である。ユーザはＷｅｂブラウザ１０６を用いて連携サーバ１０４、認可サーバ１０２と通信する。また認可サーバ１０２、リソースサーバ１０３はＬＡＮ１０１を介して接続されている。また、認可サーバ１０２、リソースサーバ１０３、連携サーバ１０４、および端末１０５は、それぞれＷＡＮ１００を介して通信可能に接続されている。また認可サーバ１０２は、不図示のデータベースサーバとＬＡＮ１０１を介して接続しており、認可サーバモジュールが利用するデータを格納するよう構成してもよい。さらには、リソースサーバ１０３、認可サーバ１０２も同一のサーバ上に構成されていてもよい。また、連携サーバ１０４を独立したサーバではなく、アプリケーションとして構成することも考えられる。例えば、リソースサーバ１０３や認可サーバ１０２がＰａａＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）として構成され、連携サーバ１０４をそのプラットフォーム上で動作するアプリケーションサービスとして構成する。

本実施形態に係る権限委譲システムは、図２に示すような構成のサーバおよび端末から成るシステム上に実現される。
図２は、認可サーバ１０２、リソースサーバ１０３、連携サーバ１０４、および端末１０５のハードウェア構成を示す。なお、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当する。本実施形態の各サーバおよび端末には一般的な情報処理装置のハードウェア構成やＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）として提供される除法処理装置の仮想的なハードウェア構成を適用できる。

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

ＩａａＳとして提供される仮想的な情報処理想定の場合においては、ＫＢＣ２０５、ＣＲＴＣ２０６等を備えず、ＮＣ２０８を介して接続される端末に備えるキーボード２０９や、ＣＲＴディスプレイ２１０から操作されるよう構成される。
なお、後述の全ての説明においては、特に断りのない限りサーバや端末における実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は外部メモリ２１１にインストールされたアプリケーションプログラムである。

図３は本実施の形態に係る、認可サーバ１０２、リソースサーバ１０３、連携サーバ１０４それぞれのモジュール構成を示す図であり、各々がモジュールを実行することでサービスを提供する。なお認可サーバ１０２、リソースサーバ１０３、連携サーバ１０４は図２のものと同一である。
認可サーバ１０２は認可サーバモジュール３０１、ＨＴＴＰサーバモジュール３０２を持つ。ＨＴＴＰサーバモジュール３０２はＷＡＮ１００を介して接続する端末１０５に設置されたＷｅｂブラウザ１０６とのＨＴＴＰ通信を行うためのモジュールである。また、ＳＳＬ／ＴＬＳによる通信が可能に構成されており、不図示の証明書ストアを持つ。また、本実施例では、後述する認可要求を受け付けた場合に、要求元に対してユーザＩＤ、パスワードによるユーザ認証を要求するよう構成している。

次に、認可サーバモジュール３０１はＨＴＴＰサーバモジュール３０２上で、もしくは、連携して動作するＷｅｂアプリケーションであり、ＨＴＴＰサーバモジュール３０２を介してＷｅｂブラウザ１０６からの要求を受け付け、処理し、応答する。その際、本実施例では、ＨＴＴＰサーバモジュール３０２にて、ユーザ認証を受け付け、要求元の認証に成功した場合、認証したユーザ情報を紐づけた、認証トークンを生成し、認可サーバモジュール３０１に通知するよう構成されている。

ここで、認証トークンとは、ユーザを認証し、ログインしている事を示す、もしくは認証されているかを検証するためのトークンであり、この認証トークンを利用する事でユーザを識別する事が可能となる。後述の認可トークンは、認証されたユーザが、さらに、認可操作をおこなった対象のクライアントが、ユーザの権限をもって、ユーザに成り代わってアクセスを許可した事を示すためのトークンであり、両者は異なる。特に顕著なのは、認証トークンの場合はユーザの確認を目的としているが、認可トークンは権限の確認を目的としている点である。
また、認可トークンは、認可コードを用いて取得し、クライアントがＡＰＩを利用するための権限を持つことを示すトークンである。さらには、リフレッシュトークンは、同じく認可コードを用いて取得し、認可コードを再発行することが可能であることを示すトークンである。ＨＴＴＰサーバモジュール３０２、および認可サーバモジュール３０１における処理の詳細は後述する。

認可サーバモジュール３０１はＬＡＮ１０１を介してリソースサーバモジュール３０３からの認可トークン検証処理を受け付け、処理し、応答するよう構成されている。この認可トークン検証処理は、ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）として構成する事も可能であるし、ＨＴＴＰサーバモジュール３０２を介してＬＡＮ１０１内で通信可能なＷｅｂサービスのＡＰＩとして構成する事も可能である。

リソースサーバ１０３はリソースサーバモジュール３０３を持つ。リソースサーバモジュールは不図示のＨＴＴＰサーバモジュール上で動作するよう構成する事も可能である。リソースサーバモジュール３０３はＷｅｂサービスとして公開するＡＰＩを備えており、後述する連携サーバ１０４からのリソース要求を受け付け、処理し、応答する。また、リソースサーバモジュール３０３は認可サーバモジュール３０１に対してＬＡＮ１０１を介して後述の認可トークン検証処理を要求する。

連携サーバ１０４は連携サーバモジュール３０４を持つ。連携サーバモジュール３０４は不図示のＨＴＴＰサーバモジュール上で動作するよう構成する事も可能である。連携サーバモジュール３０４はＷｅｂアプリケーションであり、Ｗｅｂブラウザ１０６からの要求を受け付け、処理し、応答する。また、連携サーバモジュール３０４は、リソースサーバモジュール３０３が公開するＷｅｂサービスのＡＰＩを呼び出すＨＴＴＰクライアントとしても構成されている。

図４、図５および各表を用いて、連携サーバモジュール３０４が、リソースサーバモジュール３０３が公開するＡＰＩを利用するまでの、ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用した本実施形態のシーケンスを説明する。
なお、図中“Ｒｅｆ”は参照を示しており、別図で説明する。また、“Ａｌｔ”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。

まず、表１に認可サーバモジュールのユーザテーブルのデータ例、表２に認可サーバモジュールのクライアントテーブルのデータ例を示す。

本実施形態のシーケンスで説明するユーザは、ユーザＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」および、そのパスワードを利用するとして説明する。
また、本シーケンスで説明する連携サーバモジュール３０４は、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」及びその各種データであるシークレット、リダイレクトＵＲＩを保持している。このリダイレクトＵＲＩは、連携サーバモジュール３０４が、認可応答を受け付けるためのＵＲＩである。これらデータは、あらかじめ認可サーバモジュール３０１に登録されている必要があるが、登録手段については不図示の画面を用いた方法や、認可サーバモジュール３０１が公開するＡＰＩによって実施する手段が考えられる。

Ｓ４０１にて、ユーザはＷｅｂブラウザ１０６に表示されている不図示の連携開始操作を実行する。Ｓ４０２にて、Ｗｅｂブラウザ１０６から連携サーバモジュール３０４に連携開始が通知される。連携開始を受けた連携サーバモジュール３０４は、Ｓ４０３ないしＳ４１０にて、Ｗｅｂブラウザ１０６、ＨＴＴＰサーバモジュール３０２を介して認可サーバモジュール３０１に対して認可要求（権限委譲要求）を行う。

ここで、Ｓ４０３の認可要求から、Ｓ４２１の認可トークン、リフレッシュトークン応答までの認可トークンの発行処理はＯＡｕｔｈ ２．０に定義されているＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔフローに従って実施される。
認可要求には、少なくとも、前述の連携サーバモジュール３０４が保持しているクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」およびリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」を含む。さらに、連携サーバモジュール３０４がユーザから権限委譲されるリソースの範囲を示すスコープ「ｐｒｏｆｉｌｅ」も含む。なお、リダイレクトＵＲＩは前述したとおり、認可サーバ１０２にて発行された認可コードを受け付けるクライアントのＵＲＬである。

Ｓ４０４にて、ＨＴＴＰサーバモジュール３０２は、Ｗｅｂブラウザ１０６から認可要求を受け付ける。
Ｓ４０５にて、ＨＴＴＰサーバモジュール３０２は、Ｗｅｂブラウザ１０６からの認可要求に、ＨＴＴＰ Ｃｏｏｋｉｅとして有効な認証トークンが含まれているか検証する。
含まれている場合、ＨＴＴＰサーバモジュール３０２は、認証トークンを認可サーバモジュール３０１に通知し、Ｓ４１０に移行する。
含まれていない場合は、以下の処理を実行する。Ｓ４０６にて、ＨＴＴＰサーバモジュール３０２は、ユーザ認証をするためにログイン画面をＷｅｂブラウザ１０６に応答する。

ここで、図５はＨＴＴＰサーバモジュール３０２が応答するログイン画面例である。
本実施例ではユーザはユーザＩＤおよびパスワードを入力し、それらの組が認可サーバモジュール３０１のユーザテーブルに登録されている情報の組と一致する場合に認証するよう構成されている。なおユーザを認証する手段として他の手段、例えば、Ｘ．５０９の証明書や、パスワードを複数回入力する多段階認証等、別の手段を構成する事も可能であり、本手段に限定するものではない。

図５のログイン画面５００は、ユーザＩＤを入力するユーザＩＤ入力欄５０１、パスワードを入力するパスワード入力欄５０２、およびログイン操作を実行するためのログインボタン５０３から成る。 Ｓ４０７にて、ユーザはＷｅｂブラウザ１０６に表示されたログイン画面５００に必要な情報を入力し、ログインボタン５０３を押下する。
Ｓ４０８にて、Ｗｅｂブラウザ１０６は、入力された情報をＨＴＴＰサーバモジュール３０２に送信する。

Ｓ４０９にて、ＨＴＴＰサーバモジュール３０２はユーザＩＤ、パスワードを取得し、ユーザテーブルのユーザＩＤ、パスワードの情報の組と比較し一致するかを検証する事でユーザを認証する。
本実施形態では、ユーザＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」、パスワード「ｕｓｅｒ」がログイン画面５００に入力され、ＨＴＴＰサーバモジュール３０２は、それらデータを検証し、認証する。なお、ＨＴＴＰサーバモジュール３０２は、ユーザ認証に失敗、つまり、ユーザテーブルに情報が登録されていない場合は、不図示の認証エラー画面をＷｅｂブラウザ１０６に応答する。

ユーザ認証に成功した場合、ＨＴＴＰサーバモジュール３０２は認証トークンを生成する。この認証トークンはＨＴＴＰサーバモジュール３０２の不揮発メモリ上に、ユーザＩＤに対応するＵＵＩＤと対応付けて保存される。ＵＵＩＤとは、Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒであり、重複しないユニークなＩＤである。本実施形態では、ユーザＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」に対応するＵＵＩＤ「１００００００１」に対応付けて保存される。

Ｓ４１０にて、ＨＴＴＰサーバモジュール３０２は、認可サーバモジュール３０１に対し、認証トークンを含む認可要求を行う。なお、この認証トークンはＨＴＴＰ Ｃｏｏｋｉｅとして設定され、ＨＴＴＰサーバモジュール３０２からＷｅｂブラウザ１０６への応答に設定され通知される。
以後、Ｗｅｂブラウザ１０６から認可サーバモジュール３０１へのアクセスは、ＨＴＴＰサーバモジュール３０２による認証トークンの検証、認証処理、および認証トークンの認可サーバモジュール３０１への通知が実行されるとして説明を省略する。

Ｓ４１１にて、認可サーバモジュール３０１は、受信した認可要求のうち、クライアントＩＤとリダイレクトＵＲＬの組が正しいか検証する。より具体的には、クライアントテーブルに登録されているクライアントＩＤとリダイレクトＵＲＬの組が一致するか検証する。不一致の場合、認可サーバモジュール３０１は不図示のエラー画面を、ＨＴＴＰサーバモジュール３０２を介してＷｅｂブラウザ１０６に応答する。
一致した場合、認可サーバモジュール３０１はＳ４１２で認可確認処理を実施する。この認可確認処理については、図７を用いて後述する。

次に、認可サーバモジュール３０１において、認可確認処理の結果が［許可応答］であった場合のシーケンスについて説明する。
Ｓ４１３にて認可サーバモジュール３０１は、認可コードを発行する。より具体的には、トークンＩＤ「ｃｄ＿０００００１」を発行する。そして、認可要求に含まれるクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」とリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」、スコープ「ｐｒｏｆｉｌｅ」、および、認証し許可を得たユーザのユーザＩＤに対応するＵＵＩＤ「１００００００１」を認可サーバモジュールのトークンテーブルに登録する。その際、トークン種別を認可コードとし、有効期限として当該認可コードが有効である期限の日時を登録する。なお、表３のトークンテーブルの例では、トークンが有効か否かを示す状態を「有効」として登録しているが、有効期限を検証することで有効性を毎度確認する構成としてもよい。

表３に、認可サーバモジュールのトークンテーブルの例を示す。表３では、トークンＩＤ「ｒｔ＿００００００」のリフレッシュトークンが発行済みの状態で示しているが、このリフレッシュトークンの利用については、認可確認処理にて説明する。

Ｓ４１４、Ｓ４１５にて認可サーバモジュール３０１は、Ｗｅｂブラウザ１０６を介し、連携サーバモジュール３０４に、発行した認可コードのトークンＩＤ「ｃｄ＿０００００１」を付与して認可を応答する。より具体的には、認可要求時に取得したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」に対してＷｅｂブラウザ１０６をリダイレクトするよう、Ｗｅｂブラウザ１０６にリダイレクト応答する。

Ｓ４１６にて連携サーバモジュール３０４は、認可サーバモジュール３０１に対して認可トークンを要求する。この認可トークン要求には、少なくとも、取得した認可コード「ｃｄ＿０００００１」、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」、および認可要求時に送信したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」が含まれる。

Ｓ４１７にて認可サーバモジュール３０１は取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」の組をもってクライアントを認証する。より具体的には、クライアントテーブルの組と一致するかを検証する事で認証する。ここでクライアント認証に失敗した場合は連携サーバモジュール３０４に認証エラーを応答する。

クライアント認証に成功した場合、Ｓ４１８にて認可サーバモジュール３０１は、取得した認可コード「ｃｄ＿０００００１」を検証する。認可コードの検証としては、取得した認可コードがトークンテーブルに登録されているか、登録されている場合は、有効かを検証する。さらには、認可トークン要求にて取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」とリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」がトークンテーブルのクライアントＩＤ、リダイレクトＵＲＩと一致するかを検証する。認可コード検証の結果が無効であった場合、認可サーバモジュール３０１は連携サーバモジュール３０４にトークン不正エラーを応答する。

そして、認可コード検証の結果が有効であった場合、認可サーバモジュール３０１はＳ４１９にて認可トークンを発行する。より具体的には、トークンＩＤ「ａｔ＿０００００１」を発行し、認可コードに紐づくユーザのＵＵＩＤ「１００００００１」、スコープ「ｐｒｏｆｉｌｅ」、および認証したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークンテーブルに登録する。その際、トークン種別は認可トークンとし、有効期限として当該認可トークンが有効である期限の日時を登録する。

さらに、Ｓ４２０にて、認可サーバモジュール３０１は、リフレッシュトークンを発行する。より具体的には、トークンＩＤ「ｒｔ＿０００００１」を発行する。そして、認可トークン「ａｔ＿０００００１」に紐づくユーザのＵＵＩＤ「１００００００１」、スコープ「ｐｒｏｆｉｌｅ」、および認証したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークンテーブルに登録する。
その際、トークン種別はリフレッシュトークンとし、有効期限として当該リフレッシュトークンが有効である期限の日時を登録する。また、ＯＡｕｔｈ ２．０では、認可コードは一度しか利用できないように制御することが推奨されているため、トークンＩＤ「ｃｄ＿０００００１」の認可コードの状態を「無効」にする。なお、無効にする処理として、状態を利用するのではなく、有効期限を過去の日時に更新することで無効扱いとすることや、テーブルのレコードそのものを削除することで無効にするという方法でもよい。

表４に認可サーバモジュールのトークンテーブルの例を示す。ここで、トークンＩＤ「ｒｔ＿００００００」のリフレッシュトークンの状態が「無効」になっているが、この更新処理については後述する。

そして、Ｓ４２１にて、認可サーバモジュール３０１は、発行した認可トークンのトークンＩＤ「ａｔ＿０００００１」、リフレッシュトークンのトークンＩＤ「ｒｔ＿０００００１」を連携サーバモジュール３０４に応答する。
認可トークンを取得した連携サーバモジュール３０４は、Ｓ４２２にてリソースサーバモジュール３０３が公開するＡＰＩに対してリソース要求を行う。

次に、認可サーバモジュール３０１において、認可確認処理の結果が［拒否応答］であった場合のシーケンスについて説明する。
Ｓ４２３、Ｓ４２４にて認可サーバモジュール３０１は、Ｗｅｂブラウザ１０６を介し、連携サーバモジュール３０４に拒否応答を応答する。より具体的には、認可要求時に取得したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」に対してＷｅｂブラウザ１０６をリダイレクトするようＷｅｂブラウザ１０６にリダイレクト応答する。
以上が、連携サーバモジュール３０４が、リソースサーバモジュール３０３が公開するＡＰＩを利用するまでの、ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用した本実施形態のシーケンスである。

次に、図６を用いて本実施形態での、連携サーバモジュール３０４が認可トークンをリフレッシュし、リソースサーバモジュール３０３が公開するＡＰＩを利用するためのＯＡｕｔｈ ２．０のリフレッシュシーケンスを説明する。
なお、図中“Ａｌｔ”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。また、“Ｏｐｔ”はオプションであり、処理を省くことも可能である。

本シーケンスは、Ｓ６０１のユーザ操作から開始されるケースと、連携サーバモジュール３０４が自身の処理中にて発生するケースとがある。そのため、Ｓ６０１およびＳ６０２はオプションとして記載している。
Ｓ６０１にて、ユーザは、Ｗｅｂブラウザ１０６に表示されている不図示の再実行操作を行う。
Ｓ６０２にて、Ｗｅｂブラウザ１０６から連携サーバモジュール３０４に再実行が通知される。再実行を受け付けた連携サーバモジュール３０４は、Ｓ６０３にて、リソースサーバモジュール３０３が公開するＡＰＩに対して、すでに取得済みの認可トークン「ａｔ＿０００００１」を用いてリソース要求を行う。ここで、認可トークン「ａｔ＿０００００１」は有効期限に達しており、無効状態になっているとして説明する。

Ｓ６０５にて、リソースサーバモジュール３０３は、認可サーバモジュール３０１に対して認可トークン「ａｔ＿０００００１」が有効であるか否かを問い合わせるための認可トークン検証要求を行う。認可サーバモジュール３０１は、トークンテーブルを参照し、認可トークン「ａｔ＿０００００１」が有効か否かを確認し、結果を応答する。前述の通り無効であるため、認可サーバモジュール３０１は、リソースサーバモジュール３０３に対して、認可トークン無効応答を送信する。

そして、Ｓ６０６にてリソースサーバモジュール３０３は連携サーバモジュール３０４に対して認可トークン「ａｔ＿０００００１」が無効であるとして認可トークン無効応答を返す。
Ｓ６０７にて、連携サーバモジュール３０４は認可サーバモジュール３０１に対して認可トークンリフレッシュ要求を行う。その際、認可トークン、リフレッシュトークン応答にて取得したトークンＩＤ「ｒｔ＿０００００１」、および、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」を送信する。

Ｓ６０８にて認可サーバモジュール３０１は取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」の組をもってクライアントを認証する。より具体的には、クライアントテーブルの組と一致するかを検証する事で認証する。
ここでクライアント認証に失敗した場合は連携サーバモジュール３０４に認証エラーを応答する。

クライアント認証に成功した場合、Ｓ６０９にて、認可サーバモジュール３０１は、取得したリフレッシュトークン「ｒｔ＿０００００１」を検証する。認可コードの検証としては、取得したリフレッシュトークンがトークンテーブルに登録されているか、登録されている場合は、有効かを検証する。さらには、認可トークンリフレッシュ要求にて取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」がトークンテーブルのクライアントＩＤと一致するかを検証する。リフレッシュトークン検証の結果が［無効］であった場合の処理は後述する。

リフレッシュトークン検証の結果が［有効］であった場合、認可サーバモジュール３０１は、Ｓ６１０にて認可トークンを発行する。より具体的には、トークンＩＤ「ａｔ＿０００００２」を発行し、リフレッシュトークンに紐づくユーザのＵＵＩＤ「１００００００１」、スコープ「ｐｒｏｆｉｌｅ」、および認証したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークンテーブルに登録する。その際、トークン種別は認可トークンとし、有効期限として当該認可トークンが有効である期限の日時を登録する。

さらに認可サーバモジュール３０１は、Ｓ６１１にてリフレッシュトークンを発行する。より具体的には、トークンＩＤ「ｒｔ＿０００００２」を発行する。そして、認可トークン「ａｔ＿０００００２」に紐づくユーザのＵＵＩＤ「１００００００１」、スコープ「ｐｒｏｆｉｌｅ」、および認証したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークンテーブルに登録する。その際、トークン種別はリフレッシュトークンとし、有効期限として当該リフレッシュトークンが有効である期限の日時を登録する。

また、本実施形態におけるＯＡｕｔｈ ２．０の方式では、リフレッシュトークンは一度しか利用できないように制御する方式であるため、Ｓ６１２にてトークンＩＤ「ｒｔ＿０００００１」のリフレッシュトークンの状態を「無効」にする。なお、無効にする処理として、状態を利用するのではなく、有効期限を過去の日時に更新することで無効扱いとすることや、テーブルのレコードそのものを削除することで無効にするという方法でもよい。

表５に、認可サーバモジュールのトークンテーブルの例を示す。

Ｓ６１３にて認可サーバモジュール３０１は発行した認可トークンのトークンＩＤ「ａｔ＿０００００２」、リフレッシュトークンのトークンＩＤ「ｒｔ＿０００００２」を連携サーバモジュール３０４に応答する。
認可トークンを取得した連携サーバモジュール３０４は、Ｓ６１４にてリソースサーバモジュール３０３が公開するＡＰＩに対してリソース要求を行う。

次に、認可サーバモジュール３０１において、リフレッシュトークン検証の結果が［無効］であった場合のシーケンスを説明する。
ここで、リフレッシュトークン検証の結果が［無効］となるケースについて説明する。まず、検証の対象となるリフレッシュトークンが有効期限に達し、無効になっている通常想定されるケースである。このケースの場合は正常なケースとして、以下のシーケンスを実行するのみでよく、その他処理を必要としない。

もうひとつのケースが本実施形態の特徴である後述する処理において対応されるケースである。それは、クライアントＩＤ、シークレット、リフレッシュトークンのトークンＩＤが漏えいし、第三者によって認可トークンのリフレッシュ要求が行われてしまっているケースである。その場合、連携サーバモジュール３０４が保持しているリフレッシュトークンは、上述の通り、使用済みであるとして無効になっている。また、第三者が、リソースサーバモジュール３０３が公開するＡＰＩを不正に利用できる状態が想定される。本ケースの対応については後述する。

Ｓ６１５にて認可サーバモジュール３０１は連携サーバモジュール３０４に対してリフレッシュトークンが無効であると応答する。リフレッシュトークンの無効応答を受信した連携サーバモジュール３０４は、前述のＳ４０３の認可要求を実施する。その後の処理は図４を用いて説明したシーケンスと同様出るため説明を省略する。
以上が、連携サーバモジュール３０４が認可トークンをリフレッシュし、リソースサーバモジュール３０３が公開するＡＰＩを利用するためのＯＡｕｔｈ ２．０のリフレッシュシーケンスである。

続いて、本実施の形態の特徴である、図４を用いて説明した認可確認処理Ｓ４１２について図７および図８を用いて説明する。この認可確認処理Ｓ４１２を用いることで、前述の対応すべきケース、すなわち、第三者が、リソースサーバモジュール３０３が公開するＡＰＩを不正に利用できる状態の解消を行うことが可能となる。
ここで、ＯＡｕｔｈ ２．０では、過去に同一のクライアント、同一のユーザ、および同一のスコープにて認可操作したユーザに対して、再度同じ認可操作を求めないよう構成することも可能である。この再度同じ認可操作を求めない処理を認可確認のスキップ処理と称する。

本実施形態では、この認可確認のスキップ処理も含めて説明しているが、この認可確認のスキップ処理はＯＡｕｔｈ ２．０においてはオプションの処理であり、必ず、認可操作を求めるよう構成することも可能である。
また、図４にて説明した認可要求において、必ず認可確認画面を応答するよう指定することが可能なように構成することもできる。

なお、この認可確認のスキップ処理を実施する条件が、上記の条件のみだった場合、ユーザは、一度認可操作した条件で、二度と認可操作を実施することができなくなる。これはユーザに対して不利益を生む可能性がある。たとえば、拒否操作で認可の拒否を選択した場合に特別な処理を追加することや、認可操作に追加の情報を提示するような処理を追加したとしても、過去に認可操作にて許可したユーザは追加の処理を実施することができない。
そこで、例えば、同一条件、つまり同一のクライアント、同一のユーザ、同一のスコープにて認可操作したと判断される期間に有効期限を設定し、期限が切れた場合は認可確認のスキップを実施しないよう構成することも考えられる。

さらに、本実施の形態の特徴として、同一条件で過去認可操作をしていたとしても、同一条件で発行されたリフレッシュトークンが有効な状態で残っている場合は認可確認のスキップを実施しない処理を追加している。これは、有効なリフレッシュトークンが残っているにもかかわらず、再度認可要求がきているという状況は通常処理では発生する可能性が低いためである。というのも、通常、有効なリフレッシュトークンが存在している状況であれば、クライアントは認可要求ではなく、リフレッシュトークンを利用して認可トークンをリフレッシュし、取得した新しい認可トークンを用いてリソースにアクセスする。つまり、有効なリフレッシュトークンが残っているにもかかわらず認可要求が来るという状況は、クライアント側にて何かしら、ユーザの認可操作を再度求める必要がある状況であることが考えられる。また、クライアントが保持しているリフレッシュトークンが利用できない状況である事が考えらえる。たとえば、クライアントについて大規模な更新があり、リフレッシュトークンの情報を一度クリアした、といったケースが考えらえる。その場合、クライアントＩＤは同一でも、ユーザに再度認可操作を求める方が好ましいケースとも考えられる。無論、この認可確認のスキップを実施しない条件の追加処理もオプションの処理であり、実施しないよう構成することも可能である。

Ｓ４１２の認可確認処理が開始されると、認可サーバモジュール３０１は、Ｓ７０１にて認可要求に含まれていたクライアントＩＤ、ユーザＩＤに対応するＵＵＩＤ、スコープを取得する。ここでクライアントＩＤは「ｃ００１＠ｘｘ．ｃｏｍ」、ＵＵＩＤ「１００００００１」、スコープ「ｐｒｏｆｉｌｅ」であったとして説明する。
次に、認可サーバモジュール３０１はＳ７０２にて、Ｓ７０１で取得したクライアントＩＤ、ＵＵＩＤ、スコープの組を用いて、トークンテーブルに同一の組のリフレッシュトークンが有効な状態で存在していないかを検索する。
Ｓ７０３にて、認可確認モジュール３０１は、Ｓ７０２の処理の結果、有効なリフレッシュトークンが存在しない場合は、Ｓ７０４の処理へ遷移する。また、有効なリフレッシュトークンが存在する場合は、Ｓ７０８の処理へ遷移する。

次に、認可サーバモジュール３０１はＳ７０４にて、認可要求を認可したことのある許可済みリストを取得する。許可済みリストには、少なくともクライアントＩＤ、ＵＵＩＤ、スコープが含まれている。以下に認可サーバモジュールの許可済みテーブルの例を示す。

Ｓ７０５にて、認可サーバモジュール３０１は、Ｓ７０１で取得したデータの組が、Ｓ７０４にて取得したテーブルに存在するかを検証する。例示したテーブルでは、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、ＵＵＩＤ「１００００００１」、スコープ「ｐｒｏｆｉｌｅ」の組は登録済みであるため、検証の結果として、許可済みとする。また、たとえば、クライアントＩＤが違う場合や、ＵＵＩＤが違う場合、さらには、スコープのみ違う場合においては、許可済みではないと判断される。

Ｓ７０６にて、認可サーバモジュール３０１は、Ｓ７０５の検証結果が許可済みであった場合は、Ｓ７０７へ、許可済みでないと判断された場合は、Ｓ７０８へと処理を分岐する。
Ｓ７０７にて認可サーバモジュール３０１は、認可確認処理の結果を「許可応答」として処理を終了する。なお、このＳ７０４、Ｓ７０５、Ｓ７０６、Ｓ７０７で説明した処理が、前述した認可確認のスキップ処理である。前述したように、ＯＡｕｔｈ ２．０においてはオプションの処理であり、必ず、後述の認可確認画面応答を実施するよう構成することも可能である。また、図４にて説明した認可要求において、必ず認可確認画面を応答するよう指定することが可能なように構成することもできる。
また、図７においては、有効なリフレッシュトークンがあるか探索してから許可済みリストを検証する例を示したが、先に許可済みリストを検証し、許可済みであった場合に有効なリフレッシュトークンがあるか探索するようにしてもよい。

認可サーバモジュール３０１において、Ｓ７０５の許可済みリスト検証の結果、条件に該当するデータが存在しなかった場合は、Ｓ７０６にて許可済みでないと判断され、Ｓ７０８へと処理が遷移する。
Ｓ７０８にて認可サーバモジュール３０１は認可確認画面をＷｅｂブラウザ１０６に応答する。図８は応答される認可確認画面の例である。認可確認画面９００は、認可要求に含まれるクライアントＩＤをキーとしてクライアントテーブルから取得したクライアント名を表示する領域であるアクセス元表示領域９０１を備える。さらに、認可要求で取得したスコープに対応する説明を表示する領域である委譲権限表示領域９０２を備える。また、認可確認画面９００は、ユーザが上記情報の内容について認可操作を実行する許可ボタン９０３、および拒否を実行する拒否ボタン９０４を備える。

Ｓ７０９にて、Ｗｅｂブラウザ１０６は、取得した認可確認画面９００をユーザに提示する。
そして、Ｓ７１０にて、Ｗｅｂブラウザ１０６は、ユーザが許可ボタン９０３、もしくは拒否ボタン９０４を押下した場合は、その認可確認結果を取得し認可サーバモジュール３０１に通知する。

Ｓ７１１にて、認可サーバモジュール３０１は、認可確認結果を取得する。
次に、Ｓ７１２、Ｓ７１３にて、Ｓ７０２、Ｓ７０３と同様の処理を行い、不要なリフレッシュトークンを削除する。Ｓ７０２、Ｓ７０３と同様の処理を再び行うのは、Ｗｅｂブラウザ１０６における認可確認処理を行っている間に、認可サーバモジュールにおいて他の処理が行われる可能性があり、有効なリフレッシュトークンがあるか否か再び検索する必要があるためである。この結果、たとえば、図４で説明したシーケンス中での認可確認処理の結果、トークンＩＤ「ｒｔ＿００００００」のリフレッシュトークンの状態が「無効」に更新される。また、図６で説明したシーケンス中のＳ６１５ののちに実行された場合は、第三者がリフレッシュしたのちに取得したと想定されるリフレッシュトークンも合わせて無効化される。上述の通り、この処理によって第三者による不正なＡＰＩの実行を防ぐことが可能となる。なお、図を用いての説明では、リフレッシュトークンを無効化することのみ記載しているが、合わせて、同じ条件にて認可トークンも無効化してもよい。

次に、認可サーバモジュール３０１は、Ｓ７１４にて、Ｓ７１１で取得した認可確認結果が許可であった場合は、Ｓ７１５にて認可確認処理の結果を「許可応答」として処理を終了する。そして、認可確認結果が拒否であった場合は、Ｓ７１６にて認可確認処理の結果を「拒否応答」として処理を終了する。
以上が、本実施の形態の特徴である、認可確認処理である。この認可確認処理を用いることで、不用なリフレッシュトークンが無効化され、前述の対応すべきケース、すなわち、第三者が、リソースサーバモジュール３０３が公開するＡＰＩを不正に利用できる状態の解消を行うことが可能となる。

（第２実施形態）
図７および図８で説明した認可確認処理では、第三者に情報が漏えいした場合の対処処理について説明した。しかしながら、ＯＡｕｔｈ ２．０では、クライアント自身がユーザからの許可を不正に取得することで、ユーザのリソースを不正に取得する、というケースが想定される。たとえば、ユーザに対して興味を持たせるような記事を記載し、続きを読むためには認可確認操作を行うよう誘導するような手法が考えられる。このようなケースの場合、ユーザは他のユーザからの注意喚起によってクライアントに対して不用な認可操作を行っていることに気づき、対処を実施することが考えられる。しかしながら、クライアント側も多種多様な手段により、再度ユーザから認可操作を得るための記事掲載等を行うことを繰り返すことで、ユーザのリソースを取得することを試みる。

そこで、これから説明する認可確認処理では、過去、ユーザが明示的に拒否したことがあるクライアントからの認可操作を再度行わないように注意喚起を行う。さらに、一度認可操作を実施してしまったクライアントから再度認可要求が来た際に、認可操作をスキップさせないようにするための処理を実施することで、上述のようなケースが発生することを軽減することを目的とする。

ここで、認可操作をスキップさせないために、すでに認可済みであるかを判断する処理において、同一条件で発行されたリフレッシュトークンが有効な状態で残っているかを確認することで対処している。それは、有効なリフレッシュトークンが残っているにもかかわらず、再度認可要求がきているという状況は通常処理では、発生する可能性が低い状態であるためである。というのも、通常、有効なリフレッシュトークンが存在している状況であれば、クライアントは認可要求ではなく、リフレッシュトークンを利用して認可トークンをリフレッシュし、取得した新しい認可トークンを用いてリソースにアクセスする。
しかしながら、上述の通り、リソースを不正に取得する目的のクライアントであれば、認可操作を促すための記事の記載を不特定多数に提示することが想定される。そのため、同一のユーザに対して、リフレッシュトークンの利用ではなく記事からの処理開始となるであろう。その結果、再度認可要求を実施するよう構成されることが想定されるからである。

以下、図１０および図１１を用いて上述のようなケースが発生することを軽減することを目的とした場合の認可確認処理Ｓ４１２について説明する。なお、図７、図８、図９と同様の構成および、同じ処理を実施する箇所については同じ番号を付与し説明を省略する。
図１０および図１１は、第２実施形態における認可サーバモジュール３０１による認可確認処理Ｓ４１２を説明するフローチャートである。

Ｓ７０１において、図７で説明したとおり、認可サーバモジュール３０１はクライアントＩＤ、ユーザＵＵＩＤ、およびスコープを取得する。
Ｓ１００１において、認可サーバモジュール３０１は、過去に認可確認画面にて拒否を実施した、もしくは後述の方法にて、認可操作したことをキャンセル、つまり認可の解除を実施したクライアントのリストである、拒否クライアントリストを取得する。ここで、認可の解除方法としては、たとえば、認可サーバモジュール３０１にて後述する認可の解除面をＷｅｂブラウザ１０６に提示し、ユーザの操作を持って解除する方法が考えられる。

以下に、認可サーバモジュールの拒否クライアントリストのテーブルを示す。

ここでは、ユーザＩＤに対応するＵＵＩＤ「１００００００１」のユーザが、クライアントＩＤ「ｃ００２＠ｚｚ．ｃｏｍ」に対して拒否操作をしたことを示している。

図１２（Ａ）は、前述した認可の解除画面の一例を示す図である。認可の解除画面１２００は、認可サーバモジュールの許可済みリストテーブルのクライアントＩＤをもとにクライアントテーブルから取得したクライアント名１２０１、スコープ１２０２、および解除を実行するための認可解除ボタン１２０３からなる。

次に、認可の解除画面１２００へアクセスするための処理を説明する。
ユーザは、Ｗｅｂブラウザ１０６を用いて、ＨＴＴＰサーバモジュール３０２を介し認可サーバモジュール３０１に対して認可の解除画面へのアクセスを要求する。以降の認証処理については、図４を用いて説明したＳ４０４からＳ４０９での説明における認可要求を、認可の解除画面へのアクセス要求とした場合と同じであるため説明を省略する。

認可の解除画面へのアクセス要求を受け付けた認可サーバモジュール３０１は、受信した認証トークンに紐づいたユーザのＵＵＩＤをもとに認可サーバモジュールの許可済みリストテーブルから情報を取得する。そして、認可の解除画面１２００を生成しＷｅｂブラウザ１０６へ応答する。
Ｗｅｂブラウザ１０６は、取得した認可の解除画面１２００をユーザに提示する。そして、ユーザが認可解除ボタン１２０３を押下した場合は、認可の解除要求を認可サーバモジュール３０１に通知する。認可の解除要求は、前述したＵＵＩＤに紐づく認証トークンと認可を解除する対象であるクライアントＩＤを通知する。

Ｓ１００４にて認可の解除要求を受け付けた認可サーバモジュール３０１は、Ｓ１００５にてクライアントＩＤ、およびＵＵＩＤを取得する。
次に、認可サーバモジュール３０１は、Ｓ１００６にて、取得したクライアントＩＤ、ＵＵＩＤの組が許可済みリストテーブルにて一致するデータを削除する。
さらに、認可サーバモジュール３０１は、Ｓ１００７にてトークンテーブルにて、クライアントＩＤ、およびＵＵＩＤの組が一致するデータの状態を無効にすることも可能である。
そして、認可サーバモジュール３０１は後述のＳ１００８にて、拒否クライアントリストテーブルに受信したクライアントＩＤおよび、ＵＵＩＤを登録し、処理を終了する。
なお、認可の解除画面１２００について、後述する拒否クライアントの解除画面とは別の画面として例示しているが、この二つの画面について同一の画面として構成することも可能である。

Ｓ１００２にて、認可サーバモジュール３０１は、Ｓ７０１で取得したクＵＵＩＤ、クライアントＩＤの組が拒否クライアントリストに登録されているかを確認する（拒否判断）。登録されていれば、拒否クライアントとしてＳ１００３に、拒否クライアントでなければ、Ｓ７０２に遷移する。
Ｓ１００３にて認可サーバモジュール３０１は、注意あり認可確認画面をＷｅｂブラウザ１０６に応答する。

図１３は応答される注意あり認可確認画面の一例を示す図である。注意あり認可確認画面１３００は、図９の構成要素に追加要素として、過去に同一クライアントからのアクセスを拒否したことを説明する拒否クライアント表示領域１３０１を備える。なお、注意あり認可確認画面は一例であり、このようにユーザに対して注意喚起するような認可画面をまとめて警告認可画面と称する。

この注意あり認可確認画面１３００を提示することで、ユーザが過去に拒否したクライアントに対して、再度認可操作を実施してしまうことを軽減することができる。なお、ここで注意あり認可確認画面１３００を応答するのではなく、ユーザが拒否を実施した場合と同様の処理に強制的に遷移するよう構成することも可能である。その場合は、Ｓ７１０にて拒否操作をされた場合の図８におけるＳ７１１の処理以降と同様の処理が実施される。なお、その場合は、誤って拒否してしまったクライアントに対して以降、認可操作が不能になってしまうため、認可サーバモジュール３０１にて拒否クライアントの解除画面を生成し、拒否を解除することもできる。

図１２（Ｂ）は前述の拒否クライアントの解除画面の一例を示す図である。拒否クライアントの解除画面１２０４は認可サーバモジュールの拒否クライアントリストテーブルのクライアントＩＤをもとにクライアントテーブルから取得したクライアント名１２０５、および解除を実行するための拒否解除ボタン１２０６からなる。なお、拒否クライアントの解除画面１２０４へアクセスするための処理は、認可の解除画面１２００へのアクセスするための処理において認可の解除画面へのアクセス要求を、拒否クライアントの解除画面へのアクセス要求とした場合と同様のため説明を省略する。

拒否クライアントの解除画面へのアクセス要求を受け付けた認可サーバモジュール３０１は、受信した認証トークンに紐づいたユーザのＵＵＩＤをもとに認可サーバモジュールの拒否クライアントリストテーブルから情報を取得する。そして、拒否クライアントの解除画面１２０４を生成しＷｅｂブラウザ１０６へ応答する。
Ｗｅｂブラウザ１０６は、取得した拒否クライアントの解除画面１２０４をユーザに提示する。そして、ユーザが拒否解除ボタン１２０６を押下した場合は、拒否の解除要求を認可サーバモジュール３０１に通知する。拒否の解除要求は、前述したＵＵＩＤに紐づく認証トークンと拒否を解除する対象であるクライアントＩＤを通知する。

拒否の解除要求を受け付けた認可サーバモジュール３０１は、拒否クライアントリストテーブルにて該当のクライアントＩＤ、およびＵＵＩＤの組が一致するデータを削除し、処理を終了する。
なお、拒否クライアントの解除画面１２０４について、前述した認可の解除画面１２００とは別の画面として例示しているが、この二つの画面について同一の画面として構成することも可能である。

次に、注意あり認可確認画面１３００にてユーザが操作を実施した場合の処理を説明する。なお、注意あり認可確認画面１３００にてユーザが許可ボタン９０３を押下した場合の処理は、図８で説明した場合と同様であるため説明を省略する。注意あり認可確認画面１３００にてユーザが拒否ボタン９０４を押下した場合は、図８のＳ７１６の処理ののちに、Ｓ１００８にて拒否クライアントリストの更新処理を行う。より具体的には認可サーバモジュール３０１は、拒否クライアントリストテーブルに対して取得したＵＵＩＤ、クライアントＩＤの組が登録されていなかった場合に、登録処理を行い、処理を終了する。

Ｓ１００２にて、拒否クライアントでないと判断された場合、認可サーバモジュール３０１はＳ７０２に遷移する。Ｓ７０２の処理以降は、前述した認可確認結果が拒否だった場合のＳ１００８の追加処理を除いて図７および図８と同様のため、説明を省略する。Ｓ７０２の処理の結果、有効なリフレッシュトークンが存在する場合は、認可サーバモジュール３０１は、認可確認画面をスキップする処理を実施せず、図７および図８で説明したＳ７０８の認可確認画面応答へ処理を遷移する。以降の処理は、前述した認可確認結果が拒否だった場合のＳ１００８の追加処理を除いて図７と同様のため、説明を省略する。

以上の処理により、ＯＡｕｔｈ ２．０において、クライアント自身がユーザからの許可を不正に取得することで、ユーザのリソースを不正に取得する、というケースに対して、ユーザが認可操作を実施してしまうことを軽減することが可能となる。

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

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

Claims (12)

1. サービスを提供するリソースサーバと、前記リソースサーバが有するユーザのデータへのアクセスを認可情報に基づいてクライアント装置に認めるための権限委譲を行う認可サーバとを含む権限委譲システムであって、
   前記権限委譲を求める権限委譲要求を受信する受信手段と、
   前記権限委譲要求に基づいて、更新認可情報を検索する検索手段と、
   前記検索手段により検索された前記更新認可情報が有効であるか否かを判断する判断手段と、
   前記判断手段において有効と判断された場合、検索された前記更新認可情報を無効化する無効化手段とを備える
   ことを特徴とする権限委譲システム。
2. 前記権限委譲要求には、少なくとも、ユーザＩＤ、ＵＵＩＤ、スコープを含む
   ことを特徴とする請求項１に記載の権限委譲システム。
3. 前記権限委譲を許可する場合に、前記リソースサーバへアクセスするために利用される前記認可情報と、新たな認可情報を新たな権限委譲要求なしに再発行するために利用される前記更新認可情報とを発行する発行手段をさらに備える
   ことを特徴とする請求項１または請求項２に記載の権限委譲システム。
4. 前記受信手段が前記権限委譲要求を受信した場合に、前記権限委譲を許可するか否かの認可確認画面を応答する画面応答手段と、
   認可確認画面でなされた結果を取得する結果取得手段とをさらに備え、
   前記無効化手段は、結果取得手段において取得された前記結果にかかわらず前記更新認可情報を無効化する
   ことを特徴とする請求項１ないし３のいずれか１項に記載の権限委譲システム。
5. 前記権限委譲要求に基づいて、過去に権限委譲を行ったことがあるか検証する検証手段をさらに備える
   ことを特徴とする請求項４に記載の権限委譲システム。
6. 前記検証手段が、過去に権限委譲を行ったことがあると判断した場合、
   前記画面応答手段は、前記認可確認画面の応答を行わない
   ことを特徴とする請求項５に記載の権限委譲システム。
7. 権限委譲を解除する解除手段をさらに備え、
   前記受信手段は、さらに、前記権限委譲の解除を求める解除要求を受信し、
   前記解除要求を受信した場合、前記画面応答手段は、さらに、解除画面を応答し、
   前記結果取得手段は、さらに、前記解除画面でなされた結果を取得し、
   前記解除手段は、前記結果取得手段が取得した結果が解除であった場合、前記解除要求に基づいて前記権限委譲を解除する
   ことを特徴とする請求項４ないし６のいずれか１項に記載の権限委譲システム。
8. 前記解除要求には、少なくとも、クライアントＩＤと、ＵＵＩＤに対応する認可情報とが含まれ、
   前記解除手段は、前記クライアントＩＤと前記ＵＵＩＤが一致するデータを削除もしくは無効にすることで前記権限委譲を解除する
   ことを特徴とする請求項７に記載の権限委譲システム。
9. 前記権限委譲要求に基づいて、前記ユーザが権限委譲要求を拒否したことがあるクライアントもしくは前記権限委譲を解除したことがあるクライアントである拒否クライアントか否か判断する拒否判断手段をさらに備え、
   前記拒否判断手段において拒否クライアントと判断された場合、前記画面応答手段は、注意つきの認可確認画面を応答する
   ことを特徴とする請求項４ないし８のいずれか１項に記載の権限委譲システム。
10. サービスを提供するリソースサーバが有するユーザのデータへのアクセスを認可情報に基づいてクライアント装置に認めるための権限委譲を行う認可サーバであって、
    前記権限委譲を求める権限委譲要求を受信する受信手段と、
    前記権限委譲要求に基づいて、更新認可情報を検索する検索手段と、
    前記検索手段により検索された前記更新認可情報が有効であるか否かを判断する判断手段と、
    前記判断手段において有効と判断された場合、検索された前記更新認可情報を無効化する無効化手段とを備える
    ことを特徴とする認可サーバ。
11. サービスを提供するリソースサーバと、前記リソースサーバが有するユーザのデータへのアクセスを認可情報に基づいてクライアント装置に認めるための権限委譲を行う認可サーバとを含む権限委譲システムの制御方法であって、
    前記権限委譲を求める権限委譲要求を受信する受信工程と、
    前記権限委譲要求に基づいて、更新認可情報を検索する検索工程と、
    前記検索工程において検索された前記更新認可情報が有効であるか否かを判断する判断工程と、
    前記判断工程において有効と判断された場合、検索された前記更新認可情報を無効化する無効化工程とを備える
    ことを特徴とする権限委譲システムの制御方法。
12. コンピュータを請求項１０に記載の認可サーバが備える各手段として機能させるためのプログラム。

Images