JP2018093407A - システム、リソースサーバ、システムの制御方法およびプログラム - Google Patents

Abstract

【課題】署名付き認可トークンによる認証において必要な項目のみ認可サーバへの問い合わせを行い、認可サーバのトークン検証の負荷、リソースサーバのパフォーマンス低下を低減するシステムを提供する。【解決手段】ネットワークを介してサービスを提供するリソースサーバ２０２と、認可サーバ２０１とを含むシステムであって、認可サーバ２０１は、付加情報が付加された、署名付きの認可情報を発行するＪＷＳトークン発行部６０４を有し、リソースサーバ２０２は、署名付きの認可情報の署名を検証するＪＷＳトークン検証部６１２と、署名付きの認可情報に含まれる各項目が認可サーバ２０１に問い合わせるべき項目であるかを示す付加情報に基づいて、認可サーバ２０１に問い合わせが必要な項目の検証要求を行うＪＷＳトークン管理部６１１と、を有する。【選択図】図５

Description

本発明は、システム、リソースサーバ、システムの制御方法およびプログラムに関する。

ほとんどのネットワーク上のＷｅｂサービスでは、利用者がＷｅｂサービスの利用を認められているかどうかの認証・認可が行われる。そして、Ｗｅｂサービスが多様化し、複数のＷｅｂサービスが互いに連携を行うようになるにつれ、Ｗｅｂサービスを提供するリソースサーバと認証・認可を行う認可サーバが別々のサーバとして構成されるようになってきた。このような構成では、認可サーバとリソースサーバが互いに認証・認可情報を授受することで連携している。認可サーバは認可情報を含む認可トークンを発行し、クライアントは認可トークンを利用してリソースサーバからサービスの提供を受ける。このような認可情報の授受に関する仕様の一つとしてＯＡｕｔｈ等が公開されている。

従来のＯＡｕｔｈ仕様の実装においては、クライアントからリソースサーバが受け取った全ての認可トークンについて、基本的に、リソースサーバが認可サーバ（トークンのステートを持つサーバー）に対して、該トークンの検証問い合わせを行うことになる。また一般に、トークンに紐付くユーザ情報についても同様に、リソースサーバがトークンに紐付くユーザ情報を所有する認可サーバに情報問い合わせを行うことになる。このように、クライアント、リソースサーバの台数が増えるに従い、リソースサーバから認可サーバ（発行済みトークンのトークン情報及びトークンに紐付くユーザ情報を持つサーバ）へのトークン検証、情報問い合わせが増え、認可サーバの負荷が高くなる。またクライアントから受信した全トークンについて毎回認可サーバに検証、情報問い合わせをおこなうことにより、リソースサーバのパフォーマンスが低下することになる。

ところで、認可サーバの負荷やリソースサーバのパフォーマンス低下を抑制するために、リソースサーバがクライアントから受け取った認可トークンをリソースサーバ自身で検証できるようにすることが考えられる。この場合、認可サーバで発行するトークンに、予め認可情報（トークンＩＤ、スコープ、有効期限など）およびトークンに紐付く情報（ユーザＩＤ、クライアントＩＤ、ユーザ名、メールアドレスなど）を付与する。リソースサーバが行っていたトークンの検証は、認可サーバがトークンに署名を付与してリソースサーバで行えるようにすればよい。特許文献１は、譲渡元ユーザの識別情報がグッドユーザリストに含まれている場合に、トークンの譲渡を受けたシステムが譲渡トークンに含まれる情報により譲渡トークンの正当性を検証することができる権限管理システムを開示している。

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

しかし、認可サーバで発行する署名付きトークンの認可情報、該トークンに紐付く情報については、認可サーバにおいてトークンの有効期限内に変更になる可能性がある。その際のリソースサーバでの署名付きトークン検証においては、リソースサーバは、発行済みの署名付きトークンに付与された情報の確からしさは検証できるが、それら情報について、認可サーバで現在管理されている情報を確認することができない。今現在の署名付きトークンに付与された情報を確認するためには、リソースサーバがクライアントから受け取った署名付きトークンを使用する際に、毎回認可サーバに検証、情報問い合わせを行うことになる。しかしながら、これは従来の認可サーバのトークン検証と同様にクライアント、リソースサーバの台数が増えるに従い、負荷が高くなる。また毎回認可サーバに検証、情報問い合わせをおこなうことにより、リソースサーバのパフォーマンスが低下することになる。

本発明は、署名付き認可トークンによる認証において必要な項目のみ認可サーバへの問い合わせを行い、認可サーバのトークン検証の負荷、リソースサーバのパフォーマンス低下を低減するシステムを提供することを目的とする。

上記課題を解決するために、本発明のシステムは、ネットワークを介してサービスを提供するサービス提供装置と、認可サーバとを含むシステムであって、前記認可サーバは、付加情報が付加された、署名付きの認可情報を発行する発行手段を有し、前記サービス提供装置は、前記署名付きの認可情報の前記署名を検証する署名検証手段と、前記署名付きの認可情報に含まれる各項目が前記認可サーバに問い合わせるべき項目であるかを示す前記付加情報に基づいて、前記認可サーバに問い合わせが必要な項目の検証要求を行う検証要求手段と、を有する。

本発明によれば、署名付き認可トークンによる認証において必要な項目のみ認可サーバへの問い合わせを行い、認可サーバのトークン検証の負荷、リソースサーバのパフォーマンス低下を低減するシステムを提供することができる。

情報処理装置の構成内容を示す図である。 ネットワーク構成図である。 認可トークン発行および検証のシーケンス図である。 署名付き認可トークン発行および検証のシーケンス図である。 認可サーバおよびリソースサーバのシステムの機能ブロック図である。 ＪＷＳトークンの発行および検証のシーケンス図である。 認可サーバのトークン発行処理のフローチャートである。 ＪＷＳトークンの発行要求の一例を示す図である。 ＪＷＳトークン発行処理のフローチャートである。 ＪＷＳトークンの一例を示す図である。 認可サーバから返却されるＪＷＳトークンの一例を示す図である。 サービス提供要求の一例を示す図である。 ＪＷＳトークン検証処理のフローチャートである。 ＪＷＳトークン検証処理のフローチャートである。 認可サーバへの情報問い合わせのフローチャートである。 リソースサーバのクレーム確認処理のフローチャートである。 ＪＷＳトークンの発行および検証のシーケンス図である。 第２実施形態における情報取得要求および返却の一例を示す図である。

図１は、情報処理装置のシステム構成を示す図である。図１において、情報処理装置は、ＣＰＵ１０２、メモリ１０３、記憶装置１０４、ビデオインタフェース１０５、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下、Ｉ／Ｏと略称）インタフェース１０６、通信インタフェース１０７を備えている。また、情報処理装置内の各構成要素は、システムバス１０１を介して互いに接続されている。

ＣＰＵ１０２は、システムバス１０１を介して各構成要素を制御したり、データの計算や加工を行ったりする中央処理装置である。メモリ１０３は、データやプログラムを記憶する装置で、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）から構成される。記憶装置１０４は、記憶されたデータの書き込み／読み出しを行う。記憶装置１０４は、ＨＤＤ（ハードディスクドライブ）１１１、不揮発性のデータソースとして利用されるＤＶＤ−ＲＯＭドライブ１１２、半導体メモリを用いたＳＳＤ（ソリッドステートドライブ）１１３を有している。また、図１には示されていないが、記憶装置１０４として、磁気テープドライブ、フロッピー（登録商標）ディスクドライブ（ＦＤＤ）、ＣＤ−ＲＯＭドライブ、ＣＤ／ＤＶＤ−ＲＡＭドライブ、ＵＳＢフラッシュドライブなども使用されることがある。

本実施形態に係るプログラムは、記憶装置１０４から読み込まれ、メモリ１０３に格納された上で、ＣＰＵ１０２によって実行される。なお、本実施形態ではプログラムを記憶装置１０４から読み込む構成としているが、ＲＯＭ（不図示）から読み込んだり、通信インタフェース１０７を介して外部から読み込んだりする構成としてもよい。

ビデオインタフェース１０５は、表示装置１１４への表示出力を制御する。表示装置１１４には、例えば、ＣＲＴや液晶等の方式を用いたものがある。Ｉ／Ｏインタフェース１０６には、例えば、キーボード１１５やポインティングデバイス１１６等の入力装置が接続される。ユーザは、キーボード１１５を操作することにより情報処理装置に対する動作指令等を行う。ポインティングデバイス１１６は、表示装置１１４上のカーソルを移動させてメニューやオブジェクトの選択や操作等を行う。また、表示装置１１４には、タッチパネル等による操作の入力を行えるものもある。この場合、表示装置１１４は出力装置と入力装置を兼ねることになる。通信インタフェース１０７は、ネットワーク１１７を通して外部機器との通信を行う。接続先のネットワークには、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットのような公衆回線等がある。

