JP7843843B2 - ネイティブ・アプリケーションにおける認証のセキュリティ強化のためのデバイスにバインドされた認証情報の使用 - Google Patents

Description

本発明は、コンピュータ・リソースを保護することに関連している。より詳細には、本発明の１つまたは複数の実施形態は、特定のコンピュータ・リソースへの安全なアクセスを提供する。さらに詳細には、本発明の１つまたは複数の実施形態は、Ｏｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡｕｔｈ）のリフレッシュ中にネイティブ・アプリケーションによって提示されたリフレッシュ・トークンが、それらのリフレッシュ・トークンの発行先だったデバイスと同じデバイスから送信されていることを保証するための新しい有用な解決策を提供する。

本発明の１つまたは複数の実施形態では、認可サーバが、デバイス上のネイティブ・アプリケーションから、初期認可グラント、デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、およびネイティブ・アプリケーションの信頼性の証明書を受信する。認可サーバは、デバイス上のネイティブ・アプリケーションから、リフレッシュ・トークン、および秘密鍵を使用して作成されたリフレッシュ・トークンのデジタル署名を受信し、認可サーバは、あらかじめ登録されている公開鍵を用いてリフレッシュ・トークンが検証された場合にのみ、リフレッシュ・トークンを認識する。認可サーバは、リフレッシュ・トークンのデジタル署名の妥当性を確認する。デバイス上のネイティブ・アプリケーションからのリフレッシュ・トークンの妥当性を確認することに応答して、認可サーバは、新しいアクセス・トークンが、デバイス上のネイティブ・アプリケーションがコンピュータ・リソースにアクセスすることを可能にするように、新しいアクセス・トークンおよび新しいリフレッシュ・トークンをデバイス上のネイティブ・アプリケーションに送信する。

１つまたは複数の実施形態では、本明細書に記載された方法は、コンピュータ・システム上のコンピュータ・プログラム製品の実行によって実行される。

本開示が実装され得る例示的なシステムおよびネットワークを示す図である。 Ｏｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡｕｔｈ）システム内で実行される本発明の１つまたは複数の実施形態の俯瞰的な概要を示す図である。 本発明の１つまたは複数の実施形態において実行される１つまたは複数の動作の俯瞰的なフローチャートの図である。 本発明の１つまたは複数の実施形態において利用されて示される例示的なブロックチェーン・ネットワークを示す図である。 本発明の１つまたは複数の実施形態において使用されるような例示的なブロックチェーン台帳を示す図である。 本発明の１つまたは複数の実施形態に従って、ブロックチェーンを使用する俯瞰的な一連の動作を示す図である。 本発明の１つまたは複数の実施形態において使用されるような例示的なニューラル・ネットワークを示す図である。 本発明の実施形態に従ってクラウド・コンピューティング環境を示す図である。 本発明の実施形態に従ってクラウド・コンピューティング環境の抽象モデル・レイヤを示す図である。

本明細書において説明されるように、本発明の１つまたは複数の実施形態は、デバイスにバインドされた公開鍵基盤（ＰＫＩ：Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）認証情報を利用して、リフレッシュ・トークンのメッセージ・ペイロード内のＯｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡｕｔｈ）リフレッシュ・トークンに署名する。そのため、本発明の１つまたは複数の実施形態では、初期グラントの確立中に、認証情報ペアの公開鍵の登録が実行され、その後のすべてのリフレッシュ・トークン・フローの間に、リフレッシュ・トークン上の署名の追加が提供される。

本発明の１つまたは複数の実施形態は、デバイスにバインドされた鍵ペアを、そのような鍵ペアの証明書を含めて確立するために、Ｆａｓｔ Ｉｄｅｎｔｉｔｙ Ｏｎｌｉｎｅ（ＦＩＤＯ）などのパターンを活用し、アプリケーション・レベルのペイロード以外を何も必要としない（すなわち、トランスポート層セキュリティ（ＴＬＳ：Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）拡張を必要としない）。

ＯＡｕｔｈシステムが利用される本発明の１つまたは複数の実施形態では、デバイスにバインドされる方法であらかじめ登録された鍵を用いて署名が実行されることを保証するために、リフレッシュ・トークン自体をチャレンジとして使用して、ＦＩＤＯのアサーション・ペイロード（ａｓｓｅｒｔｉｏｎ ｐａｙｌｏａｄ）がリフレッシュ・トークンのペイロード・パラメータに追加され、サーバで妥当性を確認される。

そのようなＯＡｕｔｈシステムは、ユーザがアプリケーションをインストールした後に、登録セレモニーに参加し、長寿命のＯＡｕｔｈグラント（第１のリフレッシュ・トークンおよびアクセス・トークン）を確立し、データ、プログラム、ハードウェアなどのコンピュータ・リソースへのアプリケーション・プログラミング・インターフェイス（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅｓ）を呼び出すときに、アプリケーションがそのユーザとして機能するように、ネイティブ・アプリケーションにおいてアイデンティティ・セキュリティ・パターン（ｉｄｅｎｔｉｔｙ ｓｅｃｕｒｉｔｙ ｐａｔｔｅｒｎ）を提供する。

ユーザの例示的なＯＡｕｔｈ登録プロセスは、ユーザが初期識別情報のためのユーザ・プロフィール（例えば、名前、住所など）を入力することから開始する。１つまたは複数の登録シナリオでは、多要素認証（ＭＦＡ：Ｍｕｌｔｉ－Ｆａｃｔｏｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）が使用され、多要素認証では、ユーザは、パスワードだけでなく、生体測定情報（例えば、ユーザの指紋）、ユーザによって使用される電子デバイス内の全地球測位システム（ＧＰＳ：Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）センサ、セルラー・ネットワーク内の特定の携帯電話基地局への現在の通信接続などによって決定されるような、ユーザの現在の位置、セキュリティ・システムによって現在の時刻で有効であると知られている絶えず変化する文字を生成するドングルなどの、セキュリティ・トークンへのアクセスなども提供する。

ユーザが自分のユーザ・プロフィール、ＭＦＡ認証情報などを入力した後に、この情報が、認可サーバからの初期ＯＡｕｔｈグラントに交換される。

ネイティブ・アプリケーションは、デバイス上でシステム・ブラウザを起動してよく、ユーザが、ブラウザベースのメカニズムを介して認証し、認可コード・グラント・タイプのフローを開始するか、またはネイティブ・アプリケーションは、アプリケーション自体に組み込まれたこの機能を、初期ＯＡｕｔｈグラントのために提供してよい。ネイティブ・アプリケーションは、アプリの登録されたカスタム起動ＵＲＩである任意のリダイレクトＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を順守する。

ユーザは、別のデバイスのブラウザで（例えば、ラップトップで）認証し、ネイティブ・アプリケーションがＱＲコード（登録商標)をスキャンすることができるように、認可コードを含むクイック・レスポンス（ＱＲ：Ｑｕｉｃｋ Ｒｅｓｐｏｎｓｅ）コードを提示される。

特定のフロー（上記に説明されたフローまたは同様の変形）にかかわらず、デバイス上のアプリケーションのための初期グラントが確立される。次に、リフレッシュ・トークンは、他のアプリへの開示を防ぐために、アプリに固有のセキュア・ストレージに格納される。

登録後に、デバイス（例えば、スマートフォンなどのモバイル・デバイス）上のネイティブ・アプリケーションが、ＡＰＩを呼び出すために新しいアクセス・トークンを必要とするたびに、ネイティブ・アプリケーションが認可サーバのトークン・エンドポイントへの呼び出しを行うことによって、リフレッシュ・トークン・フローが実行される。リフレッシュ・トークンそのものだけが、リフレッシュされているグラントを識別する役割を果たす。

本発明の１つまたは複数の実施形態が新しい有用な方法で克服する、今説明したＯＡｕｔｈプロセスに伴う問題は、リフレッシュ・トークンが、リフレッシュ・トークンのもともとの発行先だったデバイスから提示されているということを条件として、証明が存在しないことである。そのため、本発明がなければ、認証サーバは、異なるデバイスまたはプログラムからリフレッシュ・トークンが提示されているように、リフレッシュ・トークンがデバイス、ネイティブ・アプリケーション、もしくはネットワーク、またはそれらの組み合わせから侵害されている状況を決定／区別することができない。

この問題に対処するために、本発明の１つまたは複数の実施形態は、ネイティブ・アプリケーションに、リフレッシュ・トークン・フローが実行されるたびに、登録段階の間にアプリケーションが作成する非対称のデバイスにバインドされた認証情報を使用して、リフレッシュ・トークンに署名させる。グラントが最初に確立されたデバイ上のみで署名動作が行われ得るということを保証することによって、サーバは、グラントの発行先だったデバイス上のアプリケーションによってＯＡｕｔｈグラントが使用されているということを、非常に高いレベルで信頼することができる。

本発明の１つまたは複数の実施形態は、トークン・バインディングを上回る明確な改善をもたらす。トークン・バインディングは、暗号証明書を使用するが、ＴＬＳ接続の両端（例えば、クライアントと認可サーバの間）で暗号証明書を取得するために、トランスポート層セキュリティ（ＴＬＳ：Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）拡張の使用を必要とする。そのため、そのようなシステムのユーザ機器は、高レベルの専門知識、時間、およびコンピュータ・リソースを必要とし、本発明はこれらを必要としない。さらに、トークン・バインディングは、クライアントで作成された認証情報がデバイスにバインドされることを強制せず、したがって、認証情報の安全性を低くする。そのため、本発明の１つまたは複数の実施形態は、（例えば、ＯＡｕｔｈペイロード内の追加パラメータを使用する）アプリケーション・データ・レベルであり、ＴＬＳでのトークン・バインディングの実装に依存しない、リソース・セキュリティの解決策を提供する。

俯瞰的には、本発明の１つまたは複数の実施形態は、登録段階およびその後のグラント・リフレッシュという２つの段階を含む。

登録段階

登録中に、ネイティブ・アプリケーションは、「初期グラント・データ」をユーザから受信するか、または収集する。本発明の１つまたは複数の実施形態では、この初期グラント・データは、クライアント・デバイス上でユーザ・インターフェイスを介してネイティブ・アプリケーションに提供されるユーザ名／パスワードなどの、リソース所有者パスワード認証情報（ＲＯＰＣ：Ｒｅｓｏｕｒｃｅ Ｏｗｎｅｒ Ｐａｓｓｗｏｒｄ Ｃｒｅｄｅｎｔｉａｌｓ）ユーザ認証情報である。

本発明の１つまたは複数の実施形態では、この初期グラント・データは、システム・ブラウザからのハンドオフ（カスタム起動ＵＲＩ呼び出し）から取得されたか、またはＱＲコード（登録商標)を介してスキャンされた、認可コードである。

ネイティブ・アプリケーションがこの初期グラント・データをトークン・エンドポイントに送信して第１の認可グラントを取得する前に、ネイティブ・アプリケーションは、ローカル・デバイスにバインドされ公開鍵／秘密鍵認証情報を作成する。

