JP6170158B2 - モバイルマルチシングルサインオン認証 - Google Patents

Description

関連出願へのクロスリファレンス
本願は、２０１２年９月１９日に出願された米国仮出願 ６１／７０３，０４５ 優先権を主張するものであり、その全体を参照することにより本願に含まれる。

スマートフォン、タブレット及びノートブックのようなモバイル装置は、そのモバイル装置及び／又はそのモバイル装置上で実行されるオペレーティングシステムのために特別に書かれた固有のアプリケーションを、しばしば備える。固有のアプリケーションが、インターネットのようなネットワーク上で他のコンピュータ装置と通信することはよくあることである。ここで、他のコンピューティング装置は、モバイル装置の固有のアプリケーションにコンテンツ又はサービスを配布する。モバイル装置上で実行される、ネットワークで結ばれた固有のアプリケーションは、クライアントアプリと呼ばれ、クライアントアプリと通信中のコンピューティング装置はサーバと呼ばれる。

サーバは、クライアントアプリ又はクライアントアプリのユーザを、必ずしも信用しているわけではない。多くの場合、クライアントアプリとサーバ間の実質的な通信が始まる前に、サーバは、クライアントアプリを認証し許可する。例えば、ユーザが銀行口座にアクセスすることを可能にするクライアントアプリは、銀行サーバと通信する。銀行口座にアクセスすることは、慎重に扱うべきであり、銀行口座の所有者のみに限定されるべきであるので、サーバは、モバイル装置、クライアントアプリ、及び／又はクライアントアプリのユーザに、自身であることを確認し認証する。

ユーザは、同じ企業に承認される複数のクライアントアプリを持っていることがある。個々のクライアントアプリそれぞれは、１回の使用期間に同じ信用証明を用いて複数回認証させることをユーザに強制することがある。このように、認証と許可の冗長性を引き起こす。

複数のクライアントアプリは、同じモバイル装置上でしばしば存在する。モバイル装置のプラットフォームの制限は、クライアントアプリ間のプロセス間通信をしばしば妨げる。この制限は、関連したネットワーク資源にアクセスするときに、多重の冗長な認証や、ログオフ要求を引き起こす。例えば、ユーザは、モバイル装置上に、ユーザが企業のＨＲシステムにアクセスするためのクライアントアプリを持っており、企業の顧客関係管理（ＣＲＭ）システムを管理するためのもう１つのクライアントアプリを持っていることがある。ユーザは、彼のモバイル装置で、企業のＨＲサーバへの認証を要求するＨＲアプリを最初に実行することを選ぶ。その後、ユーザは、彼のモバイル装置で、同じ企業のワイド身分証明を使用する認証を再度要求するＣＲＭシステムにアクセスすることを選ぶ。すなわち、ユーザ及び／又はモバイル装置は、同一の又は関連する身分証明を使用する複数のコンピューティングサービスにアクセスする比較的短い時間の間、何度も認証することを強制される。ユーザがバンキングアプリをログオフしたとき、同じ信用証明に依存する双方のアプリにもかかわらずインベストメントアプリはログイン状態のままであることがある。この意図しない結果は、ユーザが彼又彼女は特定の信用証明を使用するすべてのアプリケーションをログアウトとしたと信じてしまうが、実際には１つ以上の他のアプリケーションにログイン状態であるという安全性リスクを引き起こす。

ここに記載されたシステム、方法及び装置の実施形態は、先行技術における問題を克服し、企業で使用されるモバイルアプリケーションへのシングルサインオンシステムの管理を可能にする。

いくつかの実施形態は、モバイル装置上で実行される第１のモバイルアプリケーションに関連した第１のユニフォームリソースロケータ（ＵＲＬ）にアクセスするための第１のリクエストを、モバイル装置上の独立したブラウザから受け取ることを含む。次に、１つの装置は、独立したブラウザからユーザに関連した第１の認証情報を受取り、身分証明データベースの第１の認証情報と照合することにより、少なくとも部分的にモバイル装置と相互作用してユーザを認証する。そして、認証装置は、独立したブラウザに、ブラウザベースのトークンとユーザに関連する第１のクライアントアプリケーション身分証明とを送る。さらに、認証装置は、モバイル装置上で実行される第２のモバイルアプリケーションに関連した第２のユニフォームリソースロケータ（ＵＲＬ）にアクセスするための第２のリクエストを、モバイル装置上の独立したブラウザから受け取る。ここで、第２のリクエストは、ブラウザベースのトークンを備える。装置は、身分証明データベースで、ブラウザベースのトークンの非取消しを照合し、独立したブラウザに、ユーザに関連する第２のクライアントアプリケーション身分証明を最後に送る。

実施形態のこれら及び他の特徴と利点は、以下の実施形態の記載から明らかとなる。この概要、以下の詳細な記載のどちらも本発明を限定するものではない。

図面全体にわたって、符号は、参照要素間の一致を示すために、再使用される。図面は、ここに記載された例示である実施形態を説明するために提供されるものであり、開示の範囲を限定するものではない。
複数のクライアントアプリを有する複数のクライアント装置、複数のサービスとサーバ及び認証機構を含むネットワークを示すブロックダイヤグラムである。 身分証明、認証及び許可のために使用される、モバイルクライアント装置、クライアントアプリ及びサーバ間の、プロセス、通信及びデータフローを示すブロックダイヤグラムである。 第２の認証及び許可のために使用される、モバイルクライアント装置、クライアントアプリ及びサーバ間の、プロセス、通信及びデータフローを示すブロックダイヤグラムである。 認証及び許可のために使用される、モバイルクライアント装置、第２のクライアントアプリ及びサーバ間の、プロセス、通信及びデータフローを示すブロックダイヤグラムである。 第２の認証及び許可のために使用される、モバイルクライアント装置、第２のクライアントアプリ及びサーバ間の、プロセス、通信及びデータフローを示すブロックダイヤグラムである。 認証及び許可プロセスを支援するモバイル装置上でブラウザ及びクライアントアプリによって記憶されるデータの１つの実施形態を示す。 制限されたサーバに第１のクライアントアプリがアクセスするのを認証するモバイル装置のためのプロセスを示す。 制限されたサーバに第２のクライアントアプリがアクセスするのを認証するモバイル装置のためのプロセスを示す。 制限されたサーバへのアクセスからログアウトするモバイル装置のためのプロセスを示すフローダイヤグラムである。 制限されたサーバへのアクセスからログアウトするモバイル装置のためのプロセスを示すフローダイヤグラムである。 制限されたサーバへのアクセスから１つ以上のアプリケーションをログアウトするモバイル装置のためのプロセスを示すフローダイヤグラムである。 複数のアプリケーションをログアウトするモバイル装置のためのプロセスを示すフローダイヤグラムである。 複数のアプリケーションをログアウトするモバイル装置のためのプロセスを示すフローダイヤグラムである。

モバイルシングルサインオン（Ｍｏｂｉｌｅ Ｓｉｎｇｌｅ−Ｓｉｇｎ−Ｏｎ）（モバイルＳＳＯ）概論
本開示は、固有のモバイル装置アプリケーションに対するシングルサインオン認証提供についてむけられたものである。特に、本開示は、モバイル装置上で動作するブラウザとの相互作用を通して、そして、ブラウザによって記憶されるパーシステント的なトークン又は信用証明の使用を通して、モバイルアプリケーションが認証するシングルサインオンプロセスに関連する。例えば、１つの実施形態において、アップル（登録商標）のｉ‐ＯＳ（登録商標）、グーグル（登録商標）のアンドロイド（登録商標）、ウィンドウズ（登録商標）ＲＴのようなスマートフォンのオペレーティングシステム上で動作するアプリケーションは、ＯＳ固有の独立したブラウザ（例えば、Ｓａｆａｒｉ（登録商標）、Ｃｈｒｏｍｅ（登録商標）、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）又はユーザによってダウンロードされインストールされた、特定の目的のために設計されたモバイルアプリケーションから分離しているウェブブラウザ等）を、認証を実行するため使用する。ウェブを活用した統合ウェブブラウザや単一の身分証明に対する認証と許可を実行する非ウェブのシングルサインオン技術を伴わない、固有のモバイルアプリケーション（「クライアントアプリ」）を本開示は示す。

伝統的なシングルサインオン技術を活用する、モバイルアプリケーションは、認証を実行するため独立したブラウザと相互作用をするように修正される必要がある。例えば、アプリケーション開発者（または、他の者）は、彼のモバイルアプリケーションに、ウェブブラウザとの相互作用を操作する認証モジュールを挿入する。認証モジュールは、コンパイルされ実行されるときにウェブブラウザに特定のＵＲＬのアクセスするよう指示し、及び／又は、認証が完了後に、直接又は間接に、ウェブブラウザからデータを受取るコードの断片を備えることができる。

固有のクライアントアプリが、サーバによって提供されるようなネットワークベースのアプリケーション資源にアクセスを試みたとき、クライアントアプリは、ユーザ又はモバイル装置の認証を実施する必要がある。要求される認証プロセスを実行するために、又は、いかなる認証が要求されているかを究明するために、クライアントアプリは、認証モジュールを起動する。認証モジュールは、認証モジュールがアクセスするためのクライアントアプリの身分証明がすでに記憶されているかを究明する。もし、いかなるクライアントアプリの身分証明も見つからなければ、認証モジュールは、モバイル装置のユーザに対する認証を実行するためにモバイル装置の固有の独立ブラウザを開く。認証モジュールは、認証に基づくウェブに対応するＵＲＬに固有のブラウザを誘導する。

例えば、ブラウザは、ウェブ認証サーバ又は認証装置と呼ばれる装置のＵＲＬに誘導されてもよい。認証サーバ／装置は、特定の企業によって、そのユーザを認証するために運営される。例えば、アドビ（登録商標）のＩＴ部門は従業員の、ユーザネーム、パスワード、又はここで記述されたその他の身分証明情報等の認証信用証明を照合するために、アドビ（登録商標）の全従業員用認証サーバを運用しているであろう。もう１つの方法として、認証サーバは、企業のユーザ、又は、企業の又は第三者のサービスに対するユーザ会員登録を認証するために、第三者により運営される。認証サーバ／装置は、例えば、コンピュータやモバイル装置上の制限されたローカル機能／アプリケーションや、ウェブサービス、ｅｍａｉｌ、カレンダー操作等ネットワークベースのアプリケーション等のような、認証を要求するアプリケーションの照合のための認証サービスを提供する。

そのようなサーバは、サーバにユーザ又はモバイル装置の信用証明を送信するブラウザを起動する。認証サーバはマイクロソフト（登録商標）のＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙのような身分証明データベースにアクセスすることにより信用証明を照合する。ユーザが認証した時点で、ウェブ認証サーバは、ブラウザによって使用され記憶されることを意図したトークンをブラウザ経由でモバイル装置に返送信する。

トークンは、モバイル装置上のブラウザにより記憶されたブラウザクッキーや、固有キー記憶部やその他のファイルレポジトリーに記憶されたＸ．５０９ｖ３証明書等のような、ブラウザに送られたパーシステントトークン（ｐｅｒｓｉｓｔｅｎｔ ｔｏｋｅｎ）又は信用証明である。パーシステントトークンは、他のデータに混じって、ユーザのアイデンティティ（ｉｄｅｎｔｉｔｙ）、ユーザが加入した企業の識別子、信用証明の配信時間、信用証明の満了時間を含む。このアイデンティティトークンは、ユーザ又はモバイル装置による以前の認証を照合するため認証サーバに提示することができる。パーシステントトークンに関連するセッショントークンは、同様に、ブラウザに記憶される（例えば、ＨＴＭＬ４クッキー及び／又はＨＴＭＬ５セッションオブジェクトを使用することにより）。セッショントークンは、パーシステントトークンが、最近、発行されたか又は照合されたかを示すため、認証装置により発行される。セッショントークンは、シングルサインオン セッションがアクティブで他のモバイルアプリが認証なして通過できることを検証するための再認証（又はパーシステントトークンの照合）を回避するため、ブラウザによって認証装置に提示される。

もう１つのアイデンティティトークンは、暗号化された又は暗号化されていないＵＲＬストリング、及び／又は（クッキー又は暗号化されたクッキーを含む）ブラウザヘッダー、又はユーザを識別する他のデータであるクライアントアプリのアイデンティティであり、クライアントアプリに送信される、そのようなクライアントアプリのアイデンティティは、ユーザのアイデンティティと、いくつかの実施形態においては、そのアイデンティティの認証を詳報するための署名を備える。このクライアントアプリのアイデンティティに基づいて、クライアントアプリケーション又はネットワークベースのアプリケーションは、クライアントアプリのユーザが企業データの記憶部又は他の業務用又は非業務用の資源に基づく許可を経由して提供されるサーバにアクセスする。

クライアントアプリは、認証装置上で機能するウェブサーバから送られるときに、ブラウザから直接に、このアイデンティティを受取る。もしブラウザがクライアントプリにデータを戻すことができないときは、又はアイデンティティが暗号化されているときは、クライアントアプリの認証モジュールは、指示されたウェブサーバコール経由で認証装置から直接にクライアントアプリのアイデンティティを受取る。

もし、しばらく経ってクライアントアプリが、将来、同じサーバ又はサービスへのアクセスを要求したときは、クライアントアプリは、ローカルモバイル装置、企業、又はアイデンティティを信託するクラウドアプリケーションサーバにアクセスするブラウザ又は認証サーバを使用せずに内在のクライアントアプリのアイデンティティを使用する。

いくつかの実施形態において、クライアントアプリは、クライアントアプリがアイデンティティの使用を要求するたびに、ブラウザベースのユーザ検証を要求するように構成される。このタイプの実施形態においては、クライアントアプリは、アイデンティティが照合され、ユーザは正しい許可グループにいて、及び、関連するブラウザアクセス可能なパーシステント的なトークンは取消されていないと推定されることができる。ここで、取り消されるのは、紛失／盗難のモバイル装置又はユーザ信用証明が取消された他の理由（アイデンティティが終了した等）のためである。トラッキングリボケーション（Ｔｒａｃｋｉｎｇ ｒｅｖｏｃａｔｉｏｎ）は、有効トークンのリストを記憶する認証装置を含み、又は、（全体として、このアプリケーションの中に完全に合体された、米国特許出願１２／４１９，９５１に記載された方法のような）管理用に修正された取消し回数を特定する企業データストア(ｄａｔａｓｔｏｒｅ)を使用するタイムベースのスタンプ方法を起動する。

