特許 6983685 情報処理システム、クライアント装置、認証認可サーバー、制御方法とそのプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6983685

(24)【登録日】2021年11月26日

(45)【発行日】2021年12月17日

(54)【発明の名称】情報処理システム、クライアント装置、認証認可サーバー、制御方法とそのプログラム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20211206BHJP

   G06F 21/33 20130101ALI20211206BHJP

【ＦＩ】

   H04L9/00 675B

   G06F21/33

【請求項の数】20

【全頁数】19

(21)【出願番号】特願2018-15726(P2018-15726)

(22)【出願日】2018年1月31日

(65)【公開番号】特開2019-134333(P2019-134333A)

(43)【公開日】2019年8月8日

【審査請求日】2021年1月27日

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100126240

【弁理士】

【氏名又は名称】阿部 琢磨

(74)【代理人】

【識別番号】100124442

【弁理士】

【氏名又は名称】黒岩 創吾

(72)【発明者】

【氏名】遠藤 健太

【審査官】 中里 裕正

(56)【参考文献】

【文献】 特開２０１３−２３８９６５（ＪＰ，Ａ）

【文献】 特開２０１０−４９４２０（ＪＰ，Ａ）

【文献】 特表２０１７−５０４８５６（ＪＰ，Ａ）

【文献】 特開２００４−１３３７４（ＪＰ，Ａ）

【文献】 特開２００８−３３５８３（ＪＰ，Ａ）

【文献】 特開２０１２−３８２５５（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１７／０１３４４２９（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／３３

(57)【特許請求の範囲】

【請求項1】

リソースサーバーにアクセスするための認可トークンを発行する認証認可サーバーに対する要求に、暗号鍵を用いて署名を付与するクライアント端末と、
前記クライアント端末からの要求に付与された署名を、復号鍵を用いて検証する認証認可サーバーと、を含む情報処理システムであって、
前記クライアント端末は、
前記認可トークンを取得するための要求である認可トークン要求を、前記署名が発行された時刻を含めて前記認証認可サーバーに送信する送信手段と、
前記認可トークン要求に対する応答を受信し、検証する検証手段と、
前記認証認可サーバーは、
前記送信手段によって送信された認可トークン要求に含まれる前記署名の発行時刻と、
前記認証認可サーバーにおける時刻と、が一定以上の時間差があるかを判定する判定手段と、
前記判定手段における判定に基づいて、前記認可トークン要求に対する前記応答として、前記認証認可サーバーにおける時刻を含めたエラー、または前記認可トークンを応答する応答手段と、
を有し、
前記送信手段によって送信された第一の認可トークン要求に含まれる前記署名の発行時刻と、前記認証認可サーバーにおける時刻とが、前記判定手段によって一定以上の時間差があると判定された場合、
前記応答手段は、前記認証認可サーバーにおける時刻を含めたエラーを前記クライアント端末に応答し、
前記検証手段によって、前記エラーに前記認証認可サーバーにおける時刻が含まれていると検証された場合、
前記送信手段は、前記認証認可サーバーにおける時刻を含めた第二の認可トークン要求を送信する前記認証認可サーバーに送信する情報処理システム。

【請求項2】

前記判定手段によって、前記第二の認可トークン要求に含まれる前記署名の発行時刻と、前記認証認可サーバーにおける時刻とが、一定以上の時間差があると判定されなかったことに伴い、
前記応答手段は、
前記認可トークンを前記クライアント端末に応答することを特徴とする請求項１に記載の情報処理システム。

【請求項3】

前記検証手段は、
前記応答に前記認可トークンが含まれているかを検証し、
前記検証手段によって、前記認可トークンが含まれていないと検証された場合に、
前記応答に前記認証認可サーバーにおける時刻が含まれているかを検証し、
前記認証認可サーバーにおける時刻が含まれていると検証された場合に、
前記認証認可サーバーにおける時刻を含めた第二の認可トークン要求を送信することを特徴とする請求項１または２に記載の情報処理システム。

【請求項4】

前記クライアント端末は、
前記エラーに含まれた前記認証認可サーバーにおける時刻と、前記クライアント端末における時刻との時間差を管理する管理手段を更に有し、
前記管理手段によって管理されている時間差に基づいて補正した、前記発行時刻を含めた第三の認可トークン要求を前記認証認可サーバーに送信することを特徴とする請求項１乃至３のいずれか一項に記載の情報処理システム。

【請求項5】

前記認証認可サーバーは、
前記認可トークン要求に含まれる情報と署名に基づいてハッシュ値を算出し、保持する保持手段を更に有し、
前記クライアント端末から受信した認可トークン要求に含まれる情報と署名とに基づいてハッシュ値を算出し、算出されたハッシュ値が前記保持手段によって保持されたハッシュ値に含まれているかを判定し、
含まれていると判定された場合は前記エラーを送信することを特徴とする請求項１乃至４のいずれか一項に記載の情報処理システム。

【請求項6】

前記保持手段によって保持されたハッシュ値は、
前記判定手段によって、前記認可トークン要求に含まれる署名の発行時刻と、前記認証認可サーバーにおける時刻とが一定以上の差があると判定された場合に、前記認可トークン要求に含まれる情報と署名とに基づいて算出されることを特徴とする請求項５に記載の情報処理システム。

【請求項7】

前記保持手段は、
前記署名の有効期限を保持し、前記有効期限が過ぎた署名のハッシュ値を削除することを特徴とする請求項５または６に記載の情報処理システム。

【請求項8】

