JP2023166686A - 情報処理装置、情報処理システム、情報処理方法及び情報処理プログラム - Google Patents

Abstract

【課題】利用者の利便性を向上させる情報処理装置、情報処理システム、情報処理方法及び情報処理プログラムを提供する。
【解決手段】情報処理システム１において、データ格納部１０３は、ＵＲＬ切替フラグ１３１、旧ＵＲＬ１３２及び新ＵＲＬ１３３を記憶する。認証要求部１０１は、ＵＲＬ切替フラグ１３１の値が第１情報の場合、旧ＵＲＬ１３２を用いて認証サーバー２０１への接続を実行し、旧ＵＲＬ１３２を用いた認証サーバー２０１への接続が失敗した場合、新ＵＲＬ１３３を用いて認証サーバー２１１への接続を実行し、ＵＲＬ切替フラグ１３１の値が第２情報の場合、新ＵＲＬ１３３を用いて認証サーバー２１１への接続を実行する。フラグ管理部１０２は、ＵＲＬ切替フラグの初期値を第１情報と設定し、認証要求部１０１による新ＵＲＬ１３３を用いた認証サーバー２１１への接続が成功した場合、ＵＲＬ切替フラグ１３１を第２情報に切り替える。
【選択図】図２

Description

本発明は、情報処理装置、情報処理システム、情報処理方法及び情報処理プログラムに関する。

クラウドサーバーで動作する認証サーバー及びアプリケーションサーバーと、クライアントＰＣ（Personal Computer）で動作するクライアントアプリケーションとにより構成されるクラウドソリューションがある。認証サーバーで利用される認証の仕組みとして、例えば、OAuth 2.0やOpenID Connect（登録商標）を用いることができる。

ここで、認証サーバーを用いたクラウドソリューションの動作の一例を簡単に説明する。クライアントアプリケーションは、認証サーバーに対して認証要求を送信する。認証サーバーは、認証要求を受信すると保持する各ユーザーのアカウント情報を用いて認証を行ない、認証に成功するとアクセストークンをクライアントアプリケーションへ送信する。クライアントアプリケーションは、認証サーバーから受領したアクセストークンを、クラウド上のアプリケーションサーバーに対して処理要求とともに送信する。

一般に、アクセストークンの有効期限は３０分から１時間程度とされており、有効期限を過ぎると、クライアントアプリケーションは必要に応じて認証要求を行い、アクセストークンを再取得する。クライアントアプリケーションによる認証要求の送信には以下の２種類が存在する。

１つは、認証サーバーへのログインである。具体的には、クライアントアプリケーションは、ユーザー操作により入力されたログインＩＤ（Identifier）及びパスワードを取得して認証サーバーへ送信してログインすることで認証要求を行なう。認証が成功した場合、クライアントアプリケーションは、アクセストークンの他にリフレッシュトークンを取得することができる。

他の１つは、認証サーバーへのリフレッシュトークンの送信である。具体的には、クライアントアプリケーションは、ログイン時に認証サーバーから得られるリフレッシュトークンを認証サーバーへ送信することで認証要求を行なう。クライアントアプリケーションは、送信したリフレッシュトークンに対する応答として新たなアクセストークンを取得することができる。

アプリケーションサーバーは、クライアントアプリケーションから送信されたアクセストークンを受信する。そして、アプリケーションサーバーは、受信したアクセストークンの正当性を認証サーバーに問い合わせる。その後、認証サーバーにより正当性が認められた場合に、アプリケーションサーバーは、クライアントアプリケーションからの処理要求を受け入れる。

クライアントアプリケーションは、認証サーバー及びアプリケーションサーバーのＵＲＬ（Uniform Resource Locator）を内部に保持することで通信相手とするサーバーを特定する。ここで、クライアントアプリケーションが動作するクライアントＰＣは、スマートフォンなどの携帯端末装置も含む。

なお、認証サーバーを利用する技術として、従来、認証サーバーを別の認証サーバーに変更した場合に、サービスの停止中に、ユーザーに再度認可操作を求めることなく旧認可情報を新たな認可情報に自動更新させる技術が提案されている。また、認証サーバーの変更の予定時期が決定している場合に、アクセストークンの有効期限を、遅くとも変更の予定時期に満了するように設定し、変更時期が近付くと新たな認証サーバーのＵＲＬをクライアントに通知する技術が提案されている。

特開２０１６－２２４６８４号公報 特開２０２０－１７７５３７号公報

しかしながら、認証サーバーのＵＲＬが変更され、旧ＵＲＬを用いたアクセスができなくなる状況となる場合がある。ここでは、新ＵＲＬを有する認証サーバーが、旧ＵＲＬを有する認証サーバーにより発行されたユーザーＩＤやパスワードなどのアカウント情報を引き継ぎ、引き継いだアカウント情報を用いて認証を行なうことができる場合を想定する。この状況では、旧ＵＲＬを用いて認証サーバーに接続していたクライアントアプリケーションは、新ＵＲＬを保持していないため、新ＵＲＬを有する認証サーバーと通信を行うことが困難となり、利用者の利便性が低下するおそれがある。

開示の技術は、上記に鑑みてなされたものであって、利用者の利便性を向上させる情報処理装置、情報処理システム、情報処理方法及び情報処理プログラムを提供することを目的とする。

本願の開示する情報処理装置、情報処理システム、情報処理方法及び情報処理プログラムの一つの態様において、データ格納部は、接続先切替情報、第１接続先情報及び第２接続先情報を格納する。認証要求部は、前記接続先切替情報の値が第１情報の場合、前記第１接続先情報を用いて第１認証装置への接続を実行し、前記第１接続先情報を用いた前記第１認証装置への接続が失敗した場合、前記第２接続先情報を用いて第２認証装置への接続を実行し、前記接続先切替情報の値が第２情報の場合、前記第２接続先情報を用いて前記第２認証装置への接続を実行する。接続先管理部は、前記接続先切替情報の初期値を前記第１情報と設定し、前記認証要求部による前記第２接続先情報を用いた前記第２認証装置への接続が成功した場合、前記データ格納部に格納された前記接続先切替情報を前記第２情報に更新する。

１つの側面では、本発明は、利用者の利便性を向上させることができる。

図１は、実施例に係る認証サーバーを用いた情報処理システムの概略構成図である。 図２は、実施例１に係るクライアントＰＣのブロック図である。 図３は、実施例１に係るクライアントアプリケーションによる認証要求処理のフローチャートである。 図４は、サーバー切替前の情報処理システムの動作を示す図である。 図５は、サーバー切替後の最初の認証時の情報処理システムの動作を示す図である。 図６は、サーバー切替後の２回目以降の認証時の情報処理システムの動作を示す図である。 図７は、実施例２に係るクライアントＰＣのブロック図である。 図８は、実施例３に係るクライアントＰＣのブロック図である。 図９は、実施例３に係るクライアントアプリケーションによる認証要求処理のフローチャートである。 図１０は、コンピューターのハードウェア構成図である。

以下に、本願の開示する情報処理装置、情報処理システム、情報処理方法及び情報処理プログラムの実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する情報処理装置、情報処理システム、情報処理方法及び情報処理プログラムが限定されるものではない。

図１は、実施例に係る認証サーバーを用いた情報処理システムの概略構成図である。本実施例に係る情報処理システム１は、クラウドソリューションを提供する。情報処理システム１は、図１に示すように、クライアントＰＣ１０及びクラウドサーバー２０を有する。本実施例では、情報処理システム１において、クラウドサーバー２０における認証サーバー２０１及びアプリケーションサーバー２０２が、認証サーバー２１１及びアプリケーションサーバー２１２に変更される場合について説明する。以下の説明では、クライアントＰＣ１０を操作してクラウドソリューションを利用する操作者をユーザーと呼ぶ。