同じモバイル装置内の第２のクライアントアプリは、特定の身分に基づくローカル又はネットワークベースのアプリケーションサービスへのアクセスを、同様に試みる。上述のクライアントアプリのように、第２のクライアントアプリは、ユーザを認証することが必要となるネットワークサービスへのアクセスを試みたとき、認証モジュールを起動する。認証モジュールは、アクセスするサービスに使用される、記憶されたクライアントアプリの身分が、第２のクライアントアプリ内に存在するかどうかを究明する。もし、クライアントアプリの身分が見つからなければ、第１のクライアントアプリに関連する認証モジュールは、モバイル装置を使用するユーザのための認証を実行するためモバイル装置固有のブラウザを開く。認証モジュールは、認証をベースにしたウェブに関連するＵＲＬに固有のブラウザを誘導する。

第１のクライアントアプリが認証のためにブラウザを使用したとき、ブラウザは、認証に関連するパーシステント的なトークンとセッションと薫を記憶する。いくつかの実施形態において、パーシステントトークンは、１つのブラウザセッション又は他の短期間の間に有効なだけの、セッショントークンとみなせる。ブラウザは、後で、パーシステント的又はセッショントークンを第２のクライアントアプリにより特定されるＵＲＬに送る。そのＵＲＬに対応する認証サーバは、パーシステント的トークン又はセッショントークンを調査し、照合するそして、もし、満たせば、付加的な認証の実行はしない。ユーザ認証情報の代わりに、パーシステント的／セッショントークンを受け入れる技術は、（２の）固有なモバイルアプリケーション間でのシングルサインオン（ＳＳＯ）を提供する効果を有する。ユーザは、どちらか一方のアプリと相互作用することにより、１回で効果的に認証することができ両方のアプリケーションに適用できる認証を持つことができる。また、満たさないときは、認証サーバは、再認証、又は、元の認証に使用されるものとは異なるタイプの付加的認証を要求する。

一旦、満たせば、認証サーバは、（第２のクライアントアプリが適合しているようにみえる限りにおいて）第２のクライアントアプリによる使用のためクライアントアプリの身分（例えばユーザｉｄ又はユーザｉｄとドメインのペア）を生成してアプリのブラウザを経由してその身分を送る。第２のクライアントアプリは、上述のように、ブラウザから又は認証装置から直接にクライアントアプリのアイデンティティのトークンを受取る。それから、第２のクライアントアプリは、ユーザの身分証明のため、及び、選択したときはパーシステント的なアクセスのため、このアイデンティティを利用する。

認証装置は、モバイルアプリケーションに対する記憶されたクライアントアプリＩＤのテーブルを使用することにより、クライアントアプリのアイデンティティを生成する。ここで、認証された信用証明は「キーバリュー（ｋｅｙ ｖａｌｕｅ）」(例えば、ｊｄｏｅ)として使用される。テーブル内検索により、クライアントアプリＩＤは、キーバリューに基づき戻されることがある。例えば、特定のアプリケーションに対するクライアントアプリＩＤは、キーバリュー、又は、キーバリューのプログラム的な変形（ｊｄｏｅ＠ｇｍａｉｌ．ｃｏｍ）、又は、キーバリューに関連し、特定のクライアントアプリに送るときに使用されるために記憶された全く新しい属性（ｊｄｏｅ−ｃａ−３１１３２）を有する。クライアントアプリＩＤのフォーマットと値は、モバイルアプリケーションが使用を期待するような種類のＩＤであることに依存して、アプリケーションごとに変化することがある。

さらに、１度ログインして、ユーザは第１のクライアントアプリ経由でログアウトする。ユーザがログアウトすると、アプリケーションは、特定のログアウトＵＲＬにおいて認証装置にアクセスするようブラウザに指示する。ログアウトＵＲＬは、認証装置にパーシステント的な及び／又はセッショントークンを有効なパーシステント的トークンのセットから取り除き、ブラウザにセッション及び／又はパーシステント的なトークンの削除を指示するトリガとなる。いくつかの実施形態において、その後、ブラウザは第２のクライアントアプリを起動して、例えば、ＵＲＬマッピングを用いて、第２のアプリケーションから同じユーザがログアウトする指示を渡す。そして、第２のアプリケーションは、１つ以上の付加的なアプリケーションを起動して、直接又はブラウザを通して、それらのアプリケーションに対して同様のログアウトプロシジャーを起動する。

したがって、上述のように、モバイル装置に対する認証プロセス、システム、方法におけるシングルサインオンが開示される。例えば、ユーザは、スマートフォン上のモバイルアップリケーションとインタラクトしている間、独立ブラウザを経由して、企業の認証装置に対して第１に認証することができる。スマートフォン上の第２のアプリケーションは、認証のために独立ブラウザを使うよう構成される。しかし、ユーザは、最初に独立ブラウザを使って、すでに、最初に認証しているので、第２のモバイルアプリケーションが、認証装置に関連するＵＲＬに、独立ブラウザを誘導させたとき、パーシステント性のトークン又はセッショントークンは読みとり可能であり、クライアントアプリのアイデンティティは、ユーザからのいかなる相互作用もなしに自動的に発行される。すなわち、この開示に基づき、ユーザは１度「サインオン」して、追加のユーザの介在なしに、複数のモバイルアップリケーションにわたって、「シングル」サインオンを適用できる。さらに、モバイルアプリのシングルサインオンのプロセスは、認証を実行するため独立ブラウザを使用するので、開示されたシングルサインオンのプロセスは、独立ブラウザを警手してアクセスされるウェブサーバ及びサービスに対してのシングルサインオンにも適用できる。

本開示に記載された実施形態の態様は、説明の目的のために、モバイル装置とクライアントアプリと認証サーバとネットワークサービスとの間の関係と相互作用に焦点を当てるけれども、当業者は、ここに開示した技術は、いろいろなハードウェア、ソフトウェアプロセス、アプリケーションに適用できることを理解するであろう。例えば、本開示は、主としてスマートフォンの状況に焦点を当てるけれども、開示したプロセスは、タブレットや電子リーダー等のようなモバイル装置の他のタイプにも使用される。さらに、本開示の様々な態様は、説明に役立つ例や実施形態に関して記載されているので、当業者は、開示された実施形態や例は限定を構成するものではないことを理解するであろう。開示の様々な実施形態は、特定の例や実施形態に関して記載されるが、それらは説明を意図するものであり本開示を限定するものではない。

さらに、企業が作った、認証サーバ、システム及び方法と相互作用するよう設計されたアプリは、事前定義されたＵＲＬマッピングを有する、第三者の固有モバイルアプリと互換可能である。システムと方法は、ここで記載したシングルサインオン ログオンとログオフの両方にこれらのアプリケーションを結びつけることができる。
動作環境

図１は、複数のクライアントアプリを有する複数のクライアント装置、複数のサービスとサーバ及び認証機構を含む簡単なコンピュータネットワークを示している。

クライアントアプリは、コンピュータとネットワーク環境の複合において動作する。クライアントアプリ１１１ａ〜１１１ｎ及び１１２ａ〜１１２ｎは、モバイル装置、典型的にはスマートフォン上で実行するために書かれたソフトウェアアプリケーションである。クライアントアプリは、固有のアーキテクチャーとオペレーティングシステム上において機能する、通常、ソフトウェアである。例えば、アップル（登録商標）のｉＯＳ（登録商標）オペレーティングシステム向けに設計され、オブジェクティブＣで書かれたたアプリケーションは、グーグル（登録商標） アンドロイド（登録商標） フォンでは機能しない。クライアントアプリは、クラウド配布チャンネルを使ってモバイル装置にダウンロード又はインストールされる。例えば、アップル（登録商標）のｉＰｈｏｎｅ（登録商標）製品は、ｉＴｕｎｅ（登録商標）サービスからｉＯＳ（登録商標）クライアントアプリをダウンロードでき、アンドロイド（登録商標） フォンはＧｏｏｇｌｅ Ｐｌａｙ（登録商標）からアンドロイド（登録商標） クライアントアプリをダウンロードすることができる。

ｉＰｈｏｎｅ（登録商標）やアンドロイド（登録商標）デバイスのようなスマートフォン等のモバイル装置は、固有のウェブブラウザ１１３ａ〜１１３ｎがプリインストールされる。そのようなブラウザは、ユーザが様々なＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ（ＵＲＬｓ）にアクセスすること許可する。これらのウェブブラウザは、ＨＴＴＰ及びＨＴＴＰＳ通信を送受信し、ジャバやジャバスクリプト等のクライアント側で管理されるコードを実行し、様々な受信したデータを表現するような通常のウェブブラウザの機能のほとんどを有する。モバイルブラウザは、スタンダードＨＴＭＬ４ ブラウザクッキースペース、ＨＴＭＬ５ローカルストレージを含むＨＴＭＬ５ストレージスペース、ＨＴＭＬセッションストレージ、ＨＴＭＬ５グローバルストレージ、ＨＴＭＬ ＳＱＬライトストレージ、アドビ フラッシュ（登録商標） スペース、アンドロイド（登録商標） ダルビック ストレージスペース、Ｊ２ＭＥ ｍａｎａｇｅｄ コード スペース、マイクロソフト（登録商標）ＮＥＴ コード スペース、及びＮａｔｉｖｅ Ｘ．５０９ｖ３ サーティフィケート ストレージスペースとＳＤＲＯＭファイルスペースとを含む様々なデータストアに、受信した情報を記憶する。

クライアントアプリは、同様に、(図示せぬ)統合ブラウザの能力を持つことができる。しかし、いくつかの統合ブラウザはモバイル装置の固有のブラウザ１１３ａ〜１１３ｎ又は他の統合ブラウザによってアクセス可能なデータストアにアクセスできないことがある。これらのケースでは、もし、モバイル装置上のクライアントアプリの統合ウェブブラウザが、サービスやサーバへ認証するのに使用されるときは、同じ装置上の他のクライアントアプリは、その認証情報にアクセスできないかもしれない。これは、同じ装置上の他のクライアントアプリ又はユーザが、ネットワークサービスのアクセスを開始するたびに、それらの装置に再認証しなければならない原因となる。信用証明をタイプまたは入力することは難しく、ユーザが彼らのモバイル装置上で頻繁に再認証しなければならないということは、ユーザの時間を浪費する。したがって、シングルサインオンの利点と効用は、外部テータストアへのアクセスを制限されている統合されたブラウザと認証情報を交換するときに限定される。

モバイル装置１１０ａ〜１１０ｎは、ワイヤレスネットワーキングを介して、グローバルインターネットに、通常接続される。典型的なネットワーク接続には、８０２．１１ Ｗｉ−Ｆｉコネクション又は、ＧＳＭ（登録商標）、ＥＤＧＥ、ＵＭＴＳ、ＷＣＤＭ、ＥＶ−ＤＯ、ＬＴＥ等のような３Ｇ又は４Ｇセルラー通信技術を含む。このような接続は、モバイル装置、ブラウザ及びクライアントアプリが、インターネット１０１のような、ＴＣＰ／ＩＰネットワーク又は他のＯＳＩレイヤ３ ネットワーク上の資源と通信することを許可する。接続可能な資源は、例として、企業サービス１０３ａ〜１０３ｎ、第３者により提供される（Ｇｏｏｇｌｅ（登録商標） アプリのような）ネットワークサービス１０５ａ〜１０５ｎ、そして、そのような資源として認証サービスを提供する認証サーバ又は装置を含む。

認証装置１０２は、法人又は組織的企業いずれかのネットワーク、又は（図示せぬ）企業に拡がるクラウド等に存在するサーバ又は複数のサーバである。それは、認証、ログイン許可又は秘密のサービスとしても、時々知られている。このような装置は、ユーザ及び／又は装置が、企業のサービスサーバ１０３ａ〜１０３ｎにより提供されるようなネットワークサービスへのアクセスの獲得を事前に認証することを許可する。認証装置は、装置から受信した信用証明を照合するため、及び／又は、ユーザ又は装置に関連する任意の認証又は許可を検査するため、アイデンティティデータベース１０４ｎにアクセスする。そのようなアイデンティティデータベース１０４ｎは、例えば、ＳＱＬデータベース、マイクロソフト（登録商標） アクティブディレクトリサーバ、ＬＤＡＰディレクトリ、ケルベロス（Ｋｅｒｂｅｒｏｓ）サーバ、証明サーバ、ＲＡＤＩＵＳサーバ、又は業務用又はクラウド上にあり（例えば、ときとして第三者により、現場から離れて設けられた）、ユーザの信用証明及び／又はプロファイルを記憶又は認証する任意の他のデータベースである。認証プロセスが実行された後、認証装置はアイデンティティ／トークンを、将来の使用のため、装置上の記憶部に送ることができる。これらのアイデンティティ／トークンは、ローカルノ又はネットワークベースのアップリケーションサービスへのアクセスを獲得するため認証装置又は他のサーバに提示される。アイデンティティ／トークンは、固有のモバイルアプリのシングルサインオン（ＳＳＯ）に対して、固有のモバイルアプリを支援するＳＳＯ識別子として使用できる。同様に、独立ブラウザは認証後に戻されるアイデンティティ／トークンを受取るとともにそれらへのアクセスを有するので、アイデンティティ／トークンは、ウェブアプリのシングルサインオン（ＳＳＯ）に対して、固有のモバイルアプリを支援するＳＳＯ識別子として使用できる。

