JP7091470B2 - 長期実行動作のためのリフレッシュ・トークンの安全な委任 - Google Patents

Description

本発明は、概して、データ処理環境内における認可(オーサライゼーション)のための方法に関し、より詳細には、データ処理環境内におけるトークンベースの認可のためのコンピュータ実施方法に関する。本発明は、さらに、データ処理環境内におけるトークンベースの認可のためのシステム、およびコンピュータ・プログラム製品に関する。

データ・プライバシ、プライベート・データの保護、および企業データの堅固なセキュリティの時代においては、認可および認証プロセスおよび技術が企業情報技術の主要課題である。過去数十年間にわたって、複数の独占技術およびオープン・ソース技術が、これらの課題に対処するために開発された。特に、過去１０年間で、トークンベースの認証および認可システムが発達した。

これらのシステムでは、エンドユーザが、通例、認可サーバに対して認証し、そのエンドユーザの認可、および任意選択的に、また、その識別を証明する一時的トークンを返してもらう。一時的トークンは、例えば、ウェブ・ベースのユーザ・インターフェース・バックエンド・サービス・セキュリティによって用いられ、それらのサービスにはクレデンシャルが流れないため、トークンベースのシステムは、同じ認可システムおよび手順を活用し得る異なるベンダのサービスのための技術エコシステムを可能にする。サービス間のより複雑な対話のために、トークンを、ユーザ・インターフェースからサービスを通して別の下流のサービスへ通過することも可能であり得る。

上述のシステムにおけるトークンの１つの特定の側面は、それらが、通例、それらの期限が切れるまでに限られた寿命を有することである。このようなトークンの期限切れの後に、トークンの元々の要求クライアント・アプリケーション、例えば、ウェブ・ベースのユーザ・インターフェースは、リフレッシュ・トークンを用いて新たなトークンを得ることができ、これが、次に、ウェブ・ベースのユーザ・インターフェース・アプリケーション内に記憶される。他のサービスはトークンをリフレッシュすることができない。これが、まさに、特定のコンピューティング・タスクを解決するために分散専用（ソフトウェア）サービスに大きく依存する今日の分散コンピューティング環境内における、特定のサービス、例えば、分析サービスによって提供される、長期実行トランザクションまたは他の種類の動作の課題となっている。

この問題はまた、ＲＦＣ６７４９「ＯＡｕｔｈ２．０認証フレームワーク」（例えば、https://tool.iietf.org/html/rfc6749と比較）において規定されたＯＡｕｔｈ２システムのような、周知の技術によっても対処されない。

また、他の刊行物も長期実行アプリケーションの上述のシナリオのための解決策を提供していなかった。

文献、米国特許出願公開第２０１７／００４８２３３（Ａ１）号は、認証トークンをリフレッシュするための技法を開示している。認証情報を要求コンピューティング・デバイスから受信したことに応じて、安全なコンピューティング環境へのアクセスが認められる。アクセスはセッションのために認められ、１つまたは複数のクライアント・アプリケーションが、アクセス・トークンを利用することによって、安全な所有者に代わってサーバ・リソースへの安全な委任アクセスを可能にする。

文献、米国特許出願公開第２０１７／００２６３７６（Ａ１）号は、サービスを提供するリソース・サーバと、クライアント装置である、連携サーバをオーサリングするための認可委任、および認可情報に基づいて、リソース・サーバが有するユーザ・データへのアクセスを遂行する認可サーバとを含む、認可委任システムを記載している。

これらの文献は、ＯＡｕｔｈ２．０システムの準標準的実装形態と大差ないものを記載するのみであった。クッキー交換、またはリソース・サーバから認可サーバへの認証の抽象的委任（abstract delegation）のような若干の拡張が述べられているのみである。長期実行動作およびサービスの問題は従来の技術によって対処されない。

それゆえ、長期実行アプリケーション・サービスに、今日のユーザ・プロセスのために利用可能な同じレベルのセキュリティおよび認証を備えさせる必要性が存在する。同時に、このさらなるレベルのセキュリティ、すなわち、認証はユーザに対して透過（トランスペーレント）であるべきである。

本発明の一態様によれば、データ処理環境内におけるトークンベースの認可のためのコンピュータ実施方法が提供され得る。データ処理環境は、少なくとも、ユーザ・エージェントを実行するユーザ・システム、アプリケーションを実行するアプリケーション・サーバ、および認可サーバを含み得る。ユーザ・エージェントは第１のネットワーク接続を介してアプリケーションと通信可能に連絡し得、アプリケーションは第２のネットワーク接続を介して認可サーバと通信可能に連絡し得る。アプリケーションは、長期実行動作を提供するサービスへのアクセスを提供し得る。少なくとも、長期実行動作を提供するサービスは識別子によって識別可能であり得る。

本方法は、ユーザ・エージェントを介してアプリケーションにアクセスすることと、認可プロトコルがうまく終了した後に、アクセス・トークンおよびリフレッシュ・トークンを認可サーバからアプリケーションへ送信することと、アプリケーションによって長期実行動作を提供するサービスの実行をトリガすることと、を含み得る。

これに関して、トリガすることは、アプリケーションによって認可サーバに転送可能リフレッシュ・トークンを要求すること、アプリケーションによって認可サーバから転送可能リフレッシュ・トークンを受信することであって、転送可能リフレッシュ・トークンが、少なくとも、リフレッシュ・トークン、および長期実行動作を提供するサービスのための識別子を含む、受信すること、ならびに転送可能リフレッシュ・トークンを識別子と共にアプリケーションから、長期実行動作を提供するサービスへ渡すことによって、長期実行動作を提供するサービスの実行を開始すること、を含み得る。

さらに、トリガすることは、転送可能リフレッシュ・トークンを、長期実行動作を提供するサービスの識別子と共に、長期実行動作を提供するサービスから認可サーバへ渡すこと、長期実行動作を提供するサービスのためのアクセスおよびリフレッシュ・トークンを応答として受信すること、ならびに長期実行動作を提供するサービスによって認可サーバから受信可能なリフレッシュ・トークンを用いて、長期実行動作を提供するサービスを継続すること、を含み得る。

本発明の別の態様によれば、データ処理環境内におけるトークンベースの認可のためのシステムが提供され得る。同様に、ここでも、データ処理環境は、少なくとも、ユーザ・エージェントを実行するユーザ・システム、アプリケーションを実行するアプリケーション・サーバ、および認可サーバを含み得る。ユーザ・エージェントは第１のネットワーク接続を介してアプリケーションと通信可能に連絡し得、アプリケーションは第２のネットワーク接続を介して認可サーバと通信可能に連絡し得る。

アプリケーションは、長期実行動作を提供するサービスへのアクセスを提供し得、少なくとも、長期実行動作を提供するサービスは識別子によって識別可能であり得る。

セキュリティ・システムは、ユーザ・エージェントを介してアプリケーションにアクセスするように適合されたアクセス・ユニットと、アプリケーション認可プロトコルがうまく終了した後に、アクセス・トークンおよびリフレッシュ・トークンを認可サーバからアプリケーションへ送信するように適合された送信器と、アプリケーションによって長期実行動作を提供するサービスの実行をトリガするように適合されたトリガ・ユニットと、を備え得る。

トリガ・ユニットは、アプリケーションによって認可サーバに転送可能リフレッシュ・トークンを要求するように適合された要求モジュール、アプリケーションによって認可サーバから転送可能リフレッシュ・トークンを受信するように適合された受信器であって、転送可能リフレッシュ・トークンが、少なくとも、リフレッシュ・トークン、および長期実行動作を提供するサービスのための識別子を含み得る、受信器、ならびに転送可能リフレッシュ・トークンを識別子と共にアプリケーションから、長期実行動作を提供するサービスへ渡すことによって、長期実行動作を提供するサービスの実行を開始するように適合された開始ユニット、を含み得る。

トリガ・ユニットは、転送可能リフレッシュ・トークンを、長期実行動作を提供するサービスの識別子と共に、長期実行動作を提供するサービスから認可サーバへ渡すように適合された受け渡しモジュール、長期実行動作を提供するサービスのためのアクセスおよびリフレッシュ・トークンを応答として受信するように適合された受信器、ならびに長期実行動作を提供するサービスによって認可サーバから受信可能なリフレッシュ・トークンを用いて、長期実行動作を提供するサービスを継続するように適合された継続モジュール、をさらに含み得る。

