JP2017004301A - 認証サーバーシステム、方法、プログラムおよび記憶媒体 - Google Patents

Abstract

【課題】 ＲＥＳＴｆｕｌ ＭＶＣと呼ばれるアーキテクチャをＯＡｕｔｈによるシステム間連携だけでなく、ユーザー本人が画面操作するケースに対してもＲＥＳＴを利用した場合、全てのＲＥＳＴ ＡＰＩが受け取ったトークンの種別を判断し、受け取ったトークンに対応する検証モジュールを呼び出す実装が必要となってしまう。
【解決手段】 認証トークンもしくはアクセストークンを区別なく受け付ける認証認可共通の権限検証モジュールを提供する。トークンのオーナーの権限検証を行うと共に、トークンにクライアントが紐付いている場合は追加でクライアントの権限検証も行う。
【選択図】 図８

Description

認証・認可における検証を行う認証サーバーシステム、方法、プログラムおよび記憶媒体に関する

クラウドが一般化するに伴い、複数のサービスを連携させる機会はますます増加している。サービスとは、インターネット等のネットワークを介して接続されたサーバーが提供する機能、換言すれば、ウェブアプリケーションのことを指す。サービスを連携させることでサービス提供者は、ユーザーに通常のサービスに付加価値を加えた新たなサービスを提供することができる。その一方で、サービスが連携することにより、いくつかの課題が生まれる。

すなわち、ユーザーが望んだ以上の情報がサービス間でやりとりされる虞があり、ユーザーデータや個人情報に関する情報の流出という課題がある。たとえばインターネット上には複数のサービスが存在し、様々なサービス間でサービス連携が実現される可能性があるが、ユーザーが認識したサービス以外がユーザーデータや個人情報を操作できてはいけない。またサービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。

このような状況において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈによれば、たとえばある端末内のアプリケーションからクラウドサービスが管理するデータにアクセスする場合は、アプリケーションはユーザーの明示的な認可を得ることになっている。

ユーザーが認可すると、アプリケーションはアクセスを認められたことを証明するトークン（以下、アクセストークン）を受け取り、以降のアクセスはそのアクセストークンを用いて実現できる。以下では、アクセストークンの発行のための操作を認可操作と称する。たとえば特許文献１において、ＯＡｕｔｈを利用したアクセストークンを発行する技術が開示されている。

特開２０１５−５２０２

ＯＡｕｔｈによるシステム間連携ではＲＥＳＴなどのｗｅｂサービスが採用される。また近年、ＲＥＳＴｆｕｌ ＭＶＣと呼ばれるアーキテクチャが浸透したことにより、ＯＡｕｔｈによるシステム間連携だけでなく、ユーザー本人が画面操作するケースに対してもＲＥＳＴで機能を実現できるようになった。

機能の実現方式がＲＥＳＴに共通化された場合であっても、ユーザー本人が画面操作するケースでは認証トークンが、システム間連携ではアクセストークンがそれぞれ用いられる。しかし、これらのトークンの検証の仕方が異なるため、全てのＲＥＳＴ ＡＰＩが受け取ったトークンの種別を判断し、受け取ったトークンに対応する検証モジュールを呼び出す実装が必要となってしまう。

本発明は上述した課題を解決するため、トークンの種別に関わらず共通のモジュールでトークン検証を行う仕組みを提供することを目的とする。

本発明の一実施形に係る認証サーバーシステムは、端末および認可クライアントへ特定の機能を提供するサービスを備えた情報処理装置と通信可能な認証サーバーシステムであって、前記端末を操作するユーザーが正規のユーザーであるか否かを検証するための第１の種別のトークン、および前記サービスと連携する認可クライアントに移譲された権限で前記サービスを利用できるか否かを検証するための第２の種別のトークンを発行する手段と、前記発行手段により発行されたトークンの種別に依らず、前記情報処理装置から検証要求およびスコープとともに受信したトークンを基に検証のための確認を行い検証の結果を通知する検証手段とを有し、前記検証手段は、前記第１の種別のトークンを受信した場合は、トークンに関連付けられた権限の確認を行わず、前記第２の種別のトークンを受信した場合は、トークンに関連付けられた権限の確認を行い、かつ前記スコープがトークンに関連付けられた権限の範囲内であるか否かを確認することを特徴とする。

トークンの種別に関わらず共通のモジュールでトークン検証を行うことが可能になる。

ネットワーク構成を示す図である。 本発明の実施の形態に係るサーバーコンピューターの構成図である。 本実施の形態に係るモジュール構成図である。 本実施の形態に係るログインフローおよびアクセストークンの発行フローである。 本実施の形態に係る権限検証フローである。 本実施の形態に係る画面の表示例である。 本実施の第２の形態に係るモジュール構成図である。 本実施の第２の形態に係る権限検証の模式図である。

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

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