図２は、本実施形態に係る権限委譲システムのネットワーク構成図である。
インターネット２１０には、ネットワーク２１１、ネットワーク２１２、ネットワーク２１３が接続されている。ネットワーク２１１には、認可サーバ２０１が接続されている。また、ネットワーク２１２にはクライアント２０３、ネットワーク２１３にはリソースサーバ２０２がそれぞれ接続されている。なお、本実施形態において、認可サーバ２０１、クライアント２０３、リソースサーバ２０２は、それぞれインターネット２１０を跨いだ個別のネットワーク上に構成されているが、同一のネットワーク上に構成されていてもよい。

認可サーバ２０１は、権限移譲を実現するための認可サーバである。リソースサーバ２０２は、認可サーバ２０１と連携してユーザに各々のサービスを提供するサービス提供装置である。クライアント２０３はパソコン、スマートフォンなどのユーザが操作する情報機器であり、Ｗｅｂブラウザーやアプリケーションがインストールされている。クライアント２０３は、認可サーバ２０１から認可トークンを取得する。ユーザは取得した認可トークンを使って、Ｗｅｂブラウザーやアプリケーションを介してリソースサーバ２０２のＷｅｂサービス（以下、サービスと略称）の提供を受ける。なお、本実施形態において、認可サーバ２０１、クライアント２０３、リソースサーバ２０２はいずれも、図１にて示した情報処理装置の構成を有するものとする。ただし、図１の構成に限定するものではなく、表示装置１１４を備えていなかたり、他の機能を備えていていたりしても構わない。また、サーバは、単体のコンピュータに限らず、ラックマウント型の複数台のコンピュータで構成されたシステムであっても構わない。

図３および図４を参照して、従来の権限委譲システムにおける認可トークンの発行と検証の流れについて説明する。
図３は、認可トークン発行と検証に関するシーケンス図である。まず、クライアント２０３は、認可サーバ２０１に対して認証情報あるいは認可コードを渡し、認可トークンを要求する（Ｓ３０１）。認証情報か認可コードかは、オーナーの違いによって異なる。クライアント２０３が処理を実施するオーナーである場合はクライアント２０３自体が認証を行って認証情報を渡し、クライアント２０３が他のオーナーから処理を依頼される場合にはオーナーから受け取った認可コードを渡す。認可サーバ２０１は、認可トークンを発行し、クライアント２０３に返す（Ｓ３０２）。クライアント２０３は、認可サーバ２０１から認可トークンを取得する。

次に、クライアント２０３は、取得した認可トークンを使ってリソースサーバ２０２に対してサービスの提供を要求する（Ｓ３０３）。リソースサーバ２０２は、認可サーバ２０１に対し、受け取った認可トークンが適正かどうかを検証するよう要求する（Ｓ３０４）。認可サーバ２０１は、リソースサーバ２０２から受け取った認可トークンの検証を行い（Ｓ３０５）、検証結果をリソースサーバ２０２に返す（Ｓ３０６）。認可トークンが適正であれば、リソースサーバ２０２は、サービスを提供するための処理を実行し（Ｓ３０７）、処理結果をクライアント２０３に返す（Ｓ３０８）。なお、認可トークンが不適正であった場合は、リソースサーバ２０２は処理を行わず、エラーをクライアント２０３に返す。

図４は、署名付き認可トークンの発行と検証に関するシーケンス図である。まず、クライアント２０３は、認可サーバ２０１に対して認証情報あるいは認可コードを渡して署名付き認可トークンを要求する（Ｓ４０１）。認可サーバ２０１は、署名付き認可トークンを発行し、クライアント２０３に返す（Ｓ４０２）。クライアント２０３は、認可サーバ２０１から署名付き認可トークンを取得する。

次に、クライアント２０３は、取得した署名付き認可トークンを使ってリソースサーバ２０２に対してサービスの提供を要求する（Ｓ４０３）。リソースサーバ２０２は、受け取った署名付き認可トークンの署名を元に、認可トークンが適正かどうかを検証する（Ｓ４０４）。リソースサーバ２０２は、認可サーバ２０１の署名を認証する証明書を保持しており、証明書を利用して署名を確認することで適正な認可サーバで発行された認可トークンであるか否かを検証できる。そして、認可トークンが適正であれば、リソースサーバ２０２はサービスを提供するための処理を実行し（Ｓ４０５）、処理結果をクライアント２０３に返す（Ｓ４０６）。

認可サーバ２０１とリソースサーバ２０２はネットワーク上遠い位置に存在している。そのため、図３の３０３で示すように認可サーバ２０１へ認可トークンの検証を依頼すると処理パフォーマンスが低下してしまう。しかし、図４の４０３のようにリソースサーバ２０２内で検証を行うことで処理パフォーマンスの低下を防ぐことができる。なお、４０３の検証で認可トークンが不適正であった場合は、リソースサーバ２０２は処理を行わず、エラーをクライアント２０３に返す。なお、認可トークンが不適正であった場合は、リソースサーバ２０２は処理を行わず、エラーをクライアント２０３に返す。

Ｓ４０４の署名付き認可トークンの検証においては、リソースサーバ２０２内で署名付き認可トークンの検証を実施する。しかし、署名付き認可トークンの有効期限内に認可サーバ２０１内で署名付き認可トークンに紐付く諸情報が変更された場合、リソースサーバ２０２は情報の変更を検知する手段がない。例えば、電子メールアドレスのような情報が変更された場合、リソースサーバで電子メールアドレスを使用すると誤った情報に基づいてメールを送信してしまう。このような署名付き認可トークンに紐付く諸情報の変更に起因する誤作動を抑制するためには、リソースサーバ２０２で署名付き認可トークンに含まれる情報を利用する度に認可サーバ２０１に情報の問い合わせを行う必要がある。しかし、署名付き認可トークンに含まれる情報を利用する度に認可サーバ２０１に情報の問い合わせを行うと、署名付き認可トークンをリソースサーバ２０２内で検証することで抑制していた処理パフォーマンスの低下を打ち消してしまう恐れがある。

署名付き認可トークンに付与された情報には、リソースサーバ２０２がトークン有効期限内に必ず確認したい情報と、必ずしも確認の必要のない情報が混在している。これらを認可サーバ２０１のポリシーに従いリソースサーバ２０２で適切に確認し、確認の必要性に応じて認可サーバ問い合わせすることにより、認可サーバのトークン検証、情報取得の負荷を低減し、リソースサーバのパフォーマンスを上げることが望ましい。

（第１実施形態）
本実施形態においては、署名付きの認可トークンとして、通常の認可トークンの代わりに、認可トークン情報およびリソースオーナー情報である認可トークンに紐付くユーザ情報を格納するJWS（以降JWSトークンとする）を用いる。以下では、この署名付きの認可トークンをJWSトークンと記す。以下、本実施形態で用いるJWSトークンについて詳述する。

JWS（JSON Web Signature）は、JWT（JSON Web Token）で表現されたコンテンツをデジタル署名やMACs（Message Authentication Codes）により保護して表現する手段である。またJWTは、JSON（JavaScript(登録商標) Object Notation）をベースとしたデータ構造を用いたURLセーフなクレームの表現方法である。JWS、JWTについては、各々RFC（RFC7515（JWS）、RFC7519（JWT））として仕様化、公開されている。

表１は、本実施形態で使用するJWSトークンに含まれるクレーム（すなわち、項目）を表している。

表１のクレーム名クラス“Registered Claim”の各クレームは、JWTのRFC7519で予め定義されたクレームである。すなわち、"iss"(Issuer)はJWTの発行者の識別子を、"sub"(Subject)はJWTの主語となる主体の識別子を、"aud"(Audience)はJWTを利用することが想定された主体の識別子一覧を表す。また、"exp"(Expiration Time)はJWTの有効期限を、"nbf"(Not Before)はJWTが有効になる日時を、"iat"(Issued At)、"jti"(JWT ID)は、JWTのための一意な識別子を表す。上記"exp"、"nbf"、"iat"に指定する日時はIntDateで、1970-01-01T0:0:0Z UTCから指定されたUTCの日付/時刻まで秒の数を表わすJSON数値である。またこれらの”Registered Claim”の使用は任意である。