サーバー切替前は、図１の紙面に向かって上段に示すように、情報処理システム１は、認証サーバー２０１、アプリケーションサーバー２０２及びアカウント情報２２０を有する。ここで、点線で示した認証サーバー２１１及びアプリケーションサーバー２１２は、この状態ではまだ存在しない。

アカウント情報２２０は、認証サーバー２０１又は２１１を用いたクラウドソリューションを利用するユーザーのユーザーＩＤやパスワードを含む認証情報が登録される。アカウント情報２２０は、認証サーバー２０１及び２１１のいずれからも使用される。

認証サーバー２０１は、自己のＵＲＬによりクライアントＰＣ１０で動作するクライアントアプリケーション１００からのアクセスを受ける。そして、認証サーバー２０１は、ユーザーＩＤ及びパスワードを用いたログインによる認証要求をクライアントアプリケーション１００から受ける。次に、認証サーバー２０１は、クライアントアプリケーション１００からの認証要求を受けて、アカウント情報２２０を用いて認証を行ない、認証結果として得られるアクセストークンをクライアントアプリケーション１００へ送信する。この際、認証サーバー２０１は、認証サーバー２０１とアプリケーションサーバー２０２とを結ぶ経路であるトークンバリデーションを用いてアクセストークンを送信する。また、認証サーバー２０１は、アプリケーションサーバー２０２からのアクセストークンの確認を受けて、確認結果を返す。以下の説明では、認証サーバー２０１のＵＲＬを、「旧ＵＲＬ」と呼ぶ。

アプリケーションサーバー２０２は、アクセストークンとともに処理要求をクライアントＰＣ１０から受信する。そして、アプリケーションサーバー２０２は、トークンバリデーションを用いてアクセストークンを認証サーバー２０１に送信して、アクセストークンの確認を要求する。アクセストークンの確認が成功すると、アプリケーションサーバー２０２は、アクセストークンの確認成功の通知を示す確認結果を認証サーバー２０１から受信する。そして、アプリケーションサーバー２０２は、処理要求で要求された処理を実行する。

クライアントＰＣ１０は、クライアントアプリケーション１００が動作する。クライアントアプリケーション１００は、認証サーバー２０１又は２１１を用いたクラウドソリューションを利用するための専用アプリケーションである。そのため、一般的なＷｅｂブラウザなどとは異なり、クライアントアプリケーション１００は、リダイレクトによる接続先の切り替えを行うためには作り込みが必要となり、そのような切り替え方法の実現が困難である。

クライアントアプリケーション１００は、サーバー切替前は、旧ＵＲＬを用いてインターネットを介して認証サーバー２０１にアクセスして、認証要求を行ない、アクセストークンを取得する。その後、クライアントアプリケーション１００は、取得したアクセストークンを用いてアプリケーションサーバー２０２に対して処理要求を行なう。

また、サーバー切替後は、図１の紙面に向かって下段に示すように、情報処理システム１は、認証サーバー２１１、アプリケーションサーバー２１２及びアカウント情報２２０を有する。ここで、点線で記載した認証サーバー２０１及びアプリケーションサーバー２０２は、この時点では削除されており存在しない。

認証サーバー２１１は、旧ＵＲＬとは異なる自己のＵＲＬによりクライアントＰＣ１０で動作するクライアントアプリケーション１００からのアクセスを受ける。そして、認証サーバー２１１は、クライアントアプリケーション１００からのログインによる認証要求を受けて、アカウント情報２２０を用いて認証を行ない、認証結果として得られるアクセストークンをクライアントアプリケーション１００へ送信する。また、認証サーバー２１１は、アプリケーションサーバー２１２からのアクセストークンの確認を受けて、認証サーバー２１１とアプリケーションサーバー２１２とを結ぶ経路であるトークンバリデーションを用いて検証結果を返す。以下の説明では、認証サーバー２１１のＵＲＬを、「新ＵＲＬ」と呼ぶ。

アプリケーションサーバー２１２は、アクセストークンとともに処理要求をクライアントＰＣ１０から受ける。そして、アプリケーションサーバー２１２は、トークンバリデーションを用いてアクセストークンを認証サーバー２１１に送信して、アクセストークンの確認を要求する。アクセストークンの確認が成功すると、アプリケーションサーバー２１２は、アクセストークンの確認成功の通知を示す確認結果を認証サーバー２１１から受信する。そして、アプリケーションサーバー２１２は、処理要求で要求された処理を実行する。

クライアントアプリケーション１００は、サーバー切替後は、認証サーバー２０１が存在しないため、旧ＵＲＬを用いて認証サーバー２０１にアクセスすることはできない。そこで、クライアントアプリケーション１００は、新ＵＲＬを用いてインターネットを介して認証サーバー２１１にアクセスして、認証要求を送信してアクセストークンを取得する。その後、クライアントアプリケーション１００は、取得したアクセストークンを用いてアプリケーションサーバー２１２に対して要求を行なう。

図２は、実施例１に係るクライアントＰＣのブロック図である。ここで、図２では、アカウント情報２２０を省略したが、実際には、認証時には認証サーバー２０１及び２１１は、アカウント情報２２０を用いて認証を行なう。また、図２では、認証サーバー２０１及び２１１、並びに、アプリケーションサーバー２０２及び２１２を全て記載した。ただし、実際には、サーバー切替前には認証サーバー２１１及びアプリケーションサーバー２１２は存在せず、サーバー切替後には認証サーバー２０１及びアプリケーションサーバー２０２は存在しない。以下に、図２を参照して、クライアントアプリケーション１００の動作について詳細に説明する。

クライアントＰＣ１０は、図２に示すように、認証要求部１０１、フラグ管理部１０２、データ格納部１０３及び処理要求部１０４を有する。認証要求部１０１、フラグ管理部１０２、データ格納部１０３及び処理要求部１０４は、クライアントアプリケーション１００により実現される。

データ格納部１０３は、不揮発性の記憶装置である。データ格納部１０３は、ＵＲＬ切替フラグ１３１、旧ＵＲＬ１３２及び新ＵＲＬ１３３を記憶する。また、データ格納部１０３は、認証要求部１０１が取得したアクセストークン１３４を格納する。

すなわち、データ格納部１０３は、接続先切替情報であるＵＲＬ切替フラグ１３１、第２接続先情報である旧ＵＲＬ１３２及び第２接続先情報である新ＵＲＬ１３３を格納する。

ＵＲＬ切替フラグ１３１は、データ格納部１０３に格納された不揮発性データである。ＵＲＬ切替フラグ１３１は、認証サーバー２０１から認証サーバー２１１へのサーバー切替が行われたか否かを示す値を保持する。具体的には、ＵＲＬ切替フラグ１３１は、値が「切替前」の場合、サーバー切替が行われる前の状態であることを表す。また、ＵＲＬ切替フラグ１３１は、値が「切替後」の場合、サーバー切替が行われた後の状態であることを表す。ＵＲＬ切替フラグ１３１は、初期値として「切替前」が設定される。

旧ＵＲＬ１３２は、サーバー切替前に存在し且つサーバー切替後には存在しなくなる認証サーバー２０１のＵＲＬの情報である。新ＵＲＬ１３３は、サーバー切替前には存在せずサーバー切替後に存在する認証サーバー２１１のＵＲＬの情報である。旧ＵＲＬ１３２及び新ＵＲＬ１３３はいずれも、サーバー切替が実行される１～２週間から数日前といった直前期にデータ格納部１０３に格納される。例えば、新ＵＲＬ１３３は、サーバー切替の予定日が決定した場合に、その予定日の２週間程度前に配布される。ここで、クライアントアプリケーション１００に新ＵＲＬ１３３を常に保持させることも考えられるが、その場合、新ＵＲＬ１３３の流出や悪意のある者からの書き換えといったセキュリティ上の危険がある。そのため、新ＵＲＬ１３３は、サーバー切替の予定日に近づいてから、クライアントアプリケーション１００に配布されることが好ましい。

