JP2016018529A - 認証システム、認証方法、プログラム及び通信システム - Google Patents

Abstract

【課題】既存の認証機構を用いるサービスの利用可否を、利用期限に基づき判定できるようにすることを目的とする。
【解決手段】クライアントの提供するサービスの利用期限を記憶する記憶部と、前記クライアントから、前記サービスの利用に用いられるアクセストークンの発行要求を受信する受信部と、前記発行要求の受信に応じて、前記利用期限に基づき、前記アクセストークンを発行する発行部と、前記クライアントからの前記アクセストークンの受信に応じて、現在の日時が前記アクセストークンに係る前記サービスの利用期限を超過していない場合に、前記アクセストークンが有効であると判断し、前記日時が前記利用期限を超過している場合に、前記アクセストークンが有効でないと判断する判断部と、を有する、認証システムを提供する。
【選択図】図３

Description

本発明は、認証システム、認証方法、プログラム及び通信システムに関する。

インターネットのような通信ネットワークを介し、遠隔地との間で、遠隔会議を行う会議システムが普及している。このような会議システムは、遠隔会議を行う出席者等の当事者の一方がいる会議室において、遠隔会議システムの端末装置を用い、会議の当事者などの会議室の画像および発言などの音声を撮影および収集する。そして、画像や音声のデータをデジタルデータに変換した後に、相手方の端末装置に送信し、相手方の会議室のディスプレイに表示およびスピーカにより音声出力して、実際の会議に近い状態で、遠隔地間の会議を実現する（例えば、特許文献１）。

上述の遠隔会議システムを利用し、当該遠隔会議システム上で動作するサービスを、遠隔会議システムの提供者以外の第三者が提供する場合がある。このような場合に、端末又は利用者を認証して、契約状態等に応じてサービスの利用を認可するアクセス制御の仕組みが必要となる。一のアクセス制御サービスが管理する認証情報を用いて、複数のサービスに対する利用者認証を行うために、非特許文献１に記載されるような、ＯＡｕｔｈというプロトコルが利用されている。これにより、ユーザは、認可サーバを介して、クライアント(端末、プログラム)に権限を与えることで、複数のサービスを利用することができるようになる。

また、サーバ上の機能を使用する、クライアントのサービスプログラムに対して、サーバが、サービスプログラムとクライアントの識別子の関連付けの有無により、機能の利用を許可する構成が開示されている（特許文献２）。

上述した遠隔会議システムにおいて、ＯＡｕｔｈのような既存の認証機構を用いてサービスを提供する場合、ユーザごとに、サービスの利用可否が管理される。しかしながら、既存の方法では、個別のサービスごとに、利用期限に基づいて、サービスの利用可否を判定することができなかった。

本発明は、このような問題に鑑みてなされたものであり、既存の認証機構を用いるサービスの利用可否を、利用期限に基づき判定できるようにすることを目的とする。

上述した課題を解決し目的を達成するため、本発明の一実施形態における認証システムは、
クライアントの提供するサービスの利用期限を記憶する記憶部と、
前記クライアントから、前記サービスの利用に用いられるアクセストークンの発行要求を受信する受信部と、
前記発行要求の受信に応じて、前記利用期限に基づき、前記アクセストークンを発行する発行部と、
前記クライアントからの前記アクセストークンの受信に応じて、現在の日時が前記アクセストークンに係る前記サービスの利用期限を超過していない場合に、前記アクセストークンが有効であると判断し、前記日時が前記利用期限を超過している場合に、前記アクセストークンが有効でないと判断する判断部と、
を有する。

本発明によれば、既存の認証機構を用いるサービスの利用可否を、利用期限に基づき判定できるようになる。

本発明の一実施形態における認証システムの概略図。 本発明の一実施形態における認証装置のハードウェア構成図。 本発明の一実施形態における認証装置の機能ブロック図。 端末管理ＤＢのテーブルの例を表す図。 認証管理ＤＢのテーブルの例を表す図。 機能認可管理ＤＢのテーブルの例を表す図。 サービス認可管理ＤＢのテーブルの例を表す図。 リフレッシュトークン管理ＤＢのテーブルの例を表す図。 アクセストークンの発行処理を表すシーケンス図。 アクセストークンの有効期間設定処理を表すフローチャート。 認証処理を表すシーケンス図。 アクセストークンの再発行処理を表すシーケンス図。 本発明の一実施形態における認証装置及びサービス認可装置の機能ブロック図。 サービス認可装置管理ＤＢのテーブルの例を表す図。 アクセストークン発行処理を表すシーケンス図。

以下、図を用いて、本発明の実施形態について説明する。

≪認証システムの概略≫
図１は、本発明の一実施形態における認証システム１の概略図である。認証システム１は、ユーザの使用する端末１０と、プラットフォーム提供者の提供する認証装置５０とを有する。プラットフォーム提供者は、認証装置５０を通じて、第三者であるサービス提供者の提供するクライアント・アプリケーション３０（以下、クライアント３０と呼ぶ）に、アクセス制御サービスを提供する。

ユーザは、自らが使用する、スマートフォンのような端末１０に、サービス提供者が提供するクライアント３０を、予め導入しておく。クライアント３０は、例えばインターネット２を介して、認証装置５０にアクセスし、認証装置５０からの認証を受けることで、サービスを実行することができる。

