JP2018092446A

JP2018092446A - 認証認可システム及び情報処理装置と認証認可方法とプログラム

Info

Publication number: JP2018092446A
Application number: JP2016236245A
Authority: JP
Inventors: 三原　誠; Makoto Mihara; 誠三原
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-12-05
Filing date: 2016-12-05
Publication date: 2018-06-14

Abstract

【課題】JWSアクセストークンを発行する認証認可サービスにおいて、トークンに含まれた付帯情報によって不要な情報が外部に流出してしまう。【解決手段】JWSアクセストークンに含まれる付帯情報を暗号化したり、あるいは付帯させないことで、適切な情報開示範囲を守りつつ、１つのJWSアクセストークンで異なるセキュリティドメインのリソースサーバーの利用が可能となる。【選択図】図6

Description

本発明は、例えば署名付きアクセストークン等を用いた認証認可システム及び情報処理装置と認証認可方法とプログラムに関する。

近年、インターネット上に展開された所謂クラウドサービスの利用が拡大している。また、これらクラウドサービスは個々にWebサービスのAPI（Application Programming Interface）を公開しており、他のアプリケーションやクラウドサービスからAPIを介してサービスが提供する機能を利用する事が可能となっている。これらWebサービスAPIではOAuth 2.0と呼ばれる、認可の連携を実現させるための標準プロトコルの採用が進んでいる。非特許文献1にはOAuth 2.0を利用した技術が開示されている。

OAuth 2.0によれば、例えばあるサービスAが管理するユーザーのデータを取得するAPIに対して、そのユーザーから認められた範囲にてサービスBがアクセスすることができる。このときサービスAは、サービスBからアクセスされる範囲を明らかにした上で、サービスBによるAPIへのアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを認可操作と称する。また、このアクセスされる範囲をOAuth 2.0ではスコープと呼称し、スコープによりデータへのアクセス許容量が決定される。

ユーザーが認可操作を行うと、サービスBは、サービスAにおけるユーザーが許可した範囲のデータへのアクセスが認められたことを証明するトークン (以下、認可トークンと称する) を受け取り、以降のサービスAのAPIへのアクセスはその認可トークンを用いて実現できる。このユーザーの認可操作によりサービスBがユーザーのリソースに対しアクセスすることを認可したことを権限委譲と称する。なお、OAuth 2.0では、ユーザーの認可操作を元に認可トークンを発行するサーバーを認可サーバーと呼称する。また、APIを公開するサーバーをリソースサーバー、APIをコールする主体をクライアントと呼称する。 OAuth 2.0では、認可サーバーとリソースサーバーは同一サーバーで構成する事も可能としているが、リソースサーバーが複数種存在する様な大規模なシステムでは、通常認可サーバーを独立したサーバーとして構成する。その場合、上記フローにおいて、サービスAはサービスBからのAPI利用のたびに、取得したアクセストークンの検証を認可サーバーに依頼する。そして、その検証結果を元にAPIの利用の可否を決定する。その場合、大規模システムでは、認可サーバーに負荷が集中してしまうという課題が発生する。そこでサービスAが認可サーバーに検証依頼することなく、自身でアクセストークンを検証する手段として、署名付きアクセストークンの利用が検討されている。署名付きアクセストークンとしては、非特許文献2、3のJWT（JSON Web Token）、JWS（JSON Web Signature）が知られている。サービスAは受信した署名付きアクセストークンの署名を検証する事で、認可サーバーに確認することなく、アクセストークンが有効であるかを判断する事ができる。

また、署名検証用の手段が一般に公開され、自由に認可サーバーと連携するリソースサービスを構築することも可能となってきている。これにより、ある認可サーバーが発行した一つの署名付きアクセストークンを使って異なるセキュリティドメインに所属するリソースサーバーを利用するクライアントを作成することが可能となってきた。

"The OAuth 2.0 Authorization Framework"、[online] D. Hardt、2012年8月＜URL http://tools.ietf.org/html/rfc6749＞ "JSON Web Token (JWT) "、[online] M. Jones, J. Bradley, N. Sakimura、2015年5月＜URL https://tools.ietf.org/html/rfc7519＞ "JSON Web Signature (JWS)"、[online] M. Jones, J. Bradley, N.Sakimura、2015年5月＜https://tools.ietf.org/html/rfc7515＞

特開２００７−２２６４７０号公報

特許文献1に記されているように、セキュリティドメインが異なる別の認証サーバーで管理されるリソースサーバーにアクセスする場合、ユーザー情報を匿名化してアクセスする等、別のセキュリティドメインに情報が漏えいしないように防止する対策が必要である。