認証要求部１０１は、クラウドソリューション利用の指示をクライアントアプリケーション１００がユーザーから受けると、認証要求処理を開始する。認証要求部１０１は、データ格納部１０３にアクセスし、格納されたＵＲＬ切替フラグ１３１を確認する。

ＵＲＬ切替フラグ１３１の値が、「切替前」の場合、認証要求部１０１は、旧ＵＲＬ１３２をデータ格納部１０３から取得する。そして、認証要求部１０１は、取得した旧ＵＲＬ１３２を用いて認証サーバー２０１にアクセスし、ユーザーのユーザーＩＤ及びパスワードを用いて認証サーバー２０１へのログインによる認証要求を行なう。そして、認証要求部１０１は、旧ＵＲＬ１３２を用いた認証サーバー２０１へのアクセスの成功又は失敗を判定する。

ここで、認証要求部１０１は、アクセスの成功又は失敗を認証サーバー２０１への認証用要求に対する応答により判定する。認証要求部１０１は、認証結果が成功でありアクセストークン１３４が得られた場合及び所定のエラーが応答として返ってきた場合にアクセス成功と判定する。所定のエラーとは、例えば、アカウント認証エラーやパスワード有効期限切れなどの所定の認証エラー、及び、２００番台や４００番台のＨＴＴＰエラーコードといった所定のエラーコードである。逆に、認証要求部１０１は、所定のエラー以外のエラー、例えば、５００番台のＨＴＴＰエラーコードが返ってきた場合にアクセス失敗と判定する。

アクセスが成功し認証サーバー２０１による認証が成功すると、認証要求部１０１は、認証結果としてアクセストークン１３４を認証サーバー２０１から取得する。次に、認証要求部１０１は、アクセストークン１３４をデータ格納部１０３に格納する。また、認証要求部１０１は、認証サーバー２０１による認証完了を処理要求部１０４に通知する。

また、アクセスは成功したが認証サーバー２０１による認証が失敗した場合、認証要求部１０１は、認証失敗のメッセージをモニタに出力するなどしてユーザーに認証の失敗を通知する。

これに対して、アクセスが失敗した場合、認証要求部１０１は、新ＵＲＬ１３３をデータ格納部１０３から取得する。次に、認証要求部１０１は、取得した新ＵＲＬ１３３を用いて認証サーバー２１１にアクセスし、ユーザーのユーザーＩＤ及びパスワードを用いてログインによる認証要求を行なう。そして、認証要求部１０１は、新ＵＲＬ１３３を用いた認証サーバー２１１へのアクセスの成功又は失敗を判定する。

アクセスが成功し認証サーバー２１１による認証が成功すると、認証要求部１０１は、認証結果としてアクセストークン１３４を認証サーバー２１１から取得する。次に、認証要求部１０１は、アクセストークン１３４をデータ格納部１０３に格納する。また、認証要求部１０１は、認証サーバー２１１による認証完了を処理要求部１０４に通知する。さらに、認証要求部１０１は、ＵＲＬ切替フラグ１３１の変更をフラグ管理部１０２に指示する。

また、アクセスは成功したが認証サーバー２１１による認証が失敗した場合、認証要求部１０１は、認証失敗のメッセージをモニタに出力するなどしてユーザーに認証の失敗を通知する。

これに対して、アクセスが失敗した場合、認証要求部１０１は、データ格納部１０３に格納されたＵＲＬ切替フラグ１３１の値を「切替前」のまま維持させる。そして、認証要求部１０１は、アクセス不可のメッセージをモニタに表示させてユーザーにアクセス不可を通知する。

一方、ＵＲＬ切替フラグ１３１の値が「切替後」の場合、認証要求部１０１は、最初から新ＵＲＬ１３３をデータ格納部１０３から取得する。次に、認証要求部１０１は、取得した新ＵＲＬ１３３を用いて認証サーバー２１１にアクセスし、ユーザーのユーザーＩＤ及びパスワードを用いてログインによる認証要求を行なう。そして、認証要求部１０１は、新ＵＲＬ１３３を用いた認証サーバー２１１へのアクセスの成功又は失敗を判定する。認証要求部１０１は、このアクセスの成否の判定を、旧ＵＲＬ１３２を用いた認証サーバー２０１へのアクセスの場合と同様に実行する。

アクセスが成功し認証サーバー２１１による認証が成功すると、認証要求部１０１は、認証結果としてアクセストークン１３４を認証サーバー２１１から取得する。次に、認証要求部１０１は、アクセストークン１３４をデータ格納部１０３に格納する。また、認証要求部１０１は、認証サーバー２１１による認証完了を処理要求部１０４に通知する。

また、アクセスは成功したが認証サーバー２１１による認証が失敗した場合、認証要求部１０１は、認証失敗のメッセージをモニタに出力するなどしてユーザーに認証の失敗を通知する。

これに対して、アクセスが失敗した場合、認証要求部１０１は、データ格納部１０３に格納されたＵＲＬ切替フラグ１３１の値を「切替後」のまま維持させる。そして、認証要求部１０１は、アクセス不可のメッセージをモニタに表示させてユーザーにアクセス不可を通知する。

ここで、ＵＲＬ切替フラグ１３１が「接続先切替情報」の一例にあたり、「切替前」を示す値が「第１情報」の一例にあたり、「切替後」を示す値が「第２情報」の一例にあたる。また、認証サーバー２０１が「第１認証装置」の一例にあたり、認証サーバー２１１が「第２認証装置」の一例にあたる。また、旧ＵＲＬ１３２が「第１接続先情報」の一例にあたり、新ＵＲＬ１３３が「第２接続先情報」の一例にあたる。すなわち、認証要求部１０１は、接続先切替情報が第１情報の場合、第１接続先情報を用いて第１認証装置への接続を実行する。そして、認証要求部１０１は、第１接続先情報を用いた第１認証装置への接続が失敗した場合、第２接続先情報を用いて第２認証装置への接続を実行する。また、認証要求部１０１は、接続先切替情報の値が第２情報の場合、第２接続先情報を用いて第２認証装置への接続を実行する。

フラグ管理部１０２は、データ格納部１０３に格納されたＵＲＬ切替フラグ１３１を管理する。フラグ管理部１０２は、ＵＲＬ切替フラグ１３１の初期値を「切替前」に設定する。そして、フラグ管理部１０２は、ＵＲＬ切替フラグ１３１の変更の指示を認証要求部１０１から受けると、ＵＲＬ切替フラグ１３１の値を「切替後」に設定する。その後、フラグ管理部１０２は、ＵＲＬ切替フラグ１３１の値を「切替後」に維持する。

このフラグ管理部１０２が、「接続先管理部」の一例にあたる。そして、フラグ管理部１０２は、接続先切替情報の初期値を第１情報と設定し、認証要求部１０１による第２接続先情報を用いた第２認証装置への接続が成功した場合、データ格納部１０３に格納された接続先切替情報を第２情報に更新する。

処理要求部１０４は、認証を行なった認証サーバー２０１又は２１１の情報とともに、認証完了の通知を認証要求部１０１から受ける。その後、処理要求部１０４は、ユーザーから処理要求実行の指示を受けると、アクセストークン１３４をデータ格納部１０３から取得する。

そして、認証が認証サーバー２０１により実行された場合には、処理要求部１０４は、アプリケーションサーバー２０２に対して処理要求を送信する。その後、処理要求部１０４は、処理結果を示す応答をアプリケーションサーバー２０２から受ける。

