JP2022047948A - 認可サーバ、認可サーバの制御方法 - Google Patents

Abstract

【課題】 認可コードの発行に応じて認可サーバからログアウトするための技術を提供すること。【解決手段】 アプリケーションサーバから受信した認可コードの発行要求が有効である場合は該認可コードを発行し、認可サーバにログインしているユーザの認証トークンを、認可コードの発行に応じて削除し、認可コードをアプリケーションサーバに送信する。【選択図】 図３

Description

本発明は、ユーザ端末にサービスを提供するアプリケーションサーバに対して認可コードを発行するための技術に関するものである。

従来、インターネットに接続されたＰＣ、スマートフォン、組み込み機器などの機器が、インターネットを介して提供された複数のクラウドサービスと連携し、ユーザに機能を提供するシステムが利用されている。

通常、ユーザがクラウドサービスを利用する際、ユーザ認証が行われる。近年、クラウドサービスが増加するにつれて、複数のクラウドサービスのユーザ認証を、特定の認可サーバで行うシングルサインオン技術の利用が広がってきた。例えば、シングルサインオン技術として、OpenID財団が策定するOpenID Connectや、OASISが策定するSAMLが知られている。

クラウドサービスは、その多様性およびアクセシビリティが高いので、アイデンティティの管理およびアクセスのセキュリティが中心的な関心事になっている。クラウド環境における典型的なセキュリティの問題は、不正アクセス、アカウントのハイジャック、悪意のあるインサイダーなどである。

OpenID等により、認可サーバにおける認証結果を用いてアプリケーションサーバにログインする場合、機器のWebブラウザでは、アプリケーションサーバおよび認可サーバのログイン情報（Cookie等）が管理される。この場合、認可サーバのログイン情報が不正に利用されてしまうことがある。

特許文献１では、アプリケーションサーバにログインした際に、アプリケーションサーバから認可サーバにログアウト要求を送信することで、暗黙的に認可サーバからログアウトし、ログイン情報の不正利用を防止する方法が開示されている。

特開２０１７－１５４４９２号公報

しかしながら、ユーザの認可サーバにおける認証状態はアプリケーションサーバに委ねられる。そのため、アプリケーションサーバが正しく認可サーバにログアウト要求を出していない場合、もしくは、ネットワーク遮断等の疎通問題が発生した場合、ユーザが認可サーバからログアウトされる保証がない。本発明では、認可コードの発行に応じて認可サーバからログアウトするための技術を提供する。

本発明の一様態は、認可サーバであって、ユーザ端末にサービスを提供するアプリケーションサーバから受信した認可コードの発行要求が有効である場合は、該認可コードを発行する発行手段と、前記認可サーバにログインしているユーザの認証トークンを、前記認可コードの発行に応じて削除する削除手段と、前記認可コードを前記アプリケーションサーバに対して送信する送信手段とを備えることを特徴とする。

本発明の構成によれば、認可コードの発行に応じて認可サーバからログアウトすることができる。

情報処理システムの構成例を示すブロック図。 認可サーバ１０１のハードウェア構成例を示すブロック図。 認可サーバ１０１、アプリケーションサーバ１０２、ユーザ端末１０３、のそれぞれの機能構成例を示すブロック図。 ログイン情報の構成例を示す図。 図３の各機能部によって行われる処理のフローチャート。 認可コード発行要求の構成例を示す図。 ログイン画面の表示例を示す図。 認可サーバ１０１、アプリケーションサーバ１０２、ユーザ端末１０３、のそれぞれの機能構成例を示すブロック図。 記憶部８０３に格納されている情報の構成例を示す図。 図８の各機能部によって行われる処理のフローチャート。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

［第１の実施形態］
まず、本実施形態に係る情報処理システムの構成例について、図１のブロック図を用いて説明する。図１に示す如く、本実施形態に係る情報処理システムは、認可サーバ１０１、アプリケーションサーバ１０２、ユーザ端末１０３、を有しており、それぞれはネットワーク１０４に接続されている。ネットワーク１０４は、ＬＡＮやインターネットなどの有線および／または無線のネットワークであり、認可サーバ１０１、アプリケーションサーバ１０２、ユーザ端末１０３はそれぞれネットワーク１０４を介して互いにデータ通信を行うことができる。なお、図１には、認可サーバ１０１、アプリケーションサーバ１０２、ユーザ端末１０３のそれぞれの台数を１としているが、それぞれの装置の台数は１に限らず複数であってもよい。