データ処理環境内におけるトークンベースの認可のための本提案のコンピュータ実施方法は複数の利点および技術的効果を提供し得る。

トークンベースの認証環境内における、ユーザ指向プロセス、およびユーザ指向プロセスのうちの１つに関連する長期実行バックエンド・サービスの分割の問題が解決される。サービスおよびリソースの正規のアクセスおよび理論化のために用いられるのと同じセキュリティ標準が委任のために実装され得る。

クライアント・システム上のユーザ指向アプリケーションによって呼び出される、サーバ・システム上のコンピューティング・サービスは、クライアント・システム上のユーザ指向アプリケーションと同じ認可レベルの下にあり得る。初期セットアップ・プロセスの後に、関連するバックエンドの長期実行サービスは、排他的アクセスおよびリフレッシュ・トークンによって認証されることになる。

プロセスはユーザ指向アプリケーションによって完全に制御され得るが、クライアント・アプリケーションと、サービス、例えば、長期実行するコンピュータ集約型の複雑なデータ分析を提供するバックエンド・アプリケーションとの間のいかなる追加の通信オーバヘッドも呼び出さなくてすむ。

ここで提案されるコンセプトは、自由にアクセス可能であり、それゆえ、安全でない場合がある、一方または他方のコンピューティング・システム上に記憶された安全でないクッキーに頼らない。

代わりに、クライアント・アプリケーションは － 初期段階の後に － バックエンド・システムがその結果をクライアント・アプリケーションに提供することが可能になり得るまで、バックエンド・コンピューティング・サービスの認証に気を遣うことから解放される。それゆえ、クライアント・アプリケーションへの影響は最小限に保たれ得る。加えて、また、既存の認可コンセプトへの影響も低侵襲であり、それゆえ、それは確実で信頼性の高い認可コンセプトをエレガントに拡張する。

さらに、ここで提案される方法は、全ての他のＯＡｕｔｈ２．０対話のような同じエンドポイント、パラメータ、および呼び出しスタイル（ＰＯＳＴ／トークン、要求がフォーム・データを本体として送信し、応答がＪＳＯＮ（Java(R) Script Object Notation（ジャバ・スクリプト・オブジェクト通知））を包含する）を用い得る。それゆえ、良好な互換性が与えられる。その新たなトークン方法のユーザ、プログラマ、または採用者、あるいはその組み合わせのための学習労力は軽くとどまり、それは、ＯＡｕｔｈ２のための新たな領域、例えば、トークンの期限が切れるであろうから夜間のバッチ・ランのために純粋なＯＡｕｔｈ２．０を採用することができない、夜間のバッチ・ラン内へ「真の」処理を標準的に移動させ得る銀行業務アプリケーションを可能にする。本提案のコンセプトは、代わりに、ＯＡｕｔｈ２．０をそれらのシナリオにも拡張することを可能にし、ＯＡｕｔｈ２．０をそのシナリオにおける全てのステップに適用することを可能にし得る。

以下において、 － 関連方法および関連セキュリティ・システムに適用可能な － 本発明のコンセプトの追加の諸実施形態が説明される。

本方法の１つの好ましい実施形態によれば、転送可能リフレッシュ・トークンは有効期限をさらに含み得る。これは、固定された日付／時間の組み合わせ、トークンの開始からの総時間単位数、トークンの開始からの事前設定された秒数、または同様のものであり得る。これが転送可能リフレッシュ・トークンの有効時間を制限することになる。この時間の後には、トークンはアプリケーションまたはサービスのためにもはや使用可能でなくなる。

本方法の別の好ましい実施形態によれば、ユーザ・エージェントを介してアプリケーションにアクセスすることは、また、アプリケーション、ユーザ・エージェント、および認可サーバの間の認可プロトコルを用いることを含み得、アクセスすることは、アプリケーションと認可サーバとの間で認証クレデンシャルを交換することによって認可される。選択される認可プロトコルとして、また、既知のプロトコル、またはそれらの要素が用いられてもよく、本提案のコンセプト内に統合されてもよい。それらの潜在的認可プロトコルのうちの１つは、オープン標準のＯＡｕｔｈ２．０プロトコルである。

本方法の１つの有利な実施形態によれば、転送可能リフレッシュ・トークンを要求することに関連する要求は、また、リフレッシュ・トークンを、長期実行動作を実行するサービスの識別子と共に含み得る。このように、転送可能リフレッシュ・トークンに関する安全な要求が保証され得る。

また、転送可能リフレッシュ・トークンを要求すること、および上述された、ユーザ・エージェントを介してアプリケーションにアクセスすることは、１つの要求、例えば、１つのＡＰＩ（application programming interface（アプリケーション・プログラミング・インターフェース））呼び出しに組み合わせられ得ることにも留意されたい。

本方法の許容可能な一実施形態によれば、認可サーバは、ＯＡｕｔｈ２．０プロトコルに従って認可サービスを提供するように適合され得る。これは、オープン標準のセキュリティ・プロトコルの上述の潜在的ユーザ・エッジと調和している。無論、また、他のプロトコル・タイプも、ここで提案されるコンセプトの一部として、完全に、または部分的に用いられ得る。

本方法のさらに許容可能な一実施形態によれば、長期実行動作は、データ分析プロセス、データ転送プロセス、バックアップ・プロセス、データ再編成、およびニューラル・ネットワークのプロセスを含む群から選択される。これらの異なる適用領域は、比較的長い実行時間を有する、他のコンピューティング・タスクのための例の役割も果たし得る。

本方法のさらなる一実施形態によれば、長期実行動作はアプリケーションのアクセス・トークン有効期限よりも長く実行し得る。これは、本提案のコンセプトがその利点を全て示し得る環境を表し得る。

本方法のさらに有利な一実施形態によれば、転送可能リフレッシュ・トークンは、少なくとも、ユーザ識別子 － 具体的には、実際にはユーザを表すユーザ・エージェント識別子 － 、１つまたは複数のスコープ（すなわち、「許可されたアクション」）、転送可能リフレッシュ・トークンの有効期限、長期実行動作を提供するサービスの識別子、および長期実行動作を提供するサービスの有効期限を含み得る。追加のパラメータ・コンポーネントが、基礎をなすセキュリティ・プロトコルのアーキテクチャに適合するために、転送可能リフレッシュ・トークンに追加されてもよい。

転送可能リフレッシュ・トークンの有効期限は新たに発行された転送可能リフレッシュ・トークンが、それが受信された後、所定の時間をもって用いられ得ることを確実にし得る。この有効期限は、必要とされる探索時間とは区別され、長期実行動作に関連する必要があり得る。

また、スコープの設定はＯＡｕｔｈ２．０プロトコルの文脈においてすでに説明されたことにも留意されたい。

本方法のさらに有利な一実施形態によれば、長期実行動作を提供するサービスは、第２の転送可能リフレッシュ・トークンが、第２の長期実行動作を提供する第２のサービスに提供されることを要求し得る。これは、長期実行サービスまたはアプリケーションのチェーニングを可能にし得る。これは、例えば、例として、ビッグ・データ環境内において複雑な分析を遂行するために、複数の長期実行動作が並列に実行する、サービス指向アーキテクチャにおける典型的なセット・アップを表し得る。

本方法の任意選択的な一実施形態によれば、アプリケーションによって認可サーバに転送可能リフレッシュ・トークンを要求することは、ユーザ・エージェントによる確認後にのみ遂行され得る。このために、ユーザ対話が必要とされ得るか、または推奨可能であり得る。それゆえ、ユーザは、自分の安全なアクセスが第３のエンティティ、すなわち、長期実行動作を提供するサービスへ転送される仕方を制御し得る。それゆえ、エンドユーザは、完全なプロセス、および同様にアクセス権の委任を掌握し続け得る。

さらに、諸実施形態は、コンピュータまたは任意の命令実行システムによって、またはそれと関連して使用されるためのプログラム・コードを提供するコンピュータ可用またはコンピュータ可読媒体からアクセス可能な、関連するコンピュータ・プログラム製品の形態を取り得る。本記載の目的のために、コンピュータ可用またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによって、またはそれと関連して使用されるためのプログラムを記憶、通信、伝搬、または輸送するための手段を包含し得る任意の装置であり得る。