本実施形態においては、JWSトークンを発行する認可サーバが、"iss"として認可サーバのURIを設定する。また、"sub"としてユーザのUUID（Universally Unique Identifier）を設定する。さらに、"aud"としてリソースサーバのURIを設定する。そして、"exp"として本JWT発行時から3600秒、すなわち"iat"の値+3600を、"nbf"として本JWT発行時、すなわち"iat"と同じ値を設定する。また、本実施形態においては、"jti"として認可トークン情報の認可トークンIDを設定し、"jti"を必須のクレームとする。また、本実施形態においては、認可トークンIDをRegistered Claimクラスの"jti"クレームに持っている。しかし、他クラス（例えば、Public Claimクラス、Private Claimクラス）のクレームに、新規クレーム定義、あるいは既存クレームに割り当て、などして持っても良い。

次に、表１のクレーム名クラス“Private Claim”の各クレームについて説明する。
“authz:scopes”は認可トークンスコープリストを、“authz:client_id”はクライアントIDを、“ext:fname”はファーストネームを、“ext:lname”はラストネームを表す。また、“ext:locale”はローカル名を、“ext:tenantid@recm”はテナントＩＤを、“ext:email@req”は電子メールアドレスを、“ext:appid”はアプリケーションＩＤを表す。JWTのRFC7519によると、“Private Claim”は、JWT発行者と利用者の合意のものとで使用するプライベートクレーム名クラスで、他に定義されたクレーム名と衝突のないことを前提とする。本実施形態では、”Private Claim”クラスのクレーム名に、認可トークン情報と認可トークンに紐付くユーザ情報（即ちクライアントの属性情報）を持つことを特徴とする。認可トークン情報には、認可トークンスコープリスト“authz:scopes”、認可トークンクライアントID“authz:client_id”が含まれている。認可トークンに紐付くユーザ情報には、ファーストネーム“ext:fname”、ラストネーム“ext:lname”、テナントID“ext:tenantid@recm”、電子メールアドレス“ext:email@req”、アプリケーションID“ext:appid”が含まれている。

署名付きトークンの認可情報、該トークンに紐付く情報には、トークンの有効期限内であれば必ずしも認可サーバに問い合わせて確認する必要のない情報がある。例えば、トークンに紐付く情報としてユーザ名、ロケール、クライアントにアクセスするアプリケーション名、認可スコープなどがある。これらは、認可サーバやリソースサーバの提供するサービスによるが、一般的にトークン有効期限内に変更される可能性が低く、また例え変更されても残りのトークン有効期限内にリソース提供や情報取得を行っても事実上問題ない場合が多く存在する。一方、例えば電子メールアドレスなど、リソースサーバで該情報を使用する際、トークン有効期限内であっても必ず確認の必要のある情報もある。またそもそも、クライアントからのリソース要求の際にリソースサーバで利用しない情報である場合には、トークン有効期限内に認可サーバへの情報問い合わせの必要はない。また、情報問い合わせの必要な情報かどうかを、リソースサーバだけで判断できない場合もある。例えば、認可サーバ機能により認可スコープが頻繁に変更されるようなサービスの場合、認可スコープは必ず確認の必要がある情報となる。このように、署名付きトークンに付与された情報には、リソースサーバがトークン有効期限内に必ず確認したい情報と、必ずしも確認の必要のない情報が混在している。さらにトークンに紐付く情報を管理している認可サーバのポリシーに従い必ず毎回確認させたい情報もある。

そこで、JWSトークン発行部６０４は、トークンに付加情報を付加する。本実施形態では、“Private Claim”クラスのクレーム名に、必要に応じて付加情報として、タグ文字列であるアノテーション“@req”、“@recm”などを付けることが可能である。例えば、“ext:tenantid@recm”、“ext:email@req”のように、アノテーションを付加する。以下では、アノテーション“@req”、 “@recm”などの付加情報を、クレーム情報アノテーションと呼ぶ。上記“@req”アノテーションは、リソースサーバなどで該アノテーションの付いたクレームを参照する場合、認可サーバへの確認を要求する“required”アノテーションである。また上記“@recm”アノテーションは、リソースサーバなどで本アノテーションの付いたクレームを参照する場合、認可サーバへの確認を推奨する“recommended”アノテーションである。上記表１のJWSトークンに含まれるクレームの内容、また認可サーバによる発行、リソースサーバにおける使用については後述する。

次に、設定するクレームについて詳細を説明する。本実施形態においては、JWSトークンを発行する認可サーバが、認可情報として“authz:scopes”、 “authz:client_id”のクレームを設定する。すなわち、“authz:scopes”としてリソースサーバが取得を許可するリソースを表すスコープリストを設定する。また、“authz:client_id”としてリソースサーバにアクセスするクライアントのIDを設定する。

さらに、同じくJWSトークンを発行する認可サーバが、“authz:tokened”のトークンに紐付く属性情報として、“sub”に設定したユーザIDのユーザの情報を表すクレームとして以下を設定する。すなわち、“ext:fname”として”sub”に設定したUUIDのユーザのファーストネーム。“ext:lname”として“sub”に設定したUUIDのユーザのラストネーム。“ext:locale”として“sub”に設定したUUIDのユーザのロケール名。“ext:tenantid@recm”として“sub”に設定したUUIDのユーザが所属するテナントID。“ext:email@req”として“sub”に設定したUUIDのユーザの電子メールアドレス。“ext:applicationid”としてクライアントアプリケーションのIDであるアプリケーションID。詳細は、後述する。

本実施形態のJWSトークンは、それぞれエンコード済みのヘッダー、本体の情報に相当するペイロード、署名情報の３つを、この順序でピリオド文字('.')を区切り文字として連結したURL-safeな文字列である。JWSトークンは、JWSコンパクトシリアライゼーション仕様に従っている。
本実施形態のJWSトークンを発行する認可サーバにおいては、まず、ヘッダーをJWTの仕様であるRFC7519によりJSONとしてエンコード（すなわち、符号化、暗号化）し、エンコード済ヘッダーを生成する。次に、本体の情報（即ちペイロード）である表１のクレームの内容を、JWTの仕様であるRFC7519によりJSONとしてエンコードし、エンコード済ペイロードを生成する。そして、エンコード済ヘッダーとエンコード済ペイロードを、JWSの仕様であるRFC7515のコンパクトシリアライゼーション仕様に従って秘密鍵を用いて暗号化することでデジタル署名し、エンコード済署名を生成する。最後に、生成したエンコード済ヘッダーとエンコード済ペイロード、エンコード済署名を、ピリオドを介して連結させ、JWSトークンを生成する。詳細は、図９を用いて後述する。

本実施形態においては、JWSヘッダーとしてJWSの署名に使われる暗号アルゴリズムを識別する“alg”（アルゴリズム）を用いる。具体的には、“alg”として“RS256”（RSASSA-PKCS1_v1_5 using SHA-256）を用いる。“RS256”文字列は、algの値としてIANA JSON Web Signature and Encryption Algorithmsレジストリに登録されている。“alg”は、JSON Web Algorithms(JWA)仕様（RFC7518）のSection 3.1で定義されている。

なお本実施形態においてJWSの署名に使われる暗号アルゴリズム“RS256”で使用する秘密鍵、公開鍵の鍵ペアは、認可サーバが予め生成しておいたものを使用する。また、JWSの署名を検証する公開鍵はJWSトークンを使用するリソースサーバに予め配備しておく。

図５（Ａ）は、認証・認可システムの認可サーバ２０１における機能を示すブロック図である。認可サーバ２０１は、テナント管理部６０１、ユーザ管理部６０２、クライアント管理部６０３を備えている。さらに、認可サーバ２０１は、JWSトークン発行部６０４、JWSトークン管理部６０５、JWSトークン検証部６０６、リソースサーバ情報管理部６０７を備える。
テナント管理部６０１は、テナント情報の管理を行う。ユーザ管理部６０２は、ユーザ情報の管理を行う。クライアント管理部６０３は、クライアント情報の管理を行う。JWSトークン発行部６０４はJWSトークンの発行を行い、発行されたJWSトークンの情報は発行済みJWSトークン管理部６０５に保管される。JWSトークン検証部６０６は、JWSトークンが有効かどうか検証する。リソースサーバ情報管理部６０７は、認可サーバ２０１と連携するリソースサーバ２０２に関する情報を管理する。

表２〜表８を用いて、図５（Ａ）に示した認可サーバ２０１の各部が管理するデータテーブルについて詳細を説明する。各部は、下記表に示されたデータテーブルに基づいてJWSトークンを発行、検証する。
表２は、認可サーバ２０１のユーザ管理部６０２が管理する、ユーザ管理テーブルである。

表２のユーザ管理テーブルは、ユーザID項目、ユーザIDの内部表現であるUUID（ClientID）項目、前記ユーザIDに対応するパスワードを示すPassword項目、ユーザ種別を示すUser Type項目を含む。認可サーバ２０１は、UUIDとPasswordの情報の組を検証し、正しければ認証情報を生成する。

表３は、認可サーバ２０１のユーザ管理部６０２が管理する、ユーザ属性管理テーブルである。

