JP2020177537A - 認証認可サーバー、クライアント、サービス提供システム、アクセス管理方法とプログラム - Google Patents

Abstract

【課題】クライアントのアクセス先が移行される際に、クライアントのアクセス先を移行後のサーバーに迅速に変更しないとサーバーが保持する情報に不整合が生じるおそれがある。【解決手段】認証認可サーバーにより、アクセス先の認証認可サーバーが変更されるクライアントに関して変更の予定時期を管理し、クライアントのトークン発行要求に応じてリソースサーバーへのアクセスのための、有効期限を持つアクセストークンを発行し、アクセストークンをクライアントに応答する応答し、アクセストークンを発行する際に、トークン発行要求の要求元のクライアントに関して、アクセス先の認証認可サーバーの変更の予定時期が管理されている場合には、発行するアクセストークンの有効期限を、遅くとも変更の予定時期に満了するよう設定する。【選択図】 図６

Description

本発明は、署名付きアクセストークンを用いた認証認可サーバー、クライアント、サービス提供システム、アクセス管理方法に関する。

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

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

ユーザーが認可操作を行うと、クライアントは、サービスAにおけるユーザーが許可した範囲のデータへのアクセスが認められたことを証明するトークン (以下、アクセストークンと称する)を受け取り、以降のサービスAのAPIへのアクセスはそのアクセストークンを用いて実現できる。このユーザーの認可操作によりクライアントがユーザーのリソースに対しアクセスすることを認可したことを権限委譲と称する。なお、OAuth 2.0では、ユーザーの認可操作を元に認可トークンを発行するサーバーを認可サーバーと呼称する。また、APIを公開するサーバーをリソースサーバー、APIをコールする主体をクライアントと呼称する。

OAuth 2.0では、認可サーバーとリソースサーバーは同一サーバーで構成する事も可能としているが、リソースサーバーが複数種存在する様な大規模なシステムでは、通常認可サーバーを独立したサーバーとして構成する。その場合、上記フローにおいて、サービスAはサービスBからのAPI利用のたびに、取得したアクセストークンの検証を認可サーバーに依頼する。そして、その検証結果を元にクライアントによるAPIの利用の可否を決定する。その場合、大規模システムでは、認可サーバーに負荷が集中してしまうという課題が発生する。そこでサービスAが認可サーバーに検証依頼することなく、自身でアクセストークンを検証する手段として、署名付きアクセストークンの利用が検討されている。署名付きアクセストークンとしては、非特許文献2、3のJWT（JSON Web Token）、JWS（JSON Web Signature）が知られている。サービスAは受信した署名付きアクセストークンの署名を検証する事で、認可サーバーに確認することなく、アクセストークンが有効であるかを判断する事ができる。なおユーザー認証機能を有するサーバーを認証サーバーと呼び、認可サーバーの機能を併せ持つ認証サーバーを認証認可サーバーと呼ぶ。

OAuth2.0クライアントの中には、端末1台につき、1個のクライアント情報を管理し、端末上で動作する複数のアプリケーションでそのクライアント情報を共通利用することがある。この場合、クライアント情報の管理、認可サーバーからのアクセストークン取得、各アプリケーションに対するアクセストークンの提供を一元的に管理する認証認可サーバー連携クライアントが存在する。端末で動作するアプリケーションは認証認可サーバー連携クライアントに対してアクセストークンを要求することで、アクセストークンを取得し、リソースサーバーへアクセスを行う。

さらには、クラウドサービスでは、例えば異なるリージョンなど複数のデータセンターでサービスを稼働する場合がある。この場合、それぞれのデータセンターに配置したリソースサーバーがクライアントに対してサービスを提供する。この時、ユーザーはサービスを提供するデータセンターの所在を意識することなく、いずれかのデータセンターからサービスの提供を受けることになる。

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

"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に示すような構成のネットワーク上に実現される。

●システム構成
広域ネットワーク100は、例えば、インターネット等のWide Area Network（WAN)：ワイドエリアネットワーク、電話回線、専用デジタル回線、ケーブルテレビ回線、データ放送用無線回線等のいずれであってもよいし、それらの組み合わせであってもよい。ＬＡＮ101、102、103は各構成要素を接続するLocal Area Network（LAN）である。本実施形態では、これらのネットワークはWorld Wide Web（WWW）システムが構築されている。すなわち、ネットワークは、ＴＣＰ／ＩＰネットワークであり、各サーバー／クライアントはＨＴＴＰサーバー／クライアント機能を有している。サービスに対しては、クライアントはＨＴＴＰを介してアクセスする。なおサービス提供の基盤として用いることのできるプロトコルはTCP/IPには限らず、他のプロトコルを用いてもよい。