認証装置５０は、ＯＡｕｔｈにおいて用いられる、アクセストークンを用いて、クライアント３０を認証する。認証装置５０は、クライアント３０から送信された、ＩＤやパスワードを用いて、クライアント３０を認証する。ここで、認証装置５０は、クライアント３０ごとの（すなわち、ユーザごとの）、サービスの利用期限を管理している。そして、認証装置５０は、ＩＤとパスワードによる認証が成功したことに加えて、現在の日時が、サービスの利用期限を超えていない場合に、クライアント３０に対して、アクセストークンを発行することができる。なお、同じユーザに対して複数の異なるサービスの利用期限を関連付けて管理してもよい。

これにより、認証システム１は、ＯＡｕｔｈによる枠組みの中で、クライアント３０ごとのサービスの利用期限に基づいて、アクセス制御を行うことができる。

なお、図１では、認証装置５０が、一の筐体を有するコンピュータにより構成されているが、認証装置５０は、複数のコンピュータによるシステムとして構成されても良い。以下では、説明を簡単にするために、認証装置５０が、一の筐体を有するコンピュータである例を用いて、説明する。

≪ハードウェア構成≫
図２は、本発明の本実施形態における認証装置５０のハードウェア構成図である。認証装置５０は、認証装置５０の全体の動作を制御するＣＰＵ２０１、ＩＰＬ（Initial Program Loader）のようなプログラムを記憶したＲＯＭ２０２、ＣＰＵ２０１のワークエリアとして使用されるＲＡＭ２０３、認証装置５０のプログラム向けのデータを記憶するＨＤ２０４、ＣＰＵ２０１の制御にしたがってＨＤ２０４に対するデータの読み出し又は書き込みを制御するＨＤＤ(Hard Disk Drive)２０５、フラッシュメモリのような記録メディア２０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアドライブ２０７、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示するディスプレイ２０８、インターネット２を利用してデータ通信するためのネットワークＩ／Ｆ２０９、文字、数値、各種指示などの入力のための複数のキーを備えたキーボード２１１、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行うマウス２１２、着脱可能な記録媒体の一例としてのＣＤ−ＲＯＭ(Compact Disc Read Only Memory)２１３に対する各種データの読み出し又は書き込みを制御するＣＤ−ＲＯＭドライブ２１４、及び、上記各構成要素を図２に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン２１０を備えている。

≪機能≫
図３は、本発明の一実施形態における認証装置５０の機能ブロック図である。認証装置５０は、通信部５１と、記憶・読出処理部５２と、伝送管理部５３と、アクセス制御部５４と、記憶部５５とを有する。

記憶部５５は、図２に示されるＨＤ２０４により実現され、クライアント３０又はクライアント３０のユーザの認証に用いられるデータを記憶する。記憶部５５は、特に、クライアント管理ＤＢ５００１、認証管理ＤＢ５００２、機能認可管理ＤＢ５００３、サービス認可管理ＤＢ５００４、リフレッシュトークン管理ＤＢ５００５を管理する。

クライアント管理ＤＢ５００１は、クライアントの名称や接続状態等を管理するデータベースである。

図４は、クライアント管理ＤＢ５００１のテーブルの一例を表す。図４のテーブルは、クライアント３０又はクライアント３０のユーザを識別するための識別情報である通信ＩＤと、クライアント３０又はクライアント３０のユーザの名称と、クライアント３０の接続状態と、クライアント３０のＩＰアドレスの項目を有する。名称は、クライアント３０又はユーザごとに、予め設定される。接続状態は、クライアント３０からのログイン要求に応じて、認証装置５０が適宜設定する。ＩＰアドレスは、クライアント３０と認証装置５０との通信により特定され、認証装置５０により適宜設定される。

認証管理ＤＢ５００２は、クライアント３０又はクライアント３０のユーザを識別するための識別情報である通信ＩＤと、パスワードとの組を格納するデータベースである。

図５は、認証管理ＤＢ５００２のテーブルの一例を表す。図５のテーブルは、クライアント３０又はクライアント３０のユーザごとに割り振られた通信ＩＤとパスワードとを、関連付けて記憶する。なお、パスワードは、ＳＨＡ２５６のような、一方向ハッシュ関数を用いてハッシュした値であってもよい。

機能認可管理ＤＢ５００３は、クライアント３０ごと（すなわち、通信ＩＤごと）に、利用可能なサービスと機能とを関連付ける情報を格納するデータベースである。