本発明の諸実施形態は異なる主題を参照して説明されていることに留意されたい。具体的には、一部の実施形態は、方法の形式の請求項を参照して説明されており、それに対して、他の実施形態は装置の形式の請求項を参照して説明されている。しかし、当業者は、以上および以下の説明から、別途断りのない限り、１つの種類の主題に属する特徴の任意の組み合わせに加えて、異なる主題に関連する特徴の間の、特に、方法の形式の請求項の特徴と、装置の形式の請求項の特徴との間の任意の組み合わせも本文書内において開示されていると考えられると推測するであろう。

以上において定義された諸態様、および本発明のさらなる諸態様は、以下に記載される諸実施形態の例から明らかであり、諸実施形態の例を参照して説明される。ただし、本発明はこれらに限定されない。

以下の図面を参照して本発明の好ましい諸実施形態を例としてのみ説明する。

データ処理環境内におけるトークンベースの認可のための本発明のコンピュータ実施方法の一実施形態のブロック図を示す。 本提案の発明のコンセプトの対話に関与する要素のブロック図を示す。 本方法の実現可能な実施形態の第１のステップの対話のブロック図を示す。 図３ａに係る第１のステップの状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態の次のステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態の次のステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態のさらなるステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態のさらなるステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態のさらなるステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態のさらなるステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態のまた別のステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態のまた別のステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態の追加のステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態の追加のステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態の最終ステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 本提案の方法の実現可能な実施形態の最終ステップのための、対話する関与ユニット、ならびに関連する状態および情報交換の図を示す。 （ａ）は、アクセス・トークンを示す図である。（ｂ）は、リフレッシュ・トークンを示す図である。（ｃ）は、転送可能リフレッシュ・トークンを示す図である。 データ処理環境内におけるトークンベースの認可のためのセキュリティ・システム１１００のブロック図を示す。 本提案の方法の一実装形態のためのコンピューティング・システム機器のブロック図を示す。

本記載の文脈においては、以下の規則、用語、または表現、あるいはその組み合わせが使用され得る。

用語「トークンベースの認可」は、当技術分野において知られており、ＯＡｕｔｈ２．０のオープン標準の文脈で説明される認証および認可プロセスならびに関連するプロトコルを表し得る。重要な要素のうちの１つは、呼び出し側および被呼び出し側のサービスの間でトークンを交換することであり、トークンの作成は認可サーバによって制御される。呼び出し側および被呼び出し側のサービスの間のそれらの接続のみが、既定のセキュリティ・コンセプトの基礎をなすエンティティのために確立され得る。

用語「データ処理環境」は、異なる特性を有する異なるコンピューティング・ノードを含む、ネットワークを表し得る。このようなコンピューティング・ノードの例は、エンドユーザ・システム、アプリケーション・サーバ、データベース・サーバ、計算サーバ － 特に、長期実行動作を提供するもの － である。他の種類のサーバまたはノードは、リソース・ノード、または認証および認可サービス、あるいはその両方を含み得る。

用語「ユーザ・システム」は、エンドユーザによって動作させられるノードのうちの１つを表し得る。通例、エンドユーザはブラウザを介してコンピュータのネットワークにアクセスし得る。ブラウザは、２つの部分：ユーザ・インターフェースおよびバックエンド・サービスの形で実施され得、通例、ユーザ・システム上で実行され、例示的にユーザ・エージェントと表される。ユーザ・エージェントはコンピュータのネットワーク内の実際のエンドユーザを表し得る。

用語「アプリケーション・サーバ」は、アプリケーション・サービスを提供する、１つまたは複数の専用コンピューティング・システムを表し得る。通例、ユーザ・エージェントは、特定のサービスを提供する、１つのアプリケーション・サーバにアクセスし得る。背景において、アプリケーション・サーバは他のアプリケーション・サーバからのサービスにアクセスし得る。

用語「認可サーバ」は、特定のエンドユーザを認証し、既定のセキュリティ・コンセプトの下でコンピューティング・ノードのネットワーク内のエンドユーザ関連アクションのアクセスを認可することを可能にされた － 多くの場合、専用ハードウェア・システムとして実施された － 特殊サーバを表し得る。

用語「ネットワーク接続」は、２つのシステムの間、特に、基礎をなすハードウェア・デバイスを用いたソフトウェア・サービス間の任意の技術の接続を表し得る。それゆえ、ネットワーク接続は有線接続または無線接続であり得る。ネットワーク接続のために用いられるプロトコルの一例はインターネット・プロトコルである。

用語「長期実行動作（long-running operation）」は、データ分析ジョブ、複雑な検索クエリ、人工知能システムを関与させるサービス、バックアップ・プロセス、大量のデータのためのデータ伝送プロセス、および同様のもののような、計算またはトランザクションあるいはその両方の非常に集約性の高いものであり得るアプリケーションを表し得る。長期実行動作を提供するこのようなサービスの共通の特徴は、それらの実行時間が、通例、アクセス・トークンの有効期限を超えることである。

用語「識別子」は、コンピューティング・システム内、もしくはコンピューティング・システムのネットワーク内のエンティティ、プロトコル、またはアプリケーション、あるいはその組み合わせを識別するために用いられるデジタル・コードを表し得る。

用語「アクセス・トークン」は、アプリケーション（またはアプリケーション・サービス）がコンピュータのネットワーク内の特定のリソースにアクセスすることを認可するデジタル・コードを表し得る。アクセス・トークンの発行においては、既定のセキュリティ・システムおよび関連プロトコルが関与し得る。基本的に、アクセス・トークンは、コンピュータ・ネットワーク内の別のリソースのサービスを用いるアプリケーション（または別のリソース）を可能にする。

用語「リフレッシュ・トークン」は、 － 上述のアクセス・トークンおよび関連セキュリティ・プロトコルの文脈において － 元のアクセス・トークンが期限切れになった後に関連リソース上のアクセスを継続するために用いられ得る。それゆえ、リフレッシュ・トークンは、リソースまたはサービスが、他のリソースにアクセスするその動作を継続することを可能にするために、定期的に発行され得る。

用語「転送可能リフレッシュ・トークン（transferable refresh token）」は、本提案の方法および関連システムの一部として新たに導入されたコンセプトを表し得る。従来のセキュリティ・コンセプトでは、アクセス・トークンが、別のリソースにアクセスするためにリソースに提供され得る。しかし、このようなアクセス・トークンは別のリソースへ転送可能ではない。従来のセキュリティ・アーキテクチャの制約を克服するためには、あまり安全でないプロトコルに頼る他の機構が「応急策」として用いられなければならない。本提案のコンセプトはこれらの「応急策」を旧式化させ、それらを、用いられている、基礎をなすセキュリティ・プロトコルと同じセキュリティ標準を有する認可プロトコルと置き換える。

用語「ＯＡｕｔｈ２．０プロトコル」は、インターネット・ユーザが、他のウェブサイト上の彼らの情報へのウェブサイトまたはアプリケーションのアクセスを、それらにパスワードを与えることなく認めるための手段として一般的に用いられる、アクセス委任のための周知のオープン標準プロトコルＯＡｕｔｈを表し得る。この機構は、世界的に著名なインターネット企業によって、それらのユーザが彼らのアカウントに関する情報をサード・パーティ・アプリケーションまたはウェブサイトと共有することを許可するために用いられている。

概して、ＯＡｕｔｈは、リソース所有者に代わって、クライアントに、サーバ・リソースへの「安全な委任アクセス」を提供する。それは、リソース所有者が、彼らのクレデンシャルを共有することなく、彼らのサーバ・リソースへのサード・パーティのアクセスを認可するためのプロセスを指定する。特に、ハイパーテキスト転送プロトコル（Hypertext Transfer Protocol、ＨＴＴＰ）と協働するよう設計されることで、ＯＡｕｔｈは、本質的に、アクセス・トークンが、リソース所有者の承認を得て、認可サーバによってサード・パーティ・クライアントに発行されることを可能にする。次に、サード・パーティはアクセス・トークンを用いて、リソース・サーバによってホストされた保護されたリソースにアクセスする。