アプリケーションレイヤで企業サーバ１０３ａ〜１０３ｎとして規定されている企業サーバは、ＴＣＰ／ＩＰ４ ネットワーキング又はＯＳＩレイヤ ネットワーキングを通して、クライアントアプリに、企業データベースとウェブサービス情報へのアクセスを提供する。このようなサービスの例としては、カレンダリング、ｅｍａｉｌ、ドキュメント管理、ファイルサービス、又は、クライアント／サーバ アーキテクチャを使った任意の他のアプリケーションが含まれる。企業サービスは、同じ企業に関連するクライアントアプリからの認証されたアイデンティティを、通常、受理する。例えば、もし、Ｃｏｍｐａｎｙ．ｃｏｍが、顧客と従業員のためのネットワークベースのアプリケーションサービスを提供するために企業サービスサーバ１０３ａ〜１０３ｎを使用したときは、Ｃｏｍｐａｎｙ．ｃｏｍの従業員 Ｊｏｈｎ Ｓｍｉｔｈは企業認証装置１０２から認証信用証明を得るために、アイデンティティデータベース１０４ｎに記憶された彼のユーザプロファイルを使用できる。ユーザのモバイル装置上のクライアントアプリが、典型的には記憶可能なトークン又はアイデンティティの形式で、これらの信用証明を得た後に、その信用証明は、所望のサービスを提供する企業サーバ、例えば１０３ａに提供される。企業サーバは、例えば、信用証明の署名の確認や企業アイデンティティデータベース１０４ａに対する提供された信用証明をチェックによって、その信用証明を照合する。また、企業は、企業のアイデンティティデータベース１０４ｎ、アプリケーションデータベース１０４ａ、又は、例えばローカルメモリ等の他のストレージデバイスを、ユーザを許可するために使用できる。可されると、ユーザの装置は企業のサーバサービスへのアクセスを開始できる。

同様に、第三者は、モバイル装置上で動作するクライアントアプリに対して、ネットワークベースのアプリケーションサービスを例供する。例えば、第三者のサービスプロバイダのサーバ１０５ａ〜１０５ｎは、信頼関係に基づく企業の信用証明も同様に受け入れる。認証装置１０２から特定の企業にために得られた信用証明は、もし、第三者のサービスプロバイダがその企業からの照合されたその信用証明を信頼しているときは、サービスプロバイダサーバ１０２ａでのサービスにアクセスするために使用できる。同様に、第三者の企業は、信頼された企業の信用証明に関連するユーザの付加的な許可のために様々なデータストアを使用できる。例えば、データベース１０６ａは、ユーザが特定のサービスを使用する許可がされているかどうか又はそのサービスの特徴を決定するために、信頼された企業からのユーザに関する認証情報を記憶できる。同様に、これ以外の実施形態でも、サービスプロバイダが、この情報を決定するためにデータベース１０４ａに直接アクセスすることができる。
認証モジュール

クライアントアプリは、認証モジュールを介して認証及び許可プロセスと相互作用する。認証モジュールはハードウェア、ソフトウェア、又はこれら２つの等価な結合として実装されている。いくつかの実施形態において、認証モジュールはクライアントアプリに統合されたソフトウェアである。例えば、それは、使用される固有のオブジェクティブＣコード、又は内部に存在する、ｉＯＳ（登録商標）アプリ、又は、アンドロイド（登録商標）アプリのためのジャバ（登録商標）コード、又は、ウィンドウズモバイル（登録商標）アプリのためのＮＥＴコード等で構成される。また、認証モジュールは、統合ブラウザ、又は、クライアントアプリ又はモバイル装置の他のネットワーキング機能を介して、ダウンロードされる管理コードで構成される。

認証モジュールは、ブラウザが認証ウェブサイトにアクセスするのを指示するために使用される、認証ユニフォームリソースロケータ（ＵＲＬ）を記憶する。いくつかの実施形態において、記憶されたＵＲＬはクライアントアプリのダウンロードとインストールの前に、管理者によって設定可能であるか、典型的なクライアントアプリ又はモバイル装置のコンフィギュレーション インターフェイスを通してインストール後に設定される。さらに、分かれて記憶されたＵＲＬは、固有のアプリと通信するためのネットワークを介して、使用される認証ＵＲＬを受信することにより遠隔設定することも可能である。認証モジュールは、複数の記憶されたＵＲＬを持つことがある。異なるＵＲＬは、アクセスされるネットワークベースのアプリケーション資源又はユーザログインのための特性（例えば特定のユーザネーム、ドメイン、その他の属性）に基づいて使用される。

認証モジュールは、他のものの中から、記憶された認証の信用証明を探し、記憶された認証ＵＲＬにブラウザを誘導させ、認証装置へのブラウザを介して認証用信用証明を通信し、ブラウザを介して認証装置からクライアントアプリのアイデンティティを受信する。このリストは完全ではない。これ以外の認証モジュールの動作は例として以下で記載される。
クライアントアプリ認証例

図２は、クライアントアプリ１１１ａが企業１０３ａによって提供される所望のサーバへの認証とアクセスを得ることを許可するための、クライアントアプリと認証装置１０２とデータベースアイデンティティ１０４ａとの間の相互作用を例示する。描かれている装置間の相互作用は、図１に描かれているような、ネットワークを介しての相互作用に置き換えることができる。

クライアントアプリ１１１ａがモバイル装置１１０ａにダウンロードされインストールされた後、クライアントアプリ１１１ａは起動される。直ちに又は符号化されたトリガの後に、クライアントアプリは、企業サーバ１０３ａにより提供されるネットワークベースのアプリケーションにアクセスしなければならないことを見つける。アプリケーションは、クライアントアプリにより獲得された認証信用証明を受け入れるように構成された、第三者のサーバ又は何か他のサービス（又はローカルプロセス又は保護された機能）にアクセスすることを択一的に決定する。クライアントアプリが制限されたネットワークサーバのアクセスを準備するとき、認証モジュールが使用される。

サーバにアクセスする前に、認証モジュールは、アクセスするためにサーバに示す認証信用証明を獲得する。このような信用証明は、図６で示されるように、クライアントアプリのアイデンティティ６０７の形式とできる。このようなクライアントアプリのアイデンティティ６０７は、特定のサーバが要求する何か他の属性（名称、ｅｍａｉｌ、認証機関、グループ、許可情報等）に加えて、例えば、ユーザネーム、及び／又は、会社／企業名等のような、サーバに対してユーザを特定するユーザのアイデンティティ情報を、しばしば備える。また、クライアントアプリのアイデンティティは暗号署名を含むことがある。当業者によく知られているように、ＰＫＩのような公開／秘密キー暗号を使用することにより、認証装置は、クライアントアプリのアイデンティティを発行するものであったことを、ほぼ保証できる。これは、クライアントアプリによって提供されるクライアントアプリのアイデンティティが認証装置によって発行されたものであることを、サーバに信用させることができる。この署名は厳密には必要ではなく、クライアントアプリの信用は、サーバによるアイデンティティプロバイダデータベース１０４ｎの検索をするデータベースのような他のやり方や、クライアントアプリのアイデンティティをさらに照合する技術として知られている他の方法によっても達成される。クライアントアプリのアイデンティティは、例えば、普通の文字列の又は暗号化されたユーザｉｄ、ユーザｉｄとドメイン／組織（例えばｊｏｈｎｄｏｅ＠ｃａｍｐａｎｙ.ｃｏｍ）、ＳＡＭＬ形式のアイデンティティアサーション（ａｓｓｅｒｔｉｏｎ）、ＯｐｅｎＩＤ、ＯｐｅｎＩＤ コンテント、認証に基づく形式、軽量な第三者の認証、暗号化されたＵＲＬ、暗号化されたＨＴＴＰヘッダー、又はアイデンティティ形式に基づくいずれかの他のブラウザ等からなる。上述のように、クライアントのアイデンティティは、テーブルを用いる装置により決定され、アプリケーションごとに変化することもある。

図２に示すように、認証モジュール及び／又はクライアントアプリは、以前記憶されたクライアントアプリのアイデンティティを探す。よく知られた探索技術が、基準の多様性に基づくアイデンティティを見つけるために使用される。アイデンティティは、メモリに直接か、リレーショナルデータベースのようなより複雑なデータ構造の中に記憶される。探索は、クライアントアプリに使用することができる何らかのアイデンティティが記憶された既知のメモリの場所にアクセスするか、又は、いくつかある特徴の中で、特定のユーザ、信用証明及び／又はアクセスされるネットワークベースのアプリケーション資源を基本とするデータベースを探索するような複雑なアクセスが行われる。図５に示す第２のクライアントアプリ１１２ａのために、図２のクライアントアプリ１１１ａを含む、すでに記憶されたクライアントアプリのアイデンティティを有するいずれかのクライアントアプリは、ネットワークベースのアプリケーションサーバにアクセスするため、そのクライアントアプリのアイデンティティを使用する。また、ネットワークベースのアプリケーションにアクセスする前に、そのクライアントアプリのアイデンティティは、ＳＡＭＬ アサーション（ａｓｓｅｒｔｉｏｎ）のような、さらなる信用証明を得るために使用される。そのクライアントアプリ又はさらなる信用証明がネットワークベースのアプリケーションサーバに受け入れられると、クライアントアプリは、ネットワークベースのアプリケーションサーバとセッションを開始して、図２に示したような認証プロセスを起動することなく、その資源にアクセスする。

もし認証モジュールが見つけられたクライアントアプリのアイデンティティを使用する代わりに認証プロセスを開始したときは、認証モジュールは、モバイル装置固有の、独立ブラウザか統合クライアントアプリブラウザのいずれかを起動する。認証モジュールは、そのブラウザを、認証装置１０２のＵＲＬに対応する特定の記憶されたＵＲＬに誘導する。ブラウザは、その記憶されたはＵＲＬへの、ＨＴＴＰ又はＨＴＴＰＳ（又は他の特定プロトコル）の要求を生成する。そのような要求の１部分としてのパーシステントトークン（又は会員セッショントークン）６０５が、もしブラウザによって、すでに記憶されアクセス可能となっているときは、そのトークンは、加盟しているＵＲＬ又はＵＲＬドメインに送られる。例えば、ＨＴＭＬ４ クッキー又はＨＴＭＬ５ オブジェクトの形式のパーシステントトークンは、ＵＲＬがそのクッキーのドメインとパスにマッチしているときは、そのＵＲＬに送られる。トークンがすでに存在しているときは、それは分離したクライアントモバイルアプリ又は同様の固有のブラウザアプリによって起動された認証からのものかも知れない。例えば、固有の独立ブラウザは、ウェブサービスにアクセスする１部分として、すでに認証装置１０２により認証され、モバイルアプリケーション／クライアントアプリとの相互作用なしにパーシステント又はセッショントークンを受取る。例えば、いくつかの実施形態では、ユーザが以前に認証に成功したことを示し、ブラウザアクセス可能なパーシステント又はセッショントークンが有効なときは、パーシステント又はセッショントークンを有効にして、シングルサインオン（ＳＳＯ）を用いてユーザに複数のウェブサーバ及び／又はモバイルアプリにアクセスするのを可能にする。

パーシステントトークンは、上述のクッキーの形式でも、証明やその他のアイデンティティと信用を表示するものの形式でもよい。いくつかの実施形態において、セッショントークンはパーシステントトークンに関連付けられ、ログオンセッションのパーシステントのためパーシステントトークンの代わりに使用される。例えば、（以下で述べるように）パーシステントトークンが発行されると、ＨＴＭＬ４ クッキー及び／又はＨＴＭＬ５ オブジェクトのようなセッショントークンは認証装置により生成されパーシステントトークンと先般の認証に関連付けられる。

セッショントークンとは異なって、パーシステントトークンは、ブラウザセッション間にわたりパーシステントする。例えば、パーシステントトークンは３月の間、有効で、その間、様々なブラウザを起動する。パーシステントトークンは、ブラウザセッションが起動されるたびにユーザの再認証に代えて使用される。パーシステントトークンが照合された後、セッショントークン（例えば、ある一時的な単一の識別子）は、ユーザが先般認証され及び／又は有効なパーシステントトーク鵜を有していることを示すためのセッションの間、使用するために認証装置により発行される。技術的にそれらが認識されるように、他の実施形態においては、セッショントークンが使用されず、パーシステントトークンが、全ての用途でのセッショントークンとしての役割を果たす。パーシステントトークンについての更なる情報は、以下に述べる。

一旦、ＵＲＬがアクセスされると、サーバは、受理したパーシステントトークン（又は関連するセッショントークン）に対する要求を解析する。パーシステントトークン（又は関連するセッショントークン）が見つかれば、認証装置１０２は図３に示すトークン照合プロシージャを実行する。

しかし、パーシステントトークンが見つからないと、認証装置１０２は、ブラウザベー所の認証を実行するためブラウザと通信する。そのような認証ワークフローの１つの例は、ユーザに対するユーザｉｄとパスワードのような認証情報をブラウザ１１３ａから受信して、ユーザｉｄとパスワードとの組み合わせを、企業のアイデンティティデータベース１０４ｎと照合するものである。このブラウザと認証装置との間のやり取りは、ＨＴＴＰＳ プロトコル上で使用されるＳＳＬ／ＴＬＳチャンネル等の秘密のチャンネル上で行われる。他の認証機構の例として、ＡＡＡフィーチャ（ｆｅａｔｕｒｅｓ）、認証情報及びワークフローが、参照することにより開示に含まれるとなる、出願番号 １１／７０２，３７１、１２／０７５，２１９、１２/２６，００２、１２／３９２，７６０、１２／４１９，９５１、１２／９４８，０３７、及び１３／０３５，２８９に対応する米国公開特許に示されている。認証プロセスの１部分として集められた認証情報は、ユーザ、モバイル装置１１０ａ、ブラウザを管理するクライアントアプリ１１１ａ、クライアントアプリがアクセスを試みるサーバ／サービス１０３ｎ、及び認証を助けるためのユーザ又はモバイル装置にのみ知られ得るいすずれかの情報を、表すデータ含み、かつ、それらに限定されない。

ユーザネーム（ユーザｉｄとして知られている）とパスワードとのタイプの認証に加えて、付加的又は択一的な認証機構が、秘密性を強化するため認証装置で使用される。本発明のもう１つの形態によれば、第２のアイデンティティ信用証明が、パスワードに追加して要求される。ユーザ認証に対する帯域外の秘密トークンを送信するため、ネットワーク１０１とそれに関連した通信とから分離した帯域外の通信チャンネルを使用する第２の認証システムがある。これは、ショートメッセージサービス（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）（ＳＭＳ）又は電話ネットワーク上の音声メッセージ経由で送信されるワンタイムパスワードが含まれる。一般的なワンタイムパスワードは照合のため認証装置１０２と通信される。