図６は、機能認可管理ＤＢ５００３のテーブルの一例を表す。図６のテーブルは、通信ＩＤと、当該通信ＩＤを有するクライアント３０が利用可能なサービスを表すサービスＩＤと、そのサービスが使用する、認証装置５０の機能を表す機能ＩＤとを、関連付けて記憶する。機能ＩＤとは、認証装置５０がプラットフォームとして提供する、認証機能以外の機能に割り当てられた識別情報である。例えば、認証装置５０が、遠隔会議システムにおける遠隔会議サーバとして使用される場合、以下のような機能を有することができる。
−ユーザ情報提供機能：クライアント３０を使用するユーザの属性情報（名前、所属、連絡先、住所、性別等）へのアクセスを提供する機能
−コンタクト情報（アドレス帳）提供機能：遠隔会議の宛先の一覧であるアドレス帳へのアクセスを提供する機能
−ビデオ会議中継機能：画像と音声を中継して遠隔会議を実行する機能
−テキストメッセージ中継機能：テキストメッセージを送受信する機能
なお、図５に示されるように、いくつかの機能は、一のサービスを構成するために、組となって提供され得る。例えば、遠隔会議サービス（video_meeting）は、ユーザ情報提供機能（https://example.com/scopes/user_info）、コンタクト情報（アドレス帳）提供機能（https://example.com/scopes/contacts）及びビデオ会議中継機能（https://example.com/scopes/conference）によって構成される。また、テキストチャット（テキストメッセージング）サービス（text_chat）は、ユーザ情報提供機能（https://example.com/scopes/user_info）、コンタクト情報（アドレス帳）提供機能（https://example.com/scopes/contacts）及びテキストメッセージ中継機能（https://example.com/scopes/messaging）によって構成される。

サービス認可管理ＤＢ５００４は、クライアント３０ごと（すなわち、通信ＩＤごと）の、サービスの利用期限を管理するデータベースである。

図７は、サービス認可管理ＤＢ５００４のテーブルの一例を表す。図７のテーブルは、通信ＩＤと、サービスＩＤと、当該サービスの利用が開始される開始日時と、当該サービスの利用期限とを関連付けて記憶する。なお、サービスの開始日時と利用期限は、ユーザによる対価の支払い等に応じて、プラットフォーム提供者又はサービス提供者により、適宜設定される。

リフレッシュトークン管理ＤＢ５００５は、アクセストークンと共に生成されたリフレッシュトークンを管理するためのデータベースである。

図８は、リフレッシュトークン管理ＤＢ５００５のテーブルの一例を表す。図８のテーブルは、リフレッシュトークン（文字列）と、当該リフレッシュトークンの付与対象となる通信ＩＤと、当該リフレッシュトークンにより使用可能なサービスのサービスＩＤと、当該サービスの利用する機能ＩＤとを、関連付けて記憶する。

図３に示される通信部５１は、図２に示されるネットワークＩ／Ｆ２０９の処理により実現され、インターネット２を介して、端末１０とデータのやりとりを行う。

記憶・読出処理部５２は、図２に示されるＨＤＤ２０５の処理により実現され、記憶部５５へのデータの記憶や、記憶部５５からのデータの読み出しを行う。

伝送管理部５３は、図２に示されるＣＰＵ２０１の処理により実現され、主にクライアント３０の認証処理を実行する。伝送管理部５３は、クライアント管理部５３１と、アクセストークン検証部５３２とを有する。

クライアント管理部５３１は、クライアント３０から、通信ＩＤ及びサービスＩＤを含むログイン要求を受信し、クライアント３０の接続情報を取得する。また、クライアント管理部５３１は、クライアント３０から、ログイン要求と共に、アクセストークンを受信する。

また、クライアント管理部５３１は、通信ＩＤ及びサービスＩＤ並びにアクセストークンを、アクセストークン検証部５３２に渡す。クライアント管理部５３１は、アクセストークンが有効である場合には、クライアント３０のログイン処理を実行し、ログイン処理が完了した旨の応答を、クライアント３０に通知する。ここで、ログイン処理とは、図４に示されるクライアント管理ＤＢ５００１における、クライアント３０の接続状態やＩＰアドレスの更新処理を含む。一方、クライアント管理部５３１は、アクセストークンが有効でない場合には、ログイン処理が正常に完了しなかった旨の応答を、クライアント３０に通知する。

アクセストークン検証部５３２は、クライアント管理部５３１から受け取ったアクセストークンの署名を検証し、アクセストークンの有効性を検証する。アクセストークン検証部５３２は、アクセストークンの署名が不正である場合には、アクセストークンが有効でないと判定し、その旨を、クライアント管理部５３１に通知する。

また、アクセストークン検証部５３２は、アクセストークンの署名が正常である場合、さらに、受け取った通信ＩＤ及びサービスＩＤをキーとして、図７に示されるサービス認可管理ＤＢ５００４を探索し、開始日時と利用期限を特定する。そして、アクセストークン検証部５３２は、現在の日時が、開始日時と利用期限の間である場合に、アクセストークンが有効であると判定する。一方、アクセストークン検証部５３２は、現在の日時が、開始日時より前であるか、あるいは、利用期限より後である場合には、アクセストークンが有効でないと判定する。アクセストークン検証部５３２は、判定結果を、クライアント管理部５３１に通知する。

アクセス制御部５４は、図２に示されるＣＰＵ２０１の処理により実現され、主にアクセストークンの発行処理を実行する。アクセス制御部５４は、認証管理部５４１と、機能認可管理部５４２と、サービス認可管理部５４３と、アクセストークン発行部５４４と、リフレッシュトークン管理部５４５と、認証・認可制御部５４６とを有する。

認証管理部５４１は、認証・認可制御部５４６の指示に応じて、クライアント３０から受信した、通信ＩＤとパスワードの組が、図５に示される認証管理ＤＢ５００２に登録されているか検証する。そして、認証管理部５４１は、通信ＩＤとパスワードの組が、認証管理ＤＢ５００２に登録されている場合に、認証が成功したと判定する。一方、認証管理部５４１は、通信ＩＤとパスワードの組が、認証管理ＤＢ５００２に登録されていなかった場合には、認証が失敗したと判定する。認証管理部５４１は、判定の結果を、認証・認可制御部５４６に通知する。

