JP2015501021A - ＯＡｕｔｈフレームワーク - Google Patents

Abstract

OAuth標準に準拠するフレームワークは、複数のリソースサーバ上に格納されるリソースへのアクセスがリソース所有者が同意するアクセスに確実に限られるように複数のリソースサーバによって用いられ得る包括的OAuth承認サーバに係る。各々のリソースサーバは、OAuth承認サーバに、リソースサーバによって認識されるスコープを示す当該リソースサーバのためのメタデータを登録する。OAuth承認サーバは、クライアントアプリケーションに代わってリソース所有者からの同意を要求する際に、同意が適切なスコープとなるように、このメタデータを参照する。OAuth承認サーバは、リソースサーバ上のリソースへのアクセスに用いるためにクライアントアプリケーションに与えるアクセストークンを構築する際に、このメタデータを参照する。OAuth承認サーバは、このメタデータを用いて、発行されたアクセストークンを、それらのアクセストークンがアクセスを認めるスコープにマッピングする。

Description

優先権主張
本出願は、２０１１年９月２９日に出願され、「リライングパーティおよびOAuthフレームワーク」と題された米国仮特許出願連続番号第６１／５４１，０２６号に対する米国特許法第１１９条に基づく優先権を主張する。

背景
アイデンティティ管理システムは、企業または相互ネットワークアイデンティティ管理のために用いることができる情報システムまたは技術の組である。アイデンティティ管理は、コスト、ダウンタイム、および繰返しタスクを減少しつつセキュリティおよび生産性を向上させるという目標を持って、システムおよび企業の内部でのまたはシステムおよび企業の境界を横断して個々のアイデンティティの管理、それらの認証（authentication）、承認（authorization）、役割、および特権付与を説明する。アイデンティティ管理の１つの局面は「シングルサインオン」（ＳＳＯ）である。アイデンティティ管理の分野で特に有用な１つの基準がOAuthである。

ＳＳＯは、関連しているが独立した複数のソフトウェアシステムのアクセス制御のプロパティである。このプロパティを用いると、ユーザは一度ログインし、すべてのシステムの各々において再びログインを促されることなく、すべてのシステムへのアクセスを得る。反対に、シングルサインオフは、これによって単一のサインアウト行為が複数のソフトウェアシステムへのアクセスを終了させるプロパティである。異なるアプリケーションおよびリソースは異なる認証メカニズムをサポートするので、シングルサインオンは、初期の認証で用いられるものとは異なる認証情報に内部変換して、これを格納する。ＳＳＯはフィッシングの成功を低減させる。なぜなら、ユーザは、考えずにあらゆるところでパスワードを入力するようには訓練されていないからである。ＳＳＯは、異なるユーザ名とパスワードとの組合せからのパスワード疲労を低減する。ＳＳＯは、同じアイデンティティにパスワードを再入力するのに費やされる時間を低減する。ＳＳＯは、パスワードについての情報技術（ＩＴ）ヘルプデスクへの通話の数が減ることにより、ＩＴコストを低減する。ＳＳＯは、ユーザに再催促するという不便なしに、システムへの／からの入退場／アクセスという全レベルのセキュリティを与える。ＳＳＯはコンプライアンス厳守のための集中的な報告も可能にする。ＳＳＯは、すべての他のアプリケーションおよびシステムが認証目的のために利用する集中認証サーバを用い、これを、ユーザが自身の認証情報を１回よりも多くせっせと入力しなくてもよいことを確実にする技術と組合せる。

OAuthは承認のためのオープン標準である。承認の間接的な効果が認証である。OAuthは、ユーザが、典型的には代わりにユーザ名およびパスワードトークンを供給して、自身の認証情報を渡す必要なく、１つのサイト上に格納されている自身の個人的なリソース（たとえば、写真、ビデオ、連絡先など）を別のサイトと共有できるようにする。各々のトークンは、規定された持続時間の間、特定的なリソースに対して特定的なサイトへのアクセスを認める。これにより、ユーザは、自身のアクセス許可またはその全データ範囲を共有することなく、別のサービスプロバイダが格納する自身の情報への第三者のサイトアクセスを認めることができるようにする。たとえば、トークンは、今から２時間の間、特定的なアルバムからのビデオについて、ビデオ編集サイトへのアクセスを認め得る。

たとえば、典型的な筋書きでは、LinkedInのユーザは、当該ユーザの連絡先をYahooからインポートする許可をLinkedInに求められることがある。LinkedInは、たとえば、ユーザの連絡先の各々にLinkedInに参加するよう誘う電子メールメッセージを送るためにこれらの連絡先を入手したいのかもしれない。OAuth以前は、この許可の要求は、ユーザがユーザのYahooユーザアイデンティティおよびパスワードをLinkedInに提供するという要求に係ったかもしれない。この情報は、LinkedInが当該ユーザとしてユーザのYahooアカウントにログインして、次に当該ユーザのYahooアカウントから当該ユーザの連絡先を入手できるように要求された。一般的に述べると、ユーザのYahoo（または任意の他のサイト）のアイデンティティおよびパスワードをLinkedIn（または任意のサイト）に許すのはよい考えではない。なぜなら、これは、LinkedInサイトにYahooサイトのユーザのアカウントへの無制限アクセスを認めるからである。そのような無制限アクセスはほぼ常に、単に連絡先一覧を入手することなどの、LinkedInサイトが実際にその目標を達成するのに必要な分をはるかに超えるアクセスである。

もっとよい考えは、Yahooサイトのユーザのアカウントに対して限られた承認をLinkedInサイトに与えることである。限られた承認は、Yahooサイトのユーザのアカウントに対してLinkedInサイトが行なえる動作の特定的なセットを特定し得る。たとえば、典型的な上記の筋書きを参照すると、限られた承認は、LinkedInがユーザの連絡先一覧にアクセスするしかできず、Yahooのユーザのアカウントに対して他の動作を行なえないと特定し得る。OAuthにより、そのような限られた承認が可能になる。OAuthは承認の委任を与える。

OAuthがそれによって承認を委任する技術は、類推に相対して理解されてもよい。しばしば、車の所有者が、駐車係が所有者の代わりに車を駐車できるように自身の車の管理を一時的に駐車係に譲る場合、所有者は、一般用途マスターキーを駐車係に与えるのではなく、代わりに、より用途が限定された駐車係用キーを駐車係に与える。駐車係用キーは、車を運転するのに十分なアクセスを駐車係に許すが、所有者が車内に所有するあらゆるものへのアクセスを駐車係に与えるわけではない。同じように、OAuthの使用は、第２のサイトでユーザのアカウントに対して他の動作を行なうことを第１のサイトに許すこともなく−たとえば第２のサイトが格納し得る電子メールメッセージを読むなどの、第２のサイトが格納するユーザの連絡先一覧への第１のサイトのアクセスを認め得る。OAuthは、特定される組の動作を第２のサイトに対して行なうという限られた承認が第１のサイトに与えられるようにして、それ以外は与えられないようにする。

別の例として、ユーザは、Snapfishなどの第１のサイトが提供する写真プリントサービスを用いて、第１のサイトとは独立したFlickrなどの第２のサイトが電子的に格納するあるカラー写真をプリントしたいことがある。より具体的には、ユーザは、ユーザの最近のアラスカ訪問からの写真を含むアルバムなどのFlickr上の特定のアルバムに格納されている写真のみをプリントしたいことがある。ユーザは、自身のFlickrアカウントに多数の異なるアルバムを格納していることがあるが、ユーザはアラスカのアルバムからの写真のみをプリントしたいことがある。そのような状況では、ユーザはおそらく、アラスカのアルバムの中に含まれるもの以外の自身のFlickrアルバムのいずれの内容にもSnapfishがアクセスしないのをより好む。上記の筋書きでは、OAuth用語を用いると、Snapfishがクライアントと考えられ、Flickrがリソースサーバ（写真データがリソースである）およびOAuth承認サーバであると考えられる。リソースサーバに格納されるリソース（たとえば写真データ）の所有者として、ユーザはリソース所有者でもある。

以上で提示された例を考慮すると、ユーザは、自身のインターネットブラウザアプリケーションをまず用いて、クライアント（たとえばSnapfish）に、リソースサーバ（たとえばFlickr）上のユーザのアラスカのアルバム中の写真をプリントするよう指示し得る。応答して、クライアント（たとえばSnapfish）は、ユーザをリソース承認サーバ（たとえばFlickr）のサイトに転送する。この転送動作は、リソースサーバに対して、クライアントがそれへのアクセスを望むデータの限られたセット（たとえばアラスカのアルバムの内容）を示し得る。リソース承認サーバは、その瞬間にユーザが誰であるかを知らない。というのも、ユーザはリソース承認サーバに対して自身を認証していないからである。したがって、リソース承認サーバは、ユーザが認証を行なうことを要件とする。以上で言及したように、承認の間接的な効果が認証である。（たとえば、リソース承認サーバに関連のユーザのユーザ名およびパスワードを与えることによって）ユーザがリソース承認サーバに対して自身を承認した後、リソース承認サーバは、ユーザのインターネットブラウザに同意ページを送る。同意ページは、リソース承認サーバ（たとえばFlickr）が、限られた特定されたデータのセット（たとえばアラスカのアルバムの内容）をクライアント（たとえばSnapfish）に提供するユーザの許可を有することを確認するようユーザに頼む。ユーザが同意すると仮定して、リソース承認サーバは次に、応答してクライアントに承認コードを送る。この承認コードは、「フロントチャネル」を通して、または換言すると転送を用いてユーザのインターネットブラウザを経由して送られ得る。

この筋書きでは、クライアント（たとえばSnapfish）は、承認サーバ（たとえばFlickr）の信用されるパートナーである。クライアントは承認コードまたは「承諾」を受信して、承認コードを格納する。クライアントは、ユーザがその承認コードを能動的に取消すまで、この承認コードを無限に維持する。ユーザは、OAuth承認サーバにログインして、OAuth承認サーバがユーザの代わりにさまざまなクライアントに与えた承諾の一覧を閲覧してもよい。承認コードを受信するのに応答して、クライアント（たとえばSnapfish）は、承認サーバ（たとえばFlickr）への「バックチャネル」通話を行なう。バックチャネル通話は、ユーザのインターネットブラウザに係らない通信である。バックチャネル通話は承認サーバからのアクセストークンを要求する。アクセストークンは、クライアントが承認サーバ上のユーザのアカウントに対して許されているアクセスのスコープを特定する。たとえば、アクセストークンは、クライアントがユーザのアラスカのアルバムの内容にしかアクセスを許されていないことを示し得る。承認サーバは、バックチャネルを介して、要求されたアクセストークンをクライアントに送り返す。クライアントはアクセストークンを格納する。その後、アクセストークンが期限切れになるまでまたはユーザが承諾（すなわち承認コード）を取消すまで、クライアントはアクセストークンをリソースサーバに提示して、アクセストークンによって特定されるリソースにリソースサーバ上でアクセスすることができる。ユーザがアクセストークンに関する承諾を既に取消していた場合は、アクセストークンは、アクセストークンがまだ期限切れになっていなくても、無効となる。