認可サーバ１０１は、アプリケーションサーバ１０２が提供するサービスを受けるための認可に係る各種の処理を行うサーバ装置である。アプリケーションサーバ１０２は、各種のサービスを提供するためのサーバ装置である。ユーザ端末１０３は、アプリケーションサーバ１０２が提供するサービスを受けるためにユーザが操作する端末装置であり、ＰＣ（パーソナルコンピュータ）、スマートフォン等のウェブブラウザを搭載した端末装置である。

次に、認可サーバ１０１のハードウェア構成例について、図２のブロック図を用いて説明する。なお、図２に示した構成は認可サーバ１０１に適用可能な構成の一例に過ぎず、適宜変更／変形が可能である。

ＣＰＵ２０１は、ＲＡＭ２０２やＲＯＭ２０３に格納されているコンピュータプログラムやデータを用いて各種の処理を実行する。これによりＣＰＵ２０１は、認可サーバ１０１全体の動作制御を行うとともに、認可サーバ１０１が行うものとして説明する各種の処理を実行もしくは制御する。

ＲＡＭ２０２は、ＲＯＭ２０３や外部記憶装置２０５からロードされたコンピュータプログラムやデータ、ネットワークＩ／Ｆ２０４を介して外部から受信したデータ、を格納するためのエリアを有する。またＲＡＭ２０２は、ＣＰＵ２０１が各種の処理を実行する際に用いるワークエリアを有する。このように、ＲＡＭ２０２は、各種のエリアを適宜提供することができる。

ＲＯＭ２０３には、認可サーバ１０１の設定データ、認可サーバ１０１の起動に係るコンピュータプログラムやデータ、認可サーバ１０１の基本動作に係るコンピュータプログラムやデータ、などが格納されている。

表示装置２０６は、液晶画面やタッチパネル画面などを有し、ＣＰＵ２０１による処理結果を画像や文字などでもって表示する。なお、表示装置２０６は、ＣＰＵ２０１による処理結果を画像や文字などでもって投影するプロジェクタなどの投影装置であってもよい。

ネットワークＩ／Ｆ２０４は、認可サーバ１０１を上記のネットワーク１０４に接続するための通信インターフェースである。認可サーバ１０１はネットワークＩ／Ｆ２０４を介して、ネットワーク１０４上のアプリケーションサーバ１０２やユーザ端末１０３とのデータ通信を行う。

外部記憶装置２０５は、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、光ディスクドライブ、半導体記憶装置などのメモリ装置である。外部記憶装置２０５には、ＯＳ（オペレーティングシステム）、認可サーバ１０１が行うものとして説明する各種の処理をＣＰＵ２０１に実行もしくは制御させるためのコンピュータプログラムやデータ、などが保存されている。外部記憶装置２０５に保存されているコンピュータプログラムやデータは、ＣＰＵ２０１による制御に従って適宜ＲＡＭ２０２にロードされ、ＣＰＵ２０１による処理対象となる。

入力装置２０７は、キーボード、マウス、タッチパネル画面などのユーザインターフェースであり、ユーザが操作することで各種の指示をＣＰＵ２０１に対して入力することができる。

ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、表示装置２０６、ネットワークＩ／Ｆ２０４、外部記憶装置２０５、入力装置２０７、はいずれもシステムバス２０８に接続されている。

なお、以下では説明を簡単にするために、アプリケーションサーバ１０２およびユーザ端末１０３も図２に示した構成を有するものとして説明するが、アプリケーションサーバ１０２およびユーザ端末１０３の構成は図２に示した構成に限らない。

本実施形態に係る情報処理システムにおける認可サーバ１０１、アプリケーションサーバ１０２、ユーザ端末１０３、のそれぞれの機能構成例を図３のブロック図に示す。以降の説明では、図３に示した機能部（記憶部３０６を除く）を処理の主体として説明するが、実際には、該機能部の機能をＣＰＵ２０１に実行させるためのコンピュータプログラムを該ＣＰＵ２０１が実行することで該機能部の機能が実現される。

