JP6354382B2

JP6354382B2 - 認証システム、認証方法、認証装置及びプログラム

Info

Publication number: JP6354382B2
Application number: JP2014131745A
Authority: JP
Inventors: 伯武 ▲高▼安
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2014-06-26
Filing date: 2014-06-26
Publication date: 2018-07-11
Anticipated expiration: 2034-06-26
Also published as: EP2961210A1; US20150381622A1; JP2016009469A

Description

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

従来の認証技術（例えばＯＡｕｔｈプロトコル）では、Ｗｅｂサービスや、端末等にインストールされたクライアント・アプリケーションが、認証サーバからアクセストークンを取得することで、保護されたリソースへのアクセスが可能となっていた。アクセストークンは、リソース所有者の承認を伴い、認証サーバによって発行される。Ｗｅｂサービスやクライアントは、アクセストークンを、リソースサーバが持つ保護リソースにアクセスするために利用する（非特許文献１）。

また、特許文献１は、セキュリティを高める目的で、ＡＰＩにアクセスするクライアントにクライアントＩＤを発行し、許可されたクライアントのみがアクセス可能な構成を開示している。

例えば既存のＯＡｕｔｈ２．０では、ＯＡｕｔｈ２．０を利用するクライアント・アプリケーションを判別するためのクライアント情報（client_idやclient_secret）が、クライアントの種類により、一意に定められていた。しかし、クライアントが、スマートフォンやＰＣのような、汎用のコンピューティングデバイスへインストールされる場合、クライアントの内部に保持されるクライアント情報（特に、client_secret）が漏洩する可能性がある。クライアント情報が漏えいした場合、その同種のクライアントを使用する全ユーザが、client_secretをアップデートする必要が生じ、クライアント提供者及びユーザにとって、手間がかかるという問題があった。従来の技術においても、クライアントのＩＤが漏洩した際の対応は検討されておらず、同様の問題が発生する可能性があった。本発明は、このような問題に鑑みてなされたものであり、アクセストークンの生成に用いられるクライアント情報が漏えいした場合の影響を低減することを目的とする。

上述した課題を解決し目的を達成するため、本発明の一実施形態における認証システムは、
通信端末と、アクセストークンを用いて前記通信端末に機能を提供する認証装置とを有する認証システムであって、
アクセストークンの発行に必要な、前記通信端末にインストールされるアプリケーションごとに生成されるクライアント情報を、前記認証装置に対して要求する第一要求部と、
前記第一要求部からの要求に応じて、前記クライアント情報を生成し、該クライアント情報を前記通信端末に送信する第一送信部と、
前記クライアント情報を前記認証装置に送信し、該認証装置に対してアクセストークンを要求する第二要求部と、
前記第二要求部からの要求に応じて、受信された前記クライアント情報が、前記第一送信部により送信されたクライアント情報であるか判定する判定部と、
受信された前記クライアント情報が、前記第一送信部により送信されたクライアント情報であると判定された場合に、アクセストークンを生成する生成部と、
生成された前記アクセストークンを前記通信端末に送信する第二送信部と、
前記通信端末からのアクセス記録を記録する記録部と、
記録された前記アクセス記録に基づいて不正なアクセスを検知する検知部と、
前記検知部が不正なアクセスを検知したことに応じて、前記アプリケーションの提供者に、前記クライアント情報を変更するよう通知する通知部と、
を有する。

本発明によれば、アクセストークンの生成に用いられるクライアント情報が漏えいした場合の影響を低減できる。

本発明の一実施形態における認証システムの概略図。本発明の一実施形態における認証装置のハードウェア構成図。本発明の一実施形態における通信端末のハードウェア構成図。本発明の一実施形態における認証装置の機能ブロック図。管理情報を格納するテーブルの例を表す図。認証情報を格納するテーブルの例を表す図。アクセス情報を格納するテーブルの例を表す図。クライアント情報変更画面の例を表す図。クライアント情報とアクセストークンの発行処理を表すシーケンス図。クライアント情報の変更処理を表すシーケンス図。本発明の一実施形態における効果を説明する図。

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