本発明の１つまたは複数の実施形態では、デバイスのオペレーティング・システムは、認証情報を作成するために使用されるＦａｓｔ Ｉｄｅｎｔｉｔｙ Ｏｎｌｉｎｅ－２（ＦＩＤＯ２）のプラットフォーム認証器アプリケーション・プログラム・インターフェイス（ＡＰＩ）を提供する。

本発明の１つまたは複数の実施形態では、プラットフォームＡＰＩ（例えば、セキュア・エンクレーブＡＰＩ）が、認証情報を作成する。

作成される認証情報は、ユーザ検証が作成されて使用されることを必要としても必要としなくてもよい。この選択は、結局、企業が提供するＡＰＩサービスおよび望ましいユーザ・エクスペリエンスのセキュリティ要件（ポリシー）になる。Ｆａｓｔ Ｉｄｅｎｔｉｔｙ Ｏｎｌｉｎｅ（ＦＩＤＯ）の用語および規格では、ユーザ検証は、任意選択的であり、そのため本明細書に記載されたアイデアにとどまる。

鍵ペアを作成した後に、ネイティブ・アプリケーションは、認証サーバ内のＯＡｕｔｈトークン・エンドポイントへの要求において初期グラント・データに含まれるＦＩＤＯ ａｔｔｅｓｔａｔｉｏｎＯｂｊｅｃｔを構築する。本発明の１つまたは複数の実施形態では、この証明書オブジェクトの作成に入力されるｃｌｉｅｎｔＤａｔａＪＳＯＮが（サーバによって提供されるチャレンジの代わりに）初期グラント・データになるように、パックされた証明書形式が使用される。

本発明の１つまたは複数の実施形態では、証明書秘密鍵が、ネイティブ・アプリケーションのソース自体に埋め込まれる。ホワイトボックス暗号化および安全なネイティブ・コードの配布の実践などの技術を使用して、証明書秘密鍵の保護が実行される。

本発明の１つまたは複数の実施形態は、ＦＩＤＯ２証明書などの証明書プロトコルを利用する。

ＦＩＤＯ２証明書などの証明書は、使用されたクライアント認証器のｍａｋｅ／ｍｏｄｅｌの証明を、認証サーバに提供する。クライアント認証器として機能しているネイティブ・アプリケーションの場合、この証明は、アプリケーションが、実行するようにコード化されたことを実行しているということを信用されるように、アプリケーション開発者によって指定されたネイティブ・アプリケーションのベンダーおよびバージョンを識別することによって、アプリケーションの完全性を証明することである。

本発明の１つまたは複数の実施形態では、リフレッシュ・トークン・フローに署名するよう使用される作成されている認証情報は、秘密鍵が確立されたデバイスのみでその秘密鍵が使用されるように、デバイスにバインドされているということを、認証サーバは証明することができなければならない。そのような証明書がなければ、サーバと通信しているクライアントがアプリケーションの本物のインストールであるということがサーバにはわからない。アプリケーションがクライアント・デバイスのオペレーティング・システムによって提供されたネイティブなＦＩＤＯ２ ＡＰＩを使用している場合、プラットフォームによって証明書が提供される。そうでない場合、ネイティブ・アプリケーション・コード内で証明書が提供される。

次に、ネイティブ・アプリケーションは、初期グラント・データ、（デバイスにバインドされた認証情報の公開鍵を含む）ａｔｔｅｓｔａｔｉｏｎＯｂｊｅｃｔ、および（公開鍵を検証するための）初期グラント・データの署名を、ＯＡｕｔｈ認可サーバのトークン・エンドポイントに提示する。

ＯＡｕｔｈ認可サーバは、証明書秘密鍵の信頼できる署名者を含む事前に構成されたメタデータを使用して、証明書を検証する。この検証は、証明書オブジェクト内の認証器データが、ユーザ検証が実行されたことを示すことが、サーバのポリシーである場合に、そのことをチェックすることを含む。初期グラント・データも検証される。デバイスにバインドされた認証情報の公開鍵が、サーバ側でＯＡｕｔｈグラントに関連付けられ、初期リフレッシュ・トークンおよびアクセス・トークンが、ネイティブ・アプリケーション・クライアントに返される。

その後のグラント・リフレッシュ

ネイティブ・アプリケーションはときどき、アクセス・トークンの期限が切れるときに、新しいリフレッシュ・トークン・フローを実行する。本発明の１つまたは複数の実施形態では、リフレッシュ・トークン・フローは、リフレッシュ・トークンと一緒に、ＦＩＤＯ ａｕｔｈｅｎｔｉｃａｔｏｒＤａｔａ、および初期グラントの確立中に登録されたデバイスにバインドされた認証情報の秘密鍵を使用して実行された（リフレッシュ・トークンのハッシュの）署名を含む。これによって、各リフレッシュで、グラントが確立されたデバイスで要求が生成されたことの証明をサーバに提供する。ＦＩＤＯの認証ドキュメントに記述されたｃｌｉｅｎｔＤａｔａＪＳＯＮは、サーバによって提供されたチャレンジとして、代わりにリフレッシュ・トークンを含む。

本発明の１つまたは複数の実施形態では、ｒｅｆｒｅｓｈ＿ｔｏｋｅｎに一意のタイプが与えられる。ｃｌｉｅｎｔＤａｔａＪＳＯＮの例示的な疑似コードは次のとおりである。

｛
“ｔｙｐｅ”： “ｕｒｎ：ｍｙｃｕｓｔｏｍａｐｐ：ｏａｕｔｈ”，
“ｒｅｆｒｅｓｈ＿ｔｏｋｅｎ”： “ＲＴ＿ｖａｌｕｅ”
｝

そのため、ＷｅｂＡｕｔｈｎによって定義されたｃｈａｌｌｅｎｇｅフィールド、ｏｒｉｇｉｎフィールド、またはｔｏｋｅｎＢｉｎｄｉｎｇフィールドは、必要でない。

次に、リフレッシュ・トークン・フローのｐｏｓｔ本文全体が、次のように記述される。

ＰＯＳＴ ／ｏａｕｔｈ／ｔｏｋｅｎ

ｃｌｉｅｎｔ＿ｉｄ＝ｐｕｂｌｉｃ＿ｃｌｉｅｎｔ＆ｇｒａｎｔ＿ｔｙｐｅ＝ｒｅｆｒｅｓｈ＿ｔｏｋｅｎ＆ｒｅｆｒｅｓｈ＿ｔｏｋｅｎ＝ＲＴ＿ｖａｌｕｅ＆ａｕｔｈｅｎｔｉｃａｔｏｒＤａｔａ＝ｂ６４ｕｒｌ＿ａｕｔｈｅｎｔｉｃａｔｏｒ＿ｄａｔａ＆ｓｉｇｎａｔｕｒｅ＝ｂ６４ｕｒｌ＿ｓｉｇ

認証サーバは、ＲＴ＿ｖａｌｕｅが有効であり、サーバに知られているリフレッシュ・トークン（ＲＴ：ｒｅｆｒｅｓｈ ｔｏｋｅｎ）を表すということを保証する。認証サーバは、グラントの確立でグラントに登録された関連する公開鍵を検索し（この公開鍵が、ＦＩＤＯ用語ではａｌｌｏｗＣｒｅｄｅｎｔｉａｌｓリストになる）、次に、認証アサーションを検証することにおける妥当性確認手順の残りの部分が成功していることを確認し、これが純粋なＷｅｂＡｕｔｈｎを使用するブラウザではなく、ネイティブなシナリオであるため、いくつかの重要でない検討事項がデータ値（本発明の１つまたは複数の実施形態では、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｎａｍｅ（ＵＲＮ）であるｏｒｉｇｉｎなど）に与えられる。

本発明の１つまたは複数の実施形態では、アプリケーション・レベルの中間者（ＭＩＴＭ：Ｍａｎ Ｉｎ Ｔｈｅ Ｍｉｄｄｌｅ）攻撃を防ぐために、解決策全体の一部として、証明書ピンニングなどの他の軽減も採用される。

ここで各図を参照し、特に図１を参照すると、本発明の１つまたは複数の実施形態の実装によって、もしくは実装において、またはその両方で利用され得る例示的なシステムおよびネットワークのブロック図が示されている。サーバ１０１に関して、サーバ１０１内に示されている図示されたハードウェアおよびソフトウェアの両方を含んでいる例示的なアーキテクチャの一部またはすべてが、図１に示されたクライアント・デバイス１２３もしくはソフトウェア・デプロイ・サーバ１４９もしくはコンピュータ・リソース・サーバ１５１もしくはコンピュータ・リソース１５３もしくはアプリケーション証明書サービス・サーバ１５５もしくは人工知能（ＡＩ：ａｒｔｉｆｉｃｉａｌ ｉｎｔｅｌｌｉｇｅｎｃｅ）システム１５７もしくはブロックチェーン・ネットワーク１５９またはそれらの組み合わせによって利用されてもよいし、または図２に示されたリソース所有者２００もしくは認可サーバ２０１もしくはクライアント・デバイス２２３もしくはコンピュータ・リソース・サーバ２５１もしくはコンピュータ・リソース２５３もしくはアプリケーション証明書サービス・サーバ２５５またはそれらの組み合わせによって利用されてもよいし、または本発明の１つまたは複数の実施形態に関連付けられた他の図に示された他の処理デバイスによって利用されてもよいし、またはそれらの組み合わせであってよい。

例示的なサーバ１０１は、システム・バス１０５に結合されたプロセッサ１０３を含んでいる。プロセッサ１０３は１つまたは複数のプロセッサを利用してよく、プロセッサの各々は１つまたは複数のプロセッサ・コアを含む。ディスプレイ１０９を駆動／サポートするビデオ・アダプタ１０７も、システム・バス１０５に結合される。システム・バス１０５は、バス・ブリッジ１１１を介して入出力（Ｉ／Ｏ：ｉｎｐｕｔ／ｏｕｔｐｕｔ）バス１１３に結合される。Ｉ／Ｏインターフェイス１１５はＩ／Ｏバス１１３に結合され、Ｉ／Ｏインターフェイス１１５は、キーボード１１７、マウス１１９、媒体トレイ１２１（（ＣＤ－ＲＯＭドライバ、マルチメディア・インターフェイスなどのストレージ・デバイスを含んでよい）、および外部ＵＳＢポート１２５を含む、さまざまなＩ／Ｏデバイスとの通信を提供する。Ｉ／Ｏインターフェイス１１５に接続されたポートの形式は、コンピュータ・アーキテクチャの当業者に知られている任意のものであってよいが、一実施形態では、これらのポートの一部またはすべては、ユニバーサル・シリアル・バス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）ポートである。

図に示されるように、サーバ１０１は、ネットワーク・インターフェイス１２９を使用してネットワーク１２７と通信することができる。ネットワーク・インターフェイス１２９は、ネットワーク・インターフェイス・カード（ＮＩＣ：ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄ）などのハードウェア・ネットワーク・インターフェイスである。ネットワーク１２７は、インターネットなどの外部ネットワーク、またはイーサネット（登録商標）もしくは仮想プライベート・ネットワーク（ＶＰＮ：ｖｉｒｔｕａｌ ｐｒｉｖａｔｅ ｎｅｔｗｏｒｋ）などの内部インターネットであってよい。