また、認証が認証サーバー２１１により実行された場合には、処理要求部１０４は、アプリケーションサーバー２１２に対して処理要求を送信する。その後、処理要求部１０４は、処理結果を示す応答をアプリケーションサーバー２１２から受ける。

図３は、実施例１に係るクライアントアプリケーションによる認証要求処理のフローチャートである。次に、図３を参照して、本実施例に係るクライアントアプリケーション１００による認証要求処理の流れを説明する。

認証要求部１０１は、データ格納部１０３にアクセスし、格納されたＵＲＬ切替フラグ１３１を確認する（ステップＳ１）。

そして、認証要求部１０１は、ＵＲＬ切替フラグ１３１の値が「切替前」か否かを判定する（ステップＳ２）。

ＵＲＬ切替フラグ１３１の値が「切替前」の場合（ステップ２：肯定）、認証要求部１０１は、旧ＵＲＬ１３２をデータ格納部１０３から取得する。そして、認証要求部１０１は、旧ＵＲＬ１３２を用いて認証サーバー２０１にアクセスして、ユーザーＩＤ及びパスワードを用いてログインによる認証要求を行なう（ステップＳ３）。

その後、認証要求部１０１は、認証要求に対する応答により旧ＵＲＬ１３２を用いた認証サーバー２０１へのアクセスが成功したか否かを判定する（ステップＳ４）。旧ＵＲＬ１３２を用いたアクセスが成功した場合（ステップＳ４：肯定）、認証要求部１０１は、取得した応答に応じた処理を行って認証要求処理を終了する。

これに対して、旧ＵＲＬ１３２を用いたアクセスが失敗した場合（ステップＳ４：否定）、認証要求部１０１は、新ＵＲＬ１３３をデータ格納部１０３から取得する。そして、認証要求部１０１は、新ＵＲＬ１３３を用いて認証サーバー２１１にアクセスして、ユーザーＩＤ及びパスワードを用いてログインによる認証要求を行なう（ステップＳ５）。

その後、認証要求部１０１は、認証要求に対する応答により新ＵＲＬ１３３を用いた認証サーバー２１１へのアクセスが成功したか否かを判定する（ステップＳ６）。新ＵＲＬ１３３を用いたアクセスが失敗した場合（ステップＳ６：否定）、認証要求部１０１は、アクセス不可を通知して認証要求処理を終了する。

これに対して、新ＵＲＬ１３３を用いたアクセスが成功した場合（ステップＳ６：肯定）、認証要求部１０１は、ＵＲＬ切替フラグ１３１の変更をフラグ管理部１０２に指示する。フラグ管理部１０２は、指示を受けてＵＲＬ切替フラグ１３１の値を「切替後」に変更する（ステップＳ７）。その後、認証要求部１０１は、取得した応答に応じた処理を行って認証要求処理を終了する。

一方、ＵＲＬ切替フラグ１３１の値が「切替後」の場合、認証要求部１０１は、新ＵＲＬ１３３をデータ格納部１０３から取得する。そして、認証要求部１０１は、新ＵＲＬ１３３を用いて認証サーバー２０１にアクセスして、ユーザーＩＤ及びパスワードを用いてログインによる認証要求を行なう（ステップＳ８）。その後、認証要求部１０１は、取得した応答に応じた処理を行って認証処理を終了する。

次に、図４～６を用いて、本実施例に係る認証を含むクラウドソリューションを提供する情報処理システム１の全体の流れを再度まとめて説明する。図４は、サーバー切替前の情報処理システムの動作を示す図である。図５は、サーバー切替後の最初の認証時の情報処理システムの動作を示す図である。図６は、サーバー切替後の２回目以降の認証時の情報処理システムの動作を示す図である。

サーバー切替前には、ＵＲＬ切替フラグ１３１は、初期値の「切替前」である。そこで、図４に示すように、クライアントアプリケーション１００は、旧ＵＲＬ１３２を用いて認証サーバー２０１にアクセスし、ユーザーＩＤ及びパスワードを用いたログインによる認証要求を行なう（ステップＳ１０１）。この場合、認証サーバー２０１が存在するため、クライアントアプリケーション１００は、旧ＵＲＬ１３２を用いたアクセスに成功する。

認証サーバー２０１は、受信したユーザーＩＤ及びパスワードとアカウント情報２２０とを用いて認証を行なう。認証が成功すると、認証サーバー２０１は、アクセストークン１３４をクライアントアプリケーション１００へ送信する（ステップＳ１０２）。

クライアントアプリケーション１００は、認証サーバー２０１から受信したアクセストークン１３４とともに処理要求をアプリケーションサーバー２０２に対して送信する（ステップＳ１０３）。その後、アプリケーションサーバー２０２は、トークンバリデーションを用いてアクセストークン１３４の確認を認証サーバー２０１に依頼する。アクセストークン１３４の確認成功の通知を受けて、アプリケーションサーバー２０１は、要求された処理を実行する。

サーバー切替後の最初の認証時には、ＵＲＬ切替フラグ１３１は、初期値の「切替前」のままである。そのため、図５に示すように、クライアントアプリケーション１００は、旧ＵＲＬ１３２を用いて認証サーバー２０１にアクセスし、ユーザーＩＤ及びパスワードを用いたログインによる認証要求を行なう（ステップＳ２０１）。しかし、サーバー切替が行われて認証サーバー２０１が存在しないため、クライアントアプリケーション１００は、アクセスに失敗する。

次に、クライアントアプリケーション１００は、新ＵＲＬ１３３を用いて認証サーバー２１１にアクセスし、ユーザーＩＤ及びパスワードを用いたログインによる認証要求を行なう（ステップＳ２０２）。この場合、サーバー切替が行われて認証サーバー２１１が存在するため、クライアントアプリケーション１００は、新ＵＲＬ１３３を用いたアクセスに成功する。この時点で、クライアントアプリケーション１００は、ＵＲＬ切替フラグ１３１の値を、「切替後」に変更する。

認証サーバー２１１は、受信したユーザーＩＤ及びパスワードとアカウント情報２２０とを用いて認証を行なう。認証が成功すると、認証サーバー２１１は、アクセストークン１３４をクライアントアプリケーション１００へ送信する（ステップＳ２０３）。

クライアントアプリケーション１００は、認証サーバー２１１から受信したアクセストークン１３４とともに処理要求をアプリケーションサーバー２１２に対して送信する（ステップＳ２０４）。その後、アプリケーションサーバー２１２は、トークンバリデーションを用いてアクセストークン１３４の確認を認証サーバー２１１に依頼する。アクセストークン１３４の確認成功の通知を受けて、アプリケーションサーバー２１２は、要求された処理を実行する。

サーバー切替後の２回目以降の認証時には、ＵＲＬ切替フラグ１３１の値は、「切替後」である。そこで、図６に示すように、クライアントアプリケーション１００は、新ＵＲＬ１３３を用いて認証サーバー２１１にアクセスし、ユーザーＩＤ及びパスワードを用いたログインによる認証要求を行なう（ステップＳ３０１）。この場合、認証サーバー２１１が存在するため、クライアントアプリケーション１００は、新ＵＲＬ１３３を用いたアクセスに成功する。

認証サーバー２１１は、受信したユーザーＩＤ及びパスワードとアカウント情報２２０とを用いて認証を行なう。認証が成功すると、認証サーバー２１１は、アクセストークン１３４をクライアントアプリケーション１００へ送信する（ステップＳ３０２）。

クライアントアプリケーション１００は、認証サーバー２１１から受信したアクセストークン１３４とともに処理要求をアプリケーションサーバー２１２に対して送信する（ステップＳ３０３）。その後、アプリケーションサーバー２１２は、トークンバリデーションを用いてアクセストークン１３４の確認を認証サーバー２１１に依頼する。アクセストークン１３４の確認成功の通知を受けて、アプリケーションサーバー２１２は、要求された処理を実行する。