アクセストークンに加えて、承認サーバはクライアントに「リフレッシュトークン」を与えることがある。アクセストークンはしばしば特定された寿命を有し、その後では期限切れになってしまうが、リフレッシュトークンは長命のトークンである。クライアントは、関連のアクセストークンとともにリフレッシュトークンを格納し得る。その後、リソースサーバがクライアントの現在のアクセストークンが期限切れであるとする場合は、クライアントはリフレッシュトークンをリソースサーバに提示して、リソースサーバから新しいアクセストークンを入手し得る。

有利には、OAuthが用いる方策は、リソースサーバ上のユーザのアカウントについての、クライアントに対するユーザのパスワードの開示を回避する。認証情報のこの開示を回避することにより、クライアントがリソースサーバ上のユーザのアカウントに対して不正行為を行なえないようにする。ユーザが自身のパスワードを供給する唯一の時間は、クライアントのサイトから転送された後のリソースサーバとの直接のユーザの初期認証の間である。

簡単な概要
本発明の実施形態は、アイデンティティ管理、認証、および承認フレームワークに関する。１つの実施形態では、フレームワークは、エンタープライズのアイデンティティおよびアクセス管理（ＩＡＭ）インフラストラクチャにおけるインターネットアイデンティティの統合のために設けられる。別の実施形態に従うと、フレームワークはオープン承認のために設けられる。OAuthシステムについては非常に多くの異なる使用事例があるので、単一の方策が常に各々の使用事例に合うわけではない。したがって、発明の実施形態は、OAuthシステムをより柔軟にする。発明の実施形態は、OAuthシステムをそのシステムのエンタープライズ管理者にとってより容易なものにして、管理者自身の用途向けにカスタマイズする。発明の実施形態は、OAuthシステムを、アプリケーションプロバイダおよびリソースプロバイダによってよりカスタマイズしやすいものにする。

伝統的に、リソースサーバおよびOAuth承認サーバは同じエンティティであった。発明の実施形態に従うと、OAuth承認サーバの責務からリソースサーバを解放する包括的フレームワークが設けられる。これらの責務は、スコープ管理、承認トークンの発行、リフレッシュトークンの発行、およびアクセストークンの発行を含み得る。このように、包括的OAuth承認サーバはこの包括的フレームワークに従って実現可能である。その結果、各個々のリソースサーバは、それ自身の独自のOAuth承認サーバを実現する必要がない。実際、発明の実施形態に従うと、複数の異なるリソースサーバはすべて同時に同じ包括的OAuth承認サーバの機能を用いることができる。たとえば、発明の実施形態では、単一のOAuth承認サーバは、すべて同時にいくつかの異なるリソースサーバについてスコープを管理することができる。リソースサーバとOAuth承認サーバとの間には多数対１の関係が存在し得る。

発明の１つの実施形態では、この複数の異なるリソースサーバと対話できることを達成するため、包括的OAuth承認サーバは、どのトークンがどのリソースサーバに属し、誰が各リソースサーバの信用されるパートナーであるのかなどを示すマッピングデータを維持する。さらに、発明の実施形態では、包括的OAuthフレームワークは、リソースサーバ管理者がフレームワークを容易にカスタマイズして自身のリソースサーバのための特定の使用事例に対応できるように構築される。異なるリソースサーバ管理者は自身の特定的なコンポーネントを包括的OAuthフレームワークに「プラグイン」することができる。このように、発明の１つの実施形態では、各々のリソースサーバは、リソースサーバが使用するかもしれない潜在的なスコープ（すなわちリソースに対する限られた動作）に関して包括的OAuth承認サーバに通知する。

以上は、他の特徴および実施形態とともに、以下の明細書、請求項、および添付の図面を参照するとより明らかになるであろう。

発明の実施形態に従うOAuthシステムアーキテクチャおよびその論理コンポーネントを図示するブロック図である。 発明の実施形態に従うリソースサーバ環境を図示するブロック図である。 発明の実施形態に従うOAuthクライアント環境を図示するブロック図である。 発明の実施形態に従う、包括的OAuth承認サーバに第１のリソースサーバのメタデータを登録するための技術を図示するフロー図である。 発明の実施形態に従う、包括的OAuth承認サーバに第２のリソースサーバのメタデータを登録するための技術を図示するフロー図である。 本発明の実施形態に従って用いられ得るシステム環境のコンポーネントを図示する簡略ブロック図である。 本発明の実施形態に従って用いられ得るコンピュータシステムの簡略ブロック図である。

詳細な説明
以下の説明では、説明の目的のため、発明の実施形態の完全な理解を与えるための具体的な詳細を述べる。しかしながら、発明はこれらの具体的詳細がなくても実践され得ることが明らかであろう。２０１１年９月２９日に出願され、「リライングパーティおよびOAuthフレームワーク」と題された米国仮特許出願連続番号第６１／５４１，０２６号の全内容がここに引用により援用される。

図１は、発明の実施形態に従う、OAuthシステムアーキテクチャ１００およびその論理コンポーネントを図示するブロック図である。アーキテクチャ１００は、リソース所有者（またはユーザ）１０２、クライアントアプリケーション１０４、リソースレジストリ１０６、およびリソースエコシステム１１０を含む。リソースエコシステムは、クライアントレジストリ１１２、トークン−スコープレジストリ１１４、スコープレジストリ１１６、ユーザ同意１２０、およびリソースサーバ１２２を含む。１つのリソースサーバ１２２が示されるが、発明の実施形態は複数の別個のリソースサーバを含むことができる。図１の接続からわかるように、クライアントアプリケーション１０４はリソースレジストリ１０６と対話する。リソース所有者１０２は、リソースレジストリ１０６およびクライアントレジストリ１１２と対話する。承認サーバ１１８は、クライアントレジストリ１１２、トークン−スコープレジストリ１１４、およびユーザ同意１２０と対話する。リソースサーバ１２２は、トークン−スコープレジストリ１１４と対話する。ユーザ同意１２０は、スコープレジストリ１１６と対話する。これらのコンポーネントおよびその機能のさまざまなものを以下にさらに論じる。

発明の実施形態は承認の委任に係ることができる。異なるリソース使用事例は異なるスコープ定義を要件とすることがある。異なるリソースは、異なる承認モデルおよびソリューションに依拠することができることがある。異なる特定的ユーザ行為は、異なるリソースサーバが維持するリソースにアクセスするクライアントアプリケーション同意を与えることが要件とされ得る。好ましくは、各々の異なるリソースプロバイダは、別個の独自OAuth承認サーバを設けて当該リソースプロバイダの具体的詳細と統合する必要がないようにすべきである。各々のリソースプロバイダが別個の独自OAuth承認サーバを設けることの不幸な結果は、複数の異なるリソースプロバイダおよび複数の異なるクライアントフォームファクタと統合することを望むエンタープライズが無数の異なるOAuth承認サーバインターフェイスを扱わなければならなくなることであろう。

したがって、発明の実施形態では、包括的OAuthフレームワークアーキテクチャが提供される。フレームワークは、メタデータおよびランタイムレジストリを含むOAuthワイヤプロトコルコンポーネント（クライアントおよびサーバ）を含み得る。フレームワークは、特定用途向けソリューションをカスタマイズし、配備するプラグ可能な「コントラクト」のインフラストラクチャを含み得る。

発明の１つの実施形態では、リソースサーバ１２２は、トークン−スコープレジストリ１１４の中に、リソースサーバ１２２が認識するスコープの表示を格納する。各々のそのようなスコープは、リソースサーバ１２２上に格納されるリソースの異なるセットに対して行なわれ得る動作の異なるセットを示すことができる。ある実施形態が複数の異なるまたは別個のリソースサーバを含み得る限り、トークン−スコープレジストリ１１４は異なるリソースサーバと異なるスコープとの間のマッピングを格納することができる。さらに、発明の１つの実施形態では、各々のスコープは、トークン−スコープレジストリ１１４内の別個のトークンにマッピングされる。このように、トークン−スコープレジストリ１１４の参照により、リソースサーバ１２２は、クライアントアプリケーション１０４によってリソースサーバ１２２に提示される特定のトークンにマッピングされる動作のセットおよびリソースのセットを定めることができる。リソースサーバ１２２は、リソースサーバ１２２が維持するリソースに対してクライアントアプリケーション１０４が行なう動作を、特定のトークンにマッピングされる動作のセットが具体的に示す動作に限ることができる。

このように、発明の１つの実施形態では、複数のリソースサーバの群のうちの各々の特定のリソースサーバは、当該特定のリソースサーバ上のリソースにアクセスするのに用いることができるトークンにマッピング可能なスコープを示すメタデータの異なるセットをOAuthフレームワークに与える。したがって、スコープはリソースサーバの管理者によってカスタマイズ可能であり、OAuthフレームワークを柔軟にするとともに多数の異なる使用事例に適用可能にする。その結果、多くの異なる種類のリソースサーバはすべて、リソースサーバの各々異なる種類毎の特定的なOAuthフレームワークの作成を必要とせずに、同じ包括的OAuthフレームワークを用いることができる。

実施形態では、図１に示される包括的OAuthフレームワークが基本概念構造を提供する。OAuthフレームワークは、既存のアイデンティティ管理製品上に層をなすことができる。OAuthフレームワークでは、コントラクトはこれらの既存の製品との統合点を規定することができる。OAuthフレームワークとコントラクト実現例との組合せは、種々雑多な使用事例および配備オプションを満たすことができる。実施形態に従うと、OAuthフレームワークは、２つの広い「ロール」、すなわちコンシューマー／クライアントロールおよび承認サーバ／リソースサーバロール、を含む。図２を参照して承認サーバ／リソースサーバロールを以下に論じる一方で、図３を参照してコンシューマー／クライアントロールを以下に論じる。

図２は、発明の実施形態に従うリソースサーバ環境２００を図示するブロック図である。発明の実施形態では、環境２００は、リソース所有者（またはユーザ）２０２、クライアントアプリケーション２０４、リソースサーバ２１０、OAuth承認サーバ２２０、ポリシーサービス２４０、およびトークンサービス２５０を含む。リソースサーバ２１０は、アクセストークン有効化ＡＰＩ２１４およびゲート２１６を含むリソースサーバアプリケーション２１２を含む。OAuth承認サーバ２２０は、トークン−スコープレジストリ２２２、リソース＆スコープレジストリ２２４、ユーザ同意オーケストレーション２２６、ＯＰＳＳ−ＴＳ（オラクルプラットフォームセキュリティサービス−ＴＳ）２２８、ＯＰＳＳ−ＡＺ（オラクルプラットフォームセキュリティサービス−ＡＺ）２３０、OAuthコアエンジン２３２、OAuthプロトコルエンジン２３４、およびクライアントレジストリ２３６を含む。実施形態では、リソース所有者２０２はクライアントアプリケーション２０４と対話し、ゲート２１６を通してアクセストークン有効化ＡＰＩ２１４にアクセスする。クライアントアプリケーション２０４はOAuth承認サーバ２２０とも対話する。アクセストークン有効化ＡＰＩ２１４は、トークン−スコープレジストリ２２２およびポリシーサービス２４０と対話する。ＯＰＳＳ−ＴＳはトークンサービス２５０と対話する。ＯＰＳＳ−ＡＺはポリシーサービス２５０と対話する。コンポーネント２２８−２３４はまとめて、トークン−スコープレジストリ２２２およびユーザ同意オーケストレーション２２６と対話する。ユーザ同意オーケストレーション２２６はリソース＆スコープレジストリ２２４と対話する。