ところで、署名付きアクセストークンではトークンに紐付く付帯情報（ユーザーの姓名、メールアドレスなど）を付与する。その結果、リソースサーバーはクライアントから受け取った署名付きアクセストークンから付帯情報を取得することが可能となり、認証認可サーバーへ改めてトークンの付帯情報を問い合わせる必要が無くなる。ただし、前述のように他のセキュリティドメインのリソースサーバーに対して付帯情報を持つ署名付きアクセストークンを送信すると、認証認可サーバーの情報が別のドメインのリソースサーバーに流出してしまうという問題があった。そのため、一つの署名付きアクセストークンで複数のセキュリティドメインのリソースサーバーを利用する場合、付帯情報を最低限にする等の対策が必要であった。この対策を実施すると、同一のセキュリティドメインのリソースサーバーは認証認可サーバーよりトークンの付帯情報を取得する必要があるため、認証認可サーバーへのアクセスが結果減らなくなるという課題があった。

本発明は上記課題を解決するために成されたもので、外部のリソースサーバーへの情報流出を防止しつつ適切なリソースサーバーに対してのみ付帯情報を提供可能とすることを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

リソースへのアクセス権を持つユーザーを認証する認証認可サーバーと、サービスを提供するリソースサーバーと、該リソースサーバーにより提供されるサービスを利用可能なクライアント端末とを有する認証認可システムであって、
前記認証認可サーバーは、所定の付帯情報を暗号化し、暗号化された前記付帯情報を含むデジタル署名されたアクセストークンを発行するトークン発行手段を有し、
前記リソースサーバーは、前記認証認可サーバーより提供された検証用情報を用いて前記アクセストークンを検証するトークン検証手段と、
前記認証認可サーバーより提供された復号用情報を基に、前記アクセストークンに含まれる暗号化された前記付帯情報を復号する復号手段と
を有する。

本発明によれば、外部のリソースサーバーへの情報流出を防止しつつ適切なリソースサーバーに対してのみ付帯情報を提供可能とするこれにより、認証認可サーバーが各リソースサーバーからの問い合わせを削減しつつ、一つの署名付きアクセストークンで複数のセキュリティドメインのリソースサーバーを利用することが可能となる。

システム構成図各装置のハードウェア構成図各装置のソフトウェアモジュール構成図従来技術でのアクセストークン発行と検証のシーケンス図 JWSアクセストークン発行と検証のシーケンス図 JWSアクセストークン発行のフロー図 JWSアクセストークン検証のフロー図アプリケーションを識別したJWSアクセストークン発行のシーケンス図 JWSアクセストークン発行のフロー図

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

本実施例においては、インターネット上の各サーバーにアプリケーションが設置されていることとする。アプリケーションはクライアント端末と連携し、様々な機能を提供することとする。このような機能を提供する実体をサービスと称し、機能をクライアント端末に提供することをサービスの提供と称する。

＜認証認可システムの構成＞
本実施の形態に係る情報処理システムである認証・認可システムは、図1に示すような構成のネットワーク上に実現される。Wide Area Network（広域ネットワーク：WAN）100は、複数のLANを接続してWorld Wide Web（WWW）システムが構築されている。LAN101、102、103は各構成要素を接続するLocal Area Network（ローカルエリアネットワーク：LAN）である。認証認可サーバー110、111はユーザー・クライアント端末の認証および、OAuthを実現する。リソースサーバー120は、様々なサービスを提供する。また、実施例において各サーバーは1台ずつ設置されているが複数台で構成されていても良く、例えば、認証認可サーバーシステムとして提供されても良い。クライアント端末140は、パソコン、モバイル端末、画像形成装置などである。クライアント端末140には、1つまたは複数のリソースサービス連携アプリケーションがインストールされており、リソースサービスとのデータ送受信を行う。認証認可サーバー111とリソースサーバー121は認証認可サーバー110とリソースサーバー120と同様であるが、別のセキュリティドメインのシステムであり、認証認可サーバー111より発行されたトークンでリソースサーバー121を利用する。また、本実施例においては、認証認可サーバー110が発行したトークンでリソースサーバー121が利用可能である。詳細は後述する。

＜サーバー及びクライアントのハードウェア＞
図2は本実施例に係る、認証認可サーバー110、111、リソースサーバー120、121、クライアント端末140を構成する情報処理装置の一般的なハードウェア構成である。CPU231は、ROM233のプログラム用ROMに記憶された、或いはハードディスク（HD）等の外部メモリ241からRAM232にロードされたOSやアプリケーション等のプログラムを実行する。またCPU231は、システムバス234に接続される各ブロックを制御する。ここでOSとはコンピューター上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをOSと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。RAM232は、CPU231の主メモリ、ワークエリア等として機能する。操作部I/F235は、操作部239からの入力を制御する。CRTコントローラ（CRTC）236は、CRTディスプレイ240の表示を制御する。ディスクコントローラ（DKC）237は各種データを記憶するハードディスク（HD）等の外部メモリ241におけるデータアクセスを制御する。ネットワークコントローラ（NC）238はWAN100もしくはLAN101、102、103を介して接続されたサーバーコンピューターや他の機器との通信制御処理を実行する。
尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はCPU231であり、ソフトウェア上の主体は外部メモリ241にインストールされたアプリケーションプログラムである。

