(57)【要約】【課題】クライアントクレデンシャルを別のクライアント端末にコピーされると、クライアントクレデンシャルの一意性を常に確保できない。【解決手段】動的にクライアントクレデンシャルの発行を行う機器認可システムにおいて、認証認可サーバーが、クライアント端末のクライアントクレデンシャルと機器固有識別子を対応付けて管理し、クライアント端末が、トークン発行要求時に、クライアントクレデンシャルとともに機器固有識別子を送信することで、前記認証認可サーバーは、通知された前記クライアントクレデンシャルと前記機器固有識別子の組み合わせが登録済の情報と一致しなかった場合に、エラーを通知し、クライアント端末に再登録を促す。【選択図】図３
2019128858.tif 000002
【特許請求の範囲】
【請求項１】
機器登録を要求する認証要求手段と、
アクセストークンの発行を要求する認可要求手段と、（３４０，３４１）
を有するクライアント機器と、（１４１，１４２）
前記認証要求手段により要求を受けると前記クライアント機器ごとに動的にクライアントクレデンシャルを発行する機器認証手段と、（３１０）
前記機器認証手段により発行された前記クライアントクレデンシャルを登録する機器情報管理手段と、（３１１）
前記クライアント機器から前記認可要求手段によりアクセストークンが要求された際に、前記クライアントクレデンシャルに応じたアクセストークンを発行する機器認可手段と、（３１２）
を有する認証認可サーバーと、（１１０）
で構成される機器認可システムにおいて、
前記クライアント機器は、前記認証要求手段において、前記クライアント機器を固有に識別することが可能な機器固有識別子を通知し、（Ｓ４０１）
前記認証認可サーバーは、前記機器情報管理手段において、前記クライアントクレデンシャルと前記機器固有識別子を対応付けて管理し、（Ｓ４０２）
前記クライアント機器は、前記認可要求手段において、前記機器認証手段により発行された前記クライアントクレデンシャルと前記機器固有識別子を通知し、（Ｓ４０３、Ｓ４１１）
前記認証認可サーバーは、前記機器認可手段において、通知された前記クライアントクレデンシャルと前記機器固有識別子の組み合わせが前記機器情報管理手段において登録された対応付けと一致しなかった場合には、アクセストークンを返さずにエラーを通知し、（Ｓ４１２）
前記クライアント機器は、前記エラーを受けて、前記認証要求手段により、機器の登録を行う（Ｓ４１３）ことを特徴とする機器認可システム。
【請求項２】
前記認証認可サーバーは、記機器認可手段において、通知された前記クライアントクレデンシャルと前記機器固有識別子の組み合わせが前記機器情報管理手段において登録されている組み合わせと一致しなかった場合には、前記クライアントクレデンシャルを無効化する（Ｓ５１１）ことを特徴とする請求項１に記載の機器認可システム。
【請求項３】
前記認証認可サーバーは、前記機器認可手段において、前記クライアント機器の持つ複数の前記機器固有識別子のうち、同一のクライアント機器であることを示すのに必要な前記機器固有識別子の数の下限値を示す閾値を持ち、通知された前記機器固有識別子と、前記機器情報管理手段において前記クライアントクレデンシャルに対応づいて登録されている前記機器固有識別子と、が前記閾値以上の個数一致していれば、前記アクセストークンを発行する（Ｓ６０４）ことを特徴とする請求項１又は請求項２に記載の機器認可システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器認可システムにおけるクライアントクレデンシャル発行方法に関する。
【背景技術】
【０００２】
近年、インターネット上に展開された所謂クラウドサービスの利用が拡大している。また、これらクラウドサービスは個々にＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ  ）を公開しており、他のアプリケーションからＡＰＩを介してサービスが提供する機能を利用する事が可能となっている。これらＷｅｂサービスＡＰＩではＯＡｕｔｈ  ２．０と呼ばれる、認可の連携を実現させるための標準プロトコルの採用が進んでいる。非特許文献１はＯＡｕｔｈ  ２．０のプロトコルの定義である。
【０００３】
ＯＡｕｔｈ  ２．０によれば、例えばあるサービスＡが管理するデータを取得するＡＰＩに対して、クライアントＢからのアクセスを認可する事ができる。
【０００４】
クライアントＢはクライアントＢである事を認証するための情報（以下、クライアントクレデンシャルと称する）を用いてクライアントＢのＡＰＩへのアクセス認可を得るためのトークン（以下、アクセストークンと称する）を受け取る事ができる。ここでクライアントＢのクライアントクレデンシャルとしては、非特許文献１によれば、クライアントＢを一意に識別するためのＩＤおよび、秘匿情報であるシークレットを用いる。また、非特許文献２によれば、アプリケーションＢである事を認証するための情報については、ＩＤ、シークレットを用いる方法の他に、デジタル証明書によるデジタル署名を用いる方式が定義されている。
【０００５】
以降のサービスＡのＡＰＩへのアクセスはそのアクセストークンを用いて実現できる。このクライアントＢがリソースに対しアクセスすることを認可したことを権限委譲と称する。なお、ＯＡｕｔｈ  ２．０では、アクセストークンを発行するサーバーを認証認可サーバーと呼称する。
【０００６】
ＯＡｕｔｈ  ２．０によるアクセストークン発行のためには、各クライアントがクライアントクレデンシャルを保持している必要があるが、１つの機器を１つのクライアントとして扱うサービスにおいては各機器を固有に識別可能なクライアントクレデンシャルを生産時にあらかじめ組み込んでおく静的な発行方法と、生産時に特定の生産者によって正式に製造された機器であることを証明するための情報（以下、ベンダークレデンシャルと称する）を一律で組み込み、認証認可サーバーに対して各機器が証明情報を使用してクライアント登録処理を行うことで動的に発行する方法がある。本発明では、後者の動的に発行する方法を対象とする。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】”Ｔｈｅ  ＯＡｕｔｈ  ２．０  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ”、［ｏｎｌｉｎｅ］  Ｄ．  Ｈａｒｄｔ、２０１２年８月  ＜ＵＲＬ  ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９＞
【非特許文献２】”ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ  （ＪＷＴ）  Ｐｒｏｆｉｌｅ  ｆｏｒ  ＯＡｕｔｈ  ２．０  Ｃｌｉｅｎｔ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｇｒａｎｔｓ”、［ｏｎｌｉｎｅ］  Ｍ．  Ｊｏｎｅｓ、Ｂ．  Ｃａｍｐｂｅｌｌ、Ｃ．  Ｍｏｒｔｉｍｏｒｅ、２０１５年５月  ＜ＵＲＬ  ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７５２３＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
例えば、機器Ａの記憶領域に保存されているクライアントＡとしてのクライアントクレデンシャルを機器Ｂにコピーした場合、機器ＢからもクライアントＡのクライアントクレデンシャルとして利用し、アクセストークンを取得することが可能となる。このとき、クライアントクレデンシャルは機器Ａとの一意性を担保できなくなるため、認証した機器Ａであることを証明できなくなってしまう。
【０００９】
本発明は、動的にクライアントクレデンシャルを発行する方法においてクライアントクレデンシャルが機器に対し常に一意性の確保することを目的とする。
【課題を解決するための手段】
【００１０】
上記の目的を達成するために、本発明に係る機器認可システムは、
機器登録を要求する認証要求手段と、
アクセストークンの発行を要求する認可要求手段と、（３４０，３４１）
を有するクライアント機器と、（１４１，１４２）
前記認証要求手段により要求を受けると前記クライアント機器ごとに動的にクライアントクレデンシャルを発行する機器認証手段と、（３１０）
前記機器認証手段により発行された前記クライアントクレデンシャルを登録する機器情報管理手段と、（３１１）
前記クライアント機器から前記認可要求手段によりアクセストークンが要求された際に、前記クライアントクレデンシャルに応じたアクセストークンを発行する機器認可手段と、（３１２）
を有する認証認可サーバーと、（１１０）
で構成される機器認可システムにおいて、
前記クライアント機器は、前記認証要求手段において、前記クライアント機器を固有に識別することが可能な機器固有識別子を通知し、（Ｓ４０１）
前記認証認可サーバーは、前記機器情報管理手段において、前記クライアントクレデンシャルと前記機器固有識別子を対応付けて管理し、（Ｓ４０２）
前記クライアント機器は、前記認可要求手段において、前記機器認証手段により発行された前記クライアントクレデンシャルと前記機器固有識別子を通知し、（Ｓ４０３、Ｓ４１１）
前記認証認可サーバーは、前記機器認可手段において、通知された前記クライアントクレデンシャルと前記機器固有識別子の組み合わせが前記機器情報管理手段において登録された対応付けと一致しなかった場合には、アクセストークンを返さずにエラーを通知し、（Ｓ４１２）
前記クライアント機器は、前記エラーを受けて、前記認証要求手段により、機器の登録を行う（Ｓ４１３）ことを特徴とする。
【発明の効果】
【００１１】
本発明に係る機器認可システムによれば、各機器の保有するクライアントクレデンシャルが機器に対して常に一意性を確保することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】システム構成図
【図２】ハードウェア構成図
【図３】ソフトウェアモジュール構成図
【図４】第１の実施形態におけるシーケンス図
【図５】第２の実施形態におけるシーケンス図
【図６】第３の実施形態におけるフローチャート
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための形態について、図面を参照しながら説明する。
【００１４】
本実施例においては、インターネット上の各サーバーにアプリケーションが設置されていることとする。アプリケーションはクライアント端末と連携し、様々な機能を提供することとする。このような機能を提供する実体をサービスと称し、機能をクライアント端末に提供することをサービスの提供と称する。
【００１５】
本実施の形態に係る情報処理システムであるデータアクセス管理システムは、図１に示すような構成のネットワーク上に実現される。
【００１６】
１００は、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＷＡＮ）であり、本発明ではＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ）である。１１０はクライアント端末の認証・認可を実現するための認証認可サーバーである。１２０はリソースサーバーであり、クライアント端末のデータをバックアップするサービスや、クライアント端末のセンサー情報を分析するサービスなど様々なサービスを提供する。認証１４０、１４１はクライアント端末であり、サービスを利用するためのパソコン、モバイル端末、画像形成装置などの機器である。認可サーバー１１０はクライアント端末１４０、１４１を認証し、各クライアント端末がリソースサーバー１２０を利用するのに必要なアクセストークンを発行する。実施例において各サーバー１１０、１２０は１台ずつ設置されているが複数台で構成されていても良く、例えば、認証認可サーバーシステムとして提供されても良い。
【００１７】
図２は本実施例に係る、認証認可サーバー１１０、クライアント端末１４０、１４１を構成する情報処理装置の一般的なハードウェア構成である。
【００１８】
ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳやアプリケーション等のプログラムを実行する。またＣＰＵ２３１は、システムバス２３４に接続される各ブロックを制御する。ここでＯＳとはコンピューター上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。操作部Ｉ／Ｆ２３５は、操作部２３９からの入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。ディスクコントローラ（ＤＫＣ）２３７は各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２３８はＷＡＮ１００もしくはＬＡＮ１０１、１０２、１０３を介して接続されたサーバーコンピューターや他の機器との通信制御処理を実行する。
【００１９】
尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたアプリケーションプログラムである。
【００２０】
図３は本実施の形態に係る、認証認可サーバー１１０、クライアント端末１４０、１４１それぞれのモジュール構成を示す図である。
【００２１】
各々のモジュールが実行されることで、各々の機能を実現する。
【００２２】
認証認可サーバー１１０、は機器認証モジュール３１０、機器情報管理モジュール３１１、機器認可モジュール３１２を持つ。
【００２３】
機器認証モジュール３１０では、クライアント端末から送られてくるベンダークレデンシャルを受けて各クライアント端末が正式な端末であるかを確認し、認証したクライアント端末にクライアントクレデンシャルを発行する。ここで、ベンダークレデンシャルおよびクライアントクレデンシャルは、それぞれ製造者および各クライアント端末を一意に証明できるものであれば、その方法を制限するものではない。例えば、通信路の暗号化を前提としたクライアント端末を一意に識別するためのＩＤおよび、シークレットの組み合わせでも良いし、デジタル証明書によるデジタル署名を用いた方法でも良い。
【００２４】
機器情報管理モジュール３１１はクライアント端末を管理し、クライアントクレデンシャルと機器固有識別子を管理する。機器固有識別子は、機器ごとに固有の値であれば、それを制限するものではなく、例えば、各機器に付与されているデバイスシリアルＩＤでもよいし、ネットワークユニットに付与されるＭＡＣアドレスでも良い。また、管理する機器固有識別子はクライアント端末ごとに複数であっても良い。
【００２５】
機器認可モジュール３１２は、クライアント端末の認可処理を行い、クライアント端末に応じたアクセストークンを発行する。クライアント端末１４０、１４１は認証要求モジュール３４０、３４１、認可要求モジュール３４２、３４３を持つ。認証認可要求モジュール３４０、３４１は認証認可サーバー１１０に対してクライアント端末の認証要求およびアクセストークン発行要求を行う。
【００２６】
＜第１の実施形態＞
本実施例における基本の実施形態を説明する。
【００２７】
図４は、クライアント端末１４０のクライアントクレデンシャルがクライアント端末１４１にコピーされたケースにおけるクライアントクレデンシャルの一意性を担保するための処理の流れの一例を示している。以下に、各ステップの処理内容を説明する。
【００２８】
ステップＳ４０１〜Ｓ４０４はクライアント端末１４０が機器登録を行い、正常にアクセストークンを発行するまでの流れである。クライアント端末１４０は予めベンダークレデンシャル４０５および、機器固有識別子４０６を保持している。
【００２９】
ステップＳ４０１において、未認証のクライアント端末１４０の認証認可要求モジュール３４０は認証認可サーバー１１０に機器登録要求を行う。このとき、クライアント端末１４０のベンダークレデンシャル４０５および機器固有識別子４０６を送信する。
【００３０】
ステップＳ４０２において、認証認可要求モジュール３４０から機器登録要求を受けた認証認可サーバー１１０の機器認証モジュール３１０は送られてきたベンダークレデンシャル４０５が正式に発行されたものであることを確認したのち、クライアント端末１４０のクライアントクレデンシャル４０７を発行し、機器情報管理モジュール３１１に機器固有識別子４０６とクライアントクレデンシャル４０７を渡し、機器情報の登録を行う。
Ｓ４０１およびＳ４０２のステップが完了すると、クライアント端末１４０に発行したクライアントクレデンシャル４０７をレスポンスする。
【００３１】
ステップＳ４０３において、認証済のクライアント端末１４０の認証認可要求モジュール３４０は認証認可サーバー１１０にトークン発行要求を行う。このとき、クライアントクレデンシャル４０７とともに機器固有識別子４０６も送信する。
【００３２】
ステップＳ４０４において、認証認可要求モジュール３４０からトークン発行要求を受けた認証認可サーバー１１０の機器認可モジュール３１２は機器情報管理モジュール３１１よりクライアントクレデンシャル４０７の一致する機器固有識別子を取得し、クライアントクレデンシャル４０７が登録されており、かつ、関連する機器固有識別子がクライアント端末１４０より送られてきた機器固有識別子４０６と一致することを確認する。本実施形態では、機器情報管理モジュール３１２が機器固有識別子の一致を判断しているが、機器情報管理モジュールに３１１にクライアントクレデンシャルと機器固有識別子の組み合わせを渡して、機器情報管理モジュール３１１が一致を判断しても良い。
【００３３】
Ｓ４０３およびＳ４０４のステップを完了すると、クライアント端末１４０がリソースサーバー１２０を利用するためのアクセストークン４０８をレスポンスする。これにより、クライアント端末１４０はリソースサーバー１２０のサービスを利用することが可能になる。
【００３４】
ステップＳ４１１〜Ｓ４１４はクライアント端末１４０に発行されたクライアントクレデンシャル４０７が未認証のクライアント端末１４１にコピーされ、それを利用してトークン発行処理が行われた場合の処理の流れである。クライアント端末１４１は予めベンダークレデンシャル４１５および、機器固有識別子４１６を保持している。
【００３５】
ステップＳ４１１において、未認証のクライアント端末１４１の認証認可要求モジュール３４１はクライアント端末１４０のクライアントクレデンシャル４０７を保持しているため、認証済機器であると判断し、機器登録処理を置こうことなく認証認可サーバー１１０にトークン発行要求を行う。このとき、クライアント端末１４０のクライアントクレデンシャル４０７とともにクライアント端末１４１機器固有識別子４１６を送信する。
【００３６】
ステップＳ４１２において、認証認可要求モジュール３４１からトークン発行要求を受けた機器認可モジュール３１２は機器情報管理モジュール３１１よりクライアントクレデンシャル４０７の関連する機器固有識別子を取得する。このとき、機器情報管理モジュール３１１より取得される機器固有識別子４０６は送られてきた機器固有識別子４１６と一致しないため、機器認可モジュール３１２はエラーをレスポンスする。
【００３７】
ステップＳ４１３において、クライアント端末１４１の認証認可要求モジュール３４１はエラーを受けて、ただちにベンダークレデンシャル４１５および、機器固有識別子４１６を用いて認証認可サーバー１１０に機器登録要求を行う。
【００３８】
ステップＳ４１４において、認証認可要求モジュール３４１から機器登録要求を受けた認証認可サーバー１１０の機器認証モジュール３１０は送られてきたベンダークレデンシャル４１５が正式に発行されたものであることを確認したのち、クライアント端末１４１のクライアントクレデンシャル４１７を発行し、機器情報管理モジュール３１１に機器固有識別子４１６とクライアントクレデンシャル４１７を渡し、機器情報の登録を行う。
Ｓ４１３およびＳ４１４のステップが完了すると、クライアント端末１４１に発行したクライアントクレデンシャル４１７をレスポンスする。
【００３９】
以上の処理により、クライアント端末１４０のクライアントクレデンシャルが別のクライアント端末１４１にコピーされた場合においても、クライアント端末１４１においてアクセストークンが取得されることはなく、ただちに別のクライアントクレデンシャルが発行される。これにより、各クライアント端末のクライアントクレデンシャルは常に一意性が確保される。
【００４０】
＜第２の実施形態＞
第１の実施形態に加えて実施する第２の実施形態を説明する。
【００４１】
第１の実施形態では、ステップＳ４１２において、クライアント端末１４０のクライアントクレデンシャルがクライアント端末１４１から送られてきた際、エラーを返すことでクライアント端末１４１の機器登録を促しているが、クライアント端末１４０に発行されたクライアントクレデンシャル４０７はその後も利用可能である。しかし、本来クライアント端末ごとの秘匿情報として扱われるべきクライアントクレデンシャルが別端末に利用される状況は、クライアントクレデンシャル４０７を放置することでクライアント端末１４０のアクセストークンを不正に発行されるなど悪用されるケースも考えられ、セキュリティ上対処すべきである。第２の実施形態では、上記の問題を解決する。
【００４２】
図５にて、第２の実施形態における処理の流れを説明する。
【００４３】
ステップＳ５１１は不適切なクライアント端末からトークン発行要求があった際に、クライアントクレデンシャルを無効にする流れである。
【００４４】
ステップＳ４１２において、機器情報管理モジュール３１１より取得される機器固有識別子４０６は送られてきた機器固有識別子４１６と一致しないことを受け、ステップＳ５１１において、機器認証モジュール３１２は機器情報管理モジュール３１１の管理するクライアントクレデンシャル４０７を無効化する。
【００４５】
ステップＳ５０１〜Ｓ５０４はクライアントクレデンシャル４０７が無効化されて以降のクライアント端末１４０の処理の流れである。
【００４６】
ステップＳ５０１において、クライアント端末１４０の認証認可要求モジュール３４０はクライアントクレデンシャル４０７を保持しているため、認証済機器であると判断し、機器登録処理を置こうことなく認証認可サーバー１１０にトークン発行要求を行う。
【００４７】
ステップＳ５０２において、認証認可要求モジュール３４０からトークン発行要求を受けた機器認可モジュール３１２は機器情報管理モジュール３１１よりクライアントクレデンシャル４０７の関連する機器固有識別子を取得する。このとき、機器情報管理モジュール３１１の管理情報にクライアントクレデンシャル４０７は存在しないため、機器認可モジュール３１２はエラーをレスポンスする。
【００４８】
ステップＳ５０３において、クライアント端末１４０の認証認可要求モジュール３４０はエラーを受けて、ただちにベンダークレデンシャル４０５および、機器固有識別子４０６を用いて認証認可サーバー１１０に再度機器登録要求を行う。
【００４９】
ステップＳ５０４において、認証認可要求モジュール３４０から機器登録要求を受けた認証認可サーバー１１０の機器認証モジュール３１０はベンダークレデンシャル４０５が正式に発行されたものであることを確認したのち、クライアント端末１４０のクライアントクレデンシャル５０５を発行し、機器情報管理モジュール３１１に機器固有識別子４０６とクライアントクレデンシャル５０５を渡し、機器情報の登録を行う。
【００５０】
Ｓ５０３およびＳ５０４のステップが完了すると、クライアント端末１４０に発行したクライアントクレデンシャル５０５をレスポンスする。このとき、クライアントクレデンシャル５０５を用いて発行するアクセストークンはクライアントクレデンシャル４０７にて発行されていたアクセストークン４０８と同等のアクセス権限を持つことで、クライアント端末１４０は漏洩の可能性があるクライアントクレデンシャル４０７を無効化しながらも、これまでと変わらずサービス利用を継続できる。
【００５１】
＜第３の実施形態＞
第１および第２の実施形態に加えて実施する第３の実施形態を説明する。
【００５２】
第１および第２の実施形態では、機器情報管理モジュール３１１においてクライアントクレデンシャルに対応付けられた機器固有識別子がクライアント端末より送信された組み合わせと一致するか否かでトークン発行可否を判断していた。しかしながら、クライアント端末によっては、ハードウェアの故障により部品を交換したことで、機器固有識別子が変わってしまう可能性がある。このとき、故障修理後のクライアント端末は以前のクライアント端末と同一であると判断されず、トークン発行ができなくなってしまう。第３の実施形態では、上記の問題を解決する。
【００５３】
図６は、本実施形態において、機器認可モジュール３１２がトークン発行要求を受けた際の処理の流れである。
【００５４】
表１は、トークン発行要求時にクライアント端末から通知される情報の一例、表２は、機器情報管理モジュール３１１が保持する機器情報管理テーブルの一例である。表１および表２の条件を例に図６の各ステップを説明する。
【００５５】
【表１】
2019128858.tif 000003
【００５６】
【表２】
2019128858.tif 000004
【００５７】
ステップＳ６０１において、機器認可モジュール３１２はクライアント端末からトークン発行要求を受ける。このとき、表１のクライアントクレデンシャルおよび機器固有識別子が渡される。
【００５８】
ステップＳ６０２において、機器情報管理モジュール３１１よりクライアントクレデンシャルｊｗｔ１の関連する機器固有識別子を取得する。機器情報管理モジュール３１１は表２の管理テーブルから機器固有識別子として（ａ−１、ｂ−１、ｃ−１）の情報を返す。
【００５９】
ステップＳ６０３において、機器認可モジュール３１２は、機器固有識別子がすべて一致しているかを判定する。すべての機器固有識別子が一致している場合には、ステップＳ６０７へ進む。表１のケースでは、機器固有識別子は（ａ−１、ｂ−３、ｃ−１）となり管理テーブルの情報と一致していないため、ステップＳ６０４へ進む。
【００６０】
ステップＳ６０４において、クライアント端末の構成要素である各ユニットの機器固有識別子のうち、一致してている機器固有識別子数が予め設定された閾値以上かを判定する。閾値以上であれば同一のクライアント端末、未満であれば異なるクライアント端末であると判定する。ここで、閾値となる機器固有識別子数は任意の値で良いが、クライアント端末の一意性を確保するために、構成される全機器固有識別子数の過半数であることが望ましい。本実施形態では、全機器固有識別子数３に対し、閾値を２とする。表１より機器固有識別子（ａ−１、ｂ−３、ｃ−１）のうち、（ａ−１、ｃ−１）の２ユニットは一致しているため、同一のクライアント端末と判定され、ステップＳ６０５へ進む。閾値未満である場合には、異なるクライアント端末と判断し、ステップＳ６０８へ進む。
【００６１】
ステップＳ６０５において、クライアント端末の管理者へクライアントの機器構成が変更されていることを検知した旨の通知を行う。管理者への通知方法は限定されたものではなく、クライアント端末のアプリケーションへの通知でも良いし、メールを利用した通知でも良い。
【００６２】
ステップＳ６０６において、機器情報管理モジュール３１１の管理テーブルについて、表３のようクライアント端末の機器固有識別子を更新する。
【００６３】
【表３】
2019128858.tif 000005
【００６４】
ステップＳ６０７において、適切なクライアント端末からのトークン発行要求である場合には、トークン発行処理を行う。
【００６５】
ステップＳ６０８において、適切でないクライアント端末からのトークン発行要求である場合には、エラーをレスポンスする。
【００６６】
以上の処理により、故障等によりクライアント端末の機器固有識別子が変更された場合でも、クライアント端末はサービスの継続利用が可能である。
【符号の説明】
【００６７】
１１０  認証認可サーバー、１２０  リソースサーバー、１４０  クライアント端末、
１４１  クライアント端末、３１０  機器認証モジュール、
３１１  機器情報管理モジュール、
３１２  機器認可モジュール、３４０  認証認可要求モジュール、３４１  認証認可要求モジュール、
Ｓ４０１〜Ｓ４０４  第１の実施形態におけるクライアント端末１４０に関連する処理ステップ、
４０５  ベンダークレデンシャル、４０６  機器固有識別子、
４０７  クライアントクレデンシャル、４０８  アクセストークン、
Ｓ４１１〜Ｓ４１４  第１の実施形態におけるクライアント端末１４１に関連する処理ステップ、
４１５  ベンダークレデンシャル、４１６  機器固有識別子、
４１７  クライアントクレデンシャル、
Ｓ５０１〜Ｓ５０４  第２の実施形態におけるクライアント端末１４０に関連する処理ステップ、
５０５  クライアントクレデンシャル、
Ｓ５１１  第２の実施形態におけるクライアント端末１４１に関連する処理ステップ、
Ｓ６０１〜Ｓ６０３  第３の実施形態における機器認可モジュール３１２に関連する処理ステップ
【図１】
2019128858.tif 000006
【図２】
2019128858.tif 000007
【図３】
2019128858.tif 000008
【図４】
2019128858.tif 000009
【図５】
2019128858.tif 000010
【図６】
2019128858.tif 000011