用語「スコープ」は表し、ＯＡｕｔｈ２．０セキュリティ・コンセプトにおいて説明され得る。基本的に、スコープは活動レベルを規定し、アプリケーション（または別のリソース）が認められ得る。例えば、アプリケーションは特定のデータへの読み出しアクセスを有するが、書き込み権または削除権を有しなくてもよい。加えて、読み出しアクセスはデータの既定のセットに限定されてもよい。

以下において、図の詳細な説明が与えられる。図における全ての指示は概略的なものである。まず、データ処理環境内におけるトークンベースの認可のための本発明のコンピュータ実施方法の一実施形態のブロック図が与えられる。その後、さらなる諸実施形態、およびデータ処理環境内におけるトークンベースの認可のためのシステムの諸実施形態が説明される。

図１は、データ処理環境内におけるトークンベースの認可のためのコンピュータ実施方法１００の一実施形態のブロック図を示す。これは、例えば、クラウド・コンピューティング環境、またはサービス指向アーキテクチャに基づく別のシステムであり得る。

データ処理環境は、少なくとも、通例、エンドユーザによって操作されるブラウザを備え得るユーザ・システムを含む。それはまた、エンドユーザとしてのアクションを表すユーザ・エージェントを実行し得る。ユーザ・エージェントはブラウザのバックエンド・サービスを表し得る。

データ処理環境はまた、アプリケーション、通例、ウェブ・アプリケーションを実行するアプリケーション・サーバ、および概して、ここで提案されるコンセプトによって強化されるＯＡｕｔｈ２．０規則に従って動作し得る認可サーバを含む。

ユーザ・エージェントは第１のネットワーク接続を介してアプリケーションと通信可能に連絡しており、アプリケーションは第２のネットワーク接続を介して認可サーバと通信可能に連絡している。

アプリケーションは、長期実行動作を提供するサービスへのアクセスを提供する。これは、例えば、データ分析アプリケーション（もしくはその部分）、データ転送プログラム、人工知能システムのタスク、および比較的長い実行時間を必要とする同等のサービスのような特殊システムであり得る。少なくとも、長期実行動作を提供するサービスは識別子によって識別可能である（すなわち、認識可能である）。

本方法は、ユーザ・エージェントを介してアプリケーションにアクセスすること（１０２）と、認可プロトコルがうまく終了した後に、アクセス・トークンおよびリフレッシュ・トークンを認可サーバからアプリケーションへ送信すること（１０４）と、アプリケーションによって長期実行動作を提供するサービスの実行をトリガすること（１０６）と、を含み得る。実際には、トリガすることはユーザ・エージェントによって遂行され得る。

これに関して、トリガすること（１０６）は、アプリケーションによって認可サーバに転送可能リフレッシュ・トークンを要求すること（１０８）、アプリケーションによって認可サーバから転送可能リフレッシュ・トークンを受信すること（１１０）であって、転送可能リフレッシュ・トークンが、少なくとも、リフレッシュ・トークン、および長期実行動作を提供するサービスのための識別子を含む、受信すること（１１０）を含む。

加えて、トリガすること（１０６）は、転送可能リフレッシュ・トークンを識別子と共にアプリケーションから、長期実行動作を提供するサービスへ渡すことによって、長期実行動作を提供するサービスの実行を開始すること（１１２）、転送可能リフレッシュ・トークンを、長期実行動作を提供するサービスの識別子と共に、長期実行動作を提供するサービスから認可サーバへ渡すこと（１１４）、長期実行動作を提供するサービスのためのアクセスおよびリフレッシュ・トークンを応答として受信すること（１１６）、長期実行動作を提供するサービスによって認可サーバから － 特に、直接および定期的に － 受信可能なリフレッシュ・トークンを用いて、長期実行動作を提供するサービスを継続すること（１１８）、を含む。

図２は、本提案の発明のコンセプトの対話に関与する要素のブロック図２００を示す。リソース所有者２１０ － 通例、ウェブ・ブラウザの前に座っているエンドユーザ － は、クライアント２０６ － 通例、サービスをエンドユーザに提供しているアプリケーション・サーバ（図示せず）上で実行するウェブ・アプリケーションと対話している。ここで、人としてのリソース所有者の代わりに、ユーザ・エージェントが、図２の他の要素と通信可能に連絡した対話コンポーネントとして用いられ得ることに留意されたい。

対外の対話的ログイン・エクスペリエンス、リソース所有者２１０ － または、同等に、ユーザ・エージェント － は、クライアント２０６のアクセス要求の認証および認可のために認可サーバ２０２へリダイレクトされる。

クライアント２０６ － 通例、ウェブ・アプリケーション － は認可サーバ２０２と対話し、アクセス・トークンを取得する。加えて、本提案のコンセプトの一部として、クライアント２０６はまた、認可サーバ２０２と対話し、転送可能リフレッシュ・トークンを取得する。クライアント２０６は、例えば、ＡＰＩ呼び出しを介して、転送可能リフレッシュ・トークンを長期実行クライアント２０８へ渡す。

長期実行クライアント２０８は認可サーバ２０２と対話し、その転送可能リフレッシュ・トークンを安全にアンラップし、アクセス・トークンをリフレッシュ・トークンと共に取得する。同じ対話が、後にアクセス・トークンをリフレッシュするために必要とされる。長期実行クライアント２０８は、次に、リソース・サーバ２０４と対話し、リソースの所有者の代わりにリソースにアクセスする。

基礎をなす認可（および認証）手順として、ＯＡｕｔｈ２．０のコンセプトが適用され得ることに留意されたい。しかし、また、今述べた転送可能リフレッシュ・トークンはＯＡｕｔｈ２．０システムのコンセプトの一部ではないことも明らかであるはずである。

簡潔に言えば、本提案のコンセプトの利益を得るために、対話ステップの一般的な流れは以下のように記述され得る：
１．クライアント２０６がアクセス・トークンおよび１つまたは複数のリフレッシュ・トークンをリソース所有者２１０から取得する。
２．クライアント２０６が転送可能リフレッシュ・トークンを認可サーバ２０２から取得する。
３．クライアント２０６が長期実行クライアント２０８を呼び出し、転送可能リフレッシュ・トークンを渡す。
４．長期実行クライアント２０８がアクセス・トークンおよび１つまたは複数のリフレッシュ・トークンを転送可能リフレッシュ・トークンから取得する。
５．長期実行クライアント２０８が、適切なアクセス・トークンを用いてリソース・サーバ２０４を呼び出す。
６．長期実行クライアント２０８がアクセス・トークンをリフレッシュし、リソース・サーバ２０４の呼び出しを継続する。

ステップ１、５、６はＯＡｕｔｈ２．０システムによって包括され得ることに留意されたい。しかし、ステップ２、３、４は、ここで新たに提案されるコンセプトに関連することが指摘され得る。

図３ａは第１のステップの対話のブロック図を示す。簡単に言えば、リソース所有者２１０、すなわち、エンドユーザを表すユーザ・エージェントがクライアント２０６（例えば、エイト・ウェブ・アプリケーション（eight web application））と対話し、例えば、長期実行データ分析ジョブを開始する。データ分析ジョブの代わりに、長期実行トランザクション（単数または複数）、長期実行データ伝送、変数間の多くの依存性を伴うデータ・クレンジング・プロセス、人工知能システムへの複雑なアクセス等のような、他の長期実行動作も可能であることに留意されたい。

次に図３ｂ（第１のステップの状態および情報交換の図を示す）を参照すると、ＯＡｕｔｈ２．０規格は、クライアント２０６がリソース所有者２１０またはそのユーザ・エージェントのために取得するトークン（アクセス・トークン／リフレッシュ・トークン）を得るための２つの様式を規定している。第１の様式では、リソース所有者２１０がユーザ名／パスワードの組み合わせをクライアント２０６へ送信する（３０２）。クライアント２０６は、これらのクレデンシャル、ならびに自分の固有のクライアント識別子およびシークレットを受け取り、トークン要求を認可サーバ２０２へ送信する（３０４）。認可サーバは、クライアント２０６によってのみ用いられ得るアクセス・トークンおよびリフレッシュ・トークンを返す（３０６）。通例、クライアント２０６は、リソース所有者とのセッションを維持するために、セッション・クッキー、または同様のものを送り返す（３０８）。