認証認可サーバー110は、認証・認可を実現するためのサービスを提供するサーバーであり、 リソースサーバー120へのアクセスを制御する。リソースサーバー120は、例えば、クライアント端末のデータをバックアップするサービスや、クライアント端末のセンサー情報を分析するサービスなど、アプリケーションに応じて様々なサービスを提供する。認証認可サーバー110とリソースサーバー120は同じデータセンターに存在するサーバーであることを想定する。すなわち、認証認可サーバー110とリソースサーバー120は同じリージョンＡに属する。

認証認可サーバー111は、認証認可サーバー110とは別のサーバーであり、リソースサーバー121へのアクセスを制御する。リソースサーバー121は、例えば、クライアント端末のデータをバックアップするサービスや、クライアント端末のセンサー情報を分析するサービスなど様々なサービスを提供する。認証認可サーバー111とリソースサーバー121は同じデータセンターに存在するサーバーであることを想定する。すなわち、認証認可サーバー111とリソースサーバー121とは同じリージョンＢに属する。また、認証認可サーバー110と認証認可サーバー111、リソースサーバー120とリソースサーバー121とは、それぞれ別のデータセンターに存在するサーバーであると想定する。

実施形態において認証認可サーバー110とリソースサーバー120、認証認可サーバー111とリソースサーバー121は同じデータセンター内に1台ずつ設置しているが、複数台で構成されていても良い。クライアント端末130は、サービスを利用するためのパソコン、モバイル端末、画像形成装置などの機器である。

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

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はCPU231であり、ソフトウェア上の主体は外部メモリ241にインストールされたアプリケーションプログラムである。なおサーバーは、操作部I/F235、操作部239、DSPC236、ディスプレイ240を持っていなくともよい。

●各機器のソフトウェア構成および管理テーブル
図3は本実施の形態に係る、認証認可サーバー110、111、リソースサーバー120、121、クライアント端末130、それぞれのモジュール構成を示す図である。各々のモジュールが実行されることで、各々の機能を実現する。これらモジュールはCPU231がプログラム（ソフトウェア）を実行することで実現され、提供される。

認証認可サーバー110、111は認証認可モジュール310を持つ。認証認可モジュール310では、ユーザーやクライアント端末の認証処理、認証されたユーザーやクライアント端末の認可処理、署名付きアクセストークンの発行処理を行う。クライアント管理モジュール311はクライアントを管理し、クライアントのIDやシークレットを管理する。管理とは、たとえば保存と、必要とされる更新や他の認証認可サーバーへの移行（マイグレーション）等の保守などを含む。

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

クライアント端末130は認証認可サーバー連携クライアント330、リソースサービス連携アプリケーション331を持つ。認証認可サーバー連携クライアント330は認証認可サーバー110に対して、ユーザーやクライアントの認証の要求、アクセストークンの発行依頼や取得を行う。リソースサービス連携アプリケーション331は、リソースサーバー120、121よりサービス提供を受けるアプリケーションである。

リソースサービス連携アプリケーション331は以下の手順でリソースサーバー120、121よりサービス提供を受ける。まず、リソースサーバー120、121は、認証認可サーバー連携クライアント330に対してアクセストークンの発行を依頼する。ここで、認証認可サーバー連携クライアント330は、利用可能なアクセストークンを有していれば、それをリソースサーバー120、121に提供する。利用可能なアクセストークンを有していなければ、リソースサービス連携アプリケーション331用のアクセストークンを認証認可サーバー110、111より取得する。認証認可サーバー連携クライアント330は取得したアクセストークンを要求元のリソースサービス連携アプリケーション331に提供する。リソースサービス連携アプリケーション331は取得したアクセストークンを利用して、リソースサーバー120、121へリソース要求を行うことでサービスの提供を受けることができる。

ここで、認証認可サーバー110、111は表1に示すように、クライアントを一意に識別するクライアントIDとクライアントを認証するための公開鍵、更には、当該クライアントが稼働するクライアント端末130を一意に識別するためのデバイスシリアル、テナントIDを管理している。この表がサーバー用クライアント管理テーブルである。なおここではクライアントとは認証認可サーバー連携クライアント330のことである。認証認可モジュール310は、クライアントIDと公開鍵を元にクライアント端末130を認証し、クライアント端末130のデバイスシリアル、テナントIDを特定することができる。なおテナントとはサービスの提供を受ける顧客の単位であり、実際にリソースサーバーにアクセスしてサービスを受ける個々のユーザーやクライアントはいずれかのテナントに属している。たとえば各テナントのユーザーは他のテナントを意識することなくサービスをあたかも占有しているかのように利用できる。