リソースサーバーにアクセスするための認可トークンを発行する認証認可サーバーに対する要求に、暗号鍵を用いて署名を付与するクライアント端末と、
前記クライアント端末からの要求に付与された署名を、復号鍵を用いて検証する認証認可サーバーと、を含む情報処理システムの制御方法であって、
前記クライアント端末は、
前記認可トークンを取得するための要求である認可トークン要求を、前記署名が発行された時刻を含めて前記認証認可サーバーに送信する送信ステップと、
前記認可トークン要求に対する応答を受信し、検証する検証ステップと、
前記認証認可サーバーは、
前記送信ステップによって送信された認可トークン要求に含まれる前記署名の発行時刻と、前記認証認可サーバーにおける時刻とが一定以上の差があるかを判定する判定ステップと、
前記判定ステップにおける判定に基づいて、前記認可トークン要求に対する前記応答として、前記認証認可サーバーにおける時刻を含めたエラー、または前記認可トークンを応答する応答ステップと、
を有し、
前記送信ステップによって送信された第一の認可トークン要求に含まれる前記署名の発行時刻と、前記認証認可サーバーにおける時刻とが、前記判定ステップによって一定以上の差があると判定された場合、
前記応答ステップは、前記認証認可サーバーにおける時刻を含めたエラーを前記クライアント端末に応答し、
前記検証ステップによって前記エラーに、前記認証認可サーバーにおける時刻が含まれていると検証された場合、
前記送信ステップは、前記認証認可サーバーにおける時刻を含めた第二の認可トークン要求を送信する前記認証認可サーバーに送信する情報処理システムの制御方法。

【請求項9】

リソースサーバーにアクセスするための認可トークンを発行する認証認可サーバーに対する要求に、暗号鍵を用いて署名を付与するクライアント端末であって、
前記認可トークンを取得するための要求である第一の認可トークン要求を、前記署名が発行された発行時刻を含めて前記クライアント端末が前記認証認可サーバーに送信する送信手段と、
前記送信手段によって送信された第一の認可トークン要求に対する応答を前記認証認可サーバーから受信する受信手段と、を有し、
前記受信手段によって受信した応答がエラーであった場合、
前記送信手段は、
前記エラーと共に受信した、前記認証認可サーバーにおける時刻を含めた第二の認可トークン要求を送信するクライアント端末。

【請求項10】

前記クライアント端末は、
前記認証認可サーバーから前記認可トークンを受信する第二の受信手段を更に有し、
前記第二の受信手段によって受け付けた認可トークンを前記リソースサーバーに送信することで、前記リソースサーバーが提供するサービスを利用することを特徴とする請求項９に記載のクライアント端末。

【請求項11】

前記クライアント端末は、
前記認証認可サーバーから受信した認可トークン要求を検証する検証手段を更に有し、
前記検証手段は、
前記応答に前記認可トークンが含まれているかを検証し、
前記認可トークンが含まれていないと検証された場合に、
前記応答に前記認証認可サーバーにおける時刻が含まれているかを検証し、
前記認証認可サーバーにおける時刻が含まれていると検証された場合に、
前記認証認可サーバーにおける時刻を含めた第二の認可トークン要求を送信することを特徴とする請求項９または１０に記載のクライアント端末。

【請求項12】

前記クライアント端末は、
前記受信手段によって受信した前記認証認可サーバーにおける時刻と、前記クライアント端末における時刻との時間差を管理する管理手段を更に有し、
前記管理手段によって管理されている時間差に基づいて補正した前記発行時刻を含めた第三の認可トークン要求を前記認証認可サーバーに送信することを特徴とする請求項９乃至１１のいずれか一項に記載のクライアント端末。

【請求項13】

リソースサーバーにアクセスするための認可トークンを発行する認証認可サーバーに対する要求に、暗号鍵を用いて署名を付与するクライアント端末の制御方法であって、
前記認可トークンを取得するための要求である第一の認可トークン要求を、前記署名が発行された発行時刻を含めて前記クライアント端末が前記認証認可サーバーに送信する送信ステップと、
前記送信ステップによって送信された第一の認可トークン要求に対する応答を前記認証認可サーバーから受信する受信ステップと、を有し、
前記受信ステップによって受信した応答がエラーであった場合、
前記送信ステップは、
前記エラーと共に受信した、前記認証認可サーバーにおける時刻を含めた第二の認可トークン要求を送信するクライアント端末の制御方法。

【請求項14】

コンピュータを、
リソースサーバーにアクセスするための認可トークンを発行する認証認可サーバーに対する要求に、暗号鍵を用いて署名を付与するクライアント端末として機能させるためのプログラムであって、
前記認可トークンを取得するための要求である第一の認可トークン要求を、前記署名が発行された発行時刻を含めて前記クライアント端末が前記認証認可サーバーに送信する送信手段と、
前記送信手段によって送信された第一の認可トークン要求に対する応答を前記認証認可サーバーから受信する受信手段と、を有し、
前記受信手段によって受信した応答がエラーであった場合、
前記送信手段は、
前記エラーと共に受信した、前記認証認可サーバーにおける時刻を含めた第二の認可トークン要求を送信するクライアント端末として機能させるためのプログラム。

【請求項15】

クライアント端末からの要求に付与された署名を、復号鍵を用いて検証する検証手段と、
リソースサーバーにアクセスするための認可トークンを発行する発行手段と、を有する認証認可サーバーであって、
前記認可トークンを取得するための要求である認可トークン要求に含まれる、前記署名の発行時刻と、前記認証認可サーバーにおける時刻とが一定以上の差があるかを判定する判定手段と、
前記判定手段によって一定以上の差があると判定された場合、
エラーとして前記認証認可サーバーにおける時刻を前記クライアント端末に送信する送信手段と、
を有する認証認可サーバー。

