(57)【要約】【課題】  上記の課題に鑑みてなされたものであり、ユーザ毎かつサービス毎にアクセストークンを発行できる認可サーバ及びリソース提供システムを提供する。【解決手段】  一実施形態に係る認可サーバは、ユーザがサービスを利用するためのクライアントに関する情報であるクライアント情報を記憶するクライアント情報記憶部と、前記ユーザ毎かつ前記サービス毎に登録されたアカウントに関するアカウント情報を記憶するアカウント情報記憶部と、前記クライアントからアクセストークンの発行を要求されると、前記クライアント情報及び前記アカウント情報に基づいて、前記ユーザを認証し、前記ユーザの認証が成功した場合、認証された前記ユーザの前記アカウントに応じたアクセストークンを、前記クライアントに発行する認証部と、を備える。【選択図】  図３
2018084979.tif 000002
【特許請求の範囲】
【請求項１】
ユーザがサービスを利用するためのクライアントに関する情報であるクライアント情報を記憶するクライアント情報記憶部と、
前記ユーザ毎かつ前記サービス毎に登録されたアカウントに関するアカウント情報を記憶するアカウント情報記憶部と、
前記クライアントからアクセストークンの発行を要求されると、前記クライアント情報及び前記アカウント情報に基づいて、前記ユーザを認証し、前記ユーザの認証が成功した場合、認証された前記ユーザの前記アカウントに応じたアクセストークンを、前記クライアントに発行する認証部と、
を備える認可サーバ。
【請求項２】
前記クライアント情報は、前記クライアントを識別する識別子と、前記クライアントに設定されたパスワードと、前記クライアントにより利用される前記サービスを識別する識別子と、を含む
請求項１に記載の認可サーバ。
【請求項３】
前記アカウント情報は、前記アカウントを識別する識別子と、前記アカウントを所有する前記ユーザを識別する識別子と、前記アカウントに設定されたパスワードと、前記アカウントが登録された前記サービスを識別する識別子と、を含む
請求項１又は請求項２に記載の認可サーバ。
【請求項４】
前記認証部は、前記クライアントから、前記ユーザを識別する識別子と、前記ユーザの前記アカウントに設定されたパスワードと、前記クライアントを識別する識別子と、前記クライアントに設定されたパスワードと、を受信する
請求項１乃至請求項３のいずれか１項に記載の認可サーバ。
【請求項５】
前記認証部は、前記クライアントから受信した前記クライアントを識別する識別子及び前記クライアントに設定された前記パスワードと、前記クライアント情報と、に基づいて、前記クライアントにより利用する前記サービスを識別する識別子を特定する
請求項４に記載の認可サーバ。
【請求項６】
前記認証部は、特定された前記サービスを識別する識別子と、前記クライアントから受信した、前記ユーザを識別する識別子及び前記アカウントに設定されたパスワードと、に基づいて、前記ユーザを認証する
請求項５に記載の認可サーバ。
【請求項７】
請求項１乃至請求項６のいずれか１項に記載の認可サーバと、
前記クライアントから受信した前記アクセストークンに基づいて、前記クライアントにリソースを提供するリソースサーバと、
を備えるリソース提供システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認可サーバ及びリソース提供システムに関する。
【背景技術】
【０００２】
ＯＡｕｔｈ２．０では、クライアントがユーザにリソースへのアクセス（リソースの利用）の認可を要求し、ユーザが認可グラントを入力し、これを利用してクライアントが認可サーバにアクセストークンの発行を要求するフローが知られている。アクセストークンの発行を要求された認可サーバは、認可グラントに基づいて、ユーザを認証し、リソースへのアクセスを認可し、アクセストークンを発行する。クライアントは、このアクセストークンを利用することにより、リソースへアクセスすることができる。
【０００３】
ＯＡｕｔｈ２．０では、認可グラントとして、リソースオーナーパスワードクレデンシャルが利用できる。このリソースオーナーパスワードクレデンシャルは、ユーザＩＤやパスワードなどのユーザ情報に相当する。すなわち、クライアントは、ユーザから入力されたユーザ情報を利用することにより、認可サーバからアクセストークンを取得し、リソースへアクセスすることができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来の認可サーバは、同一のユーザ情報を利用してアクセストークンの発行を要求された場合、ユーザが利用するサービスが異なる場合であっても、ユーザのアカウントを区別することができなかった。したがって、認可サーバは、ユーザ毎にアクセストークンを発行できるものの、サービス毎にアクセストークンを発行することができなかった。
【０００５】
本発明は、上記の課題に鑑みてなされたものであり、ユーザ毎かつサービス毎にアクセストークンを発行できる認可サーバ及びリソース提供システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
一実施形態に係る認可サーバは、ユーザがサービスを利用するためのクライアントに関する情報であるクライアント情報を記憶するクライアント情報記憶部と、前記ユーザ毎かつ前記サービス毎に登録されたアカウントに関するアカウント情報を記憶するアカウント情報記憶部と、前記クライアントからアクセストークンの発行を要求されると、前記クライアント情報及び前記アカウント情報に基づいて、前記ユーザを認証し、前記ユーザの認証が成功した場合、認証された前記ユーザの前記アカウントに応じたアクセストークンを、前記クライアントに発行する認証部と、を備える。
【発明の効果】
【０００７】
本発明の各実施形態によれば、ユーザ毎かつサービス毎にアクセストークンを発行できる認可サーバ及びリソース提供システムを提供することができる。
【図面の簡単な説明】
【０００８】
【図１】リソース提供システムの構成の一例を示す図。
【図２】認可サーバのハードウェア構成の一例を示す図。
【図３】認可サーバの機能構成の一例を示す図。
【図４】クライアントテーブルの一例を示す図。
【図５】アカウントテーブルの一例を示す図。
【図６】サービステーブルの一例を示す図。
【図７】アクセストークンの発行処理の一例を示すフローチャート。
【図８】リソースサーバの機能構成の一例を示す図。
【図９】リソーステーブルの一例を示す図。
【図１０】リソースの提供処理の一例を示すフローチャート。
【発明を実施するための形態】
【０００９】
以下、本発明の各実施形態について、添付の図面を参照しながら説明する。なお、各実施形態に係る明細書及び図面の記載に関して、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重畳した説明を省略する。
【００１０】
＜第１実施形態＞
第１実施形態に係るリソース提供システムについて、図１〜図７を参照して説明する。本実施形態に係るリソース提供システムは、ＯＡｕｔｈ２．０に従って、クライアントにアクセストークンを発行し、アクセストークンに応じたリソースを提供するシステムである。
【００１１】
まず、リソース提供システムの構成について説明する。図１は、リソース提供システムの構成の一例を示す図である。図１のリソース提供システムは、認可サーバ１と、クライアント端末２と、リソースサーバ３と、ネットワーク４と、により構成される。
【００１２】
認可サーバ１は、クライアントにアクセストークンを発行するサーバコンピュータである。認可サーバ１は、クライアントから、リソースにアクセスするためのアクセストークンの発行を要求されると、当該クライアントを利用しているユーザを認証し、認証に成功した場合、リソースへのアクセスを認可し、クライアントにアクセストークンを発行する。アクセストークンは、クライアントがリソースへのアクセスを認可されたことを示す文字列であり、クライアントがアクセス可能なリソースの範囲及び期間を定義する。
【００１３】
本実施形態において、認可サーバ１は、ユーザ毎かつサービス毎にアカウントを予め登録され、当該アカウント毎にアクセストークンを発行する。すなわち、認可サーバ１は、ユーザ毎かつサービス毎にアクセストークンを発行する。認可サーバ１について、詳しくは後述する。なお、図１の例では、認可サーバ１が１つのサーバコンピュータにより構成される場合を想定しているが、認可サーバ１は、複数のサーバコンピュータにより構成されてもよい。
【００１４】
クライアント端末２は、ユーザがサービスを利用するためのクライアントコンピュータである。ここでいうサービスには、会議サービス、通訳サービス、ＳＮＳ（Social Networking Service）及びウェブメールなどの、インターネット上で提供される任意のサービスが含まれる。また、ここでいうユーザは、ＯＡｕｔｈ２．０におけるエンドユーザ（リソースオーナー）に相当する。
【００１５】
ユーザは、クライアント端末２を介してクライアントを操作することにより、サービスを利用する。ここでいうクライアントとは、サービスを利用するためのクライアントアプリケーションのことである。クライアントは、クライアント端末２上で動作してもよいし、サービスを提供するサーバ上で動作してもよい。いずれの場合も、クライアントは、クライアント端末２を介して操作される。
【００１６】
クライアントは、認可サーバ１に、リソースにアクセスするためのアクセストークンの発行を要求し、発行されたアクセストークンを利用して、リソースサーバ３にリソースを要求し、リソースを取得する。クライアントがリソースを取得することにより、ユーザは、自分のリソースを利用して、サービスを利用することができる。
【００１７】
リソースサーバ３は、クライアントにリソースを提供するサーバコンピュータである。リソースサーバ３は、各サービスにおけるユーザ毎のリソースを保存する。また、リソースサーバ３は、クライアントからリソースを要求されると、クライアントから受信したアクセストークンを検証し、アクセストークンで定められたリソースの範囲及び期間に従って、クライアントにリソースを提供する。
【００１８】
リソースとは、ユーザがクライアントを利用するために必要であり、かつ、クライアントがアクセスするためにユーザからの認可が必要なデータのことである。例えば、会議サービスや通訳サービスのリソースとして、アドレス帳などのデータが挙げられる。リソースサーバ３について、詳しくは後述する。なお、図１の例では、リソースサーバ３が１つのサーバコンピュータにより構成される場合を想定しているが、リソースサーバ３は、複数のサーバコンピュータにより構成されてもよい。
【００１９】
ネットワーク４は、ＬＡＮ（Local Area Network）やインターネットなどの通信ネットワークである。ネットワーク４は、認可サーバ１、クライアント端末２及びリソースサーバ３を接続する。認可サーバ１、クライアント端末２及びリソースサーバ３の間の通信は、ネットワーク４を介して行われる。
【００２０】
次に、認可サーバ１のハードウェア構成について説明する。なお、クライアント端末２及びリソースサーバ３のハードウェア構成は、認可サーバ１と同様であるため説明を省略する。
【００２１】
図２は、認可サーバ１のハードウェア構成の一例を示す図である。図２の認可サーバ１は、ＣＰＵ（Central Processing Unit）１０１と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、ＨＤＤ（Hard Disk Drive）１０４と、を備える。また、認可サーバ１は、入力装置１０５と、表示装置１０６と、ネットワークインタフェース１０７と、バス１０８と、を備える。
【００２２】
ＣＰＵ１０１は、プログラムを実行することにより、各構成を制御し、認可サーバ１の機能を実現する。ＲＯＭ１０２は、ＣＰＵ１０１が実行するプログラムや設定値を含む各種のデータを記憶する。ＲＡＭ１０３は、ＣＰＵ１０１に作業領域を提供する。ＨＤＤ１０４は、ＣＰＵ１０１が実行するプログラムや設定値を含む各種のデータを記憶する。入力装置１０５は、ユーザの操作を受け付け、認可サーバ１に各種の情報を入力する。入力装置１０５は、例えば、マウス、キーボード、タッチパネル、ハードウェアキーなどである。表示装置１０６は、認可サーバ１が保持している各種の情報を表示する。表示装置１０６は、例えば、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ、ブラウン管ディスプレイなどである。ネットワークインタフェース１０７は、認可サーバ１をネットワーク４に接続するためのインタフェースである。認可サーバ１は、ネットワークインタフェース１０７を介して、ネットワーク４に接続された外部装置（クライアント端末２やリソースサーバ３）と通信する。バス１０８は、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、ＨＤＤ１０４、入力装置１０５、表示装置１０６及びネットワークインタフェース１０７を接続する。
【００２３】
次に、認可サーバ１の機能構成について説明する。図３は、認可サーバ１の機能構成の一例を示す図である。図３の認可サーバ１は、クライアント情報記憶部１１と、アカウント情報記憶部１２と、サービス情報記憶部１３と、認証部１４と、を備える。これらの各機能構成は、ＣＰＵ１０１がプログラムを実行することにより実現される。
【００２４】
クライアント情報記憶部１１は、認可サーバ１によるアクセストークンの発行対象として登録された各クライアントのクライアント情報を予め記憶する。クライアント情報には、クライアントＩＤと、シークレットと、クライアント名と、サービスＩＤと、が含まれる。クライアントＩＤは、クライアントを識別する識別子である。シークレットは、クライアントに設定されたパスワードである。クライアント名は、クライアントの名称である。サービスＩＤは、クライアントにより利用されるサービスを識別する識別子である。クライアント情報記憶部１１は、各クライアントのクライアント情報を保存するためのクライアントテーブルを備える。
【００２５】
図４は、クライアントテーブルの一例を示す図である。図４の各レコードが、各クライアントのクライアント情報に相当する。図４の例では、１行目のレコードに対応するクライアントのクライアントＩＤは「ABC」、シークレットは「Secret1」、クライアント名は「第１ＯＳ（Operation System）用会議クライアント」、サービスＩＤは「S001」である。また、２行目のレコードに対応するクライアントのクライアントＩＤは「DEF」、シークレットは「Secret2」、クライアント名は「第２ＯＳ用会議クライアント」、サービスＩＤは「S001」である。このように、本実施形態に係る認可サーバ１は、同一のサービスを利用するためのクライアントが複数用意される場合にも適用可能である。なお、クライアント情報は、図４の例に限られず、クライアントに関する任意の情報を含み得る。
【００２６】
アカウント情報記憶部１２は、認可サーバ１によるアクセストークンの発行対象として登録されたアカウントのアカウント情報を予め記憶する。アカウント情報には、アカウントＩＤと、ユーザＩＤと、パスワードと、サービスＩＤと、が含まれる。アカウントＩＤは、アカウントを識別する識別子である。アカウントＩＤは、ユーザ毎かつサービス毎に割り当てられる。ユーザＩＤは、アカウントを所有するユーザを識別する識別子である。ユーザＩＤとして、ユーザのメールアドレスやユーザ名を利用できる。パスワードは、アカウントに設定されたパスワードである。サービスＩＤは、アカウントが登録されたサービスを識別する識別子である。アカウント情報記憶部１２は、各アカウントのアカウント情報を保存するためのアカウントテーブルを備える。
【００２７】
図５は、アカウントテーブルの一例を示す図である。図５の各レコードが、各アカウントのアカウント情報に相当する。図５の例では、ユーザＩＤはメールアドレスであり、１行目のレコードに対応するアカウントのアカウントＩＤは「A001」、ユーザＩＤは「user1@example.com」、パスワードは「pass1」、サービスＩＤは「Ｐ００１」である。また、２行目のレコードに対応するアカウントのアカウントＩＤは「A002」、ユーザＩＤは「user2@example.com」、パスワードは「pass2」、サービスＩＤは「Ｐ００２」である。また、３行目のレコードに対応するアカウントのアカウントＩＤは「A003」、ユーザＩＤは「user1@example.com」、パスワードは「pass1」、サービスＩＤは「Ｐ００２」である。このように、本実施形態では、アカウントは、ユーザ毎かつサービス毎に登録される。なお、アカウント情報は、図５の例に限られず、アカウントに関する任意の情報を含み得る。
【００２８】
サービス情報記憶部１３は、認可サーバ１によるアクセストークンの発行対象として登録された各サービスのサービス情報を予め記憶する。サービス情報には、サービスＩＤと、サービス名と、が含まれる。サービスＩＤは、サービスを識別する識別子である。サービス名は、サービスの名称である。サービス情報記憶部１３は、各サービスのサービス情報を保存するためのサービステーブルを備える。
【００２９】
図６は、サービステーブルの一例を示す図である。図６の各レコードが、各サービスのサービス情報に相当する。図６の例では、１行目のレコードに対応するサービスのサービスＩＤは「S001」、サービス名は「会議サービス」である。また、２行目のレコードに対応するサービスのサービスＩＤは「S002」、サービス名は「通訳サービス」である。図６の例では、会議サービスを利用するためのクライアントとして、第１ＯＳ用会議クライアント及び第２ＯＳ用会議クライアントが用意され、通訳サービスを利用するためのクライアントとして、通訳クライアントが用意されている場合を想定している。なお、サービス情報は、図６の例に限られない。
【００３０】
認証部１４は、クライアントから、リソースにアクセスするためのアクセストークンの発行を要求されると、クライアントから受信した情報に基づいて、ユーザを認証する。認証部１４は、ユーザの認証に成功した場合、リソースへのアクセスを認可し、ユーザのアカウントに応じたアクセストークンをクライアントに発行する。すなわち、認証部１４は、アクセストークンを生成し、生成したアクセストークンをクライアントに送信する。認証部１４は、アクセストークンの生成方法として、既存の任意の方法を利用できる。
【００３１】
次に、本実施形態に係るリソース提供システムが実行するアクセストークンの発行処理について説明する。図７は、アクセストークンの発行処理の一例を示すフローチャートである。
【００３２】
まず、クライアントがユーザに、リソースへのアクセスの認可を要求する（ステップＳ１０１）。具体的には、クライアントは、クライアント端末２の表示装置１０６にユーザ情報の入力画面を表示する。
【００３３】
ユーザは、入力画面が表示されると、当該入力画面に自分のユーザ情報を入力する（ステップＳ１０２）。ユーザ情報は、ユーザに関する情報であり、ユーザＩＤと、パスワードと、を含む。ユーザＩＤは、ユーザを識別する識別子である。パスワードは、ユーザが所有するアカウントに設定されたパスワードである。
【００３４】
クライアントは、ユーザ情報を入力されると、認可サーバ１の認証部１４にアクセストークンの発行を要求する（ステップＳ１０３）。この際、クライアントは、ユーザから入力されたユーザ情報（ユーザＩＤ及びパスワード）と、自分のクライアントＩＤ及びシークレットと、を認証部１４に送信する。
【００３５】
認証部１４は、クライアントからアクセストークンの発行を要求されると、当該クライアントのアカウントの認証処理を開始する。認証部１４は、まず、クライアントから受信したクライアントＩＤ及びシークレットを、クライアント情報記憶部１１に渡す（ステップＳ１０４）。
【００３６】
クライアント情報記憶部１１は、クライアントＩＤ及びシークレットを受け取ると、クライアントテーブルを参照して、受け取ったクライアントＩＤ及びシークレットと一致するクライアント情報を有するクライアントを探索する。
【００３７】
クライアント情報記憶部１１は、受け取ったクライアントＩＤ及びシークレットと一致するクライアント情報を有するクライアントが見つかった場合、見つかったクライアントのサービスＩＤを認証部１４に返す（ステップＳ１０５）。これにより、認証部１４は、クライアントにより利用されるサービスのサービスＩＤを特定できる。
【００３８】
一方、クライアント情報記憶部１１は、受け取ったクライアントＩＤ及びシークレットと一致するクライアント情報を有するクライアントが見つからない場合、その旨を認証部１４に通知する。この通知を受けた認証部１４は、認証に失敗したことをクライアントに通知する。この通知を受けたクライアントは、認証に失敗したことをユーザに通知する。例えば、クライアントは、クライアント端末２の表示装置１０６に、認証が失敗したことを通知するメッセージを表示する。
【００３９】
認証部１４は、クライアント情報記憶部１１からサービスＩＤを受け取ると、受け取ったサービスＩＤと、クライアントから受信したユーザＩＤと、をアカウント情報記憶部１２に渡す（ステップＳ１０６）。
【００４０】
アカウント情報記憶部１２は、ユーザＩＤ及びサービスＩＤを受け取ると、アカウントテーブルを参照して、ユーザＩＤ及びサービスＩＤが一致するアカウント情報を有するアカウントを探索する。
【００４１】
アカウント情報記憶部１２は、受け取ったユーザＩＤ及びサービスＩＤと一致するアカウント情報を有するアカウントが見つかった場合、見つかったアカウントのパスワード及びアカウントＩＤを、認証部１４に返す（ステップＳ１０７）。これにより、認証部１４は、ユーザのアカウントのアカウントＩＤ及びパスワードを特定できる。
【００４２】
一方、アカウント情報記憶部１２は、受け取ったユーザＩＤ及びサービスＩＤと一致するアカウント情報を有するアカウントが見つからない場合、その旨を認証部１４に通知する。この通知を受けた認証部１４は、認証に失敗したことをクライアントに通知する。この通知を受けたクライアントは、認証に失敗したことをユーザに通知する。例えば、クライアントは、クライアント端末２の表示装置１０６に、認証が失敗したことを通知するメッセージを表示する。
【００４３】
認証部１４は、アカウント情報記憶部１２からパスワード及びアカウントＩＤを受け取ると、受け取ったパスワードと、クライアントから受信したパスワードと、を比較する（ステップＳ１０８）。
【００４４】
認証部１４は、受け取ったパスワードと、クライアントから受信したパスワードと、が一致した場合、リソースへのアクセスを認可したユーザが、受け取ったアカウントＩＤを有するアカウントを所有する正当なユーザであると判断し、当該ユーザを認証する。
【００４５】
認証部１４は、ユーザを認証すると、受け取ったアカウントＩＤを有するアカウントに、クライアントがアクセス可能なリソースの範囲及び機関などの権限を付与し、付与した権限の範囲内でのクライアントによるリソースへのアクセスを認可する。アカウントに付与する権限は、認可サーバ１に予め登録されていてもよいし、ステップＳ１０２において、ユーザ情報と共にユーザにより入力されてもよい。
【００４６】
認証部１４は、クライアントによるリソースへのアクセスを認可すると、アカウントに付与された権限及びアカウントＩＤに応じたアクセストークンを生成する（ステップＳ１０９）。この際、認証部１４は、アクセストークンを発行したのが認可サーバ１であることを証明する電子署名を、アクセストークンに付与する。その後、認証部１４は、生成したアクセストークンをクライアントに送信する（ステップＳ１１０）。これにより、クライアントにアクセストークンが発行される。
【００４７】
以降、クライアントは、発行されたアクセストークンを利用して、リソースサーバ３にリソースを要求し、リソースを取得することができる。
【００４８】
ここで、図７の発行処理について具体的に説明する。以下では、クライアント情報記憶部１１は、図４のクライアントテーブルを備え、アカウント情報記憶部１２は、図５のアカウントテーブルを備えるものとする。また、ユーザは、アカウントＩＤが「A001」であるアカウント（以下、「アカウントA001」という）及び「A003」であるアカウント（以下、「アカウントA003」という）を所有するユーザ（以下、「ユーザＵ１」）であるものとする。
【００４９】
以下では、ユーザＵ１が、第１ＯＳ用会議クライアントを利用する場合の発行処理と、第２ＯＳ用会議クライアントを利用する場合の発行処理と、についてそれぞれ説明する。
【００５０】
ユーザＵ１が、第１ＯＳ用会議クライアントを利用する場合、第１ＯＳ用会議クライアントは、ユーザ情報の入力画面を表示して、ユーザＵ１にリソースへのアクセスの認可を要求する（ステップＳ１０１）。ユーザＵ１は、入力画面に自分のユーザＩＤ（user1@example.com）及びパスワード（pass1）を入力する（ステップＳ１０２）。
【００５１】
次に、第１ＯＳ用会議クライアントは、認可サーバ１の認証部１４にアクセストークンの発行を要求する（ステップＳ１０３）。この際、第１ＯＳ用会議クライアントは、ユーザＵ１が入力したユーザＩＤ（user1@example.com）及びパスワード（pass1）と、自分のクライアントＩＤ（ABC）及びシークレット（Secret1）と、を認証部１４に送信する。
【００５２】
認証部１４は、第１ＯＳ用会議クライアントからアクセストークンの発行を要求されると、クライアントＩＤ（ABC）及びシークレット（Secret1）を、クライアント情報記憶部１１に渡す（ステップＳ１０４）。クライアント情報記憶部１１は、クライアントＩＤ（ABC）及びシークレット（Secret1）と一致するクライアント情報を有する第１ＯＳ用会議クライアントのサービスＩＤ（S001）を認証部１４に返す（ステップＳ１０５）。
【００５３】
次に、認証部１４は、受け取ったサービスＩＤ（S001）と、第１ＯＳ用会議クライアントから受信したユーザＩＤ（user1@example.com）と、をアカウント情報記憶部１２に渡す（ステップＳ１０６）。アカウント情報記憶部１２は、ユーザＩＤ（user1@example.com）及びサービスＩＤ（S001）と一致するアカウント情報を有するアカウントA001のパスワード（pass1）及びアカウントＩＤ（A001）を、認証部１４に返す（ステップＳ１０７）。
【００５４】
続いて、認証部１４は、受け取ったパスワード（pass1）と、第１ＯＳ用会議クライアントから受信したパスワード（pass1）と、を比較する（ステップＳ１０８）。これらのパスワードは一致するため、認証部１４は、リソースへのアクセスを認可したユーザＵ１が、アカウントA001を所有する正当なユーザであると判断し、ユーザＵ１を認証する。
【００５５】
その後、認証部１４は、アカウントA001にアクセス可能なリソースの範囲や期間などを付与し、当該権限の範囲内でのリソースへのアクセスを認可する。そして、認証部１４は、アカウントA001に付与されたアカウントＩＤ（A001）及び権限に応じたアクセストークンを生成し（ステップＳ１０９）、生成したアクセストークンを第１ＯＳ用会議クライアントに送信する（ステップＳ１１０）。
【００５６】
以降、第１ＯＳ用会議クライアントは、発行されたアクセストークンを利用して、リソースサーバ３にリソース（アドレス帳などのデータ）を要求し、リソースを取得することができる。
【００５７】
これに対して、ユーザＵ１が、通訳クライアントを利用する場合、通訳クライアントは、ユーザ情報の入力画面を表示し、ユーザＵ１にリソースへのアクセスの認可を要求する（ステップＳ１０１）。ユーザＵ１は、入力画面に自分のユーザＩＤ（user1@example.com）及びパスワード（pass1）を通訳クライアントに入力する（ステップＳ１０２）。
【００５８】
次に、通訳クライアントは、認可サーバ１の認証部１４にアクセストークンの発行を要求する（ステップＳ１０３）。この際、通訳クライアントは、ユーザＵ１が入力したユーザＩＤ（user1@example.com）及びパスワード（pass1）と、自分のクライアントＩＤ（XYZ）及びシークレット（Secret3）と、を認証部１４に送信する。
【００５９】
認証部１４は、クライアントからアクセストークンの発行を要求されると、クライアントＩＤ（XYZ）及びシークレット（Secret3）を、クライアント情報記憶部１１に渡す（ステップＳ１０４）。クライアント情報記憶部１１は、クライアントＩＤ（XYZ）及びシークレット（Secret3）と一致するクライアント情報を有する通訳クライアントのサービスＩＤ（S002）を認証部１４に返す（ステップＳ１０５）。
【００６０】
次に、認証部１４は、受け取ったサービスＩＤ（S002）と、クライアントから受信したユーザＩＤ（user1@example.com）と、をアカウント情報記憶部１２に渡す（ステップＳ１０６）。アカウント情報記憶部１２は、ユーザＩＤ（user1@example.com）及びサービスＩＤ（S002）と一致するアカウント情報を有するアカウントA003のパスワード（pass1）及びアカウントＩＤ（A003）を、認証部１４に返す（ステップＳ１０７）。
【００６１】
続いて、認証部１４は、受け取ったパスワード（pass1）と、クライアントから受信したパスワード（pass1）と、を比較する（ステップＳ１０８）。これらのパスワードは一致するため、認証部１４は、リソースへのアクセスを認可したユーザＵ１が、アカウントA003を所有する正当なユーザであると判断し、ユーザＵ１を認証する。
【００６２】
その後、認証部１４は、アカウントA003に、通訳クライアントがアクセス可能なリソースの期間及び範囲などの権限を付与し、権限の範囲内での通訳クライアントによるリソースへのアクセスを認可する。そして、認証部１４は、アカウントA003に付与されたアカウントＩＤ（A003）及び権限に応じたアクセストークンを生成し（ステップＳ１０９）、生成したアクセストークンを通訳クライアントに送信する（ステップＳ１１０）。
【００６３】
以降、通訳クライアントは、発行されたアクセストークンを利用して、リソースサーバ３にリソース（アドレス帳などのデータ）を要求し、リソースを取得することができる。
【００６４】
以上説明した通り、本実施形態によれば、認可サーバ１は、同一のユーザ情報を利用してアクセストークンの発行を要求された場合であっても、利用されるサービスが異なる場合、サービス毎に異なるアクセストークンを発行することができる。すなわち、認可サーバ１は、ユーザ毎かつサービス毎にアクセストークンを発行することができる。したがって、本実施形態によれば、ユーザは、サービス毎に、アクセス可能なリソースの権限を設定することができる。これにより、リソースサーバ３に記憶されたリソースが、複数のサービスにより共用される場合であっても、サービス毎にアクセス可能なリソースを管理することができる。
【００６５】
＜第２実施形態＞
第２実施形態について、図８〜図１０を参照して説明する。本実施形態では、クライアントへのリソースの提供方法の一例について説明する。なお、リソース提供システムの各構成は、第１実施形態と同様である。
【００６６】
図８は、リソースサーバ３の機能構成の一例を示す図である。図８のリソースサーバ３は、リソース提供部３１と、検証部３２と、リソース記憶部３３と、を備える。これらの各機能構成は、リソースサーバ３のＣＰＵがプログラムを実行することにより実現される。
【００６７】
リソース提供部３１は、クライアントからリソースを要求されると、クライアントから受信したアクセストークンに基づいて、クライアントにリソースを提供する。
【００６８】
検証部３２は、クライアントからのリソース要求が有効であるか否か検証する。検証部３２により有効なリソース要求であることが検証された場合、リソース提供部３１は、クライアントにリソースを提供する。
【００６９】
リソース記憶部３３は、リソースと、各ユーザのリソース情報と、を記憶する。リソース情報は、ユーザが所有するリソースに関する情報であり、アカウントＩＤと、リソースＩＤと、を含む。アカウントＩＤは、ユーザが所有するアカウントを識別する識別子である。リソースＩＤは、ユーザが所有するリソースを識別する識別子である。リソースＩＤとして、例えば、ＵＲＩ（Uniform Resource Identifier）を利用できる。リソース記憶部３３は、各ユーザのリソース情報を保存するためのリソーステーブルを備える。
【００７０】
図９は、リソーステーブルの一例を示す図である。図９の各レコードが、各ユーザのリソース情報に相当する。図９の例では、１行目のレコードに対応するユーザのアカウントＩＤは「A001」、リソースＩＤは「Ｒ００１，Ｒ００２，Ｒ００３」である。また、２行目のレコードに対応するユーザのアカウントＩＤは「A002」、リソースＩＤは「Ｒ００４，Ｒ００５」である。このように、リソース記憶部３３は、各ユーザについて、複数のリソースを記憶し得る。なお、リソース情報は、図９の例に限られず、リソースに関する任意の情報を含み得る。
【００７１】
次に、本実施形態に係るリソース提供システムが実行するリソースの提供処理について説明する。図１０は、リソースの提供処理の一例を示すフローチャートである。なお、以下では、アクセストークンには、アクセスを認可されたリソースＩＤが含まれるものとする。すなわち、認可サーバ１の認証部がリソースＩＤを含むアクセストークンを生成するものとする。
【００７２】
まず、クライアントがリソースサーバ３のリソース提供部３１に、リソースを要求する（ステップＳ２０１）。この際、クライアントは、要求するリソースのリソースＩＤと、認可サーバ１から発行されたアクセストークンと、をリソース提供部３１に送信する。
【００７３】
リソース提供部３１は、クライアントからリソースを要求されると、クライアントから受信したリソースＩＤ及びアクセストークンを検証部３２に渡す（ステップＳ２０２）。
【００７４】
検証部３２は、リソースＩＤ及びアクセストークンを受け取ると、リソース要求が有効であるか否か検証する（ステップＳ２０３）。具体的には、検証部３２は、アクセストークンに付与された電子署名を確認し、受信したアクセストークンが認可サーバ１により発行されたものであるか確認する。受信したアクセストークンが認可サーバ１により発行されたものであることが確認された場合、検証部３２は、アクセストークンに含まれるリソースＩＤと、クライアントから受信したリソースＩＤと、が一致するか確認する。アクセストークンに含まれるリソースＩＤと、クライアントから受信したリソースＩＤと、が一致する場合、検証部３２は、リソース要求は有効であると判断し、その旨をリソース提供部３１に通知する（ステップＳ２０４）。
【００７５】
なお、検証部３２は、クライアントからのリソース要求が、有効なリソース要求でない（無効なリソース要求である）と判断した場合、その旨をリソース提供部３１に通知する。この通知を受けたリソース提供部３１は、リソースを提供できないことをクライアントに通知する。この通知を受けたクライアントは、リソースを取得できないことをユーザに通知する。例えば、クライアントは、クライアント端末２の表示装置１０６に、リソースを取得できないことを通知するメッセージを表示する。
【００７６】
リソース提供部３１は、検証部３２から有効なリソース要求であることを通知されると、リソース記憶部３３にリソースを要求する（ステップＳ２０５）。この際、リソース提供部３１は、検証部３２から受け取ったリソースＩＤをリソース記憶部３３に渡す。
【００７７】
リソース記憶部３３は、リソースを要求されると、受け取ったリソースＩＤに対応するリソースをリソース提供部３１に返す（ステップＳ２０６）。
【００７８】
その後、リソース提供部３１は、リソース記憶部３３から受け取ったリソースを、クライアントに送信（提供）する（ステップＳ２０７）。これにより、クライアントは、リソースを取得することができる。以降、ユーザは、取得したリソースを利用して、サービスの提供を受けることができる。
【００７９】
以上説明した通り、本実施形態によれば、クライアントは、認可サーバ１が発行したアクセストークンを利用して、リソースサーバ３からリソースを取得することができる。なお、本実施形態に係るクライアントは、リソースの取得方法として、アクセストークンを利用する既存の任意の方法を利用することができる。
【００８０】
なお、上記実施形態に挙げた構成等に、その他の要素との組み合わせなど、ここで示した構成に本発明が限定されるものではない。これらの点に関しては、本発明の趣旨を逸脱しない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。
【符号の説明】
【００８１】
１：認可サーバ
２：クライアント端末
３：リソースサーバ
４：ネットワーク
１１：クライアント情報記憶部
１２：アカウント情報記憶部
１３：サービス情報記憶部
１４：認証部
３１：リソース提供部
３２：検証部
３３：リソース記憶部
【先行技術文献】
【特許文献】
【００８２】
【特許文献１】特開２０１６−８５６３８号公報
【図１】
2018084979.tif 000003
【図２】
2018084979.tif 000004
【図３】
2018084979.tif 000005
【図４】
2018084979.tif 000006
【図５】
2018084979.tif 000007
【図６】
2018084979.tif 000008
【図７】
2018084979.tif 000009
【図８】
2018084979.tif 000010
【図９】
2018084979.tif 000011
【図１０】
2018084979.tif 000012