ハード・ドライブ・インターフェイス１３１も、システム・バス１０５に結合される。ハード・ドライブ・インターフェイス１３１は、ハード・ドライブ１３３とインターフェイスをとる。一実施形態では、ハード・ドライブ１３３は、やはりシステム・バス１０５に結合されたシステム・メモリ１３５にデータを入力する。システム・メモリは、サーバ１０１内の最低レベルの揮発性メモリとして定義される。この揮発性メモリは、キャッシュ・メモリ、レジスタ、およびバッファを含むが、これらに限定されない、さらに高いレベルの追加の揮発性メモリ（図示されていない）を含む。システム・メモリ１３５に入力されるデータは、サーバ１０１’のオペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）１３７およびアプリケーション・プログラム１４３を含む。

ＯＳ１３７は、アプリケーション・プログラム１４３などのリソースへの透過的なユーザ・アクセスを提供するためのシェル１３９を含んでいる。一般にシェル１３９は、ユーザとオペレーティング・システムの間のインタープリタおよびインターフェイスを提供するプログラムである。より詳細には、シェル１３９は、コマンド・ライン・ユーザ・インターフェイスに入力されたコマンド、またはファイルからのコマンドを実行する。したがって、シェル１３９（コマンド・プロセッサとも呼ばれる）は通常、オペレーティング・システムの最高レベルのソフトウェア階層であり、コマンド・インタープリタとして機能する。シェルは、システム・プロンプトを提供し、キーボード、マウス、または他のユーザ入力媒体によって入力されたコマンドを解釈し、解釈されたコマンドを、処理するために適切なさらに低いレベルのオペレーティング・システム（例えば、カーネル１４１）に送信する。シェル１３９はテキストベースのライン指向ユーザ・インターフェイスであるが、本発明の１つまたは複数の実施形態が、グラフィック、音声、ジェスチャーなどの他のユーザ・インターフェイス・モードも同様に適切にサポートするということに注意する。

図に示されるように、ＯＳ１３７は、ＯＳ１３７の他の部分およびアプリケーション・プログラム１４３によって必要とされる不可欠なサービス（メモリ管理、プロセスとタスクの管理、ディスク管理、およびマウスとキーボードの管理を含む）を提供することを含めて、ＯＳ１３７のさらに低いレベルの機能を含むカーネル１４１も含んでいる。

アプリケーション・プログラム１４３は、ブラウザ１４５として例示的に示されたレンダラを含んでいる。ブラウザ１４５は、ワールド・ワイド・ウェブ（ＷＷＷ：ｗｏｒｌｄ ｗｉｄｅ ｗｅｂ）クライアント（すなわち、サーバ１０１）で、ハイパーテキスト転送プロトコル（ＨＴＴＰ：ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）メッセージングを使用してネットワーク・メッセージをインターネットに対して送受信できるようにするプログラム・モジュールおよび命令を含んでおり、このようにして、クライアント・デバイス１２３もしくはソフトウェア・デプロイ・サーバ１４９もしくはコンピュータ・リソース・サーバ１５１もしくはコンピュータ・リソース１５３もしくはアプリケーション証明書サービス・サーバ１５５もしくは他のコンピュータ・システムまたはそれらの組み合わせとの通信を可能にする。

サーバ１０１のシステム・メモリ内のアプリケーション・プログラム１４３は、コンピュータ・リソースへの安全なアクセスのためのプログラム（ＰＳＡＣＲ：Ｐｒｏｇｒａｍ ｆｏｒ Ｓｅｃｕｒｅ Ａｃｃｅｓｓ ｔｏ Ｃｏｍｐｕｔｅｒ Ｒｅｓｏｕｒｃｅｓ）１４７も含んでいる。ＰＳＡＣＲ１４７は、図２～７で説明されているプロセスを含む、下記に説明されるプロセスを実装するためのコードを含んでいる。本発明の１つまたは複数の実施形態では、サーバ１０１は、ソフトウェア・デプロイ・サーバ１４９からＰＳＡＣＲ１４７をダウンロードすることができ、このダウンロードは、実行に必要とされるまでＰＳＡＣＲ１４７のコードがダウンロードされない、オンデマンドのダウンロードを含む。本発明の１つまたは複数の実施形態では、ソフトウェア・デプロイ・サーバ１４９が、本発明に関連するすべての機能を（ＰＳＡＣＲ１４７の実行を含めて）実行するため、サーバ１０１が、ＰＳＡＣＲ１４７を実行するためにそれ自身の内部コンピューティング・リソースを使用する必要がないということにさらに注意する。

サーバ１０１に示されたハードウェア要素が、網羅的であるよう意図されておらず、本発明の１つまたは複数の実施形態によって必要とされる不可欠なコンポーネントを強調するための代表例であるということに注意する。例えば、サーバ１０１は、磁気カセット、デジタル・バーサタイル・ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋｓ）、ベルヌーイ・カートリッジなどの代替のメモリ・ストレージ・デバイスを含んでよい。これらおよび他の変形が本発明の範囲に含まれるということが意図されている。

ここで図２を参照すると、変更されたＯｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡｕｔｈ）システム２０６内で実行される本発明の１つまたは複数の実施形態の俯瞰的な概要が示されている。

ステップ１および２に示されるように、リソース所有者２００は、ユーザ・インターフェイスを介してクライアント・デバイス２２３とインターフェイスをとる人間ユーザ、またはアプリケーション・プログラム・インターフェイス（ＡＰＩ）を介して初期グラント認証情報（ｉｎｉｔｉａｌ ｇｒａｎｔ ｃｒｅｄｅｎｔｉａｌｓ）をクライアント・デバイスに提示するためにユーザによって使用されるコンピュータのいずれかであり、初期グラント認証情報をネイティブ・アプリケーション２０２に提示する。そのような認証情報の例としては、認可コード、ユーザ名およびパスワードなどが挙げられるが、これらに限定されない。

ステップ２ａ（クライアント・デバイス２２３内で発生し、図１に示されたアプリケーション証明書サービス・サーバ１５５に類似するアプリケーション証明書サービス・サーバ２５５と通信するように示されている）に表されるように、ネイティブ・アプリケーション２０２は、リソース所有者２００から受信された初期グラント認証情報をアプリケーション証明書サービス・サーバ２５５に送信する。アプリケーション証明書サービス・サーバ２５５は、ネイティブ・アプリケーション２０２が変更されておらず、本物のクライアント・デバイス２２３上で稼働していることの妥当性を確認するネイティブ・アプリケーション証明書サービスを提供する。アプリケーション証明書サービス・サーバ２５５は、ステップ３ａのペイロードに含まれているこの証明書の暗号証明を提供する。

ステップ２ｂに示されるように、次に、クライアント・デバイス２２３は、下記に説明されるように使用される公開鍵／秘密鍵ペア２０４を生成する。

ステップ３ａに示されるように、ネイティブ・アプリケーション２０２は、初期認可グラント、（ネイティブ・アプリケーション証明書サービスによって生成された）証明書の結果、（ネイティブ・アプリケーション２０２によって生成された）公開鍵、および対応する秘密鍵を使用して署名された初期認可グラントの署名を、認可サーバ２０１に送信する。

ステップ３ｂに示されるように、認可サーバは、アプリケーション証明書サービスを使用してアプリケーションの証明書の結果を検証する。証明書サービスによって証明書が検証されない場合、登録が中断される。

ステップ３ｃに示されるように、認可サーバ２０１は、初期認可グラントの署名を使用して公開鍵を検証し、公開鍵を格納し、この公開鍵は、コンピュータ・リソース２５３へのアクセス権限を付与するために下記のステップで使用される。

ステップ４に示されるように、認可サーバ２０１は、初期アクセス・トークンおよびリフレッシュ・トークンを生成し、それらをネイティブ・アプリケーションに返す。初期アクセス・トークンは、ネイティブ・アプリケーション２０２がコンピュータ・リソース２５３にアクセスすることを可能にし、リフレッシュ・トークンは、認可サーバ２０１がアクセス・トークンをリフレッシュする／新しくすることを可能にする。

ステップ５に示されるように、ネイティブ・アプリケーション２０２は、アクセス・トークン（すなわち、認可サーバ２０１による生成がリフレッシュ・トークンによって認可されている初期アクセス・トークンまたは新しいアクセス・トークンのいずれか）を使用して、リソース所有者２００の代わりにネイティブ・アプリケーション２０２によってコンピュータ・リソース２５３にアクセスする。

アクセス・トークンには制限された（例えば、５分未満の）有効期間があり、したがってアクセス・トークンは、リフレッシュ・トークンを使用することによって定期的にリフレッシュされる必要がある。

したがって、ステップ６に示されるように、ネイティブ・アプリケーション２０２は、認可サーバ２０１を使用して現在のリフレッシュ・トークンを新しいアクセス・トークンおよび新しいリフレッシュ・トークンに定期的に交換する。すなわち、リフレッシュ・トークンは使い捨てであるため、新しいリフレッシュ・トークンは古い／現在のリフレッシュ・トークンを置き換える。認可サーバ２０１に新しいリフレッシュ・トークンを生成させるようにネイティブ・アプリケーション２０２から要求する際には、ネイティブ・アプリケーション２０２によって秘密鍵を用いて古いリフレッシュ・トークンが署名され、この署名は、トークン・リフレッシュ・フローの一部として認可サーバ２０１に送信される。したがって、ステップ３ａで受信された公開鍵を使用して古いリフレッシュ・トークンの署名が検証された場合にのみ、認可サーバ２０１は、新しいアクセス・トークンおよび新しいリフレッシュ・トークンを生成して返す。

ここで図３を参照すると、本発明の１つまたは複数の実施形態において実行される１つまたは複数の動作の俯瞰的なフローチャートが示されている。

開始ブロック３０１の後、ブロック３０３に示され、図２で詳細に説明されるように、認可サーバは、デバイス上のネイティブ・アプリケーションから、初期認可グラント、デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、およびネイティブ・アプリケーションの信頼性の証明書を受信する。

ブロック３０５に示され、図２で詳細に説明されるように、認可サーバは、デバイス上のネイティブ・アプリケーションから、リフレッシュ・トークン、および秘密鍵を使用して作成されたリフレッシュ・トークンのデジタル署名を受信する。本発明の１つまたは複数の実施形態では、あらかじめ登録されている公開鍵を用いてリフレッシュ・トークンが検証された場合にのみ、認可サーバはリフレッシュ・トークンを認識する。

ブロック３０７に示され、図２で詳細に説明されるように、次に、認可サーバが、リフレッシュ・トークンのデジタル署名の妥当性を確認する。