表３のユーザ属性管理テーブルは、ユーザIDの内部表現であるUUID項目、UUIDのユーザの姓を示すFirst Name項目、名を示すLast Name項目を含む。さらに、ユーザ属性管理テーブルは、ロケールを示すLocale項目、同ユーザの所属するテナントを示すTenant ID項目、同ユーザの電子メールアドレスを示すEmail項目、同ユーザの使用できるサービスを示すService ID項目を含む。

表４は、認可サーバ２０１のクライアント管理部６０３が管理する、クライアント管理テーブルである。

表４のクライアント管理テーブルは、クライアントIDを示すClient ID項目、ClientIDのクライアントのクライアント名を示すClient Name項目を含む。さらに、クライアント管理テーブルは、OAuth2（RFC6749）プロトコル等で使用する、同クライアントのリダイレクトURLを示すRedirect URL、同クライアントの使用できるサービスを示すService ID項目を含む。

表５は、認可サーバ２０１のリソースサーバ情報管理部６０７が管理する、サービス管理テーブルである。

表５のサービス管理テーブルは、Service ID項目、Scope項目、URL項目を含む。Service ID項目は、リソースサーバで提供するリソースに関するサービスを表すサービスIDを示す。Scope項目は、OAuthプロトコルなどの認可要求のスコープに指定される内容であるScope項目を示す。URL項目は、Service IDに相当するサービス（リソース）を提供するリソースサーバのURLを示すURL項目を含む。

表６は、認証・認可システムの認可サーバ２０１の、JWSトークン発行部６０４および発行済みJWSトークン管理部６０５、JWSトークン検証部６０６が管理、参照するトークン管理テーブルである。

表６のトークン管理テーブルは、トークンIDを示すToken ID項目、認可トークンや認可コードなどトークンIDのトークンタイプを示すToken Type項目、トークンIDの有効期限を秒で示すExpiration Time項目を含む。さらに、トークン管理テーブルは、OAuthプロトコルなどの認可要求のスコープに指定される内容であるScope項目、OAuthプロトコルなどで使用するトークンIDのGrant Typeを示すGrant Type項目を含む。

表７は、認可サーバ２０１のJWSトークン発行部６０４、JWSトークン管理部６０５、JWSトークン検証部６０６が管理、参照するリフレッシュトークン管理テーブルである。

表７のリフレッシュトークン管理テーブルは、OAuthプロトコルなどで使用する、リフレシュトークンを管理するテーブルである。リフレッシュトークン管理テーブルは、トークンIDを示すToken ID項目、トークンIDのリフレッシュトークンのIDを示すRefresh Token Type項目を含む。さらに、リフレッシュトークン管理テーブルは、リフレッシュトークンIDの有効期限を秒で示すRefresh Token Expiration Time項目を含む。

表８は、認可サーバ２０１のJWSトークン発行部６０４、JWSトークン管理部６０５、JWSトークン検証部６０６が管理、参照するトークン属性管理テーブルである。

表８のトークン属性管理テーブルは、OAuthプロトコルなどで使用する、トークン属性を管理するテーブルである。トークン属性管理テーブルは、トークンIDを示すToken ID項目、トークンIDの発行要求元のクライアントIDを示すClient ID項目、トークンIDに紐付くUUIDを示すUUID項目を含む。さらに、トークン属性管理テーブルは、トークンIDを用いて、サービス管理テーブル表５のサービスIDのサービスを利用するアプリケーションを示すApplication IDを含む。

図５（Ｂ）は、認証・認可システムのリソースサーバ２０２における機能を示すブロック図である。リソースサーバ２０２は、リソース管理部６１０、JWSトークン管理部６１１、JWSトークン検証部６１２、認可サーバ情報管理部６１３を備える。
リソース管理部６１０は、後述するスコープとリソースの対応関係の定義を含むリソース情報の管理を行う。JWSトークン管理部６１１は、JWSトークン情報の管理を行う。JWSトークン検証部６１２は、JWSトークンの検証を行う。認可サーバ情報管理部６１３は、リソースサーバ２０２と連携する認可サーバ２０１に関する情報を管理する。

図６は、認証・認可システムの署名付き認可トークン発行と検証に関するシーケンス図である。本実施形態ではOAuth2（RFC6749）における認可コードグラントのフローを用いたJWSトークンの発行と検証について述べる。JWSトークンの発行と検証については、認可コードグラントだけでなく、OAuth2（RFC6749）にあるクライアントクレデンシャルグラント、リソースオーナーパスワードクレデンシャルグラント、インプリシットグラント等を用いても良い。

OAuth2プロトコルにおいては、認可トークン発行などのフローを開始する前に、クライアントを認可サーバ２０１に登録する。クライアント２０３を認可サーバ２０１に登録する方法は、通常エンドユーザーとの対話を伴うHTML登録フォームを持つことになる。本実施形態においては、予め必要なクライアントは登録されているものとする。クライアント登録の際、認可サーバ２０１はクライアント２０３に対してクライアントID、パスワードを発行する。そして、表２のユーザ管理テーブルのUUID（ClientID）に発行したクライアントを、Passwordに発行したパスワードを登録する。また、クライアント登録の際、後述する認可トークンに付与するScopeに関連付けられたサービスIDの値を、表４のクライアント管理テーブルに登録する。

また、本実施形態においては、認可サーバ２０１は、OAuth2（RFC6749）の認可コードフローに従い、ユーザ管理テーブル表２のユーザIDに相当するリソースオーナーの認証後、認可コードを登録する。登録する認可コードは、例えば、トークン管理テーブル表６、トークン属性管理テーブル表８などである。そして、クライアント２０３が認可コードを取得する。

図６において、まず、クライアント２０３が認可サーバ２０１に、OAuthプロトコルの仕様に従い認可コード、各種クレデンシャルを示して認可トークンの発行を要求する（Ｓ７０１）。認可サーバ２０１は、要求に応じてJWSトークンを発行する（Ｓ７０２）。Ｓ７０２の詳細については、図７および図９のフローチャートを参照して、その詳細を説明する。

図７および図９のフローチャートを参照して、JWSトークンの発行の詳細について説明する。図７は、クライアント２０３からのJWSトークン発行要求に対する、認可サーバ２０１の応答処理について示したフローチャートである。
認可サーバ２０１のJWSトークン発行部６０４は、クライアント２０３からのJWSトークン発行の要求を受信する（Ｓ８０１）。具体的には、図８に示されるJWSトークン発行要求を受信する。図８は、クライアントから認可サーバに送信されるJWSトークン発行要求の一例を示す図である。

次に、JWSトークン発行部６０４は、クライアント認証を行う（Ｓ８０２）。具体的には、JWSトークン発行部６０４は、JWSトークン発行要求のAuthorizationヘッダー部にBase64符号化されて含まれるClientID、パスワードを認証する。本実施形態の場合、Authorizationヘッダーに含まれるBase64符号を復号化し、表２のユーザ管理テーブルのUUID（ClientID）、Passwordの組と比較して認証する。また、OAuth2仕様に従い、JWSトークン発行部６０４は、表８のトークン属性テーブルを参照し、JWSトークン要求に含まれる認可コード項目がToken ID項目に存在するかどうか確認する。すなわち、code=AipziOBeZoQYbJS6WxSbKBがToken ID項目に存在するかどうか確認する。さらに、該Token IDに対応するClient ID項目を確認し、該Client ID項目に対応するリダイレクトIDを表４のクライアント管理テーブルから検索する。そして、JWSトークン要求に含まれるリダイレクトURI項目（redirect_uri= https%3A%2F%2Fclient%2Eexample%2Ecom%2Fredirect）に一致するかどうか確認する。

次に、JWSトークン発行部６０４は、Ｓ８０２の認証の成否を判断する（Ｓ８０３）。ここで認証に失敗したと判断された場合は、クライアントにエラーメッセージを返して（Ｓ８０７）処理を終了する。一方、認証に成功したと判断された場合はＳ８０４に進む。
認証に成功した場合、JWSトークン発行部６０４は、権限検証を行う（Ｓ８０４）。すなわち、JWSトークン発行部６０４は、表４のクライアント管理テーブルのクライアントIDに対応するサービスIDを参照し、さらに表５のサービス管理テーブルのサービスIDに対応するScopeが存在するかどうか確認する。

JWSトークン発行部は、Ｓ８０４のScope存在確認に基づいて、JWSトークン発行要求の権限検証の成否を判定し、トークンの発行の可否を判断する（Ｓ８０５）。クライアントIDに対応するScopeが存在しなければ、JWSトークン発行部６０４は、権限検証に失敗したとしてエラーメッセージをクライアントに返して（Ｓ８０７）処理を終了する。一方、権限検証に成功、すなわちクライアントIDに対応するScopeが存在したならば、JWSトークン発行部６０４は、JWSトークン発行が可能であると判断し、Ｓ８０６に進む。そして、JWSトークン発行を行い（Ｓ８０６）処理を終了する。Ｓ８０６の詳細については、図９のフローチャートを参照して説明する。