－ 次に図４ａおよび図４ｂを参照すると － ＯＡｕｔｈ２．０に従う第２の様式は、ユーザ名／パスワードをクライアント２０６へ渡すことを必要とすることなく、クライアント２０６のためのトークンを取得する。クライアント２０６は、リソース所有者２１０がクライアント２０６にログインすることを試みた（４０２／４０４）後に － リソース所有者２１０からのクレデンシャル － 具体的には、ユーザ名／パスワード、クライアント＿ＩＤ、およびリダイレクトＵＲＬを含む関連要求 － を認可サーバ２０２へリダイレクトする（４０４）。このリダイレクションと共に、クライアント２０６の識別子およびリダイレクトＵＲＩ（universal resource identifier（ユニバーサル・リソース識別子））が認可サーバ２０２へ渡される（４０６）。リダイレクトＵＲＩは、後に、認可サーバ２０２によって認可／認証がうまく行われた後に、リソース所有者２１０をクライアント２０６へ送り返すために用いられることになる。

リソース所有者２１０は認可サーバ２０２へのリダイレクトに従い（４０６）、クライアント識別子およびリダイレクトＵＲＩを渡し（４０８）、ユーザ名およびパスワードあるいは同様の方法を用いて認証する。妥当性検証が成功した後に、認証サーバ２０２は、リダイレクトＵＲＩ、およびその応答に対する認可コードを用いて、リソース所有者をクライアント２０６へ送り返す（２０８と比較）。

次に、クライアント２０６は、認可コードならびに自分のクライアント識別子およびシークレットを受け取り（４１０）、（POST /token withgrant_type=authCode, client-ID, client_secret,authCodeを用いてそれを要求した（４１２）後に）アクセス・トークンおよびリフレッシュ・トークンを認可サーバ、２０２から取得する（４１４）。上述された第１の様式と同様に、トークンは、関連するクライアント識別子によってのみ用いられ得る。クライアント２０６は、リソース所有者２１０とのセッションを維持するために、セッション・クッキー、または同様のものを送り返す（４１６）。

以下の考察は本提案のコンセプトの動機を図との関連で再び示す。クライアント２０６が転送可能リフレッシュ・トークンを認可サーバ２０６から取得する。クライアント２０６は長期実行クライアント２０８上のＡＰＩを呼び出すことを意図していると仮定され得る。通常のＡＰＩ呼び出しは、そのＡＰＩ呼び出しの認可に対する証明のアクセス・トークンを用いるであろう。この場合には、長期実行クライアント２０８は、クライアント２０６の動作が最大アクセス・トークン有効期限よりも長く続くことになることを意味する。しかし、ここでアクセス・トークンを渡すことは、動作が結局失敗することになるため、無駄である。代わりにリフレッシュ・トークンを渡すことも、長期実行クライアント２０８の認可、すなわち、長期実行クライアント２０８のクライアント識別子およびシークレットが元のクライアント２０６のクライアント識別子とは異なるため、うまくいかない。リフレッシュ・トークンは、それを作成したクライアントによってのみ用いられ得るため、リフレッシュ・トークンは長期実行クライアント２０８のために無駄になるであろう。

この状況のために、本提案のコンセプトは、図１０（ｃ）に示されるように、転送可能リフレッシュ・トークン１００６を導入する。転送可能リフレッシュ・トークン１００６のトークン・タイプは、図１０（ｂ）に示される、名目上のリフレッシュ・トークン１００４と同様であるが、追加情報を包含する。比較の理由のために、図１０（ａ）はアクセス・トークン１００２を示す。

このような転送可能リフレッシュ・トークン１００６を作成するために、クライアント２０６はｒｅｆｒｅｓｈ＿ｔｏｋｅｎグラント・タイプおよび特別なレスポンス・タイプを用いる。クライアント２０６は以下のものを渡す（図５ｂ、５０２と比較；図５ｂは、関連対話コンポーネントを示す図５ａに関連。）
・ リフレッシュ・トークン１００４、
・ このクライアント２０６のための認証情報としてのクライアント識別子およびクライアント・シークレット、ならびに
・ 長期実行クライアント２０８のクライアント識別子。
疑似フォーマットは、POST/token,grant_type=refresh_token, client_id, client_secret, refresh_token,receive_client_id, expire, response_type = transferable_refresh_tokenとなることができるであろう。返信として、クライアント２０６は転送可能リフレッシュ・トークン１００６を受信することになる（図５ｂ、５０４と比較）。

長期実行クライアント２０８のクライアント識別子は、このクライアント識別子のみが転送可能リフレッシュ・トークン１００６を消費することが可能になることを指示するための「受信器クライアント識別子」１００８として記憶されるであろう。転送可能リフレッシュ・トークン１００６は、認可サーバ２０２に渡された、リフレッシュ・トークン１００４の元の有効期限を包含するが、また、転送可能リフレッシュ・トークン１００６がどのぐらいの間、消費され得るのか、すなわち、アクセス・トークンおよびリフレッシュ・トークンに変換され得るのかを指示する別個の有効期限も保持する。

図６ａおよび図６ｂは、第３のステップ、すなわち、クライアント２０６が長期実行クライアント２０８を呼び出し、転送可能リフレッシュ・トークンを構文解析するステップの、関与するコンポーネントおよび関連する状態情報の流れおよび図を示す。

クライアント２０６が転送可能リフレッシュ・トークンを認可サーバ２０２から取得した後に、クライアント２０６は長期実行クライアント２０８を呼び出すことができる。動作のための全ての関連パラメータ、および長期実行クライアント２０８がアクセス・トークンを随時リフレッシュすることを可能にする転送可能リフレッシュ・トークンを渡すＡＰＩ呼び出しを用いて、関連する長期実行動作が開始される（６０２）。開始ＡＰＩは、長期実行クライアント２０８のためのステータス更新を後に可能にするための動作識別子を返すことになる（６０４）。

図７ａおよび図７ｂは、第４のステップ、すなわち、長期実行クライアント２０８がアクセス・トークンおよびリフレッシュ・トークンを転送可能リフレッシュ・トークンから取得するステップの、関与するコンポーネントおよび関連する状態情報の流れおよび図を示す。

長期実行クライアント２０８は、転送可能リフレッシュ・トークンを、それを用いる前にアンラップする必要がある。そのために、長期実行クライアント２０８は認可サーバ２０２を関与させており、転送可能リフレッシュ・トークンおよび長期実行クライアント２０８の認証、すなわち、関連するクライアント識別子およびシークレットを渡す（７０２）。潜在的フォーマットは、POST /token, grant_type=transferable_refresh_token, client_id,client_secret, transferable_refresh_tokenとなり得る。

認可サーバ２０２はクライアントに対して識別子およびシークレットの妥当性を検証し、転送可能リフレッシュ・トークンをアンラップし、長期実行クライアント２０８のクライアント識別子を、転送可能リフレッシュ・トークンの内部にそのトークンの有効な受信器として記憶されたクライアント識別子と比較する。長期実行クライアント２０８識別子が転送可能リフレッシュ・トークン内に包含されている場合にのみ、動作は成功することができる。最後に、転送可能リフレッシュ・トークンの有効期限の妥当性が検証される。

全ての妥当性検証がうまく完了された後に、長期実行クライアント２０８のクライアント識別子によって所有される、新たなアクセス・トークン／リフレッシュ・トークン・ペアが作成され、呼び出し元、すなわち、長期実行クライアント２０８へ返される（７０４）。

図８ａおよび図８ｂは、第５のステップ、すなわち、長期実行クライアント２０８が適切なアクセス・トークンを用いてリソース・サーバ２０４を呼び出すステップの、関与するコンポーネントおよび関連する状態情報の流れおよび図を示す。

長期実行クライアント２０８がアクセス・トークンおよびリフレッシュ・トークンのそのペアを受信した後に、長期実行動作の実行が続行することができる。アクセス・トークンが期限切れになっていない場合には、長期実行クライアント２０８は、リソース・サーバ２０４を呼び出す際に（８０２）、アクセス・トークンを再使用することができる。最後に、長期実行クライアント２０８は結果をリソース・サーバ２０２から受信する（８０４）。