≪認証システムの概略≫
図１は、本発明の一実施形態における認証システム１の概略図である。図１において、ユーザの使用する通信端末１０と、プラットフォーム提供者の提供する認証装置５０と、サービス提供者の提供するクライアント提供装置７０が示されている。これらの装置は、インターネット２のようなネットワークにより、互いに接続されている。

認証装置５０は、ＡＰＩ（Application Programming Interface）を外部に公開し、他の装置に対して機能を提供するサーバ・コンピュータ（又はシステム）である。認証装置５０は、例えば、ＯＡｕｔｈプロトコルにおけるＯＡｕｔｈサーバ（OAuth Server）として動作する。

通信端末１０は、ユーザによって使用される、スマートフォン、タブレット、ＰＣ等のデバイスである。通信端末１０には、サービス提供者の提供するクライアント・アプリケーション３０（以下、単にクライアント３０と呼ぶ）がインストールされる。クライアント３０は、例えば、クライアント提供装置７０から、インターネット２を通じて提供される。クライアント３０は、ＯＡｕｔｈプロトコルにおけるＯＡｕｔｈクライアント（OAuth Client）として動作し、認証装置５０の提供するＡＰＩを通じて、認証装置５０の機能を使用することができる。

通信端末１０にインストールされたクライアント３０は、ＯＡｕｔｈプロトコルに従い、認証装置５０から発行されたアクセストークンを使用して、認証装置５０の提供するＡＰＩを利用することができる。認証装置５０は、クライアント３０から、クライアント３０に対して割り当てられたクライアント情報（client_secret、client_id）を使用して、アクセストークンを生成する。

ここで、本発明の一実施形態における認証装置５０は、個々のユーザの通信端末１０にインストールされたクライアント３０の単位で、異なるクライアント情報を生成する。クライアント３０は、通信端末１０にインストールされた後、アクセストークンを取得する前に、認証装置５０にアクセスし、クライアント情報を取得する。そして、クライアント３０は、取得したクライアント情報を用いて、認証装置５０に対して、アクセストークンを要求する。認証装置５０は、クライアント情報が正しい場合に、クライアント３０に対してアクセストークンを発行する。

このような動作により、仮に、一の通信端末１０にインストールされたクライアント３０のクライアント情報が、第三者に漏えいしても、他の通信端末１０にインストールされた全てのクライアント３０（のクライアント情報）を更新する必要がなくなる。クライアント３０を提供するサービス提供者は、漏えいしたクライアント情報のみを変更すればよい。これにより、サービス提供者は、漏えいしたクライアント情報のユーザに対して、クライアント情報の再設定を促すだけで済む。以下、本発明の一実施形態について、詳細に説明する。

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

また、認証装置５０は、ＯＡｕｔｈプロトコル以外の認証プロトコルに従って動作する認証サーバであってもよい。

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

≪通信端末のハードウェア構成≫
図３は、本発明の本実施形態における通信端末１０のハードウェア構成図である。通信端末１０は、通信端末１０の全体の動作を制御するＣＰＵ１０１、ＩＰＬのようなプログラムを記憶したＲＯＭ１０２、ＣＰＵ１０１のワークエリアとして使用されるＲＡＭ１０３、フラッシュメモリのような内蔵又は外部の記録メディア１０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアドライブ１０７、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示し、かつ、ユーザの指の接触を検知して入力を受け付けるタッチパネル１０８、携帯電話通信網や無線ＬＡＮ（Local Area Network）等を介してデータ通信するためのネットワークＩ／Ｆ１０９、及び、上記各構成要素を図３に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン１１０を備えている。