発明の実施形態では、リソース＆スコープレジストリ２２４は、リソース情報、スコープ、ならびにOAuth承認サーバ２２０を介して公開されるリソースおよびサービスに関連の種々雑多なメタデータを格納する。発明の実施形態では、クライアントレジストリ２３６は、承認された遠隔のクライアント（たとえばクライアントアプリケーション２０４）のための信用鍵および秘密を格納する。実施形態では、トークン−スコープレジストリ２２２は、ユーザ（たとえばリソース所有者２０２）同意に基づいてクライアント（たとえばクライアントアプリケーション２０４）に発行されるアクセストークンおよびリフレッシュトークンを格納する。実施形態では、トークン−スコープレジストリ２２２は、発行されたアクセストークンと関連付けられるAuthZスコープ情報を格納する。

発明の実施形態では、リソースサーバ２１０は、OAuth承認サーバ２２０にそれ自身のメタデータを登録する。異なるリソースサーバは同じOAuth承認サーバに異なるメタデータを登録することができる。登録プロセスの一部として、このメタデータはOAuth承認サーバ２２０にインポートされる。メタデータは、リソースサーバ２１０によって認識されるまたは公開されるさまざまな異なるスコープを示す。各々のスコープはリソースサーバ２１０が維持するリソースの異なるサブセットを特定する。発明の実施形態では、登録時に、リソースサーバ２１０が認識する各々のスコープは、リソース＆スコープレジストリ２２４の中で、リソースサーバ２１０（のみ）にマッピングされる。このように、発明の実施形態では、リソース＆スコープレジストリは、各々の登録されたスコープ毎に、そのスコープ内でアクセス可能な対応のリソースサーバのリソースのセットを示す。たとえば、スコープは、特定の写真のみがアクセス可能であること、または写真の特定のフォルダがアクセス可能であること、またはフォルダの特定のセットがアクセス可能であることを示し得る。スコープは、読出、更新、削除、作成などの、特定されたリソースに対して許容できる動作を示すことができる。

発明の実施形態では、OAuth承認サーバ２２０は、クライアントアプリケーション２０４にアクセストークンを発行する。実施形態では、そのようなアクセストークン毎に、OAuth承認サーバ２２０は、トークン−スコープレジストリ２２２の中に、アクセストークンと、当該アクセストークンに割当てられる（リソース＆スコープレジストリ２２４の中に格納されるスコープから選択される）特定のスコープとの間のマッピングを格納する。同じリソースサーバについての異なるアクセストークンには異なるスコープが割当てられ得る。このように、クライアントアプリケーション２０４がアクセストークンをOAuth承認サーバ２２０に提示する場合は、OAuth承認サーバ２２０は、トークン−スコープレジストリ２２２を参照して、当該アクセストークンにマッピングされるスコープを判断してもよく、次にリソース＆スコープレジストリ２２４を参照して、当該スコープ内でアクセス可能なリソースを判断してもよい。

発明の実施形態では、OAuth承認サーバ２２０がクライアントアプリケーション２０４にアクセストークンを認めるには、リソース所有者２０２からのユーザ同意が要件とされる。たとえば、クライアントアプリケーション２０４がリソースサーバ２１０からの特定のリソース（または当該リソースを含む特定のスコープ）へのアクセスを要求すれば、リソースサーバ２１０は要求をOAuth承認サーバ２２０に転送し得る。OAuth承認サーバ２２０は、ユーザ同意オーケストレーション２２６を呼出して、クライアントアプリケーション２０４に特定のリソース（または特定のスコープ）へのアクセスが認められるべきであることを確認するようにリソース所有者２０２に頼んでもよい。実施形態では、ユーザ同意オーケストレーション２２６は、クライアントアプリケーション２０４がアクセスを求めているスコープをリソース所有者２０２に示し、当該スコープのアクセスに同意するまたはそれを断る機会をリソース所有者２０２に与える。より具体的には、OAuth承認サーバ２２０は、（リソース＆スコープレジストリ２２４中に示されるような）特定のリソースを含む特定のスコープによって特定されるアクセスがクライアントアプリケーション２０４に認められるべきであることを確認するようにリソース所有者２２０に頼んでもよい。リソース所有者２０２から同意を受信するのに応答して、OAuth承認サーバ２２０は、アクセストークンを生成し、トークン−スコープレジストリ２２２の中に当該アクセストークンと特定のスコープとの間のマッピングを格納し得る。OAuth承認サーバ２２０は、アクセストークンをクライアントアプリケーション２０４に与えることができる。

次にクライアントアプリケーション２０４は、アクセストークンをリソースサーバアプリケーション２１２に提示することによってリソースサーバ２１０上の特定のリソースへのアクセスを試みることができる。リソースアプリケーションサーバ２１２上のエージェントは、クライアントアプリケーション２０４が特定のリソースにアクセスできるようにする前に、トークンを横取りして、（たとえばアクセストークン有効化ＡＰＩ２１４を介して）OAuth承認サーバ２２０を用いてトークンを有効にすることができる。クライアントアプリケーション２０４がアクセスを試みる特定のリソースがトークン−スコープレジストリ２２２中のアクセストークンにマッピングされるスコープ内にない場合（たとえば、クライアントアプリケーション２０４が、リソース所有者２０２が以前に同意したアクセスのスコープ外にあるフォルダにアクセスしようとしている場合）、OAuth承認サーバ２２０はトークンを有効にせず、リソースサーバ２１０は、特定のリソースへのアクセスをクライアントアプリケーション２０４に認めるのを拒む。このように、アクセスのスコープは、リソース所有者２０２による当該スコープに対する特定的な同意に基づいている。リソース所有者２０２は、クライアントアプリケーション２０４が要求する特定的なスコープに対する同意を与えるのを拒む機会を有し、その場合、OAuth承認サーバ２２０はクライアントアプリケーション２０４向けのアクセストークンを作成しない。発明の１つの実施形態では、リソースサーバ２１０が維持するリソースにアクセスする各々のクライアントアプリケーションの要求は、リソース＆スコープレジストリ２２４中の、リソースサーバ２１０にマッピングされるスコープも特定し、以上で論じたように、リソース所有者２０２の同意が要求されるのはこの特定されたスコープである。

発明の実施形態に従うと、以上の検討と一貫して、クライアントアプリケーション２０４がリソースサーバ２１０にアクセストークンを提示したときにアクセス制限の実施が行なわれる。実施は、アクセストークンによってエンコードされるスコープの理解を要件とする。アクセストークンは、スコープの定義につき、OAuth承認サーバ２２０によって発行される。アクセストークンは、発行されたトークンによってエンコードされるスコープにつき、有効にされる。発明の１つの実施形態では、組合されたポリシーサービス２４０およびトークンサービス２５０は、発行されたアクセストークンの状態を維持し、発行されたアクセストークンを承認する。発明の実施形態では、カスタマー（すなわちリソースサーバ２１０の所有者および／またはオペレータ）はそれ自身のポリシーサービス２４０およびトークンサービス２５０を提供することができる。OAuthフレームワークはプログラム的コントラクトまたはプログラム的インターフェイスを提供してもよく、これにより、そのようなカスタマーは、自身のポリシーおよびトークンサービスを、当該カスタマーが規定するスコープに一致する態様でOAuthフレームワークにプラグインすることができる。各々のカスタマーはスコープのそれ自身のセットを公開してもよい。スコープの公開されたセットは、カスタマーのトークンサービスが戻るデータの形式を示し得る。加えて、OAuthフレームワークは、トークン発行の際にポリシーが作成されるのを許すプログラミングコントラクトまたはプログラム的インターフェイスをそのようなカスタマーに提供してもよい。これらのプログラム的コントラクトまたはプログラム的インターフェイスは、カスタマーが自身のカスタムプログラム的コードをOAuthフレームワークにプラグインできるようにする。これらのプログラム的インターフェイスを用いて、カスタマーは、その既存のインフラストラクチャをOAuthシステムに結線することができる。実施形態では、スコープの自身のセットを公開するカスタマーは、そのトークンおよび／またはポリシーサービスが、公開されたスコープと整合するスコープ情報を含むトークンを確実に戻すことを担う。クライアントアプリケーション２０４がトークンの使用を試みるのに応答して、OAuth承認サーバ２２０は、カスタマーのポリシーをルックアップし、当該トークンを有効にするアプリケーションプログラミングインターフェイス（ＡＰＩ）を呼出すことができる。

実施形態では、OAuthフレームワークは、OAuth承認サーバ２２０とインターフェイスするためにカスタマーのコード（たとえばトークンサービス２５０およびポリシーサービス２４０のためのコード）が実現しなければならないインターフェイスを特定する。インターフェイスは、カスタマーが各々のインターフェイスが受信することを予期するパラメータおよび各々のインターフェイスが戻すことを予期する値に気付くように公開され得る。クライアントアプリケーション２０４がOAuth承認サーバ２２０に要求を行なう場合、OAuth承認サーバ２２０は、当該要求に関するＡＰＩに応答通話を行なう。これらの通話は、たとえば、アクセストークンを生成し、それらのアクセストークンをクライアントアプリケーション２０４に与えるカスタマーコード化コンポーネントへの通話に係り得る。発明の１つの実施形態では、OAuth承認サーバ２２０は、ＯＰＳＳ−ＴＳ２２８およびＯＰＳＳ−ＡＺ２３０の形式の前述のプログラム的コントラクトまたはプログラム的インターフェイスを公開する。トークンサービス２５０のカスタマーの自身の実現例はＯＰＳＳ−ＴＳ２２８とインターフェイスすることができる一方で、ポリシーサービス２４０のカスタマーの自身の実現例はＯＰＳＳ−ＡＺ２３０とインターフェイスすることができる。OAuth承認サーバ２２０は、アクセストークン作成およびアクセストークン有効化のために別個のＡＰＩを呼出してもよい。カスタマーは、カスタムプログラム的コードを実現して各々のタスクを行なってもよい。有効化の間、リソースに対してクライアントアプリケーション２０４が行なうことを求める行為が、クライアントアプリケーション２０４が提示するアクセストークンによってエンコードされるポリシーに一致するか否かを判断するように、トークン作成の間に構築されるポリシーにアクセス可能である。

加えて、発明の１つの実施形態では、クライアントアプリケーション２０４がOAuth承認サーバ２２０からアクセストークンを求める場合に呼出されるユーザ同意オーケストレーション２２６のカスタマーの自身の実現例をOAuth承認サーバ２２０にプラグインすることができる。リソース＆スコープレジストリ２２４およびトークン−スコープレジストリ２２２へのインターフェイスは、カスタマーがユーザ同意オーケストレーション２２６のその実現例を設計して同意要求を構築する際に用いるようにコンポーネント２２２および２２４からデータを入手できるように、カスタマーに提供され得る。