ブロック３０９に示され、図２で詳細に説明されるように、デバイス上のネイティブ・アプリケーションからのリフレッシュ・トークンの妥当性を確認することに応答して、認可サーバは、新しいアクセス・トークンおよび新しいリフレッシュ・トークンを認可サーバからデバイス上のネイティブ・アプリケーションに送信する。この新しいアクセス・トークンは、デバイス上のネイティブ・アプリケーションがコンピュータ・リソースにアクセスすることを可能にする。

フローチャートは、終了ブロック３１１で終了する。

本発明の１つまたは複数の実施形態では、本明細書において説明されるように、デバイス上で公開鍵／秘密鍵が生成され、秘密鍵が、デバイスにバインドされることによって、不正使用または抽出から保護される。すなわち、公開鍵／秘密鍵ペアを生成したクライアント・デバイスのみが秘密鍵にアクセスできるため、悪意のある行為者によって秘密鍵が「ハッキング」され得ない。

本発明の１つまたは複数の実施形態では、認可サーバおよびクライアントは、本発明によって変更されているＯｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡｕｔｈ）アーキテクチャ（例えば、図２に示されている変更されたＯｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡｕｔｈ）システム２０６）のコンポーネントである。

本発明の１つまたは複数の実施形態では、前述したように、トランスポート層セキュリティ（ＴＬＳ）プロトコル拡張を使用せずに、クライアントからのアプリケーション・ペイロード内のデータを使用して、リフレッシュ認可グラント（ｒｅｆｒｅｓｈ ａｕｔｈｏｒｉｚａｔｉｏｎ ｇｒａｎｔ）が、そのリフレッシュ認可グラントの発行先だったデバイスから来ることを検証される。

本発明の１つまたは複数の実施形態では、（例えば、図２に示された認可サーバ２０１内の）１つまたは複数のプロセッサは、リフレッシュ認可グラント処理の一部としてＦａｓｔ Ｉｄｅｎｔｉｔｙ Ｏｎｌｉｎｅ（ＦＩＤＯ）認証を適用することによって、デバイスのアイデンティティを確認する。ＦＩＤＯもしくはＦＩＤＯ２またはその両方の詳細は、上記に説明されている。

本発明の１つまたは複数の実施形態では、デバイスのアイデンティティは、その特定のデバイスによって使用され、その特定のデバイスを特定のＩＰアドレスに関連付けるルックアップ・テーブルによって識別されるインターネット・プロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス、その特定のデバイスによってネットワーク・セグメント内の通信においてネットワーク・アドレスとして使用するためにネットワーク・インターフェイス・コントローラに割り当てられた媒体アクセス制御（ＭＡＣ：Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）、その特定のデバイス用に生成された、その特定のデバイスに固有のＵｎｉｆｏｒｍ Ｕｎｉｖｅｒｓａｌ Ｉｄｅｎｔｉｆｉｅｒ（ＵＵＩＤ）などの、その特定のデバイスの識別子によって決定されるか、もしくは確認されるか、またはその両方が行われる。

そのため、本発明の１つまたは複数の実施形態では、認可サーバは、リフレッシュ・トークンが、初期認可グラントおよび秘密鍵／公開鍵ペアの公開鍵を作成した特定のデバイスから来ている場合にのみ、デバイス上のネイティブ・アプリケーションからのリフレッシュ・トークンの妥当性を確認する。認可サーバは、本発明の１つまたは複数の実施形態では、その特定のデバイスが初期認可グラント、デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、ネイティブ・アプリケーションの信頼性の証明書、およびリフレッシュ・トークンを認可サーバに送信するときに、その特定のデバイスから認可サーバに送信されるヘッダーの一部である、特定のデバイスによって現在使用されているＩＰアドレス、特定のデバイスによって現在使用されているＭＡＣアドレス、特定のデバイスのＵＵＩＤなどによって、その特定のデバイスを識別する。

したがって、本発明の１つまたは複数の実施形態では、認可サーバは、そのデバイス内または別のデバイス内のどのアプリケーションがリフレッシュ・トークン、初期認可グラント、もしくは秘密鍵／公開鍵ペアの公開鍵、またはそれらの組み合わせを認可サーバに送信したかにかかわらず、リフレッシュ・トークンが、初期認可グラント、および秘密鍵／公開鍵ペアの公開鍵を作成した特定のデバイスから来ている場合にのみ、デバイス上のネイティブ・アプリケーションからのリフレッシュ・トークンの妥当性を確認する。

本発明の１つまたは複数の実施形態では、アクセス・トークンもしくはリフレッシュ・トークンまたはその両方を生成するために図２に示された認可サーバ２０１によって使用されるデータ／要素／係数が有効であることを、そのようなデータ／要素／係数をブロックチェーン台帳に格納することによって保証するために、ブロックチェーン・システムが使用される。

したがって、図４を参照すると、本発明の１つまたは複数の実施形態では、「信頼できる唯一の位置」でトランザクションを安全かつ透過的に格納し、追跡し、管理するために、ブロックチェーン・ネットワーク４５９（図１に示されたブロックチェーン・ネットワーク１５９に類似している）が、インフラストラクチャ（例えば、チェーンコードの実行）およびサービス（例えば、アイデンティティ管理などのメンバーシップ・サービス）を提供するために使用される。ブロックチェーン・ネットワーク４５９は、システム内でこれまでに行われたありとあらゆるトランザクションの（信頼できる唯一の位置の）検証可能な記録を維持する。データがブロックチェーンに入力された後に、それらのデータは消去され得ず（不変性）、変更され得ない。すなわち、記録に対する変更は、新しいトランザクションを発行／導入することと見なされる。したがって、そのような消去または変更の禁止は、データの監査可能性および検証可能性を保証する。

ブロックチェーン・ネットワーク４５９（「ブロックチェーン・ファブリック」、「ブロックチェーン・システム」、「オープン・ブロックチェーン」、または「Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃ」としても知られている）は、参加している関係者間で実行されて共有されているすべてのトランザクションまたはデジタル・イベントの記録の分散データベースに基づく。システム内の参加者の大部分を組み込む合意メカニズムを介して、ブロックチェーン内の個別のトランザクションが妥当性を確認されるか、または検証される。このようにして、反論できない記録を許可されたパブリックな台帳に作成することによって、参加している実体が、デジタル・イベントが発生したということを確実に知ることができるようにする。

トランザクションが実行されるときに、それに対応するチェーンコードが、システムの複数の妥当性を確認しているピアによって実行される。例えば、図４に示されるように、ピア４１８ａ～４１８ｄが、トランザクション・パラメータの有効性を確立し、それらのピアが合意に達した後に、新しいブロックが生成されて、ブロックチェーン・ネットワークに追加される。すなわち、監視コンピュータ４０１（例えば、図２に示された認証サーバ２０１もしくは図１に示されたサーバ１０１またはその両方）上で稼働しているアプリケーション・プロセス４０８（例えば図２で説明されたように、認証サーバ２０１で実行されるＯＡｕｔｈプロセス）が、図に示されたアプリ４０３（例えば、ＯＡｕｔアプリケーション）などのアプリケーションを実行し、ソフトウェア開発キット（ＳＤＫ：ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｋｉｔ）４１０が、一般的なリモート・プロシージャ呼び出し（ｇｒｐｃ：ｇｅｎｅｒａｌ ｒｅｍｏｔｅ ｐｒｏｃｅｄｕｒｅ ｃａｌｌｓ）を使用して、ピアツーピア・ネットワーク４０４をサポートするメンバーシップ・サービス４０９と通信することを引き起こし、ピアツーピア・ネットワーク４０４は、ピア４１８ａ～４１８ｇを使用してブロックチェーン４１６をサポートする。

図５を参照すると、本発明の１つまたは複数の実施形態において利用されるような、ブロックチェーン４１６内の例示的なブロックチェーン台帳５００が示されている。

本発明の１つまたは複数の実施形態では、ブロックチェーン台帳５００が、図４に示されたピアツーピア・ネットワーク４０４もサポートするか、もしくは利用するか、またはその両方を行う図２に示された認証サーバ２０１もしくは図１に示されたサーバ１０１またはその両方などの監視コンピュータの識別子（ブロック５０２に示されている）を含んでいる。例えば、本発明の１つまたは複数の実施形態では、ブロック５０２が、監視コンピュータのインターネット・プロトコル（ＩＰ：ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）アドレス、ユニフォーム・リソース・ロケータ（ＵＲＬ：ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）などを含む。この情報は、本明細書に記載されたプロセス・フローに関連するトランザクションを受信するために、図４に示されたピアツーピア・ネットワーク４０４内のピアによって使用される。

本発明の１つまたは複数の実施形態では、ブロックチェーン台帳５００は、第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンを生成するために認証サーバによって利用される初期認可グラント（ブロック５０４）、公開鍵（ブロック５０６）、ネイティブ・アプリケーションの信頼性の証明書（ブロック５０８）、リフレッシュ・トークン（ブロック５１０）、およびリフレッシュ・トークンのデジタル署名（ブロック５１２）のコピーも含む。その後、ブロックチェーン台帳５００からの情報が、最初に認証サーバに提示された（ただし、必ずしも認証サーバによって使用されない）ときから変化していないと保証される形態で取り出される。すなわち、初期認可グラント、デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、およびネイティブ・アプリケーションの信頼性の証明書が作成され、認可サーバおよびブロックチェーンの両方に並列に送信される。しかし、初期認可グラント、デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、およびネイティブ・アプリケーションの信頼性の証明書は、認可サーバによって使用される前に破損する可能性がある。そのため、初期認可グラント、デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、およびネイティブ・アプリケーションの信頼性の証明書の破損していないバージョンがブロックチェーンに格納され、これらは、あらゆるデータ破損を防ぐブロックチェーン・システムに格納される。

図４に示されたブロックチェーン・ネットワーク４５９の例示的動作が、図６に示されている。ステップ６０１で説明されるように、コンピューティング・デバイス（例えば、１つまたは複数の実施形態では、図１に示されたサーバ１０１もしくは図２に示された認可サーバ２０１またはその両方である、図４に示された監視コンピュータ４０１）が、トランザクションを実行する（例えば、図２で前述したように、デバイス上のネイティブ・アプリケーション、初期認可グラント、デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、ネイティブ・アプリケーションの信頼性の証明書、リフレッシュ・トークン、秘密鍵を使用して作成されたリフレッシュ・トークンのデジタル署名などを受信する）。ステップ６０３に示されるように、監視コンピュータ４０１は、セキュア・ハッシュ・アルゴリズム（ＳＨＡ－２）などのハッシュ・アルゴリズムを使用してトランザクションをハッシュし、次に、デジタル署名を使用してそのハッシュに署名する。ステップ６０５で説明されるように、その後、この署名が、図４に示されたピアツーピア・ネットワーク４０４にブロードキャストされる。ステップ６０７に示されるように、ピアツーピア・ネットワーク４０４内のピア（例えば、ピア４１８ａ）が、トランザクションを図４に示されたブロックチェーン４１６に集約する。ブロック６０９に示されるように、各ブロックは、前のブロックへのリンクを含む。新たに修正されたブロックチェーン４１６は、ピア４１８ａ～４１８ｄのうちの１つまたは複数の他のピアによって、もしくは他の認可されたブロックチェーン・システムからの他のピアによって、またはその両方によって、妥当性を確認される（ステップ６１１）。ステップ６１３で説明されるように、次に、妥当性を確認されたブロックがピア４１８ｂ～４１８ｄにブロードキャストされる。これらのピア４１８ｂ～４１８ｄは、新しいブロックをリッスンして受信し、それらのブロックをブロックチェーン４１６の自分のコピーにマージする（ステップ６１５）。