なお、認証管理部５４１は、受け取ったパスワードを所定のハッシュ関数によりハッシュ値に変換し、そのハッシュ値と通信ＩＤとを用いて、その組が正しいか否かを確認してもよい。

機能認可管理部５４２は、認証・認可制御部５４６の指示に応じて、通信ＩＤ、サービスＩＤ、機能ＩＤの組が、図６に示される機能認可管理ＤＢ５００３に登録されているか検証する。そして、機能認可管理部５４２は、通信ＩＤ、サービスＩＤ、機能ＩＤの組が、機能認可管理ＤＢ５００３に登録されている場合に、機能の使用が認可されていると判定する。一方、機能認可管理部５４２は、通信ＩＤ、サービスＩＤ、機能ＩＤの組が、機能認可管理ＤＢ５００３に登録されていなかった場合には、機能の使用が認可されていないと判定する。機能認可管理部５４２は、判定の結果を、認証・認可制御部５４６に通知する。なお、複数の異なる機能ＩＤが、一のサービスＩＤに対して、関連付けられても良い。また、複数の異なるサービスＩＤが、一の通信ＩＤに対して、関連付けられても良い。

サービス認可管理部５４３は、認証・認可制御部５４６の指示に応じて、通信ＩＤ、サービスＩＤの組をキーとして、図７に示されるサービス認可管理ＤＢを探索し、対応する開始日時と利用期限とを特定する。また、サービス認可管理部５４３は、現在の日時を取得し、現在の日時が、開始日時と利用期限との間にあるか判定する。

サービス認可管理部５４３は、現在の日時が、開始日時と利用期限との間にある場合には、サービスの使用が認可されていると判定し、その旨を、認証・認可制御部５４６に通知する。また、このとき、サービス認可管理部５４３は、開始日時と利用期限とを、認証・認可制御部５４６に通知する。一方、現在の日時が、開始日時より前であるか、利用期限より後である場合には、サービスの使用が認可されていないと判定し、その旨を、認証・認可制御部５４６に通知する。

アクセストークン発行部５４４は、認証・認可制御部５４６の指示に応じて、クライアント３０の実行するサービスごとに、有効期限付きのアクセストークンを発行する。アクセストークン発行部５４４は、デフォルト値として、予め定められた有効期間を有するアクセストークンを発行する。但し、有効期間は、サービスの利用期限を超えない範囲で、設定される。

なお、アクセストークン発行部５４４は、例えば、JSON Web Token（draft-ietf-oauth-json-web-token-16）の形式を用いて、アクセストークンを発行することができる。アクセストークンは、少なくとも、通信ＩＤ、サービスＩＤ、機能ＩＤ、有効期間、アクセストークンの発行日時の情報を含み、認証装置５０の秘密鍵にて署名される。アクセストークンを検証するサービスは、認証装置５０の公開鍵にて署名を検証した後、作成に用いた方式（例えば、JSON Web Token）を解釈することで、保持する情報を取り出すことができる。

リフレッシュトークン管理部５４５は、認証・認可制御部５４６の指示に応じて、クライアント３０向けのリフレッシュトークンを発行する。リフレッシュトークンとは、アクセストークンの有効期限が切れた場合に、新たなアクセストークンを発行する際に必要となる、予測不可能な文字列である。リフレッシュトークン管理部５４５は、生成されたリフレッシュトークンの情報を、図８に示されるリフレッシュトークン管理ＤＢに格納する。

リフレッシュトークンは、任意の構造を有する。例えば、リフレッシュトークンは、非特許文献１に示されるＯＡｕｔｈプロトコルで用いられる構造を有していても良い。なお、リフレッシュトークンには、利用期限を設けるのが一般的であり、その場合は、ユーザに、再度通信ＩＤとパスワードを入力させずに認証を可能としてもよい期間（数日〜数ヶ月など）が指定される。

認証・認可制御部５４６は、クライアント３０からの、アクセストークン発行要求を受信し、上述した機能部を用いて、アクセストークン及びリフレッシュトークンの発行処理を実行する。認証・認可制御部５４６は、アクセストークン及びリフレッシュトークンが正しく発行された場合には、そのアクセストークンを、クライアント３０に送信する。一方、認証・認可制御部５４６は、アクセストークンが正しく発行されなかった場合には、認証・認可が失敗した旨を、クライアント３０に通知する。

≪動作例 − アクセストークンの発行処理≫
図９は、アクセストークンの発行処理を表すシーケンス図である。以下の例では、クライアント３０は、ビデオ会議のサービスを実行するためのアプリケーションであるものとして、説明を行う。

まず、端末１０のクライアント３０は、ユーザに対して、通信ＩＤとパスワードの入力を求めるダイアログを表示する（Ｓ１０１）。このダイアログには、通信ＩＤとパスワードとを入力するテキストフィールドと、「ログイン」ボタンが配置されている。ユーザは、通信ＩＤ「aaa」とパスワード「pass01」を入力し、「ログイン」ボタンを押下する（Ｓ１０２）。クライアント３０は、認証装置５０の認証・認可制御部５４６に、通信ＩＤ、パスワード、ビデオ会議のサービスＩＤ（video_meeting）、ビデオ会議の実行に必要な以下の機能ＩＤを通知し、アクセストークンの発行を要求する（Ｓ１０３）。