【請求項16】

前記判定手段によって、前記認可トークン要求に含まれる発行時刻と前記認証認可サーバーにおける時刻とが一定以上の差がないと判定された場合、
前記認可トークン要求を送信したクライアント端末に対して前記認可トークンを送信することを特徴とする請求項１５に記載の認証認可サーバー。

【請求項17】

前記認証認可サーバーは、
前記認可トークン要求に含まれる情報と署名に基づいてハッシュ値を算出し、保持する保持手段を更に有し、
前記クライアント端末から受信した認可トークン要求に含まれる情報と署名とに基づいてハッシュ値を算出し、算出されたハッシュ値が前記保持手段によって保持されたハッシュ値に含まれているかを判定し、
含まれていると判定された場合はエラーを送信することを特徴とする請求項１５または１６に記載の認証認可サーバー。

【請求項18】

前記保持手段によって保持されたハッシュ値は、
前記判定手段によって、前記認可トークン要求に含まれる署名の発行時刻と、前記認証認可サーバーにおける時刻とが一定以上の差があると判定された場合に、前記認可トークン要求を用いて算出されることを特徴とする請求項１７に記載の認証認可サーバー。

【請求項19】

クライアント端末からの要求に付与された署名を、復号鍵を用いて検証する検証ステップと、
リソースサーバーにアクセスするための認可トークンを発行する発行ステップと、を有する認証認可サーバーの制御方法であって、
前記認可トークンを取得するための要求である認可トークン要求に含まれる、前記署名の発行時刻と、前記認証認可サーバーにおける時刻と、が一定以上の差があるかを判定する判定ステップと、
前記判定ステップによって一定以上の差があると判定された場合、
エラーとして前記認証認可サーバーにおける時刻を前記クライアント端末に送信する送信ステップと、
を有する認証認可サーバーの制御方法。

【請求項20】

コンピュータを、
クライアント端末からの要求に付与された署名を、復号鍵を用いて検証する検証手段と、
リソースサーバーにアクセスするための認可トークンを発行する発行手段と、を有する認証認可サーバーとして機能させるためのプログラムであって、
前記認可トークンを取得するための要求である認可トークン要求に含まれる、前記署名の発行時刻と、前記認証認可サーバーにおける時刻とが一定以上の差があるかを判定する判定手段と、
前記判定手段によって一定以上の差があると判定された場合、
エラーとして前記認証認可サーバーにおける時刻を前記クライアント端末に送信する送信手段と、
を有する認証認可サーバーとして機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、認可トークンを発行する情報処理システム、クライアント装置、認証認可サーバー、制御方法とそのプログラムに関する。

【背景技術】

【0002】

近年、インターネット上に展開されたクラウドサービスの利用が拡大している。これらクラウドサービスは個々にＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を公開しており、他のアプリケーションからＡＰＩを介してサービスが提供する機能を利用する事ができる。ＡＰＩを呼び出す標準プロトコルでは、認可の連携を実現させるＯＡｕｔｈ２．０の採用が進んでいる。

【0003】

ＯＡｕｔｈ２．０においてクライアントは、リソースサーバーが公開するＡＰＩにアクセスするために、クライアントである事を認証する認証情報を用いて認証認可サーバーから認可トークンを取得する。ＡＰＩへのアクセスは、取得した認可トークンを用いて実現される。

【0004】

クライアントの認証情報を認証認可サーバーに送信する形態としては、クライアントを一意に識別するためのクライアントＩＤおよび秘匿情報であるシークレットを送信する形態と、デジタル証明書によるデジタル署名（以下、アサーション）を用いる形態がある。

【0005】

前者の形態では、クライアントＩＤとシークレットはクライアントの秘匿情報であるため、クライアントと認証認可サーバー間でクライアントの秘匿情報をやりとりすることになる。その秘匿情報が漏洩した場合には、自由に認可トークンを発行できてしまう。

【0006】

一方のアサーションを用いる形態では、クライアントと認証認可サーバー間でやり取りする情報に含まれるのは、秘匿情報ではない署名と公開情報である。暗号鍵（秘密鍵）を有するクライアントのみが、認証認可サーバーに対するリクエストに署名を付与できるため、秘匿情報が漏えいすることなく、認証認可サーバーはクライアントを認証し、認可トークンを発行できる。

【0007】

アサーションは一般にＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ（ＪＷＴ）で表現される。ＪＷＴ形式のアサーションは、発行者の識別子（ｉｓｓ）、ユーザー識別子（ｓｕｂ）、利用を想定する主体の識別子（ａｕｄ）、発行時刻（ｉａｔ）、有効期限（ｅｘｐ）、トークン識別子（ｊｔｉ）などを含む各種情報に対し、署名が付与されている。認証認可サーバーは、署名とそれに含まれる各種情報を検証し、有効なアサーションであると判断した際に認可トークンを発行する。一方で、検証した結果、不正が確認された場合は認可トークン要求元にエラーを返す。

【0008】

このように、アサーションによりクライアントを認証する形態では、クライアントがＪＷＴ形式のアサーションを作成できさえすればいつでも認可トークン要求を認証認可サーバーに送信できる。

【0009】

セキュリティをより高めるために、アサーションに有効期限を設定する形態がある。これは、アサーションを含む認可トークン要求が詐取され、その認可トークン要求を再利用して認可トークンが取得される、いわゆるリプレイアタックを防ぐためである。セキュリティ向上のためには、アサーションの有効期限をできるだけ短く設定することが望ましい。そのため、例えば、アサーションの有効期限とアサーションの発行時刻との差が５分以上であるアサーションを受け付けない形態も考えられる。特許文献１には、電子証明書自身の発行時刻、あるいは有効期限を含む電子証明書の発行方法が開示されている。