図９は、認可サーバ２０１におけるJWSトークンの発行処理について示したフローチャートである。
JWSトークン発行部６０４は、まず、JWSトークンのJWSヘッダーを生成する（Ｓ９０１）。具体的には、JWSトークン発行部６０４は、JWSヘッダーとして、"alg": "RS256"、"typ": "JWT"を設定する。そして、JWSトークン発行部６０４は、生成したJWSヘッダーをエンコードして、エンコード済みJWSヘッダーを生成する。

次に、JWSトークン発行部６０４は、受信したJWSトークン発行要求に基づいて行われた、クライアント認証および権限検証の情報に従ってJWSトークンのペイロード（即ち、データ本体）を生成する（Ｓ９０２）。JWSトークン発行部６０４は、JWSトークンのペイロードとして、表１のJWSトークンに含まれるRegistered ClaimとPrivate Claimに対応する情報を設定する。そして、JWSトークン発行部６０４は、生成したJWSペイロードをエンコードして、エンコード済みJWSペイロードを生成する。

具体的には、JWSトークン発行部６０４は、まず、表２、表５、表６を参照し、表１のRegistered Claimに対応するクレームを、以下のように設定する。
すなわち、JWTの発行者の識別子"iss"として、認可サーバ２０１のURI “https://auth.example.com”を設定する。JWTの主語となる主体の識別子"sub"として、JWSトークン発行要求に含まれる認可コードに対応するリソースオーナーのIDである、表２のUUID“1ce42f74-1225-4cbb-b23f-f525dabc3cfd”を設定する。JWTを利用することが想定された主体の識別子一覧"aud"として、Ｓ８０４で検証したScopeに相当するリソースサーバのURLである表５のURL項目の“https://print.srv.example.com”と“https://form.srv.example.com” を設定する。JWTの有効期限"exp"として、本実施形態の場合、JWT発行時から3600秒、すなわち“iat”の値+3600である“1472713413”を設定する。また、“nbf”としてJWT発行時、すなわち“iat”と同じ値“1472709813”を設定する。また、本実施形態においては、JWSトークンの発行時に認可トークンを表６のトークン管理テーブルに示すように発行する。“jti”として、該認可トークンの認可トークンID“b2652f6d75b14aa49adfe89b8808b337ef276e8d1363400d98fab100c7463df0”を設定する。

次に、JWSトークン発行部６０４は、表1のPrivate Claimに対応するクレームを設定する。このとき、JWSトークン発行部６０４は、表３、表４、表６、表８を参照し、JWSトークン発行要求のクライアントID、リソースオーナーIDであるユーザID（UUID）に紐付く値を設定する。
すなわち、“authz:scopes”として表６のScopes項目である“[client.PrintService client.FormService]”を設定する。“authz:client_id”として表４のClientID項目の“523ee20c9f39@2449baxt”を設定する。ファーストネーム“ext:fname”として表３の“John”を設定する。ラストネーム “ext:lname”として表３の“Doe”を設定する。ロケール名“ext:locale”として表３の“en_US.utf-8”を設定する。テナントID“ext:tenantid@recm”として表３の“170BA”を設定する。電子メールアドレス“ext:email@req”として表３の“john.doe@example.com”を設定する。アプリケーションID“ext:appid”として表８のApplicationID項目である“42c5a9626098459e96d4bacd73c29823392a76a02cc94d36985b7dc0d790b9a4”を設定する。

まとめると、Ｓ９０２において、表９に表されるような、署名を付加する前のJWSトークンのデータ本体であるJWSペイロードを設定する。表９は、本実施形態においてJWSトークン発行時にJWSトークン発行部６０４が設定する、JWSペイロードを示すテーブルである。

次に、JWSトークン発行部６０４は、JWSペイロードにデジタル署名を行う（Ｓ９０３）。具体的には、エンコード済JWSヘッダーとエンコード済JWSペイロードをピリオドで連結した文字列に対して、ヘッダーで指定されたアルゴリズムで、秘密鍵により暗号化してデジタル署名する。これは、JWSの仕様であるRFC7515のコンパクトシリアライゼーション仕様に従って行われる。そして、このデジタル署名（即ち、JWS署名）をエンコード（BASE64 URLエンコード）して、エンコード済JWS署名を生成する。
最後に、JWSトークン発行部６０４は、JWSトークンを生成、発行する（Ｓ９０４）。具体的には、エンコード済JWSヘッダー、エンコード済JWSペイロード、およびエンコード済JWS署名をこの順序で、ピリオド文字で連結して、JWSトークンを生成する。Ｓ９０４で生成したJWSトークンの一例を図１０に示す。図１０は、JWSトークンの一例を示す図である。２つのピリオド（．）によってエンコード済JWSヘッダー、エンコード済JWSペイロード、およびエンコード済JWS署名が連結されている。

ここで図６のフローに戻る。
認可サーバ２０１のJWSトークン発行部６０４は、上記のようにJWSトークンを生成すると、クライアント２０３に該JWSトークンを返却する（Ｓ７０３）。図１１は、認可サーバ２０１がクライアント２０３に返却するJWSトークンの一例を示す図である。
その後、認可サーバ２０１において、JWSトークン発行時のクレーム情報から変更が行われる可能性がある（Ｓ７０４）。

認可サーバ２０１からJWSトークンを受け取ったクライアント２０３は、先に取得したJWSトークンを使ってリソースサーバ２０２に対してサービスの提供を要求する（Ｓ７０５）。具体的には、クライアント２０３は、リソース要求のREST API呼び出しなどの際に、HTTPのAuthenticationヘッダーにJWSトークンを図１２に示すようにセットして利用する。図１２は、サービスの提供要求のHTTPのAuthenticationヘッダーにJWSトークンをセットした一例を示す図である。

クライアント２０３からJWSトークンを含むサービスの提供要求を受けたリソースサーバ２０２は、JWSトークンの検証を行う（Ｓ７０６）。JWSトークンの検証の詳細については、図１３および図１４を参照して説明する。
図１３および図１４は、リソースサーバ２０２のJWSトークン検証について示したフローチャートである。

リソースサーバ２０２は、クライアント２０３からのサービス提供要求時、HTTP Authorization ヘッダーとしてJWSトークンを受信する（ステップ１００１）。
次に、JWSトークンを受信したリソースサーバ２０２のJWSトークン検証部６１２は、JWSトークンを検証する。JWSトークンの検証はRFC7515のA.2.2仕様に従い、公開鍵により復号化して検証を行う。
JWSトークン検証部６１２は、JWSトークンの検証として、まず、JWS署名を検証する（Ｓ１００２）。具体的には、JWSトークン検証部６１２は、まずJWSトークンを、区切り文字ピリオド('.')文字でエンコード済JWSヘッダー、エンコード済JWSペイロード、およびエンコード済JWS署名に分割する。さらにJWSトークン検証部６１２は、分割したJWSヘッダー、JWSペイロード、JWS署名を復号化（BASE64 URLデコード）する。そして、JWSヘッダーに示されたアルゴリズム（“alg”: “RS256”）より、予め検証用に保存してある公開鍵証明書を用いてJWS署名を検証する。
そして、JWS署名検証の成否を判定する（Ｓ１００３）。JWS署名の検証に失敗したと判定された場合は、JWSトークン検証部６１２は、クライアント２０３にリソース取得エラーを返却して処理を終了する（Ｓ１００８）。一方、JWS署名の検証に成功したと判定された場合は、Ｓ１００４に進む。

JWS署名の検証に成功した場合、JWSトークン管理部６１１は、デコード（復号化）済みのJWSペイロードのJWTを参照して、クレーム情報の取得および検証を行う。ここで取得されるクレーム情報は、図９のＳ９０２で設定した表９の値である。
以下、Ｓ１００４〜Ｓ１０１４において、JWSトークン管理部６１１がクレーム情報を確認し、認可サーバ２０１に情報問い合わせの必要のあるクレームを決定し、認可サーバ問い合わせリストを作成する処理について説明する。

JWSトークン管理部６１１は、JWSトークンに含まれるクレーム情報のうち、表９のRegistered Claimクラスのクレームの検証を行う（Ｓ１００４）。本実施形態においては、トークンが消費される場所を表す“aud”、有効期限を表す“exp”, “nbt”についてチェックを行う。
JWSトークン管理部６１１は、Ｓ１００４の検証の結果に基づいて、トークンの有効、無効を判断する（Ｓ１００５）。ここで、“aud”に含まれる文字列のうち、リソースサーバ２０２のURLが含まれない場合や、“exp”が有効期限を過ぎているか、“nbt”が現在時刻以前である場合、受信したJWSトークンが有効でないと判断する。JWSトークンが有効でないと判断した場合は、クライアント２０３にエラーを返却して処理を終了する（Ｓ１００８）。一方、“aud”, “exp”, “nbt”の検証に成功したならば、Ｓ１００６に進む。

