JP6759691B2 - 情報処理装置、認可方法及びプログラム - Google Patents

Description

本発明は情報処理装置、認可方法及びプログラムに関する。

近年、クラウドサービスを実現する手法の１つとして、マイクロサービスが注目されている。マイクロサービスとは、システムを複数のサービスの集合体として構成する手法である。マイクロサービスは、サービスを分割することで、それぞれを独立して開発やメンテナンスできるというメリットがある。

このようなマイクロサービスを実現する際には、サービス間の連携やアクセス制御が必要になる。例えばサービス間の連携やアクセス制御を行う方法としてはクッキー（Ｃｏｏｋｉｅ）に認証チケットを格納して利用する方法が既に知られている。また、サービス間の連携やアクセス制御を行う別の方法としては、ＯＡｕｔｈ２．０と呼ばれる認可の連携を実現させるための標準プロトコルを利用する方法が既に知られている（例えば特許文献１参照）。

Ｃｏｏｋｉｅに認証チケットを格納して利用する方法では、各サービスに対して利用可能な操作を制限できず、セキュリティ上の懸念が存在していた。一方、ＯＡｕｔｈ２．０と呼ばれる認可の連携を実現させるための標準プロトコルを利用する方法では、各サービスが利用可能な操作を制限できる。

しかしながら、ＯＡｕｔｈ２．０と呼ばれる認可の連携を実現させるための標準プロトコルを利用する方法では、ユーザが各サービスに対して明示的に認可を行わなければならない。したがって、上記のようなマイクロサービスにより実現される情報処理システムではマイクロサービスを利用する権限をクライアントへ委譲することを許可する許可確認を何度もユーザが行わなければならず、ユーザの利便性を損ねていた。

本発明の実施の形態は、上記の点に鑑みなされたものであり、認可確認におけるユーザの利便性を向上させる情報処理装置を提供することを目的とする。

上記した課題を達成するために本願請求項１は、サービスの利用権限を有するユーザから、前記サービスを利用するクライアントに対して前記利用権限を委譲するための認可の処理を行う情報処理装置であって、前記クライアントから認可の要求を受け付ける認可要求受付手段と、あらかじめ前記情報処理装置に設定されており、前記ユーザから認可の許可又は拒否を受け付ける認可確認画面の表示を省略するか否かを前記クライアント毎に示す情報に基づき、前記認可確認画面の表示を省略するか否かを判定する判定手段と、前記認可確認画面の表示を省略すると判定した場合に、前記ユーザの操作する端末装置への前記認可確認画面の表示を省略し、前記ユーザから認可の許可を受け付けたものとして前記クライアントへ前記利用権限を委譲する利用権限委譲手段と、前記認可確認画面の表示を省略しないと判定した場合に、前記端末装置へ前記認可確認画面の表示を要求する認可確認画面表示要求手段と、を有し、前記利用権限委譲手段は、前記認可確認画面において前記ユーザから認可の許可を受け付けると、限定された前記サービスの利用権限を示す資格情報の発行を前記クライアントに対して行うことにより、前記クライアントへ限定された前記サービスの利用権限を委譲することを特徴とする。

本発明の実施の形態によれば、認可確認におけるユーザの利便性を向上させることができる。

本実施形態に係る情報処理システムの一例の構成図である。 コンピュータの一例のハードウェア構成図である。 本実施形態に係るアプリサーバ装置の一例の処理ブロック図である。 本実施形態に係る認可サーバ装置の一例の処理ブロック図である。 本実施形態に係るユーザ端末装置の一例の処理ブロック図である。 クライアント情報の一例の構成図である。 認可コード情報の一例の構成図である。 アクセストークン情報の一例の構成図である。 リフレッシュトークン情報の一例の構成図である。 自動認可が有効でない場合の認可処理の一例のシーケンス図である。 認可確認画面の一例のイメージ図である。 自動認可が有効である場合の認可処理の一例のシーケンス図である。