このようにして、図４～図６で説明されたブロックチェーン・ファブリックは、分散型台帳を提供するブロックチェーン・デプロイメント技術を表し、分散型台帳は、持続して、トランザクションと呼ばれる、複数の参加者間で共有されるデジタル・イベントを管理し、各参加者は、これらのイベントにおいて利害関係がある。台帳は、参加者間の合意のみによって更新されることが可能である。さらに、トランザクションが記録された後に、それらのトランザクションは変更され得ない（変更不可能である）。そのようなすべての記録されたトランザクションは、参加者からの合意の証明を使用して、暗号によって検証可能であり、このようにして、トランザクションの発祥を追跡する堅牢な来歴メカニズムを提供する。

そのため、ブロックチェーン・ファブリックは、分散ネットワークを使用してイベントのデジタル台帳を維持し、したがって、各ピアに格納されたブロックチェーンが以前のブロックに依存し、これによって、ブロックチェーン内のその後のブロックに保護されたデータを提供するため、デジタル台帳の優れたセキュリティを実現する。

すなわち、本明細書に記載されたブロックチェーン・ファブリックは、分散的システムを提供し、分散的システム内のすべてのノードが、ブロックチェーンのコピーを含む。これによって、信頼できる第三者によって管理された集中データベースを持つ必要性を回避する。トランザクションは、ソフトウェア・アプリケーションを使用してネットワークにブロードキャストされる。ネットワーク・ノードは、トランザクションの妥当性を確認し、それらのトランザクションを自分のコピーに追加し、その後、これらの追加を他のノードにブロードキャストすることができる。しかし前述したように、それにもかかわらず、ブロックチェーンは、１つまたは複数の以前のブロックに基づいて各新しいブロックが保護される（例えば、ハッシュされる）ため、非常に安全である。

したがって、本発明の１つまたは複数の実施形態では、図３で上記に説明された新しいアクセス・トークンが第１の新しいアクセス・トークンとして識別され、新しいリフレッシュ・トークンが第１の新しいリフレッシュ・トークンとして識別されるということを仮定する。

本発明の１つまたは複数の実施形態では、ブロックチェーン・アーキテクチャ（例えば、図１に示されたサーバ１０１、または図２に示された認可サーバ２０１、または図４に示された監視コンピュータ４０１もしくはブロックチェーン・ネットワーク４５９またはその両方、またはそれらの組み合わせ）は、第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンを生成するために認証サーバによって利用される初期認可グラント、公開鍵、ネイティブ・アプリケーションの信頼性の証明書、リフレッシュ・トークン、およびリフレッシュ・トークンのデジタル署名を含む、格納されたブロックチェーンを格納する。

監視コンピュータ（例えば、認可サーバ２０１）は、格納されたブロックチェーンをブロックチェーン・アーキテクチャから取り出し、格納されたブロックチェーンからの初期認可グラント、公開鍵、ネイティブ・アプリケーションの信頼性の証明書、リフレッシュ・トークン、およびリフレッシュ・トークンのデジタル署名を使用することによって、第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンを生成する。

１つまたは複数のプロセッサは、第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンが、第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンに一致するということを決定するために、第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンを、第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンと比較する。

第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンが第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンに一致するということの決定に応答して、１つまたは複数のプロセッサは、認可サーバによって生成された第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンが認可サーバからネイティブ・アプリケーションに送信されることを認可する。

本発明の１つまたは複数の実施形態では、新しいアクセス・トークンが第１の新しいアクセス・トークンであり、新しいリフレッシュ・トークンが第１の新しいリフレッシュ・トークンであり、今説明したブロックチェーンが、第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンを生成するために認証サーバによって利用される初期認可グラント、公開鍵、ネイティブ・アプリケーションの信頼性の証明書、リフレッシュ・トークン、およびリフレッシュ・トークンのデジタル署名を含み、格納されたブロックチェーンがブロックチェーン・アーキテクチャから取り出され、認証サーバが、格納されたブロックチェーンからの初期認可グラント、公開鍵、ネイティブ・アプリケーションの信頼性の証明書、リフレッシュ・トークン、およびリフレッシュ・トークンのデジタル署名を使用することによって第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンを生成する。

しかし、これらの１つまたは複数の実施形態では、１つまたは複数のプロセッサは、第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンが、第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンに一致しないということを決定するために、第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンを、第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンと比較する。そのため、第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンが第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンに一致しないということの決定に応答して、１つまたは複数のプロセッサは、認可サーバからネイティブ・アプリケーションへの認可サーバによって生成された第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンの送信を阻止する。

したがって、ブロックチェーンの内容は、第１の新しいアクセス・トークンおよび第１の新しいリフレッシュ・トークンを生成するために認証サーバによって利用される初期認可グラント、公開鍵、ネイティブ・アプリケーションの信頼性の証明書、リフレッシュ・トークン、およびリフレッシュ・トークンのデジタル署名が有効であることを、ブロックチェーン内のそれらの以前の格納によって保証されているとして確認するために使用される。

本発明の１つまたは複数の実施形態では、認可サーバが生成するアクセス・トークンおよびリフレッシュ・トークンの妥当性を確認するために、人工知能（例えば、ニューラル・ネットワーク）が使用される。

次に、図７を参照すると、本発明の１つまたは複数の実施形態において使用される例示的な人工知能システムは、本発明の１つまたは複数の実施形態において利用されるような（図１に示された人工知能システム１５７に類似する）深層ニューラル・ネットワーク（ＤＮＮ：ｄｅｅｐ ｎｅｕｒａｌ ｎｅｔｗｏｒｋ）７５７である。ＤＮＮ７５７内のノードは、ハードウェア・プロセッサ、仮想プロセッサ、またはソフトウェア・アルゴリズムを表すか、またはハードウェア・プロセッサ、仮想プロセッサ、もしくはソフトウェア・アルゴリズム、またはそれらの組み合わせを表す。

本発明の１つまたは複数の実施形態では、ＤＮＮ７５７は、ブロック７０２に示されるように、ニューラル・ネットワークによって生成されたアクセス・トークンもしくはニューラル・ネットワークによって生成されたリフレッシュ・トークンまたはその両方を生成するようにトレーニングされる。

ＤＮＮ７５７は、ブロック７０２に示されるように、認可サーバのデータ７００（例えば、新しいアクセス・トークンおよび新しいリフレッシュ・トークンを生成するために認証サーバによって利用される初期認可グラント、公開鍵、ネイティブ・アプリケーションの信頼性の証明書、リフレッシュ・トークン、およびリフレッシュ・トークンのデジタル署名）を使用してニューラル・ネットワークによって生成されたアクセス・トークンもしくはニューラル・ネットワークによって生成されたリフレッシュ・トークンまたはその両方を生成するようにトレーニングされている。ＤＮＮ７５７は、既知のニューラル・ネットワークによって生成されるアクセス・トークンもしくはニューラル・ネットワークによって生成されるリフレッシュ・トークンまたはその両方を生成するのに使用される、さまざまな既知の種類の初期認可グラント、既知の種類の公開鍵、既知の種類のネイティブ・アプリケーションの信頼性の証明書、既知の種類のリフレッシュ・トークン、および既知の種類のリフレッシュ・トークンのデジタル署名を使用することによってトレーニングされる。

ＤＮＮ７５７は、本発明の１つまたは複数の実施形態において使用される、例示的な種類のニューラル・ネットワークである。本発明の１つまたは複数の実施形態において使用され得る他のニューラル・ネットワークは、畳み込みニューラル・ネットワーク（ＣＮＮ：ｃｏｎｖｏｌｕｔｉｏｎａｌ ｎｅｕｒａｌ ｎｅｔｗｏｒｋｓ）および深層学習の他の形態を使用するニューラル・ネットワークを含む。

ニューラル・ネットワークは、名前が含意するように、生物学的ニューラル・ネットワーク（例えば、人間の脳）を真似て大まかにモデル化される。生物学的ニューラル・ネットワークは、互いに影響を与える一連の相互接続されたニューロンで構成されている。例えば、シナプスによって、（第１のニューロンからの）第２のニューロンによって受け取られる神経伝達物質の放出を介して、第１のニューロンが第２のニューロンに電気的に接続され得る。これらの神経伝達物質は、第２のニューロンの興奮または抑制を引き起こすことができる。興奮／抑制にある相互接続されたニューロンのパターンは、最終的に、思考、筋肉の動き、記憶検索などを含む生物学的結果につながる。生物学的ニューラル・ネットワークのこの説明は非常に簡略化されているが、俯瞰的な概要としては、１つまたは複数の生物学的ニューロンが、１つまたは複数の他の生体電気的に接続された生物学的ニューロンの動作に影響を与えるということである。

電子ニューラル・ネットワークは、同様に電子ニューロンで構成されている。しかし、生物学的ニューロンとは異なり、電子ニューロンは技術的に「抑制性」になることはなく、さまざまな程度に「興奮性」になるに過ぎない。

ＤＮＮ７５７内の電子ニューロン（本明細書では、単に「ニューロン」または「ノード」とも呼ばれる）は、入力層７０３、隠れ層７０５、および出力層７０７として知られている層に配置される。入力層７０３は、入力データを受け取ってニューロンの一連の隠れ層（例えば、隠れ層７０５）に送信するニューロン／ノードを含み、隠れ層のうちの１つの層からのニューロンが、隠れ層７０５のうちの次の層内のすべてのニューロンと相互接続される。次に、隠れ層７０５のうちの最終的な層が、計算結果を出力層７０７に出力し、出力層７０７は多くの場合、ベクトル情報を保持する単一のノードである。

前述したように、図に示されたＤＮＮ７５７内の各ノードは、図に示されたニューロン７０９などの電子ニューロンを表す。ブロック７１１に示されるように、（ニューロン７０９を含む）各ニューロンは、少なくとも４つの特徴（アルゴリズム、出力値、重み、およびバイアス値）を機能的に含む。

アルゴリズムは、１つまたは複数の上流のニューロンからのデータを処理するための数学的式である。例えば、中央の隠れ層７０５に示されたニューロンのうちの１つまたは複数が、データ値をニューロン７０９に送信すると仮定する。次に、ニューロン７０９は、１つまたは複数の出力値を作成するために、ブロック７１１に示された数学関数を実行することによって、これらのデータ値を処理し、その後、これらの出力値が、隠れ層７０５内の別のニューロンまたは出力層７０７内のニューロンなどの、別のニューロンに送信される。各ニューロンは、そのニューロンもしくは他の接続されたニューロンまたはその両方に固有である重みも有する。さらに、出力値がバイアス値に加算されて、出力値を増やすか、または減らし、ＤＮＮ７５７がさらに「微調整される」ことを可能にする。