なお、図３は、通信端末１０が、スマートフォンやタブレットのようなデバイスである場合のハードウェア構成である。しかしながら、通信端末１０は、図３に示されるハードウェア構成以外の構成であってもよく、例えば、通信端末１０がＰＣである場合には、図２に示されるキーボード２１１やマウス２１２（又はタッチパッド）等を有していても良い。

≪機能≫
図４は、本発明の一実施形態における認証装置５０と通信端末１０の機能ブロック図である。まず、本発明の一実施形態における通信端末１０は、クライアント管理部１１と、クライアント情報取得部３１と、認証要求部３２と、トークン取得部３３とを有する。

クライアント管理部１１は、図３に示されるＣＰＵ１０１等の処理により実現され、ユーザからの指示に応じて、サービス提供者のクライアント提供装置７０から、クライアント３０のプログラムをダウンロードする。そして、クライアント管理部１１は、ダウンロードしたプログラムを、通信端末１０のＲＯＭ１０２又はメディア１０６にインストールする。

クライアント管理部１１は、このプログラムをＲＡＭ１０３に読み込み、ＣＰＵ１０１に実行させることにより、クライアント３０の機能を具体化することができる。以下では、クライアント３０が有する、クライアント情報取得部３１と、認証要求部３２と、トークン取得部３３の機能について、詳細に説明する。

クライアント情報取得部３１は、ＣＰＵ１０１及びネットワークＩ／Ｆ１０９等の処理により実現され、認証装置５０に対して、クライアント情報（client_secret、client_id）の送信を要求する。クライアント情報取得部３１は、クライアント３０の初回起動時、あるいは、認証装置５０からクライアント情報の変更通知を受け取った場合、認証装置５０に対して、クライアント情報の送信を要求することができる。このとき、クライアント情報取得部３１は、クライアント３０に固有に割り当てられたクライアント番号やクライアント名（例えば、Apps for Phone）を、認証装置５０に通知しても良い。クライアント情報取得部３１は、認証装置５０からクライアント情報を受信し、受信したクライアント情報を、図示しない記憶部に記憶することができる。

認証要求部３２は、ＣＰＵ１０１及びネットワークＩ／Ｆ１０９等の処理により実現され、クライアント３０が認証装置５０の提供する機能にアクセスするために、ＩＤとパスワードを用いたユーザ認証を、認証装置５０に要求する。認証要求部３２は、ユーザ認証が成功したことに応じて、認証装置５０から、認可コードを受信する。

トークン取得部３３は、ＣＰＵ１０１及びネットワークＩ／Ｆ１０９等の処理により実現される。トークン取得部３３は、認証要求部３２が認証装置５０から受け取った認可コードと、クライアント情報取得部３１が受け取ったクライアント情報とを用いて、認証装置５０に対して、アクセストークンの送信を要求する。トークン取得部３３は、認証装置５０からアクセストークンを受信し、受信したアクセストークンを、図示しない記憶部に記憶する。以後、クライアント３０は、記憶されたアクセストークンを用いて、認証装置５０の提供するＡＰＩを使用することができる。

また、本発明の一実施形態における認証装置５０は、記憶部５１と、クライアント情報管理部５２と、クライアント情報生成部５３と、認証処理部５４と、トークン管理部５５と、トークン生成部５６と、アクセス記録部５７と、検知部５８と、変更受付部５９と、通知部６０とを有する。

記憶部５１は、図２のＨＤ２０４及びＨＤＤ２０５により実現され、管理情報５００１と、認証情報５００２と、アクセス情報５００３を記憶する。

管理情報５００１は、クライアント３０ごとに発行したクライアント情報や、クライアント３０そのもの情報を管理する情報である。

図５は、管理情報５００１を格納するテーブルの例を表す。管理情報５００１は、ＯＡｕｔｈで用いられるクライアント情報（client_id及びclient_secret）と、クライアント３０の種類を示すクライアント番号と、クライアント３０のクライアント名と、クライアント３０を提供するサービス提供者に予め割り当てられたサービス提供者番号とを関連付けて記憶する。なお、クライアント情報は、クライアント３０が個々の通信端末１０にインストールされた後に、個別に生成される。一方、クライアント番号、クライアント名、提供者番号は、クライアント３０ごとに、予め決められた値が用いられる。