つまり、認可サーバ１０１の機能部（記憶部３０６を除く）の機能を該認可サーバ１０１のＣＰＵ２０１に実行させるためのコンピュータプログラムを該ＣＰＵ２０１が実行することで、認可サーバ１０１の機能部の機能が実現される。また、アプリケーションサーバ１０２の機能部の機能を該アプリケーションサーバ１０２のＣＰＵ２０１に実行させるためのコンピュータプログラムを該ＣＰＵ２０１が実行することで、アプリケーションサーバ１０２の機能部の機能が実現される。また、ユーザ端末１０３の機能部の機能を該ユーザ端末１０３のＣＰＵ２０１に実行させるためのコンピュータプログラムを該ＣＰＵ２０１が実行することで、ユーザ端末１０３の機能部の機能が実現される。図３の各機能部によって行われる処理について、図５のフローチャートに従って説明する。

＜ステップＳ５０１＞
ユーザ端末１０３のユーザは、アプリケーションサーバ１０２が提供するサービスのうち受けたいサービスを、該ユーザ端末１０３の入力装置２０７を操作して指定する。Ｗｅｂブラウザなど、Ｗｅｂサイトにアクセスするための機能を提供するユーザエージェント３０９は、該指定を受けると、該指定されたサービスの提供を要求するサービス提供要求を、アプリケーションサーバ１０２に対して送信する。

＜ステップＳ５０２＞
アプリケーションサーバ１０２の受付部３０７は、ユーザ端末１０３から送信されたサービス提供要求を受信する。

＜ステップＳ５０３＞
アプリケーションサーバ１０２の受付部３０７は、ステップＳ５０２でのサービス提供要求の受信に応じ、ユーザ端末１０３のユーザの認可コードの発行を要求する認可コード発行要求を、認可サーバ１０１に対して送信する。

ここで、認可コード発行要求には、少なくとも、認可コード発行要求の送信元であるアプリケーションサーバ１０２を示す情報が含まれている。認可コード発行要求の構成例を図６に示す。

図６の認可コード発行要求では、HTTP（Hypertext Transfer Protocol）のプロトコルに従った構文によってメッセージが形成されている。URL（Uniform Resource Locator）部６０１では、認可コード発行要求の送信元（クライアント）と、発行する認可コードの送信先と、が指定されている。ヘッダ部６０２には、ユーザのログイン情報に含まれる認証トークン（該ユーザの本人確認が行われたことを表す一意に識別可能な値）が指定されている。

認可コード発行要求は、ブラウザリダイレクトによってユーザ端末１０３のブラウザを介して認可サーバ１０１に送信される。ブラウザのCookieにユーザの認証トークンが記憶されている場合は、該認証トークンは認可コード発行要求のヘッダ部６０２で指定される。

＜ステップＳ５０４＞
認可サーバ１０１の受付部３０１は、アプリケーションサーバ１０２もしくは認可サーバ１０１から送信された認可コード発行要求を受信する。

＜ステップＳ５０５＞
認可サーバ１０１の受付部３０１は、ステップＳ５０４で受信した認可コード発行要求のヘッダ部６０２に指定されている認証トークンを検証する。該検証の結果、該認証トークンが有効であると判断された場合、受付部３０１は、ユーザ端末１０３のユーザの本人確認が成功したと判断し、発行部３０２に対し、認可コードの発行を要求し、処理はステップＳ５１３に進む。一方、該検証の結果、該認証トークンが有効ではない（無効である）と判断された場合、もしくはヘッダ部６０２にユーザ端末１０３のユーザの認証トークンが指定されていない場合、受付部３０１は、ユーザ端末１０３のユーザの本人確認は成功していない判断し、認証部３０３に対し、ユーザ端末１０３のユーザの認証を要求し、処理はステップＳ５０６に進む。

＜ステップＳ５０６＞
認可サーバ１０１の認証部３０３は、受付部３０１からユーザの認証の要求を受けると、該要求に応じて、ユーザ端末１０３に対してログイン画面を送信する。

＜ステップＳ５０７＞
ユーザ端末１０３のユーザエージェント３０９は、認可サーバ１０１（認証部３０３）から送信されたログイン画面を受信する。

＜ステップＳ５０８＞
ユーザ端末１０３のユーザエージェント３０９は、ステップＳ５０７で受信したログイン画面を、ユーザ端末１０３の表示装置２０６に表示させる。ログイン画面の表示例を図７に示す。図７のログイン画面７０１は、ユーザ端末１０３のユーザに固有の識別情報であるユーザＩＤを入力するための領域７０２、該ユーザに対して発行されているパスワードを入力するための領域７０３、ログインを指示するためのログインボタン７０４、を有する。