＜サーバー及びクライアントのソフトウェアモジュール＞
図3は本実施の形態に係る、認証認可サーバー110、111、リソースサーバー120、121、クライアント端末140、それぞれのモジュール構成を示す図である。各々のモジュールが実行されることで、各々の機能を実現する。認証認可サーバー110、111は認証認可モジュール310を持つ。認証認可モジュール310では、例えばリソースへのアクセス権を持つユーザーやクライアント端末の認証処理、認証されたユーザーやクライアント端末の認可処理、署名（デジタル署名とも呼ぶ）付きアクセストークンの発行処理を行う。デジタル署名はたとえば、メッセージのハッシュ値を、署名鍵（署名用情報とも呼ぶ）を用いて符号化した情報であり、検証鍵（検証用情報とも呼ぶ）によって復号したハッシュ値をメッセージのハッシュ値と比較することなどで検証される。

リソースサーバー120、121はリソースサーバーモジュール320を持つ。リソースサーバーモジュール320は、WebサービスとしてAPIを公開し、クライアント端末140からのサービス提供の要求を受け付けサービスの提供を行う。また、クライアント端末140からの要求に対して、署名付きアクセストークンの検証処理を行うことでサービス提供の可否を決定する。

クライアント端末140は認証認可サーバー連携クライアント341、リソースサービス連携アプリケーション342を持つ。また、WWWを利用するためのユーザーエージェントであるWebブラウザ343を持つ場合があるが必須ではない。認証認可サーバー連携クライアント341は認証認可サーバー110に対して、ユーザーやクライアントの認証の要求、アクセストークンの発行依頼や取得を行う。リソースサービス連携アプリケーション342は、リソースサーバー120、121よりサービス提供を受けるアプリケーションである。リソースサービス連携アプリケーション342は以下の手順でリソースサーバー120、121よりサービス提供を受ける。まず、認証認可サーバー連携クライアント341に対してアクセストークンの発行を依頼する。ここで、認証認可サーバー連携クライアント341はリソースサービス連携アプリケーション342用のアクセストークンを認証認可サーバー110より取得する。認証認可サーバー連携クライアント341は取得したアクセストークンを要求元のリソースサービス連携アプリケーション342に返却する。リソースサービス連携アプリケーション342は取得したアクセストークンを利用して、リソースサーバー120、121へリソース要求を行うことでサービスの提供を受けることができる。

＜従来の認証および検証手順＞
図4にてOAuth 2.0を基にした従来技術でのアクセストークン発行と検証の流れについて説明する。図4は従来技術におけるアクセストークン発行と検証に関するシーケンス図である。認証認可サーバー110、リソースサーバー120、クライアント端末140間で連携している。まず、クライアント端末140は、ステップS401にて認証認可サーバー110に対して認証情報あるいは認可コードを渡しアクセストークンを要求し、取得する。認証情報か認可コードかは、オーナーの違いによって異なる。クライアント端末140が処理を実施するオーナーである場合はクライアント端末140自体が認証を行い、クライアント端末140が他のオーナーから処理を依頼される場合にはオーナーから受け取った認可コードを渡すことになる。次に、クライアント端末140は取得したアクセストークンを使って、ステップS402にてリソースサーバー120に対してサービスの提供を要求する。リソースサーバー120は受け取ったアクセストークンが適正かどうかをステップS403にて認証認可サーバー110に検証するよう要求する。認証認可サーバー110はステップS404にてアクセストークンの検証を行い、適正であればリソースサーバー120はステップS405にてサービスを提供するための処理を実行し、処理結果をクライアント端末140に返す。
なお、ステップS404の検証でアクセストークンが不適正であった場合は、リソースサーバー120は処理を行わず、エラーをクライアント端末140に返す。

＜署名付きアクセストークン＞
引き続き本実施例における署名付きアクセストークンの説明を行う。本実施例では、通常のアクセストークンの代わりにアクセストークン情報およびリソースオーナー情報であるアクセストークンに紐付くユーザー情報を格納するJWS（以降JWSアクセストークンとする）を用いる。

以下本実施例で用いるJWSアクセストークンについて詳述する。JWS（JSON Web Signature：JSONウェブ署名）は、JWT（JSON Web Token：JSONウェブトークン）で表現されたコンテンツをデジタル署名やMACs（Message Authentication Codes：メッセージ認証コード）により保護して表現する手段である。またJWTは、JSON（JavaScript（登録商標） Object Notation）をベースとしたデータ構造を用いたURLセーフなクレームの表現方法である。JWS、JWTについては、各々RFC（RFC7515（JWS）、RFC7519（JWT））として仕様化、公開されている。