表1においてたとえばクライアント１は、公開鍵としてpublickey1を用い、稼働する端末のシリアル番号は123456789であり、属するテナントはtenantAである。

クライアント端末130の認証認可サーバー連携クライアント330は、表2に示すように、自端末用のクライアントIDと秘密鍵を、クライアント用クライアント管理テーブルとして保持している。

本実施形態では、クライアントIDと対称鍵（秘密鍵）を用いた認証を前提として説明するが、前述の通り認証方式は特に問わず、クライアントIDとシークレットによる認証といった他の方法でも良い。また、クライアント端末130へのクライアントIDと秘密鍵の登録に関してクライアント端末130の利用開始時に動的に登録する方法や、事前に登録しておくといった方法がある。例えば、動的に登録する場合、クライアント端末130に秘密の情報を保持させておき、その秘密の情報とともに認証認可サーバー110、111にリクエストすると、クライアントIDと対称鍵が動的に生成される。クライアント端末130は認証認可サーバー110、111にて生成されたクライアントIDと秘密鍵をレスポンスで取得し、クライアント管理テーブルにて管理する。

同様に、認証認可サーバー110、111は表3に示すように、クライアントを一意に識別するクライアントIDとクライアントを認証するためのシークレットを管理しており、認証認可モジュール310はその情報を元にクライアント端末130を認証する。

また、認証認可サーバー110、111は、表4に示すように、リージョンごとの接続先情報を管理テーブルとして保持する。接続先情報は、各リージョンの認証認可サーバー110、111やリソースサーバー120、121のURLである。接続先は例えばアドレスと呼んでもよい。接続先は、認証認可サーバーであればアクセストークンの要求の送信先であり、リソースサーバーであればサービス要求の送信先であるともいえる。

ここで、認証認可サーバー110、111は、表5のテナント管理テーブルで示すように、テナント情報として、クライアント端末130が現在アクセスしているデータセンターのリージョン情報１と、マイグレーション後（すなわち移行後または変更後）にアクセスするデータセンターのリージョン情報２と、マイグレーション完了予定時刻（予定時期とも呼ぶ）を管理する。ここでアクセスしているデータセンターとは、アクセスしているサーバーが設置されたデータセンターのことであり、データセンターのリージョン情報は、サーバーのリージョン情報ということもできる。マイグレーションとは、認証認可サーバー110または、リソースサーバー120で管理している、テナント情報、ユーザー情報を、他の認証認可サーバーまたはリソースサーバーに移動（または移行）することである。他の認証認可サーバーまたは、リソースサーバーとは、たとえばクライアントから近いリージョンの認証認可サーバー111または、リソースサーバー121であってもよい。マイグレーションの必要が生じたテナントにおいては、管理者が事前に（マイグレーションに先立って）接続先管理テーブルを登録することで、認証認可サーバー110、111は、表5で示すようにマイグレーション完了予定時刻を管理する。

マイグレーションの発生予定がある場合、つまり、表5のマイグレーション完了予定時刻が設定されている場合は、表５のtenantA、tenantCの状態であり、移行元リージョンである、リージョン情報１と移行先リージョンであるリージョン情報２の値が設定されている状態になる。マイグレーションが終了すると認証認可サーバー110、111は表５をtenantBの設定例のように、リージョン情報２に登録されていた移行先のリージョンIDをリージョン情報１に設定し、リージョン情報２とマイグレーション完了予定時刻の設定値を消去する。この状態だとマイグレーション予定がないテナントの状態になる。

表５のテナント管理テーブルは、アクセス先の認証認可サーバーが変更されるテナント（クライアントを含む）に関して、その変更の予定時期と、変更元および変更先を管理するテーブルともいえる。表５のテナント管理テーブルは、各リージョンの認証認可サーバーが共通に保持してもよいが、リージョン情報１とリージョン情報２それぞれのリージョンに属するデータセンターに設置された認証認可サーバーのみが保持してもよい。後者の場合、たとえばregion（以下リージョンと表す）Aに属する認証認可サーバーがtenant（以下テナントと表す）Aに関するテナント管理テーブルを保持し、リージョンBに属する認証認可サーバーがテナントBとテナントCとに関するテナント管理テーブルを保持してもよい。前者の場合には、すべての認証認可サーバー間でテナント管理テーブルを同期する必要がある。後者の場合には、マイグレーションの予定が登録されたなら、マイグレーション先のリージョンに属する認証認可サーバーのテナント管理テーブルを更新して、マイグレーション前のリージョンに属する認証認可サーバーとテナント管理テーブルの関係する部分を共有する必要がある。