＜ステップＳ５０９＞
ユーザ端末１０３のユーザエージェント３０９は、ユーザがユーザ端末１０３の入力装置２０７を用いてログイン画面に対して入力したユーザＩＤおよびパスワードを認可サーバ１０１に対して送信する。図７のログイン画面７０１の場合、ユーザがユーザ端末１０３の入力装置２０７を用いて領域７０２および領域７０３のそれぞれにユーザＩＤおよびパスワードを入力してからログインボタン７０４を指示すると、ユーザエージェント３０９は、領域７０２に入力されたユーザＩＤおよび領域７０３に入力されたパスワードを認可サーバ１０１に対して送信する。

なお、ここでは、ユーザの認証情報として該ユーザのユーザＩＤおよびパスワードを用いているが、ユーザのユーザＩＤおよびパスワードに加えてもしくは代えてほかの情報をユーザの認証情報としてもよい。

＜ステップＳ５１０＞
認可サーバ１０１の認証部３０３は、ユーザ端末１０３から送信されたユーザの認証情報を受信する。

＜ステップＳ５１１＞
認可サーバ１０１の認証部３０３は、ステップＳ５１０で受信したユーザの認証情報に基づいて該ユーザの認証を行う。

＜ステップＳ５１２＞
ステップＳ５１１における認証が成功した場合（該認証情報が有効である場合）、認証部３０３は、ユーザ端末１０３のユーザの本人確認が成功したと判断し、発行部３０４に対して認証トークンの発行を要求する。発行部３０４は、該要求に応じ、ユーザ端末１０３のユーザに対する認証トークンを発行する。

そして発行部３０４は、認証情報に含まれているユーザＩＤと、発行した認証トークンと、のセットをログイン情報として記憶部３０６に登録する。これにより、ユーザ端末１０３のユーザが認可サーバ１０１にログインしている状態となる。

記憶部３０６に登録されているログイン情報の構成例を図４に示す。列４０１には各ユーザのユーザＩＤが登録されており、列４０２には各ユーザの認証トークンが登録されている。例えば、ユーザＡのユーザＩＤに対応する認証トークンが記憶部３０６に登録されていることは、ユーザＡの本人確認が行われ、ユーザＡが認可サーバ１０１においてログイン状態であることを表している。

また発行部３０４は、発行した認証トークンをユーザ端末１０３に対して送信する。

＜ステップＳ５３０＞
ユーザ端末１０３のユーザエージェント３０９は、認可サーバ１０１から送信された認証トークンを受信する。

＜ステップＳ５３１＞
ユーザ端末１０３のユーザエージェント３０９は、ステップＳ５３０で受信した認証トークンをブラウザのＣｏｏｋｉｅに記憶させるとともに、該受信した認証トークンをヘッダ部６０２にて指定した認可コード発行要求を認可サーバ１０１に対して送信する。

＜ステップＳ５１３＞
認可サーバ１０１の発行部３０２は、受付部３０１からの要求に応じて、認可コードを発行する。

＜ステップＳ５１４＞
無効化部３０５は、認可コードの発行に応じて、該認可コードを発行したユーザのログイン情報を記憶部３０６から削除するとともに、ユーザ端末１０３のブラウザのCookieから該ユーザのログイン情報を削除するよう該ユーザ端末１０３に指示する。ユーザ端末１０３は該指示を受けると、該ユーザ端末１０３のブラウザのCookieから該ユーザのログイン情報を削除する。これにより、認証トークンを無効化し、ユーザを認可サーバ１０１からログアウトさせる。なお、削除はログイン情報に含まれている認証トークンのみであってもよい。

＜ステップＳ５１５＞
認可サーバ１０１の発行部３０２は、ステップＳ５１３で発行した認可コードをアプリケーションサーバ１０２に対して送信する。

＜ステップＳ５１６＞
アプリケーションサーバ１０２の受付部３０７は、認可サーバ１０１から送信された認可コードを受信する。そして受付部３０７は、該受信に応じてサービス提供部３０８に対し、ユーザ端末１０３へのサービスの提供を要求する。