本実施例で使用するJWSアクセストークンに含まれるクレームは、表１のとおりである。クレームはトークンに関連付けられた付帯情報ということもできる。

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

本実施例においては、JWSアクセストークンを発行する認証認可サーバー110が以下のように値を設定する。"iss"として認証認可サーバー110のURI、"sub"としてユーザーのUUID（Universally Unique Identifier）、"aud"としてリソースサーバー120のURIを設定する。また、"exp"として本JWT発行時から3600秒、すなわち"iat"の値+3600、"nbf"として本JWT発行時、"すなわち"iat"と同じ値を設定する。また、"jti"として認可トークン情報の認可トークンIDを設定する。

さらには、表１のクレーム名クラス"Private Claim"の各クレームは、JWTのRFC7519によると、JWT発行者と利用者の合意の下で使用するプライベートクレーム名クラスである。他に定義されたクレーム名と衝突のないことを前提とする。本実施例では、"Private Claim"クラスのクレーム名に認可トークン情報（認可トークンスコープリスト "authz:scopes", 認可トークンクライアントID "authz:client_id" ）と、認可トークンに紐付く属性情報（ファーストネーム"ext:fname", ラストネーム "ext:lname", テナントID "ext:tenantid", 電子メールアドレス "ext:email", デバイスシリアル "ext:device-serial", アプリケーションID "ext:appid" ）を持つことを特徴とする。

具体的に本実施例においては、JWSアクセストークンを発行する認証認可サーバー110が、認可情報として"authz:scopes"、 "authz:client_id" のクレームを設定する。すなわち、"authz:scopes"としてリソースサーバー120が取得を許可するリソースを表すスコープリストを設定する。さらに、"authz:client_id"としてリソースサーバー120にアクセスするクライアントのIDを表す"authz:client_id"を設定する。また、JWSアクセストークンを発行する認証認可サーバー120が、"authz:tokened"のトークンに紐付く属性情報として、"sub"に設定したUUIDのユーザーの情報を表すクレームを以下のように設定する。すなわち、"ext:fname"としてのファーストネーム、"ext:lname"としてラストネーム、"ext:tenantid" として所属するテナントID、"ext:email"として電子メールアドレスを設定する。さらには、"ext:dev-serial"としてクライアント端末140を識別するデバイスシリアル番号、"ext: appid"としてリソースサービス連携アプリケーション342を識別するためのアプリケーションIDを設定する。詳細は後述する。

本実施例の上記表１で示されたような内容のJWSアクセストークンを発行する認証認可サーバー110は、上記表１のクレームをJWTの仕様であるRFC7519によりJSONとしてエンコードする。また、JWSの仕様であるRFC7515のコンパクトシリアライゼーション仕様に従ってデジタル署名されたコンテンツ（表１のクレームのJSON表現、すなわちJWSペイロード）をコンパクトなURL-safe文字列として表現符号化する。本実施例のJWSアクセストークンは、JWSコンパクトシリアライゼーション仕様に従い、エンコード済JWSヘッダー、エンコード済JWSペイロード、およびエンコード済JWS署名を、この順序でピリオド('.')文字を区切り文字として連結した文字列である。

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

なお本実施例においてJWSの署名に使われる暗号アルゴリズム"RS256"で使用する秘密鍵、公開鍵の鍵ペアは、認証認可サーバー110が予め生成しておいたものを使用する。またJWSの署名を検証する公開鍵はJWSアクセストークンを使用するリソースサーバー120、121に予め配備しておく。リソースサーバー121は認証サーバー110と異なるセキュリティドメインに属するが、JWSアクセストークンを検証する公開鍵を保持する。このため、認証認可サーバー110が発行したJWSアクセストークンでリソースサーバー121が利用可能となる。

＜認証認可サーバーの各種テーブル＞
図5、図6、図7および、表2から表8にて本実施例にかかわるJWSアクセストークン発行と検証の流れについて説明する。表2から表7は、本実施例における認証認可サーバー110の認証認可モジュール310が管理するテーブルであり、ユーザー管理テーブル（表2）、ユーザー属性管理テーブル（表3）、クライアント属性管理テーブル(表4)、サービス管理テーブル(表5) 、トークン管理テーブル(表6)、属性情報格納方式管理テーブル(表7)である。

表2のユーザー管理テーブルは、ユーザーとクライアントを一意に管理するユーザーID（クライアントID）項目、ユーザーID（クライアントID）の内部表現であるUUID項目、前記ユーザーIDに対応するパスワードを示すPassword項目、ユーザー種別を示すUser Type項目から成る。認証認可サーバー110は、ユーザーID（クライアントID）、Passwordの情報の組を検証し、正しければ認証情報を生成することで、各ユーザーもしくはクライアントを認証する機能（不図示）を備える。