認証情報５００２は、クライアント３０がインストールされる通信端末１０のユーザの認証情報を管理する情報である。

図６は、認証情報５００２を格納するテーブルの例を表す。図６の認証情報５００２は、ユーザに固有に割り当てられたユーザ名（ユーザＩＤ）と、そのユーザのパスワードとを、関連付けて記憶する。ユーザ名とパスワードの組み合わせは、予め、ユーザによって設定される。

アクセス情報５００３は、クライアント３０による、認証装置５０へのアクセスの記録を保持する情報である。

図７は、アクセス情報５００３を格納するテーブルの例を表す。図７のアクセス情報５００３は、アクセスがなされた日時と、アクセスがなされたとき、クライアント３０が通信に使用したＩＰアドレスとを、関連付けて記憶する。なお、図７に示されるテーブルは、例えば、通信端末１０にインストールされたクライアント３０ごと（すなわち、client_idごと）、又は、ユーザ名ごとに設けられる。

クライアント情報管理部５２は、図２のＣＰＵ２０１の処理によって主に実現され、クライアント３０から、クライアント情報の送信の要求を受け取ると、クライアント情報生成部５３に、クライアント情報を生成するよう指示する。そして、クライアント情報管理部５２は、生成されたクライアント情報を、クライアント３０に送信する。

クライアント情報生成部５３は、図２のＣＰＵ２０１の処理によって主に実現され、クライアント情報管理部５２からの指示に応じて、クライアント情報（すなわち、client_secret、client_id）を生成する。なお、クライアント情報生成部５３は、例えば、ハッシュ関数を使用して、予測不可能な数値と文字列の組み合わせにより、クライアント情報を生成することができる。

また、クライアント情報生成部５３は、生成したクライアント情報を、管理情報５００１に格納する。このとき、クライアント情報生成部５３は、クライアント３０から通知された、クライアントの番号やクライアント名を、合わせて管理情報５００１に格納しても良い。さらに、クライアント情報生成部５３は、クライアント名から特定できる、クライアント３０のサービス提供者の提供者番号を、管理情報５００１に格納しても良い。クライアント情報生成部５３は、生成したクライアント情報を、クライアント情報管理部５２に渡す。

認証処理部５４は、図２のＣＰＵ２０１の処理によって主に実現され、クライアント３０からのユーザ認証の要求を受け取ると、その要求とともに受け取ったＩＤとパスワードの組が、認証情報５００２に登録されているか検証する。そして、認証処理部５４は、ＩＤとパスワードの組が登録されている場合に、認証が成功したと判定し、認可コードをクライアント３０に送信する。認可コードは、後に、クライアント３０がアクセストークンを要求する際に、必要となるコードである。

トークン管理部５５は、図２のＣＰＵ２０１の処理によって主に実現され、クライアント３０から、アクセストークンの送信の要求を受け取る。ここで、トークン管理部５５は、その要求とともに、認可コードとクライアント情報を受け取る。トークン管理部５５は、受け取った認可コードが、認証処理部５４が送信した認可コードと同一であり、かつ、受け取ったクライアント情報が、管理情報５００１に登録されている場合に、アクセストークンを生成するよう、トークン生成部５６に指示する。そして、トークン管理部５５は、生成されたアクセストークンを、クライアント３０に送信する。

トークン生成部５６は、図２のＣＰＵ２０１の処理によって主に実現され、トークン管理部５５からの指示に応じて、アクセストークンを生成する。トークン生成部５６は、例えば、ＯＡｕｔｈで用いられるアクセストークンと同様の構成を有する、アクセストークンを生成することができる。トークン生成部５６は、生成したアクセストークンを、トークン管理部５５に通知する。