接続先管理テーブルは、ユーザーの現在のアクセス先として設定された認証認可サーバーおよびリソースサーバーの所在と、マイグレーション完了予定時期とを管理するためのテーブルであり、さらにユーザーのマイグレーション後のアクセス先として設定された認証認可サーバーおよびリソースサーバーの所在を管理するためのテーブルである。なお予定時刻には時刻のみならず、年月日など、タイミングを特定するための情報を含んでよい。

また本実施形態ではテナントを単位として管理がされているので表５のような各種テーブルはテナントごとに登録されている。これをたとえばユーザーごとに管理するなら、テナントIDに代えてユーザーIDが登録される。さらにテナントはユーザーの管理単位なので、テナントをユーザーと呼び代えることもできる。

●署名付きアクセストークン
引き続き本実施形態における署名付きアクセストークンの説明を行う。本実施形態では、通常のアクセストークンの代わりにアクセストークン情報およびリソースオーナー情報であるアクセストークンに紐付くユーザー情報を格納する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アクセストークンに含まれるクレームは、以下である。

表6のクレーム名クラス"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)を表す。"nbf"は有効期限の開始時期を示す。上記"exp"、"nbf"、"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を設定する。

さらには、表6のクレーム名クラス"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"としてクライアント端末130を識別するデバイスシリアル番号、"ext: appid"としてリソースサービス連携アプリケーション342を識別するためのアプリケーションIDを設定する。

本実施形態の上記表6で示されたような内容のJWSアクセストークンを発行する認証認可サーバー110は、上記表6のクレームをJWTの仕様であるRFC7519によりJSONとしてエンコードする。また、JWSの仕様であるRFC7515のコンパクトシリアライゼーション仕様に従ってデジタル署名されたコンテンツ（表6のクレームの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、111が予め生成しておいたものを使用する。またJWSの署名を検証する公開鍵はJWSアクセストークンを使用するリソースサーバー120、121に予め配備しておく。リソースサーバー121は認証サーバー110と異なるセキュリティドメインに属するが、JWSアクセストークンを検証する公開鍵を保持する。このため、認証認可サーバー110が発行したJWSアクセストークンで、それを検証する公開鍵を保持したリソースサーバー121が利用可能となる。

図4から図６にて、クライアント端末130がデータマイグレーション後に、移行元リソースサーバー120から移行先リソースサーバー121にアクセス先を変更する処理の流れについて説明する。図4は、クライアント端末130がリソースサーバー120、121にアクセスする通常の処理の流れである。なお、アクセス先のサーバーは図４のリージョンAでもリージョンBでもどちらでもよいが、リソースサーバーと、そのリソースサーバーにアクセスするための認証認可サーバーとは同一のリージョンにあるものとする。

クライアント端末130のリソースサービス連携アプリケーション331はステップS401にて、認証認可サーバー連携クライアント330にトークンの発行要求を行う。認証認可サーバー連携クライアント330は、要求に応じて、表2のクライアント管理テーブルにて管理されているクライアントIDと当該クライアントの秘密鍵を利用してアサーションを作成し、アサーションとともにトークン発行リクエストを生成する。

認証認可サーバー連携クライアント330はステップS402にて認証認可サーバー110、111にアサーションを送信しトークン発行要求を行う。認証認可サーバー連携クライアント330からのトークン発行要求を受けた認証認可サーバー110、111は、ステップS403にてトークン発行要求をしてきた要求元のクライアントの公開鍵を取得し、アサーションの署名を検証する。検証に成功すれば署名付きアクセストークンを発行し、それをレスポンスする。このとき、認証認可サーバー110、111は、要求元のクライアントがアクセスするリソースサーバーURLと認証認可サーバーURLとをトークンとともに応答する。

そのためにステップＳ４０３において認証認可サーバー110、111は、表２のクライアント管理テーブルのクライアントIDが属するテナントのテナントIDを表5のテナント管理テーブルから参照する。テナントとクライアント／ユーザーとの包含関係は、別途テーブルなどで認証認可サーバーが管理していてよい。そして表５のテナント管理テーブルに登録された、参照したテナントIDに対応した現在のクライアントのリージョン情報１を読む。そしてそのリージョン情報１が示すリージョンにひもづくリソースサーバーURLと認証認可サーバーURLとを表４の接続先管理テーブルから取得する。取得した各サーバーのURLを、発行したトークンとともにレスポンスする。なお表１〜表５に示したテーブルを、一つのデータベースとしてまとめておいてもよく、そうすれば上述したテーブルの参照手順も簡単化できる。