表3のユーザー属性管理テーブルは、UUID項目、前記UUIDのユーザーの姓を示すFirst Name項目、名を示すLast Name項目、所属するテナントを示すTenant ID項目、電子メールアドレスを示すEmail項目、使用できるサービスを示すService ID項目から成る。

表4のクライアント属性管理テーブルは、UUID項目、クライアントがどのデバイスに発行されたかを示すデバイスシリアル番号項目、OAuth2（RFC6749）プロトコル等で使用する、同クライアントのリダイレクトURLを示すRedirect URL項目、同クライアントの使用できるサービスを示すService ID項目から成る。

表5のサービス管理テーブルは、リソースサーバー120で提供するリソースに関するサービスを示すService ID項目、前記Service IDに相当するサービスをリソースとして表し、OAuth 2.0プロトコルなどの認可要求のスコープに指定される内容であるScope項目、前記Service IDに相当するサービス（リソース）を提供するリソースサーバーのURLを示すURL項目から成る。

表6のトークン管理テーブルは、トークンIDを示すToken ID項目、アクセストークン、認可コードなど、前記トークンIDのトークンタイプを示すToken Type項目、前記トークンIDの有効期限を秒で示すExpiration Time項目、OAuthプロトコルなどの認可要求のスコープに指定される内容であるScope項目、OAuthプロトコルなどで使用する、前記トークンIDのGrant Typeを示すGrant Type項目、前記トークンIDのリフレッシュトークンのIDを示すRefresh Token ID項目、前記リフレッシュトークンIDの有効期限を秒で示すRefresh Token Expiration Time項目、前記トークンIDの発行要求元のクライアントを示すClient UUID項目、前記トークンIDに紐付くオーナーを示すOwner UUID項目、前記トークンIDを用いるリソースサービス連携アプリケーション342を示すApplication IDから成る。なお表６ではトークン管理テーブルを二つに分割して示した。Application IDはリソースサービス連携アプリケーション342毎に決定される。認証認可サーバー連携クライアント341がリソースサービス連携アプリケーション342からのトークンの発行要求を行う際に自動的に取得され、認証認可サーバー110の認証認可モジュール310に通知される。

表7の属性情報格納方式管理テーブルは、JWSアクセストークンに紐付く属性情報への値の格納方法を管理する。対象となるクレーム名とそのクレームへの値の暗号化方式を指定する情報とから成る。平文のまま格納する属性情報（すなわち付帯情報）については平文であることを示す情報が格納される。表７は、暗号化対象となる所定の付帯情報を示すと共に、暗号化方法（たとえば暗号化プログラムや暗号化鍵など）を付帯情報に関連づけて示す情報とも言える。

＜JWSアクセストークンの発行および検証シーケンス＞
図5は本実施例でのOAuth 2.0に基づくJWSアクセストークン発行と検証に関するシーケンス図である。認証認可サーバー110、リソースサーバー120、121、クライアント端末140間で連携している。
まず、クライアント端末140の認証認可サーバー連携クライアント341は、ステップS501にてJWSアクセストークンの発行要求をし、取得する。本要求は、認証認可サーバー110の認証認可モジュール310に対してOAuth 2.0の認可コードグラントやクライアントクレデンシャルグラントなどに基づき、認証情報あるいは認可コードを渡して行われる。認証認可サーバー110の認証認可モジュール310はステップS502にてトークン発行処理を行う。具体的には図6にて説明する。このように本実施例では、アクセストークンの検証をリソースサーバーが行うことができる。

＜トークン発行処理＞
図6は認証認可モジュール310がステップS502にて行うトークン発行処理のフローを表す図である。

ステップS601にて、アクセス元のクライアントやオーナーの認証・認可を行う。認証・認可が失敗したらステップS603で要求元にエラーレスポンスを返す。認証・認可に成功したら、ステップS602にて、JWSサクセストークンを生成する。この際、認証認可サーバー110の認証認可モジュール310はJWSアクセストークンに設定する表1のクレームの値に関して、認証認可サーバー110の認証認可モジュール310で管理する表2から表7のデータに基づき生成する。

JWSヘッダーとして、"alg": "RS256", "typ": "JWT"を設定する。さらにJWSペイロードとして以下をそれぞれ設定する。JWT の発行者の識別子"iss" (Issuer)として本認証認可サーバー110のURI "https://auth.example.com"。JWT の主語となる主体の識別子"sub" (Subject)として前記JWSアクセストークン発行要求に含まれる認可コードに対応するリソースオーナーのIDである表2のUUID "1ce42f74"。JWT を利用することが想定された主体の識別子一覧"aud" (Audience)としてScopeに相当するリソースサーバーのURLとして表5のURL項目の"https://print.srv.example.com"。JWT の有効期限"exp" (Expiration Time)として本JWT発行時から3600秒、すなわち本実施例の場合"iat"の値+3600である"1472713413"。"nbf"として本JWT発行時、すなわち"iat"と同じ値"1472709813"。JWSペイロードとして上記の値を設定する。また本実施例においては、本JWSアクセストークンの発行時に表6のトークン管理テーブルに示すように発行し、"jti"として該JWSトークンのトークンID "b2652"を、認可トークンスコープリスト "authz:scopes"に"owner.PrintService"を、認可トークンクライアントID"authz:client_id"に"" 241332ca"をそれぞれ設定する。