−機能ＩＤ
https://example.com/scopes/user_info
https://example.com/scopes/contacts
https://example.com/scopes/conference
なお、当該要求及び後のアクセストークンを用いたやりとりは、すべてＳＳＬ／ＴＬＳにて暗号化された通信路を介して行われる。

認証システム５０の認証・認可制御部５４６は、受信した通信ＩＤ「aaa」とパスワード「pass01」を、認証管理部５４１に渡す（Ｓ１０４）。認証管理部５４１は、受け取った通信ＩＤとパスワードの組が、図５に示される認証管理ＤＢ５００２に登録されているか検証する（Ｓ１０５）。そして、認証管理部５４１は、通信ＩＤとパスワードの組が、認証管理ＤＢ５００２に登録されていることから、認証が成功したと判定し、その結果を、認証・認可制御部５４６に通知する（Ｓ１０６）。

次に、認証システム５０の認証・認可制御部５４６は、通信ＩＤ「aaa」、サービスＩＤ「video_meeting」及び上述の機能ＩＤを、機能認可管理部５４２に通知する（ステップＳ１０７）。機能認可管理部５４２は、通信ＩＤ、サービスＩＤ、機能ＩＤの組が、図６に示される機能認可管理ＤＢ５００３に登録されているか検証する（Ｓ１０８）。そして、機能認可管理部５４２は、通信ＩＤ、サービスＩＤ、機能ＩＤの組が、機能認可管理ＤＢ５００３に登録されていることから、機能の使用が認可されていると判定し、その結果を、認証・認可制御部５４６に通知する（Ｓ１０９）。

次に、認証システム５０の認証・認可制御部５４６は、通信ＩＤ「aaa」及びサービスＩＤ「video_meeting」を、サービス認可管理部５４３に通知する（Ｓ１１０）。サービス認可管理部５４３は、通信ＩＤ、サービスＩＤの組をキーとして、図７に示されるサービス認可管理ＤＢを探索し、対応する開始日時「2014-02-01 00:00 JST」と利用期限「2014-04-30 23:59 JST」とを特定する（Ｓ１１１）。次いで、サービス認可管理部５４３は、開始日時と利用期限とを、認証・認可制御部５４６に通知する（Ｓ１１２）。次いで、認証・認可制御部５４６は、現在の日時（ここでは、「2014-04-01 10:00 JST」であるとする）が、開始日時と利用期限との間にあると判定する（Ｓ１１３）。

次に、認証システム５０の認証・認可制御部５４６は、アクセストークン発行部５４４に、アクセストークンを発行するよう指示する（Ｓ１１４）。このとき、認証・認可制御部５４６は、開始日時、利用期限、通信ＩＤ、パスワード、サービスＩＤ、機能ＩＤを、アクセストークン発行部５４４に通知する。アクセストークン発行部５４４は、利用期限を超えない範囲の有効期限を有する、アクセストークンを発行する（Ｓ１１５）。アクセストークンは、少なくとも、通信ＩＤ、サービスＩＤ、機能ＩＤ、有効期間、アクセストークンの発行日時の情報を含み、認証装置５０の秘密鍵にて署名される。アクセストークンの有効期限の決定方法については後述する。次いで、アクセストークン発行部５４４は、発行したアクセストークンを、認証・認可制御部５４６に通知する（Ｓ１１６）。

さらに、認証システム５０の認証・認可制御部５４６は、リフレッシュトークン管理部５４５に、リフレッシュトークンを発行するよう指示する（Ｓ１１７）。このとき、認証・認可制御部５４６は、必要に応じて、開始日時、利用期限、通信ＩＤ、パスワード、サービスＩＤ等の情報を、リフレッシュトークン管理部５４５に通知しても良い。リフレッシュトークン管理部５４５は、取得した情報を用いて、リフレッシュトークンを発行する（Ｓ１１８）。さらに、リフレッシュトークン管理部５４５は、発行したリフレッシュトークンの情報を、図８に示されるリフレッシュトークン管理ＤＢに記憶する（Ｓ１１９）。そして、リフレッシュトークン管理部５４５は、発行したリフレッシュトークンを、認証・認可制御部５４６に通知する（Ｓ１２０）。

そして、認証システム５０の認証・認可制御部５４６は、発行されたアクセストークンとリフレッシュトークンを、クライアント３０に送信する（Ｓ１２１）

≪動作例 − アクセストークンの有効期間設定処理≫
図１０は、アクセストークンの有効期間設定処理を表すフローチャートである。図１０に示される処理は、アクセストークン発行部５４４により実行される。