＜ステップＳ５１７＞
アプリケーションサーバ１０２のサービス提供部３０８は、受付部３０７からの要求に応じ、認可サーバ１０１から受信した認可コードによって認可サーバ１０１からＩＤトークンを取得し、該取得したＩＤトークンを検証する。そしてサービス提供部３０８は、該検証の結果、該受信したＩＤトークンが有効であれば、ユーザ端末１０３から要求されたサービスを該ユーザ端末１０３に対して提供する。サービスの提供とは、例えば、ユーザ端末１０３から要求されたＷｅｂページの送信である。

＜ステップＳ５１８＞
ユーザ端末１０３のユーザエージェント３０９は、アプリケーションサーバ１０２から提供されたサービスを取得する。サービスの取得とは、例えば、ユーザ端末１０３がアプリケーションサーバ１０２に対して要求したＷｅｂページの受信である。

［第２の実施形態］
本実施形態では、第１の実施形態との差分について説明し、以下で特に触れない限りは、第１の実施形態と同様であるものとして説明する。第１の実施形態では、認可サーバ１０１で行う認可コードの発行において、認可コードの発行に応じて認証トークンを無効化し、認可サーバ１０１がユーザをログアウトさせる例を示した。本実施形態では、認可コードの発行要求元（クライアント）に応じて認証トークンの無効化の要否を判定する例を示す。本実施形態によれば、認可サーバ１０１による認証トークンの無効化の要否をクライアントごとに切り替えることができ、特定のクライアントに対して認可サーバ１０１へのログイン状態を維持することができる。

本実施形態に係る情報処理システムにおける認可サーバ１０１、アプリケーションサーバ１０２、ユーザ端末１０３、のそれぞれの機能構成例を図８のブロック図に示す。図８において図３に示した機能部と同じ機能部には同じ参照番号を付しており、該機能部に係る説明は省略する。図８に示す如く、本実施形態に係る認可サーバ１０１は、図３の認可サーバ１０１に、情報管理部８０１、無効化判定部８０２、記憶部８０３を加えたものである。

以降の説明では、図８に示した機能部（記憶部３０６および記憶部８０３を除く）を処理の主体として説明するが、実際には、第１の実施形態と同様、該機能部の機能をＣＰＵ２０１に実行させるためのコンピュータプログラムを該ＣＰＵ２０１が実行することで該機能部の機能が実現される。

図８の各機能部によって行われる処理について、図１０のフローチャートに従って説明する。図１０において図５に示した処理ステップと同じ処理ステップには同じステップ番号を付しており、該処理ステップに係る説明は省略する。図１０のフローチャートは、図５のフローチャートにおいてステップＳ５１３の直後にステップＳ１００１を加えたものである。

＜ステップＳ１００１＞
情報管理部８０１は、ステップＳ５１３で認可コードが発行されたことに応じて、ステップＳ５０４で受信した認可コード発行要求に含まれているクライアントＩＤに対応する無効化フラグを記憶部８０３から取得する。記憶部８０３には、クライアントＩＤごとに無効化フラグが格納されている。記憶部８０３に格納されている情報の構成例を図９に示す。

列９０１には、アプリケーションサーバ１０２を認可サーバ１０１のクライアントとして一意に識別するための識別情報であるクライアントＩＤが登録されている。列９０２には、発行部３０２で発行された認可コードを受け取るアプリケーションサーバ１０２のＵＲＬであるリダイレクトＵＲＬが登録されている。列９０３には、認証トークンの無効化の要否を示すフラグである無効化フラグが登録されている。

そして無効化判定部８０２は、記憶部８０３から取得した無効化フラグが「認証トークンの無効化が必要」を示すか、「認証トークンの無効化が不要」を示すか、を判断する。

この判断の結果、記憶部８０３から取得した無効化フラグが「認証トークンの無効化が必要」を示す場合には、処理はステップＳ５１４に進む。一方、記憶部８０３から取得した無効化フラグが「認証トークンの無効化が不要」を示す場合には、処理はステップＳ５１５に進む。

なお、上記の各実施形態で使用した数値、処理タイミング、処理順、データ（情報）の構成／送信先／送信元、画面の構成やその操作方法などは、具体的な説明を行うために一例として挙げたものであり、このような一例に限定することを意図したものではない。

また、以上説明した各実施形態の一部若しくは全部を適宜組み合わせて使用しても構わない。また、以上説明した各実施形態の一部若しくは全部を選択的に使用しても構わない。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１０１：認可サーバ １０２：アプリケーションサーバ １０３：ユーザ端末 ３０１：受付部 ３０２：発行部 ３０３：認証部 ３０４：発行部 ３０５：無効化部 ３０６：記憶部 ３０７：受付部 ３０８：サービス提供部 ３０９：ユーザエージェント