次に、JWSトークン管理部６１１は、Ｓ１００６〜Ｓ１０１２で、認可サーバに問い合わせが必要なクレームを確認し、認可サーバ問い合わせリストを作成する。
まず、JWSトークン管理部６１１は、JWSトークンに含まれるクレーム情報のうち、表９のPrivate Claimクラスのクレームの検証を行う（Ｓ１００６）。具体的には、Private Claimクラスの各クレームについて、クレーム名に、例えば、“@req”や“@recm”などのクレーム情報アノテーションが存在するかどうか確認する。

そして、JWSトークン管理部６１１は、該クレーム情報アノテーションに“required”アノテーション（“@req”）が存在するかどうか判定する（Ｓ１００７）。本実施形態の“required”アノテーションは、本クレームをリソースサーバが使用する場合、認可サーバに都度確認が必須であることを表す。例えば、電子メールアドレスを示すクレームが、“required”アノテーションが付加された“ext:email@req”クレームであれば、リソースサーバは該クレームを参照し電子メールアドレスを使用する場合、認可サーバに都度確認を行う。そのため、JWSトークン発行時から後に認可サーバ２０１の該情報が更新された場合でも、リソースサーバは更新内容を反映して、更新後の電子メールアドレスを使用してメールを正しく送信することができる。Ｓ１００７において、“required”アノテーションが存在すると判定された場合はＳ１０１０に進む。一方、“required”アノテーションが存在しないと判定された場合はＳ１００９に進む。

JWSトークン管理部６１１は、“required”アノテーションが付加されたクレームが、リソースサーバ２０２で使用するクレーム項目かどうかを判定する（Ｓ１０１０）。例えば、本実施形態の場合、“ext:email@req”項目の値である電子メールアドレスを使用するか否か判定する。Ｓ１０１０において、該クレームを使用すると判定された場合には、Ｓ１０１１に進む。そして、認可サーバ２０１に情報問い合わせを行うための認可サーバ問い合わせリストに、該クレームを追加する（Ｓ１０１１）。一方、JWSトークン管理部６１１が、“@req”アノテーションが付いているクレーム項目を使用しないと判定した場合は、Ｓ１０１２に進む。

Ｓ１０１２では、JWSトークン管理部６１１は、認可サーバに確認が必要かまだ判定されていないクレーム項目が残っているかどうか判定する（Ｓ１０１２）。クレーム項目がまだ残っていると判定された場合は、Ｓ１００７に戻り、次のクレームの判定処理を継続する。一方、クレーム項目が残っていない、即ち、すべてのクレーム項目が認可サーバに確認が必要であるか否か判定されたと判定された場合は、Ｓ１０１３に進む。

JWSトークン管理部６１１は、クレーム項目名に“@req”アノテーションが存在しないと判定した場合、該クレーム情報アノテーションに“recommended”アノテーション（“@recm”）が存在するかどうか判定する（Ｓ１００９）。本実施形態の“recommended”アノテーションは、本クレームをリソースサーバが使用する場合、認可サーバに都度確認を推奨することを表す。例えば、本実施形態では、テナントIDを示すクレームが、“recommended”アノテーションが付加された“ext:tenanted@recm”クレームである。そのため、リソースサーバが該クレームを参照し、テナントIDを利用する場合、認可サーバに都度確認を行うことが推奨されることを示している。例えば、JWSトークン発行時から後に、認可サーバ２０１の該情報が更新された場合、必要であればリソースサーバは更新内容を反映して更新後のテナントIDを使用して正しくテナントIDの表示を行うことができる。Ｓ１００９において、“@recm”が存在すると判定された場合、つまり本実施形態の場合クレーム項目名が表９の“ext:tenantid@recm”であれば、Ｓ１０１５に進む。一方、“@recm”が存在しないと判定された場合はＳ１０１２に進む。
Ｓ１０１５でJWSトークン管理部６１１は、“@recm”が存在すると判定されたクレームが、リソースサーバ２０２で確認したい項目かどうか判定する（Ｓ１０１５）。例えば、リソースサーバ２０２が正確なテナントIDに基づいてリソースを返す場合かどうかなどを判定する。Ｓ１０１５において、確認したい項目でないと判定された場合はＳ１０１２に進む。一方、確認したい項目であると判定された場合は、Ｓ１０１０に進み、実際に使用するクレーム項目かどうかを判定して、使用するのであれば、Ｓ１０１１において認可サーバ２０１に情報問い合わせを行うための認可サーバ問い合わせリストに追加する。

上記のように、認可サーバ問い合わせリストへの追加が終了し、Ｓ１０１２の判定で表９のクレーム項目を全て判定して検証すべき次のクレーム項目が存在しなくなった場合、Ｓ１０１３に進む。そして、後述する認可サーバ問い合わせ処理（Ｓ１０１３）とクレーム確認処理（Ｓ１０１４）を行って処理を終了する。

図１５は、図１４のＳ１０１３に記載の、リソースサーバ２０２によるJWSトークン認可サーバ問い合わせ処理の詳細を示すフローチャートである。本フローチャートは、JWSトークン管理部６１１が、図１４のJWSトークン検証処理のＳ１０１２において表９のクレーム項目を全て判定した後に、認可サーバ問い合わせリストを参照して実行する。なお、本実施形態においては、認可サーバ問い合わせリストに“ext:email@req”と“ext:tenantid@recm”が追加されているものとする。

まず、JWSトークン管理部６１１は、認可サーバ問い合わせリストが空かどうか判定する（Ｓ１１０１）。ここで該リストが空であると判定されれば、本フローチャートの処理を終了する。一方、該リストが空でないと判定されれば、Ｓ１１０２に進む。
次に、JWSトークン管理部６１１は、認可サーバ２０１に対してJWSトークン情報の検証を行いその検証結果をリソースサーバ２０２に返却するよう、検証要求（情報取得要求）を行い、認可サーバ２０１からJWSトークン情報を取得する（Ｓ１１０２）。なお、この検証要求は、図６のＳ７０７に対応している。

JWSトークン情報取得は、JWSトークン管理部６１１が以下のように行う。まず、JWSトークン管理部６１１は、認可サーバ問い合わせリストのクレーム項目の値を空欄にして、クレーム情報取得用JWSトークン（以下、情報取得用トークンと記す）を生成する。すなわち、本実施形態の場合、表９のうち認可サーバ問い合わせリストに存在する“ext:email@req”と“ext:tenantid@recm”の値を空欄にしたJWSトークンペイロードを作成する。さらにJWSトークン検証部６１２が分割したJWSヘッダー、JWS署名とともにJWSヘッダー、JWSペイロード、JWS署名を符号化（BASE64 URLエンコード）する。そして、この順序でピリオド('.')文字を区切り文字として連結した文字列にして、情報取得用トークンを生成する。なお、情報取得用トークンは、署名部分がリソース要求APIのJWSトークンと同じで厳密にはJWSではないクレーム情報取得用のトークンである。

次に、JWSトークン管理部６１１は、認可サーバ２０１に対して、検証要求を行う。具体的には、JWSトークン管理部６１１は、生成した情報取得用トークンを認可サーバ２０１に送信し、認可サーバ問い合わせリストのクレームの値を空欄にした“ext:email@req”と“ext:tenantid@recm”の値を要求する。
情報取得用トークンにより検証および情報取得を依頼された認可サーバ２０１のJWSトークン管理部６０５は、取得した情報取得用JWSトークンを、区切り文字ピリオド('.')文字で分割する。区切り文字ピリオド('.')文字での分割により、情報取得用トークンは、エンコード済JWSヘッダー、エンコード済JWSペイロード、およびエンコード済JWS署名に分割される。そして、発行済みJWSトークン管理部６０５は、分割したJWSペイロードを復号化（BASE64 URLデコード）し、“Registered Claim”クラスの"jti"クレームを参照する。本“jti”クレームは認可トークンの認可トークンIDを表すので、発行済みJWSトークン管理部６０５は、“jti”クレームの値である“b2652f6d75b14aa49adfe89b8808b337ef276e8d1363400d98fab100c7463df0”が表６トークン管理テーブルに存在することを確認する。さらに、発行済みJWSトークン管理部６０５は、トークンIDに基づいて、表８のトークン属性管理テーブルから情報取得用トークンのJWSペイロードのクレームの値の空欄項目を取得する。すなわち本実施形態においては、認可トークンID検証の後、“ext:email@req”として表８の“john.doe@example.com”を、“ext:tenantid@recm”として“170BA”を取得する。本実施形態においてはクレーム値にJWSトークン発行時と変更はないが、JWSトークン発行時から変更があった場合には、Ｓ１１０２のトークン情報取得により変更後のクレーム値を取得することができる。