１５１はユーザーの認証およびアクセストークンの発行を行う認証・認可サーバー、１５２はリソースサーバーである。アクセストークンとは、あるアプリケーションがユーザーに、なんらかの操作を許可されたことを証明するものであり、ユーザーがアプリケーションに対して認可操作することで発行される。たとえばクラウドサービスが管理するデータにアクセスするためのアクセストークンを用いると、アプリケーションは、ユーザーに許可された範囲でデータにアクセスできるようになる状況を提供する。１９１はユーザーが操作するユーザー端末である。また１７１および１７２はユーザーから委譲された権限を用いてリソースサーバー１５２とシステム間連携を実施する認可クライアントである。

認証・認可サーバー１５１、リソースサーバー１５２はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１を介して接続されている。また同様にユーザー端末１９１はＷＡＮネットワーク１００およびＬＡＮ１０２を介して接続されている。認可クライアント１７１および１７２はＷＡＮネットワーク１００およびＬＡＮ１０３を介して接続されている。なお認証・認可サーバー１５１、リソースサーバー１５２はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。なお、図１では各サーバーは１台で示しているが、複数台から構成されるサーバー群であっても良い。例えば、認証・認可を行うサーバーが複数台で構成されたサーバー群であっても良いわけである。このように、本願発明を実施する上でサーバーの数が１台または複数台であることを問わないので、本実施例においてサーバーシステムと称した場合、どちらの形態も含むものとする。例えば、認証サーバーシステムであれば、１台または複数台で構成された認証サーバーと言うことになる。

図２は本実施の形態に係る、認証・認可サーバー１５１のサーバーコンピューターの構成を示す図である。またリソースサーバー１５２のサーバーコンピューターの構成やユーザー端末１９１、認可クライアント１７１および１７２の構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のサーバーコンピューターおよびモバイル端末には一般的な情報処理装置のハードウェア構成を適用できる。

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

図３は本実施の形態に係る、認証・認可サーバー１５１、リソースサーバー１５２、認可クライアント１７１のモジュール構成を示す図である。図３（Ａ）は認証・認可サーバー１５１、図３（Ｂ）はリソースサーバー１５２、図３（Ｃ）は認可クライアント１７１のモジュール構成を、それぞれ示す。認証・認可サーバー１５１は認証モジュール３０１、認可モジュール３０２、認証認可共通権限検証モジュール３０３を持つ。また認証・認可サーバー１５１はユーザー管理モジュール３０４、クライアント管理モジュール３０５、スコープ管理モジュール３０６を持つ。リソースサーバー１５２はリソース管理モジュール３５１、トークン検証要求モジュール３５２を持つ。また認可クライアント１７１はアクセストークン要求モジュール３７１、リソースサーバーアクセスモジュール３７２を持つ。なお認可クライアント１７２は認可クライアント１７１と同様の構成を取れるものとする。何れもハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムを構成するモジュールであり、ＣＰＵ２０１により実行されることで各サーバーの機能を発揮する。

図４（Ａ）は本実施の形態に係る、認証・認可サーバーにおけるログインフローである。本フローは認証・認可サーバー１５１がユーザー端末１９１からログイン要求を受信することで開始される。ステップＳ４０１で認証モジュール３０１は、ユーザー端末１９１に対し、図６（Ａ）に示されるような認証画面１００１を送信する。ステップＳ４０２で認証モジュール３０１は、認証画面１００１で入力された認証情報を受け付ける。ステップＳ４０３で認証モジュール３０１は、ステップＳ６０２で受け付けた認証情報が妥当か判断する。ここで認証情報が妥当であり正規なユーザーであると判断された場合はステップＳ４０４に遷移する。また認証情報が妥当でないと判断された場合はステップＳ４５０に遷移する。

ステップＳ４０４で認証モジュール３０１は、ユーザーのログインを許可し、認証トークンを発行してフローを終了する。なおここ発行された認証トークンは、ユーザーと紐付けられ、表１に示されるような認証トークンテーブルで管理される。

ステップＳ４５０で認証モジュール３０１は、ユーザーのログインを拒否し、フローを終了する。

図４（Ｂ）は本実施の形態に係る、認証・認可サーバー１５１における、アクセストークンの発行フローである。本フローは認証・認可サーバー１５１の認可モジュール３０２がユーザー端末１９１および認可クライアント１７１から、アクセストークンの要求を受信することで開始される。ステップＳ５０１で認可モジュール３０２は、ユーザー端末１９１および認可クライアント１７１からアクセストークンの要求を受け付ける。ここで受け付けたアクセストークンの要求は、ユーザーの情報およびクライアント識別子を含む。