ワンタイムパスワードのような時間制限を受けるトークンを使用する代わりに、検証のためのさらなる基盤として要求されるユーザ特定の情報の他のタイプがある。１つは、パスワードとは異なる静的な個人識別番号（ＰＩＮ）である。もう１つは、ユーザの最初の自動車の名前、ユーザの高校のマスコットの名前等のような、理論的には、ユーザやさもなければ大変親しい仲間しか知らないような答を基礎とする知識を求める質問に基づく情報である。さらに、クライアントアプリ１１１ａの記憶されたデジタル信用証明や、モバイル装置に取り付けられるＵＳＢキーが、第２のアイデンティティ信用証明として提供される。要求され照合される様々なアイデンティティの信用証明には、Ｘ．５０９ｖ３ 信用証明、ワンタイムパスワードを送信するＳＭＳ、ワンタイムパスワードを送信する電話通信、静的ＰＩＮ，ワンタイムパスワードを送信するｅｍａｉｌ、ＹｕｂｉｋｅｙのようなＵＳＢトークン、ＲＦＩＤやＮＦＣのような近接型カード、いずれかの知識に基づく質問又は答等が含まれるが、これらに限定されるものではない。

一旦、この認証情報が集められると、認証装置１０２は、ユーザ又はモバイル装置のアイデンティティを照合するため、様々な企業アイデンティティデータベースを使う。アイデンティティデータベース１０４ｎ等には、例えば、ＳＱＬデータベース、マイクロソフト アクティブ ディレクトリ サーバ、ＬＤＡＰ ディレクトリ、オラクル ＯＤＢＣ サーバ、ＲＡＤＩＵＳ サーバ、又はいずれかの他のサイト又はクラウドデータベースであって、ユーザの信用証明又はプロファイルを記憶したものを含む。これらのディレクトリ又は認証サービスのそれぞれは、認証されているユーザ又はモバイル装置１１０ａについての情報を記憶する。これらのデータベースの多くは、認証プロトコルもサポートする。

認証装置に渡されるデータを介してのユーザの照合のための１つの方法は、ユーザのデータベースへの登録を検索するものであり、ユーザが提出した情報とデータベースの中にある情報とを比較するものである。もし、提出された情報とだーたベースの存在する情報とが、同一か又は比較パラメータの選択の範囲内であれば、ユーザは、主張した本人であるみなされ、照合されたとみなされる。このケースで、図２の4「アイデンティティ照合」と「アイデンティティ結果の戻り」のステップは、データベース内の特定のユーザ又はモバイル装置１１０ａを探し、完全なユーザ登録又はユーザやモバイル装置の特定の属性等の、ユーザ又はモバイル装置１１０ａについての情報をデータベースから受取り、受取ったデータを提出された情報と比較する。このようなデータベースとの相互作用は、ＳＳＩ／ ＴＬＳ等の秘密チャンネルやいずれか他の秘密機構上でされる。比較により、ユーザ又はモバイル装置１１０ａが提出した情報が、ユーザ又はモバイル装置１１０ａしか知らないものであることが示されれば、ユーザ又はモバイル装置は、照合したものとみなされ、認証される。

ユーザを認証する他の方法は、データベースと認証の交換をすることである。例えば、マイクロソフトのアクティブ ディレクトリを含むＬＤＰＡ ディレクトリは、ユーザパスワードと人用照明を照合する多様な認証機構をサポートする。認証交換の１つの例として、ＬＤＡＰ結合（ｂｉｎｄ）や、公開／秘密キー交換がある。この方法は、データベースに特定の認証情報を送信する必要がない。代わりに、当業者に知られた技術であるので、これらの方法は、ユーザ又はモバイル装置１１０ａが正しい認証情報を提出したかどうかを決定するために、暗号、ノンス（ｎｏｎｃｅｓ）、ハッシュを使用する。

認証プロセスが実行された後、認証装置は、ユーザ及び／又はクライアントアプリに、企業サービスサーバ１０３ｎ、又は、企業サービスサーバ上で提供される特定のサービス又は機能の使用を許可する。例えば、クライアントアプリにより要求される特定のサーバ、サービス又は機能に対する認証は、ユーザに対応する特定の属性を検知することにより許可されるように構成される。データ自体のいずれかの比較を実行することに代えて、認証装置は、特定のユーザ又はモバイル装置１１０ａが、クライアントアプリ１１１ａにより要求されているアクセスを備えているかどうかを、異なるサーバ又はアイデンティティデータベース以外のデータベースから要求する。さらに、図４について言及する他の箇所で述べているように、認証装置はブラウザベースのパーシステントトークンを受け入れて、アイデンティティに対するトークンがすでに認証装置によって認証されたことを理解し、認証装置１０２又はアイデンティティデータベース１０４ｎにより特定されている強化された又はより強い認証を、トリガとする規定又は設定をチェックする。これは、認証装置によって供給されたブラウザベースのパーシステントトークンにより提供されたシングルサインオン（ＳＳＯ）機能のおかげで、ユーザは複数回のアイデンティティ入力をしなくてもよいという利点がある。

認証プロセスの成功後、認証装置１０２は２つのトークンを生成する。ブラウザアクセス可能トークン（パーシステントトークン又はセッショントークンに基づくトークン、又はパーシステントトークンとセッショントークンの２つに基づくトークン）６０５とクライアントアプリのアイデンティティ６０７（図６）である。

パーシステントブラウザアクセス可能トークンは、ユーザとモバイル装置のブラウザ１１３ａにより過去のログイン実行を有効にするために使用された認証情報とを記憶したブラウザに渡されるデータ構造を有する。図６に示すように、パーシステントブラウザアクセス可能トークン６０５は、ユーザのアイデンティティ（例えば、ユーザネーム、ＩＤ番号、ｅｍａｉｌアドレス等）、ユーザが加入した企業（例えば、ｇｏｏｇｌｅ．ｃｏｍ、ｉｂｍ．ｃｏｍ等）、トークンが生成された又は配送された時間、及びトークンの失効時間を含む。また、パーシステントブラウザアクセス可能トークンは、認証装置のＵＲＬ又はドメイン名を記憶する。パーシステントブラウザアクセス可能トークンは、ブラウザ又はそれに関連するプロセスによって様々なストレージスペース（ｓｔｏｒａｇｅ ｓｐａｃｅｓ）に書かれる、標準ＨＴＭＬ４ ブラウザクッキーストレージ、ＨＴＭＬ５ ストレージ（例えばＨＴＭＬ５ ローカルストレージ、ＨＴＭＬ５ セッションストレージ、ＨＴＭＬ４ グローバルストレージ、ＨＴＭＬ５ ライトストレージ等）アドビ フラッシュ スペース、アンドロイド ダルビック ストレージスペース、Ｊ２ＭＥ ｍａｎａｇｅｄ コード スペース、ＮＥＴ（スマート クライアント）コード スペース、Ｎａｔｉｖｅ ｘ．５０９ｖ３ Ｃｅｒｔｉｆｉｃａｔｅ ストレージスペース、ＳＤＲＯＭ、ブラウザ１１３ａにより読み込み／書き込み可能なその他のストレージスペース等である。

パーシステントブラウザアクセス可能トークンを生成、初期化するために、認証装置は、ブラウザ１１３ａにより送られてきた認証情報又はユーザ又はモバイル装置１１３ａについてのアイデンティティデータベース１１４ｎから受け取った情報を使用する。例えば、ユーザがユーザネームとパスワードを送って認証が成功したときは、ユーザネームは、パーシステントブラウザアクセス可能トークンのユーザのアイデンティティとして使用される。他の実施形態では、ユーザのアイデンティティは、アイデンティティデータベース１０４ｎによって認証装置１０２に送られたユーザネームとＩＤ番号とである。また、データが、パーシステントトークンの中に記憶されるため生成される。例えば、配信時間として、トークンが生成されるか又はブラウザに送信された現在時間をセットする。さらに、認証装置１０２の構成やアイデンティティデータベース１０４ｎに記憶されたデータ又は規則に基づいて、失効時間が計算される。これは、現在時間に、認めるように構成されたパーシステント時間を追加することにより実行され、パーシステントトークンの中に計算された時間が記憶される。

上述のように、いくつかの実施形態において、認証装置は、また、現在のユーザｉｄとパーシステントトークンに関連する加入したセッショントークン（例えば、ＨＴＭＬ４ クッキー及び／又はＨＴＭＬ５ オブジェクト等）を生成する。このトークンは、現在のブラウザセッションに対してだけ有効である。それは、新たなアプリケーションのためにアクセスするたびごとに求められるパーシステントトークンの再チェックの代わりに、同じブラウザセッションで要求がされる限りにおいて有効なセッションであることを、認証装置は単にチェックするだけで済むようにする。

クライアントアプリのアイデンティティは、モバイル装置１１０ａ上でクライアントアプリを起動するＵＲＬマッピング構造を介して、ブラウザに送られクライアントアプリと通信するための他のデータ構造又はテキスト列である。同６で示すように、クライアントアプリのアイデンティティ６０７は、上述のように、ユーザのアイデンティティと検証構造を含む。付加的な信用証明を得るため、ネットワークベースのアプリケーションにアクセスするため、又はユーザ特定のローカル機能を使用するため、クライアントアプリのアイデンティティを送信及び／又は受信することを含む、しかし、これらに限定されない様々な方法で、クライアントアプリは、クライアントアプリのアイデンティティを記憶し使用する。例えば、クライアントアプリはサーバにクライアントアプリのアイデンティティを渡す。そのアプリケーションは、ＲＥＳＴコールや、ウェブサービスやＡＰＩ又は他の機構を含むよう様々な方法を使用する。いくつかの実施形態において、クライアントアプリのＩＤはクライアントアプリにより使用される前にクライアントアプリのアイデンティティによって変形されることがある。

トークン／アイデンティティ、ブラウザアクセス可能な維持トークン（といずれかのセッショントークン）とクライアントアプリのアイデンティティは、ウェブブラウザベースの通信を介して、ブラウザ１１３ａに、認証装置１０２により送られる。これは、ＨＴＴＰ 又は ＨＴＴＰＳデータの転送により実行されることにより、又は当業者に知られているいずれか他の技術により達成される。秘密交換のために、データは暗号を使用するブラウザに送られる。そして、ブラウザは、ブラウザアクセス可能トークンのストアの１つの中にパーシステントトークンを記憶する。ストアとして、ＨＴＭＬ４ パーシステントセッショントークン チケット、ＨＴＭＬ５ ストレージ（ローカルストレージ、セッションストレージグローバルストレージ、ＳＱＬライトストレージ）、ｘ．５０９ｖ３ ｃｅｒｔｉｆｉｃａｔｅ ストア、フラッシュ クッキー、及び／又は将来使うために上述したその他のものを含む。ブラウザ１１３ａは、認証装置１１２ａかた、ブラウザを閉じる及び／又はクライアントアプリ１１１ａに対するモバイル装置１１０ａのユーザインターフェイスのフォーカスを戻すために、以下に延べる指示を受ける。

いくつかの実施形態で、クライアントアプリのアイデンティティは、ブラウザ１１３ａから、様々な機構を使用するクライアントアプリ１１１ａ内の認証モジュールに、転送される。

いくつかの実施形態では、ＵＲＬは、ブラウザによってそのＵＲＬがアクセスされたときに、クライアントアプリを起動するため、モバイル装置上及び／又はそのブラウザ上にマップされる。このマッピングは、クライアントアプリ／認証モジュールの起動のとき、ダウンロードのとき、及び又インストールのときクライアントアプリ／認証モジュールによって、又はモバイル装置の他の管理部によって、そのブラウザ及び／又はモバイル装置に登録される。例えば、例えば、クライアントは、起動して、装置上に、登録されたＵＲＬマッピングを持っているかどうか検査する。もし、登録されていなければ、ＵＲＬ“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ１”がブラウザによってコール／アクセスされたとき、クライアントアプリの実行を起動するマッピングを登録する。また、“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ１”は、クライアントアプリのインストールのとき登録される。クライアントアプリが、クライアントアプリのアイデンティティを要求し、認証装置の認証ワークフローを実行するようブラウザを起動したとき、認証装置は、そのブラウザに、ＵＲＬ“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ１”にコール／アクセスするよう指示する。“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ１”のマッピングはモバイル装置及び／又はブラウザに登録されているので、そのＵＲＬへのブラウズをしようとする代わりに、クライアントアプリが、代わりに起動されて、そのブラウザは閉じられる。このようなマッピングは、また、認証装置内に記憶される。

固有の独立ブラウザが特定の認証ＵＲＬに誘導されるようにされたとき、その認証ＵＲＬはクライアントアプリに関連する特定の形式であったり、クライアントアプリの指標となるクエリーストリングパラメータ（ｑｕｅｒｙ ｓｔｒｉｎｇ ｐａｒａｍｅｔｅｒｓ）を含んでいたりする。ＨＴＴヘッダー又はクッキーは、認証装置に対する特定のアプリに対してアイデンティティの認証に使用される。この識別子（例えば、ｈｔｔｐ：／／ａｕｔｈ.ｅｎｔｅｒｐｒｉｓｅ.ｃｏｍ／ａｕｔｈｅｎｔｉｃａｔｅ／？ｃｌｉｅｎｔａｐｐ＝ＣＬＩＥＮＴＡＰＰ１）に基づいて、認証装置は、ブラウザに、“ＣＬＩＥＮＴＡＰＰ１”として同定されるクライアントアプリに対応するＵＲＬ“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ１”にコール又はアクセスするよう指示する。

一旦、クライアントアプリが起動されると、クライアントアプリは、様々な方法でクライアントアプリのアイデンティティを受取る。例えば、アクセス／コールした、クライアントアプリを起動するＵＲＬストリングパラメータ名（例えば、ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ１？ｉｄｅｎｔｉｔｙ＝ＪｏｈｎＤｏｃ等）からパラメータとして構文解析することや、ブラウザのベースヘッダーやセッション情報の独立ブラウザのストレージにアクセスしたり読んだりすること（例えば、ブラウザのクッキーストレージにアクセスすること）等が含まれる。他のケースでは、クライアントアプリのアイデンティティを渡すために使用されるクエリーストリングパラメータ名やクッキー／セッション名が、認証装置と、転送されるクライアントアプリのアイデンティティデータの同定を助けるためのクライアントアプリの両方に知られている。上記の例のように、認証装置とクライアントアプリ／認証モジュールとは、クライアントアプリのアイデンティティは、アイデンティティのクエリパラメータやネームＵＲＬの中に記憶されることを知っている。このようなネーミングの慣習は、クライアントアプリ／認証モジュールと装置の中で設定可能である。