以下、本発明の実施形態について図面を参照しながら説明する。
［第１の実施形態］
＜システム構成＞
図１は本実施形態に係る情報処理システムの一例の構成図である。図１の情報処理システム１は、ユーザ端末装置１０、１つ以上のアプリサーバ装置１２、認可サーバ装置１４及びリソースサーバ装置１６が、インターネットなどのネットワーク１８により接続された構成である。

ユーザ端末装置１０はリソースを所有するユーザ（リソースオーナ）が操作する端末装置である。ユーザ端末装置１０は一般的なＯＳなどが搭載されたコンピュータによって実現できる。ユーザ端末装置１０は、デスクトップＰＣ、ノートＰＣ、スマートフォン、携帯電話、タブレットＰＣ、複合機、コピー機、スキャナ、プリンタ、レーザプリンタ、プロジェクタ、電子黒板などの端末装置（電子機器）である。

アプリサーバ装置１２は、一般的なＯＳなどが搭載されたコンピュータによって実現することができ、アプリケーションを実行する。アプリサーバ装置１２で実行されるアプリケーションは、認可を取得してリソースに対するリクエスト（要求）を行うクライアントである。

認可サーバ装置１４は、一般的なＯＳなどが搭載されたコンピュータによって実現することができ、リソースオーナの認証及び認可を行い、認可コード、アクセストークン、リフレッシュトークンなどのトークンを発行する。認可コードは、リソースオーナにより提供されたリソースへのアクセス許可を表す。また、認可コードはアクセストークン及びリフレッシュトークンを得るために使用される。

アクセストークンはアプリサーバ装置１２で実行されるアプリケーション（以下、クライアントと呼ぶ）がリソースオーナに代わり、認証済みリクエストを行うために使用されるトークンである。また、リフレッシュトークンはクライアントがリソースオーナの新しいアクセストークンを得るために使用されるトークンである。

リソースサーバ装置１６は一般的なＯＳなどが搭載されたコンピュータによって実現することができ、リソースに対するリクエストをクライアントから受け付け、クライアントにレスポンスを返す。リソースはアクセスが制限されたリソースであり、認証済みリクエストにより取得が可能である。

なお、図１の情報処理システム１では自社製のアプリケーション（自社製アプリ）を実行するアプリサーバ装置１２と、サードベンダ製のアプリケーション（サードベンダアプリ）を実行するアプリサーバ装置１２と、を有する構成を一例として示している。自社製アプリは事前に信頼できると見なせるサービスの一例である。サードベンダアプリは事前に信頼できると見なせないサービスの一例である。図１の情報処理システム１の構成は一例であって、様々な構成が考えられる。例えば認可サーバ装置１４とリソースサーバ装置１６とは、一体化されていてもよい。

＜ハードウェア構成＞
図１のユーザ端末装置１０、アプリサーバ装置１２、認可サーバ装置１４及びリソースサーバ装置１６は例えば図２に示すようなハードウェア構成のコンピュータにより実現される。

図２はコンピュータの一例のハードウェア構成図である。図２のコンピュータ１００は入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ１０４、ＲＯＭ１０５、ＣＰＵ１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ１０８などを備え、それぞれがバスＢで相互に接続されている。

入力装置１０１はキーボードやマウス、タッチパネルなどを含み、ユーザが各操作信号を入力するのに用いられる。表示装置１０２はディスプレイ等を含み、コンピュータ１００による処理結果を表示する。なお、入力装置１０１及び表示装置１０２は必要なときに接続して利用する形態であってもよい。

通信Ｉ／Ｆ１０７はコンピュータ１００をネットワーク１８に接続するインタフェースである。これにより、コンピュータ１００は通信Ｉ／Ｆ１０７を介してデータ通信を行うことができる。

ＨＤＤ１０８はプログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには例えばコンピュータ１００全体を制御する基本ソフトウェアであるＯＳや、ＯＳ上において各種機能を提供するアプリケーションソフトウェアなどがある。なお、コンピュータ１００はＨＤＤ１０８に替え、記憶媒体としてフラッシュメモリを用いるドライブ装置（例えばソリッドステートドライブ：ＳＳＤ）を利用するものであってもよい。