例えば、ニューロン７１３がデータの一部分の分析結果をニューロン７０９に送信していると仮定する。ニューロン７０９は、特にニューロン７１３から来るデータがどの程度重要であるかを定義する第１の重みを有する。このデータが重要である場合、ニューロン７１３から来るデータが重く重み付けされるか、もしくはバイアス値によって増やされるか、またはその両方が実行され、このようにして、ニューロン７０９内の数学関数に、出力層７０７内のニューロンにより大きな影響を与えるより大きな出力を生成させる。同様に、ニューロン７１３が、ニューロン７０９の動作にとって重要であるということが決定された場合、ニューロン７０９が、ニューロン７１３内の数学関数の出力のより大きな値を受信するように、ニューロン７１３の重みが増やされる。代替として、ニューロン７０９の出力に影響を与えるために使用される重みもしくはバイアスまたはその両方を減らすことによって、ニューロン７０９の出力が最小限に抑えられ得る。これらの重み／バイアスは、信頼できる出力が出力層７０７から生じるように、ＤＮＮ７５７内のすべてのニューロンのうちの１つ、一部、またはすべてについて調整可能である。本発明の１つまたは複数の実施形態では、重みの値およびバイアス値を見つけることは、ニューラル・ネットワークをトレーニングすることによって自動的に実行される。本発明の１つまたは複数の実施形態では、学習率、ドロップアウト、正則化係数などのハイパーパラメータを調整するために、手動による調整が適用される。そのため、ニューラル・ネットワークをトレーニングすることは、損失関数を最小化するための最適な重みおよびバイアス値に達するまで、複数のデータセットに対して前方伝搬および後方伝搬を実行することを含む。損失関数は、さまざまな入力に対するニューラル・ネットワークによる予測値および実際のラベルにおける差を測定する。

ＤＮＮ７５７トレーニング中に手動で調整される場合、重みは、出力層７０７からの出力が期待値に一致するまで繰り返されられる方法で調整される。

自動的に調整される場合、「後方伝搬」を使用して重み（もしくは数学関数またはその両方）が調整され、後方伝搬では、各重み値をどの方向に調整するべきかを決定する「勾配降下」法を使用することによって、ニューロンの重み値が調整される。この勾配降下プロセスは、出力層７０７からの出力が改善するまで（例えば、適切なアクセス・トークンおよびリフレッシュ・トークンを正確に生成するまで）、各ニューロンにおける重みを特定の方向に移動する。

図７に示されるように、ニューロンの個々の層が異なる陰影を付けられており、本発明の１つまたは複数の実施形態では、これらの層が、リフレッシュ・トークンを生成するときに認証サーバによって使用される情報のさまざまな側面を認識するために特にトレーニングされるということを示している。

したがって、本発明の１つまたは複数の実施形態では、隠れ層７０５内に、認可グラントの種類を評価するように設計されたニューロンを含んでいる層７０６、公開鍵の種類を評価するように設計されたニューロンを含んでいる層７０８、およびネイティブ・アプリケーションの信頼性の証明書の種類を評価するように設計されたニューロンを含んでいる層７１０が存在する。

次に、層７１０からのニューロンの出力が、出力層７０７で検出される値を制御する。

したがって、本発明の１つまたは複数の実施形態は、ニューラル・ネットワークに、初期認可グラント、公開鍵、ネイティブ・アプリケーションの信頼性の証明書、リフレッシュ・トークン、およびリフレッシュ・トークンのデジタル署名を入力し、ニューラル・ネットワークは、ニューラル・ネットワークによって生成されたアクセス・トークンおよびニューラル・ネットワークによって生成されたリフレッシュ・トークンを生成するようにトレーニングされる。次に、１つまたは複数のプロセッサは、認可サーバによって生成された新しいアクセス・トークンおよび新しいリフレッシュ・トークンの妥当性を確認するために、認可サーバによって生成された新しいアクセス・トークンおよび新しいリフレッシュ・トークンを、ニューラル・ネットワークによって生成されたアクセス・トークンおよびニューラル・ネットワークによって生成されたリフレッシュ・トークンと比較する。

本発明の１つまたは複数の実施形態では、１つまたは複数のプロセッサは、新しいアクセス・トークンおよび新しいリフレッシュ・トークンがニューラル・ネットワークによって生成されたアクセス・トークンおよびニューラル・ネットワークによって生成されたリフレッシュ・トークンに一致するということを決定する。新しいアクセス・トークンおよび新しいリフレッシュ・トークンがニューラル・ネットワークによって生成されたアクセス・トークンおよびニューラル・ネットワークによって生成されたリフレッシュ・トークンに一致するということの決定に応答して、１つまたは複数のプロセッサは、新しいアクセス・トークンおよび新しいリフレッシュ・トークンをネイティブ・アプリケーションに送信する。

本発明の１つまたは複数の実施形態では、１つまたは複数のプロセッサは、新しいアクセス・トークンおよび新しいリフレッシュ・トークンがニューラル・ネットワークによって生成されたアクセス・トークンおよびニューラル・ネットワークによって生成されたリフレッシュ・トークンに一致しないということを決定する。新しいアクセス・トークンおよび新しいリフレッシュ・トークンがニューラル・ネットワークによって生成されたアクセス・トークンおよびニューラル・ネットワークによって生成されたリフレッシュ・トークンに一致しないということの決定に応答して、１つまたは複数のプロセッサは、ネイティブ・アプリケーションへの新しいアクセス・トークンおよび新しいリフレッシュ・トークンの送信を阻止する。

したがって、本発明の１つまたは複数の実施形態では、ニューラル・ネットワークは、前述の認証サーバによって実行される作業の妥当性を確認するか、またはこの作業を無効にする。

そのため、本明細書において提示されたさまざまな実施形態で説明されるように、ネイティブ・アプリケーションの信頼性の証明書は、ネイティブ・アプリケーションおよびデバイスの完全性および信頼性を保証する。

１つまたは複数の実施形態では、本発明は、クラウド・コンピューティングを使用して実装される。それにもかかわらず、本開示にはクラウド・コンピューティングの詳細な説明が含まれているが、本明細書において示された内容の実装が、クラウド・コンピューティング環境に限定されないということが、あらかじめ理解される。むしろ、本発明の実施形態は、現在既知であるか、または今後開発される任意の他の種類のコンピューティング環境と組み合わせて実装され得る。

クラウド・コンピューティングは、構成可能な計算リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールへの便利なオンデマンドのネットワーク・アクセスを可能にするためのサービス提供モデルであり、管理上の手間またはサービス・プロバイダとのやりとりを最小限に抑えて、これらのリソースを迅速にプロビジョニングおよび解放することができる。このクラウド・モデルは、少なくとも５つの特徴、少なくとも３つのサービス・モデル、および少なくとも４つのデプロイメント・モデルを含む。

特徴は、次のとおりである。

オンデマンドのセルフサービス：クラウドの利用者は、サーバの時間およびネットワーク・ストレージなどの計算能力を一方的に、サービス・プロバイダとの人間的なやりとりを必要とせず、必要に応じて自動的にプロビジョニングすることができる。

ブロード・ネットワーク・アクセス：能力は、ネットワークを経由して利用可能であり、標準的なメカニズムを使用してアクセスできるため、異種のシン・クライアントまたはシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による利用を促進する。

リソース・プール：プロバイダの計算リソースは、プールされて、マルチテナント・モデルを使用して複数の利用者に提供され、さまざまな物理的および仮想的リソースが、要求に従って動的に割り当ておよび再割り当てされる。利用者は通常、提供されるリソースの正確な場所に関して管理することも知ることもないという点において、場所に依存しないという感覚があるが、それでも、さらに高い抽象レベルでは場所（例えば、国、州、またはデータセンター）を指定できる。

迅速な順応性：能力は、迅速かつ柔軟に、場合によっては自動的にプロビジョニングされ、素早くスケールアウトし、迅速に解放されて素早くスケールインすることができる。プロビジョニングに使用できる能力は、利用者には、多くの場合、任意の量をいつでも無制限に購入できるように見える。

測定されるサービス：クラウド・システムは、計測機能を活用することによって、サービスの種類（例えば、ストレージ、処理、帯域幅、およびアクティブなユーザのアカウント）に適した抽象レベルで、リソースの使用を自動的に制御および最適化する。リソースの使用量は監視、制御、および報告することができ、利用されるサービスのプロバイダと利用者の両方に透明性が提供される。

ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：利用者に提供される能力は、クラウド・インフラストラクチャ上で稼働しているプロバイダのアプリケーションの利用である。それらのアプリケーションは、Ｗｅｂブラウザ（例えば、Ｗｅｂベースの電子メール）などのシン・クライアント・インターフェイスを介して、さまざまなクライアント・デバイスからアクセスできる。利用者は、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または個々のアプリケーション機能を含む基盤になるクラウド・インフラストラクチャを、限定的なユーザ固有のアプリケーション構成設定を行う可能性を除き、管理することも制御することもない。

ＰａａＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）：利用者に提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、利用者が作成または取得したアプリケーションをクラウド・インフラストラクチャにデプロイすることである。利用者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、デプロイされたアプリケーション、および場合によってはアプリケーション・ホスティング環境の構成を制御することができる。

ＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：利用者に提供される能力は、処理、ストレージ、ネットワーク、および他の基本的な計算リソースのプロビジョニングであり、利用者は、オペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアをデプロイして実行できる。利用者は、基盤になるクラウド・インフラストラクチャを管理することも制御することもないが、オペレーティング・システム、ストレージ、デプロイされたアプリケーションを制御することができ、場合によっては、選ばれたネットワーク・コンポーネント（例えば、ホスト・ファイアウォール）を限定的に制御できる。

デプロイメント・モデルは、次のとおりである。

プライベート・クラウド：このクラウド・インフラストラクチャは、組織のためにのみ運用される。１つまたは複数の実施形態では、このクラウド・インフラストラクチャは、この組織もしくはサード・パーティによって管理されるか、もしくはオンプレミスもしくはオフプレミスに存在するか、またはその両方である。

コミュニティ・クラウド：このクラウド・インフラストラクチャは、複数の組織によって共有され、関心事（例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンスに関する考慮事項）を共有している特定のコミュニティをサポートする。１つまたは複数の実施形態では、このクラウド・インフラストラクチャは、これらの組織もしくはサード・パーティによって管理されるか、またはオンプレミスもしくはオフプレミスに存在するか、またはその両方である。

パブリック・クラウド：このクラウド・インフラストラクチャは、一般ユーザまたは大規模な業界団体が使用できるようになっており、クラウド・サービスを販売する組織によって所有される。

ハイブリッド・クラウド：このクラウド・インフラストラクチャは、データおよびアプリケーションの移植を可能にする標準化された技術または独自の技術（例えば、クラウド間の負荷バランスを調整するためのクラウド・バースト）によって固有の実体を残したまま互いに結合された２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の複合である。