さらには、認可トークンに紐付く属性情報を表7の設定に従ってそれぞれの値を格納する。"ext:fname"、 "ext:lname"、 "ext:email"属性には表3のユーザー属性管理テーブルよりFirst Name項目、Last Name項目、Email項目の値を格納する。本例では、それぞれ"Jhon","Doe"," john.doe@example.com"の値を"暗号化1"の方法で暗号化してから格納する。同様に"ext:tenantid"属性には表3のユーザー属性管理テーブルよりテナントID項目の" 170BA"の値を"暗号化2"の方法で暗号化してから格納する。なお、それぞれの暗号化の方法に関しては特に制限はなく、復号するための手段を任意のリソースサーバーにそれぞれ提供可能であれば良い。"ext:dev-serial"属性には、表4のクライアント属性管理テーブルよりデバイスシリアル番号項目の" 12345678"を平文で格納する。"ext:appid"属性には、トークン発行要求元である、リソースサービス連携アプリケーション342の識別子である"print"を平文で格納する。

＜トークン検証処理＞次にクライアント端末140は取得したJWSアクセストークンを使って、ステップS503にてリソースサーバー120のリソースサーバーモジュール320に対してサービスの提供を要求する。リソースサーバー120のリソースサーバーモジュール320は受け取ったJWSアクセストークンが適正かどうかをステップS504にて検証し、ステップS505にてJWSアクセストークンに含まれるトークンに紐づく属性情報を取得する。具体的には図7にて説明する。図7はリソースサーバーモジュール320がステップS504にて行うトークン検証処理とS505にて行うトークンに紐づく属性情報取得処理のフローを表す図である。なお、本フローを実行するに当たり、リソースサーバー120のリソースサーバーモジュール320は、認証認可サーバー110の署名を認証する証明書と、表8で示すJWSアクセストークン属性取得管理テーブルにて、属性の取得方法を有している。

表8のJWSアクセストークン属性取得管理テーブルは、JWSアクセストークンに紐付く属性情報の値の取得方法を管理する。対象となるクレーム名とそのクレームから値を取得する方法から成る。本実施例では、リソースサーバー120は認証認可サーバー110より、暗号化1の方式の値を復号する手段の提供を受けているので、"exe:fname""、"ext:lname"、"ext:email"に関しては復号手段1が保存されている。"ext:tenantId"に関しては復号できないので取得できない。"ext:dev-serial"、"ext:appid"に関しては平文のまま取得できる。なお復号手段とは、たとえば復号鍵や復号処理のためのプログラムなどを示すなどの復号用情報でよい。

図7のステップS701にて、リソースサーバーモジュール320はJWSアクセストークンの署名を確認することで適正な認証認可サーバー110で発行されたJWSアクセストークンであることを確認する。署名検証が失敗したらステップS707にて、要求元にエラーレスポンスを返す。JWSアクセストークンが適正であれば、すなわち検証が成功した場合には、ステップS702〜S706の処理ループにて、JWSアクセストークンに含まれるトークンに紐づく属性情報をそれぞれ取得する。検証が成功したアクセストークンは有効なアクセストークンということもできる。ステップS703では表8の情報より、対象となる属性情報の取得方法を取得する。"ext:dev-serial"、"ext:appid"のように取得方法が平文の場合はステップS704にてそのまま値を読み取る。"exe:fname""、"ext:lname"、"ext:email"のように取得方法が復号手段1の場合にはステップS705にて値を復号してから読み取る。"ext:tenantId"のように取得方法がない場合には、ステップS706にて値の取得を行わない。ステップS702はトークンの属性情報それぞれについて実行され、ステップS703で判別された取得方法に応じてステップS704〜S706の何れかが選択的に実行される。

認証認可サーバー110はリソースサーバー120、121に対してどの暗号化方法を復号する手段を提供するかを決定することで、各リソースサーバーがJWSアクセストークンのどの属性を利用できるかの制御が可能となる。

図7の一連の処理が完了したら、リソースサーバー120のリソースサーバーモジュール330は、ステップS506にてサービスを提供するための処理を実行し、処理結果をクライアント端末140に返す。