発明の実施形態では、リソース＆スコープレジストリ２２４に格納されるマッピングは、各々のスコープ内に含まれるリソースのサブセットだけでなく、リソースのそれらのサブセットに対してクライアントアプリケーションが行なうことが許される動作の排他的サブセットも示す。たとえば、特定のマッピングは、特定のスコープについて、リソースサーバ２１０上に維持されるリソースの特定されたサブセット（たとえば、ファイル、フォルダ、ディレクトリ、一覧、プロファイル、画像、文書など）に対して作成または削除動作ではなく読出および更新動作を行なうことができると示し得る。このように、発明の１つの実施形態では、以上で論じた同意要求は、スコープと関連付けられるリソースのサブセットだけでなく、当該スコープと関連付けられる動作のサブセットも特定する。その結果、リソース所有者２０２は、クライアントアプリケーション２０４が同意−要求−特定されたスコープ内のリソースのサブセットに対して行なう同意を自身が与えている動作の種類を正確に知る。

発明の実施形態に従うと、クライアントアプリケーション２０４は、リソースサーバ２１０がOAuth承認サーバ２２０に登録した特定的なスコープのうち１つと均等のリソースアクセスを要求する。このように、発明の１つの実施形態では、クライアントアプリケーション２０４は、リソースサーバ２１０について登録される特定的なスコープを意識して設計される。クライアントアプリケーション２０４はさまざまな異なるリソースサーバが維持するリソースと対話し得るので、さまざまなリソースサーバのベンダーは、自身のリソースサーバがOAuth承認サーバ２２０に登録するスコープの標準的なセットについて同意し得、これにより、クライアントアプリケーション２０４および他のクライアントアプリケーションの設計者の設計業務が容易になる。

発明の１つの実施形態では、クライアントフレームワークは、クライアントアプリケーション２０４などのクライアントアプリケーションがさまざまな異なる種類のリソースプロバイダのための「フック」を実現できるように設けられる。たとえば、クライアントアプリケーション２０４は、Google、Facebook、Yahoo、LinkedInなどのための別個のフックを実現し得る。図３は、発明の実施形態に従うOAuthクライアント環境３００を図示するブロック図である。OAuthクライアント環境３００は、リソース所有者３０２、リソースサーバ３０４、OAuth承認サーバ３０６、クライアントアプリケーション３０８、およびOAuthクライアント３２０を含む。クライアントアプリケーション３０８はOAuthクライアントＡＰＩ３１０を含む。OAuthクライアント３２０は、OAuthクライアントエンジン３２２、リソースレジストリ３２４、ローカルアプリケーションレジストリ３２６、およびトークンレジストリ３２８を含む。リソースサーバ３０４およびOAuth承認サーバ３０６は互いと対話する。リソースサーバ３０４およびOAuthクライアント３２０は互いと対話する。OAuth承認サーバ３０６およびOAuthクライアント３２０は、リソース所有者３０２を介して（たとえば、リソース所有者３０２のインターネットブラウザによって達成される転送を通じて）互いと対話する。リソース所有者３０２はクライアントアプリケーション３０８とも対話する。クライアントアプリケーション３０８はOAuthクライアントＡＰＩ３１０を通してOAuthクライアントエンジン３２２と対話する。OAuthクライアントエンジン３２２は、リソースレジストリ３２４、ローカルアプリケーションレジストリ３２６、およびトークンレジストリ３２８と対話する。

発明の実施形態に従うと、クライアントアプリケーション３０８が対話し得る異なる種類のリソースサーバのすべてに関するメタデータがリソースレジストリ３２４内に格納されて、クライアントアプリケーション３０８がさまざまな異なるリソースサーバと対話できるようにする。リソースレジストリは、たとえば、各々の異なる種類のリソースサーバが認識するスコープの異なるセットを示すことができる。その結果、クライアントアプリケーション３０８は、リソースサーバ３０４が認識する特定のスコープに対応するアクセスを要求することができ、この特定のスコープは、OAuth承認サーバ３０６がクライアントアプリケーション３０８の代わりにリソース所有者３０２に送る同意要求の中に特定され得る。リソースプロバイダは、設計者が当該プロバイダのリソースサーバのための適切なサーバ−スコープマッピングをリソースレジストリ３０８に入れることができるように、それらのOAuth標準−準拠スコープの仕様を公開することができる。実施形態では、クライアントアプリケーション３０８とは独立してリソースレジストリ３０８に入れることができるので、クライアントアプリケーション３０８は新たに発見されたリソースサーバと対話するように改められる必要はない。代わりに、開発者は、クライアントアプリケーション３０８が対話するリソースレジストリ３２４の中にそれらのリソースサーバのための新しいマッピングを単に「プラグイン」することができる。

リソースプロバイダまたはサーバとして働く複合ウェブサイトは、一体化したアプリケーションではないことがしばしばである。代わりに、複合ウェブサイトはさまざまな異なるアプリケーションを構成することがしばしばである。発明の実施形態では、ローカルアプリケーションレジストリ３２６は、さまざまな異なるリソースプロバイダと当該リソースプロバイダが提供するまたは公開するアプリケーションのセットとの間のマッピングを格納する。各々のそのようなアプリケーションは、当該アプリケーションのための別個のユニフォームリソースロケータ（ＵＲＬ）へのローカルアプリケーションレジストリ３２６の中にマッピングされ得る。発明の１つの実施形態では、ローカルアプリケーションレジストリ３２６は信用キーを格納して、OAuthクライアントロールを行なって遠隔リソースにアクセスする。

典型的に、クライアントアプリケーション３０８は、特定のアクセストークンを、当該特定のアクセストークンが期限切れになる前に複数回用いて、リソースサーバ３０４が維持するリソースにアクセスすることができる。発明の実施形態では、クライアントアプリケーション３０８がOAuth承認サーバ３０６から入手するアクセストークンは、トークンレジストリ３２８内に格納される。クライアントアプリケーション３０８が複数の異なるリソースサーバと対話し得る限り、トークンレジストリ３２８は、アクセストークンと、当該アクセストークンが属する異なるリソースサーバとの間のマッピングを維持することができる。トークンレジストリ３２８は、さまざまな異なる遠隔リソースサーバ（たとえば、リソースサーバ３０４）のためのアクセストークンおよびリフレッシュトークンならびにスコープの両方を格納することができる。

図４は、発明の実施形態に従う、包括的OAuth承認サーバに第１のリソースサーバのメタデータを登録するための技術４００を図示するフロー図である。技術４００はあるブロックまたは動作に係るが、代替的な実施形態は図示されるよりも多くのまたはそれよりも少ないまたはそれとは異なる動作に係ってもよい。さらに、代替的な実施形態は、図示されたものとは異なる順序での動作の実行に係ってもよい。ブロック４０２で、OAuth承認サーバは、第１のリソースサーバから、第１のリソースサーバが認識するスコープの第１のセットを示すメタデータの第１のセットを受信する。ブロック４０４で、メタデータの第１のセットを受信するのに応答して、OAuth承認サーバは、スコープの第１のセット中のスコープと第１のリソースサーバが維持するリソースのサブセットとの間のマッピングを格納する。１つの実施形態では、メタデータの第１のセットを受信するのに応答して、OAuth承認サーバは、特定のスコープと、第１のリソースサーバが格納するリソースのサブセットと、特定のスコープにマッピングされる特定のトークンの保持者がリソースの第１のサブセット中のリソースに対して行なうことが許される動作のセットとの間のマッピングを格納する。

ブロック４０６で、OAuth承認サーバは、スコープの第１のセットから第１のスコープを特定する特定の要求を受信する。ブロック４０８で、第１のスコープを特定する要求を受信するのに応答して、OAuth承認サーバは、第１のスコープと整合するクライアントアプリケーションアクセスを認める同意を、第１のスコープ内に含まれるリソースの所有者に求める。ブロック４１０で、所有者から同意を受信するのに応答して、OAuth承認サーバは、（ａ）第１のアクセストークンを作成し、（ｂ）第１のアクセストークンと第１のスコープとの間のマッピングを格納し、かつ（ｃ）第１のアクセストークンをクライアントアプリケーションに送る。１つの実施形態では、所有者から同意を受信するのに応答して、OAuth承認サーバは、OAuth承認サーバを提供しないカスタマー（たとえば第１のリソースサーバの所有者）が提供するプログラム的コードを呼出す。プログラム的コードは、OAuth承認サーバのプロバイダがカスタマーに提供するインターフェイスを実現する。プログラム的コードは第１のアクセストークンを作成する。

ブロック４１２で、OAuth承認サーバは、第１のリソースサーバから、第１のアクセストークンを有効化する要求を受信する。ブロック４１４で、第１のアクセストークンを有効化する要求を受信するのに応答して、OAuth承認サーバは、第１のアクセストークンと第１のスコープとの間のマッピングに基づいて第１のアクセストークンを有効化する。１つの実施形態では、第１のアクセストークンを有効化するために、OAuth承認サーバは、OAuth承認サーバを提供しないカスタマー（たとえ、第１のリソースサーバの所有者）が提供するプログラム的コードを呼出す。このプログラム的コードは、OAuth承認サーバのプロバイダがカスタマーに提供するインターフェイスを実現する。プログラム的コードは第１のアクセス接続トークンを有効化する。

ブロック４１６で、第１のアクセストークンを有効化するのに応答して、OAuth承認サーバは、第１のリソースサーバに、第１のアクセストークンを第１のリソースサーバに提示したクライアントアプリケーションが、第１のリソースサーバによって維持されかつ第１のスコープによって特定されるリソースのセットに対して動作を行なうことを承認されると示す。

図５は、発明の実施形態に従う、包括的OAuth承認サーバに第２のリソースサーバのメタデータを登録するための技術を図示するフロー図である。技術５００はあるブロックまたは動作に係るが、代替的な実施形態は図示されるよりも多くのまたはより少ないまたはこれとは異なる動作に係ってもよい。さらに、代替的な実施形態は図示されるものとは異なる順序での動作の実行に係ってもよい。ブロック５０２で、OAuth承認サーバは、（図４で参照する）第１のリソースサーバとは別個の第２のリソースサーバから、第２のリソースサーバが認識するスコープの第２のセットを示すメタデータの第２のセットを受信する。スコープの第２のセットは（図４で参照する）スコープの第１のセットとは異なる。ブロック５０４で、メタデータの第２のセットを受信するのに応答して、OAuth承認サーバは、スコープの第２のセット中のスコープと第２のリソースサーバが維持するリソースのサブセットとの間のマッピングを格納する。ブロック５０６で、OAuth承認サーバは、第２のアクセストークンとスコープの第２のセットからの第２のスコープとの間のマッピングを格納する。ブロック５０８で、OAuth承認サーバは、第２のリソースサーバから、第２のアクセストークンを有効化する要求を受信する。ブロック５１０で、第２のアクセストークンを有効化する要求を受信するのに応答して、OAuth承認サーバは、第２のアクセストークンと第２のスコープとの間のマッピングに基づいて第２のアクセストークンを有効化する。ブロック５１２で、第２のアクセストークンを有効化するのに応答して、OAuth承認サーバは、第２のリソースサーバに、第２のアクセストークンを第２のリソースサーバに提示したクライアントアプリケーションが、第２のリソースサーバによって維持されかつ第２のスコープによって特定されるリソースのセットに対して動作を行なうのを承認されると示す。