ここで、本実施例では、認証サーバー２０１及びアプリケーションサーバー２０２の双方を認証サーバー２１１及びアプリケーションサーバー２１２へ切り替える場合で説明した。ただし、これに限らず、認証サーバー２０１を認証サーバー２１１に切り替え、アプリケーションサーバー２０２をそのままで使用する構成でも、クライアントアプリケーション１００は、同様の認証処理により認証サーバー２０１又は２０２に認証を行なわせることができる。

以上に説明したように、本実施例に係る認証サーバーを用いたクラウドソリューションを提供する情報処理システムでは、クライアントアプリケーションは、サーバー切替のタイミングで、ＵＲＬ切替フラグ、旧ＵＲＬ及び新ＵＲＬを保持する。そして、クライアントアプリケーションは、ＵＲＬ切替フラグが「切替前」であれば、旧ＵＲＬを用いた認証サーバーへのアクセスを行い、アクセスに成功すればそのまま旧ＵＲＬで示される認証サーバーを利用する。これに対して、旧ＵＲＬを用いたアクセスに失敗すると、クライアントアプリケーションは、新ＵＲＬを用いた認証サーバーへのアクセスを行い、新ＵＲＬを用いたアクセスに成功すると、ＵＲＬ切替フラグの値を「切替後」に変更する。そして、クライアントアプリケーションは、新ＵＲＬで示される認証サーバーを利用する。また、クライアントアプリケーションは、ＵＲＬ切替フラグが「切替後」であれば、新ＵＲＬを用いた認証サーバーへのアクセスを行い、新ＵＲＬで示される認証サーバーを利用する。

これにより、本実施例に係るクライアントアプリケーションは、サーバー切替が行われ旧ＵＲＬで示される認証サーバーがなくなった場合にも、新ＵＲＬを用いて切替後の認証サーバーへアクセスすることができる。したがって、シームレスな認証サーバーの切り替えが可能となる。また、２回目以降の認証では、クライアントアプリケーションが旧ＵＲＬを用いることなく新ＵＲＬを用いて切替後の認証サーバーに直接アクセスするので、存在しない認証サーバーへのアクセスを行うことなく迅速に認証サーバーへアクセスすることが可能となる。したがって、サーバー切替により認証サーバーへのユーザーのアクセスが滞ることが無くなり、ユーザーの利便性を向上させることが可能となる。

なお、旧ＵＲＬから新ＵＲＬへの切り替えの技術として、クライアントＰＣに予め新旧２つのＵＲＬを持たせ、どちらか接続可能であった方のサーバーと通信を行わせるという方法が考えられる。しかしこの方法では、最初に通信を試みたサーバーとの通信が失敗する状況では、通信するたびに再試行を行うため、クライアントからサーバーへの通信が遅くなるという問題がある。特に、認証サーバーを用いたクラウドソリューションでは、アクセス先となるＵＲＬの書き換えをユーザーに禁止している場合が多いため、上述した問題が発生し易い。これに対して、本実施例に係るクライアントアプリケーションは、１度新ＵＲＬへのアクセスが成功すると、次からは直接新ＵＲＬへアクセスするため、クライアントからサーバーへの通信が遅くなるという問題を回避することができる。

また、認証サーバーの変更時に旧認可情報を新たな認可情報に自動更新させる従来技術では、サービス稼働中の認証サーバーのＵＲＬ変更は考慮されておらず、ユーザーの利便性を向上させることは困難である。また、認証サーバーの変更時期が近付くと新たな認証サーバーのＵＲＬをクライアントに通知する技術は、複数の認証サーバーの存在を前提としており、新たな認証サーバーは既に存在する認証サーバーのいずれかである。そのため、新旧いずれか１台の認証サーバーが稼働する場合には、この技術を用いても変更時期を過ぎると旧ＵＲＬを有する認証サーバーにはアクセス不可となり、認証サーバーを変更することが困難となる。したがって、この技術を用いても利用者の利便性を向上させることは困難である。これに対して、本実施例に係るクライアントアプリケーションは、１台の認証サーバーが他の認証サーバーに切り替えられる場合にも、旧ＵＲＬにアクセスせずに直接新ＵＲＬに接続するように自動的に変更することができ、利用者の利便性を向上させることが可能である。

図７は、実施例２に係るクライアントＰＣのブロック図である。本実施例に係るクライアントＰＣ１０は、クライアントアプリケーション１００の他に、アプリケーション１１１及び１１２を有する。アプリケーション１１１及び１１２は、例えば、それぞれクラウドサーバー２０を利用して業務を行うアプリケーションである。

本実施例に係るクライアントアプリケーション１００は、認証サーバー２０１及び２１１、並びに、アプリケーションサーバー２０２及び２１２へのアクセスを担当する。アプリケーション１１１及び１１２は、クライアントアプリケーション１００との間でプロセス間通信を行い、クライアントアプリケーション１００を介して認証サーバー２０１及び２１１、並びに、アプリケーションサーバー２０２及び２１２にアクセスする。以下に、クライアントアプリケーション１００を介したに認証サーバー２０１及び２１１、並びに、アプリケーションサーバー２０２及び２１２との通信について説明する。以下の説明では、実施例１と同様の各部の動作については説明を省略する場合がある。

アプリケーション１１１は、業務の実行中にクラウドサーバー２０に実行させる処理要求をユーザーの情報とともにクライアントアプリケーション１００にプロセス間通信を用いて送信する。その後、アプリケーション１１１は、処理要求に対する応答をクライアントアプリケーション１００からプロセス間通信を用いて受信する。そして、アプリケーション１１１は、受信した応答に基づいて業務を継続する。アプリケーション１１２も同様に、以上の動作を実行する。このアプリケーション１１１及び１１２が、「業務実行部」の一例にあたる。

本実施例に係るクライアントアプリケーション１００は、認証要求部１０１、フラグ管理部１０２、データ格納部１０３及び処理要求部１０４に加えて、プロセス間通信部１０５を有する。

プロセス間通信部１０５は、プロセス間通信によりクラウドサーバー２０に対する処理要求をユーザーの情報とともにアプリケーション１１１又は１１２から受信する。そして、プロセス間通信部１０５は、認証の依頼をユーザーの情報とともに認証要求部１０１へ送信する。また、プロセス間通信部１０５は、受信した処理要求を処理要求部１０１へ送信する。

その後、プロセス間通信部１０５は、処理要求に対する応答を処理要求部１０４から受信する。そして、プロセス間通信部１０５は、処理要求に対する応答を処理要求の送信元であるアプリケーション１１１又は１１２へプロセス間通信を用いて送信する。

認証要求部１０１は、認証の依頼をユーザーの情報と共にプロセス間通信部１０５から受信する。そして、認証要求部１０１は、データ格納部１０３にアクセスし、ＵＲＬ切替フラグ１３１を確認して、値が「切替前」であれば旧ＵＲＬ１３２を用いて認証サーバー２０１にアクセスしてログインによる認証要求を実行する。旧ＵＲＬ１３２を用いたアクセスに失敗した場合、認証要求部１０１は、新ＵＲＬ１３３を用いて認証サーバー２０１にアクセスして認証要求を実行する。新ＵＲＬ１３３を用いたアクセスに成功すると、認証要求部１０１は、ＵＲＬ切替フラグ１３１の変更をフラグ管理部１０２に指示する。また、ＵＲＬ切替フラグ１３１の値が「切替後」の場合、認証要求部１０１は、新ＵＲＬ１３３を用いて認証サーバー２０１にアクセスして認証要求を実行する。