クラウド・コンピューティング環境は、ステートレス、疎結合、モジュール性、および意味的相互運用性に重点を置いたサービス指向の環境である。クラウド・コンピューティングの中心になるのは、相互接続されたノードのネットワークを備えるインフラストラクチャである。

ここで図８を参照すると、例示的なクラウド・コンピューティング環境５０が示されている。図示されるように、クラウド・コンピューティング環境５０は、クラウドの利用者によって使用されるローカル・コンピューティング・デバイス（例えば、パーソナル・デジタル・アシスタント（ＰＤＡ）または携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、もしくは自動車コンピュータ・システム５４Ｎ、またはそれらの組み合わせなど）が互いに通信する、１つまたは複数のクラウド・コンピューティング・ノード１０を含んでいる。さらに、ノード１０は、互いに通信する。一実施形態では、これらのノードは、前述したプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、もしくはハイブリッド・クラウド、またはそれらの組み合わせなどの１つまたは複数のネットワーク内で、物理的または仮想的にグループ化される（図示されていない）。これによって、クラウド・コンピューティング環境５０は、クラウドの利用者がローカル・コンピューティング・デバイス上でリソースを維持する必要のないインフラストラクチャ、プラットフォーム、もしくはＳａａＳ、またはそれらの組み合わせを提供できる。図８に示されたコンピューティング・デバイス５４Ａ～５４Ｎの種類は、例示のみが意図されており、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、任意の種類のネットワークもしくはネットワーク・アドレス可能な接続（例えば、Ｗｅｂブラウザを使用した接続）またはその両方を経由して任意の種類のコンピュータ制御デバイスと通信することができると理解される。

ここで図９を参照すると、クラウド・コンピューティング環境５０（図９）によって提供される機能的抽象レイヤのセットが示されている。図８に示されたコンポーネント、レイヤ、および機能は、例示のみが意図されており、本発明の実施形態がこれらに限定されないということが、あらかじめ理解されるべきである。図示されるように、次のレイヤおよび対応する機能が提供される。

ハードウェアおよびソフトウェア・レイヤ６０は、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例としては、メインフレーム６１、ＲＩＳＣ（縮小命令セットコンピュータ：Ｒｅｄｕｃｅｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ）アーキテクチャベースのサーバ６２、サーバ６３、ブレード・サーバ６４、ストレージ・デバイス６５、ならびにネットワークおよびネットワーク・コンポーネント６６が挙げられる。一部の実施形態では、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７およびデータベース・ソフトウェア６８を含む。

仮想化レイヤ７０は、１つまたは複数の実施形態では、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに仮想クライアント７５などの仮想的実体が提供される、抽象レイヤを備える。

一例を挙げると、管理レイヤ８０は、以下で説明する機能を提供する。リソース・プロビジョニング８１は、クラウド・コンピューティング環境内でタスクを実行するために利用される計算リソースおよび他のリソースの動的調達を行う。計測および価格設定８２は、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡、およびそれらのリソースの利用に対する請求書またはインボイスの送付を行う。一例を挙げると、それらのリソースは、アプリケーション・ソフトウェア・ライセンスを含む。セキュリティは、クラウドの利用者およびタスクのアイデンティティ検証を行うとともに、データおよび他のリソースの保護を行う。ユーザ・ポータル８３は、クラウド・コンピューティング環境へのアクセスを利用者およびシステム管理者に提供する。サービス・レベル管理８４は、必要なサービス・レベルを満たすように、クラウドの計算リソースの割り当てと管理を行う。サービス・レベル・アグリーメント（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）計画および実行８５は、今後の要求が予想されるクラウドの計算リソースの事前準備および調達を、ＳＬＡに従って行う。

ワークロード・レイヤ９０は、１つまたは複数の実施形態においてクラウド・コンピューティング環境で利用される機能の例を示している。このレイヤから提供されるワークロードおよび機能の例としては、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想クラスルーム教育の配信９３、データ分析処理９４、トランザクション処理９５、および本明細書に記載された本発明の特徴のうちの１つまたは複数を実行する安全なコンピュータ・リソース・アクセス処理９６が挙げられる。

本発明は、システム、方法、もしくはコンピュータ・プログラム製品、またはそれらの組み合わせであってよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を含んでいる１つまたは複数のコンピュータ可読ストレージ媒体を含んでよい。

コンピュータ可読ストレージ媒体は、命令実行デバイスによって使用するための命令を保持および格納できる有形のデバイスであることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組み合わせであってよいが、これらに限定されない。コンピュータ可読ストレージ媒体のさらに具体的な例の非網羅的リストは、ポータブル・フロッピー（登録商標）・ディスク、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリ・メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ－ＲＯＭ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、メモリ・スティック、フロッピー（登録商標）・ディスク、命令が記録されているパンチカードまたは溝の中の隆起構造などの機械的にエンコードされるデバイス、およびこれらの任意の適切な組み合わせを含む。本明細書において使用されるとき、コンピュータ可読ストレージ媒体は、電波または他の自由に伝搬する電磁波、導波管もしくは他の送信媒体を伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、またはワイヤを介して送信される電気信号などの、それ自体が一過性の信号であると解釈されるべきではない。

本明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体から各コンピューティング・デバイス／処理デバイスへ、またはネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、広域ネットワーク、もしくはワイヤレス・ネットワーク、またはそれらの組み合わせ）を介して外部コンピュータまたは外部ストレージ・デバイスへダウンロードされ得る。このネットワークは、銅伝送ケーブル、光伝送ファイバ、ワイヤレス送信、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、もしくはエッジ・サーバ、またはそれらの組み合わせを備えてよい。各コンピューティング・デバイス／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェイスは、コンピュータ可読プログラム命令をネットワークから受信し、それらのコンピュータ可読プログラム命令を各コンピューティング・デバイス／処理デバイス内のコンピュータ可読ストレージ媒体に格納するために転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、またはＪａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組み合わせで記述されたソース・コードまたはオブジェクト・コードであってよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で全体的に実行すること、ユーザのコンピュータ上でスタンドアロン・ソフトウェア・パッケージとして部分的に実行すること、ユーザのコンピュータ上およびリモート・コンピュータ上でそれぞれ部分的に実行すること、またはリモート・コンピュータ上もしくはサーバ上で全体的に実行することができる。後者のシナリオでは、リモート・コンピュータが、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザのコンピュータに接続されてもよいし、または接続が、（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに対して行われてよい。一部の実施形態では、本発明の態様を実行するために、例えばプログラマブル・ロジック回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによって、電子回路をカスタマイズするためのコンピュータ可読プログラム命令を実行してよい。

本発明の態様は、本明細書において、本発明の実施形態に従って、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して説明される。フローチャート図もしくはブロック図またはその両方の各ブロック、ならびにフローチャート図もしくはブロック図またはその両方に含まれるブロックの組み合わせが、コンピュータ可読プログラム命令によって実装され得るということが理解されるであろう。

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックに指定される機能／動作を実施する手段を作り出すべく、汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されてマシンを作り出すものであってよい。これらのコンピュータ可読プログラム命令は、命令が格納されたコンピュータ可読ストレージ媒体がフローチャートもしくはブロック図またはその両方の１つまたは複数のブロックに指定される機能／動作の態様を実施する命令を含んでいる製品を備えるように、コンピュータ可読ストレージ媒体に格納され、コンピュータ、プログラム可能なデータ処理装置、もしくは他のデバイス、またはそれらの組み合わせに特定の方式で機能するように指示できるものであってもよい。

コンピュータ可読プログラム命令は、コンピュータ上、他のプログラム可能な装置上、または他のデバイス上で実行される命令が、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックに指定される機能／動作を実施するように、コンピュータ、他のプログラム可能なデータ処理装置、または他のデバイスに読み込まれてもよく、それによって、一連の動作可能なステップを、コンピュータ上、他のプログラム可能な装置上、またはコンピュータ実装プロセスを生成する他のデバイス上で実行させる。

本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、本発明を制限することを意図していない。本明細書において使用されるとき、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈で特に明示的に示されない限り、複数形も含むよう意図されている。「備える」もしくは「備えている」またはその両方の用語は、本明細書で使用される場合、記載された機能、整数、ステップ、動作、要素、もしくはコンポーネント、またはそれらの組み合わせの存在を示すが、１つまたは複数の他の機能、整数、ステップ、動作、要素、コンポーネント、もしくはこれらのグループ、またはそれらの組み合わせの存在または追加を除外していないということが、さらに理解されるであろう。

下記の特許請求の範囲内のすべての手段またはステップおよび機能要素の対応する構造、材料、動作、および等価なものは、具体的に請求される他の請求された要素と組み合わせて機能を実行するための任意の構造、材料、または動作を含むことが意図されている。本発明のさまざまな実施形態の説明は、例示および説明の目的で提示されているが、網羅的であることは意図されておらず、開示された形態での本発明に制限されない。本発明の範囲から逸脱することなく、多くの変更および変形が、当業者にとって明らかになるであろう。本発明の原理および実際的な適用を最も適切に説明するため、およびその他の当業者が、企図された特定の用途に適するようなさまざまな変更を伴う多様な実施形態に関して、本発明を理解できるようにするために、実施形態が選択されて説明された。

本発明の１つまたは複数の実施形態では、本開示において説明された任意の方法が、ＶＨＤＬ（ＶＨＳＩＣ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ：ＶＨＳＩＣハードウェア記述言語）プログラムおよびＶＨＤＬチップを使用することによって実装される。ＶＨＤＬは、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ）、および他の類似の電子デバイス用の設計入力言語の一例である。したがって、本発明の１つまたは複数の実施形態では、本明細書に記載された任意のソフトウェアによって実装される方法が、ハードウェアベースのＶＨＤＬプログラムによってエミュレートされ、その後、ＦＰＧＡなどのＶＨＤＬチップに適用される。

したがって、本出願の本発明の実施形態を詳細に説明したことにより、およびその実施形態例を参照することにより、変更および変形が、添付の特許請求の範囲で定義された本発明の範囲から逸脱することなく可能であるということは明らかであろう。

Claims (16)

1. 認可サーバによって、デバイス上のネイティブ・アプリケーションから、初期認可グラント、前記デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、および前記ネイティブ・アプリケーションの信頼性の証明書を受信することと、
   前記認可サーバによって、前記デバイス上の前記ネイティブ・アプリケーションから、リフレッシュ・トークン、および前記秘密鍵を使用して作成された前記リフレッシュ・トークンのデジタル署名を受信することであって、前記認可サーバが、あらかじめ登録されている前記公開鍵を用いて前記リフレッシュ・トークンが検証された場合にのみ、前記リフレッシュ・トークンを認識する、前記受信することと、
   前記認可サーバによって、前記リフレッシュ・トークンの前記デジタル署名の妥当性を確認することと、
   前記デバイス上の前記ネイティブ・アプリケーションからの前記リフレッシュ・トークンの妥当性を確認することに応答して、前記認可サーバによって、新しいアクセス・トークンおよび新しいリフレッシュ・トークンを前記認可サーバから前記デバイス上の前記ネイティブ・アプリケーションに送信することであって、前記新しいアクセス・トークンが、前記デバイス上の前記ネイティブ・アプリケーションにコンピュータ・リソースへアクセスさせる、前記送信することと
   を含む、方法。