図６は、本発明の実施形態に従って用いられ得るシステム環境６００のコンポーネントを図示する簡略ブロック図である。示されるように、システム環境６００は、ウェブブラウザ、独自クライアント（たとえばオラクルフォーム）などのクライアントアプリケーションを動作するように構成される１つ以上のクライアントコンピューティングデバイス６０２、６０４、６０６、６０８を含む。さまざまな実施形態では、クライアントコンピューティングデバイス６０２，６０４、６０６、および６０８はサーバ６１２と対話し得る。

クライアントコンピューティングデバイス６０２、６０４、６０６、６０８は、（一例として、マイクロソフトウインドウズ（登録商標）および／もしくはアップルマッキントッシュオペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／もしくはラップトップコンピュータを含む）汎用パーソナルコンピュータ、（マイクロソフトウインドウズ（登録商標）モバイルなどのソフトウェアを実行し、かつインターネット、電子メール、ＳＭＳ、ブラックベリー（登録商標）または他の通信プロトコル可能化である）携帯電話もしくはＰＤＡ、および／または（ＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムの種類を限定なく含む）さまざまな市販のＵＮＩＸ（登録商標）またはＵＮＩＸ状オペレーティングシステムの任意のものを実行するワークステーションコンピュータであり得る。代替的に、クライアントコンピューティングデバイス６０２、６０４、６０６、および６０８は、ネットワーク（たとえば以下に説明するネットワーク６１０）上で通信することができる、シンクライアントコンピュータ、インターネット可能化ゲームシステム、および／またはパーソナルメッセージングデバイスなどの任意の他の電子デバイスであり得る。４つのクライアントコンピューティングデバイスを有する例示的なシステム環境６００が示されるが、任意の数のクライアントコンピューティングデバイスをサポートしてもよい。センサを有するデバイスなどの他のデバイスがサーバ６１２と対応してもよい。

システム環境６００はネットワーク６１０を含み得る。ネットワーク６１０は、限定されることなくＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、アップルトークなどを含むさまざまな市販のプロトコルのうち任意のものを用いるデータ通信をサポートすることができる、当業者には馴染みのある任意の種類のネットワークであり得る。単に一例として、ネットワーク６１０は、イーサネット（登録商標）ネットワーク、トークンリングネットワークなどのローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク、限定されることなくバーチャルプライベートネットワーク（ＶＰＮ）を含む仮想ネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、ＩＥＥＥ８０２．１１プロトコル群、当該技術分野で公知のブルートゥース（登録商標）プロトコル、および／もしくは任意の他の無線プロトコルのうち任意のものに基づいて動作するネットワーク）、ならびに／またはこれらおよび／もしくは他のネットワークの任意の組合せであり得る。

システム環境６００は、汎用コンピュータ、（一例として、ＰＣサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）特化されたサーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な構成および／または組合せであり得る１つ以上のサーバコンピュータ６１２も含む。さまざまな実施形態では、サーバ６１２は、以上の開示に記載される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。たとえば、サーバ６１２は、本発明の実施形態に従ってリライングパーティおよびオープン承認処理を行なうためのサーバに対応し得る。

サーバ６１２は、以上で論じたもののうち任意のものを含むオペレーティングシステムおよび任意の市販のサーバオペレーティングシステムを実行し得る。サーバ６１２は、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、Ｊａｖａ（登録商標）サーバ、データベースサーバなどを含むさまざまな付加的なサーバアプリケーションおよび／または中間階層アプリケーションのうち任意のものも実行し得る。例示的なデータベースサーバは、限定されることなく、オラクル、マイクロソフト、Sybase、ＩＢＭなどから市販されているものを含む。

システム環境６００は、１つ以上のデータベース６１４、６１６も含み得る。データベース６１４、６１６はさまざまな場所に常駐し得る。一例として、データベース６１４、６１６のうち１つ以上はサーバ６１２にローカルの（および／またはその中に常駐する）非一時的記憶媒体上に常駐してもよい。これに代えて、データベース６１４、６１６はサーバ６１２から遠隔であってもよく、ネットワークに基づく接続または専用の接続を介してサーバ６１２と通信していてもよい。実施形態の１つの組では、データベース６１４、６１６は、当業者には馴染みのあるストレージエリアネットワーク（ＳＡＮ）中に常駐してもよい。同様に、サーバ６１２に帰する機能を行なうための任意の必要なファイルを適宜サーバ６１２上にローカルにおよび／または遠隔に格納してもよい。実施形態の１つの組では、データベース６１４、６１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納、更新、および検索するように適合される、オラクルが提供するデータベースなどのリレーショナルデータベースを含んでもよい。

図７は、本発明の実施形態に従って用いられ得るコンピュータシステム７００の簡略ブロック図である。たとえば、サーバ６０２は、システム７００などのシステムを用いて実現されてもよい。バス７２４を介して電気的に結合され得るハードウェア要素を備えるコンピュータシステム７００が示される。ハードウェア要素は、１つ以上の中央処理装置（ＣＰＵ）７０２、１つ以上の入力装置７０４（たとえば、マウス、キーボードなど）、および１つ以上の出力装置７０６（たとえば、ディスプレイ装置、プリンタなど）を含んでもよい。コンピュータシステム７００は１つ以上の記憶装置７０８も含んでもよい。一例として、記憶装置７０８は、ディスクドライブなどの装置、光学記憶装置、ならびにプログラム可能でフラッシュ更新可能などであり得るランダムアクセスメモリ（ＲＡＭ）および／または読出専用メモリ（ＲＯＭ）などの固体状態記憶装置を含んでもよい。

コンピュータシステム７００は、加えて、コンピュータ読出可能記憶媒体リーダ７１２、通信サブシステム７１４（たとえば、モデム、ネットワークカード（無線または有線）、赤外線通信デバイスなど）、ならびに上述のようなＲＡＭおよびＲＯＭデバイスを含み得るワーキングメモリ７１８を含んでもよい。いくつかの実施形態では、コンピュータシステム７００は、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサなどを含むことができる処理加速ユニット７１６も含んでもよい。

コンピュータ読出可能記憶媒体リーダ７１２は、遠隔、ローカル、固定、および／または取外し可能記憶装置プラス一時的におよび／またはより永続的にコンピュータ読出可能情報を内蔵するための記憶媒体を包括的に表わすコンピュータ読出可能記憶媒体７１０にともに（オプションで記憶装置７０８と組合せて）さらに接続可能である。通信システム７１４は、データがネットワーク１６１０および／またはシステム環境１６００に対して上述の任意の他のコンピュータと交換されるのを許し得る。

コンピュータシステム７００は、（クライアントアプリケーション、ウェブブラウザ、中間階層アプリケーション、ＲＤＢＭＳなどであり得る）アプリケーションプログラムなどのオペレーティングシステム７２０および／またはその他のコード７２２を含む、現在ワーキングメモリ７１８内に位置するものとして示されるソフトウェア要素も備えてもよい。例示的な実施形態では、ワーキングメモリ７１８は、上述のようなリライングパーティおよびオープン承認関連の処理のために用いられる実行可能なコードおよび関連のデータ構造を含んでもよい。コンピュータシステム７００の代替的な実施形態は上述されたものからの数多くの変形を有し得ることを認めるべきである。たとえば、カスタマイズされたハードウェアも用いてもよく、および／または特定の要素は、ハードウェア、（アプレットなどの可搬ソフトウェアを含む）ソフトウェア、またはその両方で実現されてもよい。さらに、ネットワーク入出力装置などの他のコンピューティングデバイスとの接続を用いてもよい。

コードまたはコードの部分を内蔵するための記憶媒体およびコンピュータ読出可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、データ信号、データ伝送、または所望の情報を記憶するもしくは伝送するのに用いることができ、コンピュータによってアクセス可能な任意の他の媒体を含む、コンピュータ読出可能命令、データ構造、プログラムモジュール、または他のデータなどの、情報の記憶および／または伝送のための任意の方法または技術において実現される、揮発性および不揮発性（非一時的）、取外し可能および取外し不可能媒体などの、しかしこれらに限定されない記憶媒体および通信媒体を含む、公知のまたは技術分野で用いられている任意の適切な媒体を含むことができる。

発明の具体的な実施形態を記載してきたが、さまざまな修正例、変更例、代替的な構成、および均等例も発明の範囲内に包含される。本発明の実施形態は、ある具体的なデータ処理環境内の動作に制限されず、複数のデータ処理環境内で自由に動作する。さらに、本発明の実施形態が特定の一連のトランザクションおよびステップを用いて説明されたが、当業者には、本発明の範囲が記載された一連のトランザクションおよびステップに限定されないことは明確であるはずである。

さらに、本発明の実施形態をハードウェアとソフトウェアとの特定の組合せを用いて説明したが、ハードウェアとソフトウェアとの他の組合せも本発明の範囲内であると認識されるべきである。本発明の実施形態は、ハードウェアのみにおいて、またはソフトウェアのみにおいて、またはその組合せを用いて実現されてもよい。

したがって、明細書および図面は制限的な意味というよりはむしろ例示的な意味でみなされるべきである。しかしながら、より広い精神および範囲から逸脱することなく、追加、削減、削除、ならびにさまざまな修正および変更がなされてもよいことが明らかであろう。

［付録］
背景
本発明の実施形態は、アイデンティティ管理、認証、および承認フレームワークに関する。

簡単な要約
本発明の実施形態は、アイデンティティ管理、認証、および承認フレームワークに関する。１つの埋込では、企業のアイデンティティおよびアクセス管理（ＩＡＭ）インフラストラクチャにおけるインターネットアイデンティティの統合のためにフレームワークが設けられる。別の実施形態に従うと、フレームワークはオープン承認のために設けられる。フレームワークはリライングパーティの機能性のためにも設けられる。

以上は、他の特徴および実施形態とともに、以下の明細書、請求項、および添付の図面を参照するとより明らかになるであろう。

図面の簡単な説明
この文書にいくつかの図面を含む。

付加的に、図１は、本発明の実施形態に従って用いられ得るシステム環境のコンポーネントを図示する簡略ブロック図である。

図２は、本発明の実施形態に従って用いられ得るコンピュータシステムの簡略ブロックである。

詳細な説明
以下の説明では、説明の目的のため、発明の実施形態の完全な理解を与えるための具体的な詳細を述べる。しかしながら、発明はこれらの具体的詳細がなくても実践され得ることが明らかであろう。