Claims (8)

1. 認可サーバであって、
   ユーザ端末にサービスを提供するアプリケーションサーバから受信した認可コードの発行要求が有効である場合は、該認可コードを発行する発行手段と、
   前記認可サーバにログインしているユーザの認証トークンを、前記認可コードの発行に応じて削除する削除手段と、
   前記認可コードを前記アプリケーションサーバに対して送信する送信手段と
   を備えることを特徴とする認可サーバ。
2. 前記削除手段は、前記アプリケーションサーバの識別情報とセットで管理されている、前記認証トークンの削除の要否を示すフラグが、前記認証トークンの削除が必要であることを示す場合には、前記認証トークンを前記認可コードの発行に応じて削除し、前記フラグが前記認証トークンの削除が不要であることを示す場合には、前記認証トークンを削除しないことを特徴とする請求項１に記載の認可サーバ。
3. さらに、
   前記発行要求が無効である場合は、前記ユーザ端末にて入力された前記ユーザの認証情報に基づいて該ユーザを認証し、該認証が成功した場合には認証トークンを発行する第２発行手段と、
   前記第２発行手段が発行した認証トークンを登録する登録手段と
   を備え、
   前記削除手段は、前記登録手段が登録した前記ユーザのログイン情報を、前記認可コードの発行に応じて削除する
   ことを特徴とする請求項１または２に記載の認可サーバ。
4. さらに、
   前記第２発行手段が発行した前記ユーザの認証トークンを前記ユーザ端末に対して送信する手段を備え、
   前記削除手段は、前記ユーザ端末におけるブラウザのＣｏｏｋｉｅに記憶された前記ユーザの認証トークンを削除させる
   ことを特徴とする請求項３に記載の認可サーバ。
5. 認可サーバと、ユーザ端末と、該ユーザ端末にサービスを提供するアプリケーションサーバと、を有する情報処理システムであって、
   前記認可サーバは、
   前記アプリケーションサーバから受信した認可コードの発行要求が有効である場合は、該認可コードを発行する発行手段と、
   前記認可サーバにログインしているユーザの認証トークンを、前記認可コードの発行に応じて削除する削除手段と、
   前記認可コードを前記アプリケーションサーバに対して送信する送信手段と
   を備え、
   前記アプリケーションサーバは、
   前記ユーザ端末からサービスの提供要求を受信したことに応じて、前記認可サーバに対して前記発行要求を送信する手段と、
   前記認可サーバから送信された前記認可コードを受信すると、前記ユーザ端末に対してサービスを提供する手段と
   を備える
   ことを特徴とする情報処理システム。
6. 前記認可サーバは、
   前記発行要求が無効である場合は、前記ユーザ端末にて入力された前記ユーザの認証情報に基づいて該ユーザを認証し、該認証が成功した場合には認証トークンを発行する第２発行手段と、
   前記第２発行手段が発行した認証トークンを登録する登録手段と、
   前記第２発行手段が発行した認証トークンを前記ユーザ端末に対して送信する手段と
   を備え、
   前記削除手段は、前記登録手段が登録した前記ユーザのログイン情報を、前記認可コードの発行に応じて削除し、
   前記ユーザ端末は、
   前記認可サーバから送信された前記認証トークンを指定する、認可コードの発行要求を前記認可サーバに対して送信する手段
   を備え、
   前記発行手段は、前記ユーザ端末から受信した認可コードの発行要求が有効である場合は、認可コードを発行する
   ことを特徴とする請求項５に記載の情報処理システム。
7. 認可サーバの制御方法であって、
   前記認可サーバの発行手段が、ユーザ端末にサービスを提供するアプリケーションサーバから受信した認可コードの発行要求が有効である場合は、該認可コードを発行する発行工程と、
   前記認可サーバの削除手段が、前記認可サーバにログインしているユーザの認証トークンを、前記認可コードの発行に応じて削除する削除工程と、
   前記認可サーバの送信手段が、前記認可コードを前記アプリケーションサーバに対して送信する送信工程と
   を備えることを特徴とする認可サーバの制御方法。
8. コンピュータを、請求項１ないし４のいずれか１項に記載の認可サーバの各手段として機能させるためのコンピュータプログラム。

Images