しかし、モバイル装置上のブラウザは、クライアントアプリのアイデンティティを、モバイル装置上で動作するクライアントアプリ１１１ａに転送することができない。認証モジュールは、ブラウザ１１３ａからアプリのアイデンティティを受取る必要はないが、代わりに、クライアントアプリのアイデンティティは、（図示せぬ）他のクライアントサーバ構造上で、クライアントアプリ１１１ａに直接送られなければならない。これは、当業者に知られている技術の様々な方法で達成される。例えば、クライアントアプリ１１１ａ内の認証モジュールは、ウェブサーバ又は認証サーバへの直接のＲＥＳＴ ＡＰＩ コールに対して許可する。この評価トークンは認証サーバから、クライアントアプリに渡すことができる。

クライアントアプリのアイデンティティがどのように受取られるかを気にしなければ、通常の又は暗号化テキストで受取られる。暗号化されていれば、クライアントアプリ（又は任意のネットワークベースのアプリケーション資源）は、クライアントアプリのアイデンティティを復号するため、ウェブサービスコールやその他の機構を使用する。そして、通常のテキストであるクライアントのアイデンティティは、認証装置からクライアントアプリ／認証モジュールに送られる。他の実施形態では、暗号化されたクライアントアプリのアイデンティティを、モバイル装置上でローカルに実行されるシンメトリック、公開／秘密鍵の暗号／復号を使用して、復号化をする。

クライアントアプリ１１１ａがクライアントの身分を受取ると、クライアントアプリ１１１ａは、そのアイデンティティを企業サービスサーバ１０３ｎに送り、さらに、アイデンティティを使用する認証用／許可用のトークン／信用証明を得て、クライアントのアイデンティティが受入れられ使用される任意のローカル機能又はネットワークサービスを使用する。企業サービスサーバ１０３ｎは、そのアイデンティティを分析して、内部的にそのトークンが属するユーザ又はモバイル装置を決定して、その認証性を照合する。照合は、クライアントアプリのアイデンティティ内に含まれる暗号署名を有効化すること、又はアイデンティティデータベース１０４ｎのような局所的又は遠隔のデータベースの検索を実行することを引き起こすが、これらに限られるものではない。企業サービスサーバ１０３ｎは、クライアントアプリに関連するユーザ又はモバイル装置１１０ａの認証として、そのアイデンティティを受け入れることに加えて、その企業サービスサーバをユーザ又はモバイル装置が使用するための許可を、独立してする。

１度、独立ブラウザがパーシステントトークン及び／又はセッショントークンを記憶すると、ユーザは、様々なウェブサイト、ウェブサーバ、ウェブサービスに、追加的な認証なしでアクセスできることに留意すべきである。独立ブラウザは、ブラウザベースのパーシステントトークン中のアイデンティティのアイデンティティ認識を介して、シングルサインオン機能を自動的に実現するのに、そのパーシステントトークンを使用する。このＳＳＯの機能は、本願に記載する認証サーバにより実行される。
クライアントアプリ再認証例

クライアントアプリは、ユーザにより１度以上使用されることがある。例えば、ユーザは、特定のローカル機能やネットワークベースのアプリケーションサービスにアクセスして上述の認証プロセスが使用される認証を要求されるために、クライアントアプリを使用する。そして、ユーザは、同じクライアントアプリを再度使用し同じか類似のローカル機能やネットワークベースのアプリケーションサービスにアクセスを試みる。

図３は、所望のネットワークベースのアップリケーションサービスのために、クライアントアプリ１１１ａが、まず認証して、その後、認証装置１０２から、クライアントアプリの身分を受取る認証プロセスを示す。クライアントプリ１１１ａの２回目の使用のために、上述の同じ基本認証プロセスが実行される。しかし、クライアントアプリ１１１ａは、既に認証されているので、認証プロセスは、少し異なるプロセスを実行する。

最初に、クライアントアプリ１１１ａが、初期化されるか、ネットワークベースのアプリケーションへのアクセスを得ることを試みるとき、認証モジュールはクライアントアプリのアイデンティティを検索する。クライアントアプリ１１１ａは、既に認証しているので、そのようなクライアントアプリのアイデンティティは見つけられる。認証モジュールにより見つけられた記憶されたアイデンティティが、企業サービスサーバ１０３ｎの所望のネットワークベースのアプリケーションへのアクセスに有効であることを究明するため、クライアントアプリのアイデンティティが検査される。この究明は、１つのまたは複数の要因に基づく。要因には、例えば、現在のユーザは、以前のセッションからのクライアントアプリのアイデンティティを使用しているかどうか、クライアントアプリのアイデンティティは時間限定されているかどうか、クライアントアプリのアイデンティティは同じサービスへのものかどうか、クライアントアプリのアイデンティティは有効かどうか、等が含まれる。有効であることがわかると、クライアントアプリ１１１ａは、アクセス鵜を得るために、サービスのクライアントアプリのアイデンティティを、すぐに送るか、使用する。クライアントアプリ１１２ａに対する同様のプロセスが、図５に示されている。有効でないときは、クライアントアプリは、図２で示される認証プロセスを繰り返すか、繰り返しのユーザの認証の信用証明又は許可が無効にされているかどうかを究明する。

同じ実施形態において、クライアントアプリのアイデンティティが見つけられた、又は検索されたかどうかにかかわらず、クライアントアプリ１１１ａは、所望のネットワークベースのアプリケーションサービスに対する繰り返しユーザの認証の信用証明又は許可が、図２に示す初期認証プロセス以降、無効となっているかどうかの確認を要求する。この理由又は他の理由のため、クライアントアプリ１１１ａの認証モジュールは、認証が要求されるときはいつも、認証ＵＲＬにブラウザを誘導するように構成される。

上述のように、ブラウザ１１３ａは、渡されたＵＲＬにアクセスすることにより認証装置にアクセスする。認証ＵＲＬにアクセスする１部分として、ブラウザは、ＨＴＭＬ４ セッションクッキー又はＨＴＭＬ５ セッションオブジェクト及び／又は記憶されたパーシステントトークンを、自動的に又は要求により認証装置に渡す。パーシステントトークンを認証装置に送るかどうかは、パーシステントトークンに関連付けられたＵＲＬ及び／又はドメインとそのＵＲＬとの比較をするブラウザにより決定される。一致又は部分的一致が見つかると、ブラウザ１１３ａは、認証装置１０２にそのパーシステントトークンを送る。別の方法では、ブラウザが、そのパーシステントトークンに関連付けられた記憶されたセッショントークンを有していれば、セッショントークンだけが認証装置に渡される必要がある。

認証装置１１２ａは、ブラウザ１１３ａにより送られたパーシステントトークン又はセッショントークンを検索する。パーシステント又はセッショントークンが見つけられると、認証装置は、そのトークンを有効にし、照合する。このような有効確認と照合確認は、パーシステントトークンを含む署名の暗号有効確認の実行、又は、関連するアイデンティティデータベース１０４ｎに一致するトークンの中に記憶された情報又はローカルデータベースの以前の認証についての記憶された属性の照合を引き起こす。また、この有効確認と照合確認は、特定のアプリケーションに対するユーザの認証の権利と許可とが、無効となっているかどうかを究明することを含む。これらの権利は、アイデンティティデータベース１０４ｎの中のユーザ属性に関連する無効の調査、例えば、信用証明の最大個数や信用証明の有効期間の開始時間と終了時間等により究明される。これらの値は、企業サービスや認証装置１０２やアイデンティティデータベース１０４ｎの管理者のような管理者により設定可能である。このような究明は、その全体を参照することにより本願に含まれる出願番号１２／４１９，９５１であるＵＳ公開特許に記載されているように、実行される。

有効確認と検証確認が、成功すると、認証装置１０２は、図２で記述するような所望の企業サービスサーバ１０３ｎへのアクセスを得るために使用されるクライアントアプリ１１１ａに送られる、新たなクライアントアプリのアイデンティティを生成する。
第２のクライアントアプリの認証例

図４を参照して、この例示するシナリオでは、クライアントアプリ１１１ａは、すでに、認証装置を使用する認証をしている。クライアントアプリのアイデンティティは、クライアントアプリ１１１ａの中に記憶され、パーシステントトークンはブラウザ１１３ａの中に記憶されている。モバイル装置１１０ａ上にダウンロードされインストールされた第２のクライアントアプリ１１２ａは、クライアントアプリ１１１ａのように、同じ又は異なる企業サービスサーバを使用するために探す。クライアントアプリ１１１ａとクライアントアプリ１１２ａとが同じ又は関連する認証ＵＲＬ（例えば、認証のため認証装置に関連する同じもの又はドメイン等）を使うとすれば、第２のクライアントアプリ１１２ａの認証プロセスは、ブラウザ１１３ａの中に記憶されたパーシステントトークンを用いて短縮することができる。

一般的には、第２のアプリケーションは、図２に示されるように、第１のクライアントアプリのようなやり方で、認証して、ネットワークベースのアプリケーションに対するアクセスを得る。認証装置１０２ａは、ブラウザ１１３ａによって送られるパーシステントブラウザアクセス可能トークンを検索する。図３で上述のように、もし見つけられれば、認証装置は、そのトークン（又は、もし送られていれば、関連するセッショントークン）を有効にし、照合する。このような有効確認と照合確認は、パーシステントトークンを含む署名の暗号有効確認の実行、又は、関連するアイデンティティデータベース１０４ｎに一致するトークンの中に記憶された情報又はローカルデータベースの以前の認証についての記憶された属性の照合を引き起こす。また、この有効確認と照合確認は、特定のアプリケーションに対するユーザの認証の権利と許可とが、無効となっているかどうかを決定することを含む。これらの権利は、アイデンティティデータベース１０４ｎの中のユーザ属性に関連する無効の調査、例えば、信用証明の最大個数や信用証明の有効期間の開始時間と終了時間等により決定される。さらには、ＯＣＳＰｓやＣＲＬｓのような従来の証明が利用できる。これらの値は、企業サービスや認証装置１０２やアイデンティティデータベース１０４ｎの管理者のような管理者により設定可能である。このような決定は、その全体を参照することにより本願に含まれる出願番号１２／４１９，９５１であるＵＳ公開特許に記載されているように、実行される。

パーシステントトークンの有効確認と照合確認の１部分として、認証装置１０２は、実行されるための、ユーザ、第２のクライアントアプリ１１２ａ、及び／又はモバイル装置１１０ａの付加的認証を要求する。認証装置は、第２のクライアントアプリがアクセスを試みる特定のネットワークベースのアプリケーションが、秘密性の強化のため、複数の認証のタイプや、以前実行されたよりも強い認証を要求することを決定する。この決定は、認証装置１０２上の規定の設定又はアイデンティティデータベース１０４ｎの設定又は規定の参照に基づいて、独立して行われる。例えば、アイデンティティデータベース１０４は、要求される認証がより高度なレベルの又は複数要素の認証であることを示す、特定のユーザやモバイル装置１１０ａ、クライアントアプリ１１２a、又は企業サービスに関連する属性を記憶する。このような設定は、ユーザに付加的な認証情報を提供することを要求する。また、付加的な認証は、その全体を参照することにより本願に含まれる出願番号１２／９４８，０３７であるＵＳ公開特許に記載されているように、実行される。付加的な認証の実行の例として、すでに集められたユーザネーム（ユーザｉｄ）とパスワードに加え、同様に、ＳＭＳメッセージの１部分や、質問／答に基づく知識、静的ＰＩＮ、又はＵＳＢキーが集められた認証装置がある。認証性を決定するため、集められたデータは認証装置１０２により、ローカルデータベースやアイデンティティデータベース１０４ｎ内の情報と比較される。

付加的な認証が成功すると、認証装置は、ブラウザ１１３に送信され記憶される新たなブラウザアクセス可能なパーシステントトークンを生成する。ユーザ、モバイル装置１１０ａ、又はクライアントアプリ１１２ａが、耐性のある複数タイプの又はより強いタイプの認証を有することを、新たなパーシステントトークンは示している。もう１つの又は複合したものとして、認証装置は、古い又は最近生成されたパーシステントトークンであって、そのトークンのべアラー(ｂｅａｒｅｒ)が、複数の要因を使用して又は信頼できるレベルの強度で認証されていることを示すパーシステントトークンについての情報を記憶する。この情報はアイデンティティデータベース１０４ｎの中に、又は、認証装置１０２の中にローカルに、記憶される。例えば パーシステントトークンに関連する認証の数、認証のタイプ、及び／又は認証の強度は、アプリ１１２ａのユーザに対応するアイデンティティデータベース１０４ｎの中のユーザプロファイルの中に記憶される。

同様に、認証装置は、第２のクライアントアプリ１１２ａによって送受信される新しいクライアントアプリのアイデンティティを生成する。ここで、ユーザ、モバイル装置１１０ａ、又はクライアントアプリ１１２ａが、耐性のある複数タイプの又はより強いタイプの認証を有することを、この新しいクライアントのアイデンティティは示している。もう１つの又は複合したものとして、認証装置は、そのトークンのべアラー(ｂｅａｒｅｒ)が、複数の要因を使用して又は信頼できるレベルの強度で認証されていることを示すクライアントアプリのアイデンティティについての情報を記憶する。この情報はアイデンティティデータベース１０４ｎの中に、又は、認証装置１０２の中にローカルに、記憶される。例えば クライアントアプリのアイデンティティに関連する認証の数、認証のタイプ、及び／又は認証の強度は、アプリ１１２ａのユーザに対応するアイデンティティデータベース１０４ｎの中のユーザプロファイルの中に記憶される。

もし、付加的な認証が必要とされないならば、パーシステントブラウザアクセス可能なトークンとクライアントアプチの身分は、生成されて、ブラウザとクライアントアプリ１１２ａそれぞれに、普通に送られる。上記の図２で検討したトークンを含む、このようなトークンは以前の認証の認証レベルを示すデータを含んでいる。いくつかの実施形態において、付加的な認証が全く要求されなければ、同じパーシステントトークンを使い続け、新しいパーシステントトークンは生成されない。

当業者が認識するように、いくつかの実施形態は、クライアントアプリのアイデンティティ、パーシステントトークン又は認証装置１０２内又はアイデンティティデータベース１０４ｎのいずれかにおいて認証レベルを追跡できる。