レスポンスを受信したクライアント端末130の認証認可サーバー連携クライアント330は、ステップＳ４０１で受信したリクエストの応答として、トークンとリソースサーバーURL、認証認可サーバーURLをリソースサービス連携アプリケーション331へレスポンスする。本トークンは、認証認可サーバー110、111のいずれかによりアクセス制御されているリソースサーバー120、121のいずれかにより検証される。またリソースサーバーURL、認証認可サーバーURLはリソースサーバー120、121のいずれかへアクセスするためのものである。

リソースサービス連携アプリケーション331は、トークンを利用して（すなわちトークンとともに）リソースサーバーURLのリソースサーバー120、121にサービスのリクエストを送信する。リソースサーバー120、121はステップS405にて受信したトークンの検証を行う。リソースサーバー120、121は認証認可サーバー110、111が発行したトークンを検証するための公開鍵を保持しており、トークンを検証することでクライアントの認可を行う。トークンの検証では、トークンの署名が正しいかを公開鍵を用いて検証し、さらにトークンが有効期間中であるかを検証する。このとき、ステップS406にていずれかの検証によりトークンの正当性が判断できない場合は、検証エラー結果をリソースサービス連携アプリケーション331に応答する。また、リソースサーバー120、121はトークンを検証した結果、クライアント情報を取得することが可能であり、アクセス元のクライアント端末130をデバイスシリアルで識別できる。リクエストを受けたリソースサーバー120、121はステップS407にて受信したリクエストに対する処理を行う。

●マイグレーション処理
図５は、クライアント端末130が移行元リソースサーバー120から移行先リソースサーバー121にアクセス先を変更する処理の流れである。本実施形態では、認証認可サーバー110とリソースサーバー120をデータマイグレーション前の移行元サーバーとして、認証認可サーバー111とリソースサーバー121をデータマイグレーション後の移行先サーバーとして定義する。すなわちクライアント端末130が属するテナントに係るデータが、リージョンAからリージョンBへと移行されるということもできる。

クライアント端末130はステップS501にて、認証認可サーバー110にトークン発行要求を行う。認証認可サーバー110は、ステップS502にてトークン発行要求してきたクライアントの公開鍵を取得し、アサーションの署名を検証し、トークンを発行しクライアント端末130にレスポンスする。このとき、表4、表5の情報から移行元リソースサーバーURL、移行元認証認可サーバーURLをトークンとともにレスポンスする。このとき、表５のテナント管理テーブルのマイグレーション完了予定時刻の値が設定されている場合、表5のリージョン情報１のリージョンが、表４の接続先管理テーブル中で示すリソースサーバーURL、認証認可サーバーURLのリージョンとなる。また、このときのトークンにおける有効期限はマイグレーションの完了予定時刻に満了するよう設定される。表６のアクセストークンにおける"nbf"値（有効期限）の設定フローについては図6で後述する。

クライアント端末130は、ステップS503にて、リソースサーバーURLが示す移行元リソースサーバー120にリクエストを送る。移行元リソースサーバー120は、ステップS504にて受信したトークンの検証を行う。移行元リソースサーバー120は、トークンの検証において表6の"nbf"値が有効期間内であるか検証し、有効期間外であれば、検証結果エラーをステップS505にてレスポンスする。データマイグレーション時の移行先リソースサーバー121への切り替え前に発行されるアクセストークンの有効期限としては、遅くともデータマイグレーションが完了するタイミングで満了するが設定される。そのため、図５のように、マイグレーション前に発行されたアクセストークンは、マイグレーション後のステップS505では有効期限を渡過しており、検証の結果エラーをレスポンスすることになる。

クライアント端末130はステップS506にて、取得した認証認可サーバーURLが示す移行元認証認可サーバー110にトークン発行要求を行う。認証認可サーバー110は、ステップS507にてトークンを発行しクライアント端末130にレスポンスする。このとき、表4の接続先管理テーブル、表5のテナント管理テーブルの情報からマイグレーション実行後のリージョン情報１にひもづく移行先リソースサーバーURL、移行先認証認可サーバーURLをトークンとともにレスポンスする。