アクセス記録部５７は、図２のＣＰＵ２０１の処理によって主に実現され、クライアント３０（通信端末１０）から、認証装置５０へのアクセスがあると、その日時と、クライアント３０の使用するＩＰアドレスを、アクセス情報５００３に格納する。

検知部５８は、図２のＣＰＵ２０１の処理によって主に実現され、定期的あるいは不定期的に、アクセス情報５００３を監視し、アクセス日時とＩＰアドレスから、ユーザのなりすましによる不正なアクセスを検知する。例えば、検知部５８は、クライアント３０ごとに記録されるアクセス情報に、以下のような条件を満たす記録が含まれる場合に、不正なアクセスがあったことを検知することができる。
・同時刻又はほぼ同時刻に、割当国の異なるＩＰアドレスからのアクセスが記録されている場合
・通常の使用では想定されない頻度でアクセスが記録されている場合（例えば、１日にわたり、1秒ごとにアクセスが記録されている、等）
検知部５８は、あるクライアント３０に関して不正なアクセスを検知すると、その旨を、クライアント３０に対して割り当てられたclient_idとともに、クライアント３０を提供するサービス提供者に通知する。

検知部５８は、例えば、予め登録されている、サービス提供者のメールアドレスを用いて、通知を行うことができる。また、検知部５８は、サービス提供者がアクセス可能なサイトに、不正なアクセスを検知した旨を、通知しても良い。

変更受付部５９は、図２のＣＰＵ２０１の処理によって主に実現され、サービス提供者に対して、図８に示されるクライアント情報変更画面を提示し、不正が検知されたクライアント３０のクライアント情報の変更を受け付ける。変更受付部５９は、例えば、Ｗｅｂサーバとして動作する認証装置５０の機能を用いて、サービス提供者の使用する端末のブラウザ上に、図８に示される画面を表示することができる。

図８に示されるクライアント情報変更画面は、サービス提供者番号の他に、新たに設定されるクライアント情報（すなわち、client_id、client_secret）の項目を有する。サービス提供者は、この画面を用いて、自ら生成したクライアント情報か、当該画面において自動的に生成されたクライアント情報を、クライアント３０に対して再設定することができる。変更受付部５９は、図８のクライアント情報変更画面において、「再設定」ボタンが押下されたことに応じて、指定されたクライアント情報を、管理情報に格納する。

通知部６０は、図２のＣＰＵ２０１の処理によって主に実現され、変更受付部５９によって変更されたclient_idを有するクライアント３０に対して、クライアント情報が変更されたことを示す、変更通知を送信する。

≪動作例 − アクセストークンの発行処理≫
図９は、アクセストークンの発行処理を表すシーケンス図である。ここでは、通信端末１０を所有するユーザ（ユーザ名「user1」）が、クライアント提供装置７０から、クライアント３０のプログラムをダウンロードし、このプログラムを通信端末１０にインストールした直後である。ユーザは、通信端末１０を操作し、クライアント３０を起動したものとして、以下の説明を行う。

まず、通信端末１０のクライアント情報取得部３１は、インターネット２を通じて、認証装置５０に、クライアント情報の送信要求を送信する（Ｓ１０１）。このとき、クライアント情報取得部３１は、クライアント番号「１０１」や、クライアント名「Apps for Phone」を、認証装置５０に通知しても良い。

認証装置５０のクライアント情報管理部５２は、クライアント情報の送信要求の受信に応じて、クライアント情報を生成するよう、クライアント情報生成部５３に指示する（Ｓ１０２）。クライアント情報生成部５３は、クライアント情報管理部５２からの指示に応じて、例えば、以下のようなクライアント情報を生成する（Ｓ１０３）。
−client_id ：aUnWUB8PTG67VDXj27QX_vo_lsR6WeEl
−client_secret：ymYzYwt2d_uStLdnlOX67nlDw3DGDLXY
クライアント情報生成部５３は、生成したクライアント情報を、図５に示される管理情報５００１に格納する（Ｓ１０４）。また、クライアント情報生成部５３は、クライアント３０から受け取ったクライアント番号「１０１」やクライアント名「Apps for Phone」を、管理情報５００１に格納してもよい。