【先行技術文献】

【特許文献】

【0010】

【特許文献1】特開２００５−８０１２７

【発明の概要】

【発明が解決しようとする課題】

【0011】

アサーションの有効期限とアサーションの発行時刻との差が設定されているシステムである場合、アサーションの有効期限と発行時刻とが検証の対象となる。その結果、クライアントにおいて設定されたアサーションの発行時刻が、認証認可サーバーにおいて不正であると判定されると、認可トークンが発行されない。不正な発行時刻がクライアントで設定される場合とは具体的に、クライアントに設定されている現在時刻が認証認可サーバーでの現在時刻とずれていたり、クライアントに時計機能が存在しなかったりする場合である。クライアントで設定されている現在時刻に基づいてアサーションの発行時刻が設定されるため、不正な発行時刻がアサーションに設定されることになる。

【0012】

本発明では、クライアント端末で設定されるアサーションの発行時刻が認証認可サーバーの現在時刻と異なる場合でも、アサーションの発行時刻を調整し、クライアント端末に認可トークン要求を再送させることにより、認可トークンを発行する情報処理システムを円滑に運用することを目的とする。

【課題を解決するための手段】

【0013】

リソースサーバーにアクセスするための認可トークンを発行する認証認可サーバーに対する要求に、暗号鍵を用いて署名を付与するクライアント端末と、前記クライアント端末からの要求に付与された署名を、復号鍵を用いて検証する認証認可サーバーと、を含む情報処理システムであって、前記クライアント端末は、前記認可トークンを取得するための要求である認可トークン要求を、前記署名が発行された時刻を含めて前記認証認可サーバーに送信する送信手段と、前記認可トークン要求に対する応答を受信し、検証する検証手段と、前記認証認可サーバーは、前記送信手段によって送信された認可トークン要求に含まれる前記署名の発行時刻と、前記認証認可サーバーにおける時刻とが一定以上の時間差があるかを判定する判定手段と、前記判定手段における判定に基づいて、前記認可トークン要求に対する前記応答として、前記認証認可サーバーにおける時刻を含めたエラー、または前記認可トークンを応答する応答手段と、を有し、前記送信手段によって送信された第一の認可トークン要求に含まれる前記署名の発行時刻と、前記認証認可サーバーにおける時刻とが、前記判定手段によって一定以上の時間差があると判定された場合、前記応答手段は、前記認証認可サーバーにおける時刻を含めたエラーを前記クライアント端末に応答し、前記検証手段によって、前記エラーに前記認証認可サーバーにおける時刻が含まれていると検証された場合、前記送信手段は、前記認証認可サーバーにおける時刻を含めた第二の認可トークン要求を送信する前記認証認可サーバーに送信する。

【発明の効果】

【0014】

本発明により、クライアント端末で設定されるアサーションの発行時刻が認証認可サーバーの現在時刻と異なる場合でも、アサーションの発行時刻を調整し、クライアント端末に認可トークン要求を再送させることにより、認可トークンを発行する情報処理システムを円滑に運用することができる。

【図面の簡単な説明】

【0015】

【図1】情報処理システムの構成図

【図2】情報処理システムを構成する各種装置のハードウェア構成図

【図3】実施例１における、認証認可サーバー１１０でのＪＷＴ形式のアサーションの検証を示したフローチャート

【図4】実施例１における、クライアント端末１３０が認可トークンを取得するフロー

【図5】実施例１における、クライアント端末１３０が認可トークンを取得するフロー

【図6】実施例２における、クライアント端末１３０が認可トークンを取得するフロー

【図7】実施例３における、認証認可サーバー１１０でのＪＷＴ形式のアサーションの検証を示したフローチャート

【図8】ＪＷＴ形式のアサーションに含まれる検証用情報の一例

【図9】各種装置のソフトウェアモジュール構成図

【図10】情報処理システムのクライアント端末１３０が認可トークンを取得するまでのシーケンス図

【発明を実施するための形態】

【0016】

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

【0017】

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

【0018】

本実施例に係る情報処理システムは、図１に示すような構成のネットワーク上で実現される。

【0019】

ＷＡＮ１００（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）は、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されており、ＬＡＮ１０１（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介して各種装置に接続する。各種装置にはクライアント端末１３０、クライアント端末１３０の認証・認可を実現する認証認可サーバー１１０、クライアント端末１３０にサービスを提供するリソースサーバー１２０がある。

【0020】

リソースサーバー１２０が提供するサービスとしては例えば、クライアント端末１３０のデータをバックアップするサービスや、クライアント端末１３０のセンサー情報を分析するサービス等がある。クライアント端末１３０としては具体的に、パソコン、モバイル端末、画像形成装置などの機器が挙げられる。認証認可サーバー１１０はクライアント端末１３０を認証し、認証したクライアント端末から認可トークン要求を受信し、リソースサーバー１２０を利用するために必要な認可トークンを発行する。

【0021】

図１では各種サーバーが１台ずつ設置されている形態を示しているが、物理的な台数や構成は問わず、例えば認証認可サービスシステムとして、認証認可サーバー１１０やリソースサーバー１２０の機能を提供する形態でもよい。また、認証認可サーバー１１０やリソースサーバー１２０の機能を、複数の物理サーバーで実現する形態等でもよい。

【0022】