認可サーバ２０１のJWSトークン管理部６０５は、情報返却用トークンを生成する。具体的には、まず、取得した情報取得用トークンをコピーし、取得したクレーム値を該コピーした情報取得用トークンのJWSペイロードに設定する。なお、本実施形態において取得したクレーム値は、例えば、“ext:email@req”として“john.doe@example.com”、 “ext:tenantid@recm”として“170BA”である。さらに、JWSトークン管理部６０５は、JWSペイロードを符号化（BASE64 URLエンコード）する。そして、JWSヘッダー、JWSペイロード、JWS署名を、この順序でピリオド('.')文字を区切り文字として連結した文字列にして情報返却用トークンを生成する。

その後、JWSトークン管理部６０５は、情報返却用トークンをリソースサーバ２０２に返却する。
情報返却用トークンを受信したリソースサーバ２０２は、JWSトークン管理部６１１およびJWSトークン検証部６１２により、情報返却用トークンの処理を行う。

ここで図１５のフローチャートに戻る。認可サーバ２０１から情報返却用トークンを受信したリソースサーバ２０２のJWSトークン管理部６１１は、受信が成功したかどうか判定する（Ｓ１１０３）。受信が成功していれば、JWSトークン管理部６１１は処理を終了する。一方、受信が失敗していた場合は、Ｓ１１０２と同様のトークン情報取得をリトライする（Ｓ１１０４）。そして、JWSトークン管理部６１１は、リトライの成否を判定する（Ｓ１１０５）。受信が成功していれば、JWSトークン管理部６１１は処理を終了する。一方、受信に失敗していた場合は、Ｓ１１０６に進む。

JWSトークン管理部６１１は、Ｓ１１０４のJWSトークン情報取得のリトライに失敗した場合、JWSトークン検証部６１２に依頼し、認可サーバ問い合わせリストに情報取得失敗項目を作成する（Ｓ１１０６）。情報取得失敗項目とは、JWSトークン情報取得のリトライ後、情報返却用トークンのうち正常に取得できなかったクレーム項目の値を空文字列にしたものである。なお、情報返却用トークン自体の取得に失敗した場合は、全クレーム項目の取得失敗とし、認可サーバ問い合わせリストの全クレーム項目の値を空文字列にする。情報取得失敗項目を作成すると、リソースサーバ２０２は認可サーバ２０１への問い合わせ処理を終了する。
本実施形態においては、リトライを１回行う例を示したが、リトライの回数は所定の回数行われるように設定してもよい。また、例えばリトライの回数を認可サーバ問い合わせリストにあるクレーム名に付加されたアノテーションに“@recm”が含まれる場合には５回、“@recm”のみである場合には３回にするなど、問い合わせの必要度に応じて設定するようにしてもよい。

図１６は、図１４のフローチャートで示した、Ｓ１０１４のクレーム確認処理の詳細を示すフローチャートである。図１５のフローチャートで詳細を示した、図１４のＳ１０１３のリソースサーバ２０２のJWSトークン認可サーバ問い合わせ処理が終了すると、JWSトークン検証部６１２は、Ｓ１０１４に進み、認可サーバ問い合わせリストのクレーム項目を確認する。

まず、JWSトークン検証部６１２は、認可サーバ問い合わせリストの存在を確認する（Ｓ１２０１）。そして、認可サーバ問い合わせリストが存在するかどうか、すなわち、リストが空かどうかを判定する（Ｓ１２０２）。該リストが空であれば、認可サーバ２０１へのJWSトークン情報取得がなされなかったと判定して処理を終える。

一方、該リストが空でなければ、以下ステップでJWSトークン情報取得の結果を確認する。まず、JWSトークン検証部６１２は、該リストの“Required”アノテーションの付いた確認必須のクレーム項目の値の取得成功を判定する（Ｓ１２０３）。該項目が空であれば、必須情報の情報取得に失敗したとみなして、JWSトークン検証部６１２は、処理中断のエラーを返却して（Ｓ１２０６）処理を終える。一方、“Required”アノテーションの付いたクレーム項目の値のチェックに成功したならば、Ｓ１２０４に進む。

次に、JWSトークン検証部６１２は、ステップ１２０３と同様に該リストの“Recommended”アノテーションの付いた確認推奨のクレーム項目の値の取得成功を判定する（Ｓ１２０４）。該項目が空であれば、推奨情報の情報取得に失敗したとみなして、JWSトークン検証部６１２は、取得推奨データのデータ取得失敗のエラーを返却して（Ｓ１２０７）処理を終える。一方、“Recommended”アノテーションの付いたクレームの値のチェックに成功したならば、Ｓ１２０５に進む。そして、JWSトークン検証部６１２は、全てのJWSトークンに含まれるクレームの値を取得したとしてデータ取得成功を返却して処理を終える（Ｓ１２０５）。

以上により、リソース要求API呼び出しを受けたリソースサーバ２０２による、JWSトークンの検証（Ｓ７０６）、リソースサーバ２０２のJWSトークン認可サーバ問い合わせ処理（Ｓ７０７）、検証処理（Ｓ７１０）が終了する。その後、リソースサーバ２０２のリソース管理部６１０は、検証処理が成功した場合は、クライアント２０３からのリソースサーバ２０２へのリソース要求API呼び出しに応じて処理結果（すなわち、要求リソース）を返して処理を終える（Ｓ７１１）。一方、検証処理が失敗したら、失敗を通知して処理を終える（Ｓ７１１）。

署名付きトークン（JWSトークン）に付与された情報には、リソースサーバがトークン有効期限内に必ず確認したい情報と、確認が推奨される情報が混在している。すなわち、“Required”アノテーション付与のクレームの値と、“Recommended”アノテーション付与のクレームの値が混在している。以上のように、本実施形態においては、JWSトークンに付加されたクレーム情報アノテーションに基づいて、認可サーバのポリシーに従いリソースサーバで適切に確認、認可サーバ問い合わせを行う。認可サーバのトークン検証、情報取得の負荷を低減し、リソースサーバのパフォーマンスを上げることができる。

（第２実施形態）
第１実施形態においては、リソースサーバ２０２による認可サーバ２０１に対する、検証要求（Ｓ７０７）において情報取得用トークンを用い、その応答（Ｓ７０９）において情報返却用トークンを用いた。本実施形態においては、該情報取得用トークンをGraphQL問い合わせに変更した例を説明する。GraphQLは、Facebook社により開発され、現在RFCにドラフト案が公開されている、クライアント・サーバアプリケーション向けのデータモデリング記述のためのクエリ言語である。本実施形態においては、上記リソースサーバ２０２の認可サーバ２０１への検証要求およびその応答に、GraphQLを用いる。GraphQLは、統一されたAPI（Endpoints）、型をもつため、REST APIのバージョン管理、エンドポイント管理、クライアント側で取得したデータの管理など、一般に複雑で面倒な部分が解決できる。また、第１実施形態の情報取得用認可トークンと比べて、必要な情報のみ問い合わせることが可能なため、リソースサーバ２０２と認可サーバ２０１でやり取りされるクレーム要求、応答のデータ量を削減することも可能となる。

図１７は、本実施形態における認証・認可システムの署名付き認可トークン発行と検証に関するシーケンス図である。図１３において、Ｓ１３０１〜Ｓ１３０６は、図６におけるＳ７０１〜Ｓ７０６と同様である。また、Ｓ１３１０およびＳ１３１１は、図６におけるＳ７１０およびＳ７１１と同様である。以下では、第１実施形態との差異であるＳ１３０７〜Ｓ１３０９について説明する。なお、問い合わせクレームの判定については、第１実施形態の基準に従う。

Ｓ１３０７において、リソースサーバ２０２のJWSトークン管理部６１１は、情報取得用QraphQLを含む検証要求をREST API呼び出しとして認可サーバ２０１に送信し、クレームの値の問い合わせを行う。
図１８（Ａ）は、リソースサーバ２０２が認可サーバ２０１に送信する検証要求の一例を示す図である。検証要求は、具体的には、HTTPのPOSTメソッドで、認可サーバ２０１のGraphQLを受信するエンドポイントである/api/graphqlに対し、Content-TypeとしてGraphQLを示す“applicatioon/graphql”を指定し、Authorizationヘッダーとして、“Bearer” + 表９の“jti”で示される認可トークンIDをBase64 URL符号化した文字列を示す。またリクエストボディは、認可サーバ２０１の表６トークン管理テーブルで管理されているトークンID“b2652f6d75b14aa49adfe89b8808b337ef276e8d1363400d98fab100c7463df0”に紐付く電子メールアドレス（“email”）とテナントID（“tenantid”）を検索、取得することを示すGraphQL言語である。上記トークンIDは、Ｓ１３０５で取得したJWSトークンの“jti”クレームに含まれる認可トークンのIDである。