図９ａおよび図９ｂは、第５のステップ、すなわち、長期実行クライアント２０８が、リソース・サーバ２０４の呼び出しを継続するためにアクセス・トークンをリフレッシュするステップの、関与するコンポーネントおよび関連する状態情報の流れおよび図を示す。

長期実行動作の実行の最中に、長期実行クライアント２０８は最終的にアクセス・トークンの有効期限に達することになる。アクセス・トークンが期限切れになった場合には、それは、新たな有効期限を有する新たなアクセス・トークンによって置換される必要がある。このために、長期実行クライアント２０８は標準のＯＡｕｔｈ２．０リフレッシュ・トークンのアプローチを用いてもよく、ｒｅｆｒｅｓｈ＿ｔｏｋｅｎ ＡＰＩ呼び出しを再発行することになる（９０２）。フォーマットは、POST /token, grant_type=refresh_token, client_ID, client_secret,refresh_token=...となり得る。その結果、新たなアクセス・トークンおよび新たなリフレッシュ・トークンが認証サーバ２０２から長期実行クライアント２０８へ返されることになる（９０４）。それゆえ、長期実行動作 － すなわち、長期実行クライアント２０８とリソース・サーバ２０４との間の対話 － を持続させるために、クライアント２０６およびリソース所有者２１０は全く関与しない。

図１１は、データ処理環境内におけるトークンベースの認可のためのセキュリティ・システム１１００のブロック図を示す。データ処理環境は、少なくとも、ユーザ・エージェントを実行するユーザ・システム、アプリケーションを実行するアプリケーション・サーバ、および認可サーバを含む。ユーザ・エージェントは第１のネットワーク接続を介して前記アプリケーションと通信可能に連絡しており、前記アプリケーションは第２のネットワーク接続を介して前記認可サーバと通信可能に連絡している。アプリケーションは、長期実行動作を提供するサービスへのアクセスを提供し、少なくとも、前記長期実行動作を提供する前記サービスは識別子によって識別可能である。

セキュリティ・システムは、前記ユーザ・エージェントを介して前記アプリケーションにアクセスするように適合されたアクセス・ユニット１１０２と、認可プロトコルがうまく終了した後に、アクセス・トークンおよびリフレッシュ・トークンを前記認可サーバから前記アプリケーションへ送信するように適合された送信器１１０４と、前記アプリケーションによって前記長期実行動作を提供する前記サービスの実行をトリガするように適合されたトリガ・ユニット１１０６と、を備える。

トリガ・ユニットは、前記アプリケーションによって前記認可サーバに転送可能リフレッシュ・トークンを要求するように適合された要求モジュール１１０８、前記アプリケーションによって前記認可サーバから前記転送可能リフレッシュ・トークンを受信するように適合された受信器１１１０であって、前記転送可能リフレッシュ・トークンが、少なくとも、リフレッシュ・トークン、および前記長期実行動作を提供する前記サービスのための前記識別子を含む、受信器１１１０、ならびに前記転送可能リフレッシュ・トークンを前記識別子と共に前記アプリケーションから、前記長期実行動作を提供するサービスへ渡すことによって、前記長期実行動作を提供する前記サービスの実行を開始するように適合された開始ユニット１１１２を含む。

加えて、トリガ・ユニットは、前記転送可能リフレッシュ・トークンを、前記長期実行動作を提供する前記サービスの前記識別子と共に、前記長期実行動作を提供する前記サービスから前記認可サーバへ渡すように適合された受け渡しモジュール１１１４、前記長期実行動作を提供する前記サービスのためのアクセスおよびリフレッシュ・トークンを応答として受信するように適合された受信器１１１６、ならびに前記長期実行動作を提供する前記サービスによって前記認可サーバから受信可能なリフレッシュ・トークンを用いて、前記長期実行動作を提供する前記サービスを継続するように適合された継続モジュール１１１８を含む。

本発明の諸実施形態は、プラットフォームが、プログラム・コードを記憶するか、または実行するか、あるいはその両方を行うために適していることに関係なく、事実上任意の種類のコンピュータと共に実施され得る。図１２は、本提案の方法に関連するプログラム・コードを実行するために適したコンピューティング・システム１２００を一例として示す。本提案の方法を実行するために用いられるサーバのうちの１つまたは複数はコンピューティング・システム１２００の形態を有し得る。

コンピューティング・システム１２００は好適なコンピュータ・システムの一例にすぎず、コンピュータ・システム１２００が、実装されるか、または以上において説明された機能性のうちのいずれかを遂行するか、あるいはその両方の能力を有するかどうかに関係なく、本明細書において説明される本発明の諸実施形態の使用または機能性の範囲に関するいかなる限定を示唆することも意図されていない。コンピュータ・システム１２００内には、数多くの他の汎用または専用コンピューティング・システム環境または構成と共に動作可能であるコンポーネントが存在する。コンピュータ・システム／サーバ１２００と共に使用するために適し得る周知のコンピューティング・システム、環境、または構成、あるいはその組み合わせの例としては、限定するものではないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドもしくはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベースのシステム、セット・トップ・ボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上述のシステムもしくはデバイスのうちの任意のものを含む分散クラウド・コンピューティング環境、ならびに同様のものが挙げられる。コンピュータ・システム／サーバ１２００は、プログラム・モジュールなどのコンピュータ・システム実行可能命令がコンピュータ・システム１２００によって実行されるという一般的状況で説明されてもよい。概して、プログラム・モジュールは、特定のタスクを遂行するか、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含み得る。コンピュータ・システム／サーバ１２００は、タスクが、通信ネットワークを通じてリンクされたリモート処理デバイスによって遂行される分散クラウド・コンピューティング環境内で実施されてもよい。分散クラウド・コンピューティング環境内において、プログラム・モジュールは、メモリ記憶デバイスを含むローカルおよびリモート・コンピュータ・システム記憶媒体の両方の内部に配置されてもよい。

図に示されるように、コンピュータ・システム／サーバ１２００は汎用コンピューティング・デバイスの形態で示されている。コンピュータ・システム／サーバ１２００のコンポーネントは、限定するものではないが、１つまたは複数のプロセッサもしくは処理ユニット１２０２、システム・メモリ１２０４、およびシステム・メモリ１２０４を含む様々なシステム・コンポーネントをプロセッサ１２０２に結合するバス１２０６を含み得る。バス１２０６は、メモリ・バスまたはメモリ・コントローラ、周辺バス、アクセラレイティッド・グラフィックス・ポート、ならびに種々のバス・アーキテクチャのうちの任意のものを用いるプロセッサまたはローカル・バスを含む、いくつかの種類のバス構造のうちの任意のもののうちの１つまたは複数を表す。限定ではなく、例として、このようなアーキテクチャとしては、業界標準アーキテクチャ（Industry Standard Architecture、ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（Micro Channel Architecture、ＭＣＡ）バス、拡張ＩＳＡ（Enhanced ISA、ＥＩＳＡ）バス、ビデオ・エレクトロニクス規格協会（Video Electronics Standards Association、ＶＥＳＡ）ローカル・バス、および周辺装置相互接続（Peripheral Component Interconnect、ＰＣＩ）バスが挙げられる。コンピュータ・システム／サーバ１２００は通例、種々のコンピュータ・システム可読媒体を含む。このような媒体は、コンピュータ・システム／サーバ１２００によってアクセス可能である任意の利用可能な媒体であり得、それは、揮発性および不揮発性媒体、着脱式および非着脱式媒体の両方を含む。

システム・メモリ１２０４は、ランダム・アクセス・メモリ（random access memory、ＲＡＭ）１２０８またはキャッシュ・メモリ１２１０あるいはその両方などの、揮発性メモリの形態のコンピュータ・システム可読媒体を含み得る。コンピュータ・システム／サーバ１２００は、他の取り外し可能／非取り外し可能な、揮発性／不揮発性コンピュータ・システム記憶媒体をさらに含み得る。単なる一例として、記憶システム１２１２が、非取り外し可能な不揮発性磁気媒体（図示されておらず、通例、「ハード・ドライブ」と呼ばれる）からの読み取り、およびそれへの書き込みのために設けられ得る。図示されていないが、取り外し可能な不揮発性磁気ディスク（例えば、「フロッピー（Ｒ）・ディスク」）からの読み取り、およびそれへの書き込みのための磁気ディスク・ドライブ、ならびにＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、または他の光媒体などの取り外し可能な不揮発性光ディスクからの読み取り、またはそれへの書き込みのための光ディスク・ドライブが設けられ得る。このような場合には、１つまたは複数のデータ媒体インターフェースによって各々をバス１２０６に接続することができる。以下においてさらに図示され、説明されるように、メモリ１２０４は、本発明の諸実施形態の機能を実施するように構成されたプログラム・モジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含み得る。