外部Ｉ／Ｆ１０３は、外部装置とのインタフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、コンピュータ１００は外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａにはフレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリなどがある。

ＲＯＭ１０５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５にはコンピュータ１００の起動時に実行されるＢＩＯＳ、ＯＳ設定、及びネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ１０４はプログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。

ＣＰＵ１０６は、ＲＯＭ１０５やＨＤＤ１０８などの記憶装置からプログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、コンピュータ１００全体の制御や機能を実現する演算装置である。

図１のユーザ端末装置１０、１つ以上のアプリサーバ装置１２、認可サーバ装置１４及びリソースサーバ装置１６は、コンピュータ１００のハードウェア構成により、後述するような各種処理を実現できる。

＜ソフトウェア構成＞
《アプリサーバ装置》
本実施形態に係るアプリサーバ装置１２は例えば図３に示す処理ブロックにより実現される。図３は、本実施形態に係るアプリサーバ装置の一例の処理ブロック図である。アプリサーバ装置１２はプログラムを実行することで、図３に示すような処理ブロックを実現する。アプリサーバ装置１２は認可要求部２１、認可コード取得部２２、アクセストークン取得部２３、ＡＰＩ呼び出し部２４、アプリ処理実行部２５を実現している。

認可要求部２１は、リソースオーナの操作によりリソースへアクセスする必要性が生じると、認可サーバ装置１４に対して認可要求を行う。認可コード取得部２２はリソースへのアクセスが許可された場合に認可サーバ装置１４から認可コードを取得する。アクセストークン取得部２３は認可コードを使用して認可サーバ装置１４からアクセストークンを取得する。また、アクセストークン取得部２３は、リフレッシュトークンを使用して認可サーバ装置１４から新しいアクセストークンを取得する。

ＡＰＩ呼び出し部２４はアクセストークンを使用してリソースサーバ装置１６のＡＰＩを呼び出し、リソースサーバ装置１６のリソースにアクセスする。アプリ処理実行部２５はアクセスしたリソースを使用して何らかの処理を実行する。

《認可サーバ装置》
本実施形態に係る認可サーバ装置１４は、例えば図４に示す処理ブロックにより実現される。図４は本実施形態に係る認可サーバ装置の一例の処理ブロック図である。

認可サーバ装置１４はプログラムを実行することで、図４に示すような処理ブロックを実現する。認可サーバ装置１４は、認可要求受付部３１、自動認可判定部３２、認可確認画面表示要求部３３、リダイレクト処理部３４、アクセストークン発行部３５を実現している。また、認可サーバ装置１４は、クライアント情報保存部４１、認可コード情報保存部４２、アクセストークン情報保存部４３、リフレッシュトークン情報保存部４４を有している。

認可要求受付部３１はアプリサーバ装置１２からの認可要求を受け付ける。自動認可判定部３２は、クライアント情報保存部４１に保存されているクライアント情報を参照して自動認可判定処理を行う。自動認可判定処理は、クライアント情報に含まれる自動認可が有効か否か（無効か）を示す情報により、自動認可が有効か無効かを判定する。自動認可は認可確認画面の表示を省略し、リソースオーナが認可したものとして処理を進めるものである。

自動認可判定部３２は自動認可が無効であれば、認可確認画面の表示を認可確認画面表示要求部３３に指示する。認可確認画面表示要求部３３はユーザ端末装置１０に認可確認画面を表示させ、リソースオーナに認可を許可するか／拒否するかを選択させる。自動認可判定部３２は自動認可が有効であれば、認可確認画面表示要求部３３に対する認可確認画面の表示の指示を省略し、リソースオーナが認可を許可したものとする。

リダイレクト処理部３４は、リソースオーナが認可を許可した場合に、認可コードを発行し、認可コードと共にリダイレクトＵＲＬにリダイレクトを行う。発行した認可コードに関する認可コード情報は認可コード情報保存部４２に保存しておく。