ステップＳ５０２で認可モジュール３０２は、ユーザー端末１９１を操作しているユーザーがログイン済みか判断する。ここでユーザーがログイン済みと判断された場合はステップＳ５０５に遷移する。またログイン済みでないと判断された場合はステップＳ５０３に遷移する。ステップＳ５０３で認証モジュール３０１は、ユーザー端末１９１に対し、図６（Ａ）に示されるような認証画面１００１を送信する。なおログインフローの詳細は図４（Ａ）で示したものと同様である。ステップＳ５０４で認証モジュール３０１は、ステップＳ５０３に対応してユーザーがログインしたか判断する。ここでユーザーがログインしたと判断されればステップＳ５０５に遷移する。またユーザーがログインしなかったと判断された場合はステップＳ５５０に遷移する。

ステップＳ５０５で認可モジュール３０２は、ユーザー端末１９１に対し、図６（Ｂ）に示すような認可確認画面１００２を送信し、ユーザーの確認を求める。ステップＳ５０６で認可モジュール３０２は、ステップＳ５０５に対応してユーザーの認可を得られたか判断する。ここで認可を得られたと判断された場合はステップＳ５０７に遷移する。また認可を得られなかったと判断された場合はステップＳ５５０に遷移する。ユーザーが認可を行うために図６（Ｂ）にて許可を選択するための操作を認可操作と称し、ユーザーにより認可操作が行われたことでアクセストークンの発行が行われる。

ステップＳ５０７で認可モジュール３０２は、アクセストークンを発行し、ステップＳ５０１で受け付けたアクセストークンの要求に含まれるクライアント識別子とユーザー情報に紐付けて表２のアクセストークンテーブルで記憶する。またユーザー端末１９１を介して、発行したアクセストークンを認可クライアント１７１に返し、フローを終了する。

ステップＳ５５０で認可モジュール３０２は、アクセストークンを発行できない旨をリソース管理モジュール３５１に通知し、フローを終了する。

図５（Ａ）は本実施の形態に係る、認証・認可サーバー１５１における、認証トークンおよびアクセストークンの検証フローである。本フローは認証・認可サーバー１５１の認証認可共通権限検証モジュール３０３が、リソースサーバー１５２のトークン検証要求モジュール３５２から権限検証要求を受信することで開始される。ここで権限検証要求は、リソースサーバー１５２のリソース管理モジュール３５１が、ユーザー端末１９１もしくは認可クライアント１７１からリソース要求を受信したことに対応して実施される。

ステップＳ６０１で認証認可共通権限検証モジュール３０３は、リソースサーバー１５２のトークン検証要求モジュール３５２から権限検証要求を受信する。ここで権限検証要求にはリソースサーバー１５２のリソース管理モジュール３５１がユーザー端末１９１から受信した認証トークンを含む。もしくはリソースサーバー１５２のリソース管理モジュール３５１が認可クライアント１７１から受信したアクセストークンを含む。また前記権限検証要求は、リソースサーバー１５２のリソース管理モジュール３５１がユーザー端末１９１もしくは認可クライアント１７１から要求されたリソースの利用に必要なスコープリストも含む。即ち、認証認可共通権限検証モジュール３０３は、スコープに関する情報をトークンの種別に依らず常に受信することになる。詳細は後述するが、認証認可共通権限検証モジュール３０３は認証トークンをした場合、スコープに関する情報を受信したとしても検証のための確認にスコープに関する情報を利用することはない。

なおリソース管理モジュール３５１が受信したトークンが認証トークンだったかアクセストークンだったかに関わらず、リソースの利用に必要なスコープリストとしては、トークンのユーザーおよびクライアントのそれぞれに要求されるスコープを含む。このようにすることでリソースサーバー１５２は、リソース管理モジュール３５１が受信したトークンの種別に関わらず、同じスコープリストを認証・認可サーバー１５１に渡すことで権限検証を要求できる。

ステップＳ６０２で認証認可共通権限検証モジュール３０３は、ステップＳ６０１で受信した権限検証要求から、認証トークンもしくはアクセストークンと、前記リソースの利用に必要なスコープリストを取り出す。ステップＳ６０３で認証認可共通権限検証モジュール３０３は、ステップＳ６０２で取り出したトークンが認証トークンだったかアクセストークンだったか判断する。トークンが認証トークンだった場合はステップＳ６０６に遷移し、アクセストークンだった場合はステップＳ６０４に遷移する。

ステップＳ６０４で認証認可共通権限検証モジュール３０３は、認可モジュール３０２が管理する表２に示されるようなアクセストークンテーブルに問い合わせ、ステップＳ６０２で取り出したアクセストークンに紐付くスコープを取得する。ステップＳ６０５で認証認可共通権限検証モジュール３０３は、ステップＳ６０４で取得したアクセストークンに紐付くスコープが、ステップＳ６０２で取り出した前記リソースの利用に必要なスコープリストのすべてのスコープを含むか判断する。換言すると、スコープがアクセストークンから特定した与えられた権限の範囲内であるかを判断することになる。必要なスコープをすべて含むと判断された場合はステップＳ６０６に遷移し、必要なスコープの内で１つでも含まれないものがあると判断された場合はステップＳ６５０に遷移する。