すなわち、本実施例に係る認証要求部１０１は、業務実行部からの接続要求を受けて、接続先切替情報を確認して、接続切替情報の値に応じて、第１認証装置又は第２認証装置への接続を実行する。

フラグ管理部１０２は、認証要求部１０１からのＵＲＬ切替フラグ１３１の変更の指示を受けて、ＵＲＬ切替フラグ１３１の値を「切替後」に設定する。

処理要求部１０４は、認証要求部１０１からのアクセストークン１３４を受けて、アクセストークン１３４の送信元に応じて、アプリケーションサーバー２０２又は２１２に処理要求を送信する。その後、処理要求部１０４は、処理要求に対する応答をアプリケーションサーバー２０２又は２１２から受信して、受信した応答をプロセス間通信部１０５へ送信する。

以上に説明したように、本実施例に係るクライアントアプリケーションは、他のアプリケーションのクラウドサーバーのアクセスを仲介する。すなわち、クラウドサーバーへのアクセス及び認証がクライアントアプリケーションに集約される。そのため、あるアプリケーションを用いてクラウドサーバーを利用する場合に、すでに他のアプリケーションで新ＵＲＬを用いたアクセスが成功している場合であれば、旧ＵＲＬにアクセスすることなく変更後の認証サーバーに認証要求を送ることができる。したがって、認証サーバーへのアクセスを迅速に行うことができ、ユーザーの利便性をより向上させることが可能となる。

図８は、実施例３に係るクライアントＰＣのブロック図である。本実施例に係るクライアントアプリケーション１００は、リフレッシュトークン１３５の送信により接続先を認証サーバー２０１から認証サーバー２１１へ切り替えることができる。以下に、本実施例に係るクライアントアプリケーション１００の詳細について説明する。以下の説明では、実施例１と同様の各部の動作については説明を省略する場合がある。ここでは、ログインしてアクセストークン１３４を取得したタイミングでは、サーバー切替が行われておらず、その後にサーバー切替が行われた場合で説明する。

認証サーバー２０１は、サーバー切替前に、ログインによる認証要求を認証要求部１０１から受けると、認証を行ない、認証が成功するとアクセストークン１３４及びリフレッシュトークン１３５を認証要求部１０１へ送信する。その後、認証サーバー２０１は、リフレッシュトークン１３５を認証要求部１０１から受信すると、新たなアクセストークン１３４を認証部１０１へ送信する。

また、認証サーバー２０１は、サーバー切替前に、認証要求部１０１がリフレッシュトークン１３５を送信して認証要求を行なった場合、新たなアクセストークン１３４を認証部１０１へ送信する。

認証サーバー２１１は、サーバー切替後に、認証要求部１０１が自装置に対するログインを行わずにリフレッシュトークン１３５を送信して認証要求を行なった場合、新たなアクセストークン１３４を認証部１０１へ送信する。例えば、認証サーバー２１１は、アカウント情報２２０において認証サーバー２０１により各アカウントに紐づけられたリフレッシュトークン１３５の情報を確認することで、リフレッシュトークン１３５の正当性を確認することができる。

認証要求部１０１は、データ格納部１０３にアクセスし、サーバー切替前のログインによる認証要求時にＵＲＬ切替フラグ１３１を確認する。この場合、ログイン時にはサーバー切替が行われていないため、ＵＲＬ切替フラグ１３１の値は、「切替前」である。そこで、認証要求部１０１は、旧ＵＲＬ１３２を用いて認証サーバー２０１にアクセスしてログインによる認証要求を行なう。その後、認証が成功すると、認証要求部１０１は、アクセストークン１３４及びリフレッシュトークン１３５を認証サーバー２０１から受信する。そして、認証要求部１０１は、アクセストークン１３４及びリフレッシュトークン１３５をデータ格納部１０３に格納する。

ここで、アクセストークン１３４の有効期限は数分～数時間程度と比較的短時間である。これに対して、リフレッシュトークン１３５の有効期限は数か月と比較的長く設定される。認証要求部１０１は、リフレッシュトークン１３５を認証サーバー２０１に送信することで、ログインを行わずに新たなアクセストークン１３４を取得することができる。ここでは、リフレッシュトークン１３５を送信して新たなアクセストークン１３４を取得することも、認証要求と呼ぶ。

例えば、クライアントアプリケーション１００にクラウドサーバー２０との常時接続が求められる場合、認証要求部１０１は、アクセストークン１３４を常に有効な状態に保つことが求められる。そのため、認証要求部１０１は、有効期限が切れる数分前までの時間を予め更新時間として記憶しておき、アクセストークン１３４の取得時にその有効期限を確認し、更新時間経過後にリフレッシュトークン１３５によるアクセストークン１３４の更新を行う。例えば、アクセストークン１３４の有効期限が１時間であり、５５分が更新時間である場合、認証要求部１０１は、５５分の間隔でリフレッシュトークン１３５の送信を行う。認証要求部１０１は、データ格納部１０３にアクセスし、リフレッシュトークン１３５の送信時に、ＵＲＬ切替フラグ１３１を確認する。

ＵＲＬ切替フラグ１３１の値が、「切替前」の場合、認証要求部１０１は、旧ＵＲＬ１３２をデータ格納部１０３から取得する。そして、認証要求部１０１は、取得した旧ＵＲＬ１３２を用いて認証サーバー２０１にアクセスし、リフレッシュトークン１３５を認証サーバー２０１へ送信して認証要求を行なう。そして、認証要求部１０１は、旧ＵＲＬ１３２を用いた認証サーバー２０１へのアクセスの成功又は失敗を判定する。

アクセスが成功し認証サーバー２０１による認証が成功すると、認証要求部１０１は、認証結果として新たなアクセストークン１３４を認証サーバー２０１から受信する。次に、認証要求部１０１は、新たなアクセストークン１３４をデータ格納部１０３に格納してアクセストークン１３４を更新する。

これに対して、アクセスが失敗した場合、認証要求部１０１は、新ＵＲＬ１３３をデータ格納部１０３から取得する。次に、認証要求部１０１は、取得した新ＵＲＬ１３３を用いて認証サーバー２１１にアクセスし、リフレッシュトークン１３５を認証サーバー２１１へ送信して認証要求を行なう。そして、認証要求部１０１は、新ＵＲＬ１３３を用いた認証サーバー２１１へのアクセスの成功又は失敗を判定する。

アクセスが成功し認証サーバー２１１による認証が成功すると、認証要求部１０１は、認証結果として新たなアクセストークン１３４を認証サーバー２１１から取得する。次に、認証要求部１０１は、新たなアクセストークン１３４をデータ格納部１０３に格納してアクセストークン１３４を更新する。さらに、認証要求部１０１は、ＵＲＬ切替フラグ１３１の変更をフラグ管理部１０２に指示する。

これに対して、アクセスが失敗した場合、認証要求部１０１は、データ格納部１０３に格納されたＵＲＬ切替フラグ１３１の値を「切替前」のまま維持させる。そして、認証要求部１０１は、アクセス不可のメッセージをモニタに表示させてユーザーにアクセス不可を通知する。

一方、ＵＲＬ切替フラグ１３１の値が「切替後」の場合、認証要求部１０１は、最初から新ＵＲＬ１３３をデータ格納部１０３から取得する。次に、認証要求部１０１は、取得した新ＵＲＬ１３３を用いて認証サーバー２１１にアクセスし、リフレッシュトークン１３５を認証サーバー２１１へ送信して認証要求を行なう。そして、認証要求部１０１は、新ＵＲＬ１３３を用いた認証サーバー２１１へのアクセスの成功又は失敗を判定する。

アクセスが失敗した場合、認証要求部１０１は、データ格納部１０３に格納されたＵＲＬ切替フラグ１３１の値を「切替後」のまま維持させる。そして、認証要求部１０１は、アクセス不可のメッセージをモニタに表示させてユーザーにアクセス不可を通知する。