特徴：
（１） 既存の企業アイデンティティおよびアクセス管理（ＩＡＭ）インフラストラクチャにおけるインターネットアイデンティティの統合のためのリライングパーティプラットフォーム／フレームワーク
ビジネス、特にインターネット対応（internet facing）プロパティ（ウェブサイト、電子商取引アプリ、モバイルアプリなど）を用いるものは、より高い採用とより高い収入との達成に向けて自身のユーザ基盤を拡張しようとしている。「インターネットアイデンティティ」は、Facebook、Google、Yahooなどのような著名サイトで保持されるユーザアカウントである−これらは何千万ものユーザの掘出し物である。同時に、企業は、これらの変化する技術の統合ならびにインターネット対応配備の規模およびセキュリティの局面の両方の観点で、これらのアイデンティティを扱うよう備えていないＩＡＭシステムに対する既存の投資を有する。いくつかの先のソリューションは、企業に対してともに貼られる−カスタム／その場限りの／ピア−ピア（peer-peer）／ぴしゃりと貼られる／高価な−「バンドエイド」である。いくつかの製品はいくつかの統合ソリューションを与えるが、それらは製品に結び付きすぎている。全体的に、先のソリューションは変化するインターネット環境に対処することおよび既存のＩＡＭソリューションへの投資を保全することという課題の両方に取組むには、拡張性、スケーラビリティ、およびセキュリティを欠いている。

本発明の実施形態に従うと、フレームワークまたはプラットフォームは以下の特徴を備える。

・Google、Yahoo、FaceBook、LinkedIn、Twitterなどの周知のインターネットアイデンティティプロバイダ（ＩＤＰ）のための内蔵コネクタ。

・準拠ＩＤＰ（ＯｐｅｎＩＤ、OAuth（オープン承認）、セキュリティアクセスマークアップ言語（ＳＡＭＬ）など）と統合する、標準に基づくインターフェイス。

・（オラクル、ＣＡ、ＩＢＭ、その他などの）トップＩＡＭベンダーのための内蔵統合
・特定的な配備の必要性を満たすためにカスタマイズするための抽象ワークフロー／プロセスフローの上に層をなすプラグインポイントを介した拡張性。

例示的なワークフロープロセスフロー：
−ＩＤＰに対するユーザ認証は適切なレベルでのエンタープライズセッション作成に繋がる。

−プログレッシブ（progressive）ユーザ登録
−「ローカル」認証との統合を介したポリシーに基づく認証レベル向上。

実施形態は、フレームワークに関する特徴、ワークフロー／プロセスベースのプラグイン、ボーディングおよび認証に関するプログレッシブおよびオンデマンド／アプリケーション駆動ユーザなどを含むがこれらに限定されないいくつかの新規の特徴を提供する。

本発明の実施形態は、先の解決策に勝る大きな改良点を提供する。抽象ワークフロー／プロセスモデルは、ビジネスが製品の具体的詳細に対する技術的専門性よりもむしろビジネス使用事例を扱えるようにする。本発明の実施形態を、小規模（たとえば単純なＬＤＡＰ、ＪＳＥＳＳＩＯＮＩＤに基づく）から大規模ＩＡＭ配備にわたるさまざまなＩＡＭソリューションに関連して用いてもよい。

（２） OAuthフレームワーク
ビジネスは、競争力を保ちかつ成長するためには、インターネットを介していくつかのエンティティ（カスタマー、従業員、パートナー、クラウドサービスなど）と対話する必要がある。ソーシャルネットワーキングおよびユーザ中心アイデンティティにおける最近の進歩の結果、会社がともに、OAuthと呼ばれるオープン標準を創出してエンタープライズ間の安全なドメイン間通信を容易にするようになった。広くは、この基準は、１つのドメインから別のドメインへのサービスおよびリソースへの２地点間の安全なアクセスをカバーする。サービス／リソースは一般的に以下のカテゴリに入る。

−ユーザが管理するデータ−ユーザのカレンダー、写真、連絡先一覧など
−企業が管理するデータ−ＣＲＭ ＳａａＳサービス、顧客リスト、ユーザ管理サービス、ユーザ提供データ、ＳＬＡなど
これらのサービス／リソースは、社内またはクラウドにホスティングされてもよい。

OAuth２．０は、その単純さおよびインターネットスケーラビリティにより、データおよびリソースを広いインターネット上で共有するために、ここ二、三年で大きく人気を獲得した。

先の解決策は、典型的には移動体、ウェブブラウザ、ウェブサーバ、スタンドアロンアプリケーションなどのあらゆるクライアントフォームファクタ毎に異なる１つである、個々のリソース／サービス所有者によって提供される「ツールキット」に基づいている。問題は、OAuthが標準ではあるものの、これは「相互運用可能な」仕様ではないことである−そのため、各個々のツールキットは、それ自身の特定的な態様でプロトコルおよび対話を実現する。したがって、異なるクライアントフォームファクタにおいて、複数のパートナーとの統合を望むエンタープライズは、無数のツールキットを扱うという大きな困難を有する。また、よい実現例は、データセキュリティおよびその説明責任を確実にする（たとえば変化するビジネス関係に適合する）には、きめ細かくダイナミックなポリシーを扱える強固な承認モデルを必要とする。

いくつかの先の解決策は、既存のエンタープライズＩＡＭ配備とはうまく統合しない企業に対してともに貼られる−カスタム／その場限りの／ピア−ピア／ぴしゃりと貼られる／高価な−「バンドエイド」である。全体的に、先の解決策は異なるかつ変化し続けるインターネット環境に対処することおよび既存のＩＡＭソリューションへの投資を保全することという課題の両方に取組むには、拡張性、スケーラビリティ、およびセキュリティを欠いている。

本発明の実施形態は、以下の特徴を有するOAuthフレームワークまたはプラットフォームを提供する。

・Google Docs、Yahoo、Facebook、LinkedIn、Twitter、Salesforce.com、オラクルＯＤ、オラクルウェブセンターなどの周知のインターネットリソースおよび承認サーバのための内蔵コネクタ
・トップＩＡＭベンダー（オラクル、ＣＡ、ＩＢＭ、その他）のための内蔵統合。

・特定的な配備の必要性を満たすためにカスタマイズするための抽象ワークフロー／プロセスフローの上に層をなすプラグインポイントを介した拡張性。

１つの実施形態では、ワークフロープロセスは以下のように流れる。
−ユーザ認証はリソース／サービスアクセスのためのトークン発行に繋がる。

−遠隔のサービス／リソースへのアプリケーション駆動アクセス。
−パートナーエンティティへのローカルリソース／サービスのポリシーベースの公開。

−トークンライフサイクル−ユーザ駆動、管理者駆動、ポリシー駆動。
実施形態は、フレームワーク／プラットフォームに関する特徴、ワークフロー／プロセスベースのプラグイン、オンデマンド／アプリケーション駆動リソースアクセスなどを含むいくつかの新規の特徴を提供する。

本発明の実施形態は、先の解決策に勝る大きな改良点を提供する。抽象ワークフロー／プロセスモデルは、ビジネスが製品の具体的詳細に対する技術的専門性よりもむしろビジネス使用事例を扱えるようにする。発明の実施形態を、小規模（たとえば単純なＬＤＡＰ、ＪＳＥＳＳＩＯＮＩＤに基づく）から大規模ＩＡＭ配備にわたるさまざまなＩＡＭソリューションとともに用いてもよい。

さらなる詳細は、以下のセクション／パート（パート１から７）に記載される。以下のさまざまなパートはさまざまな実施形態を記載する。記載は、本質的に制限的であることまたは限定的であることを意図するものではない。

図１は、本発明の実施形態に従って用いられ得るシステム環境１００のコンポーネントを図示する簡略ブロック図である。示されるように、システム環境１００は、ウェブブラウザ、独自クライアント（たとえばオラクルフォーム）などのクライアントアプリケーションを動作するように構成される１つ以上のクライアントコンピューティングデバイス１０２、１０４、１０６、１０８を含む。さまざまな実施形態では、クライアントコンピューティングデバイス１０２，１０４、１０６、および１０８はサーバ１１２と対話し得る。

クライアントコンピューティングデバイス１０２、１０４、１０６、１０８は、（一例として、マイクロソフトウインドウズ（登録商標）および／もしくはアップルマッキントッシュオペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／もしくはラップトップコンピュータを含む）汎用パーソナルコンピュータ、（マイクロソフトウインドウズ（登録商標）モバイルなどのソフトウェアを実行し、かつインターネット、電子メール、ＳＭＳ、ブラックベリー（登録商標）または他の通信プロトコル可能化である）携帯電話もしくはＰＤＡ、および／または（ＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムの種類を限定なく含む）さまざまな市販のＵＮＩＸまたはＵＮＩＸ状のオペレーティングシステムの任意のものを実行するワークステーションコンピュータであり得る。代替的に、クライアントコンピューティングデバイス１０２、１０４、１０６、および１０８は、ネットワーク（たとえば以下に説明するネットワーク１１０）上で通信することができるシンクライアントコンピュータ、インターネット可能化ゲームシステム、および／またはパーソナルメッセージングデバイスなどの任意の他の電子デバイスであり得る。４つのクライアントコンピューティングデバイスを有する例示的なシステム環境１００が示されるが、任意の数のクライアントコンピューティングデバイスをサポートしてもよい。センサを有するデバイスなどの他のデバイスがサーバ１１２と対応してもよい。

システム環境１００はネットワーク１１０を含み得る。ネットワーク１１０は、限定されることなくＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、アップルトークなどを含むさまざまな市販のプロトコルのうち任意のものを用いるデータ通信をサポートすることができる、当業者には馴染みのある任意の種類のネットワークであり得る。単に一例として、ネットワーク１１０は、イーサネット（登録商標）ネットワーク、トークンリングネットワークなどのローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク、限定されることなくバーチャルプライベートネットワーク（ＶＰＮ）を含む仮想ネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、ＩＥＥＥ８０２．１１プロトコル群、当該技術分野で公知のブルートゥース（登録商標）プロトコル、および／もしくは任意の他の無線プロトコルのうち任意のものに基づいて動作するネットワーク）、ならびに／またはこれらおよび／もしくは他のネットワークの任意の組合せであり得る。

システム環境１００は、汎用コンピュータ、（一例として、ＰＣサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）特化されたサーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な構成および／または組合せであり得る１つ以上のサーバコンピュータ１１２も含む。さまざまな実施形態では、サーバ１１２は、以上の開示に記載される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。たとえば、サーバ１１２は、本発明の実施形態に従ってリライングパーティおよびオープン承認処理を行なうためのサーバに対応し得る。

サーバ１１２は、以上で論じたもののうち任意のものを含むオペレーティングシステムおよび任意の市販のサーバオペレーティングシステムを実行し得る。サーバ１１２は、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、Ｊａｖａ（登録商標）サーバ、データベースサーバなどを含むさまざまな付加的なサーバアプリケーションおよび／または中間階層アプリケーションのうち任意のものも実行し得る。例示的なデータベースサーバは、限定されることなく、オラクル、マイクロソフト、Sybase、ＩＢＭなどから市販されているものを含む。