クライアント情報生成部５３は、生成したクライアント情報を、クライアント情報管理部５２に渡す（Ｓ１０５）。クライアント情報管理部５２は、インターネット２を介して、受け取ったクライアント情報を、通信端末１０のクライアント情報取得部３１に送信する（Ｓ１０６）。

次に、ユーザが、内部的に認証装置５０のＡＰＩを使用する、クライアント３０の所定の機能を使用しようとしたものとする。認証部３２は、認証装置５０の認証機能を使用するために、ユーザを、認証装置５０の認証画面に誘導し、ユーザから、ユーザ名とパスワードの入力を受け付ける（Ｓ１０７）。次いで、認証部３２は、受け付けたユーザ名「user1」とパスワード「pass01」を、認証装置５０の認証処理部５４に通知し、認証を要求する（Ｓ１０８）。

認証装置５０の認証処理部５４は、通信端末１０の認証部３２から受信したユーザ名とパスワードの組が、図６に示される認証情報５００２に登録されているか確認することにより、認証を行う（Ｓ１０９）。そして、認証処理部５４は、受信したユーザ名とパスワードの組が、認証情報５００２に登録されていることに応じて、認証が成功したと判断し、認可コードを、通信端末１０の認証部３２に送信する（Ｓ１１０）。

通信端末１０の認証部３２は、受信した認可コードを、トークン取得部３３に通知する（Ｓ１１１）。トークン取得部３３は、受け取った認可コードと、Ｓ１０６で取得されたクライアント情報とを、認証装置５０のトークン管理部５５に送信し、アクセストークンの送信要求を行う（Ｓ１１２）。

認証装置５０のトークン管理部５５は、受け取った認可コードが、認証処理部５４が送信した認可コードと同一であり、かつ、受け取ったクライアント情報が、管理情報５００１に登録されているか判定する（Ｓ１１３）。そして、トークン管理部５５は、受け取った認可コードが同一であり、かつ、受け取ったクライアント情報が登録されている場合に、トークン生成部５６に、アクセストークンを生成するよう指示する（Ｓ１１４）。

トークン生成部５６は、トークン管理部５５からの指示に応じて、アクセストークンを生成する（Ｓ１１５）。トークン生成部５６は、生成したアクセストークンを、トークン管理部５５に渡す（Ｓ１１６）。トークン管理部５５は、受け取ったアクセストークンを、通信端末１０のトークン取得部３３に送信する（Ｓ１１７）。

≪動作例 − クライアント情報の変更処理≫
図１０は、クライアント情報の変更処理を表すシーケンス図である。ここでは、図９に示される手順により、通信端末１０のクライアント３０が、アクセストークンを取得した後に、何者かが、クライアント３０の使用するクライアント情報と同一のクライアント情報を用いて、認証装置５０にアクセスしたものとする。図７は、そのような状況を、認証装置５０のアクセス記録部５７が記録した場合の例を表している。すなわち、図７において、ほぼ同一の時刻である「2014-04-04 13:00:01 JST」と「2014-04-04 13:00:00 JST」に、米国で使用されるＩＰアドレス「11.1.1.55」と、フランスで使用されるＩＰアドレス「90.1.1.120」から、同一のclient_idによるアクセスが記録されている。

認証装置５０の検知部５８は、図７に示されるアクセス情報を定期的又は不定期的に監視しており、上述した不正なアクセスを検知する（Ｓ２０１）。検知部５８は、サービス提供者に対して、電子メールにより、不正なアクセスが検知された旨を、client_idとともに通知する（Ｓ２０２）。