プログラム・モジュール１２１６のセット（少なくとも１つ）を有するプログラム／ユーティリティが、限定ではなく、例として、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データと同様に、メモリ１２０４内に記憶されてもよい。オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データ、あるいはこれらの何らかの組み合わせの各々は、ネットワーキング環境の一実装形態を含み得る。プログラム・モジュール１２１６は、本明細書において説明されるとおりの本発明の諸実施形態の機能または方法論あるいはその両方を一般的に実施する。

コンピュータ・システム／サーバ１２００はまた、キーボード、ポインティング・デバイス、ディスプレイ１２２０等などの１つまたは複数の外部デバイス１２１８、ユーザがコンピュータ・システム／サーバ１２００と対話することを可能にする１つまたは複数のデバイス、またはコンピュータ・システム／サーバ１２００が１つまたは複数の他のコンピューティング・デバイスと通信することを可能にする任意のデバイス（例えば、ネットワーク・カード、モデム等）、あるいはその組み合わせと通信し得る。このような通信は入力／出力（Input/Output、Ｉ／Ｏ）インターフェース１２１４を介して行うことができる。それでもなお、コンピュータ・システム／サーバ１２００は、ネットワーク・アダプタ１２２２を介して、ローカル・エリア・ネットワーク（local area network、ＬＡＮ）、一般のワイド・エリア・ネットワーク（wide area network、ＷＡＮ）、または公衆ネットワーク（例えば、インターネット）、あるいはこの組み合わせなどの１つまたは複数のネットワークと通信し得る。図示のように、ネットワーク・アダプタ１２２２はバス１２０６を介してコンピュータ・システム／サーバ１２００の他のコンポーネントと通信し得る。図示されていないが、他のハードウェアまたはソフトウェア・コンポーネントあるいはこの両方をコンピュータ・システム／サーバ１２００と併せて用いることができるであろうことを理解されたい。例としては、限定するものではないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ記憶システム等が挙げられる。

本発明の様々な実施形態の説明が例示の目的のために提示されたが、網羅的であること、または開示された諸実施形態に限定されることを意図されてはいない。当業者には、上述の諸実施形態の範囲および思想から逸脱することなく、多くの変更および変形が明らかであろう。本明細書において使用される用語法は、諸実施形態の原理、実際の適用、または市場において見いだされる技術に対する技術的改善を最もうまく説明するため、あるいは他の当業者が、本明細書において開示される諸実施形態を理解することを可能にするために選定された。

本発明は、システム、方法、またはコンピュータ・プログラム製品、あるいはその組み合わせとして具体化され得る。コンピュータ・プログラム製品は、プロセッサに本発明の諸態様を実施させるためのコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体（または媒体群）を含み得る。

媒体は、伝搬媒体のための電子、磁気、光学、電磁、赤外線、または半導体システムであり得る。コンピュータ可読媒体の例としては、半導体もしくはソリッド・ステート・メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリー・メモリ（read-only memory、ＲＯＭ）、剛性磁気ディスク、および光学ディスクが挙げられ得る。光学ディスクの現在の例としては、コンパクト・ディスク・リード・オンリー・メモリ（compact disk - read only memory、ＣＤ－ＲＯＭ）、コンパクト・ディスク・リード／ライト（compact disk - read/write、ＣＤ－Ｒ／Ｗ）、ＤＶＤ、およびブルー・レイ・ディスクが挙げられる。

コンピュータ可読記憶媒体は、命令実行デバイスによる使用のための命令を保持および記憶することができる有形のデバイスであることができる。コンピュータ可読記憶媒体は、例えば、限定するものではないが、電子記憶デバイス、磁気記憶デバイス、光記憶デバイス、電磁記憶デバイス、半導体記憶デバイス、または上述のものの任意の好適な組み合わせであり得る。コンピュータ可読記憶媒体のより具体的な例の非網羅的なリストは、以下のもの：ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリー・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリー・メモリ（ＥＰＲＯＭ（erasable programmable read-only memory）もしくはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（static random access memory、ＳＲＡＭ）、ポータブル・コンパクト・ディスク・リード・オンリー・メモリ（compact disk read-only memory、ＣＤ－ＲＯＭ）、デジタル多用途ディスク（digital versatile disk、ＤＶＤ）、メモリ・スティック、フロッピー（Ｒ）・ディスク、穿孔カード、または命令が記録された溝内の隆起構造などの、機械的に符号化されたデバイス、ならびに上述のものの任意の好適な組み合わせを含む。コンピュータ可読記憶媒体は、本明細書で使用するとき、電波または他の自由伝搬する電磁波、導波路または他の伝送媒体を通って伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、あるいは電線を通して伝送される電気信号などの、一過性信号自体であると解釈されるべきでない。

本明細書において説明されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスに、あるいはネットワーク、例えば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、または無線ネットワーク、あるいはその組み合わせを経由して外部コンピュータまたは外部記憶デバイスにダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組み合わせを含み得る。各コンピューティング／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェースがネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令をそれぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体における記憶のために転送する。

本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（instruction-set-architecture、ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、あるいはＳｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋、もしくは同様のものなどの、オブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは同様のプログラミング言語などの、従来の手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで書かれた、ソース・コードまたはオブジェクト・コードのいずれかであり得る。コンピュータ可読プログラム命令は完全にユーザのコンピュータ上で実行するか、一部ユーザのコンピュータ上で実行するか、独立型ソフトウェア・パッケージとして実行するか、一部ユーザのコンピュータ上で、且つ一部リモート・コンピュータ上で実行するか、または完全にリモート・コンピュータもしくはサーバ上で実行し得る。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む、任意の種類のネットワークを通じてユーザのコンピュータに接続され得るか、あるいは外部コンピュータへの接続が（例えば、インターネット・サービス・プロバイダを利用してインターネットを通じて）行われてもよい。実施形態によっては、例えば、プログラマブル論理回路機構、フィールド・プログラマブル・ゲート・アレイ（field-programmable gate array、ＦＰＧＡ）、またはプログラマブル論理アレイ（programmable logic array、ＰＬＡ）を含む電子回路機構が、本発明の諸態様を遂行するために、コンピュータ可読プログラム命令の状態情報を利用して電子回路機構を個別化することによって、コンピュータ可読プログラム命令を実行し得る。

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

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行する命令が、フローチャートまたはブロック図あるいはその両方のブロックまたはブロック群において指定された機能／行為を実施するための手段を生み出すように、汎用コンピュータ、専用コンピュータ、または機械を作り出すための他のプログラム可能データ処理装置のプロセッサに提供され得る。これらのコンピュータ可読プログラム命令はまた、内部に記憶された命令を有するコンピュータ可読記憶媒体が、フローチャートまたはブロック図あるいはその両方のブロックもしくはブロック群内で指定された機能／行為の諸態様を実施する命令を含む製造品を構成するように、コンピュータ、プログラム可能データ処理装置、または他のデバイスあるいはその組み合わせを特定の仕方で機能するように仕向けることができるコンピュータ可読記憶媒体内に記憶され得る。

コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラム可能装置、または別のデバイス上で実行する命令が、フローチャートまたはブロック図あるいはその両方のブロックまたはブロック群において指定された機能／行為を実施するように、コンピュータ、他のプログラム可能データ処理装置、または別のデバイス上にロードされ、一連の動作ステップを、コンピュータ、他のプログラム可能装置、または他のデバイス上で遂行させ、コンピュータ実施プロセスを作り出し得る。