システム環境１００は、１つ以上のデータベース１１４、１１６も含み得る。データベース１１４、１１６はさまざまな場所に常駐し得る。一例として、データベース１１４、１１６のうち１つ以上はサーバ１１２にローカルの（および／またはその中に常駐する）非一時的記憶媒体上に常駐してもよい。これに代えて、データベース１１４、１１６はサーバ１１２から遠隔であってもよく、ネットワークに基づく接続または専用の接続を介してサーバ１１２と通信していてもよい。実施形態の１つの組では、データベース１１４、１１６は、当業者には馴染みのあるストレージエリアネットワーク（ＳＡＮ）中に常駐してもよい。同様に、サーバ１１２に帰する機能を行なうための任意の必要なファイルを適宜サーバ１１２上にローカルにおよび／または遠隔に格納してもよい。実施形態の１つの組では、データベース１１４、１１６は、ＳＱＬフォーマットのコマンドに応答して、データを格納、更新、および検索するように適合される、オラクルが提供するデータベースなどのリレーショナルデータベースを含んでもよい。

図２は、本発明の実施形態に従って用いられ得るコンピュータシステム２００の簡略ブロック図である。たとえば、サーバ１０２は、システム２００などのシステムを用いて実現されてもよい。バス２２４を介して電気的に結合され得るハードウェア要素を備えるコンピュータシステム２００が示される。ハードウェア要素は、１つ以上の中央処理装置（ＣＰＵ）２０２、１つ以上の入力装置２０４（たとえば、マウス、キーボードなど）、および１つ以上の出力装置２０６（たとえば、ディスプレイ装置、プリンタなど）を含んでもよい。コンピュータシステム２００は１つ以上の記憶装置２０８も含んでもよい。一例として、記憶装置２０８は、ディスクドライブなどの装置、光学記憶装置、ならびにプログラム可能でフラッシュ更新可能などであり得るランダムアクセスメモリ（ＲＡＭ）および／または読出専用メモリ（ＲＯＭ）などの固体状態記憶装置を含んでもよい。

コンピュータシステム２００は、加えて、コンピュータ読出可能記憶媒体リーダ２１２、通信サブシステム２１４（たとえば、モデム、ネットワークカード（無線または有線）、赤外線通信デバイスなど）、ならびに上述のようなＲＡＭおよびＲＯＭデバイスを含み得るワーキングメモリ２１８を含んでもよい。いくつかの実施形態では、コンピュータシステム２００は、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサなどを含むことができる処理加速ユニット２１６も含んでもよい。

コンピュータ読出可能記憶媒体リーダ２１２は、遠隔、ローカル、固定、および／または取外し可能記憶装置プラス一時的におよび／またはより永続的にコンピュータ読出可能情報を内蔵する記憶媒体を包括的に表わすコンピュータ読出可能記憶媒体２１０にともに（オプションで記憶装置２０８と組合せて）さらに接続可能である。通信システム２１４は、データがネットワーク１６１０および／またはシステム環境１６００に対して上述の任意の他のコンピュータと交換されるようにし得る。

コンピュータシステム２００は、（クライアントアプリケーション、ウェブブラウザ、中間階層アプリケーション、ＲＤＢＭＳなどであり得る）アプリケーションプログラムなどのオペレーティングシステム２２０および／または他のコード２２２を含む、現在ワーキングメモリ２１８内に位置するものとして示されるソフトウェア要素も備えてもよい。例示的な実施形態では、ワーキングメモリ２１８は、上述のようなリライングパーティおよびオープン承認関連の処理のために用いられる実行可能なコードおよび関連のデータ構造を含んでもよい。コンピュータシステム２００の代替的な実施形態は上述されたものからの数多くの変形を有し得ることを認めるべきである。たとえば、カスタマイズされたハードウェアも用いてもよく、および／または特定の要素は、ハードウェア、（アプレットなどの可搬ソフトウェアを含む）ソフトウェア、またはその両方で実現されてもよい。さらに、ネットワーク入出力装置などの他のコンピューティングデバイスとの接続を用いてもよい。

コードまたはコードの部分を内蔵するための記憶媒体およびコンピュータ読出可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、データ信号、データ伝送、または所望の情報を記憶するもしくは伝送するのに用いることができ、コンピュータによってアクセス可能な任意の他の媒体を含む、コンピュータ読出可能命令、データ構造、プログラムモジュール、または他のデータなどの、情報の記憶および／または伝送のための任意の方法または技術において実現される、揮発性および不揮発性（非一時的）、取外し可能および取外し不可能媒体などの、しかしこれらに限定されない記憶媒体および通信媒体を含む、公知のまたは技術分野で用いられている任意の適切な媒体を含むことができる。

発明の具体的な実施形態を記載してきたが、さまざまな修正例、変更例、代替的な構成、および均等例も発明の範囲内に包含される。本発明の実施形態は、ある具体的なデータ処理環境内の動作に制限されず、複数のデータ処理環境内で自由に動作する。さらに、本発明の実施形態が特定の一連のトランザクションおよびステップを用いて説明されたが、当業者には、本発明の範囲が記載された一連のトランザクションおよびステップに限定されないことは明確であるはずである。

さらに、本発明の実施形態をハードウェアとソフトウェアとの特定の組合せを用いて説明したが、ハードウェアとソフトウェアとの他の組合せも本発明の範囲内であると認識されるべきである。本発明の実施形態は、ハードウェアのみにおいて、またはソフトウェアのみにおいて、またはその組合せを用いて実現されてもよい。

したがって、明細書および図面は制限的な意味というよりはむしろ例示的な意味でみなされるべきである。しかしながら、より広い精神および範囲から逸脱することなく、追加、削減、削除、ならびにさまざまな修正および変更がなされてもよいことが明らかであろう。

Claims (18)

1. 方法であって、
   OAuth承認サーバにおいて、第１のリソースサーバから、前記第１のリソースサーバが認識するスコープの第１のセットを示すメタデータの第１のセットを受信することと、
   前記メタデータの第１のセットを受信するのに応答して、前記OAuth承認サーバにおいて、前記スコープの第１のセット中のスコープと前記第１のリソースサーバが維持するリソースのサブセットとの間のマッピングを格納することと、
   前記OAuth承認サーバにおいて、第１のアクセストークンと前記スコープの第１のセットからの第１のスコープとの間のマッピングを格納することと、
   前記OAuth承認サーバにおいて、前記第１のリソースサーバから、前記第１のアクセストークンを有効化する要求を受信することと、
   前記第１のアクセストークンを有効化する前記要求を受信するのに応答して、前記OAuth承認サーバが、前記第１のアクセストークンと前記第１のスコープとの間の前記マッピングに基づいて前記第１のアクセストークンを有効化することと、
   前記第１のアクセストークンを有効化するのに応答して、前記OAuth承認サーバが、前記第１のリソースサーバに、前記第１のアクセストークンを前記第１のリソースサーバに提示したクライアントアプリケーションが、前記第１のリソースサーバによって維持されかつ前記第１のスコープによって特定されるリソースのセットに対する動作を行なうことを承認されると示すこととを備える、方法。
2. 前記OAuth承認サーバにおいて、前記第１のスコープを特定する特定の要求を受信することと、
   前記第１のスコープを特定する前記要求を受信するのに応答して、前記OAuth承認サーバが、前記第１のスコープと整合するクライアントアプリケーションアクセスを認める同意を、前記第１のスコープ内に含まれるリソースの所有者に求めることと、
   前記所有者から前記同意を受信するのに応答して、前記OAuth承認サーバが、（ａ）前記第１のアクセストークンを作成することと、（ｂ）前記第１のアクセストークンと前記第１のスコープとの間の前記マッピングを格納することと、（ｃ）前記第１のアクセストークンを前記クライアントアプリケーションに送ることとをさらに備える、請求項１に記載の方法。
3. 前記メタデータの第１のセットを受信するのに応答して、前記OAuth承認サーバにおいて、前記第１のスコープと、前記第１のリソースサーバによって格納されるリソースの第１のサブセットと、前記第１のスコープにマッピングされたトークンの保持者が前記リソースの第１のサブセット中のリソースに対して行なうことを許される動作の第１のセットとの間のマッピングを格納することをさらに備える、請求項１に記載の方法。
4. 前記第１のアクセストークンを有効化することは、前記OAuth承認サーバが、前記OAuth承認サーバを提供しないカスタマーによって提供されるプログラム的コードを呼出すことを備え、前記プログラム的コードは前記OAuth承認サーバのプロバイダが前記カスタマーに提供するインターフェイスを実現し、前記プログラム的コードは前記第１のアクセストークンを有効化する、請求項１に記載の方法。
5. 前記OAuth承認サーバにおいて、前記第１のスコープを特定する特定の要求を受信することと、
   前記第１のスコープを特定する前記要求を受信するのに応答して、前記OAuth承認サーバが、前記第１のスコープと整合するクライアントアプリケーションアクセスを認める同意を、前記第１のスコープ内に含まれるリソースの所有者に求めることと、
   前記所有者から前記同意を受信するのに応答して、前記OAuth承認サーバが、前記OAuth承認サーバを提供しないカスタマーによって提供されるプログラム的コードを呼出すこととをさらに備え、前記プログラム的コードは前記OAuth承認サーバのプロバイダが前記カスタマーに提供するインターフェイスを実現し、前記プログラム的コードは前記第１のアクセストークンを作成する、請求項１に記載の方法。
6. 前記OAuth承認サーバにおいて、前記第１のリソースサーバとは別個の第２のリソースサーバから、前記第２のリソースサーバが認識するスコープの第２のセットを示すメタデータの第２のセットを受信することをさらに備え、前記スコープの第２のセットは前記スコープの第１のセットとは異なり、さらに
   前記メタデータの第２のセットを受信するのに応答して、前記OAuth承認サーバにおいて、前記スコープの第２のセットの中のスコープと前記第２のリソースサーバが維持するリソースのサブセットとの間のマッピングを格納することと、
   前記OAuth承認サーバにおいて、第２のアクセストークンと前記スコープの第２のセットからの第２のスコープとの間のマッピングを格納することと、
   前記OAuth認証サーバにおいて、前記第２のリソースサーバから、前記第２のアクセストークンを有効化する要求を受信することと、
   前記第２のアクセストークンを有効化する前記要求を受信するのに応答して、前記OAuth承認サーバが、前記第２のアクセストークンと前記第２のスコープとの間の前記マッピングに基づいて前記第２のアクセストークンを有効化することと、
   前記第２のアクセストークンを有効化するのに応答して、前記OAuth承認サーバが、前記第２のリソースサーバに、前記第２のリソースサーバに前記第２のアクセストークンを提示したクライアントアプリケーションが、前記第２のリソースサーバによって維持されかつ前記第２のスコープによって特定されるリソースのセットに対する動作を行なうことを承認されると示すこととをさらに備える、請求項１に記載の方法。