ステップＳ６０６で認証認可共通権限検証モジュール３０３は、ステップＳ６０２で取り出したトークンにクライアントが紐付いているか判断する。なお表１にあるように、トークンが認証トークンだった場合はクライアントは紐付いていない。また表２にあるように、トークンがアクセストークンだった場合はトークンにクライアントが紐付いている。トークンにクライアントが紐付いていると判断された場合はステップＳ６０７に遷移し、紐付いていないと判断された場合はステップＳ６０９に遷移する。

ステップＳ６０７で認証認可共通権限検証モジュール３０３は、トークンに紐付けられたクライアントの権限の検証を行う。ステップＳ６０８で認証認可共通権限検証モジュール３０３は、ステップＳ６０７の権限検証の結果、トークンに紐付けられたクライアントが、リソースを利用するために必要な権限を持つと判断されたか確認する。クライアントが必要な権限を持つと判断された場合はステップＳ６０９に遷移し、クライアントが必要な権限を持たないと判断された場合はステップＳ６５０に遷移する。

ステップＳ６０９で認証認可共通権限検証モジュール３０３は、トークンに紐付けられたユーザーの権限の検証を行う。ステップＳ６１０で認証認可共通権限検証モジュール３０３は、ステップＳ６０９の権限検証の結果、トークンに紐付けられたユーザーが、リソースを利用するために必要な権限を持つと判断されたか確認する。ユーザーが必要な権限を持つと判断された場合はステップＳ６１１に遷移し、ユーザーが必要な権限を持たないと判断された場合はステップＳ６５０に遷移する。ステップＳ６１１で認証認可共通権限検証モジュール３０３は、権限検証の結果、ステップＳ６０１で認証認可共通権限検証モジュール３０３が受信したトークンは、リソースを利用する権限を持つと判断されたことをリソースサーバーに通知し、フローを終了する。ステップＳ６５０で認証認可共通権限検証モジュール３０３は、ステップＳ６０１で認証認可共通権限検証モジュール３０３が受信したトークンは、リソースを利用する権限を持たないと判断されたことをリソースサーバーに通知し、フローを終了する。

図５（Ｂ）は本実施の形態に係る、認証・認可サーバー１５１における、クライアントの権限検証フローである。本フローは図５（Ａ）におけるステップＳ６０７の詳細フローである。ステップＳ７０１で認証認可共通権限検証モジュール３０３は、認可モジュール３０２が管理するアクセストークンテーブルに問い合わせ、アクセストークンに紐付くクライアントを取得する。たとえばここで、アクセストークンが表２に示されるＡｚ９９８８７７６６だったとすると、アクセストークンに紐付くクライアントはＡｐｐＡｍ００１であると判断される。

ステップＳ７０２で認証認可共通権限検証モジュール３０３は、クライアント管理モジュール３０５が管理するクライアント権限テーブルに問い合わせ、ステップＳ７０１で取得したクライアントの権限を取得する。表３はクライアント権限テーブルの例である。

ここでクライアント識別子がＡｐｐＡｍ００１だった場合、クライアントはＡｐｐ−Ａ−Ｉｎｔｅｇｒａｔｉｏｎの権限を持つと判断される。

ステップＳ７０３で認証認可共通権限検証モジュール３０３は、スコープ管理モジュール３０６が管理するスコープテーブルに問い合わせ、ステップＳ６０２で取り出したスコープリストの各スコープで要求されるクライアントの権限を取得する。表４はスコープリストテーブルの例である。

ここでリソース利用に必要なスコープがｏｗｎｅｒ．Ａｐｐ−Ａ−ＲｅａｄＷｒｉｔｅ，ｃｌｉｅｎｔ．Ａｐｐ−Ａ−Ｉｎｔｅｇｒａｔｉｏｎだったとする。ここでクライアントに要求されるスコープはプレフィクスがｃｌｉｅｎｔであるｃｌｉｅｎｔ．Ａｐｐ−Ａ−Ｉｎｔｅｇｒａｔｉｏｎのため、要求されるクライアントの権限はＡｐｐ−Ａ−Ｉｎｔｅｇｒａｔｉｏｎであると判断される。

ステップＳ７０４で認証認可共通権限検証モジュール３０３は、ステップＳ７０２で取得したクライアントの権限が、ステップＳ７０３で取得した要求されるクライアントの権限をすべて含むか判断する。要求される権限をすべて含むと判断された場合はステップＳ７０５に遷移する。また要求される権限の内、１つでも含まれないものがあると判断された場合はステップＳ７５０に遷移する。たとえばここで、アクセストークンが表２に示されるＡｚ９９８８７７６６で、リソース利用に必要なスコープがｏｗｎｅｒ．Ａｐｐ−Ａ−ＲｅａｄＷｒｉｔｅ，ｃｌｉｅｎｔ．Ａｐｐ−Ａ−Ｉｎｔｅｇｒａｔｉｏｎだったとする。この場合、クライアントが持つ権限はＡｐｐ−Ａ−Ｉｎｔｅｇｒａｔｉｏｎであり、要求されるクライアントの権限もＡｐｐ−Ａ−Ｉｎｔｅｇｒａｔｉｏｎとなる。そのためクライアントは要求された権限をすべて持つと判断される。