クライアント端末130はステップS508にて、取得した認証認可サーバーURLが示す移行先認証認可サーバー111にトークン発行要求を行う。認証認可サーバー111は、ステップS509にてトークンを発行しクライアント端末130にレスポンスする。ここで、マイグレーションがあった場合には、クライアント端末130は、ステップS506の後にステップＳ50８で再度トークン発行要求を行うことになる。このトークン発行要求の繰り返しを行うか否かの判定は例えば、ステップＳ506の応答として受信した認証認可サーバーURLと、その時点で保持している認証認可サーバーURLとの比較に基づいてもよい。比較の結果、二つのURLが相違していると判定した場合には、ステップＳ508で、新たな認証認可サーバーURLに対してアクセストークンを要求する。一方同一であれば、取得したアクセストークンを用いて、アクセストークンと同時に取得したリソースサーバーURLに対して、ステップＳ503のようにリクエストを送信してよい。

クライアント端末130は、ステップS510にて、移行先リソースサーバーURLが示す移行先リソースサーバー121にリクエストを送る。移行先リソースサーバー121は、ステップS511にて受信したトークンの検証を行う。移行先リソースサーバー121は、S512にて検証結果のトークンの正当性が確認できた場合は、リクエストに対する処理を行う。移行先リソースサーバー121は、S513にて処理結果をクライアント端末130にレスポンスする。

以上の手順で、クライアントはマイグレーション後のサーバーのアクセス先を遅滞なく知ることができ、アクセスすることができる。

●有効期限（あるいは有効期間）の設定
図６は、認証認可サーバー110、111がマイグレーション予定のあるテナントのクライアント端末130に対しトークンの有効期限値の設定処理フローである。この処理は認証認可サーバーのCPUにより実行される。認証認可サーバー110、111がクライアント端末130からトークン発行要求を受けると、有効期限として既定値を用いたアクセストークンをいったん発行する。その後図6の処理が開始される。

ステップS601にて、認証認可サーバー110、111は表5のテナント管理テーブルのマイグレーション完了予定時刻の有無により、アクセストークンの要求元が、マイグレーション対象のテナントのクライアントであるかを判断する。マイグレーション対象のテナントの場合、S602にて、表５のテナント管理テーブルのマイグレーション完了予定時刻から、表6のアクセストークンの"iat"値であるトークン発行時刻を引いた値と、表6の"exp"値である有効期限値の大小を比較する。有効期限値の方が大きい場合は、S603にて、作成するトークンの有効期限値を、マイグレーション完了予定時刻から現在時刻を引いた値を有効期限値として設定し直す。有効期限値の方が小さい場合は、S604にて、デフォルトの有効期限値をそのまま設定しておく。

なお、前提として、マイグレーションの完了予定時刻とその設定時刻との間隔が、アクセストークンの最長の有効期間よりも長くなるように、マイグレーションの完了予定時刻は設定される。これは、マイグレーションの完了予定時刻が設定されていない状態でアクセストークンを発行した後、そのアクセストークンの有効期限前にマイグレーションが行われてしまうことを防止するためである。

これにより、マイグレーションの予定がある場合は、マイグレーション完了時にはトークンの有効期限が切れることになる。そのためクライアント端末がトークンをキャッシュしている端末であっても、認証認可サーバーに必ずトークンの再発行をリクエストすることで、クライアントは移行先サーバーURLを取得することが可能となる。そして、マイグレーション後にはすべてのクライアントが移行先サーバーにアクセスするようになるため、移行元・移行先サーバー間のデータの不整合或いは齟齬が発生しなくなる。

なお上記説明では、ステップS506の後にステップＳ50８で再度トークン発行要求を行うか否かの判定は例えば、ステップＳ506の応答として受信した認証認可サーバーURLと、その時点で保持している認証認可サーバーURLとの比較に基づいてもよいとした。しかしながら、トークン発行要求を受けた認証認可サーバーが、それ自身のURLと、クライアントIDに基づいて表５のテナント管理テーブルと表４の接続先管理テーブルとから得た認証認可サーバーURLとを比較し、同一であれば認証認可サーバーURLを応答しないように構成してもよい。その場合、アクセストークンを受信したクライアントは、アクセストークンとともに認証認可サーバーURLを受信していればそこに対して再度アクセストークンを要求し、受信していなければリソースサーバーへのリクエストを行ってもよい。

＜実施形態２＞
実施形態２としてデータマイグレーション中に移行元リソースサーバーに更新要求が入る場合にも移行元サーバーと移行先サーバーとの間のデータの不整合または更新ミスを防ぐ手段について説明する。本実施形態では、図６に代えて図７の手順が実行される。