これに対して、アクセスが成功し認証サーバー２１１による認証が成功すると、認証要求部１０１は、認証結果として新たなアクセストークン１３４を認証サーバー２１１から取得する。次に、認証要求部１０１は、新たなアクセストークン１３４をデータ格納部１０３に格納して、アクセストークン１３４を更新する。

このリフレッシュトークン１３５が、「更新用情報」の一例にあたる。すなわち、本実施例に係る認証要求部１０１は、第１接続先情報を用いて第１認証装置への接続を実行し、第１認証装置への接続が成功した場合に第１認証装置へログインを行うことで第１認証要求を行ない、第１認証要求の応答として認証情報及び更新用情報を取得し、ログインの後定期的に、更新用情報を用いた認証情報の更新のために接続先切替情報を確認し、接続先切替情報の値が第１情報の場合、第１接続先情報を用いて第１認証装置への再接続を実行し、第１認証装置への再接続が成功した場合に更新用情報を送信することで第２認証要求を行ない、第２認証要求の応答として新たに認証情報を第１認証装置から受信し、第１認証装置への接続が失敗した場合、第２接続先情報を用いて第２認証装置への接続を実行し、第２認証装置への接続が成功した場合に更新用情報を送信することで第２認証要求を行ない、第２認証要求の応答として新たに認証情報を第２認証装置から受信し、接続先切替情報の値が第２情報の場合、第２接続先情報を用いて第２認証装置への接続を実行し、第２認証装置への接続が成功した場合に更新用情報を送信することで第２認証要求を行ない、第２認証要求の応答として新たに認証情報を第２認証装置から受信する。

図９は、実施例３に係るクライアントアプリケーションによる認証要求処理のフローチャートである。次に、図９を参照して、本実施例に係るクライアントアプリケーション１００による認証要求処理の流れを説明する。ここでも、ログインしてアクセストークン１３４を取得したタイミングでは、サーバー切替が行われておらず、その後にサーバー切替が行われた場合で説明する。

認証要求部１０１は、サーバー切替前のログイン時にはＵＲＬ切替フラグ１３１の値が「切替前」であることから、旧ＵＲＬ１３２を用いた認証サーバー２０１に対するログインによる認証を行なう（ステップＳ１１）。

認証が成功すると、認証要求部１０１は、アクセストークン１３４及びリフレッシュトークン１３５を認証サーバー２０１から受信する（ステップＳ１２）。

その後、認証要求部１０１は、アクセストークン１３４を受信してから更新時間が経過したか否かを判定する（ステップＳ１３）。更新時間が経過していない場合（ステップＳ１３：否定）、認証要求部１０１は、更新時間が経過するまで待機する。

これに対して、更新時間が経過した場合（ステップＳ１３：肯定）、認証要求部１０１は、データ格納部１０３にアクセスし、格納されたＵＲＬ切替フラグ１３１を確認する（ステップＳ１４）。

そして、認証要求部１０１は、ＵＲＬ切替フラグ１３１の値が「切替前」か否かを判定する（ステップＳ１５）。

ＵＲＬ切替フラグ１３１の値が「切替前」の場合（ステップ１５：肯定）、認証要求部１０１は、旧ＵＲＬ１３２をデータ格納部１０３から取得する。そして、認証要求部１０１は、旧ＵＲＬ１３２を用いて認証サーバー２０１にアクセスして、リフレッシュトークン１３５の送信による認証要求を行なう（ステップＳ１６）。

その後、認証要求部１０１は、認証要求に対する応答により旧ＵＲＬ１３２を用いた認証サーバー２０１へのアクセスが成功したか否かを判定する（ステップＳ１７）。旧ＵＲＬ１３２を用いたアクセスが成功した場合（ステップＳ１７：肯定）、認証要求部１０１は、ステップＳ２２へ進む。

これに対して、旧ＵＲＬ１３２を用いたアクセスが失敗した場合（ステップＳ１７：否定）、認証要求部１０１は、新ＵＲＬ１３３をデータ格納部１０３から取得する。そして、認証要求部１０１は、新ＵＲＬ１３３を用いて認証サーバー２１１にアクセスして、リフレッシュトークン１３５の送信による認証要求を行なう（ステップＳ１８）。

その後、認証要求部１０１は、認証要求に対する応答により新ＵＲＬ１３３を用いた認証サーバー２１１へのアクセスが成功したか否かを判定する（ステップＳ１９）。新ＵＲＬ１３３を用いたアクセスが失敗した場合（ステップＳ１９：否定）、認証要求部１０１は、アクセス不可を通知して認証要求処理を終了する。

これに対して、新ＵＲＬ１３３を用いたアクセスが成功した場合（ステップＳ１９：肯定）、認証要求部１０１は、ＵＲＬ切替フラグ１３１の変更をフラグ管理部１０２に指示する。フラグ管理部１０２は、指示を受けてＵＲＬ切替フラグ１３１の値を「切替後」に変更する（ステップＳ２０）。その後、認証要求部１０１は、ステップＳ２２へ進む。

一方、ＵＲＬ切替フラグ１３１の値が「切替後」の場合（ステップＳ１５：否定）、認証要求部１０１は、新ＵＲＬ１３３をデータ格納部１０３から取得する。そして、認証要求部１０１は、新ＵＲＬ１３３を用いて認証サーバー２０１にアクセスして、リフレッシュトークン１３５の送信による認証要求を行なう（ステップＳ２１）。その後、認証要求部１０１は、ステップＳ２２へ進む。

旧ＵＲＬ１３２又は新ＵＲＬ１３３を用いたアクセスが成功すると、認証要求部１０１は、新しいアクセストークン１３４を認証サーバー２０１又は２１１から受信する（ステップＳ２２）。認証要求部１０１は、新しいアクセストークン１３４をデータ格納部１０３に格納して、アクセストークン１３４を更新する。

その後、認証要求部１０１は、リフレッシュトークン１３５の有効期限が到来したか否かを判定する（ステップＳ２３）。

リフレッシュトークン１３５の有効期限が到来していない場合（ステップＳ２３：否定）、認証要求部１０１は、ステップＳ１３へ戻る。これに対して、リフレッシュトークン１３５の有効期限が到来した場合（ステップＳ２３：肯定）、認証要求部１０１は、認証要求処理を終了する。

以上に説明したように、本実施例に係るクライアントアプリケーションは、リフレッシュトークンの送信による認証要求により、アクセス先を旧ＵＲＬから新ＵＲＬに切り替える。これにより、ログイン後にサーバーの切り替えがあった場合に、クラウドサーバーとの常時接続状態を維持しつつ、シームレスに認証サーバーを切り替えることが可能となる。したがって、認証サーバーへのログイン後も、サーバー切替により認証サーバーへのユーザーのアクセスが滞ることが無くなり、ユーザーの利便性よりを向上させることが可能となる。

（ハードウェア構成）
図１０は、コンピューターのハードウェア構成図である。以上の各実施例に係るクライアントＰＣ１０及びクラウドサーバー２０は、図１０に示すコンピューター９０により実現可能である。

コンピューター９０は、図１０に示すように、ＣＰＵ（Central Processing Unit）９１、メモリ９２、ハードディスク９３及びネットワークインタフェース９４を有する。ＣＰＵ９１は、メモリ９２、ハードディスク９３及びネットワークインタフェース９４とバスで接続される。

ネットワークインタフェース９４は、コンピューター９０と外部の装置との通信インタフェースである。例えば、クライアントＰＣ１０であれば、ネットワークインタフェース９４は、インターネットなどに接続されＣＰＵ９１とクラウドサーバー２０との間の通信を中継する。また、クラウドサーバー２０であれば、ネットワークインタフェース９４は、インターネットなどに接続されＣＰＵ９１とクライアントＰＣ１０との間の通信を中継する。