ステップＳ７０５で認証認可共通権限検証モジュール３０３は、クライアントが、要求された権限を持つと判断し、フローを終了する。ステップＳ７５０で認証認可共通権限検証モジュール３０３は、クライアントが、要求された権限を持たないと判断し、フローを終了する。

図５（Ｃ）は本実施の形態に係る、認証・認可サーバー１５１における、ユーザーの権限検証フローである。本フローは図５（Ａ）におけるステップＳ６０９の詳細フローである。ステップＳ８０１で認証認可共通権限検証モジュール３０３は、ステップＳ６０２で取り出したトークンが認証トークンだったかアクセストークンだったか判断する。トークンが認証トークンだった場合はステップＳ８０３に遷移し、アクセストークンだった場合はステップＳ８０２に遷移する。

ステップＳ８０２で認証認可共通権限検証モジュール３０３は、認可モジュール３０２が管理するアクセストークンテーブルに問い合わせ、アクセストークンに紐付くユーザーを取得する。たとえばここで、アクセストークンが表２に示されるＡｚ９９８８７７６６だったとすると、アクセストークンに紐付くユーザーはＵｓｅｒ Ｘであると判断される。

ステップＳ８０３で認証認可共通権限検証モジュール３０３は、認証モジュール３０１が管理する認証トークンテーブルに問い合わせ、認証トークンに紐付くユーザーを取得する。たとえばここで、認証トークンが表１に示されるＡｎ００１１２２３３４４だったとすると、アクセストークンに紐付くユーザーはＵｓｅｒ Ｘであると判断される。

ステップＳ８０４で認証認可共通権限検証モジュール３０３は、ユーザー管理モジュール３０４が管理するユーザー権限テーブルに問い合わせ、ステップＳ８０２もしくはステップＳ８０３で取得したユーザーの権限を取得する。表５はユーザー権限テーブルの例である。

ここでユーザーがＵｓｅｒ Ｘだった場合、ユーザーはＡｐｐ−Ａ−ＲｅａｄＷｒｉｔｅおよびＡｐｐ−Ｂ−Ｒｅａｄの権限を持つと判断される。

ステップＳ８０５で認証認可共通権限検証モジュール３０３は、スコープ管理モジュール３０６が管理するスコープテーブルに問い合わせ、ステップＳ６０２で取り出したスコープリストの各スコープで要求されるユーザーの権限を取得する。

ここでリソース利用に必要なスコープがｏｗｎｅｒ．Ａｐｐ−Ａ−ＲｅａｄＷｒｉｔｅ，ｃｌｉｅｎｔ．Ａｐｐ−Ａ−Ｉｎｔｅｇｒａｔｉｏｎだったとする。ここでユーザーに要求されるスコープはプレフィクスがｏｗｎｅｒであるｏｗｎｅｒ．Ａｐｐ−Ａ−ＲｅａｄＷｒｉｔｅのため、要求されるユーザーの権限はＡｐｐ−Ａ−ＲｅａｄＷｒｉｔｅであると判断される。

ステップＳ８０６で認証認可共通権限検証モジュール３０３は、ステップＳ８０４で取得したユーザーの権限が、ステップＳ８０５で取得した要求されるユーザーの権限をすべて含むか判断する。要求される権限をすべて含むと判断された場合はステップＳ８０７に遷移する。また要求される権限の内、１つでも含まれないものがあると判断された場合はステップＳ８５０に遷移する。たとえばここで、トークンが認証トークンであり、表１に示されるＡｎ００１１２２３３４４で、リソース利用に必要なスコープがｏｗｎｅｒ．Ａｐｐ−Ａ−ＲｅａｄＷｒｉｔｅ，ｃｌｉｅｎｔ．Ａｐｐ−Ａ−Ｉｎｔｅｇｒａｔｉｏｎだったとする。この場合、ユーザーが持つ権限はＡｐｐ−Ａ−ＲｅａｄＷｒｉｔｅであり、要求されるユーザーの権限もＡｐｐ−Ａ−ＲｅａｄＷｒｉｔｅとなる。そのためクライアントは要求された権限をすべて持つと判断される。

ステップＳ８０７で認証認可共通権限検証モジュール３０３は、ユーザーが、要求された権限を持つと判断し、フローを終了する。ステップＳ８５０で認証認可共通権限検証モジュール３０３は、ユーザーが、要求された権限を持たないと判断し、フローを終了する。