その後、認証装置５０の変更受付部５９は、サービス提供者からの求めに応じて、図８に示される、クライアント情報変更画面を提示し、サービス提供者から、クライアント情報の変更を受け付ける（Ｓ２０３）。変更受付部５９は、クライアント情報の変更を受け付けると、変更されたクライアント情報を、管理情報５００１に格納する（Ｓ２０４）。そして、変更受付部５９は、クライアント情報が変更された旨の通知を通信端末１０に送信するよう、通知部６０に指示する（Ｓ２０５）。

通知部６０は、変更受付部５９からの通知に応じて、通信端末１０のクライアント情報取得部３１に、クライアント情報が変更された旨の変更通知を送信する（Ｓ２０６）。これを受けて、通信端末１０のクライアント情報取得部３１は、認証装置５０のクライアント情報管理部５２に、クライアント情報の送信を要求する（Ｓ２０７）。認証装置５０のクライアント情報管理部５２は、変更されたクライアント情報を、通信端末１０に送信する（Ｓ２０８）。

≪効果≫
以上の構成により、本実施形態における認証システム１では、同じ種類のクライアントであっても、インストールされる単位でクライアントを識別するclient_secretを発行する。従って、client_secretが漏えいしても、client_secretを更新するために必要となる更新作業を、一のクライアントに対して行えば済むこととなる。これにより、クライアントを提供する提供者による、client_secretの管理コストが低減される。

なお、ＯＡｕｔｈ２．０では、スマートフォンやPCのような、client_secret漏洩の可能性があるクライアント向けに用意された、Implicit Flowの仕組みが用意されている。しかしながら、Implicit Flowでは、client_secretを使わないため、クライアントのなりすましが容易であるという性質がある。本発明は、client_secretを用いて、クライアントのなりすましを困難にする一方で、万が一、client_secretが漏えいした場合であっても、その影響を、漏えいしたclient_secretを使用していたクライアントに限定することができる。

図１０は、クライアントＡで共通のclient_id、client_secretを持つ従来の方式（ａ）と、クライアントＡのインストール単位で異なるclient_id、client_secretを持つ本実施形態による方式（ｂ）とにおける、client_secretの漏えい時の影響を比較する図である。図１０に示されるように、従来の方式では、全てのユーザ環境にインストールされたクライアントＡのclient_id, client_secretは、共通である。このため、client_secretが漏えいした場合、これらを再発行、更新するために、全ユーザを対象として、作業を行う必要が生ずる。

しかしながら、本実施形態を用いると、例えばユーザ１の環境からclient_secretが漏えいしても、他ユーザは、異なるclient_secretを用いて、継続して認証処理を行うことができる。従って、サービス提供者は、ユーザ１のclient_secretのみを再発行、更新すればよいことになる。

このように、本実施形態に従う認証システム１を提供することにより、アクセストークンの生成に用いられるクライアント情報が漏えいした場合の影響を、最低限に抑えることができる。

１認証システム
２インターネット
１０通信端末
３０クライアント
５０認証装置
７０クライアント提供装置

特開２００７−５１５１２７号公報

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

Claims