図面におけるフローチャートまたはブロック図あるいはその両方は、本発明の様々な実施形態に係るシステム、方法、およびコンピュータ・プログラム製品の可能な諸実装形態のアーキテクチャ、機能性、および動作を示す。この点に関して、フローチャートまたはブロック図における各ブロックは、指定された論理機能（単数または複数）を実施するための１つまたは複数の実行可能命令を含む、命令のモジュール、セグメント、または部分を表し得る。いくつかの代替的実装形態では、ブロック内に記された機能は、図面に記された順序に従わずに生じてもよい。例えば、連続して示された２つのブロックは、実際には、実質的に同時に実行されてもよく、またはブロックは、時として、含まれる機能性に依存して、逆の順序で実行されてもよい。また、ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方におけるブロックの組み合わせは、指定された機能もしくは行為を遂行するか、あるいは専用ハードウェアおよびコンピュータ命令の組み合わせを実行する専用ハードウェアベースのシステムによって実施され得ることにも留意されたい。

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

以下の請求項における全てのミーンズまたはステップ・プラス・ファンクション要素の対応する構造、物、行為、および同等物は、具体的にクレームされているとおりに、他のクレームされている要素と組み合わせて機能を遂行するための任意の構造、物、または行為を含むことが意図される。本発明の説明は例示および説明を目的として提示されたが、網羅的であること、または開示されている形態の発明に限定されることを意図されてはいない。当業者には、本発明の範囲および思想から逸脱することなく、多くの変更および変形が明らかであろう。諸実施形態は、本発明の原理、および実際の適用を最もうまく説明し、他の当業者が、本発明を、企図される特定の使用に適した様々な変更と共に様々な実施形態のために理解することを可能にするために選定され、説明されている。

Claims (12)

1. データ処理環境内におけるトークンベースの認可のための方法であって、
   前記データ処理環境が、少なくとも、
   ユーザ・エージェントを実行するユーザ・システム、
   アプリケーションを実行するアプリケーション・サーバ、および
   認可サーバ
   を含み、
   前記ユーザ・エージェントが第１のネットワーク接続を介して前記アプリケーションと通信可能に連絡しており、前記アプリケーションが第２のネットワーク接続を介して前記認可サーバと通信可能に連絡しており、
   前記アプリケーションが、長期実行動作を提供するサービスへのアクセスを提供し、
   少なくとも、前記長期実行動作を提供する前記サービスが識別子によって識別可能であり、
   前記方法が、
   － 前記ユーザ・エージェントを介して前記アプリケーションにアクセスすることと、
   － 認可プロトコルが終了した後に、アクセス・トークンおよびリフレッシュ・トークンを前記認可サーバから前記アプリケーションへ送信することと、
   － 前記アプリケーションによって前記長期実行動作を提供する前記サービスの実行をトリガすることと、
   を含み、前記トリガすることが、
   － 前記アプリケーションによって前記認可サーバに転送可能リフレッシュ・トークンを要求すること、
   － 前記アプリケーションによって前記認可サーバから前記転送可能リフレッシュ・トークンを受信することであって、前記転送可能リフレッシュ・トークンが、少なくとも、リフレッシュ・トークン、および前記長期実行動作を提供する前記サービスのための前記識別子を含む、前記受信すること、
   － 前記転送可能リフレッシュ・トークンを前記識別子と共に前記アプリケーションから、前記長期実行動作を提供する前記サービスへ渡すことによって、前記長期実行動作を提供する前記サービスの実行を開始すること、
   － 前記転送可能リフレッシュ・トークンを、前記長期実行動作を提供する前記サービスの前記識別子と共に、前記長期実行動作を提供する前記サービスから前記認可サーバへ渡すこと、
   － 前記長期実行動作を提供する前記サービスのためのリフレッシュ・トークンを応答として受信すること、
   － 前記長期実行動作を提供する前記サービスによって前記認可サーバから受信可能なリフレッシュ・トークンを用いて、前記長期実行動作を提供する前記サービスを継続すること、
   を含む、方法。
2. 前記転送可能リフレッシュ・トークンが有効期限をさらに含む、請求項１に記載の方法。
3. 前記ユーザ・エージェントを介して前記アプリケーションに前記アクセスすることが、また、
   － 前記アプリケーション、前記ユーザ・エージェント、および前記認可サーバの間の認可プロトコルを用いることを含み、前記アクセスすることが、前記アプリケーションと前記認可サーバとの間で認証クレデンシャルを交換することによって認可される、請求項１に記載の方法。
4. 前記転送可能リフレッシュ・トークンを前記要求することに関連する要求が、また、前記リフレッシュ・トークンを、前記長期実行動作を実行する前記サービスの前記識別子と共に含む、請求項１に記載の方法。
5. 前記認可サーバが、ＯＡｕｔｈ２．０プロトコルに従って認可サービスを提供するように適合されている、請求項１に記載の方法。
6. 前記長期実行動作が、データ分析プロセス、データ転送プロセス、バックアップ・プロセス、データ再編成、およびニューラル・ネットワークのプロセスを含む群から選択される、請求項１に記載の方法。
7. 前記長期実行動作が前記アプリケーションのアクセス・トークン有効期限よりも長く実行する、請求項１に記載の方法。
8. 前記転送可能リフレッシュ・トークンが、少なくとも、ユーザ識別子、前記転送可能リフレッシュ・トークンの有効期限、前記長期実行動作を提供する前記サービスの識別子、および前記長期実行動作を提供する前記サービスの有効期限を含む、請求項１に記載の方法。
9. 前記長期実行動作を提供する前記サービスが、第２の長期実行動作を提供する第２のサービスに提供される第２の転送可能リフレッシュ・トークンを要求する、請求項１に記載の方法。
10. 前記アプリケーションによって前記認可サーバに転送可能リフレッシュ・トークンを前記要求することが、前記ユーザ・エージェントによる確認後にのみ遂行される、請求項１に記載の方法。
11. データ処理環境内におけるトークンベースの認可のためセキュリティ・システムであって、
    前記データ処理環境が、少なくとも、
    ユーザ・エージェントを実行するユーザ・システム、
    アプリケーションを実行するアプリケーション・サーバ、および
    認可サーバ
    を含み、
    前記ユーザ・エージェントが第１のネットワーク接続を介して前記アプリケーションと通信可能に連絡しており、前記アプリケーションが第２のネットワーク接続を介して前記認可サーバと通信可能に連絡しており、
    前記アプリケーションが、長期実行動作を提供するサービスへのアクセスを提供し、
    少なくとも、前記長期実行動作を提供する前記サービスが識別子によって識別可能であり、
    前記セキュリティ・システムが、
    － 前記ユーザ・エージェントを介して前記アプリケーションにアクセスするように適合されたアクセス・ユニットと、
    － 認可プロトコルが終了した後に、アクセス・トークンおよびリフレッシュ・トークンを前記認可サーバから前記アプリケーションへ送信するように適合された送信器と、
    － 前記アプリケーションによって前記長期実行動作を提供する前記サービスの実行をトリガするように適合されたトリガ・ユニットと、
    を備え、前記トリガ・ユニットが、
    － 前記アプリケーションによって前記認可サーバに転送可能リフレッシュ・トークンを要求するように適合された要求モジュール、
    － 前記アプリケーションによって前記認可サーバから前記転送可能リフレッシュ・トークンを受信するように適合された受信器であって、前記転送可能リフレッシュ・トークンが、少なくとも、リフレッシュ・トークン、および前記長期実行動作を提供する前記サービスのための前記識別子を含む、前記受信器、
    － 前記転送可能リフレッシュ・トークンを前記識別子と共に前記アプリケーションから、前記長期実行動作を提供する前記サービスへ渡すことによって、前記長期実行動作を提供する前記サービスの実行を開始するように適合された開始ユニット、
    － 前記転送可能リフレッシュ・トークンを、前記長期実行動作を提供する前記サービスの前記識別子と共に、前記長期実行動作を提供する前記サービスから前記認可サーバへ渡すように適合された受け渡しモジュール、
    － 前記長期実行動作を提供する前記サービスのためのリフレッシュ・トークンを応答として受信するように適合された受信器、
    － 前記長期実行動作を提供する前記サービスによって前記認可サーバから受信可能なリフレッシュ・トークンを用いて、前記長期実行動作を提供する前記サービスを継続するように適合された継続モジュール、
    を含む、セキュリティ・システム。
12. プロセッサに、請求項１ないし１０のいずれか一項に記載の方法を実行させるためのプログラム。

Images