クライアントアプリのアイデンティティが、クライアントアプリ１１２ａにより得られると、クライアントアプリ１１２ａは、そのトークンを、付加的な認証や認証証明を得るために使用し、企業サービスサーバ１０３へのアクセスや、アイデンティティを条件とするローカル機能へのアクセスを得る。
第２のクライアントアプリの再認証の例

図５を参照して、この例示するシナリオでは、図４で示したように、クライアントアプリ１１１ａは、すでに、認証装置を使用する認証をしている。クライアントアプリのアイデンティティはクライアントアプリ１１１ａの中に記憶されていて、パーシステントブラウザアクセス可能トークンはブラウザ１１３ａの中に記憶されている。モバイル装置１１０ａ上にダウンロードされインストールされた第２のクライアントアプリ１１２ａもまた、すでに認証して、企業サービスサーバ１０３ｎにより、受け入れ可能なクライアントアプリのアイデンティティを受信して記憶している。

ユーザによりクライアントアプリ１１２ａが再初期化され、クライアントアプリ１１２ａが、２回目の企業サービスサーバへのアクセスをする前に、検索を行い、所望の企業サービスにアクセスするためのクライアントアプリのアイデンティティがすでにローカルに記憶されているかどうかを決定する。もし見つかると、クライアントアプリ１１２ａはその企業サービスサーバにクライアントアプリのアイデンティティを提供する。企業サービスサーバ１０３ｎにより受け入れられると、クライアントアプリ１１２ａは、そのとき、サービスにアクセスする。トークンが拒絶される理由には、例として、トークンが古すぎることや、トークンが暗号について有効でないことが含まれる。このように、限られた時間内に、ユーザ又はブラウザにより再認証が全く要求されないことがある。一方、ユーザは、ブラウザを使って最近、すでに認証したために、ユーザは、アプリ１１２ａを単純に起動し妨害なしにサービスのアクセスすることがある。いくつかの実施形態では、図３において第１のクライアントアプリについて述べたように、第２のクライアントアプリは、クライアントアプリのアイデンティティが無効となっているかどうか、常に決定することができる。

このケースにおいて、モバイルアップ理は固有のブラウザを起動して、そのブラウザを、例えば、図３に示したこの明らかなアプリケーションについて詳細に説明したように、ウェブサーバに誘導することを選択する。そして、ウェブブラウザは、ブラウザアクセス可能なセッショントークンを、場合によってはパーシステントトークンをも（もし、セッショントークンが得られなければ、パーシステントトークンを再検査するよう指示される）、検索して検査して、それらのトークンに対応する属性と、関連するユーザｉｄ、時間／期限、そのアイデンティティが１０４ｎのようなアイデンティティデータストアに存在するかどうか、グループ許可等を再評価する。

もしすべてが受け入れ可能であれば、認証サーバは、ここで述べたような機構を介して、クライアントアプリのプロセスの中で利用されるクライアントアプリのアイデンティティをクライアントアプリに送り返す。
他のクライアントアプリケーションのフローチャート

図７と図８は、認証モジュールと、モバイル装置上の固有の、独立ブラウザによるアクショントークンの例示の実施形態のフローチャートを示す図である。

図７は、第１の起動されたモバイルアプリケーション（即ち、クライアントアプリ）に対する認証プロセスを示している。クライアントアプリが開始されると、認証モジュールは、７０２で、以前認証された、クライアントアプリのアイデンティティを検索する。７０３で見つかると、認証モジュールは、７０４で、クライアントアプリのアイデンティティの消滅状態の常時チェックが設定されているかどうか決定する。もし、状滅状態のチェックが要求されなければ、クライアントアプリのアイデンティティは、クライアントアプリに対する所望のネットワークサーバへのアクセスを得るために、７１０でサーバに送られる。

しかし、消滅状態がチェックされると、又は、クライアントのアイデンティティは見つからないと、そのプロセスは、ブロック７０５に続く。ブロック７０５において、認証モジュールは、認証装置上の認証ＵＲＬにアクセスするよう、固有の独立ブラウザに指示する。上述のように、そのＵＲＬは、認証される特定のアプリケーション、要求される認証のレベル、ブラウザ／クライアントアプリの対に対して認証装置により使用されるクライアントアプリへのブラウザに関連する識別子等、を示すパラメータを含む。また、これらのパラメータは、ＵＲＬストリングの代わりに、ＨＴＴＰヘッダーや他の方法により渡されることもある。

ブロック７０６において、ＵＲＬにアクセスすると、ブラウザは、すでに記憶され、その認証ＵＲＬ又は認証装置に加入した、パーシステントブラウザ可能トークン（及び／又はセッショントークン）を送る。パーシステントブラウザ可能トークン（及び／又はセッショントークン）は、付加的な認証又は再認証が要求されるかどうかの決定において、認証装置によって使用されることができる。

ブロック７０７において、認証が求められると、ブラウザは、例えば、ユーザネームやパスワード、静的ＰＩＮ、ユーザ登録信用証明、答に基づく知識等を含むユーザやユーザ加入によって入力されたすべての認証データを送る。認証装置が満たされると、ブラウザは、その認証装置から、上述のパーシステントブラウザ可能トークン（及び／又はセッショントークン）を受取る。ブロック７０８において、そして、ブロック７０９において、認証モジュールが、クライアントアプリのアイデンティティを受取ると、上述のように、クライアント装置上のＵＲＬマッピング構造を用いて、認証モジュールは、クライアントアプリ／認証モジュールのＵＲＬクエリーストリングの構文解析やクッキーに対するブラウザセッション記憶の読取りを起動させることができる。ブラウザは閉じ、ブロック７１０において、認証モジュールは、アクセスのため、サーバに対してクライアントアプリのアイデンティティを使用でき、又は、モバイル装置上でローカルの利用可能な機能や他の方法でさらなる認証信用証明を獲得するためにアクセスする許可をするためを含むいずれかの他の目的のため、使用できる。

図８で、第２のクライアントアプリの認証プロセスの例を示す。ブロック８０７で、認証の第２のレベルが、あるアプリのために要求される。上述のように、ネットワークサービスが、以前のクライアントアプリ又はネットワークサービスでなされたよりもより高いレベルの認証を要求することがある。したがって、現在のクライアントアプリに対するクライアントアプリのアイデンティティが認証モジュールにより受け取られる前に、付加的な認証が、ブラウザにより送られ、認証装置によって照合される。
ログアウト

いくつかの実施形態において、ログアウト機能は企業サービスや使用されている資源からモバイルアプリをログオフする。ログアウトは、モバイルアプリがログアウトしたい企業サービスにメッセージを送信することにより起こる。

しかし、複数のアプリケーションＳＳＯ環境においては、ユーザは、同時に、複数のアプリケーションにログインされていることがある。したがって、ユーザが、１つのクライアントアプリで、１つのネットワーク資源からログアウトしたとき、ユーザがすべてのアプリケーションからログアウトしたと信じていたとしても、他のアプリケーションはまだログインしていることがある。パーシステントトークンとセッショントークンは、まだ、ブラウザの中にあり、他のアプリケーションは、ユーザがログアウトしたと信じているにもかかわらず、他のアプリにログインするための信用証明を使用する。他人のモバイル装置を保有する悪意のユーザは、ユーザが、彼又は彼女はログアウトしたと信じているにもかかわらず、そのパーシステントトークンを用いて、反応中のアプリやネットワーク資源にアクセスすることができる。シングルログアウトシステムのもう１つの欠点は、ユーザが、彼又は彼女はすべてのアプリケーションからはログアウトされていないと気付いているにもかかわらず、１度にすべてのアプリ―ケーションをログオフすることを、ユーザが強制されるのは不便であるということである。

したがって、ユーザはすべてのアプリケーションから同時にログオフすることを望む。その代わりに又は組み合わせて、関連するアプリケーション、認証装置、及び／又は、アクセスされているネットワーク資源の管理者は、無駄なログインを減らし、安全性を増加するために、すべてのアプリケーションから同時に、（例えば、設定された方針をとおして）ログアウトすることを要求する。

いくつかの実施形態において、以下に開示されるシステムと方法により解決される。それらは、ユーザにすべてのアプリケーションからログアウトすることを認め、ログアウトが起こったことを認証サービスに通知し、他のモバイルアプリケーションがブラウザに記憶されたパーシステントトークンを介してログインすることを阻止することによるものである。実施例のこのタイプは、モバイルアプリケーションが、企業サービスや資源にアクセスする前に、上述のブラウザを介して認証装置へ再認証するため、将来ログインすることを試みることを要求する。いくつかの実施形態においては、１つのアプリケーションがログアウトとすると、全体的なログアウト操作のように、関連するサービスから他のアプリケーションをログアウトする。このような全体的なログアウトは、アクティブな各アプリケーションを、ローカルに又は認証装置上に登録することにより、又は、他の実施形態においては、モバイル装置内に登録されたアクセス可能なＵＲＬの所定の順序を介して、他のモバイルアプリケーションを繰り返してコールすることにより実行される。

モバイルアプリケーションは、自動的にアプリケーションにより（例えば、タイムアウトの後）又はユーザの相互作用を介して起動される、ログアウト機能を実装する。モバイルアプリの、設定され予定されたログアウトが発生するか、ユーザが示したログアウトが発生したときは、いくつかの実施形態において、アプリケーションは、ユーザがログアウトしたことを示すため、企業サービスにログアウトメッセージを送信する。例えば、そのようなメッセージは、企業サービスに、そのモバイルアプリケーションはもはやログイン状態でないとみなされ、そのサービス又は資源へのアクセスをもはや有さないことを示す、ＨＴＴＰウェブサービスコール（又はいずれかのプロトコルでのメッセージ）を備える。企業サーバまたはサービスがモバイルアプリケーションに応答していようがいまいが、ログアウトは起こる。応答すると、モバイルアプリに、６０６に示すような、そのクライアントアプリのアイデンティティ、及び／又は、ユーザ認証／ログインに関連するドメインを消去する指示を含む。

いくつかの実施形態において、図９に示すように、モバイルアプリケーションは、認証装置に、ログアウトについて通知することを実行する。上述のように、図９において、クライアントアプリは、ユーザの選択により（又は自動的に）、企業サービスからログアウトを開始する（１）。上述のように、企業サービスはモバイルアプリケーションに対する付加的なメッセージに応答することもあるし、しないこともある。

いくつかの実施形態において、モバイルアプリは、装置／サービスに応募／サービスからログアウトすることを支持するために、認証装置と通信して、再照合（例えば、セッショントークンを廃棄し、再照合するためのパーシステントトークンの要求）のない、認証の信用証明の機能の使用を阻止する。いくつかの実施形態において、これは、モバイル装置のブラウザをコールすることと、ブラウザ１１３ａを認証装置に関連する特定のログアウトＵＲＬに誘導することにより実行される（２）。このＵＲＬは、モバイルアプリ１１２ａに既知であるか、企業サービスサーバ１０３ｎ又は認証装置１０２から、ログオンプロセス（又はいずれか他の設定プロセス）の一部として受信されるか、モバイル装置内（いくつかの実施形態においては、認証モジュール内）に記憶されている。そして、ブラウザは、ログアウト操作を要求する特定のＵＲＬにアクセスして、認証装置に、ユーザがログアウトを要求していることを識別するために、認証装置にユーザブラウザ（セッション又はパーシステント）トークンを送信する。例えば、ログインのとき、特定のログアウトＵＲＬは、生成されるか、又は、認証装置／サービスにアクセスされてブラウザに送信される（いくつかの実施形態においては、モバイルアプリに転送される）。そして、ログアウトが求められるとき、このＵＲＬは、アクセスされる。このようなログアウトＵＲＬは、ＵＲＬの様々な部分にログオフの相手先を示している。例えば、ＨＴＴＰが得たパラメータ内、ＰＯＳＴパラメータ（例えばクッキーとして送信されるパーシステントトークン）、自身の主ＵＲＬ内にである。いくつかの実施形態において、また、ログアウトＵＲＬは、ブラウザに、ログアウトＵＲＬにアクセスすることを指示するモバイルアプリケーションを示し、関連付けている。（例えば、ｈｔｔｐ：／／ ａｕｔｈ.ｅｎｔｅｐｒｉｓｅ.ｃｏｍ ／ｌｏｇｏｕｔ／？ｃｌｉｅｎｔａｐｐ＝ＣＬＩＥＮＴＡＰＰ１）。

そして、アプリケーションは、パーシステントトークン（例えば、セッショントークンやパーシステントであるようなブラウザトークン）及び／又はパーシステントトークンに関連する何らかのアイデンティティを、有効なトークンのセット及び／又は有効なアイデンティティから取り除く（４）。これは、ユーザを、現在は企業サービスにログオンしていないモバイルアプリケーションへのアクセスからログアウトする。ここで述べられるように、ログイン／認証プロセスに対してブラウザトークン（セッション又はパーシステント、実施形態に依存する）の使用を要求するモバイルアプリケーションは、ブラウザ内に記憶されたブラウザトークンを使用することができない。そのブラウザトークンを認証装置に送ることは、企業サービス／サーバ１０３ｎに使用するための適切なクライアントアプリのアイデンティティを受信しなおす結果をもはやもたらさないからである。ブラウザトークンに対応するクライアントのアイデンティティは、消去されたか、関連を解かれたか、又モバイルアプリケーションやクライアントアプリのアイデンティティへの使用を制限されているので、認証装置は、いかなるクライアントアプリのアイデンティティも参照することができない。この段階では、装置は、特定のユーザがログアウトしたことをデータベースに書き込むかファイル（例えば、ログ）する。それには、日／時間、モバイル装置の識別子、ブラウザの識別子、クライアントアプリのアイデンティティ、及び／又はログアウト要求に関連するモバイルアプリが含まれる。

その装置は送信し、その認証装置から、モバイル装置とブラウザは、モバイル装置のブラウザからブラウザトークンを取り除く指示を受信する（５）。例えば、そのブラウザトークンがＨＴＴＰクッキーの形式であるときは、（例えば、過去又は現在の時間にクッキーが消失した日付を設定するＳｅｔ−Ｃｏｏｋｉｅコマンド、又は最大の時間値に０又は制限されたパーシステント時間をセットすること、を介して）ブラウザにそのクッキーが失効したことを通知することにより、そのクッキーは消去される。そのブラウザにそのパーシステントトークンを破壊する又は再生不能にするよう指示をする、認証装置により使用される他の方法がある。