通信端末と、アクセストークンを用いて前記通信端末に機能を提供する認証装置とを有する認証システムであって、
アクセストークンの発行に必要な、前記通信端末にインストールされるアプリケーションごとに生成されるクライアント情報を、前記認証装置に対して要求する第一要求部と、
前記第一要求部からの要求に応じて、前記クライアント情報を生成し、該クライアント情報を前記通信端末に送信する第一送信部と、
前記クライアント情報を前記認証装置に送信し、該認証装置に対してアクセストークンを要求する第二要求部と、
前記第二要求部からの要求に応じて、受信された前記クライアント情報が、前記第一送信部により送信されたクライアント情報であるか判定する判定部と、
受信された前記クライアント情報が、前記第一送信部により送信されたクライアント情報であると判定された場合に、アクセストークンを生成する生成部と、
生成された前記アクセストークンを前記通信端末に送信する第二送信部と、
前記通信端末からのアクセス記録を記録する記録部と、
記録された前記アクセス記録に基づいて不正なアクセスを検知する検知部と、
前記検知部が不正なアクセスを検知したことに応じて、前記アプリケーションの提供者に、前記クライアント情報を変更するよう通知する通知部と、
を有する、認証システム。
通信端末と、アクセストークンを用いて前記通信端末に機能を提供する認証装置とを有する認証システムで実行される認証方法であって、
アクセストークンの発行に必要な、前記通信端末にインストールされるアプリケーションごとに生成されるクライアント情報を、前記認証装置に対して要求する第一要求段階と、
前記第一要求段階において受け付けた要求に応じて、前記クライアント情報を生成する生成段階と、
生成された前記クライアント情報を前記通信端末に送信する第一送信段階と、
前記クライアント情報を前記認証装置に送信し、該認証装置に対してアクセストークンを要求する第二要求段階と、
前記第二要求段階において受け取った要求に応じて、受信された前記クライアント情報が、前記第一送信段階において送信されたクライアント情報であるか判定する判定段階と、
受信された前記クライアント情報が、前記第一送信段階において送信されたクライアント情報であると判定された場合に、アクセストークンを生成する生成段階と、
生成された前記アクセストークンを前記通信端末に送信する第二送信段階と、
前記通信端末からのアクセス記録を記録する記録段階と、
記録された前記アクセス記録に基づいて不正なアクセスを検知する検知段階と、
前記検知段階が不正なアクセスを検知したことに応じて、前記アプリケーションの提供者に、前記クライアント情報を変更するよう通知する通知段階と、
を有する、認証方法。
アクセストークンを用いて通信端末に機能を提供する認証装置であって、
前記通信端末から、アクセストークンの発行に必要な、前記通信端末にインストールされるアプリケーションごとに生成されるクライアント情報の要求を受け付ける受付部と、
前記要求に応じて、前記クライアント情報を生成し、該クライアント情報を前記通信端末に送信する第一送信部と、
前記通信端末から、前記クライアント情報を含む、前記アクセストークンの発行要求を受信する受信部と、
前記発行要求に応じて、受信された前記クライアント情報が、前記第一送信部により送信されたクライアント情報であるか判定する判定部と、
受信された前記クライアント情報が、前記第一送信部により送信されたクライアント情報であると判定された場合に、アクセストークンを生成する生成部と、
生成された前記アクセストークンを前記通信端末に送信する第二送信部と、
前記通信端末からのアクセス記録を記録する記録部と、
記録された前記アクセス記録に基づいて不正なアクセスを検知する検知部と、
前記検知部が不正なアクセスを検知したことに応じて、前記アプリケーションの提供者に、前記クライアント情報を変更するよう通知する通知部と、
を有する、認証装置。
アクセストークンを用いて通信端末に機能を提供するコンピュータに、
前記通信端末から、アクセストークンの発行に必要な、前記通信端末にインストールされるアプリケーションごとに生成されるクライアント情報の要求を受け付ける受付段階と、
前記要求に応じて、前記クライアント情報を生成し、該クライアント情報を前記通信端末に送信する第一送信段階と、
前記通信端末から、前記クライアント情報を含む、前記アクセストークンの発行要求を受信する受信段階と、
前記発行要求に応じて、受信された前記クライアント情報が、前記第一送信段階において送信されたクライアント情報であるか判定する判定段階と、
受信された前記クライアント情報が、前記第一送信段階において送信されたクライアント情報であると判定された場合に、アクセストークンを生成する生成段階と、
生成された前記アクセストークンを前記通信端末に送信する第二送信段階と、
前記通信端末からのアクセス記録を記録する記録段階と、
記録された前記アクセス記録に基づいて不正なアクセスを検知する検知段階と、
前記検知段階が不正なアクセスを検知したことに応じて、前記アプリケーションの提供者に、前記クライアント情報を変更するよう通知する通知段階と、
を実行させる、プログラム。