図６は本実施の形態に係る、画面の表示例である。図６（Ａ）はユーザーがログインするときに操作する認証画面１００１の例である。また図６（Ｂ）はユーザーがクライアントモジュールを認可しアクセストークンの発行を許可する認可確認画面１００２の例である。

本実施の形態によれば、リソースサーバー１５２は、リソース管理モジュール３５１が受信したトークンの種別に関わらず、同じスコープリストを認証・認可サーバー１５１に渡すことで権限検証を要求できるようになる。トークンの種別に依存せずに共通の権限検証モジュールを呼び出せるようになるため、リソースサーバー１５２の開発効率が向上する。

次に、本発明を実施するための第２の形態について図面を用いて説明する。なお第１の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。

本実施の第１の形態でリソースサーバー１５２は、トークン種別を意識せずに、認証・認可サーバー１５１に対してトークンの検証を要求できるようになった。しかしリソースサーバー１５２のあるリソースに関しては、認証トークンに対してはリソースの利用を許可するが、アクセストークンに対してはリソースの利用を許可しないことも考えられる。このようなケースでは、認証・認可サーバー１５１はトークンの種別によって権限検証の判断を変えつつ、リソースサーバー１５２はトークン種別を意識しないことが必要になる。

また当初はアクセストークンでの利用を禁止したリソースであっても、リソースサーバー１５２のバージョンアップ等によって、アクセストークンでの利用を許可するようになることも考えられる。前述のようなケースでは、アクセストークンによる当該リソースの利用を正式に公開する前に、特定の認可クライアント１７２のみに対して限定的に機能を公開してテストできることが求められる。本実施の第２の形態は、前述の課題をかんがみて為されたものである。

図７は本実施の第２の形態に係る、認証・認可サーバー１５１のモジュール構成を示す図である。図７（Ａ）は認証・認可サーバー１５１、図７（Ｂ）はリソースサーバー１５２のモジュール構成を、それぞれ示す。認証・認可サーバー１５１は認証モジュール３０１、認可モジュール３０２、認証認可共通権限検証モジュール３０３を持つ。また認証・認可サーバー１５１はユーザー管理モジュール３０４、第２のクライアント管理モジュール３２０、第２のスコープ管理モジュール３２１を持つ。リソースサーバー１５２はリソース管理モジュール３５１、トークン検証要求モジュール３５２を持つ。またリソースサーバー１５２はリソース管理モジュール３６１、トークン検証要求モジュール３６２も持つ。

表６および表７はそれぞれ、本実施の第２の形態に係る、第２のクライアント権限テーブルおよび第２のスコープリストテーブルの例である。第２のクライアント権限テーブルおよび第２のスコープリストテーブルはそれぞれ、第２のクライアント管理モジュール３２０および第２のスコープ管理モジュール３２１に管理されている。

ここで図５（Ｂ）のクライアントの権限検証フローを例にとって説明を行う。ステップＳ７０４で認証認可共通権限検証モジュール３０３は、ステップＳ７０２で取得したクライアントの権限が、ステップＳ７０３で取得した要求されるクライアントの権限をすべて含むか判断する。たとえばここで、アクセストークンに紐付くクライアント識別子がＡｐｐＡｍＤｅｂｕｇで、リソース利用に必要なスコープがｏｗｎｅｒ．Ａｐｐ−Ａ−ＲｅａｄＷｒｉｔｅ，ｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄだったとする。この場合、クライアントが持つ権限にはｃｌｏｓｅｄＢｅｔａ−ＬｉｍｉｔｅｄＩｎｔｅｇｒａｔｉｏｎが含まれ、要求されるクライアントの権限のｃｌｏｓｅｄＢｅｔａ−ＬｉｍｉｔｅｄＩｎｔｅｇｒａｔｉｏｎを満たす。そのためクライアントは要求された権限をすべて持つと判断され、ステップＳ７０５に遷移する。

ステップＳ７０５で認証認可共通権限検証モジュール３０３は、クライアントが、要求された権限を持つと判断し、フローを終了する。なお、本実施の第２の形態におけるアクセストークンは、ｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄのスコープと関連付けられて発行されるトークンとしているため、Ｓ６０５のステップからＳ６０６へ遷移することになる。このようにすることでスコープの確認は問題ないと判断されることにはなるが、上述した通りクライアントに権限がない以上、認可クライアント１７１によるサービスの利用は認可されない。

図８は本実施の第２の形態に係る、ユーザー操作および異なる認可クライアントからのリソース要求に対する、リソースサーバー１５２から認証・認可サーバー１５１への権限検証要求を模式的に表した図である。