図５の手順では、図4のステップS403で示したようにリソースサーバー120は認証認可サーバー110へアクセストークンの検証を依頼すること必要がなくなる。そのため、アクセストークンの検証処理が各リソースサーバーに負荷分散され、認証認可サーバー110の負荷が下がることとなる。

さらに、リソースサーバー121のリソースサーバーモジュール330に認証認可サーバー110の署名を認証する証明書を保持させておいたとする。この場合、クライアント端末140はステップS507にてリソースサーバー121のリソースサーバーモジュール330に対してサービス提供を依頼できる。リソースサーバー121はステップS504と同様にステップS508にてJWSアクセストークンを検証し、ステップS509で処理を行うことが可能となる。本例では、リソースサーバー121は認証認可サーバー110より暗号を復号する手段を提供されておらず、JWSアクセストークンより、"ext:fname"、"ext:lname"、"ext:email"、"ext:tenantid"属性が取得できない。その場合でも平文で格納された情報は取得可能であり、その情報を利用してサービスの提供が可能である。

以上より、一つの署名付きアクセストークンで複数のセキュリティドメインのリソースサーバーへ適切な範囲で情報の提供が可能となる。これにより複数のセキュリティドメインと連携するクライアントを容易に作成することが可能となる。また、認証認可サーバーが各リソースサーバーからの問い合わせを削減しつつ、一つの署名付きアクセストークンで複数のセキュリティドメインのリソースサーバーと連携するクライアントが実現できる。

以上が本発明の一実施形態の説明である。

次に、実施例2で、本発明の実施例1に追加する新たな実施形態を説明する。実施例1において、JWSアクセストークンに属性情報を暗号化して格納しておくことで各リソースサーバーに提供する情報を制限する方法を説明した。本実施例では、トークン取得要求を行ってくるリソースサーバー連携アプリケーション342の種類に応じてさらにJWSアクセストークンに含まれる情報を制御する方法である。本実施例では、認証認可サーバー110が認めないアプリケーションに対しては最低限の情報のみを提供するという制御を実現する。

表9は認証認可サーバー110の認証認可モジュール310で管理される、アプリケーション管理テーブルである。アプリケーション管理テーブルは、アクセストークンの要求元であるアプリケーションのアプリケーションIDと、発行するアクセストークンに含めない付帯情報とを関連付けた除外情報ということもできる。トークン発行要求が行われるリソースサービス連携アプリケーション342のIDと、それに対してJWSアクセストークンの属性の何を除外するかが管理される。本実施例では"print"の場合には、除外属性なしが設定されている。"drs"の場合は、"ext:fname" 、 "ext:lname" 、 "ext:email"が除外属性として設定されている。その他のアプリケーションIDに対しては、"jti" 、"authz:scopes"、 "ext:fname"、 "ext:lname"、 "ext:email"、 "ext:tenantid"が除外属性として設定されている。

図8は、本実施例におけるJWSアクセストークン発行処理を示す図である。図5のステップS501、ステップS502のより詳細なフローである。

まず、ステップS801にてリソースサービス連携アプリケーション342は認証認可サーバー連携アプリケーション341にトークン発行要求を行う。認証認可サーバー連携アプリケーション341はステップS802にて依頼元のリソースサーバー連携アプリケーション342のアプリケーションIDを取得する。さらに、認証認可サーバー連携アプリケーション341は取得したアプリケーションIDも付与し、ステップS803にて認証認可サーバー110にトークンの発行要求を行う。認証認可サーバー110の認証認可モジュール310はステップS803にて、トークン発行処理を実施する。具体的には図9にて説明する。

図9は認証認可モジュール310がステップS603にて行うトークン発行処理のフローを表す図である。

ステップS901にて、アクセス元のクライアントやオーナーの認証・認可を行う。認証・認可が失敗したらステップS904で要求元にエラーレスポンスを返す。認証・認可に成功したら、ステップS902にて、要求元のアプリケーションの判別を行う。要求元アプリケーションIDを表9で示したアプリケーション管理テーブルで検証し、どの属性をJWSアクセストークンに含めるかを決定する。例えば、要求元のアプリケーションIDが"print"の場合、表９においては関連付けられた除外属性はないことから全ての属性情報をJWSアクセストークンに含める。そのため、ステップS903のJWSアクセストークン生成では、実施例1のステップS602で示したものと同様に、全ての属性が含まれるJWSアクセストークンが生成される。また例えば、要求元アプリケーションIDがテーブルに定義されていないIDすなわちその他のIDだった場合には、"jti" 、"authz:scopes"、 "ext:fname"、 "ext:lname"、 "ext:email"、 "ext:tenantid"をJWSアクセストークンに含めないよう生成する。このように発行されたJWSアクセストークンでは、クライアント端末140の確かさは認証認可サーバー110にて確認されていることがわかり、さらに、そのクライアント端末140を一意に識別するデバイスシリアルは取得することが可能である。