アクセストークン発行部３５は、アプリサーバ装置１２から認可コードを使用したアクセストークン要求を受け付ける。アクセストークン発行部３５は、アクセストークン及びリフレッシュトークンを発行する。発行したアクセストークンに関するアクセストークン情報はアクセストークン情報保存部４３に保存する。発行したリフレッシュトークンに関するリフレッシュトークン情報はリフレッシュトークン情報保存部４４に保存する。アクセストークン発行部３５は発行したアクセストークン及びリフレッシュトークンをアクセストークン要求元のアプリサーバ装置１２に返す。

《ユーザ端末装置》
本実施形態に係るユーザ端末装置１０は、例えば図５に示す処理ブロックにより実現される。図５は本実施形態に係るユーザ端末装置の一例の処理ブロック図である。ユーザ端末装置１０はプログラムを実行することで、図５に示す処理ブロックを実現する。図５のユーザ端末装置１０は認可確認画面表示部５１、認可要求許可／拒否応答部５２を実現している。

認可確認画面表示部５１は認可サーバ装置１４からの要求に基づき、後述の認可確認画面を表示する。認可確認画面はリソースオーナから認可の許可又は拒否の選択を受け付けることができる。認可要求許可／拒否応答部５２はリソースオーナから受け付けた認可の許可又は拒否の選択を認可サーバ装置１４に返す。

《情報》
図６はクライアント情報の一例の構成図である。図６のクライアント情報は項目として内部ＩＤ、企業ＩＤ、クライアントＩＤ、クライアントシークレット、リダイレクトＵＲＩ、クライアント名、クライアント種別、自動認可を有する。

内部ＩＤはテーブル内のプライマルキー（主キー）であり、内部管理用である。企業ＩＤはクライアントを作成した企業の内部ＩＤである。なお、企業は一例であって、学校や団体、部門などのグループの単位であればよい。クライアントＩＤはアプリサーバ装置１２で実行されるアプリケーション（クライアント）を識別するＩＤである。クライアントシークレットはクライアントのシークレットである。リダイレクトＵＲＩはＯＡｕｔｈの認可の際に利用するリダイレクトＵＲＩである。クライアント名はクライアントの名前である。クライアント種別はクライアントの種類である。

自動認可は、自動認可が有効か否か（無効か）を示す情報である。図６のクライアント情報では、クライアントが自社製アプリである場合、自動認可に有効（ｔｒｕｅ）が設定される。また、図６のクライアント情報では、クライアントがサードベンダアプリである場合、自動認可に無効（ｆａｌｓｅ）が設定される。なお、図６のクライアント情報の設定は認可サーバ装置１４の管理者が行う。したがって、認可サーバ装置１４の管理者はクライアントが自社製アプリである場合に、あらかじめ図６のクライアント情報の自動認可を有効に設定しておく。

図７は認可コード情報の一例の構成図である。図７の認可コード情報は項目として内部ＩＤ、クライアント内部ＩＤ、認可コード、リダイレクトＵＲＩ、スコープ、作成日時及びコードチャレンジを有する。

内部ＩＤは、テープル内のプライマルキー（主キー）であり、内部管理用である。クライアント内部ＩＤは、クライアントを識別する内部ＩＤである。認可コードは発行した認可コードである。リダイレクトＵＲＩは、認可要求時に指定されたリダイレクトＵＲＩである。スコープは認可要求のスコープである。作成日時は認可コードが作成された日時である。コードチャレンジは認可を行う際に利用するコードチャレンジである。

図８はアクセストークン情報の一例の構成図である。図８のアクセストークン情報は項目として内部ＩＤ、ユーザ内部ＩＤ、クライアント内部ＩＤ、リフレッシュトークン内部ＩＤ、トークン、スコープ及び作成日時を有する。

内部ＩＤはテープル内のプライマルキー（主キー）であり、内部管理用である。ユーザ内部ＩＤは、ユーザ（リソースオーナ）を識別する内部ＩＤである。クライアント内部ＩＤは、クライアントを識別する内部ＩＤである。リフレッシュトークン内部ＩＤは、リフレッシュトークンを識別する内部ＩＤである。トークンは発行したアクセストークンの値である。スコープはアクセストークンに紐付くスコープである。また、作成日時はアクセストークンが作成された日時である。

図９は、リフレッシュトークン情報の一例の構成図である。図９のリフレッシュトークン情報は、項目として内部ＩＤ、ユーザ内部ＩＤ、クライアント内部ＩＤ、トークン、スコープ及び作成日時を有する。

内部ＩＤはテープル内のプライマルキー（主キー）であり、内部管理用である。ユーザ内部ＩＤは、ユーザ（リソースオーナ）を識別する内部ＩＤである。クライアント内部ＩＤは、クライアントを識別する内部ＩＤである。トークンは発行したリフレッシュトークンの値である。スコープはリフレッシュトークンに紐付くスコープである。また、作成日時はリフレッシュトークンが作成された日時である。

＜処理の詳細＞
以下では、本実施形態に係る情報処理システム１の認可処理について、自動認可が有効でない場合と自動認可が有効である場合とに分けて説明する。

《自動認可が有効でない場合》
図１０は自動認可が有効でない場合の認可処理の一例のシーケンス図である。図１０ではＯＡｕｔｈ２．０の認可コードフローを用いてアクセストークンを発行する際のシーケンス図を一例として示している。

ステップＳ１１において、リソースオーナが操作するユーザ端末装置１０は、ＯＡｕｔｈ２．０の認可開始をアプリサーバ装置１２に要求する。アプリサーバ装置１２の認可要求部２１はステップＳ１２、Ｓ１３に進み、ユーザ端末装置１０をリダイレクトにより認可サーバ装置１４へアクセスさせ、認可要求を行う。

ステップＳ１４に進み、認可サーバ装置１４の自動認可判定部３２は、クライアント情報保存部４１に保存されている図６に示したクライアント情報を参照して自動認可判定処理を行う。自動認可判定部３２は図６のクライアント情報の項目「自動認可」が有効「ｔｒｕｅ」であるか無効「ｆａｌｓｅ」であるかにより、自動認可が有効であるか無効であるかを判定する。

図１０ではクライアントがサードベンダアプリであるため、自動認可が無効であると判定される。自動認可判定部３２は自動認可が無効であると判定したため、認可確認画面の表示を認可確認画面表示要求部３３に指示する。ステップＳ１５に進み、認可確認画面表示要求部３３は図１１に示すような認可確認画面の表示をユーザ端末装置１０に対して要求する。

図１１は認可確認画面の一例のイメージ図である。図１１の認可確認画面はユーザ端末装置１０を操作するリソースオーナに提示される画面である。リソースオーナは図１１の認可確認画面の「許可する」ボタンを押下することにより、認可の許可を選択することができる。また、リソースオーナは図１１の認可確認画面の「許可しない」ボタンを押下することにより、認可の拒否を選択することができる。ユーザ端末装置１０の認可確認画面表示部５１は例えば図１１の認可確認画面を表示してリソースオーナから認可の許可又は拒否の選択を受け付ける。そして、ステップＳ１６に進み、認可要求許可／拒否応答部５２はリソースオーナから受け付けた認可の許可又は拒否の選択を、認可サーバ装置１４に通知する。

認可サーバ装置１４のリダイレクト処理部３４はリソースオーナから認可の許可を受け付けた場合、認可コードを発行する。ステップＳ１７、Ｓ１８の処理へ進み、リダイレクト処理部３４は図６のクライアント情報に含まれるリダイレクトＵＲＩに認可コードと共にリダイレクトさせる。

ステップＳ１９に進み、アプリサーバ装置１２のアクセストークン取得部２３は取得した認可コードを使用して認可サーバ装置１４にアクセストークンを要求する。ステップＳ２０に進み、認可サーバ装置１４のアクセストークン発行部３５は、認可コードを使用したアクセストークン要求に基づいて、アプリサーバ装置１２にアクセストークン及びリフレッシュトークンを発行する。ステップＳ２１において、アプリサーバ装置１２のＡＰＩ呼び出し部２４はアクセストークンを使用してリソースサーバ装置１６のＡＰＩを呼び出すことで、リソースサーバ装置１６のリソースにアクセスできる。

《自動認可が有効である場合》
図１２は自動認可が有効である場合の認可処理の一例のシーケンス図である。図１２は図１０と同様、ＯＡｕｔｈ２．０の認可コードフローを用いてアクセストークンを発行する際のシーケンス図を一例として示している。

ステップＳ３１〜Ｓ３４の処理は図１０のステップＳ１１〜Ｓ１４と同様である。図１２ではクライアントが自社製アプリであるため、自動認可が有効であると判定される。自動認可判定部３２は自動認可が有効であると判定したため、図１１の認可確認画面の表示をスキップし、リソースオーナが認可を許可したものとしてステップＳ３５以降の処理を進める。なお、ステップＳ３５〜Ｓ３９の処理は図１０のステップＳ１７〜Ｓ２１と同様である。
［他の実施形態］
クライアント情報の自動認可は、クライアントが自社製アプリである場合に自動認可を有効とし、クライアントがサードベンダアプリである場合に自動認可を無効とする例に限定されない。例えばクライアント情報の自動認可は、事前に検査などにより信頼できると見なした場合に自動認可を有効とし、それ以外の自動認可を無効としてもよい。

また、自動認可判定部３２は例えばクライアント情報に含まれるリダイレクトＵＲＩのドメイン部分から自社製アプリかサードベンダアプリかを確認し、自動認可を有効とするか無効とするかを判定するようにしてもよい。

（まとめ）
本実施形態によれば、複数のサービスにより実現される情報処理システム１において認可確認を省略するサービスを設定しておくことができる。従来、複数のサービスにより実現される１つの企業のクラウドサービスは、サービスごとにリソースオーナが認可確認を行う必要があり、リソースオーナの利便性を損ねていた。また、従来、１つの企業のクラウドサービスを利用している最中に何度も認可確認画面が表示される不自然さはリソースオーナを混乱させ、更に利便性を損ねる場合もあった。

本実施形態によれば、例えば自社製アプリなど、事前に信頼できると見なしたサービスの認可確認を省略するため、セキュリティ上の安全性を確保しながら、リソースオーナの利便性を向上できる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。認可サーバ装置１４は特許請求の範囲に記載した情報処理装置の一例である。認可要求受付部３１は認可要求受付手段の一例である。自動認可判定部３２は判定手段の一例である。リダイレクト処理部３４及びアクセストークン発行部３５は利用権限委譲手段の一例である。ユーザ端末装置１０はユーザの操作する端末装置の一例である。認可確認画面表示要求部３３は認可確認画面表示要求手段の一例である。認可コード、アクセストークン及びリフレッシュトークンは資格情報の一例である。また、自動認可が有効か否か（無効か）を示す情報であるクライアント情報の項目「自動認可」は認可確認画面の表示を省略するか否かを示す情報の一例である。

１ 情報処理システム
１０ ユーザ端末装置
１２ アプリサーバ装置
１４ 認可サーバ装置
１６ リソースサーバ装置
１８ ネットワーク
２１ 認可要求部
２２ 認可コード取得部
２３ アクセストークン取得部
２４ ＡＰＩ呼び出し部
２５ アプリ処理実行部
３１ 認可要求受付部
３２ 自動認可判定部
３３ 認可確認画面表示要求部
３４ リダイレクト処理部
３５ アクセストークン発行部
４１ クライアント情報保存部
４２ 認可コード情報保存部
４３ アクセストークン情報保存部
４４ リフレッシュトークン情報保存部
５１ 認可確認画面表示部
５２ 認可要求許可／拒否応答部
１００ コンピュータ
１０１ 入力装置
１０２ 表示装置
１０３ 外部Ｉ／Ｆ
１０３ａ 記録媒体
１０４ ＲＡＭ
１０５ ＲＯＭ
１０６ ＣＰＵ
１０７ 通信Ｉ／Ｆ
１０８ ＨＤＤ
Ｂ バス

特開２０１５−９５０５６号公報

Claims (4)

1. サービスの利用権限を有するユーザから、前記サービスを利用するクライアントに対して前記利用権限を委譲するための認可の処理を行う情報処理装置であって、
   前記クライアントから認可の要求を受け付ける認可要求受付手段と、
   あらかじめ前記情報処理装置に設定されており、前記ユーザから認可の許可又は拒否を受け付ける認可確認画面の表示を省略するか否かを前記クライアント毎に示す情報に基づき、前記認可確認画面の表示を省略するか否かを判定する判定手段と、
   前記認可確認画面の表示を省略すると判定した場合に、前記ユーザの操作する端末装置への前記認可確認画面の表示を省略し、前記ユーザから認可の許可を受け付けたものとして前記クライアントへ前記利用権限を委譲する利用権限委譲手段と、
   前記認可確認画面の表示を省略しないと判定した場合に、前記端末装置へ前記認可確認画面の表示を要求する認可確認画面表示要求手段と、を有し、
   前記利用権限委譲手段は、前記認可確認画面において前記ユーザから認可の許可を受け付けると、限定された前記サービスの利用権限を示す資格情報の発行を前記クライアントに対して行うことにより、前記クライアントへ限定された前記サービスの利用権限を委譲すること
   を特徴とする情報処理装置。
2. 前記クライアントは、サーバ装置で動作するアプリケーションであって、前記端末装置である電子機器から利用されること
   を特徴とする請求項１記載の情報処理装置。
3. サービスの利用権限を有するユーザから、前記サービスを利用するクライアントに対して前記利用権限を委譲するための認可の処理を行う情報処理装置において実行される認可方法であって、
   前記クライアントから認可の要求を受け付ける認可要求受付ステップと、
   あらかじめ前記情報処理装置に設定されており、前記ユーザから認可の許可又は拒否を受け付ける認可確認画面の表示を省略するか否かを前記クライアント毎に示す情報に基づき、前記認可確認画面の表示を省略するか否かを判定する判定ステップと、
   前記認可確認画面の表示を省略すると判定した場合に、前記ユーザの操作する端末装置への前記認可確認画面の表示を省略し、前記ユーザから認可の許可を受け付けたものとして前記クライアントへ前記利用権限を委譲する利用権限委譲ステップと、
   前記認可確認画面の表示を省略しないと判定した場合に、前記端末装置へ前記認可確認画面の表示を要求する認可確認画面表示要求ステップと、を有し、
   前記利用権限委譲ステップは、前記認可確認画面において前記ユーザから認可の許可を受け付けると、限定された前記サービスの利用権限を示す資格情報の発行を前記クライアントに対して行うことにより、前記クライアントへ限定された前記サービスの利用権限を委譲すること
   を特徴とする認可方法。
4. サービスの利用権限を有するユーザから、前記サービスを利用するクライアントに対して前記利用権限を委譲するための認可の処理を行う情報処理装置を、
   前記クライアントから認可の要求を受け付ける認可要求受付手段、
   あらかじめ前記情報処理装置に設定されており、前記ユーザから認可の許可又は拒否を受け付ける認可確認画面の表示を省略するか否かを前記クライアント毎に示す情報に基づき、前記認可確認画面の表示を省略するか否かを判定する判定手段、
   前記認可確認画面の表示を省略すると判定した場合に、前記ユーザの操作する端末装置への前記認可確認画面の表示を省略し、前記ユーザから認可の許可を受け付けたものとして前記クライアントへ前記利用権限を委譲する利用権限委譲手段、
   前記認可確認画面の表示を省略しないと判定した場合に、前記端末装置へ前記認可確認画面の表示を要求する認可確認画面表示要求手段、として機能させ、
   前記利用権限委譲手段は、前記認可確認画面において前記ユーザから認可の許可を受け付けると、限定された前記サービスの利用権限を示す資格情報の発行を前記クライアントに対して行うことにより、前記クライアントへ限定された前記サービスの利用権限を委譲すること
   を特徴とするプログラム。

Images