まず、アクセストークン発行部５４４は、認証・認可制御部５４６から、アクセストークンの発行指示（図９のＳ１１４）とともに、サービスの利用期限を取得する（Ｓ２０１）。次いで、アクセストークン発行部５４４は、現在の日時を取得する（Ｓ２０２）。次いで、アクセストークン発行部５４４は、利用期限から現在の日時を引いた期間が、予め設定された、デフォルトのアクセストークン有効期間より大きいか否かを判定する（Ｓ２０３）。そして、利用期限から現在の日時を引いた期間が、デフォルトのアクセストークン有効期間より大きい場合（Ｓ２０３のＹｅｓ）、アクセストークン発行部５４４は、デフォルトのアクセストークン有効期間を、アクセストークンの有効期間とする（Ｓ２０７）。

一方、利用期限から現在の日時を引いた期間が、デフォルトのアクセストークン有効期間以下である場合（Ｓ２０３のＮｏ）、アクセストークン発行部５４４は、さらに、利用期限が、現在の日時より大きいか判定する（Ｓ２０４）。そして、利用期限が、現在の日時以降である場合（Ｓ２０４のＹｅｓ）、アクセストークン発行部５４４は、利用期限から現在の日時を引いた期間を、アクセストークンの有効期間とする（Ｓ２０５）。一方、利用期限が、現在の日時より前である場合（Ｓ２０４のＮｏ）、アクセストークン発行部５４４は、サービスの利用期限に達していると判定する（Ｓ２０６）。

アクセストークン発行部５４４が、サービスの利用期限に達していると判定した場合、アクセストークン発行部５４４は、その旨を、認証・認可制御部５４６に通知する。このとき、認証・認可制御部５４６は、認証・認可が失敗した旨を、クライアント３０に通知する。

≪動作例 − 認証処理≫
図１１は、認証処理を表すシーケンス図である。ここでは、図９のシーケンスに従って生成されたアクセストークンによる、クライアント３０の認証処理を説明する。

まず、アクセストークンを持っているクライアント３０は、認証装置５０のクライアント管理部５３１に、アクセストークンと、ログインを要求するログイン要求を送信する（Ｓ３０１）。クライアント管理部５３１は、受け取ったアクセストークンを、アクセストークン検証部５３２に渡す（Ｓ３０２）。アクセストークン検証部５３２は、アクセストークンが偽造されたものでないか確認するため、アクセストークンの署名を検証する（Ｓ３０３）。次いで、アクセストークン検証部５３２は、アクセストークンに記録された、アクセストークンの発行日時と有効期間から、現在の日時が、アクセストークンの有効期間に含まれるか確認する（Ｓ３０４）。そして、現在の日時がアクセストークンの有効期間内である場合に、その旨を、クライアント管理部５３１に通知する（Ｓ３０５）。

クライアント管理部５３１は、アクセストークンから通信ＩＤを読み出し、当該通信ＩＤのログイン処理を実施する（Ｓ３０６）。ログイン処理は、例えば、クライアント管理ＤＢ５００１における接続状態を、オンラインに設定することを含む。ログイン処理が完了すると、クライアント管理部５３１は、ログイン完了をクライアントに通知する（Ｓ３０７）。

なお、Ｓ３０４において、現在の日時が、アクセストークンの有効期間に含まれない場合には、アクセストークン検証部５３２は、その旨を、クライアント管理部５３１に通知する。この場合、クライアント管理部５３１は、ログイン処理を実行せず、ログインできない旨の応答を、クライアント３０に通知する。

≪動作例 − アクセストークンの再発行処理≫
図１２は、アクセストークンの再発行処理を表すシーケンス図である。ここでは、図８に示されるリフレッシュトークン「abcd1234」が用いられるものとして、説明を行う。

まず、クライアント３０は、リフレッシュトークン「abcd1234」、通信ＩＤ「aaa」、サービスＩＤ「video_meeting」、下記の機能ＩＤ一覧を、認証装置５０の認証・認可制御部５４６に送信する（Ｓ４０１）。

−機能ＩＤ
https://example.com/scopes/user_info
https://example.com/scopes/contacts
https://example.com/scopes/conference
認証・認可制御部５４６は、受信したリフレッシュトークン、通信ＩＤ、サービスＩＤ、機能ＩＤを、リフレッシュトークン管理部５４５に通知する（Ｓ４０２）。

リフレッシュトークン管理部５４５は、図８に示されるリフレッシュトークン管理ＤＢ５００５を読み込む（Ｓ４０３）。次いで、リフレッシュトークン管理部５４５は、受信したリフレッシュトークンをキーとして、リフレッシュトークン管理ＤＢ５００５を探索し、特定されたサービスＩＤ及び機能ＩＤが、受信したサービスＩＤ及び機能ＩＤと一致するか検証する（Ｓ４０４）。

サービスＩＤ及び機能ＩＤが一致し、リフレッシュトークンの検証が正しく完了すると、リフレッシュトークン管理部５４５は、図７に示されるサービス認可管理ＤＢ５００４を読み込む（Ｓ４０５）。次いで、リフレッシュトークン管理部５４５は、通信ＩＤ及びサービスＩＤをキーとして、サービス認可管理ＤＢ５００４を探索し、開始日時と利用期限を特定した後に、現在の日時が、開始日時と利用期限と間にあるか判定する（Ｓ４０６）。そして、リフレッシュトークン管理部５４５は、現在の日時が、開始日時と利用期限との間にある場合に、リフレッシュトークンが有効である旨を、認証・認可制御部５４６に通知する（Ｓ４０７）。