図７は、認証認可サーバー110、111がマイグレーション予定のあるテナントのクライアント端末130に対しトークンの有効期限値の設定処理フローである。認証認可サーバー110、111がクライアント端末130からトークン発行要求を受けると、ステップS701にて、認証認可サーバー110、121は表5のテナント管理テーブルのマイグレーション完了予定時刻の有無によりマイグレーション対象のテナントのクライアントであるかを判断する。マイグレーション対象のテナントの場合、S702にて、リソースサーバーへのリクエストがリソースを更新するリクエスト、つまりWrite系リクエストかどうか判断する。Write系リクエストとはhttp（Hypertext Transfer Protocol）メソッドにおけるPOST、PUT、DELETEでリクエストされるものである。

Read系のリクエストと判定した場合は、S704にて、デフォルトの有効期限値を設定する。S702にて、Write系リクエストと判定した場合、S703にて、デフォルトの有効期限値を設定し、表6のアクセストークンの"nbf"値であるトークンが有効になる日時をマイグレーション完了予定時刻に設定する。なお"nbf"のデフォルト値は発行日時と同一であってよい。更にトークンのレスポンスにトークンとともにマイグレーション完了予定時刻と移行先認証認可サーバーURLと移行先リソースサーバーURLをクライアント端末130にレスポンスする。クライアント端末130では、アクセストークンとともにマイグレーション完了予定時刻を受信したなら、マイグレーション完了予定時刻になるまで、そのトークンは使用しないようにする。また、移行先リソースサーバーURLを一緒に渡すことで、クライアント端末からのURL再取得リクエストを減らすことが可能となる。なおマイグレーション完了予定時刻の送受信を省き、発行されたトークンを通常通り使用してもよい。その場合には、リソースサーバーから、受信したアクセストークンはいまだに使用できない旨の応答があるので、その応答を受けたなら所定時間待機し、その後アクセスを再試行するようにしてよい。

上記のように、マイグレーション完了時刻以降から有効になるトークンに切り替えることにより、マイグレーション完了後のクライアント端末のアクセス先を移行先リソースへのアクセスに切り替えることが可能となる。これにより、マイグレーション後にはすべてのクライアントが移行先サーバーにアクセスするようになるため、移行元・移行先サーバー間のデータ不整合が発生しなくなる。

［その他の実施例］
実施形態１の認証認可サーバーと実施形態２の認証認可サーバーとは、ひとつの認証認可サーバーとしてまとめることもできる。その場合には、実施形態１か実施形態２かいずれの制御を行うか選択可能に認証認可サーバーを構成すればよい。すなわち、第１の選択肢では、実施形態１のようにアクセストークンの有効期限を、遅くともデータの移行の完了予定時期に満了するよう設定する。また第２の選択肢では、実施形態２のようにアクセストークンの有効期限の開始時期をデータ移行の予定時期より後に設定し、設定した開始時期をクライアントに応答する。

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

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

Claims (12)

1. リソースサーバーへのアクセスを管理する認証認可サーバーであって、
   アクセス先の認証認可サーバーが変更されるクライアントに関して、変更の予定時期を管理する管理手段と、
   クライアントのトークン発行要求に応じて、前記リソースサーバーへのアクセスのための、有効期限を持つアクセストークンを発行する発行手段と、
   前記アクセストークンを前記クライアントに応答する応答手段と
   を有し、
   前記発行手段は、前記トークン発行要求の要求元の前記クライアントに関して、アクセス先の認証認可サーバーの変更の予定時期が前記管理手段により管理されている場合には、発行する前記アクセストークンの前記有効期限を、遅くとも前記変更の予定時期に満了するよう設定する
   ことを特徴とする認証認可サーバー。
2. リソースサーバーへのアクセスを管理する認証認可サーバーであって、
   アクセス先の認証認可サーバーが変更されるクライアントに関して、変更の予定時期を管理する管理手段と、
   クライアントのトークン発行要求に応じて、前記リソースサーバーへのアクセスのための、有効期限を持つアクセストークンを発行する発行手段と、
   前記アクセストークンを前記クライアントに応答する応答手段と
   を有し、
   前記発行手段は、前記トークン発行要求の要求元の前記クライアントに関して、アクセス先の認証認可サーバーの変更の予定時期が前記管理手段により管理されている場合には、発行する前記アクセストークンの前記有効期限の開始時期を、前記変更の予定時期より後に設定し、
   前記応答手段は、前記アクセストークンとともに、前記アクセストークンの前記有効期限の開始時期を前記クライアントに応答する
   ことを特徴とする認証認可サーバー。