図２は本実施例に係る、認証認可サーバー１１０、リソースサーバー１２０、クライアント端末１３０を構成する情報処理装置の一般的なハードウェア構成である。なお、図２は一般的な情報処理装置のブロック図であり、本実施形態の各種デバイスには一般的な情報処理装置のハードウェア構成やＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）として提供される情報処理装置の仮想的なハードウェア構成を適用できる。

【0023】

ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳやアプリケーション等のプログラムを実行する。またＣＰＵ２３１は、システムバス２３４に接続される各ブロックを制御する。ここでＯＳとはコンピューター上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。操作部Ｉ／Ｆ２３５は、操作部２３９からの入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。ディスクコントローラ（ＤＫＣ）２３７は各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２３８はＷＡＮ１００もしくはＬＡＮ１０１を介して接続された各種装置との通信制御処理を実行する。

【0024】

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたアプリケーションプログラムである。

【0025】

次に図９を用いて、認証認可サーバー１１０、リソースサーバー１２０、クライアント端末１３０が有する機能について説明する。認証認可サーバー１１０は認証認可サーバー部１１０１、ＨＴＴＰサーバー部１１０２、鍵管理部１１０３を有する。ＨＴＴＰサーバー部１１０２はＷＡＮ１００を介してクライアント端末１３０とリソースサーバー１２０と接続されており、ＨＴＴＰ通信を行う機能である。また、ＨＴＴＰサーバー部１１０２はＳＳＬ／ＴＬＳによる通信が可能であり、不図示の証明書ストアを有する。

【0026】

認証認可サーバー部１１０１はＨＴＴＰサーバー部１１０２を介してＷｅｂブラウザー１３０１からの要求を受信し、受信した要求に対する結果を応答する機能である。具体的には、認可トークン要求をＨＴＴＰサーバー部１１０２がＷｅｂブラウザー１３０１から受信し、認可トークン要求に含まれるアサーションを検証する。検証に成功した場合は認可トークンを生成し、Ｗｅｂブラウザー１３０１に認可トークンを送信する。その際、認証認可サーバー部１１０１は、鍵管理部１１０３は予め管理している復号鍵（公開鍵）を用いて、クライアント端末１３０から受信したアサーションの署名を検証する。

【0027】

認証認可サーバー部１１０１は、生成された認可トークンに署名情報を付与する秘密鍵を保持するように構成する事もできる。その場合は、この秘密鍵を用いて認可トークンに署名情報を付与し、署名情報付きの認可トークンをクライアント端末１３０に対して発行する。

【0028】

リソースサーバー１２０のリソースサーバー部１２０１は、Ｗｅｂサービスを提供するためのＡＰＩを公開する機能である。なお、認証認可サーバー１１０と同様に、ＨＴＴＰサーバー部を備え、ＨＴＴＰサーバー部を介して外部との受送信を実行する形態でもよい。

【0029】

クライアント端末１３０はＷｅｂブラウザー１３０１とクライアントアプリケーション１３０２、認証部１３０３、アサーション生成部１３０４、鍵管理部１３０５、応答検証部１３０６を有する。Ｗｅｂブラウザー１３０１はＷＷＷを利用するためのユーザーエージェントによって実現される機能である。Ｗｅｂブラウザー１３０１はユーザーの操作により、認証認可サーバー１１０およびクライアントアプリケーション１３０２と通信を行う。クライアントアプリケーション１３０２は、リソースサーバー１２０が公開するＡＰＩを実行することで自身が提供する機能と合わせたＷｅｂサービスをユーザーに提供する。

【0030】

認証部１３０３はユーザーを認証するための機能である。ユーザーはクライアント端末１３０の機能を利用するために、クライアント端末１３０における不図示の入力画面においてローカルユーザーＩＤとローカルユーザーパスワードを入力する。入力を受けたクライアント端末１３０は、認証部１３０３において予め登録されている情報（ローカルユーザーＩＤとローカルユーザーパスワード）と入力された情報とを照合することでユーザーの認証処理を行い、ログインコンテキストを生成する。なお認証処理の形態はこれに留まらず、例えば、ＩＣカードを使った認証や指紋等の生体認証でもよい。

【0031】

ログインコンテキストは、クライアント端末１３０でローカルユーザーを識別するための情報であり、例えば、ローカルユーザーＩＤから構成される。このログインコンテキストはクライアントアプリケーション１３０２と認証部１３０３で共有される。以上が、各種装置が有する機能の説明である。

【0032】

また、アサーション生成部１３０４は、鍵管理部１３０５で予め管理されている秘密鍵を用いて、認可トークン要求に対して署名を付与する機能である。応答検証部１３０６は、認証認可サーバー１１０から受信した応答に認可トークン、または認証認可サーバー１１０の現在時刻が含まれているかを検証する機能である。

【0033】

図３を用いて、認証認可サーバー１１０でのＪＷＴ形式のアサーションの検証処理を説明する。図３のフローは、認証認可サーバー１１０がクライアント端末１３０から認可トークン要求を受信したことをきっかけに、認証認可サーバー１１０で実行される。

【0034】

認証認可サーバー部１１０１はクライアント端末１３０から受信した認可トークン要求に含まれるアサーションの署名を検証する（Ｓ３０１）。署名を検証する際には、鍵管理部１１０３が予め管理する公開鍵が用いられる。検証した結果、署名が正しいと判定された場合はＳ３０２へ、正しくないと判定された場合はＳ３０７へと進む。

【0035】

