JP6675163B2 - 権限委譲システム、認可サーバの制御方法、認可サーバおよびプログラム - Google Patents
権限委譲システム、認可サーバの制御方法、認可サーバおよびプログラム Download PDFInfo
- Publication number
- JP6675163B2 JP6675163B2 JP2015147023A JP2015147023A JP6675163B2 JP 6675163 B2 JP6675163 B2 JP 6675163B2 JP 2015147023 A JP2015147023 A JP 2015147023A JP 2015147023 A JP2015147023 A JP 2015147023A JP 6675163 B2 JP6675163 B2 JP 6675163B2
- Authority
- JP
- Japan
- Prior art keywords
- authorization
- authority
- client
- user
- token
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/53—Network services using third party service providers
Description
また、これら多数のクラウドサービスは個々にWebサービスのAPI(Application Programming Interface)を公開している。これにより、他のアプリケーションやクラウドサービスからAPIを介してサービスが提供する機能を利用する事が可能となっている。これにより、複数のクラウドサービスが公開する複数のAPIを組み合わせ、あたかも一つのWebサービスのように構成するマッシュアップという機能が広がりつつある。サービスの提供者からすると、クラウドサービス間の連携の仕組みは容易に実装できるものが好ましい。
このような状況において、OAuth 2.0と呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。OAuth 2.0の詳細については、以降で説明する。特許文献1にはOAuth 2.0を利用した技術が開示されている。
ユーザが認可操作を行うと、サービスBはサービスAからアクセスを認められたことを証明するトークン(以下、認可トークンと称する)を受け取り、以降のサービスAのAPIへのアクセスはその認可トークン(認可情報)を用いて実現できる。このユーザの認可操作によってユーザのリソースに対するアクセスをサービスBに認める行為を権限委譲と称する。
ここで認可トークンを用いるとサービスBは、ユーザの認証情報なしに、認可を行ったユーザの権限でサービスAのAPIにアクセスできる。そのため、ユーザから認可を受け認可トークンを取得したサービスBは、その認可トークンを厳重かつ適正に管理する責務を負う。また、この認可トークンは有効期間が設定されており、その有効期間内であれば、APIを利用することが可能である。
そこで、OAuth 2.0では、認可トークンをユーザの認可操作なしで再発行する、つまりリフレッシュするためのプロトコルが策定されている。リフレッシュでは、認可トークンをリフレッシュするためリフレッシュトークン(更新認可情報)を用いる。このリフレッシュトークンは通常、認可トークンと比べて長期間有効である。クライアントは上述のクライアントID、シークレット、リフレッシュトークンを認可サーバに送信することでユーザの認可操作なしで新しい有効期間の認可トークンを取得することができる。
本願発明の各実施形態における権限委譲システムでは、リフレッシュトークンの発行、管理の方式として第二の方式に対してより有用であるため、第二の方式で説明する。しかしながら第二の方式に制限するものではなく、第一の方式においても、実施することは可能である。
サービスとは、サーバ上で起動するソフトウェアがクライアントからの要求に従い実行されることでそのクライアントに対して提供される機能のことを指す。なお、そのソフトウェアであるWebアプリケーションのこともサービスと呼ぶ場合もある。本実施の形態においては、クラウドサービスとして連携サーバが提供するサービスと、リソースサーバが提供するサービスの2つのサービスがあり、ユーザは、端末を介して連携サーバが提供するサービスを利用している想定で説明している。また、リソースサーバはWebサービスとしてAPIを公開しており、連携サーバはこのAPIを利用する事でユーザに対してマッシュアップ機能を提供している想定にて説明する。つまり、リソースサーバから見た場合、連携サーバはクライアントに相当する。
なお、連携サーバが、リソースサーバのAPIを利用するためには、後述するOAuth 2.0のAuthorization Code Grantによるユーザの認可操作を伴った権限委譲が必要となる。言い換えると、ユーザから権限委譲を受けた連携サーバは、リソースサーバのAPIを利用する事ができるようになる。
本実施の形態に係る権限委譲システムは、図1に示すような構成のネットワーク上に実現される。
WAN100は、Wide Area Networkであり、本発明ではWorld Wide Web(WWW)システムが構築されている。LAN101は各構成要素を接続するLocal Area Networkである。
認可サーバ102はOAuth 2.0を実現するための認可サーバであり、認可サーバモジュールが設置されている。リソースサーバ103はリソースサーバであり、Webサービスとして公開されるAPIを備えるリソースサーバモジュールが設置されている。連携サーバ104は連携サーバであり、連携サーバモジュールが設置されている。連携サーバモジュールは、リソースサーバ103が備えるリソースサーバモジュールが公開するAPIを利用する事で、自身が提供するサービスと合わせてマッシュアップ機能をユーザに提供する。
図2は、認可サーバ102、リソースサーバ103、連携サーバ104、および端末105のハードウェア構成を示す。なお、図2に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当する。本実施形態の各サーバおよび端末には一般的な情報処理装置のハードウェア構成やIaaS(Infrastructure as a Service)として提供される除法処理装置の仮想的なハードウェア構成を適用できる。
なお、後述の全ての説明においては、特に断りのない限りサーバや端末における実行のハード上の主体はCPU201であり、ソフトウェア上の主体は外部メモリ211にインストールされたアプリケーションプログラムである。
認可サーバ102は認可サーバモジュール301、HTTPサーバモジュール302を持つ。HTTPサーバモジュール302はWAN100を介して接続する端末105に設置されたWebブラウザ106とのHTTP通信を行うためのモジュールである。また、SSL/TLSによる通信が可能に構成されており、不図示の証明書ストアを持つ。また、本実施例では、後述する認可要求を受け付けた場合に、要求元に対してユーザID、パスワードによるユーザ認証を要求するよう構成している。
また、認可トークンは、認可コードを用いて取得し、クライアントがAPIを利用するための権限を持つことを示すトークンである。さらには、リフレッシュトークンは、同じく認可コードを用いて取得し、認可コードを再発行することが可能であることを示すトークンである。HTTPサーバモジュール302、および認可サーバモジュール301における処理の詳細は後述する。
なお、図中“Ref”は参照を示しており、別図で説明する。また、“Alt”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。
また、本シーケンスで説明する連携サーバモジュール304は、クライアントID「c001@xx.com」及びその各種データであるシークレット、リダイレクトURIを保持している。このリダイレクトURIは、連携サーバモジュール304が、認可応答を受け付けるためのURIである。これらデータは、あらかじめ認可サーバモジュール301に登録されている必要があるが、登録手段については不図示の画面を用いた方法や、認可サーバモジュール301が公開するAPIによって実施する手段が考えられる。
認可要求には、少なくとも、前述の連携サーバモジュール304が保持しているクライアントID「c001@xx.com」およびリダイレクトURI「https://xx/res」を含む。さらに、連携サーバモジュール304がユーザから権限委譲されるリソースの範囲を示すスコープ「profile」も含む。なお、リダイレクトURIは前述したとおり、認可サーバ102にて発行された認可コードを受け付けるクライアントのURLである。
S405にて、HTTPサーバモジュール302は、Webブラウザ106からの認可要求に、HTTP Cookieとして有効な認証トークンが含まれているか検証する。
含まれている場合、HTTPサーバモジュール302は、認証トークンを認可サーバモジュール301に通知し、S410に移行する。
含まれていない場合は、以下の処理を実行する。S406にて、HTTPサーバモジュール302は、ユーザ認証をするためにログイン画面をWebブラウザ106に応答する。
本実施例ではユーザはユーザIDおよびパスワードを入力し、それらの組が認可サーバモジュール301のユーザテーブルに登録されている情報の組と一致する場合に認証するよう構成されている。なおユーザを認証する手段として他の手段、例えば、X.509の証明書や、パスワードを複数回入力する多段階認証等、別の手段を構成する事も可能であり、本手段に限定するものではない。
S408にて、Webブラウザ106は、入力された情報をHTTPサーバモジュール302に送信する。
本実施形態では、ユーザID「user@xx.com」、パスワード「user」がログイン画面500に入力され、HTTPサーバモジュール302は、それらデータを検証し、認証する。なお、HTTPサーバモジュール302は、ユーザ認証に失敗、つまり、ユーザテーブルに情報が登録されていない場合は、不図示の認証エラー画面をWebブラウザ106に応答する。
以後、Webブラウザ106から認可サーバモジュール301へのアクセスは、HTTPサーバモジュール302による認証トークンの検証、認証処理、および認証トークンの認可サーバモジュール301への通知が実行されるとして説明を省略する。
一致した場合、認可サーバモジュール301はS412で認可確認処理を実施する。この認可確認処理については、図7を用いて後述する。
S413にて認可サーバモジュール301は、認可コードを発行する。より具体的には、トークンID「cd_000001」を発行する。そして、認可要求に含まれるクライアントID「c001@xx.com」とリダイレクトURI「https://xx/res」、スコープ「profile」、および、認証し許可を得たユーザのユーザIDに対応するUUID「10000001」を認可サーバモジュールのトークンテーブルに登録する。その際、トークン種別を認可コードとし、有効期限として当該認可コードが有効である期限の日時を登録する。なお、表3のトークンテーブルの例では、トークンが有効か否かを示す状態を「有効」として登録しているが、有効期限を検証することで有効性を毎度確認する構成としてもよい。
その際、トークン種別はリフレッシュトークンとし、有効期限として当該リフレッシュトークンが有効である期限の日時を登録する。また、OAuth 2.0では、認可コードは一度しか利用できないように制御することが推奨されているため、トークンID「cd_000001」の認可コードの状態を「無効」にする。なお、無効にする処理として、状態を利用するのではなく、有効期限を過去の日時に更新することで無効扱いとすることや、テーブルのレコードそのものを削除することで無効にするという方法でもよい。
認可トークンを取得した連携サーバモジュール304は、S422にてリソースサーバモジュール303が公開するAPIに対してリソース要求を行う。
S423、S424にて認可サーバモジュール301は、Webブラウザ106を介し、連携サーバモジュール304に拒否応答を応答する。より具体的には、認可要求時に取得したリダイレクトURI「https://xx/res」に対してWebブラウザ106をリダイレクトするようWebブラウザ106にリダイレクト応答する。
以上が、連携サーバモジュール304が、リソースサーバモジュール303が公開するAPIを利用するまでの、OAuth 2.0のAuthorization Code Grantを利用した本実施形態のシーケンスである。
なお、図中“Alt”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。また、“Opt”はオプションであり、処理を省くことも可能である。
S601にて、ユーザは、Webブラウザ106に表示されている不図示の再実行操作を行う。
S602にて、Webブラウザ106から連携サーバモジュール304に再実行が通知される。再実行を受け付けた連携サーバモジュール304は、S603にて、リソースサーバモジュール303が公開するAPIに対して、すでに取得済みの認可トークン「at_000001」を用いてリソース要求を行う。ここで、認可トークン「at_000001」は有効期限に達しており、無効状態になっているとして説明する。
S607にて、連携サーバモジュール304は認可サーバモジュール301に対して認可トークンリフレッシュ要求を行う。その際、認可トークン、リフレッシュトークン応答にて取得したトークンID「rt_000001」、および、クライアントID「c001@xx.com」、シークレット「xxxxxxxxxx」を送信する。
ここでクライアント認証に失敗した場合は連携サーバモジュール304に認証エラーを応答する。
認可トークンを取得した連携サーバモジュール304は、S614にてリソースサーバモジュール303が公開するAPIに対してリソース要求を行う。
ここで、リフレッシュトークン検証の結果が[無効]となるケースについて説明する。まず、検証の対象となるリフレッシュトークンが有効期限に達し、無効になっている通常想定されるケースである。このケースの場合は正常なケースとして、以下のシーケンスを実行するのみでよく、その他処理を必要としない。
以上が、連携サーバモジュール304が認可トークンをリフレッシュし、リソースサーバモジュール303が公開するAPIを利用するためのOAuth 2.0のリフレッシュシーケンスである。
ここで、OAuth 2.0では、過去に同一のクライアント、同一のユーザ、および同一のスコープにて認可操作したユーザに対して、再度同じ認可操作を求めないよう構成することも可能である。この再度同じ認可操作を求めない処理を認可確認のスキップ処理と称する。
また、図4にて説明した認可要求において、必ず認可確認画面を応答するよう指定することが可能なように構成することもできる。
そこで、例えば、同一条件、つまり同一のクライアント、同一のユーザ、同一のスコープにて認可操作したと判断される期間に有効期限を設定し、期限が切れた場合は認可確認のスキップを実施しないよう構成することも考えられる。
次に、認可サーバモジュール301はS702にて、S701で取得したクライアントID、UUID、スコープの組を用いて、トークンテーブルに同一の組のリフレッシュトークンが有効な状態で存在していないかを検索する。
S703にて、認可確認モジュール301は、S702の処理の結果、有効なリフレッシュトークンが存在しない場合は、S704の処理へ遷移する。また、有効なリフレッシュトークンが存在する場合は、S708の処理へ遷移する。
S707にて認可サーバモジュール301は、認可確認処理の結果を「許可応答」として処理を終了する。なお、このS704、S705、S706、S707で説明した処理が、前述した認可確認のスキップ処理である。前述したように、OAuth 2.0においてはオプションの処理であり、必ず、後述の認可確認画面応答を実施するよう構成することも可能である。また、図4にて説明した認可要求において、必ず認可確認画面を応答するよう指定することが可能なように構成することもできる。
また、図7においては、有効なリフレッシュトークンがあるか探索してから許可済みリストを検証する例を示したが、先に許可済みリストを検証し、許可済みであった場合に有効なリフレッシュトークンがあるか探索するようにしてもよい。
S708にて認可サーバモジュール301は認可確認画面をWebブラウザ106に応答する。図8は応答される認可確認画面の例である。認可確認画面900は、認可要求に含まれるクライアントIDをキーとしてクライアントテーブルから取得したクライアント名を表示する領域であるアクセス元表示領域901を備える。さらに、認可要求で取得したスコープに対応する説明を表示する領域である委譲権限表示領域902を備える。また、認可確認画面900は、ユーザが上記情報の内容について認可操作を実行する許可ボタン903、および拒否を実行する拒否ボタン904を備える。
そして、S710にて、Webブラウザ106は、ユーザが許可ボタン903、もしくは拒否ボタン904を押下した場合は、その認可確認結果を取得し認可サーバモジュール301に通知する。
次に、S712、S713にて、S702、S703と同様の処理を行い、不要なリフレッシュトークンを削除する。S702、S703と同様の処理を再び行うのは、Webブラウザ106における認可確認処理を行っている間に、認可サーバモジュールにおいて他の処理が行われる可能性があり、有効なリフレッシュトークンがあるか否か再び検索する必要があるためである。この結果、たとえば、図4で説明したシーケンス中での認可確認処理の結果、トークンID「rt_000000」のリフレッシュトークンの状態が「無効」に更新される。また、図6で説明したシーケンス中のS615ののちに実行された場合は、第三者がリフレッシュしたのちに取得したと想定されるリフレッシュトークンも合わせて無効化される。上述の通り、この処理によって第三者による不正なAPIの実行を防ぐことが可能となる。なお、図を用いての説明では、リフレッシュトークンを無効化することのみ記載しているが、合わせて、同じ条件にて認可トークンも無効化してもよい。
以上が、本実施の形態の特徴である、認可確認処理である。この認可確認処理を用いることで、不用なリフレッシュトークンが無効化され、前述の対応すべきケース、すなわち、第三者が、リソースサーバモジュール303が公開するAPIを不正に利用できる状態の解消を行うことが可能となる。
図7および図8で説明した認可確認処理では、第三者に情報が漏えいした場合の対処処理について説明した。しかしながら、OAuth 2.0では、クライアント自身がユーザからの許可を不正に取得することで、ユーザのリソースを不正に取得する、というケースが想定される。たとえば、ユーザに対して興味を持たせるような記事を記載し、続きを読むためには認可確認操作を行うよう誘導するような手法が考えられる。このようなケースの場合、ユーザは他のユーザからの注意喚起によってクライアントに対して不用な認可操作を行っていることに気づき、対処を実施することが考えられる。しかしながら、クライアント側も多種多様な手段により、再度ユーザから認可操作を得るための記事掲載等を行うことを繰り返すことで、ユーザのリソースを取得することを試みる。
しかしながら、上述の通り、リソースを不正に取得する目的のクライアントであれば、認可操作を促すための記事の記載を不特定多数に提示することが想定される。そのため、同一のユーザに対して、リフレッシュトークンの利用ではなく記事からの処理開始となるであろう。その結果、再度認可要求を実施するよう構成されることが想定されるからである。
図10および図11は、第2実施形態における認可サーバモジュール301による認可確認処理S412を説明するフローチャートである。
S1001において、認可サーバモジュール301は、過去に認可確認画面にて拒否を実施した、もしくは後述の方法にて、認可操作したことをキャンセル、つまり認可の解除を実施したクライアントのリストである、拒否クライアントリストを取得する。ここで、認可の解除方法としては、たとえば、認可サーバモジュール301にて後述する認可の解除面をWebブラウザ106に提示し、ユーザの操作を持って解除する方法が考えられる。
ユーザは、Webブラウザ106を用いて、HTTPサーバモジュール302を介し認可サーバモジュール301に対して認可の解除画面へのアクセスを要求する。以降の認証処理については、図4を用いて説明したS404からS409での説明における認可要求を、認可の解除画面へのアクセス要求とした場合と同じであるため説明を省略する。
Webブラウザ106は、取得した認可の解除画面1200をユーザに提示する。そして、ユーザが認可解除ボタン1203を押下した場合は、認可の解除要求を認可サーバモジュール301に通知する。認可の解除要求は、前述したUUIDに紐づく認証トークンと認可を解除する対象であるクライアントIDを通知する。
次に、認可サーバモジュール301は、S1006にて、取得したクライアントID、UUIDの組が許可済みリストテーブルにて一致するデータを削除する。
さらに、認可サーバモジュール301は、S1007にてトークンテーブルにて、クライアントID、およびUUIDの組が一致するデータの状態を無効にすることも可能である。
そして、認可サーバモジュール301は後述のS1008にて、拒否クライアントリストテーブルに受信したクライアントIDおよび、UUIDを登録し、処理を終了する。
なお、認可の解除画面1200について、後述する拒否クライアントの解除画面とは別の画面として例示しているが、この二つの画面について同一の画面として構成することも可能である。
S1003にて認可サーバモジュール301は、注意あり認可確認画面をWebブラウザ106に応答する。
Webブラウザ106は、取得した拒否クライアントの解除画面1204をユーザに提示する。そして、ユーザが拒否解除ボタン1206を押下した場合は、拒否の解除要求を認可サーバモジュール301に通知する。拒否の解除要求は、前述したUUIDに紐づく認証トークンと拒否を解除する対象であるクライアントIDを通知する。
なお、拒否クライアントの解除画面1204について、前述した認可の解除画面1200とは別の画面として例示しているが、この二つの画面について同一の画面として構成することも可能である。
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
Claims (12)
- サービスを提供するリソースサーバと、前記リソースサーバが有するユーザのデータへのアクセスを認可情報に基づいてクライアントに認めるための権限委譲を行う認可サーバとを含む権限委譲システムであって、
少なくとも、前記クライアントを識別する情報と、ユーザを識別する情報と、前記権限委譲されるリソースの範囲を示す情報とを含む権限委譲要求を受信する受信手段と、
前記権限委譲要求に含まれる各情報の値がそれぞれ一致する前記権限委譲要求で過去に発行された更新認可情報を検索する検索手段と、を有し
前記検索手段により前記更新認可情報が検索された場合、検索された有効状態の前記更新認可情報を無効化する
ことを特徴とする権限委譲システム。 - 前記ユーザを識別する情報とはユーザIDに対応するUUIDである
ことを特徴とする請求項1に記載の権限委譲システム。 - 前記権限委譲を許可する場合に、前記リソースサーバへアクセスするために利用される前記認可情報と、新たな認可情報を新たな権限委譲要求なしに再発行するために利用される前記更新認可情報とを発行する発行手段をさらに備える
ことを特徴とする請求項1または請求項2に記載の権限委譲システム。 - 前記受信手段が前記権限委譲要求を受信した場合に、前記権限委譲を許可するか否かの認可確認画面を応答する画面応答手段と、
前記認可確認画面でなされた結果を取得する結果取得手段とをさらに備え、
前記検索手段により前記更新認可情報が検索された場合、結果取得手段において取得された前記結果にかかわらず検索された有効状態の前記更新認可情報を無効化する
ことを特徴とする請求項1ないし3のいずれか1項に記載の権限委譲システム。 - 前記権限委譲要求に基づいて、過去に権限委譲を行ったことがあるか検証する検証手段をさらに備える
ことを特徴とする請求項4に記載の権限委譲システム。 - 前記検証手段が、過去に権限委譲を行ったことがあると判断した場合、
前記画面応答手段は、前記認可確認画面の応答を行わない
ことを特徴とする請求項5に記載の権限委譲システム。 - 権限委譲を解除する解除手段をさらに備え、
前記受信手段は、さらに、前記権限委譲の解除を求める解除要求を受信し、
前記解除要求を受信した場合、前記画面応答手段は、さらに、解除画面を応答し、
前記結果取得手段は、さらに、前記解除画面でなされた結果を取得し、
前記解除手段は、前記結果取得手段が取得した結果が解除であった場合、前記解除要求に基づいて前記権限委譲を解除する
ことを特徴とする請求項4ないし6のいずれか1項に記載の権限委譲システム。 - 前記解除要求には、少なくとも、クライアントIDと、前記ユーザを識別する情報に対応する認可情報とが含まれ、
前記解除手段は、前記クライアントIDと前記ユーザを識別する情報が一致するデータを削除もしくは無効にすることで前記権限委譲を解除する
ことを特徴とする請求項7に記載の権限委譲システム。 - 前記権限委譲要求に基づいて、前記ユーザが権限委譲要求を拒否したことがあるクライアントもしくは前記権限委譲を解除したことがあるクライアントである拒否クライアントか否か判断する拒否判断手段をさらに備え、
前記拒否判断手段において拒否クライアントと判断された場合、前記画面応答手段は、注意つきの認可確認画面を応答する
ことを特徴とする請求項4ないし8のいずれか1項に記載の権限委譲システム。 - サービスを提供するリソースサーバが有するユーザのデータへのアクセスを認可情報に基づいてクライアントに認めるための権限委譲を行う認可サーバであって、
少なくとも、前記クライアントを識別する情報と、ユーザを識別する情報と、前記権限委譲されるリソースの範囲を示す情報とを含む権限委譲要求を受信する受信手段と、
前記権限委譲要求に含まれる各情報の値がそれぞれ一致する前記権限委譲要求で過去に発行された更新認可情報を検索する検索手段と、を有し
前記検索手段により前記更新認可情報が検索された場合、検索された有効状態の前記更新認可情報を無効化する
ことを特徴とする認可サーバ。 - サービスを提供するリソースサーバが有するユーザのデータへのアクセスを認可情報に基づいてクライアントに認めるための権限委譲を行う認可サーバの制御方法であって、
少なくとも、前記クライアントを識別する情報と、ユーザを識別する情報と、前記権限委譲されるリソースの範囲を示す情報とを含む権限委譲要求を受信する受信工程と、
前記権限委譲要求に含まれる各情報の値がそれぞれ一致する前記権限委譲要求で過去に発行された更新認可情報を検索する検索工程と、を有し
前記検索工程において前記更新認可情報が検索された場合、検索された有効状態の前記更新認可情報を無効化する
ことを特徴とする認可サーバの制御方法。 - コンピュータを請求項10に記載の認可サーバが備える各手段として機能させるためのプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015147023A JP6675163B2 (ja) | 2015-07-24 | 2015-07-24 | 権限委譲システム、認可サーバの制御方法、認可サーバおよびプログラム |
US15/213,601 US10154036B2 (en) | 2015-07-24 | 2016-07-19 | Authorization delegation system, control method, authorization server, and storage medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015147023A JP6675163B2 (ja) | 2015-07-24 | 2015-07-24 | 権限委譲システム、認可サーバの制御方法、認可サーバおよびプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2017027459A JP2017027459A (ja) | 2017-02-02 |
JP6675163B2 true JP6675163B2 (ja) | 2020-04-01 |
Family
ID=57837468
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015147023A Active JP6675163B2 (ja) | 2015-07-24 | 2015-07-24 | 権限委譲システム、認可サーバの制御方法、認可サーバおよびプログラム |
Country Status (2)
Country | Link |
---|---|
US (1) | US10154036B2 (ja) |
JP (1) | JP6675163B2 (ja) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9923929B2 (en) * | 2015-11-20 | 2018-03-20 | Nasdaq, Inc. | Systems and methods for in-session refresh of entitlements associated with web applications |
US10567381B1 (en) | 2015-12-17 | 2020-02-18 | Amazon Technologies, Inc. | Refresh token for credential renewal |
JP2017220113A (ja) | 2016-06-09 | 2017-12-14 | キヤノン株式会社 | 認可サーバー、制御方法、およびプログラム。 |
JP6806543B2 (ja) * | 2016-11-25 | 2021-01-06 | キヤノン株式会社 | 権限検証システムおよびリソースサーバー、認証サーバー、権限検証方法 |
US10230720B2 (en) * | 2016-12-12 | 2019-03-12 | Sap Se | Authorization code flow for in-browser applications |
US20190068533A1 (en) * | 2017-08-28 | 2019-02-28 | Microsoft Technology Licensing, Llc | Acquiring attachments from data storage providers for use in electronic communications |
JP6643373B2 (ja) * | 2018-02-09 | 2020-02-12 | キヤノン株式会社 | 情報処理システムと、その制御方法とプログラム |
EP3554038A1 (en) * | 2018-04-11 | 2019-10-16 | Barclays Services Limited | System for efficient management of invalid access tokens |
US11122035B2 (en) | 2018-05-24 | 2021-09-14 | International Business Machines Corporation | Secure delegation of a refresh token for long-running operations |
US11153305B2 (en) * | 2018-06-15 | 2021-10-19 | Canon U.S.A., Inc. | Apparatus, system and method for managing authentication with a server |
JP7234699B2 (ja) * | 2019-03-05 | 2023-03-08 | ブラザー工業株式会社 | アプリケーションプログラムおよび情報処理装置 |
CN111988318B (zh) * | 2020-08-21 | 2022-11-08 | 上海浦东发展银行股份有限公司 | 一种授权认证系统及其方法 |
CN113111316A (zh) * | 2021-04-22 | 2021-07-13 | 北京天空卫士网络安全技术有限公司 | 一种应用授权管理的方法、装置和系统 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4797533B2 (ja) * | 2005-09-16 | 2011-10-19 | 横河電機株式会社 | 制御システム及び制御システムのパラメータ設定方法 |
US8832810B2 (en) * | 2010-07-09 | 2014-09-09 | At&T Intellectual Property I, L.P. | Methods, systems, and products for authenticating users |
JP5868221B2 (ja) * | 2012-02-29 | 2016-02-24 | 三菱電機株式会社 | 処理実行装置及びコンピュータプログラム及び処理実行方法 |
JP5701844B2 (ja) * | 2012-04-27 | 2015-04-15 | 株式会社東芝 | 通信システム、データセンタ装置及びデータセンタ装置で使用される制御方法 |
JP6006533B2 (ja) * | 2012-05-25 | 2016-10-12 | キヤノン株式会社 | 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法 |
JP5751228B2 (ja) * | 2012-09-05 | 2015-07-22 | コニカミノルタ株式会社 | 会議支援システム及び制御装置並びに入力端末 |
JP6066647B2 (ja) * | 2012-09-27 | 2017-01-25 | キヤノン株式会社 | デバイス装置、その制御方法、およびそのプログラム |
JP6061633B2 (ja) * | 2012-11-14 | 2017-01-18 | キヤノン株式会社 | デバイス装置、制御方法、およびそのプログラム。 |
JP5988841B2 (ja) * | 2012-11-16 | 2016-09-07 | キヤノン株式会社 | 通信装置、通信システム、情報処理方法及びプログラム |
US9130926B2 (en) * | 2012-12-27 | 2015-09-08 | Microsoft Technology Licensing, Llc | Authorization messaging with integral delegation data |
US9374369B2 (en) * | 2012-12-28 | 2016-06-21 | Lookout, Inc. | Multi-factor authentication and comprehensive login system for client-server networks |
-
2015
- 2015-07-24 JP JP2015147023A patent/JP6675163B2/ja active Active
-
2016
- 2016-07-19 US US15/213,601 patent/US10154036B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
JP2017027459A (ja) | 2017-02-02 |
US20170026376A1 (en) | 2017-01-26 |
US10154036B2 (en) | 2018-12-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6675163B2 (ja) | 権限委譲システム、認可サーバの制御方法、認可サーバおよびプログラム | |
CA2975843C (en) | Apparatus, system, and methods for a blockchain identity translator | |
US10771459B2 (en) | Terminal apparatus, server apparatus, blockchain and method for FIDO universal authentication using the same | |
US11770261B2 (en) | Digital credentials for user device authentication | |
US11698979B2 (en) | Digital credentials for access to sensitive data | |
CN110138718B (zh) | 信息处理系统及其控制方法 | |
US9571494B2 (en) | Authorization server and client apparatus, server cooperative system, and token management method | |
US9626137B2 (en) | Image forming apparatus, server device, information processing method, and computer-readable storage medium | |
US8738901B2 (en) | Automatic certificate renewal | |
US9130758B2 (en) | Renewal of expired certificates | |
US11792180B2 (en) | Digital credentials for visitor network access | |
EP3510510A1 (en) | Architecture for access management | |
JP2018163616A (ja) | 認証認可サーバー、リソースサーバー、認証認可システム、認証方法及びプログラム | |
CN112597472B (zh) | 单点登录方法、装置及存储介质 | |
EP3188454A1 (en) | Shared registration system | |
US20100077208A1 (en) | Certificate based authentication for online services | |
AU2017275376B2 (en) | Method and apparatus for issuing a credential for an incident area network | |
JP2016018507A (ja) | データ同期システム、その制御方法、認可サーバー、およびそのプログラム | |
JP2018092446A (ja) | 認証認可システム及び情報処理装置と認証認可方法とプログラム | |
US11582232B2 (en) | Authority transfer system, server and method of controlling the server, and storage medium | |
JP2017120502A (ja) | クラウドサービスへのIoT機器の登録方法 | |
JP2016085638A (ja) | サーバー装置、端末装置、システム、情報処理方法及びプログラム | |
JP2019134333A (ja) | 情報処理システム、クライアント装置、認証認可サーバー、制御方法とそのプログラム | |
JP2020053100A (ja) | 情報処理システムと、その制御方法とプログラム | |
JP2018180692A (ja) | 認証認可システム、認証認可サーバー、認証方法及びプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180709 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20190515 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190528 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190704 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20200107 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20200127 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20200210 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20200310 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 6675163 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |