(57)【要約】【課題】OAuthの認可フローにおいて、複数あるリソースサーバーの一つがオープンリダイレクタであった場合に、アクセストークンが漏えいするおそれがあり、攻撃者が全てのリソースサーバーに不正アクセスできる可能性がある。【解決手段】認証／認可サーバーが、クライアントからトークン発行要求を受信し、受信したクライアントのリダイレクトURIと要求された権限とを、予め与えられたリダイレクトURIに紐付けられた権限情報により限定し、限定したクライアントの権限でトークンを発行する。【選択図】図5
2018180692.tif 000002
【特許請求の範囲】
【請求項１】
クライアントから、アクセストークン要求と共に前記クライアントのリダイレクトURIと要求されるクライアントの権限とを受信する受信手段と、
要求される前記権限を、前記リダイレクトURIに紐付けられた権限情報で限定する権限限定手段と、
前記権限限定手段で限定された権限のアクセストークンを発行する発行手段と
を有することを特徴とする認証認可サーバー。
【請求項２】
請求項１に記載の認証認可サーバーであって、
リダイレクトURIと権限情報とを紐づけたテーブルをさらに有し、
前記権限限定手段は、前記テーブルにおいて、前記アクセストークン要求とともに受信した前記リダイレクトURIに紐づけられた権限情報で、要求される前記権限を限定することを特徴とする認証認可サーバー。
【請求項３】
請求項１または２に記載の認証認可サーバーであって、
前記権限限定手段はさらに、前記アクセストークン要求により要求されるユーザーの権限を、前記リダイレクトURIに紐づけられた権限情報で限定することを特徴とする認証認可サーバー。
【請求項４】
請求項３に記載の認証認可サーバーであって、
前記権限限定手段により限定された前記権限をユーザーに提示して該ユーザーによる承認または拒否の入力を受け付ける手段をさらに有し、
前記発行手段は、前記ユーザーによる認可の入力がされた場合に、前記権限限定手段で限定された前記権限のアクセストークンを発行することを特徴とする認証認可サーバー。
【請求項５】
クライアントと、リソースを提供するリソースサーバーと、認証認可サーバーとを含む認証認可システムであって、
前記認証認可サーバーは、
前記クライアントから、アクセストークン要求と共に前記クライアントのリダイレクトURIと要求されるクライアントの権限とを受信する受信手段と、
要求される前記権限を、前記リダイレクトURIに紐付けられた権限情報で限定する権限限定手段と、
前記権限限定手段で限定された権限のアクセストークンを発行する発行手段と
を有し、
前記リソースサーバーは、リソースの要求と共に前記クライアントから受信する前記アクセストークンを検証し、検証に成功した場合に、前記クライアントに要求されたリソースを提供することを特徴とする認証認可システム。
【請求項６】
クライアントから、アクセストークン要求と共に前記クライアントのリダイレクトURIと要求されるクライアントの権限とを受信する受信手段と、
要求される前記権限を、前記リダイレクトURIに紐付けられた権限情報で限定する権限限定手段と、
前記権限限定手段で限定された権限のアクセストークンを発行する発行手段と
してコンピュータを機能させるためのプログラム。
【請求項７】
クライアントと、リソースを提供するリソースサーバーと、認証認可サーバーとを含む認証認可システムによる認証方法であって、
前記認証認可サーバーが、
前記クライアントから、アクセストークン要求と共に前記クライアントのリダイレクトURIと要求されるクライアントの権限とを受信し、
要求される前記権限を、前記リダイレクトURIに紐付けられた権限情報で限定し、
限定された前記権限のアクセストークンを発行し、
前記リソースサーバーが、リソースの要求と共に前記クライアントから受信する前記アクセストークンを検証し、検証に成功した場合に、前記クライアントに要求されたリソースを提供することを特徴とする認証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認可フローにおける権限の絞り込み方法であり、特にOAuth Implicit Grantフローにおける発行するトークンに紐付く権限の絞り込みをする証認可システム、認証認可サーバー、認証方法及びプログラムに関する。
【背景技術】
【０００２】
クラウドの普及に伴い、手元ではサーバーマシンを管理せず、クラウド上の仮想サーバーを利用してアプリケーションサービスを提供する機会が増えている。さらに近年では、クラウド上でさえもサーバーを保持せずにアプリケーションサービスを提供できるような、アプリケーションの汎用的な機能群（以降、フレームワークと称する）を提供するクラウドサービスが存在している。アプリケーション開発者は、クラウドサービスが提供するフレームワークを利用して、クラウドサービス上にホストしたアプリケーションサービスにアクセスするためのApplication Programming Interface（アプリケーションプログラミングインターフェイス、以降、APIと称する）を設計／実装する。このようにすると、サーバー管理者がメンテナンスすべきアプリケーションサーバーが無くなるため、メンテンスコストを下げることができる。ユーザーがクラウド上のアプリケーションを使う場合、ユーザーは、認証／認可サーバーによって、認証もしくは認可されている必要がある。
【０００３】
ユーザーを認証する方式の一つに、BASIC認証がある。ここで、BASIC認証についてユーザーがアプリケーションをWebブラウザ上で利用する際の認証方法を例に概要を説明する。認証／認可サーバーがユーザーにWebブラウザを介してユーザー名とパスワードを求めた後、ユーザーはユーザー名とパスワードを認証／認可サーバーに送信する。認証／認可サーバーはユーザーから受信したユーザー名とパスワードとを、予め与えられていたユーザー名とパスワードに紐付けられたユーザー管理テーブルに含まれるか否かを検証する。Webブラウザから受信したユーザー名とパスワードが含まれる場合には、Webブラウザに認証したことを証明するトークン（以降、認証トークンと称する）を返す。以上の手順がBASIC認証の概要である。
【０００４】
BASIC認証後にクライアントがクラウドサービス上にホストされたアプリケーションを使用するためには、クライアントがアクセスしたいアプリケーションサービスの範囲を明らかにした上で、認証／認可サーバーから認可を受けなければならない。クライアントはWebブラウザを介して認証／認可サーバーに認可を要求する。この要求にはブラウザを操作しているユーザーの認証トークン、認可を求めるクライアントの情報、認可を求めるアプリケーションサービスの範囲（以降、スコープと称する）を含む。認証／認可サーバーでは、クライアントから受信した認証トークンが正当なものかを確認する。認証トークンが正当な場合には、認証／認可サーバーはクライアントからのアクセストークン要求に対して、クラウドサービス上にホストされたアプリケーションの使用を認められたことを証明するトークン（以降、アクセストークンと称する）を発行する。以上の手順で発行されたアクセストークンを用いて認可を受けたクライアントはクラウドサービス上にホストされたアプリケーション使用することができる。
【０００５】
クライアントを認可してユーザーの権限を委譲する方式としてOAuthと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。ここで、OAuthについて概要を説明する。
【０００６】
OAuthは、クラウドサービス上のアプリケーションが管理するデータに、そのデータの所有者であるユーザーから認められたクライアントがユーザーの代理でアクセスすることを実現する方式である。このとき、クラウドサービス上にホストされたアプリケーションは、クライアントからアクセスされる範囲を明らかにする。明らかにした上で、クライアントは、認証／認可サーバーからクライアントによるアクセスに対してユーザーの明示的な権限の委譲を得なければならない。ユーザーが明示的に権限を委譲することを権限委譲と称する。ユーザーが権限委譲を行うと、認証／認可サーバーはクライアントからのアクセストークン要求に対して、クラウドサービス上にホストされたアプリケーションサービスへのアクセスを認められたことを示すアクセストークンを発行する。以上の手順で、クライアントはクラウドサービス上にホストされたアプリケーションサービスにアクセスするAPIを使用することができる。
【０００７】
以上のように、クラウドサービス上にホストされたアプリケーションを利用するには、ユーザーを認証する場合とユーザーの権限を委譲されたクライアントを認可するのかで実現方式が異なる。
【０００８】
しかし、アプリケーションをホストするクラウドサービスやフレームワークの制約で、認証トークンとアクセストークンのどちらでも受け取れるように、アプリケーションを実装できない場合がある。この場合、アプリケーション開発者は、認証トークン用とアクセストークン用で別々にAPIを作成しなければならない。同じものを作るのは非効率であるため、認証トークンを使用するWebブラウザでもアクセストークンを使用することが望ましい。
【０００９】
しかしながら、Webブラウザは、クライアントの認証情報（以降、クレデンシャルと称する）の機密性を保つのが難しいという欠点があり、OAuthでは、Webブラウザのようにクレデンシャルの機密性が保てないような場合でも、認証／認可サーバーがアクセストークンを発行できるImplicit Grant フローが定義されている。
【００１０】
Implicit Grantフローの概要について説明する。認証／認可サーバーは、クライアント（たとえばWebブラウザで実行されるスクリプトなど）からの認可リクエストを受けた後、認可リクエストに含まれるリダイレクトURIと認証／認可サーバーに予め与えられているリダイレクトURIとが一致するか否かを検証する。検証結果が一致する場合には、認証／認可サーバーはユーザーからの認可を受けた後、クライアントの認可リクエストに応答してアクセストークンを発行する。
【００１１】
この際、認証／認可サーバーがユーザーによる認可を受信すると、認証／認可サーバーは、一致が確認されたリダイレクトURIを用いてWebブラウザをリダイレクトさせる。WebブラウザはリダイレクトURIから、アクセストークン識別子が記載されたフラグメントの情報を取り出し、ローカルに保持する。Webブラウザは、リダイレクトの指示に従い、Web-Hostedクライアントリソースに、フラグメントを取り除いたリクエストを送信する。Web-Hostedクライアントリソースはリクエストを受信すると、通常は埋め込みのスクリプトが含まれるWebページをWebブラウザに返す。Webブラウザは、保持しているフラグメントを含む完全なリダイレクトURLにアクセスし、フラグメントに含まれているアクセストークンを抽出する。Webブラウザは上記Webページに含まれるスクリプトをローカルに実行し、アクセストークン識別子を取り出して、クライアントに送信する。
【００１２】
このように、Implicit Grant フローは、ユーザーが介在することと、予め認証／認可サーバーに登録している特定のリダイレクトURIを検証することで、ユーザーの権限をクライアントに委譲することを実現している。このImplicit Grantフローを適用すると、Webブラウザ上で実行されるクライアントでもアクセストークンが使えるようになる。アプリケーション開発者は、アクセストークンと認証トークンで重複していた設計／開発フローをアクセストークンによる設計／開発フローに統一することが可能となる。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開2015-228068号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
しかしながら、Implicit Grantフローでは、下記の条件が重なるとアクセストークンが漏えいしてしまう可能性がある。なおリソースサーバーが複数存在し、各々のリソースサーバーは少なくとも一つのWeb-Hostedクライアントリソースを保持しているものとする。ここで、複数存在するリソースサーバーのうち少なくとも一つで、特定のWeb-HostedクライアントリソースのURIが、任意のサーバーへのリダイレクトを実行してしまう(以降、オープンリダイレクタと称する)場合を考える。また、Implicit Grantフローを実行するWebブラウザが、リダイレクト先のURIにもフラグメントを引き継ぐものであるとする。さらに、上述した特定のWeb-HostedクライアントリソースのURIをリダイレクトURIに持つクライアントが、認証／認可サーバーに対し、全リソースサーバーへの全権限のスコープを要求するとしよう。
【００１５】
このような場合、認証／認可サーバーは、クライアントの要求に応じて、全リソースサーバーへの全権限のスコープをもつアクセストークンを発行する。このとき、上述したWeb-HostedクライアントリソースのURIに含まれたリダイレクト先にある、攻撃者が管理するサーバーが、フラグメントを読み取り、アクセストークンを入手する可能性がある。その結果、攻撃者は、入手したアクセストークンを使用して、全てのリソースサーバーに不正にアクセスできてしまう問題があった。ここで、オープンリダイレクタとなったサーバー以外に対しても不正なアクセスが発生するのは好ましくない。特許文献1では、Implicit Grant フローを拡張する技術が記載されている。特許文献１によれば、ユーザーの利便性を損なわないようにユーザー認証した際に、リダイレクトURIが一致する場合に限って、認証／認可サーバーがユーザーへの認可確認を省略して、アクセストークンを発行している。
【００１６】
しかしながら、特許文献１でも、認証／認可サーバーは、リダイレクトURIが一致していればアクセストークンを発行するため、リソースサーバーのすべてが危険にさらされてしまうという課題は依然として残る。
【００１７】
本発明は、前述の課題を鑑みてなされたものであり、Implicit Grantフローにおいてトークン漏えいが発生したとしても、不正なアクセスの拡大を防止することを目的とする。
【課題を解決するための手段】
【００１８】
上記目的を達成するために本発明は以下の構成を有する。
【００１９】
本発明の一側面によれば、本発明は、
クライアントから、アクセストークン要求と共に前記クライアントのリダイレクトURIと要求されるクライアントの権限とを受信する受信手段と、
要求される前記権限を、前記リダイレクトURIに紐付けられた権限情報で限定する権限限定手段と、
前記権限限定手段で限定された権限のアクセストークンを発行する発行手段と
を有することを特徴とする認証認可サーバーにある。
【００２０】
また他の側面によれば、本発明は、
クライアントと、リソースを提供するリソースサーバーと、認証認可サーバーとを含む認証認可システムであって、
前記認証認可サーバーは、
前記クライアントから、アクセストークン要求と共に前記クライアントのリダイレクトURIと要求されるクライアントの権限とを受信する受信手段と、
要求される前記権限を、前記リダイレクトURIに紐付けられた権限情報で限定する権限限定手段と、
前記権限限定手段で限定された権限のアクセストークンを発行する発行手段と
を有し、
前記リソースサーバーは、リソースの要求と共に前記クライアントから受信する前記アクセストークンを検証し、検証に成功した場合に、前記クライアントに要求されたリソースを提供することを特徴とする認証認可システムにある。
【発明の効果】
【００２１】
本発明によれば、Implicit Grantフローにおいてトークン漏えいが発生したとしても、不正なアクセスの拡大を防止することができる。
【図面の簡単な説明】
【００２２】
【図１】OAuthのImplicit Grant フローを示すシーケンス図である。
【図２】実施例1のネットワーク構成図である。
【図３】実施例1の各装置のハードウェア構成図である。
【図４】実施例1の各装置のモジュール構成図である。
【図５】実施例1の認可フローを示すシーケンス図である。
【図６】実施例1の認証／認可サーバーでの処理を示すフローチャートである。
【図７】実施例2の認証／認可サーバーでの処理を示すフローチャートである。
【図８】実施例2の認可確認画面を示す図である。
【発明を実施するための形態】
【００２３】
［実施形態1］
本実施の形態においては、インターネット上で帳票データを生成する帳票サービスと、インターネット上のデータを取得して印刷する印刷サービスが、インターネット上のサーバーに設置されていることを想定している。以降、帳票サービスや印刷サービスのように、インターネット上で機能を提供しているサービスを、リソースサービスと呼ぶ。また本実施の形態においては、携帯端末にインストールされた印刷アプリケーションおよび帳票アプリケーションがリソースサービスを利用することを想定している。以降、印刷アプリケーションや帳票アプリケーションのように、リソースサービスを利用するアプリケーションを、リソースサービス連携アプリケーションと呼ぶ。無論、リソースサービスは帳票サービス、印刷サービスには限られず、アプリケーションも帳票アプリケーション、印刷アプリケーションに限られるものではない。
【００２４】
さらに本実施の形態における権限の委譲ではOAuthの仕組みを利用する。OAuthでは、ユーザーから委譲された権限を証明するための情報として、アクセストークンと呼ばれる情報を利用する。本実施形態にかかる権限委譲システムは、図2に示すような構成のネットワーク上に実現される。
【００２５】
＜認証認可システムの構成＞
図2において、WAN702は、Wide Area Networkであり、本実施形態ではネットワーク702上でWorld Wide Web（WWW）システムが構築されている。LAN701、LAN703は各構成要素を接続するLocal Area Networkである。認証／認可サーバー400は、ユーザー認証とアクセストークンの発行を行うサーバーである。
【００２６】
リソースサーバー600、601、602には、印刷サービスや帳票サービスといったリソースサービスが設置されている。ここでは、OAuthにおけるWeb-Hosted クライアントリソースを含んでいる。なお1台のリソースサーバーに含まれるWeb-Hosted クライアントリソースは1つでもよく、複数でもよい。さらに、リソースサーバーに含まれるリソースサービスは1つでもよく、複数でもよい。
【００２７】
Web-Hostedクライアントリソース500、501、502は、OAuthにおけるWeb-Hosted クライアントリソースである。携帯端末201は、ユーザーが使用する携帯端末である。ここでは、OAuthにおけるクライアント230とWebブラウザ300を含んでいる。また、リソースサーバー600、601、602と接続するのは携帯端末201に限定されるものではない。クライアント230は、ユーザーの代理として保護されたサーバー上にあるリソースに対してリクエストするクライアントであり、たとえばJavaScript（登録商標）のようなスクリプト言語によるWebブラウザ300上で実行されるソフトウェアのことである。
【００２８】
認証／認可サーバー400、リソースサーバー600、601、および602はそれぞれLAN701を介してWAN702に接続されている。また、同様に携帯端末201は、LAN703を介してWAN702に接続されている。なお、認証／認可サーバー400、リソースサーバー600、601、および602は個別のLAN上に構成されていてもよいし、同一のLAN上に構成されていてもよい。また同一のPCまたはサーバー上に構成されていてもよい。
【００２９】
＜認証認可サーバーのハードウェア構成＞
図3は、本実施形態にかかる、認証／認可サーバー400のハードウェア構成を示す図である。また、リソースサーバー600、601、および602、携帯端末201の構成も同様である。図3において、CPU801は、ROM803のプログラム用ROMに記憶された、或いはハードディスク811からRAM802にロードされたOSやアプリケーション等のプログラムを実行する。ここでOSとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをOSと呼ぶ。後述する各フローチャートの処理はこのプログラムをCPU801で実行することにより実現できる。RAM802は、CPU801の主メモリ、ワークエリア等として機能する。キーボードコントローラ(KBC)805は、キーボード(KB)809や不図示のポインティングデバイスからのキー入力を制御する。CRTコントローラ(CRTC)806は、CRTディスプレイ810の表示を制御する。ディスクコントローラ(DKC)807は各種データを記憶するハードディスク(HD)811や媒体を交換できる光ディスク、フレキシブルディスク(FD)、不揮発メモリを用いた記録媒体等におけるデータアクセスを制御する。NC812はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
【００３０】
尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はCPU801であり、ソフトウェア上の主体はハードディスク(HD)811にインストールされたアプリケーションプログラムである。
【００３１】
＜アクセストークンが漏洩する原因＞
ここで、本発明を実施するための詳細な説明をする前に、前述の課題でも説明した、Implicit Grantフローでアクセストークンが漏えいする可能性の詳細について図2を用いて説明する。
リソースサーバーに少なくとも一つのWeb-Hosted クライアントリソースが内在しているものとし、リソースサーバー600と、リソースサーバー601と、リソースサーバー602がLAN701上にある。ここで、表1に認証／認可サーバーが検証する権限のスコープとリダイレクトURIとの関係を示す。このスコープはクライアント権限のスコープである。本実施形態では、単に権限といった場合にはクライアント権限を指す。
【００３２】
【表１】
2018180692.tif 000003
【００３３】
表1では、リソースサーバー600が、検証するクライアント権限のスコープscopeA、Web-Hosted クライアントリソースのURIhttps://xxx.example.comに紐付けされている。リソースサーバー601は、検証するクライアント権限のスコープscopeB、Web-Hosted クライアントリソースのURIhttps://yyy.example.comに紐付けされている。リソースサーバー602は、検証するクライアント権限のスコープscopeCとscopeD、Web-Hosted クライアントリソースのURI"https://zzz.example.com"に紐付けされている。
【００３４】
携帯端末201は、WAN702を挟んだLAN701とは別のLAN703上にある。携帯端末201は、認証／認可サーバー400に対して、リソースサーバー600への権限のスコープを要求するものとする。ただし、携帯端末201は、他のリソースサーバー601と602へのアクセスも今後したいため、一旦すべての権限のスコープを要求するものと想定する。すなわち、クライアント230は認証／認可サーバーへ、クライアント識別子をclient230、要求する権限のスコープをscopeA、scopeB、scopeC、scopeDとし、リダイレクトURIとしてhttps://xxx.example.comを指定している認可リクエストを送信してアクセストークンを要求するものとする。なお、認証／認可サーバー400には、クライアント識別子がリダイレクトURIに紐付いたクライアント管理テーブルが予め与えられているものとする。表2にクライアント管理テーブルを示す。
【００３５】
【表２】
2018180692.tif 000004
【００３６】
表2では、クライアント230のクライアント識別子client230に対して、3つのリダイレクトURIであるhttps://xxx.example.com、https://yyy.example.com、https://zzz.example.comが紐付けされている。
【００３７】
ここで、図2に示すリソースサーバー600のWeb-Hosted クライアントリソース500がリソースサーバー600の外へリダイレクトを実行するようなオープンリダイレクタになってしまっていて、且つWebブラウザ300がリダイレクト先のURIにもフラグメントを引き継いでしまう場合を想定する。このとき発生する課題について、図1で示したImplicit Grant フローに従って詳細を以下に示す。図１において、ユーザー100は、保護されたサーバー上にあるリソースのオーナーである。クライアント230は、ユーザー100の代理として保護されたサーバー上にあるリソースに対するリクエストを行うもので、たとえばJavaScript（登録商標）のようなスクリプト言語によるWebブラウザ300上で実行されるソフトウェアである。Webブラウザ300は、例えばコンピュータ上でWWWを利用するためのユーザーエージェントである。認証／認可サーバー400は、ユーザー100がクライアント230に権限委譲を認可したことを確認するとアクセストークンをクライアント230に発行するサーバーである。Web-Hosted クライアントリソース500は、Webブラウザ300からリダイレクトURIリクエストを受信し、クライアント230がアクセストークンを取得するために、Webブラウザ300にスクリプトを返すサーバー上にホストされたモジュールである。リソースサーバー600は、保護されたサーバー上にあるリソースをホストしアクセストークン識別子を用いたリソースへのリクエストを受理して応答を返すサーバーである。
【００３８】
S1.1で、ユーザー100が、Webブラウザ300を介して、リソースサーバー600にアクセスする。
S1.2で、リソースサーバー600は、ユーザー100からのアクセストークン要求を受信し、Webブラウザ300を介して、ユーザー100にWebブラウザ上で動作するクライアント230を配布する。配布されたクライアント230はWebブラウザ300により実行される。
S1.3で、クライアント230は、認証／認可サーバー400に対して、認可リクエストを送信する。認可リクエストには、クライアント識別子としてclient230が、要求する権限のスコープとしてscopeA、scopeB、scopeC、scopeDが、リダイレクトURIとしてhttps://xxx.example.comが含まれている。
S1.4で、認証／認可サーバー400は、S1.3でクライアント230から提示されたクライアント識別子とリダイレクトURIと、予め与えられていた表2に示すクライアント管理テーブルとを照合する。そして認可リクエストのクライアント識別子及びリダイレクトURIと一致するクライアント識別子及びリダイレクトURIの組が、クライアント管理テーブルに格納されているか否かを判定する。クライアント230から受信した認可リクエストに含まれるクライアント識別子とリダイレクトURIとが、表2内のクライアント識別子であるclient230と、それに紐付けられたリダイレクトURIであるhttps://xxx.example.comとに一致していると、S1.5へ進む。
S1.5で、認証／認可サーバー400は、Webブラウザ300に対して、認可確認画面を表示するスクリプトを送信する。
S1.6で、ユーザー100が認可確認をS1.5で表示した認可確認画面で認可操作を行うと、Webブラウザ300は、認可確認のメッセージを認証／認可サーバー400に送信する。
S1.7で、認可確認を受信した認証／認可サーバー400は、S1.4で一致が確認されたリダイレクトURI(https://xxx.example.com)を用いてWebブラウザ300をリダイレクトさせる。このリダイレクトURIには、要求されたアクセストークン識別子がフラグメントとして記載されている。さらに、認証／認可サーバー400では、発行したアクセストークンを管理するために、アクセストークン識別子に対して発行先のクライアントのクライアント識別子と、要求された権限のスコープとを関連付けたレコードを、後述する表3に示すアクセストークン管理テーブルに追加する。ここでは、アクセストークン識別子をAT_000201とする。認証／認可サーバー400が発行するリダイレクトURIは、アクセストークン識別子をフラグメントに記載して構成され、たとえばhttps://xxx.example.com/#token_id=AT_000201となる。さらに、アクセストークン管理テーブルには、認証／認可サーバー400によって、表3に示すように、アクセストークン識別子AT_000201と、それに関連付けらたクライアント識別子client230と、権限のスコープscopeA、scopeB、scopeC、scopeDとを含むレコードが追加される。
【００３９】
【表３】
2018180692.tif 000005
【００４０】
S1.8で、Webブラウザ300は、リダイレクトURIからフラグメントの情報を取り出し、ローカルに保持する。
Webブラウザ300は、S1.9において、リダイレクトの指示に従い、リダイレクトURIで指定されたWeb-Hostedクライアントリソース500にフラグメントを取り除いたリクエストを送信する。
【００４１】
ここで本来であれば、Web-Hostedクライアントリソース500はリクエストを受信すると、Webページ（通常、埋め込みのスクリプトが含まれるHTMLドキュメント）をWebブラウザに返す(S1.10)。そのWebページでは、Webブラウザ300によって保持されているフラグメントを含む完全なリダイレクトURLにアクセスし、フラグメントに含まれているアクセストークン（とその他のパラメーター）を抽出する(S1.11)。
Webブラウザ300は、S1.10で受信したWebページに含まれるスクリプトをローカルに実行し、アクセストークン識別子を取り出して、クライアント230に送信する(S1.12)。
以上の手順でクライアント230は、アクセストークン識別子を取得できる。またここで取得したアクセストークン識別子を用いることで、クライアントは、リソースサーバー上のリソースにアクセスできるようになる。
【００４２】
これに対して、攻撃者がオープンリダイレクタを悪用し、リダイレクトURI（Web-Hostedクライアントリソース500を示す）からさらに攻撃者のサーバーへWebブラウザ300を誘導する場合を説明する。
S1.9で、Webブラウザ300は、リダイレクトの指示に従い、リダイレクトURIで示されたWeb-Hosted クライアントリソース500にリクエストを送信する。ここで、Web-Hosted クライアントリソース500がオープンリダイレクタになってしまっていると、図示していない攻撃者のサーバーにさらにリダイレクトされる。このとき、S1.10で攻撃者のサーバーから偽のWeb-Hosted クライアントリソース（例えばスクリプトを含むWebページ）をダウンロードしたWebブラウザ300が、偽のWeb-Hosted クライアントリソースに、Webブラウザ300が保持するフラグメントを盗まれてしまう。そして、偽のWeb-Hosted クライアントリソースが、攻撃者にフラグメントを横流しし、攻撃者がフラグメントを読み取り、アクセストークン識別子のAT_000201を入手する可能性がある。
【００４３】
攻撃者は入手したアクセストークン識別子を悪用し、リソースサーバー600だけではなく、リソースサーバー601とリソースサーバー602にも不正にアクセスできてしまう。以上の手順でアクセストークンが漏れてしまう可能性がある。
【００４４】
オープンリダイレクタのサーバー以外に攻撃者からの被害を波及させないために、本発明を実施するための最良の形態について説明する。
【００４５】
＜サーバー及び端末のソフトウェア構成＞
図4は、本実施形態にかかる、認証／認可サーバー、リソースサーバー、携帯端末の、それぞれのモジュール構成を示す図である。なお認証／認可サーバー400、リソースサーバー600、携帯端末201は、図2のものと同一である。認証／認可サーバー400は認証サーバーモジュール410と、認可サーバーモジュール420を持つ。認証サーバーモジュール410は、ユーザーを認証するためのモジュールである。
【００４６】
認可サーバーモジュール420はクライアント検証部430、権限限定部440、認可確認部460、トークン発行部470、トークン検証部480を持つ。クライアント検証部430は、クライアントを検証するためのモジュールである。権限限定部440は、アクセストークンに紐付く権限の絞り込みを行うためのモジュールである。認可確認部460は、認可確認画面を表示し、認可確認をするためのモジュールである。トークン発行部470は、トークンを発行するためのモジュールである。トークン検証部480は、トークンの正当性を検証するためのモジュールである。
【００４７】
リソースサーバー600は、Web-Hosted クライアントリソースモジュール510とリソースサーバーモジュール610を持つ。Web-Hosted クライアントリソースモジュール510は、クライアントスクリプト520を持つ。リソースサーバーモジュール610はトークン権限確認部620とリソース要求処理部630を持つ。
【００４８】
携帯端末201はCPU801がROM803或いは外部メモリ811に記憶されたOS210を実行する事で各アプリケーションを制御する。さらに、携帯端末201はWWWを利用するためのユーザーエージェントであるWebブラウザ300と、クライアント230を持つ。
【００４９】
以下に示す、表4、表5、表6、表7は、認証／認可サーバー400が外部メモリに記憶するデータテーブルである。これらデータテーブルは、認証／認可サーバー400の外部メモリではなく、LAN701を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。
【００５０】
【表４】
2018180692.tif 000006
【００５１】
表4は、認証サーバーモジュール410が使用するユーザー管理テーブルである。表4のユーザー管理テーブルは、ユーザー識別子、パスワードから成る。認証／認可サーバー400は、ユーザー識別子、パスワードの情報の組を検証し、正しければ認証情報を生成することで、各ユーザーもしくはクライアントを認証する機能を備える。
【００５２】
【表５】
2018180692.tif 000007
【００５３】
表5は、クライアント検証部430が使用するクライアント管理テーブルである。表5のクライアント管理テーブルはクライアント識別子と、それに関連付けられたリダイレクトURIから成る。
【００５４】
【表６】
2018180692.tif 000008
【００５５】
表6は、権限限定部440が使用するリダイレクトURIスコープ紐付け管理テーブルである。表6のリダイレクトURIスコープ紐付け管理テーブルは、リダイレクトURIと、そのリダイレクトURIを介してImplicit Grant フローを実行する場合に、認可リクエストの元であるクライアントに対して許可される権限の範囲を示すスコープ(以降、クライアントスコープと称し、クライアントの権限情報とも呼ぶ)から成る。表6のリダイレクトURIスコープ紐付け管理テーブルの処理詳細については後述する。
【００５６】
【表７】
2018180692.tif 000009
【００５７】
表7は、トークン発行部470が生成するアクセストークン管理テーブルである。表7のアクセストークン管理テーブルは、アクセストークン識別子、クライアント識別子、ユーザー識別子、クライアントのスコープ、有効期限を関連付けたレコードから成る。表7のアクセストークン管理テーブルの処理詳細については後述する。
【００５８】
＜本実施形態の認可シーケンス＞
ここで、携帯端末201上のWebブラウザを用いてリソースサービスを利用するための、本実施形態に係る認可フローを表すシーケンスについて、図5を用いて説明する。図5は、OAuth2.0仕様のImplicit Grant フローに本実施形態に独自の拡張を加えた認可フローである。
【００５９】
まず、ユーザー100がWebブラウザ300を介して、リソースサーバー600にリソース使用開始のためのアクセスを試行する（S5.1）。
リソースサーバー600は、S5.1でユーザー100からのアクセストークン要求を受信し、Webブラウザ300を介して、ユーザー100にWebブラウザ上で実行されるクライアント230を配布する(S5.2）。
Webブラウザ300で実行されるクライアント230は、Webブラウザ300を介して認証／認可サーバー400に対して、認可リクエストを送信する(S5.3)。認可リクエストは、クライアント識別子と、要求する権限のスコープと、リダイレクトURIとを含む(S5.3)。ここで、リダイレクトURIとは、認証／認可サーバー400がWebブラウザ300をWeb-Hosted クライアントリソース500へ戻すためのURIを意味する。
認証／認可サーバー400の認証サーバーモジュール410は、クライアント230からの認可リクエストを受信する(S5.4)。
【００６０】
認証／認可サーバー400の認証サーバーモジュール410は、S5.4で認可リクエストを受信すると、ユーザーが未認証の場合には、後述のS5.5、S5.6、S5.7を行う。
認証／認可サーバー400の認証サーバーモジュール410は、ユーザー認証画面を表示(不図示)するスクリプトを送信する(S5.5)。ユーザー認証画面の具体的な例としては、ユーザーにユーザー識別子とパスワードを入力するように促す画面を挙げられる(S5.5)。
ユーザー100は、ユーザー識別子とパスワードをS5.5で表示されたユーザー認証画面で認証操作を行う(S5.6)
認証／認可サーバー400の認証サーバーモジュール410は、S5.6で受信したユーザー識別子とパスワードが表4に示すユーザー管理テーブル内のユーザー識別子とパスワードの組み合わせと一致するかを判定する(S5.7)。S5.7で一致するユーザー識別子とパスワードの組み合わせがユーザー管理テーブルに登録されていると判定された場合に、次のシーケンスに進める。
【００６１】
認証／認可サーバー400のクライアント検証部430は、S5.3でクライアント230から受信したクライアント識別子とリダイレクトURIが、表5に示すクライアント管理テーブル内のクライアント識別子とリダイレクトURIの組み合わせに一致するかを判定する(S5.8)。S5.8で一致するクライアント識別子とリダイレクトURIの組み合わせがクライアント管理テーブルに登録されている場合に、次のシーケンスに進める。
認証／認可サーバー400の権限限定部440は、S5.3でクライアント230から受信した認可リクエストに含まれたリダイレクトURIが、表6に示すリダイレクトURIスコープ紐付け管理テーブルに含まれるか否かを判定する(S5.9)。含まれる場合には、権限限定部440は、S5.3でクライアント230から受信した認可リクエストに含まれた、要求する権限のスコープを、表6に示すリダイレクトURIスコープ紐付け管理テーブルの、該当するリダイレクトURIに紐付けられたクライアントスコープで絞り込む(S5.9)。すなわち、認可リクエストに含まれたスコープが、表6に示すリダイレクトURIスコープ紐付け管理テーブルの、該当するリダイレクトURIに紐付けられたクライアントスコープ以外の部分についてはリクエストと拒否する。さらに換言すれば、要求されたスコープとその要求で指定されるリダイレクトURIに対して予め設定されたスコープとの共通部分以外については権限を認めない、ということもできる。なお、オープンリダイレクタとなっているリソースサーバー以外に不正アクセスが及ぶことを防げるために、リダイレクトURIスコープ紐付け管理テーブルに登録されるスコープは、オープンリダイレクタとなっているリソースサーバーにアクセス権限を限定するものであることが望ましい。
【００６２】
S5.9で絞り込まれたスコープが1つ以上ある場合には、認証／認可サーバー400の認可確認部460は、Webブラウザ300に対して、認可確認画面を表示するスクリプトを送信する(S5.10)。認可確認画面の具体的な例としては、ユーザーにユーザーの権限をクライアントに委譲することを許可するか拒否するかを問い合わせる内容を表示する画面と、ユーザーによるボタン入力を促す画面を挙げられる。
ユーザー100は、認可確認をS5.10で表示された認可確認画面で認可操作を行う(S5.11)。認証／認可サーバー400の認可確認部460は、ユーザー100がS5.11にてユーザーが認可操作したことを受信する(S5.11)。認可操作を受信した場合に、次のシーケンスに進める。
認証／認可サーバー400のトークン発行部470は、認可操作の受信に応じてアクセストークンを発行する(S5.12)。具体的には、表7に示すアクセストークン管理テーブルに、発行したアクセストークンのアクセストークン識別子と、そのアクセストークンの要求元であるクライアント識別子と、権限の委譲を認可したユーザー識別子と、発行したアクセストークンに対して認められた権限の範囲であるクライアントスコープと、発行したアクセストークンの有効期限のレコードとを追加する(S5.12)。
認証／認可サーバー400のトークン発行部470は、Webブラウザ300をリダイレクトさせるアクセストークンレスポンスをWebブラウザ300に送信する(S5.13)。そのアクセストークンレスポンスには、認可リクエストに含まれたリダイレクトURIと一致するとS5.8で判定したリダイレクトURIに、トークン発行部470で発行したアクセストークン識別子をフラグメントとして付加したリダイレクトURIが指定されている。
【００６３】
Webブラウザ300は、リダイレクトURIから、フラグメントの情報を取り出し、ローカルに保持する(S5.14)。
Webブラウザ300は、リダイレクトの指示に従い、指定されたリダイレクトURIに対して、Web-Hosted クライアントリソース500にフラグメントを取り除いたリダイレクトURIリクエストを送信する(S5.15)。
【００６４】
Web-Hosted クライアントリソース500はリクエストを受信すると、Webページ (通常、埋め込みのスクリプトが含まれるHTMLドキュメント) すなわちアクセストークン取得スクリプトレスポンスをWebブラウザに返す(S5.16)。
Webページでは、S5.14にて、Webブラウザ300によって保持されているフラグメントを含む完全なリダイレクトURIにアクセスし、フラグメントに含まれているアクセストークン識別子(とその他のパラメーター)を抽出する(S5.17)。
Webブラウザ300はアクセストークン識別子をクライアント230に送信する(S5.18)。 
クライアント230は、認証／認可サーバー400のトークン発行部470で発行されたアクセストークンを使用して保護されたサーバー上にあるリソースへのアクセスのため、リソースサーバー600に対して、リソースリクエストを送信する (S5.19)。このリソースリクエストには、アクセストークン識別子が含まれている(S5.19)。
リソースサーバー600のトークン権限確認部620は、クライアント230から受信したアクセストークン識別子を元にリソースリクエストで要求されたリソースに対するアクセスを許可するか否かを判定する。リソースサーバー600のトークン権限確認部620は、前記判定のために、検証リクエストを認証／認可サーバー400に送信する(S5.20)。検証リクエストには、受信したアクセストークン識別子とリソースサーバー600でリソースを使用するために必要な権限のスコープとが含まれる。
検証リクエストを受信した認証／認可サーバー400のトークン検証部480では、表7のアクセストークン管理テーブルを参照してアクセストークンを検証する。トークン検証部480は、検証リクエストと共に受信したアクセストークンの有効期限が切れていないことを確認する。さらに、トークン検証部480は、S5.20でリソースサーバー600から受信したアクセストークン識別子に紐付けられたリソースサーバー600でリソースを使用するための権限のスコープが、表7に示すクライアントスコープの範囲内であることを確認する(S5.21)。
認証／認可サーバー400のトークン検証部480は、検証結果に問題がなければ、すなわち、アクセストークンが有効であり、アクセストークンに紐づけられたスコープが許されたスコープの範囲であれば、検証の成功をリソースサーバー600へ返す(S5.22)。
リソースサーバー600のリソース要求処理部630は、クライアント230に対して、リソースをレスポンスする(S5.23)。
以上が本実施例の形態に係る認可フローである。
【００６５】
＜認証認可サーバーによるアクセストークン発行手順＞
ここで、本実施例の特徴である認証／認可サーバー400でのアクセストークンを発行するまでのフローについて、図6a、図6bを用いて詳細を説明する。次いでアクセストークンに紐付く権限の絞り込みについて前述のクライアント230について説明する。
【００６６】
図6aのS601にて、認証サーバーモジュール410は、クライアント230から認可リクエストを受信すると、S602へ進める。
図6aのS602にて、認証サーバーモジュール410は、ユーザーが認証済みか否かを判定し、ユーザー認証済みの場合にはS604へ進め、未認証の場合には、S603へ進める。S603のユーザー認証処理については、図6bを参照して後述する。
図6aのS604にて、クライアント検証部430は、S601で受信した認可リクエストに含まれるクライアント識別子とリダイレクトURIを取り出し、認証／認可サーバー400のローカルに保存する。その後、S605へ進める。
図6aのS605にて、クライアント検証部430は、S604で保存したクライアント識別子とリダイレクトURIに一致する、クライアント識別子とリダイレクトURIの組み合わせが表5に示すクライアント管理テーブル内にあるか否かを判定する。クライアント検証部430は、判定の結果、一致すると判断された場合には、S606へ進める。一致しない場合には、S690へ進める。
図6aのS606にて、権限限定部440は、S601で受信した認可リクエストに含まれるクライアントが要求する権限のスコープを取り出し、認証／認可サーバー400のローカルに保存する。その後、S607へ進める。
図6aのS607にて、権限限定部440は、S604で保存したリダイレクトURIが表6に示すリダイレクトURIスコープ紐付け管理テーブルに含まれるか否かを確認する。権限限定部440は、含まれる場合には、S608へ進める。含まれない場合には、S690へ進める。
図6aのS608にて、権限限定部440は、S606で保存したクライアントが要求する権限のスコープを、表6に示すリダイレクトURIスコープ紐付け管理テーブルのリダイレクトURIに紐付けられたクライアントスコープで絞り込む。なお、ここでは、絞り込むと表現したが、表6に示すリダイレクトURIスコープ紐付け管理テーブルのリダイレクトURIに紐付けられたクライアントスコープ以外を含む場合は、リダイレクトURIに紐づけられたスコープ外の部分については拒否するとしてもよい。その後、S609へ進める。
図6aのS609にて、権限限定部440は、S608にて絞り込まれた結果、残ったスコープが1つ以上の場合には、S610へ進める。一方、絞り込まれたスコープが1つもない場合には、S690へ進める。
図6aのS690にて、権限限定部440は、クライアント230にエラーを通知して終了する。
図6aのS610にて、認可確認部460は、認可確認画面を表示して、ユーザーに認可操作を促す。その後、S611へ進める。ユーザーは、認可確認画面上において承認すなわち許可または拒否を入力する。
図6aのS611にて、認可確認部460は、ユーザーが求められた権限委譲を認可したことを受信した場合には、S612へ進める。ユーザーが求められた権限委譲を拒否したことを受信した場合には、S691へ進める。
図6aのS612にて、トークン発行部470は、アクセストークンを発行する。本実施例では、トークン発行部470は、表7のアクセストークン管理テーブルに示すように、アクセストークン識別子と、クライアント識別子と、ユーザー識別子と、クライアントスコープと、有効期限のレコードを追加する。その後、S613へ進める。
図6aのS613にて、トークン発行部470は、フラグメントにアクセストークン識別子を記載して、クライアント230に返す。その後、終了する。
図6aのS691にて、トークン発行部470は、クライアント230に認可失敗を通知して終了する。
【００６７】
ここで、S603のユーザー認証処理について、図6bを用いて処理フローを説明する。
図6bのS620にて、認証サーバーモジュール410は、ユーザー認証をユーザーにさせるためにユーザー認証画面を表示する。
図6bのS621にて、認証サーバーモジュール410は、ユーザーに入力された認証情報を受信した後、S622へ進める。
図6bのS622にて、認証サーバーモジュール410は、S621で受信したユーザー識別子とパスワードを検証する。そのためにS622では、認証サーバーモジュール410は、S621で受信したユーザー識別子とパスワードが表4に示すユーザー管理テーブル内のユーザー識別子とパスワードの組み合わせと一致するかを判定する。認証サーバーモジュール410は、検証の結果、一致すると判断された場合には、S623へ進める。一致しない場合には、S692へ進める。
図6bのS623にて、認証サーバーモジュール410は、不図示の認証トークン管理テーブルにレコードを追加する。
図6bのS692にて、認証サーバーモジュール410は、クライアント230にログインエラーを通知し、処理を終了する。
【００６８】
＜処理の具体例＞
つぎに、前記処理フローに沿って、具体的な例を取り上げて詳しく処理を説明する。ここで、ユーザーは、ユーザー識別子uid00001、パスワードLigajD12f3KLGでユーザー認証しているものとし、ユーザーは、リソースサーバー600からクライアント230を受信しているものとする。またクライアント230の識別子をclient230とする。
S601にて、認証サーバーモジュール410は、クライアント230から、認可リクエストを受信し、S602へ進める。
S602にて、認証サーバーモジュール410は、ユーザー認証が済んでいるため、S604へ進める。
S604にて、クライアント検証部430は、S601で受信した認可リクエストに含まれるクライアント識別子とリダイレクトURIを認証／認可サーバー400のローカルに保存する。本実施例では、クライアント検証部430は、クライアント識別子としてclient230を、リダイレクトURIとしてhttps://xxx.example.comを認証／認可サーバー400のローカルに保存し、S605へ進める。
S605にて、クライアント検証部430は、S604で取り出したクライアント識別子とリダイレクトURIが、表5に示すクライアント管理テーブル内のクライアント識別子とリダイレクトURIの組み合わせと一致するため、S606へ進める。
S606にて、権限限定部440は、S601で受信した認可リクエストに含まれるクライアントが要求する権限のスコープを取り出し、認証／認可サーバー400のローカルに保存する。本実施例では、権限限定部440は、scopeA、scopeB、scopeC、scopeDを保存し、S607へ進める。
S607にて、権限限定部440は、S604で取り出したリダイレクトURIが表6に示すリダイレクトURIスコープ紐付け管理テーブルに含まれるか否かを確認する。本実施例では、https://xxx.example.comが一致するリダイレクトURIであるため、S608へ進める。
S608にて、権限限定部440は、要求する権限のスコープを表6に示すリダイレクトURIスコープ紐付け管理テーブルのリダイレクトURIに紐付けられたクライアントスコープで絞り込む。クライアント230が要求する権限は、scopeA、scopeB、scopeC、scopeDであるのに対して、表6のリダイレクトURIスコープ紐付け管理テーブル内のクライアントスコープには、scopeAが格納されている。クライアント230が要求する権限のスコープは、権限限定部440によって、scopeAに絞りこまれる。その後、S609へ進める。
S609にて、権限限定部440は、S608にて絞り込んだ結果、scopeAが残ったため、S610へ進める。
S610にて、認可確認部460は、認可確認画面を表示して、ユーザーが認可操作を実施する。その後、S611へ進める。
S611にて、認可確認部460は、ユーザーが求められた権限委譲を認可したことを受信したため、S612へ進める。
S612にて、トークン発行部470は、アクセストークンを発行する。表7に示すように、アクセストークン識別子がAT_000001、クライアント識別子がclient230、ユーザー識別子がuid00001、クライアントスコープがscopeA、有効期限2016/11/14/12:00.00として、レコードが追加される。その後、S613へ進める。
S613にて、トークン発行部470は、フラグメントにアクセストークン識別子を記載して、クライアント230に返す。このとき、トークン発行部470から発行されるリダイレクトURIは、アクセストークンの識別子をフラグメントに記載して、https://xxx.example.com/#token_id=AT_000001となる。
【００６９】
以上が実施形態1の詳細である。以上の構成により、認証／認可サーバーは、発行するアクセストークンに紐付く権限の絞り込みを実現できる。これによって、Implicit Grant フローにおけるアクセストークンが仮に漏えいした場合でも、攻撃者による不正アクセスの範囲を、リダイレクト先に紐づけられた権限の範囲に限定できる。これにより不正アクセスがあったとしても、その拡大を抑制できる。
【００７０】
［実施形態2］
実施形態1においては、クライアントの権限をリダイレクトURIに応じて絞り込むことができるが、ユーザーの権限は、認証／認可サーバーによって、絞り込まれていない。そのため、実施形態1ではアクセストークン漏えい時に、絞り込まれていないユーザーの権限が漏えいしてしまう課題がある。実施形態2の第一の目的は、ユーザーの権限の絞り込みを行うことである。この絞り込みをアクセストークン発行時に行うと、認可確認画面に表示した委譲するユーザーの権限と実際にアクセストークンに紐付けられるユーザーの権限に差異が生じ、ユーザーが誤認識してしまい、ユーザビリティが低下する課題が生じる。実施形態2の二つ目の目的は、認可確認画面表示時に、実際にアクセストークンに紐付けるスコープを列挙することで、その誤認識を防止することである。
本実施形態では、クライアントの権限をリダイレクトURIに応じて絞り込む処理に追加して、ユーザーの権限をリダイレクトURIに応じて絞り込み、さらに絞り込んだユーザーの権限を認可確認画面に表示することで、ユーザビリティの向上を図る。ここで、ユーザー権限とは、例えば携帯端末201で実行されるソフトウェアに付与される権限であり、人のユーザーに与えられるクライアント権限と区別される。このように本実施形態では、複数種類の権限それぞれについて、要求されたスコープをさらに限定する。
【００７１】
次に、実施形態2について図面を用いて説明する。なお実施形態１と共通の部分については説明を省略し、以下では差異部分のみ説明する。本実施形態は、図2に示す構成のネットワーク上に実現され、ユーザーが携帯端末201を所持しており、ユーザーが全リソースサーバーへの全権限のスコープscopeK、scopeL、scopeMを保持しているものとする。このとき、クライアント230は、クライアントの権限であるscopeA、scopeB、scopeCの他にユーザーの権限であるscopeK、scopeL、scopeMを認証／認可サーバー400に要求する。本実施形態の特徴であるユーザーの権限をリダイレクトURIで絞り込むために、表6に示したリダイレクトURIスコープ紐付け管理テーブルを拡張する。具体的には、表6のリダイレクトURIスコープ紐付け管理テーブルに、リダイレクトURIを介してImplicit Grant フローを実行する場合に、ユーザーに対して許可される権限の範囲を示すスコープ(以降、オーナースコープと称する)を追加し拡張する。表8に追加拡張した拡張リダイレクトURIスコープ紐付け管理テーブルを示す。さらに、表7に示したアクセストークン管理テーブルも表8同様、オーナースコープを追加拡張する。表9に追加拡張した拡張アクセストークン管理テーブルを示す。
【００７２】
表8、表9は、認証／認可サーバー400が外部メモリに記憶するデータテーブルである。これらデータテーブルは、認証／認可サーバー400の外部メモリではなく、LAN701を介して通信可能に構成された別のサーバーに記憶するよう構成する事もできる。
【００７３】
【表８】
2018180692.tif 000010
【００７４】
表8は、権限限定部440が使用する拡張リダイレクトURIスコープ紐付け管理テーブルである。リダイレクトURIがhttps://xxx.example.comに対して、オーナースコープがscopeKで与えられている。リダイレクトURIがhttps://yyy.example.comに対して、オーナースコープがscopeLで与えられている。リダイレクトURIがhttps://zzz.example.comに対して、オーナースコープがscopeMで与えられている。表8に示す拡張リダイレクトURIスコープ紐付け管理テーブルの処理詳細については後述する。
【００７５】
【表９】
2018180692.tif 000011
【００７６】
表9は、トークン発行部470が生成する拡張アクセストークン管理テーブルである。表9の拡張アクセストークン管理テーブルは、トークン識別子、クライアント識別子、ユーザー識別子、クライアントスコープ、オーナースコープ、有効期限から成る。
【００７７】
ここで、実施形態１による権限の絞り込みと認可確認画面について説明する。リソースサーバー600を利用しようとしているユーザーがいるとする。ここで、リソースサーバー600の利用には、クライアントの権限としてscopeA、オーナーの権限として、scopeKが必要だとする。このとき、前述のようにクライアント230が必要以上のスコープscopeA、scopeB、scopeC、scopeK、scopeL、scopeMを要求したとする。認証／認可サーバー400は、認可リクエスト受信時に、クライアント230が要求する権限のスコープをリダイレクトURIで絞り込む。絞り込みの結果、クライアントのスコープはscopeAに絞り込まれる。一方で、オーナーのスコープは依然として、scopeK、scopeL、scopeMだとする。このように、実施形態１をそのまま適用した場合には、ユーザーの権限であるオーナースコープは絞り込まれていない。セキュリティに鑑みて、アクセストークンが漏えいしたときに攻撃者からの被害を最小限にとどめておくために発行するアクセストークンに紐付けるオーナースコープを絞り込む必要がある。また、発行するアクセストークンに紐付けるオーナースコープをscopeKに絞り込むのであれば、ユーザーに権限委譲を求める認可確認画面においても、予め権限委譲するオーナースコープを絞り込んだ結果であるscopeKを表示するべきである。
【００７８】
次に、実施形態2にかかる、認証／認可サーバー400におけるアクセストークンを発行するまでのフローについて、図7を用いて説明する。初めに本フローの詳細を説明し、次いでユーザーの権限を絞り込む方法について説明する。本フローは、クライアントから認可リクエストを受信することで開始される。
図7のS601からS609は実施形態1にて説明済みであるため省略する。
図7のS2001にて、権限限定部440は、S601で受信した認可リクエストに含まれるクライアントが要求するユーザーの権限であるオーナースコープを取り出し、認証／認可サーバー400のローカルに保存する。その後、S2002へ進める。
図7のS2002にて、権限限定部440は、S2001で保存したユーザーの権限であるオーナースコープを表8に示す拡張リダイレクトURIスコープ紐付け管理テーブル内のリダイレクトURIに紐付けられたオーナースコープで絞り込む。その後S2003へ進める。ここでは、絞り込むと表現したが、表8に示す拡張リダイレクトURIスコープ紐付け管理テーブルのリダイレクトURIに紐付けられたオーナースコープ以外を含む場合は拒否する構成であってもよい。
図7のS2003にて、権限限定部440は、S2002で絞り込まれた結果、残ったユーザーの権限であるオーナースコープが1つ以上の場合には、S2004へ進める。一方、絞り込まれたスコープが1つもない場合には、S690へ進める。
図7のS2004にて、認可確認部460は、絞り込まれたユーザーの権限であるオーナースコープで認可確認画面を表示して、ユーザーに認可操作を促す。その後、S611へ進める。認可確認画面の詳細は後述する。
図7のS611からS613と、S690と、S691は、実施形態1にて説明済みであるため、省略する。
【００７９】
つぎに、前記処理フローに沿って、ユーザーの権限であるオーナースコープと認可確認画面について詳細を説明する。
S601からS609は、実施形態1で説明済みであるため省略するが、クライアント230が要求する権限のスコープはたとえばscopeAに絞り込まれる。
S2001にて、権限限定部440は、S601で受信した認可リクエストに含まれるクライアントが要求するユーザーの権限であるオーナースコープから取り出し、認証／認可サーバー400のローカルに保存する。本実施形態では、scopeK、scopeL、scopeMを取り出す。その後、S2002へ進める。
S2002にて、権限限定部440は、S2001で保存したユーザーの権限であるオーナースコープを表8に示す拡張リダイレクトURIスコープ紐付け管理テーブル内のリダイレクトURIに紐付けられたオーナースコープで絞り込む。クライアント230が要求するユーザーの権限であるオーナースコープは、scopeK、scopeL、scopeMであるのに対して、表8の拡張リダイレクトURIスコープ紐付け管理テーブル内のオーナースコープには、scopeKが格納されている。クライアント230が要求するユーザーの権限であるオーナースコープは、権限限定部440によってscopeKに絞りこまれる。その後S2003へ進める。
S2003にて、権限限定部440は、S2003で絞り込まれた結果、scopeKが残ったため、S2004へ進める。
S2004にて、認可確認部460は、絞り込まれたユーザーの権限であるオーナースコープであるscopeKを認可確認画面に表示して、ユーザーに認可操作を促す。本実施例における認可確認画面の一例を図8に示す。図8においては、ユーザーに対して絞り込み済みのユーザー権限のスコープを提示し、許可または拒否の入力を促す。
S611にて、トークン発行部470は、アクセストークンを発行する。表9に示すように、アクセストークン識別子がAT_000001、クライアント識別子がclient230、ユーザー識別子がuid00001、クライアントスコープがscopeA、オーナースコープがscopeK、有効期限2016/11/14/12:00.00として、レコードが追加される。
【００８０】
以上が実施形態2の詳細である。以上の構成により、認証／認可サーバーは、発行するアクセストークンに紐付く権限の絞り込みをユーザーの権限に対しても実現できる。さらに、認証／認可サーバーは、実際にアクセストークンに紐付けるスコープを認可確認画面に列挙することもできるため、ユーザビリティを向上することができる。また、ユーザー権限に限らず、クライアント権限等、他の種の権限についても同様に認可者に提示してもよい。
【００８１】
［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００８２】
100  ユーザー、230  クライアントPC、300  Webブラウザ、400  認証／認可サーバー、500  Web-Hostedクライアントリソース、600  リソースサーバー
【図１】
2018180692.tif 000012
【図２】
2018180692.tif 000013
【図３】
2018180692.tif 000014
【図４】
2018180692.tif 000015
【図５】
2018180692.tif 000016
【図６】
2018180692.tif 000017
【図７】
2018180692.tif 000018
【図８】
2018180692.tif 000019