また、本実施形態の認可サーバ２０１とリソースサーバ２０２が同じセキュリティドメインに属しているならば、図１８（Ｂ）に示すようなクエリーパラメーターを用いても良い。図１８（Ｂ）は、同じセキュリティドメインに属しているリソースサーバ２０２から認可サーバ２０１に送信される検証要求のクエリーパラメーターの一例を示す図である。

リソースサーバ２０２からの検証要求により、検証および情報取得を依頼された認可サーバ２０１のJWSトークン管理部６０５は、要求の検証と要求に基づいた情報取得を行う（Ｓ１３０８）。具体的には、まず、取得した検証要求のトークンIDを参照する。JWSトークン管理部６０５は、トークンIDの値である“b2652f6d75b14aa49adfe89b8808b337ef276e8d1363400d98fab100c7463df0” が表６トークン管理テーブルに存在することを確認する。さらに、JWSトークン管理部６０５は、トークンIDに基づいて、表８のトークン属性管理テーブルから前記GraphQLの“email”, “tokenid”を取得する。すなわち本実施形態においては、前記認可トークンID検証の後、“email”として表８の“john.doe@example.com”を、“tenant”として“170BA”を取得する。
本実施形態においては前記クレーム値にトークン発行時と変更はないが、万一JWSトークン発行時から変更があった場合にも、本JWSトークン情報取得により変更後のクレーム値を取得することができる。

認可サーバ２０１のJWSトークン管理部６０５は、取得した値（すなわち、“email”として“john.doe@example.com”、 “tenantid”として“170BA”）を、リソースサーバ２０２に返却する（Ｓ１３０９）。図１８（Ｃ）は、Ｓ１３０９において認可サーバ２０１からリソースサーバ２０２へ返却されるQraphQL返却の一例を示す図である。

以上により、リソース要求API呼び出しを受けたリソースサーバ２０２による、JWSトークンの検証（Ｓ１３０６）、リソースサーバ２０２のJWSトークン認可サーバ問い合わせ処理（Ｓ１３０７）、検証処理（Ｓ１３１０）が終了する。JWSトークン発行時からトークン値に変更があった場合にも、以上の処理により変更後のクレーム値を取得することができる。その後、リソースサーバ２０２のリソース管理部６１０は、クライアント２０３からのリソースサーバ２０２へのリソース要求API呼び出しに応じて処理結果（すなわち、要求リソース）を返却し（Ｓ１３１１）、処理を終える。

以上説明したように、本実施形態において、リソースサーバ２０２から認可サーバ２０１への検証要求およびその応答にGraphQLを用いる。GraphQLの統一されたAPI（Endpoints）、型により、REST APIのバージョン管理、エンドポイント管理、クライアント側で取得したデータの管理など、一般に複雑で面倒な部分が解決できる。また、第１実施形態の情報取得用認可トークンと比べて、必要な情報のみ問い合わせることが可能なため、リソースサーバ２０２と認可サーバ２０１でやり取りされるデータ量を削減することも可能となる。

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

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

Claims (18)

1. ネットワークを介してサービスを提供するサービス提供装置と、認可サーバとを含むシステムであって、
   前記認可サーバは、
   付加情報が付加された、署名付きの認可情報を発行する発行手段を有し、
   前記サービス提供装置は、
   前記署名付きの認可情報の前記署名を検証する署名検証手段と、
   前記署名付きの認可情報に含まれる各項目が前記認可サーバに問い合わせるべき項目であるかを示す前記付加情報に基づいて、前記認可サーバに問い合わせが必要な項目の検証要求を行う検証要求手段と、
   を有することを特徴とするシステム。
2. 前記検証要求手段は、前記付加情報に基づいて前記認可サーバに問い合わせるべき項目のリストを作成し、前記リストに基づいて前記検証要求を行うことを特徴とする請求項１に記載のシステム。
3. 前記検証要求手段は、前記付加情報が付加された項目がクライアントから要求されたサービスで利用する情報であるか否か判定し、前記サービスで利用する情報であると判定された場合に、前記リストに該項目を追加することを特徴とする請求項２に記載のシステム。
4. 前記付加情報は、各項目が前記認可サーバへの問い合わせが必須あるいは推奨であるかを示すアノテーションであることを特徴とする請求項１乃至請求項３のうちいずれか１項に記載のシステム。
5. 前記付加情報は、前記認可情報に含まれる各項目の項目名に付加されることを特徴とする請求項１乃至請求項４のうちいずれか１項に記載のシステム。
6. 前記認可サーバは、さらに、前記サービス提供装置からの前記検証要求に基づいて検証を行う検証手段を有し、
   前記サービス提供装置は、さらに、前記認可情報に基づいてサービスの提供を行う提供手段を有し、
   前記提供手段は、前記検証要求手段が前記検証要求を行った場合は、前記検証手段の検証結果に基づいて、前記サービスの提供を行うことを特徴とする請求項１乃至請求項５のうちいずれか１項に記載のシステム。
7. 前記付加情報に基づいて前記認可サーバに問い合わせるべき項目がない場合は、前記検証要求手段は、前記認可サーバへの前記検証要求は行わず、前記提供手段は、前記署名付きの認可情報に基づいて、前記サービスの提供を行うことを特徴とする請求項６に記載のシステム。
8. 前記検証要求手段は、前記認可サーバの前記検証手段による検証結果の取得に失敗した場合、前記検証要求のリトライを行うことを特徴とする請求項６または請求項７に記載のシステム。
9. 前記検証要求手段による前記リトライを所定の回数行い、前記検証結果の取得に失敗した場合、前記提供手段は、クライアントにエラーを返却することを特徴とする請求項８に記載のシステム。
10. 前記提供手段は、前記検証結果の取得に失敗した項目が、前記認可サーバへの問い合わせが必須の項目である場合、処理を中断してエラーを返却することを特徴とする請求項９に記載のシステム。
11. 前記検証要求手段は、前記検証要求として、前記認可サーバに問い合わせるべき項目の値を空にした署名付きの認可情報を前記認可サーバに送信することを特徴とする請求項１乃至１０のうちいずれか１項に記載のシステム。
12. 前記検証要求手段は、GraphQLを用いて前記検証要求を行うことを特徴とする請求項１乃至１０のうちいずれか１項に記載のシステム。
13. 前記発行手段は、秘密鍵により暗号化して前記署名を行い、
    前記署名検証手段は、前記秘密鍵に対応する公開鍵により前記署名付きの認可情報を復号化して前記署名を検証することを特徴とする請求項１乃至請求項１２のうちいずれか１項に記載のシステム。
14. 前記署名付きの認可情報には、トークン情報およびトークンに紐付くユーザ情報が含まれていることを特徴とする請求項１乃至請求項１３のうちいずれか１項に記載のシステム。
15. 前記発行手段は、JSON Web Tokenの仕様に従って表現された認可情報を、JSON Web Signatureの仕様に従ってデジタル署名したトークンを前記署名付きの認可トークンとして発行することを特徴とする請求項１乃至請求項１４のうちいずれか１項に記載のシステム。
16. 認可サーバが発行した、付加情報が付加された署名付きの認可情報を用いて認証を行い、ネットワークを介してサービスを提供するサービス提供装置であって、
    前記署名付きの認可情報の前記署名を検証する署名検証手段と、
    前記署名付きの認可情報に含まれる各項目が前記認可サーバに問い合わせるべき項目であるかを示す前記付加情報に基づいて、前記認可サーバに問い合わせが必要な項目の検証要求を行う検証要求手段と、
    を有することを特徴とするサービス提供装置。
17. ネットワークを介してサービスを提供するサービス提供装置と、認可サーバとを含むシステムの制御方法であって、
    前記認可サーバにおいて、付加情報が付加された、署名付きの認可情報を発行する工程と、
    前記サービス提供装置において、前記署名付きの認可情報の前記署名を検証する工程と、
    前記サービス提供装置において、前記署名付きの認可情報に含まれる各項目が前記認可サーバに問い合わせるべき項目であるかを示す前記付加情報に基づいて、前記認可サーバに問い合わせが必要な項目の検証要求を行う工程と、
    を有することを特徴とする制御方法。
18. 請求項１６に記載のサービス提供装置の各手段としてコンピュータを機能させることを特徴とするプログラム。

Images