ハードディスク９３は、補助記憶装置である。例えば、クライアントＰＣ１０であれば、ハードディスク９３は、データ格納部１０３の機能を実現する。また、ハードディスク９３は、認証要求部１０１、フラグ管理部１０２、処理要求部１０４及びプロセス間通信部１０５の機能を実現するためのプログラムを含む各種プログラムを格納する。また、クラウドサーバー２０であれば、ハードディスク９３は、アカウント情報２２０を記憶する。また、ハードディスク９３は、認証サーバー２０１及び２１１、並びに、アプリケーションサーバー２０２及び２１２の機能を実現するためのプログラムを含む各種プログラムを格納する。

メモリ９２は、主記憶装置である。メモリ９２は、例えば、ＤＲＡＭ（Dynamic Random Access Memory）を用いることができる。

ＣＰＵ９１は、ハードディスク９３から各種プログラムを読み出して、メモリ９２に展開して実行する。これにより、クライアントＰＣ１０であれば、ＣＰＵ９１は、認証要求部１０１、フラグ管理部１０２、処理要求部１０４及びプロセス間通信部１０５の機能を実現することができる。また、クラウドサーバー２０であれば、ＣＰＵ９１は、認証サーバー２０１及び２１１、並びに、アプリケーションサーバー２０２及び２１２の機能を実現することができる。

１ 情報処理システム
１０ クライアントＰＣ
２０ クラウドサーバー
１０１ 認証要求部
１０２ フラグ管理部
１０３ データ格納部
１０４ 処理要求部
１０５ プロセス間通信部
１３１ ＵＲＬ切替フラグ
１３２ 旧ＵＲＬ
１３３ 新ＵＲＬ
１３４ アクセストークン
１３５ リフレッシュトークン
２０１ 認証サーバー
２０２ アプリケーションサーバー
２１１ 認証サーバー
２１２ アプリケーションサーバー
２２０ アカウント情報

Claims (6)

1. 接続先切替情報、第１接続先情報及び第２接続先情報を格納するデータ格納部と、
   前記接続先切替情報の値が第１情報の場合、前記第１接続先情報を用いて第１認証装置への接続を実行し、前記第１接続先情報を用いた前記第１認証装置への接続が失敗した場合、前記第２接続先情報を用いて第２認証装置への接続を実行し、前記接続先切替情報の値が第２情報の場合、前記第２接続先情報を用いて前記第２認証装置への接続を実行する認証要求部と、
   前記接続先切替情報の初期値を前記第１情報と設定し、前記認証要求部による前記第２接続先情報を用いた前記第２認証装置への接続が成功した場合、前記データ格納部に格納された前記接続先切替情報を前記第２情報に更新する接続先管理部と
   を備えたことを特徴とする情報処理装置。
2. 所定の業務を実行する業務実行部をさらに備え、
   前記認証要求部は、前記業務実行部からの接続要求を受けて、前記接続先切替情報を確認して、前記接続先切替情報の値に応じて、前記第１認証装置又は前記第２認証装置への接続を実行する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記認証要求部は、
   前記第１接続先情報を用いて前記第１認証装置への接続を実行し、前記第１認証装置への接続が成功した場合に前記第１認証装置へログインを行うことで第１認証要求を行ない、前記第１認証要求の応答として認証情報及び更新用情報を取得し、
   前記ログインの後定期的に、前記更新用情報を用いた前記認証情報の更新のために前記接続先切替情報を確認し、
   前記接続先切替情報の値が第１情報の場合、
   前記第１接続先情報を用いて前記第１認証装置への再接続を実行し、
   前記第１認証装置への再接続が成功した場合に前記更新用情報を送信することで第２認証要求を行ない、前記第２認証要求の応答として新たに前記認証情報を前記第１認証装置から受信し、
   前記第１認証装置への接続が失敗した場合、前記第２接続先情報を用いて前記第２認証装置への接続を実行し、前記第２認証装置への接続が成功した場合に前記更新用情報を送信することで前記第２認証要求を行ない、前記第２認証要求の応答として新たに前記認証情報を前記第２認証装置から受信し、
   前記接続先切替情報の値が前記第２情報の場合、前記第２接続先情報を用いて前記第２認証装置への接続を実行し、前記第２認証装置への接続が成功した場合に前記更新用情報を送信することで前記第２認証要求を行ない、前記第２認証要求の応答として新たに前記認証情報を前記第２認証装置から受信する
   ことを特徴とする請求項１に記載の情報処理装置。
4. 第１認証装置、第２認証装置及び情報処理装置を有する情報処理システムであって、
   前記第１認証装置は、第１接続先情報を用いた接続を実行した前記情報処理装置と接続し、前記情報処理装置からの認証要求を受けて、認証処理を実行して、認証結果を前記情報処理装置へ送信し、
   前記第２認証装置は、第２接続先情報を用いた接続を実行した前記情報処理装置と接続し、前記情報処理装置からの認証要求を受けて、認証処理を実行して、認証結果を前記情報処理装置へ送信し、
   前記情報処理装置は、
   接続先切替情報、前記第１接続先情報及び前記第２接続先情報を格納するデータ格納部と、
   前記接続先切替情報の値が第１情報の場合、前記第１接続先情報を用いて前記第１認証装置への接続を実行し、前記第１接続先情報を用いた前記第１認証装置への接続が失敗した場合、前記第２接続先情報を用いて前記第２認証装置への接続を実行し、前記接続先切替情報の値が第２情報の場合、前記第２接続先情報を用いて前記第２認証装置への接続を実行する認証要求部と、
   前記接続先切替情報の初期値を前記第１情報と設定し、前記認証要求部による前記第２接続先情報を用いた前記第２認証装置への接続が成功した場合、前記データ格納部に格納された前記接続先切替情報を前記第２情報に更新する接続先管理部とを備えた
   ことを特徴とする情報処理システム。
5. 接続先切替情報、第１接続先情報及び第２接続先情報をデータ格納装置に格納し、
   前記接続先切替情報の初期値を第１情報に設定し、
   前記データ格納装置に格納された前記接続先切替情報の値が前記第１情報の場合、前記第１接続先情報を用いて第１認証装置への接続を実行し、
   前記第１接続先情報を用いた前記第１認証装置への接続が失敗した場合、前記第２接続先情報を用いて第２認証装置への接続を実行し、
   前記第２接続先情報を用いた第２認証装置への接続が成功した場合、前記データ格納装置に格納された前記接続先切替情報を第２情報に更新し、
   前記データ格納装置に格納された前記接続先切替情報の値が前記第２情報の場合、前記第２接続先情報を用いて前記第２認証装置への接続を実行する
   処理をコンピューターが実行することを特徴とする情報処理方法。
6. 接続先切替情報、第１接続先情報及び第２接続先情報をデータ格納装置に格納し、
   前記接続先切替情報の初期値を第１情報に設定し、
   前記データ格納装置に格納された前記接続先切替情報の値が前記第１情報の場合、前記第１接続先情報を用いて第１認証装置への接続を実行し、
   前記第１接続先情報を用いた前記第１認証装置への接続が失敗した場合、前記第２接続先情報を用いて第２認証装置への接続を実行し、
   前記第２接続先情報を用いた第２認証装置への接続が成功した場合、前記データ格納装置に格納された前記接続先切替情報を第２情報に更新し、
   前記データ格納装置に格納された前記接続先切替情報の値が前記第２情報の場合、前記第２接続先情報を用いて前記第２認証装置への接続を実行する
   処理をコンピューターに実行させることを特徴とする情報処理プログラム。

Images