認証認可サーバー部１１０１は、アサーションに含まれる情報の中からアサーションの発行時刻を取得し、発行時刻が認証認可サーバー１１０の定める正常な発行時刻範囲内に収まっているかを確認する（Ｓ３０２）。正常な発行時刻範囲とは、現在時刻から許容されるずれの範囲である。例えば、正常な発行時刻範囲を±５分とする場合、「認証認可サーバー１１０の現在時刻−５分」≦ｔ１≦「認証認可サーバー１１０の現在時刻＋５分」における値ｔ１が、正常な発行時刻範囲に相当する。アサーションの発行時刻（後述のｉａｔ）が正常な発行時刻範囲内である場合はＳ３０３へ、範囲内でない場合はＳ３０６へと進む。

【0036】

ここで図８に、アサーションに含まれる検証用情報の一例を示す。アサーションにはクライアント端末１３０の識別子（ｉｓｓ）、ユーザー識別子（ｓｕｂ）、サービスの識別子（ａｕｄ）、アサーションの発行時刻（ｉａｔ）、アサーションの有効期限（ｅｘｐ）が含まれる。

【0037】

クライアント端末１３０の識別子は、クライアント端末１３０を一意に識別できる識別子であって、デバイスのシリアル番号などが挙げられる。

【0038】

ユーザー識別子はユーザーを一意に識別できる識別子である。サービスの識別子には具体的に、リソースサーバーへのリクエスト送信先のＵＲＬが設定される。

【0039】

図８の検証用情報は、クライアント端末１３０を認証認可サーバー１１０にクライアント登録する際や、認証認可サーバー１１０が秘密鍵をクライアント端末１３０に対して発行する際に、認証認可サーバー１１０で発行され、クライアント端末１３０と認証認可サーバー１１０で共有されている情報である。アサーションは図８に示した検証用情報以外に、ヘッダー情報を含み、クライアント端末１３０の秘密鍵で行った署名が付与されて、アサーションを構成する。

【0040】

図３の説明に戻る。認証認可サーバー部１１０１は、アサーションに含まれる情報の中からアサーションの有効期限（ｅｘｐ）を取得し、アサーションの有効期限が認証認可サーバー１１０の定める正常な有効期限範囲内に収まっているかを確認する（Ｓ３０３）。正常な有効期限範囲とは、例えば、アサーションの有効期限を５分とする場合、「認証認可サーバー１１０の現在時刻」≦ｔ２≦「認証認可サーバー１１０の現在時刻＋５分」の範囲にある値ｔ２である。アサーションに設定されるアサーションの有効期限は、クライアント端末１３０で予め設定されるものであり、認可トークンを用いて利用されるサービスによって有効期限を変える形態も可能である。

【0041】

Ｓ３０３において、有効期限が正常な時間の範囲に収まっている場合はＳ３０４へ、範囲外の場合はＳ３０６へ進む。

【0042】

認証認可サーバー部１１０１は、アサーションに含まれるその他の検証用情報を検証する（Ｓ３０４）。その他の検証用情報とは例えば、クライアント端末１３０の識別子（ｉｓｓ）や、ユーザー識別子（ｓｕｂ）等であるが、検証の対象とする情報や条件については特に限定しない。検証に成功した場合、認証認可サーバー部１１０１は認可トークンを発行し（Ｓ３０５）、不合格の場合はＳ３０６に進む。

【0043】

また、本実施例ではアサーションの発行時刻と有効期限を検証してから、それ以外の検証用情報を検証する形態を示したが、発行時刻と有効期限を検証する前に、それ以外の検証用情報を検証する形態でもよい。

【0044】

認証認可サーバー部１１０１は、アサーションに含まれるその他の検証用情報が不正な場合はＷｅｂブラウザー１３０１にエラーを返し（Ｓ３０６）、処理を終了する。エラー情報には、クライアント端末１３０がアサーションを修正するために、正当な有効期限等の情報をエラーとともに返す形態も可能である。

【0045】

Ｓ３０２においてのアサーションの発行時刻が正常な時間範囲に収まっていないと判定された場合、認証認可サーバー部１１０１はクライアント端末１３０の時計が正常に動作していない（、あるいは時計を有さないクライアント端末１３０である）と判断し、認証認可サーバー１１０の現在時刻を含めたエラーを返す（Ｓ３０７）。

【0046】

Ｓ３０１においてアサーションの署名が不正であると判定された場合、認証認可サーバー部１１０１はＷｅｂブラウザー１３０１にエラーを返し（Ｓ３０８）、処理を終了する。以上が、認証認可サーバー１１０におけるアサーションの検証フローである（Ｓ３０８）。

【0047】

図４を用いて、クライアント端末１３０が認可トークンを取得する処理を説明する。

【0048】

アサーション生成部１３０４は、クライアント端末１３０における現在時刻に基づいて、アサーションの発行時刻と有効期限を決定し、アサーションを発行する（Ｓ４０１）。アサーションを発行する際には、決定した発行時刻と有効期限を含む検証用情報に対し、予め保持している秘密鍵で署名される。

【0049】

アサーションの有効期限の決定方法としては具体的に、アサーションの発行時刻「２０１８．０１．０１ １２：００：００」に対して、アサーションの有効期限が５分である場合、アサーションの有効期限は「２０１８．０１．０１ １２：０５：００」と決定される。

【0050】

認可トークン要求としてＷｅｂブラウザー１３０１は、Ｓ４０１で発行したアサーションを認証認可サーバー１１０に送信する（Ｓ４０２）。認可トークン要求を受信した後の認証認可サーバー１１０における処理は、図３のフローで示した通りである。

【0051】

図３の処理後、Ｗｅｂブラウザー１３０１は認可トークン要求に対する応答を受信する（Ｓ４０３）。

【0052】

応答検証部１３０６は、受信した応答に認可トークンが含まれているかを判定する（Ｓ４０４）。認可トークンを含まれていると判定された場合は処理を完了し、認可トークンを含まれていると判定された場合はＳ４０５に進む。