なお、Ｓ４０４においてサービスＩＤ及び機能ＩＤが一致しない場合又はＳ４０６において現在の日時が開始日時より前であるか若しくは利用期限より後である場合、リフレッシュトークン管理部５４５は、リフレッシュトークンが有効でない旨を、認証・認可制御部５４６に通知する。

リフレッシュトークンが有効である旨の通知を受け取った認証・認可制御部５４６は、図９のＳ１１４−Ｓ１２１と同様の手順に従って、新たに、アクセストークンとリフレッシュトークンを発行し、これらをクライアント３０に送信する（Ｓ４０８−Ｓ４１５）。

≪効果≫
以上の構成により、本実施形態における認証システム１では、認証装置５０が、ユーザの認証情報を検証するとともに、現在の日時が、サービスを利用可能な期間に含まれるか否かを判定し、判定結果に応じて認証結果を返答する。これにより、サービス提供者が、認証サービスを提供するプラットフォームである認証装置５０を用いて、ユーザにサービスを提供する際に、サービス利用可否を正確に制御できるようになる。特に、本実施形態によれば、クライアント３０における、ＯＡｕｔｈプロトコルの認証手続きを変更することになく、サービスの利用期限に応じたきめ細かなアクセス制御が可能となる。

≪変形例≫
以下では、上述した実施形態において認証装置５０が備えていた、サービス認可管理部５４３（図３参照）が、例えばインターネット２のようなネットワークを介して通信可能な、サービス認可装置６０に設けられている場合の例を説明する。

図１３は、本発明の一実施形態における認証装置５０及びサービス認可装置６０の機能ブロック図である。図３との差異を中心に説明すると、図１３に示される認証装置５０は、図３に示されていた、サービス認可管理部５４３と、サービス認可管理ＤＢ５００４とを有していない。代わりに、図１３における認証装置５０は、サービス認可装置管理ＤＢ５００６を新たに有する。

サービス認可装置管理ＤＢ５００６は、サービス認可管理部５４３の機能を提供するサービス認可装置６０の接続情報を管理する。

図１４は、サービス認可装置管理ＤＢ５００６のテーブルの例を表す図である。図１４に示されるテーブルは、サービスＩＤと、ホスト名の項目を有する。サービス認可装置６０は、サービス提供者の各々が提供するホスト（サーバ又はシステム）である。上述した実施形態では、個々のサービスの利用期限の検証を、認証装置５０そのものが行うことができたが、本実施形態では、この検証は、サービス提供者のサービス認可装置６０が行う。これは、個々のサービスの利用期限は、サービス提供者が、自らのシステム内で設定できたほうが、好ましい場合があるためである。従って、サービス認可装置管理ＤＢ５００６では、サービスを特定するサービスＩＤごとに、そのサービスの利用期限を検証可能なホストのホスト名を管理する。

本実施形態における認証・認可制御部５４６は、サービスの利用期限の判定を行う際に、図１４に示されるサービス認可装置管理ＤＢ５００６を参照し、特定されたサービス認可装置６０に対して、サービスの利用期限の判定を依頼することができる。

また、図１４には、新たに、サービス認可装置６０が示されている。サービス認可装置６０は、例えば、図２に示されたハードウェア構成と同様の構成を有する、１以上のコンピュータシステムである。サービス認可装置６０は、通信部６１と、サービス認可管理部６３と、記憶部６５を有する。

記憶部６５は、図２に示されるＨＤ２０４により実現され、図３に示される記憶部５５と同様に、サービス認可管理ＤＢ５００４を記憶する。サービス認可管理ＤＢ５００４は、図７に示されるテーブルと同様のテーブルを有する。

通信部６１は、図２に示されるネットワークＩ／Ｆ２０９により実現され、認証装置５０や他の装置と、インターネット２のようなネットワークを通じて通信を行う。

サービス認可管理部６３は、図３に示される認証装置５０のサービス認可管理部５４３と同様の機能を有する。すなわち、サービス認可管理部６３は、認証装置５０の認証・認可制御部５４６の指示に応じて、通信ＩＤ、サービスＩＤの組をキーとして、図７に示されるサービス認可管理ＤＢ５００４を探索し、対応する開始日時と利用期限とを特定することができる。

図１５は、アクセストークン発行処理を表すシーケンス図である。ここで、認証装置５０が、クライアント３０から、通信ＩＤ、パスワード、サービスＩＤ等を受信し、機能認可管理部５４２による検証を行うＳ５０１−Ｓ５０９は、図９のＳ１０１−Ｓ１０９と同様である。続いて、認証装置５０の認証・認可制御部５４６は、サービスＩＤ「video_meeting」をキーとして、図１４に示されるサービス認可装置管理ＤＢを読み込み、ホスト名「video_meeting.provier.com」を特定する（Ｓ５１０）。

次に、認証システム５０の認証・認可制御部５４６は、通信ＩＤ「aaa」及びサービスＩＤ「video_meeting」を、サービス認可装置６０のサービス認可管理部６３に通知する（Ｓ５１１）。サービス認可管理部６３は、通信ＩＤ、サービスＩＤの組をキーとして、図７に示されるサービス認可管理ＤＢを探索し、対応する開始日時「2014-02-01 00:00 JST」と利用期限「2014-04-30 23:59 JST」とを特定する（Ｓ５１２）。次いで、サービス認可管理部６３は、開始日時と利用期限とを、認証装置５０の認証・認可制御部５４６に通知する（Ｓ５１３）。次いで、認証装置５０の認証・認可制御部５４６は、現在の日時（ここでは、「2014-04-01 10:00 JST」であるとする）が、開始日時と利用期限との間にあると判定する（Ｓ５１４）。