2. 前記ネイティブ・アプリケーションの信頼性の前記証明書は、前記ネイティブ・アプリケーションおよびデバイスの完全性および信頼性を保証する、請求項１に記載の方法。
3. 前記デバイス上で前記公開鍵／秘密鍵が生成され、前記秘密鍵は、前記デバイスにバインドされることによって、不正使用または抽出から保護される、請求項１に記載の方法。
4. 前記認可サーバおよびクライアントは、Ｏｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＯＡｕｔｈ）アーキテクチャのコンポーネントである、請求項１に記載の方法。
5. トランスポート層セキュリティ（ＴＬＳ）プロトコル拡張を使用せずに、クライアントからのアプリケーション・ペイロード内のデータを使用して、リフレッシュ認可グラントが、前記リフレッシュ認可グラントの発行先だった前記デバイスから来ることを検証される、請求項１に記載の方法。
6. １つまたは複数のプロセッサによって、リフレッシュ認可グラント処理の一部としてＦａｓｔ Ｉｄｅｎｔｉｔｙ Ｏｎｌｉｎｅ（ＦＩＤＯ）認証を適用することによって、前記デバイスのアイデンティティを確認することをさらに含む、請求項１に記載の方法。
7. ニューラル・ネットワークに、前記初期認可グラント、前記公開鍵、前記ネイティブ・アプリケーションの信頼性の前記証明書、前記リフレッシュ・トークン、および前記リフレッシュ・トークンの前記デジタル署名を入力することであって、前記ニューラル・ネットワークは、ニューラル・ネットワークによって生成されたアクセス・トークンおよびニューラル・ネットワークによって生成されたリフレッシュ・トークンを生成するようにトレーニングされる、前記入力することと、
   １つまたは複数のプロセッサによって、前記認可サーバによって生成された前記新しいアクセス・トークンおよび前記新しいリフレッシュ・トークンの妥当性を確認するために、前記認可サーバによって生成された前記新しいアクセス・トークンおよび前記新しいリフレッシュ・トークンを、前記ニューラル・ネットワークによって生成されたアクセス・トークンおよび前記ニューラル・ネットワークによって生成されたリフレッシュ・トークンと比較することと
   をさらに含む、請求項１に記載の方法。
8. １つまたは複数のプロセッサによって、前記新しいアクセス・トークンおよび新しいリフレッシュ・トークンが前記ニューラル・ネットワークによって生成されたアクセス・トークンおよび前記ニューラル・ネットワークによって生成されたリフレッシュ・トークンに一致するということを決定することと、
   前記新しいアクセス・トークンおよび新しいリフレッシュ・トークンが前記ニューラル・ネットワークによって生成されたアクセス・トークンおよび前記ニューラル・ネットワークによって生成されたリフレッシュ・トークンに一致するということの決定に応答して、１つまたは複数のプロセッサによって、前記新しいアクセス・トークンおよび前記新しいリフレッシュ・トークンを前記ネイティブ・アプリケーションに送信することとをさらに含む、請求項７に記載の方法。
9. １つまたは複数のプロセッサによって、前記新しいアクセス・トークンおよび新しいリフレッシュ・トークンが前記ニューラル・ネットワークによって生成されたアクセス・トークンおよび前記ニューラル・ネットワークによって生成されたリフレッシュ・トークンに一致しないということを決定することと、
   前記新しいアクセス・トークンおよび新しいリフレッシュ・トークンが前記ニューラル・ネットワークによって生成されたアクセス・トークンおよび前記ニューラル・ネットワークによって生成されたリフレッシュ・トークンに一致しないということの決定に応答して、１つまたは複数のプロセッサによって、前記ネイティブ・アプリケーションへの前記新しいアクセス・トークンおよび前記新しいリフレッシュ・トークンの送信を阻止することと
   をさらに含む、請求項７に記載の方法。
10. 前記新しいアクセス・トークンは第１の新しいアクセス・トークンであり、前記新しいリフレッシュ・トークンは第１の新しいリフレッシュ・トークンであり、前記方法は、
    前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンを生成するために認証サーバによって利用される前記初期認可グラント、前記公開鍵、前記ネイティブ・アプリケーションの信頼性の前記証明書、前記リフレッシュ・トークン、および前記リフレッシュ・トークンの前記デジタル署名を含む、格納されたブロックチェーンをブロックチェーン・アーキテクチャに格納することと、
    前記ブロックチェーン・アーキテクチャから前記格納されたブロックチェーンを取り出すことと、
    前記認証サーバによって、前記格納されたブロックチェーンからの前記初期認可グラント、前記公開鍵、前記ネイティブ・アプリケーションの信頼性の前記証明書、前記リフレッシュ・トークン、および前記リフレッシュ・トークンの前記デジタル署名を使用することによって、第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンを生成することと、
    １つまたは複数のプロセッサによって、前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンが、前記第２の新しいアクセス・トークンおよび前記第２の新しいリフレッシュ・トークンに一致するということを決定するために、前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンを、前記第２の新しいアクセス・トークンおよび前記第２の新しいリフレッシュ・トークンと比較することと、
    前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンが前記第２の新しいアクセス・トークンおよび前記第２の新しいリフレッシュ・トークンに一致するということの決定に応答して、１つまたは複数のプロセッサによって、前記認可サーバによって生成された前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンが前記認可サーバから前記ネイティブ・アプリケーションに送信されることを認可することと
    をさらに含む、請求項１に記載の方法。
11. 前記新しいアクセス・トークンは第１の新しいアクセス・トークンであり、前記新しいリフレッシュ・トークンは第１の新しいリフレッシュ・トークンであり、前記方法は、
    前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンを生成するために認証サーバによって利用される前記初期認可グラント、前記公開鍵、前記ネイティブ・アプリケーションの信頼性の前記証明書、前記リフレッシュ・トークン、および前記リフレッシュ・トークンの前記デジタル署名を含む格納されたブロックチェーンをブロックチェーン・アーキテクチャに格納することと、
    前記ブロックチェーン・アーキテクチャから前記格納されたブロックチェーンを取り出すことと、
    前記認証サーバによって、前記格納されたブロックチェーンからの前記初期認可グラント、前記公開鍵、前記ネイティブ・アプリケーションの信頼性の前記証明書、前記リフレッシュ・トークン、および前記リフレッシュ・トークンの前記デジタル署名を使用することによって、第２の新しいアクセス・トークンおよび第２の新しいリフレッシュ・トークンを生成することと、
    １つまたは複数のプロセッサによって、前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンが、前記第２の新しいアクセス・トークンおよび前記第２の新しいリフレッシュ・トークンに一致しないということを決定するために、前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンを、前記第２の新しいアクセス・トークンおよび前記第２の新しいリフレッシュ・トークンと比較することと、
    前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンが前記第２の新しいアクセス・トークンおよび前記第２の新しいリフレッシュ・トークンに一致しないということの決定に応答して、１つまたは複数のプロセッサによって、前記認可サーバから前記ネイティブ・アプリケーションへの前記認可サーバによって生成された前記第１の新しいアクセス・トークンおよび前記第１の新しいリフレッシュ・トークンの送信を阻止することとをさらに含む、請求項１に記載の方法。
12. 方法を実行するためにプロセッサによって読み取られかつ実行されるプログラム・コードを含むコンピュータ・プログラムであって、前記方法は、
    デバイス上のネイティブ・アプリケーションから、初期認可グラント、前記デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、および前記ネイティブ・アプリケーションの信頼性の証明書を受信することと、
    前記デバイス上の前記ネイティブ・アプリケーションから、リフレッシュ・トークン、および前記秘密鍵を使用して作成された前記リフレッシュ・トークンのデジタル署名を受信することであって、認可サーバが、あらかじめ登録されている前記公開鍵を使用して前記リフレッシュ・トークンが検証された場合にのみ、前記リフレッシュ・トークンを認識する、前記受信することと、
    前記リフレッシュ・トークンの前記デジタル署名の妥当性を確認することと、
    前記デバイス上の前記ネイティブ・アプリケーションからの前記リフレッシュ・トークンの妥当性を確認することに応答して、新しいアクセス・トークンおよび新しいリフレッシュ・トークンを前記認可サーバから前記デバイス上の前記ネイティブ・アプリケーションに送信することであって、前記新しいアクセス・トークンが、前記デバイス上の前記ネイティブ・アプリケーションにコンピュータ・リソースへアクセスさせる、前記送信することと
    を含む、コンピュータ・プログラム。
13. 前記プログラム・コードはクラウド環境内のサービスとして提供される、請求項１２に記載のコンピュータ・プログラム。
14. 請求項１２に記載のコンピュータ・プログラムを記録した、コンピュータ可読ストレージ媒体。
15. １つまたは複数のプロセッサと、１つまたは複数のコンピュータ可読メモリと、１つまたは複数のコンピュータ可読非一過性ストレージ媒体とを備えているコンピュータ・システムであって、プログラム命令は、前記１つまたは複数のコンピュータ可読メモリのうちの少なくとも１つを介して、前記１つまたは複数のプロセッサのうちの少なくとも１つによって実行するために、前記１つまたは複数のコンピュータ可読非一過性ストレージ媒体のうちの少なくとも１つに格納され、前記格納されたプログラム命令は、
    デバイス上のネイティブ・アプリケーションから、初期認可グラント、前記デバイス上で生成された秘密鍵／公開鍵ペアの公開鍵、および前記ネイティブ・アプリケーションの信頼性の証明書を受信することと、
    前記デバイス上の前記ネイティブ・アプリケーションから、リフレッシュ・トークン、および前記秘密鍵を使用して作成された前記リフレッシュ・トークンのデジタル署名を受信することであって、認可サーバが、あらかじめ登録されている前記公開鍵を用いて前記リフレッシュ・トークンが検証された場合にのみ、前記リフレッシュ・トークンを認識する、前記受信することと、
    前記リフレッシュ・トークンの前記デジタル署名の妥当性を確認することと、
    前記デバイス上の前記ネイティブ・アプリケーションからの前記リフレッシュ・トークンの妥当性を確認することに応答して、新しいアクセス・トークンおよび新しいリフレッシュ・トークンを前記認可サーバから前記デバイス上の前記ネイティブ・アプリケーションに送信することであって、前記新しいアクセス・トークンが、前記デバイス上の前記ネイティブ・アプリケーションにコンピュータ・リソースへアクセスさせる、前記送信することと
    を含む方法を実施するように実行される、コンピュータ・システム。
16. 前記格納されたプログラム命令はクラウド環境内のサービスとして提供される、請求項１５に記載のコンピュータ・システム。