7. １つ以上のプロセッサによって実行されると、当該１つ以上のプロセッサに、
   OAuth承認サーバにおいて、第１のリソースサーバから、前記第１のリソースサーバが認識するスコープの第１のセットを示すメタデータの第１のセットを受信することと、
   前記メタデータの第１のセットを受信するのに応答して、前記OAuth承認サーバにおいて、前記スコープの第１のセット中のスコープと前記第１のリソースサーバが維持するリソースのサブセットとの間のマッピングを格納することと、
   前記OAuth承認サーバにおいて、第１のアクセストークンと前記スコープの第１のセットからの第１のスコープとの間のマッピングを格納することと、
   前記OAuth承認サーバにおいて、前記第１のリソースサーバから、前記第１のアクセストークンを有効化する要求を受信することと、
   前記第１のアクセストークンを有効化する前記要求を受信するのに応答して、前記OAuth承認サーバが、前記第１のアクセストークンと前記第１のスコープとの間の前記マッピングに基づいて前記第１のアクセストークンを有効化することと、
   前記第１のアクセストークンを有効化するのに応答して、前記OAuth承認サーバが、前記第１のリソースサーバに、前記第１のアクセストークンを前記第１のリソースサーバに提示したクライアントアプリケーションが、前記第１のリソースサーバによって維持されかつ前記第１のスコープによって特定されるリソースのセットに対する動作を行なうことを承認されると示すことと、を行なわせる命令を備えるコンピュータ読出可能メモリ。
8. 前記命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサにさらに
   前記OAuth承認サーバにおいて、前記第１のスコープを特定する特定の要求を受信することと、
   前記第１のスコープを特定する前記要求を受信するのに応答して、前記OAuth承認サーバが、前記第１のスコープと整合するクライアントアプリケーションアクセスを認める同意を、前記第１のスコープ内に含まれるリソースの所有者に求めることと、
   前記所有者から前記同意を受信するのに応答して、前記OAuth承認サーバが、（ａ）前記第１のアクセストークンを作成することと、（ｂ）前記第１のアクセストークンと前記第１のスコープとの間の前記マッピングを格納することと、（ｃ）前記第１のアクセストークンを前記クライアントアプリケーションに送ることと、を行なわせる、請求項７に記載のコンピュータ読出可能メモリ。
9. 前記命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサにさらに
   前記メタデータの第１のセットを受信するのに応答して、前記OAuth承認サーバにおいて、前記第１のスコープと、前記第１のリソースサーバによって格納されるリソースの第１のサブセットと、前記第１のスコープにマッピングされたトークンの保持者が前記リソースの第１のサブセット中のリソースに対して行なうことを許される動作の第１のセットとの間のマッピングを格納することを行なわせる、請求項７に記載のコンピュータ読出可能メモリ。
10. 前記第１のアクセストークンを有効化することは、前記OAuth承認サーバが前記OAuth承認サーバを提供しないカスタマーによって提供されるプログラム的コードを呼出すことを備え、前記プログラム的コードは前記OAuth承認サーバのプロバイダが前記カスタマーに提供するインターフェイスを実現し、前記プログラム的コードは前記第１のアクセストークンを有効化する、請求項７に記載のコンピュータ読出可能メモリ。
11. 前記命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサにさらに
    前記OAuth承認サーバにおいて、前記第１のスコープを特定する特定の要求を受信することと、
    前記第１のスコープを特定する前記要求を受信するのに応答して、前記OAuth承認サーバが、前記第１のスコープと整合するクライアントアプリケーションアクセスを認める同意を、前記第１のスコープ内に含まれるリソースの所有者に求めることと、
    前記所有者から前記同意を受信するのに応答して、前記OAuth承認サーバが、前記OAuth承認サーバを提供しないカスタマーによって提供されるプログラム的コードを呼出すこととを行なわせ、前記プログラム的コードは前記OAuth承認サーバのプロバイダが前記カスタマーに提供するインターフェイスを実現し、前記プログラム的コードは前記第１のアクセストークンを作成する、請求項７に記載のコンピュータ読出可能メモリ。
12. 前記命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサにさらに
    前記OAuth承認サーバにおいて、前記第１のリソースサーバとは別個の第２のリソースサーバから、前記第２のリソースサーバが認識するスコープの第２のセットを示すメタデータの第２のセットを受信することを行なわせ、前記スコープの第２のセットは前記スコープの第１のセットとは異なり、さらに
    前記メタデータの第２のセットを受信するのに応答して、前記OAuth承認サーバにおいて、前記スコープの第２のセットの中のスコープと前記第２のリソースサーバが維持するリソースのサブセットとの間のマッピングを格納することと、
    前記OAuth承認サーバにおいて、第２のアクセストークンと前記スコープの第２のセットからの第２のスコープとの間のマッピングを格納することと、
    前記OAuth認証サーバにおいて、前記第２のリソースサーバから、前記第２のアクセストークンを有効化する要求を受信することと、
    前記第２のアクセストークンを有効化する前記要求を受信するのに応答して、前記OAuth承認サーバが、前記第２のアクセストークンと前記第２のスコープとの間の前記マッピングに基づいて前記第２のアクセストークンを有効化することと、
    前記第２のアクセストークンを有効化するのに応答して、前記OAuth承認サーバが、前記第２のリソースサーバに、前記第２のリソースサーバに前記第２のアクセストークンを提示したクライアントアプリケーションが、前記第２のリソースサーバによって維持されかつ前記第２のスコープによって特定されるリソースのセットに対する動作を行なうことを承認されると示すこととを行なわせる、請求項７に記載のコンピュータ読出可能メモリ。
13. OAuth承認サーバであって、
    第１のリソースサーバから、前記第１のリソースサーバが認識するスコープの第１のセットを示すメタデータの第１のセットを受信するように構成される１つ以上のハードウェアプロセッサと、
    前記メタデータの第１のセットを受信するのに応答して、前記スコープの第１のセット中のスコープと前記第１のリソースサーバが維持するリソースのサブセットとの間のマッピングを格納するように構成される１つ以上のハードウェアプロセッサと、
    第１のアクセストークンと前記スコープの第１のセットからの第１のスコープとの間のマッピングを格納するように構成される１つ以上のハードウェアプロセッサと、
    前記第１のリソースサーバから、前記第１のアクセストークンを有効化する要求を受信するように構成される１つ以上のハードウェアプロセッサと、
    前記第１のアクセストークンを有効化する前記要求を受信するのに応答して、前記第１のアクセストークンと前記第１のスコープとの間の前記マッピングに基づいて前記第１のアクセストークンを有効化するように構成される１つ以上のハードウェアプロセッサと、
    前記第１のアクセストークンを有効化するのに応答して、前記第１のリソースサーバに、前記第１のアクセストークンを前記第１のリソースサーバに提示したクライアントアプリケーションが、前記第１のリソースサーバによって維持されかつ前記第１のスコープによって特定されるリソースのセットに対する動作を行なうことを承認されると示すように構成される１つ以上のハードウェアプロセッサとを備える、OAuth承認サーバ。
14. 前記第１のスコープを特定する特定の要求を受信するように構成される１つ以上のハードウェアプロセッサと、
    前記第１のスコープを特定する前記要求を受信するのに応答して、前記第１のスコープと整合するクライアントアプリケーションアクセスを認める同意を、前記第１のスコープ内に含まれるリソースの所有者に求めるように構成される１つ以上のハードウェアプロセッサと、
    前記所有者から前記同意を受信するのに応答して、（ａ）前記第１のアクセストークンを作成し、（ｂ）前記第１のアクセストークンと前記第１のスコープとの間の前記マッピングを格納し、かつ（ｃ）前記第１のアクセストークンを前記クライアントアプリケーションに送るように構成される１つ以上のハードウェアプロセッサとをさらに備える、請求項１３に記載のOAuth承認サーバ。
15. 前記メタデータの第１のセットを受信するのに応答して、前記第１のスコープと、前記第１のリソースサーバによって格納されるリソースの第１のサブセットと、前記第１のスコープにマッピングされたトークンの保持者が前記リソースの第１のサブセット中のリソースに対して行なうことを許される動作の第１のセットとの間のマッピングを格納するように構成される１つ以上のハードウェアプロセッサをさらに備える、請求項１３に記載のOAuth承認サーバ。
16. １つ以上のハードウェアプロセッサは、前記OAuth承認サーバを提供しないカスタマーによって提供されるプログラム的コードを呼出すことによって、少なくとも部分的に、前記第１のアクセストークンを有効化するように構成され、前記プログラム的コードは前記OAuth承認サーバのプロバイダが前記カスタマーに提供するインターフェイスを実現し、前記プログラム的コードは前記第１のアクセストークンを有効化するように構成される、請求項１３に記載のOAuth承認サーバ。
17. 前記OAuth承認サーバにおいて、前記第１のスコープを特定する特定の要求を受信するように構成される１つ以上のハードウェアプロセッサと、
    前記第１のスコープを特定する前記要求を受信するのに応答して、前記第１のスコープと整合するクライアントアプリケーションアクセスを認める同意を、前記第１のスコープ内に含まれるリソースの所有者に求めるように構成される１つ以上のハードウェアプロセッサと、
    前記所有者から前記同意を受信するのに応答して、前記OAuth承認サーバを提供しないカスタマーによって提供されるプログラム的コードを呼出すように構成される１つ以上のハードウェアプロセッサとをさらに備え、前記プログラム的コードは前記OAuth承認サーバのプロバイダが前記カスタマーに提供するインターフェイスを実現し、前記プログラム的コードは前記第１のアクセストークンを作成するように構成される、請求項１３に記載のOAuth承認サーバ。
18. 前記第１のリソースサーバとは別個の第２のリソースサーバから、前記第２のリソースサーバが認識するスコープの第２のセットを示すメタデータの第２のセットを受信するように構成される１つ以上のハードウェアプロセッサをさらに備え、前記スコープの第２のセットは前記スコープの第１のセットとは異なり、さらに
    前記メタデータの第２のセットを受信するのに応答して、前記スコープの第２のセットの中のスコープと前記第２のリソースサーバが維持するリソースのサブセットとの間のマッピングを格納するように構成される１つ以上のハードウェアプロセッサと、
    第２のアクセストークンと前記スコープの第２のセットからの第２のスコープとの間のマッピングを格納するように構成される１つ以上のハードウェアプロセッサと、
    前記第２のリソースサーバから、前記第２のアクセストークンを有効化する要求を受信するように構成される１つ以上のハードウェアプロセッサと、
    前記第２のアクセストークンを有効化する前記要求を受信するのに応答して、前記第２のアクセストークンと前記第２のスコープとの間の前記マッピングに基づいて前記第２のアクセストークンを有効化するように構成される１つ以上のハードウェアプロセッサと、
    前記第２のアクセストークンを有効化するのに応答して、前記第２のリソースサーバに、前記第２のリソースサーバに前記第２のアクセストークンを提示したクライアントアプリケーションが、前記第２のリソースサーバによって維持されかつ前記第２のスコープによって特定されるリソースのセットに対する動作を行なうことを承認されると示すように構成される１つ以上のハードウェアプロセッサとをさらに備える、請求項１３に記載のOAuth承認サーバ。