ここで認可クライアント１７１は通常の認可クライアントを想定し、一般公開されているＲＥＳＴ ＡＰＩのみを利用可能とするためｃｌｏｓｅｄＢｅｔａ−ＬｉｍｉｔｅｄＩｎｔｅｇｒａｔｉｏｎロールを持たないとしている。また認可クライアント１７２は、リソースサーバー１５２のＲＥＳＴ ＡＰＩをアクセストークン向けに公開する前のテストをする特殊な認可クライアントを想定している。そのため認可クライアント１７２は通常はアクセストークンでは利用できないＲＥＳＴ ＡＰＩも利用可能とするためｃｌｏｓｅｄＢｅｔａ−ＬｉｍｉｔｅｄＩｎｔｅｇｒａｔｉｏｎロールを持つとしている。

またリソースサーバー１５２のＲＥＳＴ ＡＰＩ−１はリソース管理モジュール３５１およびトークン検証要求モジュール３５２に対応するＲＥＳＴ ＡＰＩである。ＲＥＳＴ ＡＰＩ−１を利用する認可クライアントは、ｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄスコープを要求されない。またリソースサーバー１５２のＲＥＳＴ ＡＰＩ−２は第２のリソース管理モジュール３６１および第２のトークン検証要求モジュール３６２に対応するＲＥＳＴ ＡＰＩである。ＲＥＳＴ ＡＰＩ−２を利用する認可クライアントは、ｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄスコープを要求される。

２００１は認可クライアント１７１が、ＲＥＳＴ ＡＰＩ−１を呼び出す際の処理の流れを表す。２００１では認可クライアント１７１は、事前に取得したアクセストークンを用いてＲＥＳＴ ＡＰＩ−１を呼び出す。ここでＲＥＳＴ ＡＰＩ−１はｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄを要求しないため、ｃｌｏｓｅｄＢｅｔａ−ＬｉｍｉｔｅｄＩｎｔｅｇｒａｔｉｏｎロールを持たない認可クライアント１７１でも利用可能である。

２１０１は認可クライアント１７１が、ＲＥＳＴ ＡＰＩ−２を呼び出す際の処理の流れを表す。２１０１では認可クライアント１７１は、事前に取得したアクセストークンを用いてＲＥＳＴ ＡＰＩ−２を呼び出す。ここでＲＥＳＴ ＡＰＩ−２はｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄを要求するため、ｃｌｏｓｅｄＢｅｔａ−ＬｉｍｉｔｅｄＩｎｔｅｇｒａｔｉｏｎロールを持たない認可クライアント１７１では利用できない。

２１０２はユーザー端末１９１が、ＲＥＳＴ ＡＰＩ−２を呼び出す際の処理の流れを表す。２１０２ではユーザー端末１９１は、画面リポジトリから画面リソースを取得する。さらにユーザー端末１９１は、前記取得した画面リソースを介して、事前に取得した認証トークンを用いてＲＥＳＴ ＡＰＩ−２を呼び出す。ここでＲＥＳＴ ＡＰＩ−２はｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄを要求する。ただし認証認可共通権限検証モジュール３０３による権限検証時、認証トークンの場合はクライアント権限検証が行われない。そのためユーザー端末１９１は、ｃｌｏｓｅｄＢｅｔａ−ＬｉｍｉｔｅｄＩｎｔｅｇｒａｔｉｏｎロールの有無にかかわらずＲＥＳＴ ＡＰＩ−２を利用可能である。

２２０１は認可クライアント１７２が、ＲＥＳＴ ＡＰＩ−２を呼び出す際の処理の流れを表す。２２０１では認可クライアント１７２は、事前に取得したアクセストークンを用いてＲＥＳＴ ＡＰＩ−２を呼び出す。ここでＲＥＳＴ ＡＰＩ−２はｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄを要求するが、認可クライアント１７２はｃｌｏｓｅｄＢｅｔａ−ＬｉｍｉｔｅｄＩｎｔｅｇｒａｔｉｏｎロールを持つため、ＲＥＳＴ ＡＰＩ−２を利用可能である。

本実施の第２の形態によれば、システム間連携のようにユーザーが直接介在しないアクセストークンを用いたユースケースではリソースの利用を禁止できる。その場合でも、ユーザーが直接画面操作するような認証トークンを用いたユースケースではリソースの利用を許可するといった制御を実現できる。なおその際にリソースサーバー１５２はあらかじめ定められたスコープｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄを指定して認証・認可サーバー１５１に対して権限検証を要求するだけでよく、リソースサーバー１５２がトークンの種別を意識する必要はない。そのためリソースサーバー１５２の開発を効率的に行える。

またリソースサーバー１５２のあるリソースの利用に認可クライアント１７１からは前述のリソースを禁止しつつ、さらにあらかじめ定めた認可クライアント１７２のみ、正式リリース前のリソースを利用できるよう制御ができるようになる。