そのブラウザトークンは、取り除かれるか及び又は再現不能にされるので、その装置をとおして認証を探すすべてのアプリケーションは、モバイルシングルサインオンタイプのシステムをとおして、企業サーバ又はサービスへのアクセスを得るため再認証しなければならない。すなわち、そのブラウザトークンは、有効な認証セッションをもはや表さず、ユーザ／クライアントアプリのアイデンティティは、ログアウトされる。

図１０は、ログアウト機能に関連する他の実施形態を示す。図１０において、モバイルアプリケーション１０２ａは、シングルサインオンシステムにおいて、有効なクライアントアプリのアイデンティティとブラウザトークンとの関連付けを取り除くための、その装置との通信を開始できない。代わりに、ユーザがログアウトする（さもなければ企業サービス／サーバとのそれらのセッションを終了する）ことを決めた後、その企業サービスは、アプリ１１２ａにそのブラウザトークンを消去してそのウェブシングルサインオンシステムからユーザをログアウトすることを強制する（１）。これは、ログアウトするために、そのブラウザに指示するのに用いるため、クライアントアプリ１１２ａに、ＵＲＬを送信することにより実行される（２）。これらの実施形態のタイプの利点は、全体的なログアウトが発生したとき、企業サービス又は資源がコントロールして、クライアントアプリが、ログアウトＵＲＬを事前に記憶する必要がないことである。他の実施形態のように、クライアントアプリが、ログアウトプロセスを完成するため、そのＵＲＬを受信すると、そのアプリは、受信したＵＲＬにブラウザを誘導して、ログアウトプロセスは、前に図９で検討したように、続く。

図１１は、いくつかの実施形態が、上述のログアウトプロセスに含まれないクライアントアプリのログアウトをどのように強制するかを示す。上述のように、アプリケーションは、企業サービスサーバ１０３ｎに、ネットワークサービスのログアウトを通知する（１）。ネットワークサービスに接続する前又は後に、アプリは、ブラウザを特定のＵＲＬに誘導する（２）。そのＵＲＬは、認証装置に対応づけられた、ログアウトしてブラウザトークンを破壊する（又は、図１０で検討したように、企業サーバはクライアントアプリにその特定ＵＲＬにアクセスすることを指示する）ためのものである。そして、ブラウザは、その特定のＵＲＬ（又はウェブサービス、又は認証装置と通信するため使用されるいずれかのプロトコル）にアクセスする。ブラウザが、その特定ＵＲＬにアクセスすると、ブラウザは、ブラウザトークンを、認証装置１０２に送信する（３）。認証装置が、そのブラウザトークンの情報を得ると、その装置はそのブラウザトークンを、モバイル装置１１０ａ及び／又はブラウザ１１３ａに対応する有効なトークンの集合から取り除く。例えば、パーシステントトークンのＩＤを、モバイル装置１１０ａ又は特定のブラウザ１１３ａに対応させるデータベースの登録を取り除く。

認証装置に記憶されるものは、クライアントアプリのアイデンティティを受信して、ネットワークサービスにログオンするために同じパーシステントトークンを使用する、クライアントアプリ１１１ａのような１つ以上のアプリケーションのリストである。ＵＲＬマッピングは、各クライアントアプリに対応する。そのようなマッピングは、認証装置のマニュアル又は自動設定を通して取得された永続的な関連の結果であるか、又は、認証のとき又はクライアントアプリＩＤが発行されたときに、各クライアントアプリ又はそのブラウザから認証装置に送信されるものである。

先に検討したように、その後、その装置は、ブラウザトークンを（いくつかの実施形態では、オプション的にパーシステントトークンをも）破壊又は使えないことを表示する指示をもって、そのブラウザに応答する（５）。さらに、いくつかの実施形態では、認証装置は、また、クライアントアプリ１１１ａのようなクライアントアプリに対応するＵＲＬマッピングに、そのブラウザを誘導しなおすよう指示する。このようなマッピングは、例えば、認証装置により誘導しなおされたときに、そのブラウザによりそのＵＲＬ“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ１”がコールされ／アクセスされたときは、クライアントアプリの実行を起動する。“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ１”のマッピングは、モバイル装置上のクライアントアプリ１１１ａに対応するものとして登録されているので、そのＵＲＬをブラウズすることを試みる代わりに、クライアントアプリ１１１ａが代わりに起動される。

一度クライアントアプリが起動されると、アクセスしていたいずれかの企業サービスサーバやネットワーク資源のログアウトが自動的になされる（６）。これは、モバイル装置上のクライアントアプリ１１１ａに対応するクライアントのアイデンティティを下階すること、及び／又は、ログアウトしてセッションが経過したサーバやネットワーク資源に指示するため加入した企業サーバに、メッセージを送信することを含む。有利に、その技術の当業者が認識し得るように、これは、クライアントアプリ１１１ａをログアウトするため。クライアントアプリ１１２ａにより生成されたログアウトコマンドを許可する。さらに、いくつかの実施形態において。付加的なアプリケーションをログアウトするために使用される、さらなるＵＲＬマッピングについての質問を装置にするために、クライアントアプリ１１１ａは認証装置に戻る指示をブラウザにする。

いくつかの実施形態において、図１２で述べたように、ブラウザ（及び、さらにはクライアントアプリ）は、ログアウトされる場貴認証装置からアプリケーションのリストを受信する。認証装置は、ユーザの装置に送信したクライアントアプリのアイデンティティに基づいてユーザがログインしたアプリケーションを追跡する。図１２に示されるように、認証装置は、ログアウト要求を受信した後、ログインした他のアプリケーションに対するＵＲＬマッピングのリスト（又は、その代わりに、クライアントアプリがマッピングをすでに知っているときは、アプリケーションのリスト）を決定する（２）。このリストは、ブラウザ１１３ａに転送され（３）、クライアントアプリ１１１ａに渡される（４）。そして、そのリストは、各モバイルアプリをログアウトする目的で、各モバイルアプリをコールする連鎖を開始するため、固有のクライアントアプリのＵＲＬをコールするのに利用される。そして、各アプリは、第１のモバイルアプリケーションをコールバックする。第１のモバイルアプリケーションは、どのアプリがログアウトされたかと、どのアプリがコールされるために残っているかを、追跡しているからである。アプリ１１１ａは、ログアウトするため次のアプリをコールして、すべてのモバイルアプリが、ログアウトするためコールされるまで続けられる。

図１３は、ブラウザの再起動や認証装置のさらなる照会を必要とせずに、複数のクライアントアプリケーションのログアウトを可能にする他の実施形態を示している。これらの実施形態に対して、ログアウトプロセスは、前述のプロセスと同様に、特定のＵＲＬへのブラウザのアクセスと、パーシステントトークンを送信することを含む（１）。その装置が、有効なトークンのセットから、そのブラウザトークンを取り除くと、ブラウザ／ＯＳを起動するための１つ以上のＵＲＬマッピングを決定する。いくつかの実施形態において、認証装置は、コールされる基本のＵＲＬマッピングを決定する。その基本ＵＲＬマッピングは、ネットワークサービス又は企業サービス／サーバに対するクライアントアプリのアイデンティティを主張するモバイル装置上で実行されるクライアントアプリ対応するマッピングである。例えば、クライアントアプリ１１１ａは、基本ＵＲＬマッピングとみなされる所与のＵＲＬマッピングに関連付けられる。関数又は式に結びつけられた基本マッピングは、認証装置を照会せずに、付加的ＵＲＬマッピングを計算するために使用される。続けて、ログインされた１つのクライアントアプリから他のものへ進むためのログアウトインディケータの順次起動が許される（４）−（５）。

例えば、認証装置１０２は、クライアントアプリ１１１ａに対する基本マッピングを決定する。認証装置は、それが、ログオンの連鎖を起動したときや、クライアントアプリ１１１ａ又はブラウザ１１３ａにより、認証装置に、あらかじめ定められていて移転されたとき、１１１ａに対するＵＲＬマッピングを指定する。認証装置１０２は、基本ＵＲＬマッピングを変形するための適切な関数を決定又は調査／検索する。このような関数は、クライアントアプリ自身によって、外部から知られている。例えば、クライアントアプリと認証装置の両方は、特定の関数がＵＲＬマッピングの繰り返しを管理することを理解するようにプログラムされている。あるいは、その特定の関数は、クライアントアプリ又は認証装置の初期のログイン又は初期の設定に基づいて決定される。例えば、使用する適切な関数のインディケータは、クライアントアプリのアイデンティティと共に、クライアントアプリに移転される。

例を続けると、認証措置１０２は、ブラウザ１１３ａに、ログインセッションのためのブラウザセッショントークンを消去又は無効にする指示を送信する。さらに、１つのＵＲＬが、クライアントアプリ１１１ａにより登録されたＵＲＬマッピングに対応してアクセスされるために、ブラウザに送信される。このＵＲＬマッピングコールは、例えば、ＨＴＴＰ ＧＥＴ パラメータの包含による等のように、上述のクライアントアプリの関連するネットワークサービスのログアウト指示を含む。このログアウトプロセスの後、クライアントアプリ１１１ａは、例えば、クライアントアプリ１１１ｂのような、第２のクライアントアプリに対応する第２のＵＲＬマッピングにそのＵＲＬマッピングを変換するための関数又は式を使用する。例えば、クライアントアプリ１１１ａに対するＵＲＬマッピングが、“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ１”で、式が“１”を加算するものであったとすると、クライアントアプリ１１１ａは、次のＵＲＬを、“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ２”と計算する。アプリ１１１ａは、新しいＵＲＬマッピング“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ２”に登録されたクライアントアプリをコールする。これは、関連するネットワークサービス又は企業サーバからログアウトする指示とともに、ブラウザ１１３ａに新しいＵＲＬマッピングに誘導すること又はオペレーティングシステム内で新しいＵＲＬマッピングを直接コールすることを介して行われる。そして、クライアントアプリ１１１ｂは、対応するＵＲＬマッピング“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ２”へのコールによって起動される。このクライアントアプリは、関連するネットワークサービス又は企業サーバからログアウトして、同じ関数を用いた新しいＵＲＬマッピングトリガを計算する（即ち、“ＣｌｉｅｎｔＡｐｐＴｒｉｇｇｅｒ３”）。そのＵＲＬマッピングに対応するクライアントアプリがコールされ、繰り返される（５）。このやり方において、現在ログイン中のすべてのクライアントアプリは、消去又は無効化されたパーシステントトークンに対応するクライアントアプリのアイデンティティに使用からログアウトする。

的確な関数／式は、上述のようにＵＲＬマッピングの単純な反復加算であるが、より複雑な方法も考えられる。例えば、ハッシュ関数を使用するものであり、次のＵＲＬマッピングは、前のＵＲＬマッピングのハッシュである。あるいは、関数／式は、使用しなくともよい。代わりに、現在ログイン中のすべてのアプリケーションに使用されるすべてのＵＲＬマッピングのファイル／テーブルが、モバイル装置上に記憶され、検索のためと、すべてのアプリケーションをログアウトするためにコールする次のＵＲＬマッピングを決定するためにアクセスされる。いくつかの実施形態において、クライアントアプリのアイデンティティを使用して現在ログイン中のすべてのアプリケーションに使用されるすべてのＵＲＬマッピングは、モバイル装置上に記憶される。これらのＵＲＬマッピングは、図１２のステップ（２）でのブラウザに移転され、ログアウトプロセスの間、各クライアントアプリ間で転送される。あるいは、各クライアントアプリは、さらなるログアウトのためのコールする次のＵＲＬマッピングを決定するため、認証装置に照会する。
ターミノロジー（Ｔｅｒｍｉｎｏｌｏｇｙ）

実施形態によれば、ここで述べたプロセス又はアルゴリズムのいかなる特定の活動、事象、関数も、追加されたり、結合されたり、省略されていたりできる（例えば、記述した操作やイベントが、アルゴリズムの部分に透けて必要とされるわけではない）。さらに、特定の実施形態においては、操作やイベントは、同時に実施される。例えば、マルチスレッドプロセス、割り込みプロセス、逐次的なものよりは複数のプロセッサ又はプロセッサコアやその他の並列アーキテクチュア等を通してである。

ここに開示した実施形態と関連する、様々な実例となる、ロジカルブロック、モジュール、ルーチン及びアルゴリズムステップは、電子的ハードウェア、コンピュータソフトウェア、又はそれらの組合せにより実装される。説明を明確にするため、ハードウェアとソフトウェアの互換性、様々な実例となるコンポーネント、ブロック、モジュール及びステップは、それらの機能的な観点から一般的に記述されている。そのような機能が、ハードウェア又はソフトウェアとして実装されているかどうかは、特定のアプリケーションと、システム全体に課されている設計制約に依存する。記述された機能は、各特定のアプリケーション対して、多様な方法で実装されが、そのような実装の決定は、開示の観点からの分離を引き起こすものとして解釈してはならない。

ここに開示した実施形態と関連する、方法、プロセス、ルーチン、アルゴリズムのステップは、ハードウェアで直接実施されたり、プロセッサにより実行されるソフトウェアモジュールで実施されたり、これらの組合せにより実施されたりする。ソフトウェアモジュールは、ＲＡＭメモリ、ＳＤカード、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、その他の非一時的なコンピュータ読み取り可能な記憶媒体に存在する。典型的な記憶媒体は、プロセッサが情報を読み取り、書き込む記憶媒体のように、プロセッサと結合している。あるいは、記憶媒体は、プロセッサに統合されている。プロセッサと記憶媒体は１つのＡＳＩＣに存在できる。ＡＳＩＣは、ユーザ端末やモバイル装置の中にある。あるいは、プロセッサと記憶媒体は、ユーザ端末又はモバイル装置の中に、分離したコンポーネントとして存在する。