以上より、認証認可サービス110以外のセキュリティドメインに所属する様々なリソースサーバーとリソースサーバー連携アプリケーションに対して、制限つきではあるがクライアント端末140の確かな識別情報を提供することができる。そして、それらリソースサーバーに対してデバイスに連携した様々なサービスを提供させることが可能となる。
以上が本発明の実施形態の説明である。

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

110 認証認可サーバー、111 認証認可サーバー、120 リソースサーバー、121 リソースサーバー、140クライアント端末

Claims

リソースへのアクセス権を持つユーザーを認証する認証認可サーバーと、サービスを提供するリソースサーバーと、該リソースサーバーにより提供されるサービスを利用可能なクライアント端末とを有する認証認可システムであって、
前記認証認可サーバーは、所定の付帯情報を暗号化し、暗号化された前記付帯情報を含むデジタル署名されたアクセストークンを発行するトークン発行手段を有し、
前記リソースサーバーは、前記認証認可サーバーより提供された検証用情報を用いて前記アクセストークンを検証するトークン検証手段と、
前記認証認可サーバーより提供された復号用情報を基に、前記アクセストークンに含まれる暗号化された前記付帯情報を復号する復号手段と
を有することを特徴とする認証認可システム。
前記認証認可サーバーは、前記付帯情報ごとの暗号化方式を管理する手段をさらに有し、
前記トークン発行手段は、前記付帯情報ごと前記暗号化方式に従って前記付帯情報を暗号化することを特徴とする請求項１に記載の認証認可システム。
前記トークン発行手段は、前記アクセストークンを要求してきた要求元の識別情報に基づいて、前記アクセストークンに付与する前記付帯情報を制御することを特徴とする請求項１または請求項２に記載の認証認可システム。
前記認証認可サーバーは、前記要求元の識別情報と前記アクセストークンに含めない付帯情報とを関連付けた除外情報を有し、
前記トークン発行手段は、前記除外情報で示された前記付帯情報を、前記アクセストークンに付与しないことを特徴とする請求項３に記載の認証認可システム。
前記リソースサーバーは、前記トークン検証手段により前記アクセストークンの検証が成功した場合には、前記アクセストークンと共に受信した要求に応じたサービスを実行することを特徴とする請求項１乃至請求項４のいずれか一項に記載の認証認可システム。
リソースへのアクセス権を持つユーザーを認証する情報処理装置であって、
アクセストークンの発行要求を受信する手段と、
前記発行要求に応じて、所定の付帯情報を暗号化し、暗号化された前記付帯情報を含むデジタル署名されたアクセストークンを発行するトークン発行手段と
を有することを特徴とする情報処理装置。
サービスを提供する情報処理装置であって、
アクセストークンと共にサービスの要求を受信する手段と、
認証認可サーバーより提供された検証用情報を用いて前記アクセストークンを検証するトークン検証手段と、
前記認証認可サーバーより提供された復号用情報を基に、前記アクセストークンに含まれる暗号化された付帯情報を復号する復号手段と
を有することを特徴とする情報処理装置。
前記トークン検証手段により前記アクセストークンの検証が成功した場合には、前記アクセストークンと共に受信した前記サービスの要求に応じたサービスを実行することを特徴とする請求項７に記載の情報処理装置。
リソースへのアクセス権を持つユーザーを認証する認証認可サーバーと、サービスを提供するリソースサーバーと、該リソースサーバーにより提供されるサービスを利用可能なクライアント端末とを有する認証認可システムにおける認証認可方法であって、
前記認証認可サーバーは、所定の付帯情報を暗号化し、暗号化された前記付帯情報を含むデジタル署名されたアクセストークンを発行し、
前記リソースサーバーは、前記認証認可サーバーより提供された検証用情報を用いて前記アクセストークンを検証し、
前記リソースサーバーは、前記認証認可サーバーより提供された復号用情報を基に、前記アクセストークンに含まれる暗号化された前記付帯情報を復号する
ことを特徴とする認証認可方法。
リソースへのアクセス権を持つユーザーを認証する認証認可サーバーとしてコンピューターを機能させるためのプログラムであって、
アクセストークンの発行要求を受信する手段と、
前記発行要求に応じて、所定の付帯情報を暗号化し、暗号化された前記付帯情報を含むデジタル署名されたアクセストークンを発行するトークン発行手段と
して前記コンピューターを機能させるためのプログラム。
サービスを提供するリソースサーバーとしてコンピューターを機能させるためのプログラムであって、
アクセストークンと共にサービスの要求を受信する手段と、
認証認可サーバーより提供された検証用情報を用いて前記アクセストークンを検証するトークン検証手段と、
前記認証認可サーバーより提供された復号用情報を基に、前記アクセストークンに含まれる暗号化された前記付帯情報を復号する復号手段と
して前記コンピューターを機能させるためのプログラム。