(57)【要約】      （修正有）【課題】認可サーバーへの日時取得のための問い合わせを最小限にする。【解決手段】クライアント端末は、自端末に設定されている第１の日時を含むトークン発行要求を、複数の認証許可サーバーの１つに送信し、応答として認証許可サーバーの第２の日時を受信し、第１の日時と第２の日時とに基づき日時オフセットを算出して記憶する。２回目のトークン発行要求を送信する場合、記憶された日時オフセットの中から対象の認証許可サーバーの日時オフセットを特定し、特定された日時オフセットから推定される第３の日時を含めてトークン発行要求を送信する。【選択図】図８
2020009259.tif 000002
【特許請求の範囲】
【請求項１】
アクセストークンを発行することが可能な複数の認証認可サーバーと通信する情報処理装置であって、
前記情報処理装置に設定されている第１の日時を含むトークン発行要求を１つの認証認可サーバーに送信する送信手段と、
前記送信手段により送信された前記トークン発行要求に対する応答として、前記１つの認証認可サーバーに設定されている第２の日時を受信する受信手段と、
前記受信手段により受信された前記第２の日時と前記第１の日時とに基づき日時オフセットを算出し、前記１つの認証認可サーバーに関連付けて記憶する記憶手段と、を有し、
前記記憶手段は、前記複数の認証認可サーバーの夫々に対する日時オフセットを記憶することが可能であり、
前記送信手段は、前記複数の認証認可サーバーの何れか１つに対して２回目のトークン発行要求を送信する場合、前記記憶手段により記憶された日時オフセットの中から送信対象となる認証認可サーバーの日時オフセットを特定し、前記２回目のトークン発行要求には特定された前記日時オフセットから推定される第３の日時を含めて送信することを特徴とする情報処理装置。
【請求項２】
前記受信手段が受信する第２の日時は、前記１つの認証認可サーバーが前記第１の日時と前記第２の日時の誤差が一定以内ではないと判定した場合に送信される日時であることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記受信手段は、前記１つの認証認可サーバーが前記トークン発行要求が正規な要求であり、かつ前記第１の日時と前記第２の日時の誤差が一定以内であると判定した場合に送信される前記アクセストークンを受信することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記記憶手段は、前記受信手段により前記アクセストークンを受信した場合、日時オフセットを記憶しないことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記送信手段が前記複数の認証認可サーバーの何れか１つに対して２回目以降のトークン発行要求を送信する際、前記記憶手段により記憶された日時オフセットが記憶されていない場合、前記第１の日時を含むトークン発行要求を送信し、前記記憶手段により記憶された日時オフセットが記憶されている場合、前記第３の日時を含むトークン発行要求を送信することを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
【請求項６】
前記複数の認証認可サーバーに含まれる夫々の認証認可サーバーをグルーピングするグルーピング手段を有し、
前記送信手段は、前記複数の認証認可サーバーの何れか１つに対して初めてトークン発行要求を送信する場合、前記記憶手段により記憶された日時オフセットの中から送信対象の認証認可サーバーが属するグループに対応する日時オフセットを特定し、前記トークン発行要求には特定された前記日時オフセットから推定される第３の日時を含めて送信することを特徴とする請求項１乃至５の何れか１項に情報処理装置。
【請求項７】
前記グルーピング手段は、共通の特徴を持つ認証認可サーバーを同じグループとしてグルーピングすることを特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記第３の日時は、前記第１の日時と前記日時オフセットとから算出した日時であることを特徴とする請求項１乃至７の何れか１項に記載の情報処理装置。
【請求項９】
アクセストークンを発行することが可能な複数の認証認可サーバーと通信する情報処理装置の制御方法であって、
前記情報処理装置に設定されている第１の日時を含むトークン発行要求を１つの認証認可サーバーに送信する送信ステップと、
前記送信ステップにおいて送信された前記トークン発行要求に対する応答として、前記１つの認証認可サーバーに設定されている第２の日時を受信する受信ステップと、
前記受信ステップにおいて受信された前記第２の日時と前記第１の日時とに基づき日時オフセットを算出し、前記１つの認証認可サーバーに関連付けて記憶する記憶ステップと、を含み、
前記記憶ステップでは、前記複数の認証認可サーバーの夫々に対する日時オフセットを記憶することが可能であり、
前記送信ステップでは、前記複数の認証認可サーバーの何れか１つに対して２回目のトークン発行要求を送信する場合、前記記憶ステップにおいて記憶された日時オフセットの中から送信対象となる認証認可サーバーの日時オフセットを特定し、前記２回目のトークン発行要求には特定された前記日時オフセットから推定される第３の日時を含めて送信することを特徴とする制御方法。
【請求項１０】
アクセストークンを発行することが可能な複数の認証認可サーバーと通信する情報処理装置の制御方法のプログラムであって、
前記情報処理装置に設定されている第１の日時を含むトークン発行要求を１つの認証認可サーバーに送信する送信ステップと、
前記送信ステップにおいて送信された前記トークン発行要求に対する応答として、前記１つの認証認可サーバーに設定されている第２の日時を受信する受信ステップと、
前記受信ステップにおいて受信された前記第２の日時と前記第１の日時とに基づき日時オフセットを算出し、前記１つの認証認可サーバーに関連付けて記憶する記憶ステップと、を含み、
前記記憶ステップでは、前記複数の認証認可サーバーの夫々に対する日時オフセットを記憶することが可能であり、
前記送信ステップでは、前記複数の認証認可サーバーの何れか１つに対して２回目のトークン発行要求を送信する場合、前記記憶ステップにおいて記憶された日時オフセットの中から送信対象となる認証認可サーバーの日時オフセットを特定し、前記２回目のトークン発行要求には特定された前記日時オフセットから推定される第３の日時を含めて送信することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセストークンを用いる情報処理装置、制御方法、およびそのプログラムに関する。
【背景技術】
【０００２】
近年、インターネット上に展開された所謂クラウドサービスの利用が拡大している。また、これらクラウドサービスは個々にＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を公開している。他のアプリケーションやクラウドサービスからＡＰＩを介してサービスが提供する機能を利用する事が可能となっている。これらＷｅｂサービスＡＰＩではＯＡｕｔｈ  ２．０と呼ばれる、認可の連携を実現させるための標準プロトコルの採用が進んでいる。非特許文献１にはＯＡｕｔｈ  ２．０を利用した技術が開示されている。
【０００３】
ＯＡｕｔｈ  ２．０によれば、例えばあるサービスＡが管理するユーザーのデータを取得するＡＰＩに対して、そのユーザーから認められた範囲にてサービスＢがアクセスすることができる。このときサービスＡは、サービスＢからアクセスされる範囲を明らかにした上で、サービスＢによるＡＰＩへのアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを認可操作と称する。また、このアクセスされる範囲をＯＡｕｔｈ  ２．０ではスコープと呼称し、スコープによりデータへのアクセス許容量が決定される。
【０００４】
ユーザーが認可操作を行うと、サービスＢは、サービスＡにおけるユーザーが許可した範囲のデータへのアクセスが認められたことを証明する認可トークンを受け取る。以降のサービスＡのＡＰＩへのアクセスはその認可トークンを用いて実現できる。認可トークンは単にトークン、またはアクセストークンと状況に応じて様々な呼ばれ方をするが、いずれの場合であっても同じ認可トークンを指す。このユーザーの認可操作によりサービスＢがユーザーのリソースに対しアクセスすることを認可したことを権限委譲と称する。なお、ＯＡｕｔｈ  ２．０では、ユーザーの認可操作を元に認可トークンを発行するサーバーを認可サーバーまたは認証認可サーバーと呼称する。また、ＡＰＩを公開するサーバーをリソースサーバー、ＡＰＩをコールする主体をクライアントと呼称する。
【０００５】
ＯＡｕｔｈ  ２．０では、認可サーバーとリソースサーバーは同一サーバーで構成する事も可能としているが、リソースサーバーが複数種存在する様な大規模なシステムでは、通常、認可サーバーを独立したサーバーとして構成する。その場合、上記フローにおいて、サービスＡはサービスＢからのＡＰＩ利用のたびに、取得したアクセストークンの検証を認可サーバーに依頼する。そして、その検証結果を元にＡＰＩの利用の可否を決定する。その場合、大規模システムでは、認可サーバーに負荷が集中してしまうという課題が発生する。そこでサービスＡが認可サーバーに検証依頼することなく、自身でアクセストークンを検証する手段として、署名付きアクセストークンの利用が検討されている。署名付きアクセストークンとしては、非特許文献２および３にて、ＪＷＴ（ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ）とＪＷＳ（ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ）が知られている。サービスＡは受信した署名付きアクセストークンの署名を検証する事で、認可サーバーに確認することなく、アクセストークンが有効であるかを判断する事ができる。
【０００６】
また、ＪＷＴには、リプレイアタックを防ぐためと、認可サーバーが署名付きアクセストークンを保持しておく時間を明確にするために、ＪＷＴを作成した日時をそれ自身に含めることが可能である。非特許文献４は、チケットにタイムスタンプを含め、タイムスタンプがサーバーの時刻と一定以上乖離している場合、認証を受け付けない方法を示している。ＪＷＴでも同様に、ＪＷＴに含まれたＪＷＴ作成日時が認可サーバーの日時と乖離していた場合、認可サーバーが認可を拒否する方法が考えられる。
【０００７】
しかし、必ずしもクライアントや認可サーバーの日時が、実際の日時（以降、絶対日時と称する）に常に同期しているわけではない。ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）プロトコルやＳＮＴＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）プロトコルによって絶対日時に同期する方法もあるが、専用の同期用サーバーをインターネット上に公開する必要がある。その場合、大量のクライアントが使用することと、第三者に利用される可能性があることを考慮すると、コストの面から難しかった。
【０００８】
一般的な技術として特許文献１では、クライアントがサーバーから返信されたサーバー日時に同期し、同期後に認証要求を送信することを開示している。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】“Ｔｈｅ  ＯＡｕｔｈ  ２．０  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ”、［ｏｎｌｉｎｅ］Ｄ．Ｈａｒｄｔ、２０１２年８月＜ＵＲＬ  ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９＞
【非特許文献２】“ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ（ＪＷＴ）”、［ｏｎｌｉｎｅ］Ｍ．Ｊｏｎｅｓ，Ｊ．Ｂｒａｄｌｅｙ，Ｎ．Ｓａｋｉｍｕｒａ、２０１５年５月＜ＵＲＬ  ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７５１９＞
【非特許文献３】“ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ（ＪＷＳ）”、［ｏｎｌｉｎｅ］Ｍ．Ｊｏｎｅｓ，Ｊ．Ｂｒａｄｌｅｙ，Ｎ．Ｓａｋｉｍｕｒａ、２０１５年５月＜ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７５１５＞
【非特許文献４】“Ｔｈｅ  Ｋｅｒｂｅｒｏｓ  Ｎｅｔｗｏｒｋ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ（Ｖ５）”、［ｏｎｌｉｎｅ］Ｊ．Ｋｏｈｌ，Ｃ．Ｎｅｕｍａｎ、１９９３年９月＜ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ１５１０＞
【特許文献】
【００１０】
【特許文献１】特開２０１６−３１５９３
【発明の概要】
【発明が解決しようとする課題】
【００１１】
クライアントが複数の認可サーバーと通信する場合では、複数の認可サーバー同士が同一の日時に同期出来ていない時、タイミングによっては、クライアントが認可サーバーに対して日時情報取得のための問い合わせを繰り返してしまう。その結果、不要な問い合わせが増大することで、パフォーマンスの悪化およびコストが増えてしまうという課題があった。
【００１２】
本発明の目的は、上記課題を解決するために、複数の認可サーバーと通信する場合に、認可サーバーとの日時オフセットをクライアントが適切に管理し、認可サーバーへの日時取得のための問い合わせを最小限にすることである。
【課題を解決するための手段】
【００１３】
本願発明の一実施形態に係る情報処理装置は、アクセストークンを発行することが可能な複数の認証認可サーバーと通信する情報処理装置であって、前記情報処理装置に設定されている第１の日時を含むトークン発行要求を１つの認証認可サーバーに送信する送信手段と、前記送信手段により送信された前記トークン発行要求に対する応答として、前記１つの認証認可サーバーに設定されている第２の日時を受信する受信手段と、前記受信手段により受信された前記第２の日時と前記第１の日時とに基づき日時オフセットを算出し、前記１つの認証認可サーバーに関連付けて記憶する記憶手段と、を有し、前記記憶手段は、前記複数の認証認可サーバーの夫々に対する日時オフセットを記憶することが可能であり、前記送信手段は、前記複数の認証認可サーバーの何れか１つに対して２回目のトークン発行要求を送信する場合、前記記憶手段により記憶された日時オフセットの中から送信対象となる認証認可サーバーの日時オフセットを特定し、前記２回目のトークン発行要求には特定された前記日時オフセットから推定される第３の日時を含めて送信することを特徴とする。
【発明の効果】
【００１４】
本発明の目的を解決するシステムによれば、クライアントが認可サーバーの日時を取得する回数を最小限に抑えることで、パフォーマンス劣化とサーバー負荷を低減することが出来る。
【図面の簡単な説明】
【００１５】
【図１】システム構成図
【図２】各装置のハードウェア構成図
【図３】各装置のソフトウェアモジュール構成図
【図４】従来技術でのアクセストークン発行と検証のシーケンス図
【図５】ＪＷＳアクセストークン発行と検証のシーケンス図
【図６】クライアント日時設定を行うＪＷＳアクセストークン発行と検証のフロー図
【図７】複数の認証認可サーバーと通信する、クライアント日時設定を行うＪＷＳアクセストークン発行と検証のフロー図
【図８】サーバーに対応する日時オフセットを使用するＪＷＳアクセストークン発行と検証のシーケンス図
【図９】具体的な日時を使用した、サーバーに対応する日時オフセットを使用する場合の動作説明図
【図１０】サーバーグルーピングを用いるＪＷＳアクセストークン発行と検証のシーケンス図
【図１１】初期グループ決定処理のフローチャート
【図１２】具体的な日時を使用した、サーバーグルーピングを用いる場合の動作説明図
【発明を実施するための形態】
【００１６】
以下、本発明を実施するための形態について図面を用いて説明する。
【００１７】
［実施例１］
本実施例においては、インターネット上の各サーバーにアプリケーションが設置されていることとする。アプリケーションはクライアント端末と連携し、様々な機能を提供することとする。このような機能を提供する実体をサービスと称し、機能をクライアント端末に提供することをサービスの提供と称する。
【００１８】
本実施の形態に係る情報処理システムである認証・認可システムは、図１に示すような構成のネットワーク上に実現される。１００は、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＷＡＮ）であり、本発明ではＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１、１０２、１０３は各構成要素を接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ）である。１１０はユーザー・クライアント端末の認証および、ＯＡｕｔｈを実現するための認証認可サーバーＡである。１２０はリソースサーバーＡであり、様々なサービスを提供する。
【００１９】
実施例１において各サーバーは１台ずつ設置されているが複数台で構成されていても良く、例えば、認証認可サーバーＡシステムとして提供されても良い。１４０はクライアント端末であり、パソコン、モバイル端末、画像形成装置などである。クライアント端末１４０には、１つまたは複数のリソースサービス連携アプリケーションがインストールされており、リソースサービスとのデータ送受信を行う。認証認可サーバーＢ１１１とリソースサーバーＢ１２１は認証認可サーバーＡ１１０とリソースサーバーＡ１２０と同様の構成である。しかし、別のセキュリティドメインのシステムであり、認証認可サーバーＢ１１１より発行されたトークンでリソースサーバーＢ１２１を利用する。
【００２０】
図２は本実施例に係る、認証認可サーバーＡ１１０、認証認可サーバーＢ１１１、リソースサーバーＡ１２０、リソースサーバーＢ１２１、クライアント端末１４０を構成する情報処理装置の一般的なハードウェア構成である。ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳやアプリケーション等のプログラムを実行する。またＣＰＵ２３１は、システムバス２３４に接続される各ブロックを制御する。ここでＯＳとはコンピューター上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。
【００２１】
ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。操作部Ｉ／Ｆ２３５は、操作部２４２からの入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。ディスクコントローラ（ＤＫＣ）２３７は各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。
【００２２】
ネットワークコントローラ（ＮＣ）２３８はＷＡＮ１００もしくはＬＡＮ１０１、１０２、１０３を介して接続されたサーバーコンピューターや他の機器との通信制御処理を実行する。リアルタイムクロック（ＲＴＣ）２３９は、情報処理装置の電源が切られていても日時をカウントするために用いられる。システム本体の電源系統とは異なる電源とも接続される。異なる電源は、ボタン型電池などの一次電池や、コンデンサや二次電池などから供給される。
【００２３】
尚、後述の全ての説明においては、特に断りのない限り各機能の実行フローのハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたアプリケーションプログラムである。
【００２４】
図３は本実施の形態に係る、認証認可サーバーＡ１１０、認証認可サーバーＢ１１１、リソースサーバーＡ１２０、リソースサーバーＢ１２１、クライアント端末１４０、それぞれのモジュール構成を示す図である。各々のモジュールが実行されることで、各々の機能を実現する。
【００２５】
認証認可サーバーＡ１１０、認証認可サーバーＢ１１１は認証認可モジュール３１０を持つ。認証認可モジュール３１０では、ユーザーやクライアント端末の認証処理、認証されたユーザーやクライアント端末の認可処理、署名付きアクセストークンの発行処理を行う。
【００２６】
リソースサーバーＡ１２０、リソースサーバーＢ１２１はリソースサーバーモジュール３２０を持つ。リソースサーバーモジュール３２０は、ＷｅｂサービスとしてＡＰＩを公開し、クライアント端末１４０からのサービス提供の要求を受け付けサービスの提供を行う。また、クライアント端末１４０からの要求に対して、署名付きアクセストークンの検証処理を行うことでサービス提供の可否を決定する。
【００２７】
クライアント端末１４０は認証認可サーバー連携クライアント３４１、リソースサービス連携アプリケーション３４２を持つ。また、ＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ３４３を持つ場合があるが必須ではない。認証認可サーバー連携クライアント３４１は認証認可サーバーＡ１１０に対して、ユーザーやクライアントの認証の要求、アクセストークンの発行依頼や取得を行う。
【００２８】
リソースサービス連携アプリケーション３４２は、リソースサーバーＡ１２０、リソースサーバーＢ１２１よりサービス提供を受けるアプリケーションである。リソースサービス連携アプリケーション３４２は以下の手順でリソースサーバーＡ１２０、リソースサーバーＢ１２１よりサービス提供を受ける。まず、リソースサービス連携アプリケーション３４２は認証認可サーバー連携クライアント３４１に対してアクセストークンの発行を依頼する。ここで、認証認可サーバー連携クライアント３４１はリソースサービス連携アプリケーション３４２用のアクセストークンを認証認可サーバーＡ１１０より取得する。
【００２９】
認証認可サーバー連携クライアント３４１は取得したアクセストークンを要求元のリソースサービス連携アプリケーション３４２に返却する。リソースサービス連携アプリケーション３４２は取得したアクセストークンを利用して、リソースサーバーＡ１２０、リソースサーバーＢ１２１へリソース要求を行うことでサービスの提供を受けることができる。
【００３０】
また、認証認可サーバー連携クライアント３４１は日時オフセット記憶領域３４４を持つ。日時オフセット記憶領域３４４は、認証認可サーバーＡ１１０、認証認可サーバーＢ１１１が返却するサーバー日時とクライアント端末１４０の持つクライアント日時との差分が記憶される。
【００３１】
図４にてＯＡｕｔｈ  ２．０でのアクセストークン発行と検証の流れについて説明する。図４はアクセストークン発行と検証に関するシーケンス図である。認証認可サーバーＡ１１０、リソースサーバーＡ１２０、クライアント端末１４０間で連携している。
【００３２】
まず、クライアント端末１４０は、ステップＳ４０１にて認証認可サーバーＡ１１０に対して認証情報あるいは認可コードを送信しアクセストークンを要求し、取得する。認証情報を送信するか認可コードを送信するかは、オーナーによって異なる。クライアント端末１４０が処理を実施するオーナーである場合はクライアント端末１４０自体が認証を行い、クライアント端末１４０が他のオーナーから処理を依頼される場合にはオーナーから受け取った認可コードを渡すことになる。
【００３３】
次に、クライアント端末１４０は取得したアクセストークンを使って、ステップＳ４０２にてリソースサーバーＡ１２０に対してサービスの提供を要求する。リソースサーバーＡ１２０は受け取ったアクセストークンが適正かどうかをステップＳ４０３にて認証認可サーバーＡ１１０に検証するよう要求する。
【００３４】
認証認可サーバーＡ１１０はステップＳ４０４にてアクセストークンの検証を行い、適正であればリソースサーバーＡ１２０はステップＳ４０５にてサービスを提供するための処理を実行し、処理結果をクライアント端末１４０に返す。なお、ステップＳ４０４の検証でアクセストークンが不適正であった場合は、リソースサーバーＡ１２０は処理を行わず、エラーをクライアント端末１４０に返す。
【００３５】
引き続き実施例１における署名付きアクセストークンの説明を行う。実施例１では、通常のアクセストークンの代わりにアクセストークン情報およびリソースオーナー情報であるアクセストークンに紐付くユーザー情報を格納するＪＷＳ（以降ＪＷＳアクセストークンとする）を用いてリソースサーバーにアクセスする。
【００３６】
以下本実施例で用いるＪＷＳアクセストークンについて詳述する。ＪＷＳ（ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ）は、ＪＷＴ（ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ）で表現されたコンテンツをデジタル署名やＭＡＣｓ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅｓ）により保護して表現する方法である。またＪＷＴは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標）  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）をベースとしたデータ構造を用いたＵＲＬセーフなクレームの表現方法である。ＪＷＳ、ＪＷＴについては、各々ＲＦＣ（ＲＦＣ７５１５（ＪＷＳ）、ＲＦＣ７５１９（ＪＷＴ））として仕様化、公開されている。
【００３７】
本実施例で使用するＪＷＳアクセストークンに含まれるクレームは、以下である。
【００３８】
【表１】
2020009259.tif 000003
【００３９】
表１のクレーム名クラス“Ｒｅｇｉｓｔｅｒｅｄ  Ｃｌａｉｍ”の各クレームは、ＪＷＴのＲＦＣ７５１９で予め定義されたクレームで以下である。すなわち、ＪＷＴの発行者の識別子“ｉｓｓ”（Ｉｓｓｕｅｒ）、ＪＷＴの主語となる主体の識別子“ｓｕｂ”（Ｓｕｂｊｅｃｔ）、ＪＷＴを利用することが想定された主体の識別子一覧“ａｕｄ”（Ａｕｄｉｅｎｃｅ）、ＪＷＴの有効期限“ｅｘｐ”（Ｅｘｐｉｒａｔｉｏｎ  Ｔｉｍｅ）、ＪＷＴが有効になる日時“ｎｂｆ”（Ｎｏｔ  Ｂｅｆｏｒｅ）、ＪＷＴを発行した時刻“ｉａｔ”（Ｉｓｓｕｅｄ  Ａｔ）、ＪＷＴのための一意な識別子“ｊｔｉ”（ＪＷＴ  ＩＤ）を表す。上記“ｅｘｐ”、“ｎｂｔ”、“ｉａｔ”に指定する日時はＩｎｔＤａｔｅで、１９７０−０１−０１Ｔ０：０：０Ｚ  ＵＴＣから指定されたＵＴＣの日付／時刻まで秒の数を表わすＪＳＯＮ数値である。またこれらの“Ｒｅｇｉｓｔｅｒｅｄ  Ｃｌａｉｍ”の使用は任意である。
【００４０】
実施例１においては、ＪＷＳアクセストークンを発行する認証認可サーバーＡ１１０が以下のように値を設定する。“ｉｓｓ”として認証認可サーバーＡ１１０のＵＲＩ、“ｓｕｂ”としてユーザーのＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）、“ａｕｄ”としてリソースサーバーＡ１２０のＵＲＩを設定する。また、“ｅｘｐ”として本ＪＷＴ発行時から３６００秒、すなわち“ｉａｔ”の値＋３６００、“ｎｂｆ”として本ＪＷＴ発行時、“すなわち“ｉａｔ”と同じ値を設定する。また、“ｊｔｉ”として認可トークン情報の認可トークンＩＤを設定する。
【００４１】
さらには、表１のクレーム名クラス“Ｐｒｉｖａｔｅ  Ｃｌａｉｍ”の各クレームは、ＪＷＴのＲＦＣ７５１９によると、ＪＷＴ発行者と利用者の合意のものとで使用するプライベートクレーム名クラスである。他に定義されたクレーム名と衝突のないことを前提とする。本実施例では、“Ｐｒｉｖａｔｅ  Ｃｌａｉｍ”クラスのクレーム名に認可トークン情報（認可トークンスコープリスト“ａｕｔｈｚ：ｓｃｏｐｅｓ”，認可トークンクライアントＩＤ“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”）と、認可トークンに紐付く属性情報（デバイスシリアル“ｅｘｔ：ｄｅｖｉｃｅ−ｓｅｒｉａｌ”，アプリケーションＩＤ“ｅｘｔ：ａｐｐｉｄ”）を持つことを特徴とする。
【００４２】
具体的には、ＪＷＳアクセストークンを発行する認証認可サーバーＡ１１０が、認可情報として“ａｕｔｈｚ：ｓｃｏｐｅｓ”、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”のクレームを設定する。すなわち、“ａｕｔｈｚ：ｓｃｏｐｅｓ”としてリソースサーバーＡ１２０が取得を許可するリソースを表すスコープリストを設定する。さらに、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”としてリソースサーバーＡ１２０にアクセスするクライアントのＩＤを表す“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”を設定する。また、“ｅｘｔ：ｄｅｖ−ｓｅｒｉａｌ”としてクライアント端末１４０を識別するデバイスシリアル番号、“ｅｘｔ：ａｐｐｉｄ”としてリソースサービス連携アプリケーション３４２を識別するためのアプリケーションＩＤを設定する。詳細は後述する。また、ＪＷＳはアクセストークンのためだけでなく、クライアント端末１４０が認証認可サーバーＡ１１０、認証認可サーバーＢ１１１に対して、トークン発行要求を行うときにも使用される。その際の各クレームに格納すべき値は、ＪＷＳアクセストークンと同様となる。
【００４３】
実施例１の表１で示されたような内容のＪＷＳアクセストークンを発行する認証認可サーバーＡ１１０は、表１のクレームをＪＷＴの仕様であるＲＦＣ７５１９によりＪＳＯＮとしてエンコードする。また、ＪＷＳの仕様であるＲＦＣ７５１５のコンパクトシリアライゼーション仕様に従ってデジタル署名されたコンテンツ（表１のクレームのＪＳＯＮ表現、すなわちＪＷＳペイロード）をコンパクトなＵＲＬ−ｓａｆｅ文字列として表現符号化する。本実施例のＪＷＳアクセストークンは、ＪＷＳコンパクトシリアライゼーション仕様に従い、エンコード済ＪＷＳヘッダー、エンコード済ＪＷＳペイロード、およびエンコード済ＪＷＳ署名を、この順序でピリオド（’．’）文字を区切り文字として連結した文字列である。
【００４４】
本実施例においては、ＪＷＳヘッダーとしてＪＷＳの署名に使われる暗号アルゴリズムを識別する“ａｌｇ”（アルゴリズム）を用いる。具体的に本実施例においては、“ａｌｇ”として“ＲＳ２５６”（ＲＳＡＳＳＡ−ＰＫＣＳ１＿ｖ１＿５  ｕｓｉｎｇ  ＳＨＡ−２５６）を用いる。“ＲＳ２５６”文字列は、ａｌｇの値としてＩＡＮＡ  ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ  ａｎｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ａｌｇｏｒｉｔｈｍｓレジストリに登録されており、ＪＳＯＮ  Ｗｅｂ  Ａｌｇｏｒｉｔｈｍｓ（ＪＷＡ）仕様（ＲＦＣ７５１８）のＳｅｃｔｉｏｎ  ３．１で定義されている。
【００４５】
なお本実施例においてＪＷＳの署名に使われる暗号アルゴリズム“ＲＳ２５６”で使用する秘密鍵、公開鍵の鍵ペアは、認証認可サーバーＡ１１０が予め生成しておいたものを使用する。またＪＷＳの署名を検証する公開鍵はＪＷＳアクセストークンを使用するリソースサーバーＡ１２０、１２１に予め配備しておく。リソースサーバーＢ１２１は認証認可サーバーＡ１１０と異なるセキュリティドメインに属するが、ＪＷＳアクセストークンを検証する公開鍵を保持する。このため、認証認可サーバーＡ１１０が発行したＪＷＳアクセストークンでリソースサーバーＡ１２０が利用可能となる。
【００４６】
次にＪＷＳアクセストークン発行と検証の流れについて、図５を用いて説明する。図５は、ＪＷＳアクセストークン発行と検証のシーケンス図である。本実施例では、複数の認証認可サーバーとの通信を行う場合を表している。クライアント端末１４０が認証認可サーバーＡ１１０と認証認可サーバーＢ１１１の２つの認証認可サーバーと通信を行う。
【００４７】
まず、クライアント端末１４０は認証認可サーバーＡ１１０に対して、トークン発行要求を行う（Ｓ５０１）。ここでトークン発行要求はＪＷＴとして表現される。特にＪＷＴクレーム“ｉａｔ”（Ｉｓｓｕｅｄ  Ａｔ）にはクライアント端末１４０のクライアント日時が使用される。クライアント日時は、ＲＴＣ２３９を基に算出される値であっても良いし、ＣＰＵ２３１が独自にカウントアップする日時情報を基に算出しても良い。
【００４８】
認証認可サーバーＡ１１０は、クライアント端末１４０から受信したトークン発行要求が正規のものか、または有効期限が切れていないか、などの検証を行う（Ｓ５０２）。認証認可サーバーＡ１１０は、有効期限について、“ｅｘｐ”（Ｅｘｐｉｒａｔｉｏｎ  Ｔｉｍｅ）、“ｎｂｆ”（Ｎｏｔ  Ｂｅｆｏｒｅ）、“ｉａｔ”（Ｉｓｓｕｅｄ  Ａｔ）クレームが有効かどうかを確認することによって判定する。具体的には、ＪＷＴ発行日時である“ｉａｔ”が、認証認可サーバーＡ１１０の持つサーバー日時と比較し誤差が一定以内、例えば±３０秒、かどうかによって判定する。この、日時の検証処理によってリプレイ攻撃に対する耐性を高めることが出来る。
【００４９】
次に、認証認可サーバーＡ１１０は、リソースサーバーＡ１２０で有効なＪＷＳアクセストークンの発行処理を行う（Ｓ５０３）。クライアント端末１４０はＳ５０３にて発行されたＪＷＳアクセストークンを受信する。
【００５０】
さらに、図５には別の認証認可サーバーＢ１１１からＪＷＳアクセストークンを取得する流れが記載されている。トークン発行要求の送信処理Ｓ５０４は、発行要求に署名する秘密鍵が異なる以外は認証認可サーバーＡに対するトークン発行要求の送信処理Ｓ５０１と同じ処理となる。同様にトークン発行処理Ｓ５０６は、認証処理サーバーＡが行うトークン発行処理Ｓ５０３と同じ処理となる。
【００５１】
クライアント端末１４０は認証認可サーバーＡから取得したＪＷＳアクセストークン、および認証認可サーバーＢから取得したＪＷＳアクセストークンを用いることで、異なるリソースサーバーにリソース要求を行う（Ｓ５０７）。クライアント端末１４０とリソースサーバー間の処理は図４と同等のため、ここでは省略する。このように、図５は、クライアント端末１４０が任意のタイミングで、複数の認証認可サーバーと通信出来ることを示している。
【００５２】
図５ではクライアント端末１４０のクライアント日時、および認証認可サーバーＡ１１０と認証認可サーバーＢ１１１それぞれの持つサーバー日時の同期が取れており、ＪＷＴ検証処理Ｓ５０２、Ｓ５０５で日時に関する検証が成功する場合を示した。一方で、これらのクライアントサーバ間で日時の同期が取れていないことも考えられる。そこで、クライアント端末１４０のクライアント日時が絶対日時と同期が取れていない場合の一例について、図６を用いて説明する。
【００５３】
まず、クライアント端末１４０は認証認可サーバーＡ１１０に対して１回目のトークン発行要求を行う（Ｓ６０１）。この１回目のトークン発行要求は図５のトークン発行要求（Ｓ５０１）と同様の処理であるため、詳細は省略する。
【００５４】
次に認証認可サーバーＡ１１０は、Ｓ６０１にて受信したトークン発行要求の正当性検証を行う（Ｓ６０２）。ここで、クライアント端末１４０のクライアント日時と認証認可サーバーＡ１１０のサーバー日時間に差異があると仮定しているため、ＪＷＴ発行日時“ｉａｔ”がサーバー日時に比べ既定の差異よりも大きいこととなる。認証認可サーバーＡ１１０は、ＪＷＴ発行日時“ｉａｔ”がサーバー日時に対して差異が大きすぎるため、クライアント端末１４０に対して、検証処理エラーを返す。認証認可サーバーＡ１１０は、クライアント端末１４０に対して、単にエラーを返すだけでなく、自身のサーバー日時も返すようにする。
【００５５】
クライアント端末１４０は、Ｓ６０２にて検証処理に失敗した旨を知ると共に、認証認可サーバーＡ１１０のサーバー日時を受信する。クライアント端末１４０は、受信したサーバー日時を自身のクライアント日時として設定する（Ｓ６０３）。クライアント日時の記憶先として、ＲＡＭ２３２内に記憶しＣＰＵ２３１がカウントアップする方式でも良いし、ＲＴＣ２３９に直接設定する方式であっても良い。
【００５６】
続いて、クライアント端末１４０は認証認可サーバーＡ１１０に対して２回目のトークン発行要求を行う。２回目のトークン発行要求は、１回目のトークン発行要求と同様の処理であるが、発行要求に含めるＪＷＴ発行日時“ｉａｔ”が、認証認可サーバーＡ１１０のサーバー日時基づくものである点が異なる。なお、２回目のトークン発行要求に用いられる内容は、単にＪＷＴ発行日時“ｉａｔ”が異なるだけではなく、その他のクレームおよび署名結果が異なっても良い。
【００５７】
認証認可サーバーＡ１１０は、２回目のトークン発行要求に用いられたＪＷＴの検証を行う（Ｓ６０４）。２回目のトークン発行要求に用いられたＪＷＴのＪＷＴ発行日時“ｉａｔ”は、自身のサーバー日時に基づくものであるから、検証に成功する。以降の処理、Ｓ６０５とＳ６０６は、図５のＳ５０３、Ｓ５０７と同様の処理であるから、詳細は省略する。
【００５８】
以上、図６の処理方式であれば、仮にクライアント端末１４０のクライアント日時に誤差がある場合であっても、クライアント日時が再び誤差が生じないとすれば、２回目以降のトークン発行要求でＪＷＳアクセストークンが取得可能となる。
【００５９】
しかし、図６の方式を採用すると、複数の認証認可サーバーからＪＷＳアクセストークンを取得する場合に、過剰なトークン発行要求を出してしまうという問題が発生する場合がある。問題となる場合の処理の一例を、図７を用いて説明する。図７では認証認可サーバーＡ１１０、認証認可サーバーＢ１１１のサーバー日時が絶対日時に対して誤差があるものとする。
【００６０】
クライアント端末１４０は、認証認可サーバーＡ１１０に対して１回目のトークン発行要求を行う。この処理は図６のＳ６０１、Ｓ６０２、Ｓ６０３の同様の処理である。このような、ＪＷＴ検証処理Ｓ６０２に失敗し、認証認可サーバーＡ１１０がクライアント端末１４０に対して自身のサーバー日時を返す処理を、認証認可サーバーＡ１１０に対するトークン発行要求（Ｓ７０１）と呼ぶ。
【００６１】
同様に、クライアント端末１４０は、認証認可サーバーＢ１１１に対しても１回目のトークン発行要求を行う。前提では認証認可サーバーＢ１１１のサーバー日時は絶対日時に対して誤差が無い。しかし、認証認可サーバーＡ１１０のサーバー日時を用いたクライアント日時設定処理Ｓ６０３によって、クライアント端末１４０のクライアント日時は誤差を持っている。そのため、認証認可サーバーＢに対するトークン発行要求はＪＷＴ発行日時“ｉａｔ”が原因でＪＷＴ検証処理（Ｓ６０２）に失敗する。その結果、クライアント端末１４０はクライアント日時として認証認可サーバーＢから送られてきた日時を設定する。
【００６２】
続いて、クライアント端末１４０は再び認証認可サーバーＡ１１０にトークン発行要求を行う（Ｓ７０３）。この処理は、クライアント端末１４０のクライアント日時が認証認可サーバーＢ１１１と同期してしまっているため、誤差を含む認証認可サーバーＢ１１１のサーバー日時に基づいたＪＷＴ発行日時“ｉａｔ”が原因でＪＷＴ検証処理Ｓ６０２エラーとなる。
【００６３】
以降は、タイミングによってはＳ７０３とＳ７０４が繰り返されることとなり、過剰なトークン発行要求を出してしまう恐れがある。過剰なトークン発行要求は認証認可サーバーの負荷を増大させることになり、パフォーマンス劣化および管理保守コストの増大に繋がる。
【００６４】
検証に成功するトークン発行要求処理（Ｓ７０５）は、図６の２回目のアクセストークン発行要求（Ｓ６０３）と同様の処理のため詳細は省略する。加えて、リソースサーバーとの通信処理（Ｓ７０６）は図６にあるリソースサーバーとの通信処理（Ｓ６０６）と同様のため詳細は省略する。
【００６５】
図７では１回目のトークン発行要求と２回目のトークン発行要求の間に他の処理が割り込める状態であった。しかし、１回目のトークン発行要求と２回目のトークン発行要求の間に、他の処理が割り込めないようにミューテックスロック等を行ったとしても、毎回サーバー日時取得のための余分なトークン発行要求を出してしまう問題は残る。
【００６６】
以上、図７によって、単に認証認可サーバーから取得した日時をクライアント日時に設定するだけでは過剰なトークン発行要求を出してしまうという問題が発生する場合があることを示した。
【００６７】
このような余分なトークン発行要求を出さない方式を、図８を用いて説明する。図８は、図６と図７のＪＷＳアクセストークン発行と検証の処理を踏襲している。その差異について説明する。まず、クライアント端末１４０が認証認可サーバーＡ１１０から取得したサーバー日時と自身のクライアント日時から日時オフセットを算出、および記憶する（Ｓ８０１）。クライアント端末１４０は同様の処理を認証認可サーバーＢ１１１に対しても行う（Ｓ８０２）。
【００６８】
これらの日時オフセット記憶処理は、認証認可サーバー連携クライアント３４１の管理する日時オフセット記憶領域３４４に記憶される。また、日時オフセット記憶領域３４４は単一の日時オフセットを記憶するものではなく、認証認可サーバーごとに日時オフセットを記憶する領域が確保される。すなわち、認証認可サーバーＡ１１０のサーバー日時に基づいて算出した日時オフセットと、認証認可サーバーＢ１１１のサーバー日時に基づいて算出した日時オフセットは互いに上書きされることなく、異なる領域に記憶される。また、各日時オフセットは認証認可サーバー毎に関連付けられて記憶される。日時オフセットは、返信されたサーバー日時からサーバー日時受信時のクライアント日時を差し引いた値とする。
【００６９】
さらに別の差異として、クライアント端末１４０は、認証認可サーバーＡ１１０に対する２回目のトークン発行要求を行う前に、トークン発行要求に含まれるＪＷＴ発行日時“ｉａｔ”クレームの値の推定を行う（Ｓ８０３）。同様に、クライアント端末１４０は、認証認可サーバーＢ１１１に対する２回目のトークン発行要求前にＪＷＴ発行日時“ｉａｔ”クレームの値の推定を行う（Ｓ８０４）。ＪＷＴ作成日時推定処理（Ｓ８０３，Ｓ８０４）は、Ｓ８０１およびＳ８０２の日時オフセット記憶処理で記憶した日時オフセットに、クライアント端末１４０のクライアント日時を足すことによって、ＪＷＴ作成日時を推定する。
【００７０】
２回目のトークン発行要求（Ｓ６０３）は、図６の処理と同等のため詳細を省略する。同様に、リソースサーバーとの通信処理（Ｓ８０５）も図６の処理と同等のため詳細を省略する。以上、図８のＪＷＳアクセストークン発行と検証の処理によれば、１回目と２回目のトークン発行要求の間に、別の認証認可サーバー向けのトークン発行処理が割り込んだとしても、サーバー日時取得のための要求を高々１回に抑えることができる。
【００７１】
なお、図８の例では、認証認可サーバーＡ１１０、認証認可サーバーＢ１１１ともトークン発行要求に対する応答としてサーバー日時を送信しているが、トークン発行要求の検証に成功した場合は図５のＳ５０３およびＳ５０６に示す通りＪＷＳアクセストークンを送信する。その場合、クライアント端末１４０は日時オフセットを算出し、記憶することは行わない。２回目以降のトークン発行要求を行う場合、日時オフセットが記憶されていない場合は図５に示す通りクライアント端末１４０に設定されている日時を利用し、日時オフセットが記憶されている場合はＪＷＴ作成日時推定処理を行う。なお、２回目以降のトークン発行要求は、ＪＷＳアクセストークンの有効期限が切れた場合に行われる。
【００７２】
図９を用いて、図８で説明したＪＷＳアクセストークン発行と検証の処理のフローについて、実際の日時の値を用いて動作を具体的に説明する。図９ではクライアント端末１４０と、各認証認可サーバーの日時、および時間経過を表すために、３つの時間的なスナップショットを記載している。より正確に言えば、認証認可サーバーにリクエストを出してからレスポンスが到着するまでには時間経過が発生する。しかし、図９では、時間経過が無視できる程度に短いものとして考慮していない。ただし、例えばリクエストが到着するまで数百ミリ秒といった、時間経過が無視できない場合には、リクエスト送信直前のクライアント日時とレスポンス受信時点のクライアント日時の平均値を、２回目のトークン発行要求に使用してもよい。また、図９の例ではＪＷＴ発行日時“ｉａｔ”と認証認可サーバーのサーバー日時間の誤差が３０秒を超える場合にエラーを返すものとする。
【００７３】
まず、スナップショット１の状態の処理について説明する。クライアント端末１４０は、認証認可サーバーＡ１１０に対して１回目のトークン発行要求を出す（Ｓ９０１）。この時、クライアント端末１４０は、サーバーＡ用日時オフセットが設定されていないことから、認証リクエストＳ９０１に含まれるＪＷＴ発行日時“ｉａｔ”に、クライアント日時［１２：００：５０］を設定する（Ｓ９０１）。
【００７４】
次に、認証認可サーバーＡ１１０はクライアント端末１４０から受信したリクエストに含まれるＪＷＴの検証を行う。サーバーＡ日時［１２：０１：３０］とＪＷＴ発行日時“ｉａｔ”に設定された日時［１２：００：５０］間には４０秒の差異があり規定の秒数を超えるため、認証認可サーバーＡはエラーとして認証レスポンスを返信する（Ｓ９０２）。この時、認証認可サーバーＡは認証レスポンスに自身のサーバー日時［１２：０１：３０］を含める。
【００７５】
クライアント端末１４０は、Ｓ９０２にて受信した認証レスポンスのサーバー日時［１２：０１：３０］と自身のクライアント日時［１２：００：５０］から日時オフセット［＋００：００：４０］を算出する。クライアント端末１４０は、算出した日時オフセット［＋００：００：４０］を認証認可サーバーＡ１１０に対応する日時オフセットである、サーバーＡ用日時オフセットとして格納する。ここで、サーバーＡ用日時オフセットは日時オフセット記憶領域３４４内に記憶されるものとする。
【００７６】
続いて、スナップショット１から４０秒経過後のスナップショット２における処理の流れについて説明する。スナップショット２ではクライアント端末１４０が認証認可サーバーＡ１１０に対して２回目のトークン発行要求を出す前に、認証認可サーバーＢ１１１に対して通信しようとする状態を表している。
【００７７】
クライアント端末１４０は、認証認可サーバーＢに対して、サーバーＢ用日時オフセットが未設定であることからＪＷＴ発行日時“ｉａｔ”に自身のクライアント日時［１２：０１：３０］とした認証リクエストを送信する（Ｓ９０４）。
【００７８】
認証認可サーバーＢ１１１は、受信した認証リクエスト内のＪＷＴ発行日時“ｉａｔ”［１２：０１：３０］と自身のサーバー日時［１２：０２：５０］との間に、差異が８０秒あることを確認する。その結果、既定の秒数を超えるため、エラーとして認証レスポンスをクライアント端末１４０に返信する（Ｓ９０５）。
【００７９】
クライアント端末１４０は認証レスポンスに含まれる認証レスポンスのサーバー日時［１２：０２：５０］と自身のクライアント日時［１２：０１：３０］から日時オフセット［＋００：０１：２０］を算出する。クライアント端末１４０は、算出した日時オフセット［＋００：００：４０］を認証認可サーバーＡ１１０に対応する日時オフセットである、サーバーＢ用日時オフセットとして日時オフセット記憶領域３４４に格納する。
【００８０】
スナップショット３では、クライアント端末１４０が認証認可サーバーＡに対して２回目のトークン発行要求を行う（Ｓ９０８）。クライアント端末１４０はＳ９０８で送信する認証リクエスト内のＪＷＴ発行日時“ｉａｔ”の算出のためにＪＷＴ作成日時推定処理Ｓ８０３を行う（Ｓ９０７）。具体的にはクライアント端末１４０のクライアント日時［１２：０２：１０］に送信対象となるサーバーＡ用の日時オフセット［＋００：００：４０］を加算することで、ＪＷＴ作成推定日時［１２：０２：５０］を得る。
【００８１】
認証認可サーバーＡ１１０は、Ｓ９０８にて送信された認証リクエストを受信し、認証リクエスト内のＪＷＴ発行日時“ｉａｔ”と自身のサーバー日時を比較する。ここでは、ＪＷＴ発行日時“ｉａｔ”［１２：０２：５０］と自身のサーバー日時［１２：０２：５０］に差はないことから、ＪＷＴ検証処理Ｓ６０４は成功する。
【００８２】
認証認可サーバーＡ１１０はクライアント端末１４０に対してＪＷＳアクセストークンを含む認証レスポンスを返信する（Ｓ９０９）。クライアント端末１４０はＳ９０９にて受信したＪＷＳアクセストークンを使用することで、ＪＷＳアクセストークンのスコープに対応するリソースサーバーに対してリソース要求を行えるようになる。
【００８３】
また、本実施例ではＪＷＳアクセストークン取得に係る処理を記載した。しかし、ＪＷＳアクセストークン取得に係る処理だけではなく、認証認可サーバーに対してＪＷＴ発行日時“ｉａｔ”を含むＪＷＴを送信する他の処理についても同様の方法を適用してもよい。例えばＯＡｕｔｈ２．０のクライアントのクライアントＩＤおよびクライアントシークレットを、認証認可サーバーが発行する場合、ＪＷＴ発行日時“ｉａｔ”の検証処理は、ＪＷＳアクセストークン発行と同様に行う。このクライアントＩＤおよびクライアントシークレット発行時に同様の方式を適用してもよい。
【００８４】
以上より、クライアント端末１４０は、複数の認可サーバーと通信する場合に、認可サーバーとの日時オフセットをクライアント端末１４０が適切に管理し、認可サーバーへの日時取得のための問い合わせを最小限にすることが出来る。結果、パフォーマンス劣化とサーバー負荷を低減することが出来る。
【００８５】
［実施例２］
実施例１において、複数の認可サーバーと通信する場合に、認可サーバーの日時をクライアント端末１４０が個別に管理することで、日時取得のための問い合わせを最小限にする方法を示した。
【００８６】
実施例１の方式では、日時取得のための問い合わせが、認証認可サーバーの日時に追加の誤差が発生しなければ、高々１回で済む。ところで、同じ地域のデータセンターや同じＬＡＮ内に存在する認証認可サーバーは、似通った日時同期、例えば同じＮＴＰサーバーに同期、を行っている可能性が高い。しかし、実施例１の方式では、このような場合でも、クライアント日時またはサーバー日時に差異があった場合は、最低でも１回、日時取得のための問い合わせをしてしまう。
【００８７】
図１０を用いて、このような課題を解決するための、グルーピングを伴うＪＷＳアクセストークン発行と検証について説明する。なお、説明を省略する部分については実施例１と同様の構成である。
【００８８】
まず、クライアント端末１４０は、自身が通信する予定の認証認可サーバー群を、特定の特徴に基づいてグルーピングし、その結果を初期グループとする（Ｓ１００１）。初期グループ決定処理Ｓ１００１について図１１を用いて詳細に説明する。クライアント端末１４０は、グルーピングの済んでいる認証認可サーバーがあるかチェックする（Ｓ１１０１）。もしグルーピングが未決定の認証認可サーバーがあった場合、Ｓ１１０２に遷移する。一方で全ての認証認可サーバーのグルーピングが終わった場合、繰り返し処理を抜け、本処理から戻る。
【００８９】
クライアント端末１４０は、既にグループが存在するかチェックする。もし既にグループが作られていた場合Ｓ１１０３に遷移する。一方で、まだグループが作られていなかった場合Ｓ１１０４に遷移する（Ｓ１１０２）。
【００９０】
クライアント端末１４０は、グルーピング対象の認証認可サーバーが、既に決定済みのグループと共通の特徴を持つかどうか判定する。ここで特定の特徴とは、例えばトークン発行要求の際に送信するＪＷＴの署名用証明書が共通である、および／またはＦＱＤＮの親ドメインが共通するかどうかなどを特徴としている。それらが共通する認証認可サーバー同士は同じグループとなる。もし、クライアント端末１４０が共通の特徴を持つグループがあると判定した場合、Ｓ１１０５に遷移する。一方で、共通の特徴を持つグループが無いと判定した場合Ｓ１１０４に遷移する（Ｓ１１０３）。
【００９１】
クライアント端末１４０は、Ｓ１１０３にて共通の特徴を持つグループがあると判定した場合、該グループにグルーピング中の認可認証サーバーを追加する（Ｓ１１０５）。クライアント端末１４０は、Ｓ１１０２、Ｓ１１０３のいずれにも該当しなかった場合、グルーピング中の認証認可サーバーを唯一のサーバーとする、新規グループを作成する（Ｓ１１０４）。
【００９２】
図１０に戻り、クライアント端末１４０は初期グループ決定後、認証認可サーバーＡにトークン発行要求を行う。図１０では、認証認可サーバーＡ１１０および認証認可サーバーＢ１１１が同じグループに入ったものとする。また、発行要求Ｓ６０１および認証認可サーバーＡ１１０のＪＷＴ検証処理Ｓ６０２は既に説明済みのため詳細を省略する。
【００９３】
クライアント端末１４０は、認証認可サーバーＡ１１０のエラーレスポンスに含まれるサーバー日時とクライアント日時から日時オフセットを算出する。クライアント端末１４０は算出した日時オフセットを認証認可サーバーＡ１１０の属するグループに対応する日時オフセット記憶領域３４４に記録する（Ｓ１００２）。
【００９４】
続いてクライアント端末１４０は、認証認可サーバーＢ１１１に対して、１回目のトークン発行要求を行う。ここで、クライアント端末１４０は、トークン発行要求に含まれるＪＷＴ発行日時“ｉａｔ”に、認証認可サーバーＢ１１１の属するグループに対応する日時オフセット記憶領域３４４から取得した日時オフセットを設定する（Ｓ１００３）。
【００９５】
前提として認証認可サーバーＡ１１０と認証認可サーバーＢ１１１は、初期グループ決定処理Ｓ１００１にて同じグループに属すと決定しているため、Ｓ１００２では認証認可サーバーＡ１１０が返信したサーバー日時に基づく日時オフセットが使用される。ここで、認証認可サーバーＡ１１０と認証認可サーバーＢ１１１のサーバー日時が同期しているかどうかに依存して、２つのフローに分かれる。もし、ＪＷＴ発行日時“ｉａｔ”とサーバー日時の差異が既定時間内である場合、認証認可サーバーＢ１１１はＪＷＴ検証処理Ｓ６０２で検証に成功するためＪＷＳアクセストークンを返却する。
【００９６】
一方で、ＪＷＴ発行日時“ｉａｔ”とサーバー日時の差異が既定時間外だった場合、認証認可サーバーＢ１１１はＪＷＴ検証処理Ｓ６０２にて、ＪＷＴ発行日時“ｉａｔ”が原因で検証に失敗する。クライアント端末１４０は、受信したエラーレスポンスに含まれるサーバー日時と自身のクライアント日時から日時オフセットを算出する。この時、既に存在するグループに対応する日時オフセットの中で、算出した日時オフセットと最も日時オフセットの値が近いものを探す。
【００９７】
最も値が近かった日時オフセットと、算出した日時オフセットの値の差異が最大誤差時間以下だった場合、クライアント端末１４０は最も値が近かった日時オフセットに対応するグループに認証認可サーバーＢ１１１を追加する。すなわち、元々は認証認可サーバーＡ１１０のグループに属していた認証認可サーバーＢ１１１のグループが変更される。
【００９８】
追加すべきグループが無かった場合、クライアント端末１４０は、認証認可サーバーＢ１１１を唯一含む、新規のグループを作成する。ここで、最大誤差時間は既定の定数であってもよいし、認証認可サーバーのＪＷＴ検証処理（Ｓ６０２）にて判定に用いられるＪＷＴ発行日時“ｉａｔ”とサーバー日時の許容誤差時間であってもよい。
【００９９】
次に、図１２を用いて図１０で説明したＪＷＳアクセストークン発行と検証の処理のフローについて、実際の日時と値を用いて、動作を具体的に説明する。図１２では、初期には異なるグループに属する認証認可サーバー群が、実際の通信で動的に１つのグループに合成される例を示す。前提として、認証認可サーバーＡ１１０はグループＡに属し、認証認可サーバーＢ１１１はグループＢに属し、かつ認証認可サーバーＡ１１０と認証認可サーバーＢ１１１は互いに同期が取れており、クライアント日時のみ同期が取れていないものとする。
【０１００】
スナップショット１においてＳ９０１、Ｓ９０２は図９と同一の処理のため詳細を省略する。クライアント端末１４０は、クライアント日時［１２：００：５０］とＳ９０２にて返信されたサーバー日時［１２：０１：３０］から日時オフセット［＋００：００：４０］を算出する。クライアント端末１４０は、認証認可サーバーＡ１１０に対応するグループＡ用日時オフセットとして日時オフセット［＋００：００：４０］を記憶する（Ｓ１２０１）。
【０１０１】
続いてスナップショット２では、クライアント端末１４０が、認証認可サーバーＢ１１１に対してトークン発行要求を行う。前提として認証認可サーバーＡ１１０と認証認可サーバーＢ１１１は同じサーバー日時となっているため、ＪＷＴ検証処理（Ｓ６０２）は失敗する。結果、認証認可サーバーＢ１１１はエラーレスポンスと共に自身のサーバー日時をクライアント端末１４０に返信する。
【０１０２】
クライアント端末１４０は、返信されたサーバー日時と自身のクライアント日時から日時オフセットを算出し、最も近しいかつ、差異が最大誤差時間以下のグループ用日時オフセットを持つグループを探す。図１２では前提として認証認可サーバーＡ１１０と認証認可サーバーＢ１１１は同じサーバー日時となっているため、グループＡ用日時オフセットが該当する。
【０１０３】
クライアント端末１４０は、該当したグループＡに認証認可サーバーＢ１１１を移動させ、空となったグループＢは削除する（Ｓ１２０２）。
【０１０４】
スナップショット３では、クライアント端末１４０が認証認可サーバーＢに対して２回目のトークン発行要求を行う。認証認可サーバーＢの対応付けは、グループＢからグループＡに移動したため、クライアント端末１４０はグループＡ用日時オフセット［＋００：００：４０］と自身のクライアント日時［１２：０１：３０］からＪＷＴ作成推定日時［１２：０２：５０］を得る（Ｓ１２０３）。
【０１０５】
その後、クライアント端末１４０はＳ１２０３で取得したＪＷＴ作成推定日時［１２：０２：５０］を用いて２回目のトークン発行要求を行う。認証認可サーバーＢはＪＷＴ検証処理（Ｓ６０２）にて、自身のサーバー日時［１２：０２：５０］とクライアント端末１４０から受信した認証リクエストに含まれるＪＷＴ作成推定日時［１２：０２：５０］が許容誤差日時以内であることからＪＷＳアクセストークンを発行する。
【０１０６】
このように、初期グループ決定処理（Ｓ１００１）で決定した初期グループに問題があった場合でも動的にグルーピングし直すことによって、日時同期が取れていると推測される認証認可サーバー群を同一のグループにすることが出来る。
【０１０７】
以上、実施例２によれば、初期に日時同期が取れていると推測されるサーバー群をグルーピングしグループに対応する日時オフセットを用いて日時を推定することで、不要な日時取得のための問い合わせを減らすことが出来る。さらに、動的にグルーピングをし続けることで環境の変化に応じて、適したグループ構成を維持することが出来る。
【０１０８】
［その他の実施例］
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【０１０９】
１１０  認証認可サーバーＡ
１１１  認証認可サーバーＢ
１２０  リソースサーバーＡ
１２１  リソースサーバーＢ
１４０  クライアント端末
【図１】
2020009259.tif 000004
【図２】
2020009259.tif 000005
【図３】
2020009259.tif 000006
【図４】
2020009259.tif 000007
【図５】
2020009259.tif 000008
【図６】
2020009259.tif 000009
【図７】
2020009259.tif 000010
【図８】
2020009259.tif 000011
【図９】
2020009259.tif 000012
【図１０】
2020009259.tif 000013
【図１１】
2020009259.tif 000014
【図１２】
2020009259.tif 000015