ここで使用される条件的な言葉、例えば、“ｃａｎ”、“ｃｏｕｌｄ”、“ｍｉｇｈｔ”、“ｍａｙ”、“ｅ．ｇ．”等は、明確に記述された他のものがないときや、使用される文脈の中で理解される以外では、特定の実施形態が、他の実施態様では含まない、特定の機能、要素及び／又はステップを含むことを伝えるように一般的に意図したものである。このような条件的な言葉は、機能、要素及び／又はステップが１つ以上の実施形態で必要とされるということや、１つ以上の実施形態において、これらの機能、要素及び／又はステップは含まれるのか、又は、ある特定の実施形態において実行されるのかを、著者の入力又は刺激の有無にかかわらず、決定する論理を必然的に含むということを、暗示する意図で一般的に使用されるものではない。“ｃｏｍｐｒｉｓｉｎｇ”、“ｉｎｃｌｕｄｉｎｇ”、“ｈａｖｉｎｇ”、等の言葉は、同義的であり、制限なく包括的に使用され、付加的な要素、機能、活動、操作等を排除しない。また、“ｏｒ”は、包括的な意味で使用される（排他的な意味ではない）。例えば、要素のリストに結び付けて使用されるとき、“ｏｒ”の用語は、リストの中の要素１つ、いくつか又はすべてを意味する。

「Ｘ，Ｙ及びＺの少なくとも１つ」（“ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ｘ，Ｙ ａｎｄ Ｚ”）のような条件付き言葉は、特別に記述された他のものがなければ、項目、用語等は、例えば、Ｘ，Ｙ又はＸのどれか、又はそれらの組合せであることを伝えるように一般的に使用される文脈として理解される。このような条件付き言葉は、特定の実施形態が、少なくともＸ、少なくともＹ、少なくともＺが、それぞれ存在することを、要求するということを暗示する意図ではない。

上記詳細な説明でいろいろな実施形態に適用される新規な機能を示し、記述し、指摘し、さらに、説明した装置やアルゴリズムの形式や詳細の中で、いろいろな省略、置き換え、変換が、開示の精神から逸脱することなく、できる。認識しえるように、ここで記述された発明の特定の実施形態は、ここで説明された機能や利益のすべてを提供しない形でも実施可能である。いくつかの機能は他のものと分離して使用され実行されるからである。ここで開示した特定の発明の範囲は、前述の記載よりむしろ、付加されたクレームにより示されている。クレームの等価性の意味や範囲内における変更は、この範囲内に包含される。

Claims (26)

1. プロセスを実行するモバイルコンピューティング装置に指示するプログラムであって、 前記プロセスは、
   前記モバイルコンピューティング装置上で実行可能な独立ブラウザに、アイデンティティ（ｉｄｅｎｔｉｔｙ）データベースと、前記ブラウザから受信した前記モバイルコンピューティング装置のユーザに関連する認証情報とを照合し、前記独立ブラウザにブラウザアクセス可能トークンを送信するよう構成された認証装置であって、シングルサインオン（ｓｉｎｇｌｅ‐ｓｉｇｎ‐ｏｎ：ＳＳＯ）サービスを提供するように構成され、前記シングルサインオンサービスは、認証の目的で、認証情報の代わりに、前記認証装置と、モバイルクライアントアプリケーション又は前記独立ブラウザの１つとの間での先の認証の結果である、先に生成された有効なブラウザアクセス可能トークンを受理することを含む、認証装置に関連するユニフォームリソースロケータ（ＵＲＬ）へのアクセスを、認証モジュールにより指示することと、
   前記認証モジュールにて、前記認証装置からの、前記モバイル装置のユーザを示し、前記モバイル装置の前記ユーザは前記認証装置により認証されているクライアントアプリケーションのアイデンティティを受信することと、
   前記クライアントアプリケーションのアイデンティティを復号するため前記認証装置とのネットワークコネクションを起動することと、
   前記クライアントアプリケーションのアイデンティティを、ネットワークベースのアプリケーションサービスへのアクセスの獲得に使用すること、
   を備えるプロセスである、プログラム。
2. 前記プロセスは、
   前記クライアントアプリケーションのアイデンティティを探すことと、
   ２回目において、前記ネットワークベースのサービスへのアクセスの獲得に前記クライアントアプリケーションのアイデンティティを使用すること、
   を更に備える前記プロセスである、請求項１に記載のプログラム。
3. 前記クライアントアプリケーションのアイデンティティは、ＵＲＬ検索ストリングパラメータとして受信したユーザｉｄ、暗号化されたＵＲＬ検索ストリングパラメータとして受信したユーザｉｄ、クッキー、又は、暗号化されたクッキーの１つを備える、請求項１に記載のプログラム。
4. 前記プロセスは、
   第２の認証モジュールにより、前記独立ブラウザに、前記認証装置に関連する前記ユニフォームリソースロケータへのアクセスを指示すること、
   を更に備えるプロセスである、請求項１に記載のプログラム。
5. 前記認証情報は、ユーザネーム、パスワード、及び、ＳＭＳメッセージの一部、静的ｐｉｎ、答に基づく情報、又はＵＳＢキーの１つを備える、請求項１に記載のプログラム。
6. 前記ブラウザアクセス可能なトークンは、前記ブラウザにより、ＨＴＭＬ４ ブラウザクッキースペース、ＨＴＭＬ５ ストレージスペース、アドビ フラッシュ スペース、アンドロイド ダルビック（Ｄａｌｖｉｋ）ストレージスペース、Ｊ２ＭＥ 管理コード スペース、ＮＥＴ モバイルコード スペース、又は、Ｎａｔｉｖｅ Ｘ．５０９ｖ３ 認証 ストレージスペースの１つに記憶される、請求項１に記載のプログラム。
7. 前記プロセスは、
   前記モバイル装置上で実行される前記独立ブラウザに、前記ブラウザアクセス可能トークンと前記クライアントアプリケーションのアイデンティティとの間の関連付けを取り除くよう構成された前記認証装置に関連する第２のユニフォームリソースロケータへのアクセスを指示すること、
   を更に備えるプロセスである、請求項１に記載のプログラム。
8. モバイル装置のユーザに、シングルサインオン（ｓｉｎｇｌｅ‐ｓｉｇｎ‐ｏｎ：ＳＳＯ）認証を提供するシステムであって、
   １つ以上のプロセッサと、
   コンピュータ読取り可能なメモリと、
   コンピュータ読取り可能なメモリに記憶された実行インストラクション（ｉｎｓｔｒｕｃｔｉｏｎ）を備える認証装置と、
   を備え、
   前記１つ以上のプロセッサは、少なくとも、
   前記モバイル装置上の独立ブラウザから、第１のモバイルアプリケーションに関連する第１のユニフォームリソースロケータ（ＵＲＬ）にアクセスする第１の要求を受信し、
   前記独立ブラウザから前記ユーザに関連する第１の認証情報を受信することと、
   前記第１の認証情報をアイデンティティデータベースと照合すること、
   により前記モバイル装置を使用するユーザを認証し、
   前記独立ブラウザに、ブラウザベーストークン（ｂｒｗｓｅｒ−ｂａｓｅｄ ｔｏｋｅｎ）と、前記独立ブラウザを介して送られた、前記第１のモバイルアプリケーションが使用する第１のクライアントアプリケーションのアイデンティティとを送信し、
   前記モバイル装置上の前記独立ブラウザから、第２のモバイルアプリケーションに関連する第２のユニフォームリソースロケータへのアクセスの第２の要求を受信し、
   前記ブラウザベーストークンの非取消を、前記アイデンティティデータベースと照合し、
   前記第２のモバイルアプリケーションが使用する第２のクライアントアプリケーションのアイデンティティを、前記独立ブラウザに送信し、
   前記独立ブラウザに、１つ以上のログインしているモバイルアプリケーションのログオフを起動するように構成されたユニフォームリソースロケータのリストを送信する、
   ようにプログラムされたプロセッサである、システム。
9. 前記第１のユニフォームリソースロケータ（ＵＲＬ）は、前記第２のユニフォームリソースロケータ（ＵＲＬ）と同一である、請求項８に記載のシステム。
10. 前記第１のモバイルアプリケーションと前記第２のモバイルアプリケーションは、同じモバイルアプリケーションである、請求項８に記載のシステム。
11. 前記第１のクライアントアプリケーションのアイデンティティは、ＵＲＬ検索ストリングパラメータとして受信したユーザｉｄ、暗号化されたＵＲＬ検索ストリングパラメータとして受信したユーザｉｄ、クッキー、又は、暗号化されたクッキーの１つを備える、請求項８に記載のシステム。
12. 前記第１の認証情報は、ユーザネーム、パスワード、及び、ＳＭＳメッセージの一部、答に基づく情報、静的ｐｉｎ、又はＵＳＢキーの１つを備える、請求項８に記載のシステム。
13. 前記１つ以上のプロセッサは、さらに、少なくとも、前記独立ブラウザから、第１の認証情報とは異なる第２の認証情報を受信するようにプロクラムされている、請求項８に記載のシステム。
14. モバイル装置上のクライアントアプリケーションのユーザに、シングルサインオン（ｓｉｎｇｌｅ‐ｓｉｇｎ‐ｏｎ：ＳＳＯ）認証を提供するコンピュータ実装された方法であって、前記方法は、
    モバイル装置上の独立ブラウザから、前記モバイル装置上で実行される第１のモバイルアプリケーションに関連する第１のユニフォームリソースロケータ（ＵＲＬ）にアクセスする第１の要求を受信することと、
    少なくとも、部分的に、前記独立ブラウザから前記ユーザに関連する第１の認証情報を受信し、前記第１の認証情報をアイデンティティデータベースと照合することにより、前記モバイル装置を使用するユーザを認証することと、
    前記独立ブラウザに、ブラウザベーストークン（ｂｒｗｓｅｒ−ｂａｓｅｄ ｔｏｋｅｎ）と、前記第１のモバイルアプリケーションが使用するための第１のクライアントアプリケーションのアイデンティティとを送信することと、
    前記モバイル装置上の前記独立ブラウザから、前記モバイル装置上で実行される第２のモバイルアプリケーションに関連する第２のユニフォームリソースロケータ（ＵＲＬ）にアクセスするため前記ブラウザベーストークンを有する第２の要求を受信することと、
    前記ブラウザベーストークンの非取消を、前記アイデンティティデータベースと照合することと、
    前記第２のモバイルアプリケーションが使用する第２のクライアントアプリケーションのアイデンティティを、前記独立ブラウザに送信することと、
    前記独立ブラウザに、１つ以上のログインしているモバイルアプリケーションのログオフを起動するように構成されたユニフォームリソースロケータのリストを送信すること、
    を備え、前記モバイル装置と分離したコンピュータシステムによって全体として実行さされる、方法。
15. 前記第１のユニフォームリソースロケータ（ＵＲＬ）は、前記第２のユニフォームリソースロケータ（ＵＲＬ）と同一である、請求項１４に記載の方法。
16. 前記第１のモバイルアプリケーションと前記第２のモバイルアプリケーションは、同じモバイルアプリケーションである、請求項１４に記載の方法。
17. 前記独立ブラウザに、前記第１のモバイルアプリケーションへのＵＲＬマッピングに関連する第３のユニフォームリソースロケータ（ＵＲＬ）を送信すること、を更に備える、請求項１４に記載の方法。
18. 前記第１のクライアントアプリケーションのアイデンティティは、ＵＲＬ検索ストリングパラメータとして受信したユーザｉｄ、暗号化されたＵＲＬ検索ストリングパラメータとして受信したユーザｉｄ、クッキー、又は、暗号化されたクッキーの１つを備える、請求項１４に記載の方法。
19. 前記第１の認証情報は、ユーザネーム、パスワード、及び、ＳＭＳメッセージの一部、答に基づく情報、静的ｐｉｎ、又はＵＳＢキーの１つを備える、請求項１４に記載の方法。
20. 少なくとも、前記独立ブラウザから、第１の認証情報とは異なる第２の認証情報を受信すること、を更に備える、請求項１４に記載の方法。
21. モバイル装置のユーザに、シングルサインオン（ｓｉｎｇｌｅ‐ｓｉｇｎ‐ｏｎ：ＳＳＯ）認証を提供するプロセスの実行を、コンピューティング装置に指示するプログラムであって、前記プロセスは、
    モバイル装置上の独立ブラウザから、モバイル装置上で実行される第１のモバイルアプリケーションに関連する第１のユニフォームリソースロケータ（ＵＲＬ）にアクセスする第１の要求を受信することと、
    前記独立ブラウザから前記ユーザに関連する第１の認証情報を受信することと、
    前記第１の認証情報をアイデンティティデータベースと照合すること、
    により前記モバイル装置を使用するユーザを認証することと、
    前記独立ブラウザに、ブラウザベーストークン（ｂｒｗｓｅｒ−ｂａｓｅｄ ｔｏｋｅｎ）と、前記第１のモバイルアプリケーションが使用するための第１のクライアントアプリケーションのアイデンティティとを送信することと、
    前記モバイル装置上の前記独立ブラウザから、前記モバイル装置上で実行される第２のモバイルアプリケーションに関連する第２のユニフォームリソースロケータ（ＵＲＬ）にアクセスするため前記ブラウザベーストークンを有する第２の要求を受信することと、
    前記ブラウザベーストークンの非取消を、前記アイデンティティデータベースと照合することと、
    前記第２のモバイルアプリケーションが使用する第２のクライアントアプリケーションのアイデンティティを、前記独立ブラウザに送信することと、
    前記独立ブラウザに、１つ以上のログインしているモバイルアプリケーションのログオフを起動するように構成されたユニフォームリソースロケータのリストを送信すること、
    を備えるプロセスである、プログラム。
22. 前記第１のユニフォームリソースロケータ（ＵＲＬ）は、前記第２のユニフォームリソースロケータ（ＵＲＬ）と同一である、請求項２１に記載のプログラム。
23. 前記第１のモバイルアプリケーションと前記第２のモバイルアプリケーションは、同じモバイルアプリケーションである、請求項２１に記載のプログラム。
24. 前記プロセスは、
    前記独立ブラウザに、前記第１のモバイルアプリケーションへのＵＲＬマッピングに関連する第３のユニフォームリソースロケータ（ＵＲＬ）を送信すること、
    を更に備えるプロセスである、請求項２１に記載のプログラム。
25. 前記第１のクライアントアプリケーションのアイデンティティは、ＵＲＬ検索ストリングパラメータとして受信したユーザｉｄ、暗号化されたＵＲＬ検索ストリングパラメータとして受信したユーザｉｄ、クッキー、又は、暗号化されたクッキーの１つを備える、請求項２１に記載のプログラム。
26. 前記第１の認証情報は、ユーザネーム、パスワード、及び、ＳＭＳメッセージの一部、答に基づく情報、静的ｐｉｎ、又はＵＳＢキーの１つを備える、請求項２１に記載のプログラム。

Images