【0053】

応答検証部１３０６は、応答に認証認可サーバー１１０の現在時刻が含まれているかを判定する（Ｓ４０５）。現在時刻が含まれていると判定された場合にはＳ４０６へ進み、現在時刻が含まれていないと判定された場合は本処理をエラー終了する。

【0054】

アサーション生成部１３０４は、応答が含む認証認可サーバー１１０の現在時刻に基づいて、アサーションを再度発行する。その際、認証認可サーバー１１０の現在時刻をアサーションの発行時刻とし、その発行時刻に基づいて署名の有効期限を決定する。そしてアサーション生成部１３０４は、決定した発行時刻と有効期限を含むアサーションに秘密鍵で署名し、アサーションを再度発行する（Ｓ４０６）。発行したアサーションは、認証認可サーバー１１０に対して認可トークン要求として送信される（Ｓ４０２）。

【0055】

本実施例ではＳ４０５において、応答に現在時刻が含まれていない場合、エラー終了しているが、認可トークン取得失敗時の対応はこれに限定されない。例えば、図５のフローのように、時刻以外に起因するエラーとしてアサーションを修正するための情報を含むかを判定し（Ｓ１１０１）、含むと判定された場合はその情報に基づいてアサーションを修正する（Ｓ１１０２）。含まないと判定された場合は処理をエラー終了する。Ｓ１１０２の後はＳ４０２の処理に戻り、アサーション生成部１３０４は認証認可サーバー１１０に対し、修正したアサーションを送信する。時刻以外に起因するエラーの例としては、検証用情報（図８）に含まれるユーザー識別子等のエラーが考えられる。

【0056】

以上がクライアント端末１３０における認可トークンの取得フローである。

【0057】

図１０に、クライアント端末１３０が認可トークン要求を送信し、クライアント端末１３０に対してリソースが提供されるまでのシーケンス図を示す。上記で説明済みの部分については同じ符番を振り、詳細な説明は省略する。

【0058】

Ｓ３０５において、認証認可サーバー１１０が認可トークンを発行すると、発行された認可トークンはクライアント端末１３０に送信される（Ｓ１００１）。リソース要求として、発行された認可トークンをリソースサーバー部１２０１に送信し（Ｓ１００２）、認可トークンが検証された（Ｓ１００３）ことに応じて、リソースがクライアント端末１３０に提供される（Ｓ１００４）。以上が認可トークン要求を送信してからリソースが提供されるまでの処理である。

【0059】

本実施例により、クライアント端末１３０の現在時刻が認証認可サーバー１１０の現在時刻と異なっていても、クライアント端末１３０は認証認可サーバー１１０の現在時刻に基づいて新たな認可トークン要求を送信することが出来る。

【0060】

［実施例２］
本実施例では、認可トークン要求の度に認証認可サーバー１１０からのエラーに基づいて、アサーションを修正することなく、認可トークンを取得する形態を示す。実施例１で既に説明された部分については、説明を省略する。

【0061】

実施例２において、クライアント端末１３０は時計もしくはクライアント起動時からのカウントを示すカウンター値などを保持しているものとする。ここでカウンター値とは、時計を有さない機器が起動する度に、０からカウントアップされる値である。

【0062】

認証認可サーバー１１０でのアサーションの検証処理は実施例１の場合（図３）と同様なので、省略する。また、実施例１で説明済みの処理についても同じ符番を振り、詳細な説明は省略する。

【0063】

図６は、実施例２においてクライアント端末１３０がＪＷＴ形式のアサーションを用いて認可トークンを取得するフローである。

【0064】

クライアント端末１３０は、時刻補正情報を保持しているかを確認する（Ｓ６０１）。時刻補正情報とは、認証認可サーバー１１０とクライアント端末１３０の時間差を記録した値であり、クライアント端末１３０で管理される。時刻補正情報の一例は後述する。時刻補正情報は図６のフローを初めて実行した際にはクライアント端末１３０において保持されていないため、Ｓ４０１へ進む。２回目以降の図６の処理であれば時刻補正情報が保持されているため、Ｓ６０２に進む。

【0065】

Ｓ６０１で時刻補正情報が保持されていないと判定された場合、クライアント端末１３０はアサーションを発行する（Ｓ４０１）。

【0066】

Ｓ６０１で時刻補正情報が保持されていると判定された場合、クライアント端末１３０の現在時刻を時刻補正情報で補正した現在時刻をもとにアサーションの発行時刻及び有効期限を決定し、アサーションを発行する（Ｓ６０２）。表１は時刻補正情報の一例を示す。クライアント端末１３０の現在時刻が「２０１８．０１．０１ １２：００：００」であり、保持されている時刻補正情報が「＋３２４００秒」である場合、補正後の現在時刻は３２４００秒後の「２０１８．０１．０１ ２１：００：００」となる。これにより、認証認可サーバー１１０との時刻ずれを補正することができる。

【0067】

【表1】

【0068】

Ｓ４０２〜Ｓ４０５の処理により、認証認可サーバー１１０からのエラーに含まれる現在時刻を取得した後、認証認可サーバー１１０の現在時刻とクライアント端末１３０の現在時刻の時間差を時刻補正情報として保持する（Ｓ６０３）。例えば、クライアント１３０の現在時刻が「２０１８．０１．０１ １：００：００」のとき、認証認可サーバー１１０の現在時刻が「２０１８．０１．０１ １０：００：００」だった場合、その時間差を算出し「＋３２４００秒」という時刻補正情報が算出され保持される。時刻補正情報を算出した後は、Ｓ６０１の処理に戻る。