3. 請求項１乃至２のいずれか一項に記載の認証認可サーバーであって、
   前記管理手段は、前記クライアントに関する現在のアクセス先の認証認可サーバーのアドレスをさらに管理し、アクセス先の認証認可サーバーが変更される前記クライアントに関しては、変更後のアクセス先の認証認可サーバーのアドレスをさらに管理し、
   前記管理手段はさらに、アクセス先の認証認可サーバーが変更される前記クライアントに関して、前記変更の予定時期に達したなら、前記変更後のアクセス先の認証認可サーバーのアドレスを、前記現在のアクセス先の認証認可サーバーのアドレスとして設定し、前記変更後のアクセス先の認証認可サーバーのアドレスと前記変更の予定時期とを消去する
   ことを特徴とする認証認可サーバー。
4. 請求項１乃至３のいずれか一項に記載の認証認可サーバーであって、
   前記応答手段は、前記アクセストークンとともに、前記トークン発行要求の要求元の前記クライアントに関する前記現在のアクセス先の認証認可サーバーのアドレスを前記クライアントに応答する
   ことを特徴とする認証認可サーバー。
5. 請求項１乃至４のいずれか一項に記載の認証認可サーバーであって、
   前記管理手段は、前記クライアントに関する現在のアクセス先のリソースサーバーのアドレスをさらに管理し、
   前記応答手段はさらに、前記アクセストークンとともに、前記トークン発行要求の要求元の前記クライアントに関する前記現在のアクセス先のリソースサーバーのアドレスを前記クライアントに応答する
   ことを特徴とする認証認可サーバー。
6. リソースサーバーへアクセスするためのアクセストークンの要求を認証認可サーバーに送信する要求手段と、
   前記アクセストークンの要求に対する応答として前記認証認可サーバーから受信したアクセス先の認証認可サーバーのアドレスが、前記アクセストークンの要求の送信先の前記認証認可サーバーのアドレスと相違している場合には、前記認証認可サーバーから受信したアクセス先の認証認可サーバーのアドレスに対して、前記アクセストークンの要求を送信するよう制御する制御手段と、
   前記認証サーバーから受信した前記アクセストークンを用いて前記リソースサーバーにアクセスする手段と
   を有することを特徴とするクライアント。
7. 請求項６に記載のクライアントであって、
   前記認証認可サーバーから、前記アクセストークンとともに前記アクセストークンの前記有効期限の開始時期を受信した場合には、前記開始時期の後に、前記アクセストークンを用いて前記リソースサーバーにアクセスする
   ことを特徴とするクライアント。
8. 請求項１乃至５のいずれか一項に記載の認証認可サーバーとしてコンピューターを機能させるためのプログラム。
9. 請求項６または７に記載のクライアントとしてコンピューターを機能させるためのプログラム。
10. 請求項１乃至５のいずれか一項に記載の認証認可サーバーと、
    請求項６または７に記載のクライアントと
    を含むことを特徴とするサービス提供システム。
11. 認証認可サーバーによるリソースサーバーへのアクセス管理方法であって、
    アクセス先の認証認可サーバーが変更されるクライアントに関して、変更の予定時期を管理し、
    クライアントのトークン発行要求に応じて、前記リソースサーバーへのアクセスのための、有効期限を持つアクセストークンを発行し、
    前記アクセストークンを前記クライアントに応答するアクセス管理方法であって、
    前記アクセストークンを発行する際に、前記トークン発行要求の要求元の前記クライアントに関して、アクセス先の認証認可サーバーの変更の予定時期が管理されている場合には、発行する前記アクセストークンの前記有効期限を、遅くとも前記変更の予定時期に満了するよう設定する
    ことを特徴とするアクセス管理方法。
12. 認証認可サーバーによるリソースサーバーへのアクセス管理方法であって、
    アクセス先の認証認可サーバーが変更されるクライアントに関して、変更の予定時期を管理し、
    クライアントのトークン発行要求に応じて、前記リソースサーバーへのアクセスのための、有効期限を持つアクセストークンを発行し、
    前記アクセストークンを前記クライアントに応答するアクセス管理方法であって、
    前記アクセストークンを発行する際に、前記トークン発行要求の要求元の前記クライアントに関して、アクセス先の認証認可サーバーの変更の予定時期が管理されている場合には、発行する前記アクセストークンの前記有効期限の開始時期を、前記変更の予定時期より後に設定し、
    前記アクセストークンとともに、前記アクセストークンの前記有効期限の開始時期を前記クライアントに応答する
    ことを特徴とするアクセス管理方法。

Images