なお認可クライアント１７２による十分なテストが実施された後には、リソースサーバー１５２は、前述のリソースを利用するためのスコープとしてｃｌｉｅｎｔ．ｎｏｔＡｌｌｏｗｅｄを要求しないようバージョンアップすることが考えられる。そのようにすることで前述のリソースを認可クライアント１７１に対しても公開できるようになる。

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

１５１ 認証・認可サーバー
１９１ ユーザー端末
３０１ 認証モジュール
３０２ 認可モジュール
３０３ 認証認可共通権限検証モジュール
３０４ ユーザー管理モジュール
３０５ クライアント管理モジュール
３０６ スコープ管理モジュール
３５１ リソース管理モジュール
３５２ トークン検証要求モジュール

Claims (10)

1. 端末および認可クライアントへ特定の機能を提供するサービスを備えた情報処理装置と通信可能な認証サーバーシステムであって、
   前記端末を操作するユーザーが正規のユーザーであるか否かを検証するための第１の種別のトークン、および前記サービスと連携する認可クライアントに移譲された権限で前記サービスを利用できるか否かを検証するための第２の種別のトークンを発行する発行手段と、
   前記発行手段により発行されたトークンの種別に依らず、前記情報処理装置から検証要求およびスコープとともに受信したトークンを基に検証のための確認を行い検証の結果を通知する検証手段とを有し、
   前記検証手段は、前記第１の種別のトークンを受信した場合は、トークンに関連付けられた権限の確認を行わず、前記第２の種別のトークンを受信した場合は、トークンに関連付けられた権限の確認を行い、かつ前記スコープがトークンに関連付けられた権限の範囲内であるか否かを確認することを特徴とする認証サーバーシステム。
2. 前記検証手段が前記情報処理装置から受信する前記スコープは、前記認可クライアントから前記情報処理装置に対して要求された前記サービスを利用するためのスコープであることを特徴とする請求項１に記載の認証サーバーシステム。
3. 前記検証手段が前記情報処理装置から受信する前記スコープは、前記第２の種別のトークンを用いて前記サービスを利用することを禁止するためのスコープであることを特徴とする請求項１または２に記載の認証サーバーシステム。
4. 前記検証手段は、前記第２の種別のトークンを受信した場合、トークンを基に前記認可クライアントに関連付く権限の確認を行い、かつ前記スコープが前記認可クライアントに関連付く権限の範囲内であるか否かを確認し、
   前記スコープがトークンに関連付けられた権限の範囲内であると確認され、かつ前記スコープが前記認可クライアントに関連付く権限の範囲内であると確認されたことに応じて、前記サービスと連携する前記認可クライアントに移譲された権限で前記サービスを利用できる旨を検証の結果として通知することを特徴とする請求項１乃至３の何れか１項に記載の認証サーバーシステム。
5. 前記検証手段は、前記情報処理装置から受信する前記スコープが前記第２の種別のトークンを用いて前記サービスを利用することを禁止するためのスコープであっても、前記認可クライアントに関連付く権限が特定の権限であると確認した場合は、前記サービスと連携する前記認可クライアントに移譲された権限で前記サービスを利用できる旨を検証の結果として通知することを特徴とする請求項１乃至４の何れか１項に記載の認証サーバーシステム。
6. 前記発行手段は、認証画面を介して入力された認証情報が妥当であると判断した場合に前記第１の種別のトークンを発行し、認可確認画面を介して前記サービスにおけるユーザーの権限を前記認可クライアントに移譲することが認可されたと判断した場合に前記第２の種別のトークンを発行することを特徴とする請求項１乃至５の何れか１項に記載の認証サーバーシステム。
7. 前記検証手段は、前記第１の種別のトークンを受信した場合は、前記端末を操作するユーザーのユーザー情報が前記認証サーバーシステムに登録されているか否かを確認することを特徴とする請求項１乃至６の何れか１項に記載の認証サーバーシステム。
8. 端末および認可クライアントへ特定の機能を提供するサービスを備えた情報処理装置と通信可能な認証サーバーシステムで実行される方法であって、
   発行手段は、前記端末を操作するユーザーが正規のユーザーであるか否かを検証するための第１の種別のトークン、および前記サービスと連携する認可クライアントに移譲された権限で前記サービスを利用できるか否かを検証するための第２の種別のトークンを発行し、
   検証手段は、前記発行手段により発行されたトークンの種別に依らず、前記情報処理装置から検証要求およびスコープとともに受信したトークンを基に検証のための確認を行い検証の結果を通知し、
   更に、前記検証手段は、前記第１の種別のトークンを受信した場合は、トークンに関連付けられた権限の確認を行わず、前記第２の種別のトークンを受信した場合は、トークンに関連付けられた権限の確認を行い、かつ前記スコープがトークンに関連付けられた権限の範囲内であるか否かを確認することを特徴とする方法。
9. 請求項８に記載の方法を認証サーバーシステムに実行させるためのプログラム。
10. 請求項９に記載のプログラムを記憶した記憶媒体。

Images