その後、認証装置５０が、アクセストークンとリフレッシュトークンを発行し、クライアント３０に通知するＳ５１５−Ｓ５２２は、図９のＳ１１４−Ｓ１２１と同様である。

以上の構成により、本実施形態における認証システム１では、プラットフォーム提供者の提供する認証装置５０とは異なる、サービス提供者のサービス認可装置６０が、サービスの利用期限の判定を行う。すなわち、プラットフォーム提供者は、プラットフォーム上で動作する各サービスの利用期限を把握しない。代わりに、クライアント３０を提供するサービス提供者の各々が、サービスの利用期限を、自ら運用するサービス認可装置６０で管理することが可能となる。これにより、サービス提供者は、ユーザのサービスの利用期限の変更のたびに、認証装置５０に、サービスの利用期限の情報を伝達する必要がなくなる。

１ 認証システム
２ インターネット
１０ 端末
３０ クライアント・アプリケーション
５０ 認証装置
６０ サービス認可装置

特開２０１３−０８５２０８号公報 特許４５８３１５２号公報

D. Hardt, Ed、「ＲＦＣ−６７４９」、[online]、２０１２年１０月、インターネット＜ＵＲＬ：http://tools.ietf.org/html/rfc6749＞

Claims (10)

1. クライアントの提供するサービスの利用期限を記憶する記憶部と、
   前記クライアントから、前記サービスの利用に用いられるアクセストークンの発行要求を受信する受信部と、
   前記発行要求の受信に応じて、前記利用期限に基づき、前記アクセストークンを発行する発行部と、
   前記クライアントからの前記アクセストークンの受信に応じて、現在の日時が前記アクセストークンに係る前記サービスの利用期限を超過していない場合に、前記アクセストークンが有効であると判断し、前記日時が前記利用期限を超過している場合に、前記アクセストークンが有効でないと判断する判断部と、
   を有する、認証システム。
2. 前記判断部が前記アクセストークンが有効であると判断した場合に、前記クライアントによる前記サービスの利用を許可し、前記判断部が前記アクセストークンが有効でないと判断した場合に、前記クライアントによる前記サービスの利用を許可しない、
   請求項１に記載の認証システム。
3. 前記発行部は、現在の日時が、前記サービスの利用期限を超過していない場合に、前記アクセストークンを発行する、
   請求項１又は２に記載の認証システム。
4. 前記受信部は、前記アクセストークンの再発行要求を受信し、
   前記発行部は、現在の日時が、前記サービスの利用期限を超過していない場合に、さらなるアクセストークンを発行する、
   請求項３に記載の認証システム。
5. 前記発行部は、前記アクセストークンの発行とともに、該アクセストークンの更新に用いられるリフレッシュトークンを発行する、
   請求項４に記載の認証システム。
6. 前記クライアントは、ビデオ会議機能又はテキストメッセージング機能を有するアプリケーションである、
   請求項１乃至５何れか１項に記載の認証システム。
7. 前記認証システムは、前記サービスの実行に必要となるプラットフォームの提供者の第一のシステムと、前記クライアントの提供者の第二のシステムとを含み、
   前記第一のシステムは、前記受信部と、前記発行部とを有し、
   前記第二のシステムは、前記判断部を有する、
   請求項１に記載の認証システム。
8. クライアントから、該クライアントの提供するサービスの利用に用いられるアクセストークンの発行要求を受信する第一受信段階と、
   前記発行要求の受信に応じて、前記サービスの利用期限を記憶部から読み込む読み込み段階と、
   読み込まれた前記利用期限に基づき、前記アクセストークンを発行する発行段階と、
   前記クライアントから、発行された前記アクセストークンを受信する第二受信段階と、
   前記クライアントからの前記アクセストークンからの受信に応じて、現在の日時が前記アクセストークンに係る前記サービスの利用期限を超過していない場合に、前記アクセストークンが有効であると判断し、前記日時が前記利用期限を超過している場合に、前記アクセストークンが有効でないと判断する判断段階と、
   を有する、認証方法。
9. 請求項８に記載の認証方法をコンピュータに実行させるプログラム。
10. 認証システムとクライアントとを有する通信システムであって、
    サービスの利用に用いられるアクセストークンの発行要求を前記認証システムに送信する送信部と、
    前記発行要求を受信する受信部と、
    前記クライアントの提供するサービスの利用期限を記憶する記憶部と、
    前記発行要求の受信に応じて、前記利用期限に基づき、前記アクセストークンを前記クライアントに発行する発行部と、
    前記クライアントからの前記アクセストークンの受信に応じて、現在の日時が前記アクセストークンに係る前記サービスの利用期限を超過していない場合に、前記アクセストークンが有効であると判断し、前記日時が前記利用期限を超過している場合に、前記アクセストークンが有効でないと判断する判断部と、
    を有する、通信システム。

Images