【0069】

図６で示した処理では、クライアント端末１３０が時計を保有していることを想定している形態である。しかし、クライアント端末１３０が時計を保有しない場合でも、クライアント端末１３０のカウンター値をＵＮＩＸ（登録商標）時刻として処理を行うことで同様に補正することができる。

【0070】

表２は、カウンター値により算出された時刻補正情報の一例である。たとえば、クライアント端末１３０のカウンター値が３０である場合、カウント開始時刻「１９７０．０１．０１ ００：００：００」から算出して現在時刻「１９７０．０１．０１ ０：００：３０」が特定される。それに基づいて、認証認可サーバー１１０の現在時刻「２０１８．０１．０１ １０：００：００」との時間差から「＋ １５１４７６８３７０秒」という時刻補正情報を算出することができる。

【0071】

【表2】

【0072】

本実施例により、クライアント端末１３０が時計を有するかどうかに関わらず、認証認可サーバー１１０の現在時刻との時間差に基づいて、アサーションを生成することができる。

【0073】

［実施例３］
クライアント端末１３０の現在時刻が認証認可サーバー１１０における現在時刻に対して未来に設定されている場合、アサーションに設定されるアサーションの発行時刻は、認証認可サーバー１１０の現在時刻に対して未来の時刻となる。実施例１の処理に従えば、そのアサーションを含む認可トークン要求は、認証認可サーバー１１０においてエラーとして判定される。

【0074】

しかし、アサーションに設定された未来の時刻まで待ち、再度同じアサーションを含む認可トークン要求を認証認可サーバーに送信すると認可トークンを取得できてしまい、リプレイアタックを防ぐことができない。

【0075】

本実施例では、未来の発行時刻が設定されたアサーションによるリプレイアタックを防ぐ方法を、図７を用いて説明する。図７は認証認可サーバー１１０におけるアサーションの検証フローを示す。クライアント端末１３０における現在時刻が、認証認可サーバー１１０の現在時刻に対して未来に設定されているものとする。また、既に説明済みの処理については同じ符番を振り、詳細な説明は省略する。

【0076】

認可トークン要求を受信した認証認可サーバー部１１０１はアサーションを検証した後、認可トークン要求の検証を行う。具体的には、アサーションに含まれる情報（検証用情報と署名を含む）のハッシュ値が要求済トークンテーブルに存在するかを判定する（Ｓ７０１）。存在しないと判定された場合はＳ３０２の処理に進むが、存在すると判定された場合はエラーを返す。

【0077】

要求済トークンテーブルの一例を表３に示す。表３には、アサーションに設定されたアサーションの有効期限と、アサーションに含まれる情報のハッシュ値、要求済みの認可トークン要求を識別するためのＩＤ「００１」が含まれる。

【0078】

【表3】

【0079】

Ｓ３０２において、アサーションの発行時刻が不正であると判定されたことに伴い、不正な認可トークン要求であるとみなす。そして、不正であると判定された認可トークン要求に含まれるアサーションの情報をハッシュ化し、要求済トークンテーブル（表３）にそのハッシュ値を記憶する（Ｓ７０２）。尚、認証認可サーバーにおける時刻をエラーとともに送信する処理（Ｓ３０７）とＳ７０２の順序は問わない。

【0080】

表３で、アサーションの有効期限を記載している理由を説明する。Ｓ３０２の処理では、アサーションの発行時刻が認証認可サーバー１１０の時刻に対して未来に設定されているのか、過去に設定されているのかは問わずに、ハッシュ値が要求済トークンテーブルに管理される。アサーションの発行時刻が未来に設定されている認可トークン要求のみを管理し、リプレイアタックを防ぎたいため、アサーションの有効期限が切れた（または既に切れている）レコードを要求済トークンテーブルから削除する。それにより、有効期限が過ぎリプレイアタックで用いられる恐れがない認可トークン要求を、要求済トークンテーブルで管理せずに済む。

【0081】

以上が、本実施例におけるアサーションの検証処理である。

【0082】

本実施例により、秘密鍵を保持していない不正なクライアント端末１３０であれば、検証用情報を正しい情報に書き換えたとしても署名ができず、Ｓ３０１で弾かれる。また、検証用情報を書き変えなければ、同じ認可トークン要求を認証認可サーバー１１０に送信することとなり、Ｓ７０１で弾かれる。

【0083】

また、本実施例では、ハッシュ値によりアサーションを識別しているが、アサーションをユニークに識別することができれば、その方法を限定するものではなく、トークン識別子（ｊｔｉ）をアサーション内に含めることで識別しても良く、発行者（ｉｓｓ）と発行時刻（ｉａｔ）の組み合わせにより識別しても良い。

【0084】

以上のシーケンスにより、未来の時刻が設定されたトークン要求によるリプレイアタックを防止しつつ、正規のクライアント端末１３０に対しては認可トークン発行を行うことができる。

【0085】

［その他の実施例］
上記の実施例において、アサーションの署名で用いる秘密鍵は、クライアント端末１３０が予め保持している形態で説明したがそれには限定されない。クライアント端末１３０が認証認可サーバー１１０にアクセスして認証を行い、認証認可サーバー１１０から発行された秘密鍵を保持する形態などでも良い。

【0086】

また、本発明の目的は以下の処理を実行することによっても達成される。即ち、上述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

【符号の説明】

【0087】

１１０ 認証認可サーバー
１２０ リソースサーバー
１３０ クライアント端末
１１０１ 認証認可サーバー部
１１０３ 鍵管理部
１３０４ アサーション生成部
１３０５ 鍵管理部
１３０６ 応答検証部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】