JP6006533B2 - 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法 - Google Patents

認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法 Download PDF

Info

Publication number
JP6006533B2
JP6006533B2 JP2012120140A JP2012120140A JP6006533B2 JP 6006533 B2 JP6006533 B2 JP 6006533B2 JP 2012120140 A JP2012120140 A JP 2012120140A JP 2012120140 A JP2012120140 A JP 2012120140A JP 6006533 B2 JP6006533 B2 JP 6006533B2
Authority
JP
Japan
Prior art keywords
authorization information
authorization
update
server
information
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
Application number
JP2012120140A
Other languages
English (en)
Other versions
JP2013246655A5 (ja
JP2013246655A (ja
Inventor
俊介 茂垣
俊介 茂垣
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2012120140A priority Critical patent/JP6006533B2/ja
Priority to CN201380027459.4A priority patent/CN104350501B9/zh
Priority to KR1020147035695A priority patent/KR101640383B1/ko
Priority to PCT/JP2013/061344 priority patent/WO2013175901A1/en
Priority to US14/001,658 priority patent/US9571494B2/en
Publication of JP2013246655A publication Critical patent/JP2013246655A/ja
Publication of JP2013246655A5 publication Critical patent/JP2013246655A5/ja
Application granted granted Critical
Publication of JP6006533B2 publication Critical patent/JP6006533B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101—Auditing as a secondary aspect
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2151—Time stamp

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、たとえば複数のオンラインサービスシステムをマッシュアップして実現されるオンラインシステムにおいて、複数のオンラインサービスシステム間のアクセスを制御するための認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法に関する。
近年、クラウドサービスと呼ばれる、インターネットを介してソフトウェアの機能を提供するシステムが注目を集めている。最近では、複数のクラウドサービスを連携させて、新しいシステムを提供するケースが増えている。
クラウドサービスを連携させるに際して、サービスを提供するシステム間のアクセス制御を安全且つ容易に行う仕組みとしてＯＡｕｔｈと呼ばれる技術がある（非特許文献１）。
ＯＡｕｔｈは、連携先のシステムのアクセス権限に限り、連携元のシステムに対してユーザーのアクセス権限を移譲する技術である。この技術により、連携元のシステムは、連携先のシステムに対して当該ユーザーの権限でアクセスでき、連携先システムが提供するサービスを利用したサービスをユーザーに提供できる。ＯＡｕｔｈによるシステムのアクセス権限移譲の構成を、連携するシステムの夫々の認証機構が備えることで、連携先のシステムにおけるユーザーＩＤやパスワードなどの、セキュリティに関わる認証情報を連携元のシステムに記憶させることなく、安全にシステム間の連携を実現することができる。ＯＡｕｔｈでは、連携元のシステムからのアクセスを許可する認可情報に有効期間を設けており、認可情報の有効期間が経過した後に再発行する仕組みや、認可情報および認可情報の再発行を無効にする仕組みも設けている。
一方、ＯＡｕｔｈとは異なる別の認証技術ではあるが、利用許可に有効期間を設定する方法がある。そこにおいて、各システムで利用許可の有効期間を延長する方法や、有効期間が切れた後でも一定期間ならば各システムでの検証を省略して再度利用を許可する方法が従来から知られている（特許文献１）。
特表２０１１−５１９０８７号公報
"Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｄｒａｆｔ−ｉｅｔｆ−ｏａｕｔｈ−ｖ２−２５"、Ｅ．Ｈａｍｍｅｒ、２０１２年１０月９日、＜ＵＲＬ ｈｔｔｐ:／／ｔｏｏｌｓ.ｉｅｔｆ.ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｏａｕｔｈ−ｖ２−２５＞
しかしながら、現状のＯＡｕｔｈにおける、認可情報の有効期間が経過した後に再発行する構成にはセキュリティの面で課題がある。具体的には、クライアントの認証情報および更新認可情報が漏えいした場合、悪意のあるユーザーによる認可情報の不正な再発行が行われてしまう問題である。また、クライアントの認証情報および更新認可情報の漏えいに対応するためサーバーシステム内で管理しているクライアントの認証情報を変更する場合、サーバーシステムの運用に大きな影響を与えることになる。
本願発明は、上述した課題を解決する認可システムを提供することを目的の１つとする。具体的には、より安全性を高めた認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法を提供することを目的とする。
上記目的を達成するために、本発明は以下の構成を有する。
クライアント装置からリソースサーバーへのアクセス要求を、該要求と関連して前記クライアント装置から受信した有効な認可情報に基づいて認可する認可サーバーであって、
認証情報とともにクライアント装置から受信した発行要求に応じて、リソースサーバーへアクセスするために利用される認可情報と、新たな認可情報を前記認証情報なしに再発行するために利用される更新認可情報とを発行する発行手段と、
更新認可情報とともに受信したリフレッシュ処理要求に応じて、新たな更新認可情報及び新たな認可情報を再発行し、再発行された認可情報及び更新認可情報に関連付けて、新たな更新認可情報及び認可情報を再発行するために前記発行手段により発行した更新認可情報を初回更新認可情報として記憶する再発行手段と、
更新認可情報とともに受信した無効化要求に応じて、受信した前記更新認可情報が初回更新認可情報として関連付けられている更新認可情報を無効化する無効化手段とを有する。
他の観点によれば本発明は以下の構成を有する。
リソースサーバーに対して、認可サーバーにより発行された認可情報とともにアクセス要求を送信して前記リソースサーバーによるサービスを要求するクライアント装置であって、
前記認可サーバーにより発行された認可情報と、新たな認可情報を認証情報なしに再発行するために利用される更新認可情報と、前記認可情報を再発行するために前記認可サーバーが最初に発行した初回更新認可情報とを関連付けて記憶する手段と、
記憶した前記初回更新認可情報とともに無効化要求を前記認可サーバーに送信して、前記初回更新認可情報に関連付けられた更新認可情報の無効化を要求する無効化要求手段とを有する。
さらに他の観点によれば本発明は以下の構成を有する。
クライアント装置からリソースサーバーへのアクセス要求を、該要求と関連して前記クライアント装置から受信した有効な認可情報に基づいて認可する認可サーバーと、リソースサーバーに対して、認可サーバーにより発行された認可情報とともにアクセス要求を送信して前記リソースサーバーによるサービスを要求するクライアント装置と、前記クライアント装置に対してサービスを提供するリソースサーバーとを含むサーバー連携システムであって、
前記認可サーバーは、
認証情報とともにクライアント装置から受信した発行要求に応じて、リソースサーバーへアクセスするために利用される認可情報と、新たな認可情報を前記認証情報なしに再発行するために利用される更新認可情報とを発行する発行手段と、
更新認可情報とともに受信したリフレッシュ処理要求に応じて、新たな更新認可情報及び新たな認可情報を再発行し、再発行された認可情報及び更新認可情報に関連付けて、新たな更新認可情報及び認可情報を再発行するために前記発行手段により発行した更新認可情報を初回更新認可情報として記憶する再発行手段と、
更新認可情報とともに受信した無効化要求に応じて、受信した前記更新認可情報が初回更新認可情報として関連付けられている更新認可情報、及び、受信した前記更新認可情報を無効化する無効化手段とを有し、
前記クライアント装置は、
前記認可サーバーにより発行された認可情報と、新たな認可情報を認証情報なしに再発行するために利用される更新認可情報と、前記認可情報を再発行するために前記認可サーバーが最初に発行した初回更新認可情報とを関連付けて記憶する手段と、
記憶した前記初回更新認可情報とともに無効化要求を前記認可サーバーに送信して、前記初回更新認可情報に関連付けられた更新認可情報の無効化を要求する無効化要求手段とを有する。
他の観点によれば本発明は以下の構成を有する。
クライアント装置からリソースサーバーへのアクセス要求を、該要求と関連して前記クライアント装置から受信した有効な認可情報に基づいて認可する認可サーバーと、前記リソースサーバーに対して、前記認可サーバーにより発行された認可情報とともにアクセス要求を送信して前記リソースサーバーによるサービスを要求するクライアント装置と、前記クライアント装置に対してサービスを提供するリソースサーバーとを有するサーバー連携システムにおけるトークン管理方法であって、
前記認可サーバーが、認証情報とともにクライアント装置から受信した発行要求に応じて、リソースサーバーへアクセスするために利用される認可情報と、新たな認可情報を前記認証情報なしに再発行するために利用される更新認可情報とを発行する発行工程と、
前記クライアント装置が、前記認可サーバーにより発行された認可情報と、新たな認可情報を認証情報なしに再発行するために利用される更新認可情報と、前記認可情報を再発行するために前記認可サーバーが最初に発行した初回更新認可情報とを関連付けて記憶する工程と、
前記クライアント装置が、アクセス要求に対して、前記認可情報が無効であるとの応答を受信した場合、無効であると応答された前記認可情報に関連付けられた更新認可情報とともにリフレッシュ処理要求を前記認可サーバーに対して送信する工程と、
前記認可サーバーが、更新認可情報とともに受信したリフレッシュ処理要求に応じて、新たな更新認可情報及び新たな認可情報を再発行し、再発行された認可情報及び更新認可情報に関連付けて、新たな更新認可情報及び認可情報を再発行するために前記発行手段により発行した更新認可情報を初回更新認可情報として記憶する再発行工程と、
前記クライアント装置が、記憶した前記初回更新認可情報とともに無効化要求を前記認可サーバーに送信して、前記初回更新認可情報に関連付けられた更新認可情報の無効化を要求する無効化要求工程と、
前記認可サーバーが、更新認可情報とともに受信した無効化要求に応じて、受信した前記更新認可情報が初回更新認可情報として関連付けられている更新認可情報を無効化する無効化工程とを有する。
本発明によれば、クライアントの認証情報および更新認可情報が漏えいした場合にも、認可情報の不正な再発行を防げる。
また、本発明によれば、クライアントの認証情報の変更をせずに済むためクライアントのシステムを停止することはなく、小さい影響範囲で更新認可情報の漏えいに対応できる。
システム全体図 サーバーのハードウェア構成図 外部サーバーのソフトウェア構成図 アクセス管理サーバーのソフトウェア構成図 帳票サーバーのソフトウェア構成図 外部サービスシステム１０３が保持するデータ構造を示したテーブルの図 アクセス管理サービスシステム１０４が保持するアカウントテーブルの図 アクセス管理サービスシステム１０４が保持する認可コードのデータ構造を示したテーブルの図 アクセス管理サービスシステム１０４が保持する認可情報のデータ構造を示したテーブルの図 アクセストークン発行のフロー図 認可画面の一例を示した図 本発明によって制御される認可処理のフロー図 第１の実施形態における認可情報無効化処理のフロー図 第２の実施形態における認可情報無効化処理のフロー図 ＯＡｕｔｈの権限移譲フロー図 ＯＡｕｔｈの課題１を示す図 ＯＡｕｔｈの課題２を示す図
まず本発明の課題の具体例を幾つか紹介する。ＯＡｕｔｈによりアクセス権限移譲を行う際には、連携先システムにおいて、連携元システムの権限確認と、連携元システムを利用しているユーザーの権限確認を行う。連携元システムとはユーザーが直にアクセスしてサービスを要求するシステムである。連携先システムとは、連携元システムと連携し、連携元システムに対してサービス等（リソースを含む）を提供するシステムである。以降、ＯＡｕｔｈの定義に従い、連携元システムをクライアント、連携先システムをリソースサーバー、リソースサーバーの認証情報および認可情報を管理するサーバーを認可サーバーと呼ぶ。ここで、認可サーバーが管理する認証情報とは、リソースサーバーを利用するユーザーやシステムを認証するためのセキュリティ情報である。例えばユーザーＩＤおよびパスワードである。認可サーバーが管理する認可情報とは、ＯＡｕｔｈの権限移譲フローによって認可サーバーが発行する、リソースサーバーへのアクセスを許可する情報である。認可情報を、ＯＡｕｔｈではアクセストークンと呼ぶ。クライアントはリソースサーバーにアクセスする際に、リソースサーバーにアクセストークンを送る。リソースサーバーは受け取ったアクセストークンを認可サーバーで確認させ、アクセス可否を判定する。これにより、クライアントは認可サーバーが管理している認証情報を知らずに、リソースサーバーが利用できる。
図１５を用いて、ＯＡｕｔｈの権限移譲フローについて説明する。なお、連携元システムを利用しているユーザーをリソースオーナー（単にオーナーとも呼ぶ）、ユーザーが操作している情報処理端末が備えるＷｅｂブラウザをユーザーエージェントと呼ぶ。
１５０１において、オーナーがユーザーエージェントを介してクライアントを操作している。この状態で、クライアントがリソースサーバーを利用するために、ＯＡｕｔｈのフローを開始する。１５０２において、クライアントがユーザーエージェントを認可サーバーにリダイレクトさせる。この際クライアントは、クライアント自身を一意に識別するクライアントＩＤとリダイレクトＵＲＬとを認可サーバーに送る。
１５０３において、認可サーバーは、ユーザーエージェントを介してオーナーの認証を行う。オーナーの認証は例えば、ユーザーエージェントに認証画面を表示し、オーナーに対して認可サーバーが管理しているユーザーIDとパスワードの入力を要求する方法で行われる。オーナーの認証に成功すると、認可サーバーは認証したオーナーがリソースサーバーに対して適切なアクセス権限を持つか判定する。
１５０４において、認可サーバーはユーザーエージェントを介して、アクセス権限を持つと判定されたオーナーに対して、クライアントによるリソースサーバーへのアクセスの認可確認を行う。オーナーへの認可確認は例えば、認可確認画面を表示し、オーナーに認可ボタンの押下を要求する方法などである。オーナーが認可を行うと、認可サーバーは認可コードを生成する。認可コードとは、オーナーがクライアントに対して、リソースサーバーへのアクセスを許可したことを示す情報である。
１５０５において、認可サーバーは、１５０２でクライアントから渡されたリダイレクトＵＲＬに対して、生成した認可コードを送る。
１５０６において、クライアントは認可サーバーに対して、リソースサーバー利用のための認可情報を要求する。この際、クライアントは受け取った認可コードと、クライアントの認証情報を送る。クライアントの認証情報は例えば、クライアントのＩＤとパスワードである。認可サーバーは、受け取った認可コードの確認と、クライアントの認証を行う。クライアントの認証に成功すると、認可サーバーはリソースサーバーがクライアントに対して連携を許可しているかを確認する。認可コードが有効であり、かつリソースサーバーがクライアントに対して連携を許可していることが確認されると、認可サーバーはリソースサーバーに対する認可情報を生成する。
１５０７において、認可サーバーは生成した認可情報をクライアントに送る。
１５０８において、クライアントは認可情報をリソースサーバーに送り、リソースサーバーの利用要求を行う。
１５０９において、リソースサーバーはアクセス許可判定のために、認可サーバーに対して受け取った認可情報を送る。認可サーバーは受け取った認可情報の確認を行う。
１５１０において、認可サーバーはリソースサーバーに認可情報の確認結果を返す。リソースサーバーは認可情報の確認結果に従い、クライアントに対してアクセスの可否を判断する。
ここで、ＯＡｕｔｈでは１５０９、１５１０のように、認可サーバーでのアクセストークンの確認のみでリソースサーバーに対するアクセス可否を判断している。そのため、アクセストークンが正規のクライアント以外のシステムに流出すると、意図しないクライアントがアクセストークンを発行した正規のクライアントになりすましてリソースサーバーを利用できる。このような問題から、ＯＡｕｔｈは安全のためにアクセストークンの有効期間を短く設定する事を推奨している。一方、アクセストークンの有効期間が短いと、オーナーが一度認可したシステムでも、１５０４のオーナーに対する認可確認が毎回発生するため、利便性が低くなる。そのため、ＯＡｕｔｈは利便性を高くするために、１５０６でのアクセストークン発行時に、アクセストークンと合わせてアクセストークン更新を認可した更新認可情報を発行する方法を提供している。この更新認可情報をリフレッシュトークンと呼ぶ。リフレッシュトークンとは、オーナーに対する認可確認をせずに、アクセストークンを発行するための情報である。認可サーバーはリフレッシュトークンと共に発行されたアクセストークンと同じ権限か、権限を狭めた新たなアクセストークンを発行する。
リフレッシュトークンを用いて新たなアクセストークンを発行する際には、クライアントは認可サーバーに対してリフレッシュトークンと、クライアントの認証情報を送る。クライアントの認証情報は例えば、クライアントのＩＤとパスワードである。認可サーバーはリフレッシュトークンの確認とクライアントの認証を行う。クライアントの認証に成功すると、認可サーバーはリソースサーバーがクライアントに対して連携を許可しているかを確認する。リフレッシュトークンが有効であり、かつリソースサーバーがクライアントに対して連携を許可していることが確認されると、認可サーバーは新たなアクセストークンとリフレッシュトークンを発行する。この際、認可サーバーは利用したリフレッシュトークンを無効にする。以降、リフレッシュトークンを用いてアクセストークンの再発行をする処理をリフレッシュ処理と呼ぶ。なお、トークンの再発行を、トークンの更新あるいはトークンのリフレッシュと呼ぶこともあるが、これらは本実施形態では同義である。
ここで、リフレッシュトークンおよびクライアントの認証情報が流出した場合、不正なクライアントが正規のクライアントになりすましてリフレッシュ処理を行える。リフレッシュ処理を行った不正なクライアントは、発行されたアクセストークンを用いて正規のクライアントになりすましてリソースサーバーを利用出来る。また不正なクライアントは、リフレッシュ処理によって発行された新たなリフレッシュトークンを利用することで、正規クライアントになりすましてリソースサーバーを利用し続けられる。さらに、不正なクライアントが発行したアクセストークンを提供するだけで、様々なクライアントが容易に、リソースサーバーを不正利用できてしまう。
ＯＡｕｔｈが公開している範囲でリフレッシュトークンおよびクライアントの認証情報の流出に対応するには、２つの方法がある。１つ目の方法は、リフレッシュトークンを指定し、指定したリフレッシュトークンと、そのリフレッシュトークンとペアになるアクセストークンをそれぞれ無効にする方法である。この方法によりリフレッシュトークンが無効になるので、リフレッシュ処理を防げる。
しかし、この方法には課題がある。図１６を用いて本方法の課題を説明する。１６０１において、不正クライアントが認可サーバーに対してリフレッシュ処理を要求する。ここで不正クライアントとは、クライアントから流出した認証情報およびリフレッシュトークンを所持しているシステムとする。不正クライアントは正規クライアントの認証情報を利用しているため、認可サーバーでのクライアント認証に成功する。さらに、リフレッシュトークンは正しいものであるため、認可サーバーでのリフレッシュトークン確認も成功する。これにより、認可サーバーはリフレッシュ処理を行い、新たなアクセストークンとリフレッシュトークンを発行する。その後、認可サーバーはリフレッシュ処理に利用したリフレッシュトークンを無効にする。１６０２において、認可サーバーは不正クライアントに対し、発行したアクセストークンとリフレッシュトークンを渡す。
この状態で、１６０３において、クライアントがリフレッシュトークンとアクセストークンの無効化を要求する。しかし、クライアントが持つリフレッシュトークンは、１６０１でのリフレッシュ処理により既に無効となっている。またクライアントは、１６０１のリフレッシュ処理で発行されたリフレッシュトークンを知る事が出来ない。そのためクライアントは、不正クライアントが１回でもリフレッシュ処理を行うと、それ以降のリフレッシュ処理を無効化できないという課題を持つ。
２つ目の方法は、正規クライアントの認証情報を更新する方法である。例えば、認可サーバーでクライアントのパスワードを変更すると、変更前の認証情報しか知らない不正なクライアントによるリフレッシュ処理を防げる。この方法によれば、不正なクライアントがリフレッシュ処理を行っていても、リフレッシュ処理を防げる。
しかし、この方法は影響範囲が大きいという課題を持つ。図１７を用いて本方法の課題を説明する。１７０１でオーナーＡがクライアントを利用しており、１７０２でクライアントが、以前発行したアクセストークンを用いてリソースサーバーへのアクセスを要求したとする。１７０３において、リソースサーバーはアクセス許可判定のためにアクセストークンを認可サーバーに送る。ここで、アクセストークンが無効であったとする。そのため、１７０４において、認可サーバーはリソースサーバーにアクセストークン無効を返す。リソースサーバーはアクセストークンが無効であったため、アクセスを拒否する。１７０５において、リソースサーバーはクライアントにアクセストークン無効を返し、アクセスを拒否する。
１７０６において、クライアントは、アクセストークンが無効であったため、リフレッシュトークンを利用してアクセストークンの再発行を試みる。認可サーバーにリフレッシュトークンとクライアントの認証情報を送りリフレッシュ処理を要求する。ここで、リフレッシュトークンが無効であったとする。リフレッシュトークンが無効である場合は例えば、すでにリフレッシュ処理が行われていて無効になっていた場合や、リフレッシュトークンの有効期限が経過して無効になっている場合がある。認可サーバーは１７０７で、クライアントにリフレッシュトークン無効を返す。
クライアントはリフレッシュトークン無効を受け、不正にリフレッシュ処理がされた可能性を検知する。そのため、１７０８において、認可サーバーに対してクライアントの認証情報の変更を要求する。認証情報の変更は例えば、パスワード変更である。認可サーバーはクライアントの認証情報変更要求を受け、認可サーバーで管理しているクライアントの認証情報を更新する。その後、１７０９でクライアントに対して、クライアントの認証情報変更終了を通知する。
ここで、認可サーバーでのクライアント認証は、アクセストークン発行の際と、リフレッシュ処理の際に行われる。そのため、パスワードを変更する際には、これらの処理を止める必要がある。つまり、１７０８、１７０９の間はクライアントでのこれらの処理が停止される。ここで、ＯＡｕｔｈではひとつのクライアントを複数のオーナーが利用するモデルである。例えば、オーナーＡによる１７０１のクライアント利用と並行して、オーナーＢからのクライアント利用要求１７１０、オーナーＣからのクライアント利用要求１７１１がある。そのため、オーナーＡの認可によって発行されたリフレッシュトークンが無効であった場合にも関わらず、１７０８、１７０９の間は、オーナーＢやオーナーＣからの要求によるアクセストークン発行処理やリフレッシュ処理も停止してしまう。つまり、もしクライアントを停止すると、クライアントを利用している全てのオーナーに影響が出る。
本発明は、このような課題を解決するものであり、クライアントの認証情報およびリフレッシュトークンが流出した場合に、小さい影響範囲でアクセストークンの再発行を防ぎ、システムの不正利用を防ぐ仕組みを提供するものである。
以下、本発明を実施するための最良の形態について図面を用いて説明する。
［実施形態１］
インターネット上で、様々なサービス提供者が様々なオンラインサービスを提供している。単一のサービス提供者が運営している単体のオンラインサービスもあれば、複数のサービス提供者が運営している複数のオンラインサービスを組み合わせて、１つのソリューションを実現するという手法も存在する。後者は、マッシュアップと呼ばれ、表向きはあたかも１つのＷｅｂサイトあるいはＷｅｂサービスとして見える。しかしながら、実際にはバックエンドでは、複数のオンラインサービスが連携・連動して、必要な機能を組み合わせてソリューションを実現する。なお、ここで言うオンラインサービスとは、Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどが提供する機能群のことである。Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどは、サーバーコンピューターで実行されるソフトウェアである。マッシュアップにより構成されたシステムを本実施形態ではサーバー連携システムあるいは単に連携システムとも呼ぶ。
＜オンラインサービスシステムの構成例＞
図１は、各種オンラインサービスが存在するネットワーク構成を示している。インターネット１００は、インターネットなどの外部から接続可能なパブリックなネットワークである。イントラネット１０１はＬＡＮなどの外部から接続不可能なプライベートなネットワークである。情報機器端末１０２は、インターネット１００を介して、パーソナルコンピューターやモバイル端末などのオンラインサービスを利用する際に使用される情報機器端末である。本例では２台の端末１０２Ａと端末１０２Ｂとが示されているが、いずれを用いてもよいため特に区別をしない限り情報機器端末１０２と称する。ＯＡｕｔｈにおいては、情報機器端末１０２を操作するユーザーをオーナー、情報機器端末１０２が備えるＷｅｂブラウザをユーザーエージェントと呼ぶ。 外部サービスシステム１０３は、後述する帳票サービスシステム１０５をオンラインでマッシュアップしたオンラインサービスシステムである。ＯＡｕｔｈにおいてはクライアントと呼ばれる。なお本実施形態では、クライアントが装置であることを明確にするためにクライアント装置と呼ぶことがある。外部サービスシステム１０３は１台ないし複数台の外部サーバーで構成され、負荷分散装置１０８によりインターネット１００からのリクエストを分散して処理する事が出来るよう構成されている。なお、図上は外部サービスシステム１０３を構成する外部サーバーは１０３Ａと１０３Ｂの２台となっているが、実際には１台から複数台の外部サーバーによって構成される。
アクセス管理サービスシステム１０４は、ユーザーの認証情報及び認可情報を管理するサービスシステムである。ＯＡｕｔｈにおいては認可サーバーと呼ばれる。アクセス管理サービスシステム１０４は1台ないし複数台のアクセス管理サーバーで構成され、負荷分散装置１０８によりインターネット１００およびイントラネット１０１からのリクエストを分散して処理する事が出来るよう構成されている。なお、図上はアクセス管理サービスシステム１０４を構成するアクセス管理サーバーは１０４Ａと１０４Ｂの２台となっているが、実際には１台から複数台のアクセス管理サーバーによって構成される。
帳票サービスシステム１０５は、インターネット１００を介した情報機器端末１０２あるいは外部サービスシステム１０３からのリクエストに応じて帳票を生成するオンラインサービスシステムである。ＯＡｕｔｈにおいてはリソースサーバーと呼ばれる。帳票サービスシステム１０５は1台ないし複数台の帳票サーバーで構成され、負荷分散装置１０８によりインターネット１００からのリクエストを分散して処理する事が出来るよう構成されている。また、帳票サービスシステム１０５はイントラネット１０１を介してのリクエストを負荷分散装置１０８により分散して処理する事も出来る。なお、図上は帳票サービスシステム１０５を構成する帳票サーバーは１０５Ａと１０５Ｂの２台となっているが、実際には１台から複数台の帳票サーバーによって構成される。また本例ではリソースサーバーとして帳票サービスシステムを例示しているが、ウエブを介してサービスを提供するサーバーであれば適用可能である。
＜サーバーコンピューターのハードウェア構成＞
図２は、図１に示した各種サーバーを構成するＷｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどのソフトウェアを実行するサーバーコンピューターの情報処理機能の論理構成を示している。
ユーザーインターフェース２０１は、ディスプレイ、キーボード、マウスなどによる、情報の入出力を行うハードウェアである。これらのハードウェアを備えないコンピューターは、リモートデスクトップなどにより、他のコンピューターから接続・操作することも可能である。ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行うハードウェアである。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行し、各種サービスを実現する。ＲＯＭ２０４は、組込済みプログラムおよびデータが記録されている記憶装置である。ＲＡＭ２０５は、一時メモリ領域である。二次記憶装置２０６は、ＨＤＤに代表されるような外部記憶装置である。各部は入出力インターフェース２０７を介して接続されている。
＜外部サーバーの機能構成＞
図３は、外部サーバー１０３Ａの内部構造を示したブロック図である。リクエスト処理部３０１は、外部サービスシステム１０３がインターネット１００を経由して受信した機能リクエストを処理する処理部である。機能制御部３０２はリクエスト処理部３０１からの要求を受け、必要な処理を行い、応答データを呼び出し元に返す。機能連携データ３０３は、外部サービスシステム１０３が連携しているシステムに対するリクエストを生成するためのデータを管理する、認可コード管理部３０４は、認可コードのデータを管理する。トークン管理部３０５は認可情報のデータを管理する。外部サーバー１０３Ｂは、外部サーバー１０３Ａと異なる機能を提供することもできるが、本例では外部サーバー１０３Ａと同じ構成を有し、同じ機能を提供して負荷を分散している。また、外部サーバー１０３Ａが提供する機能としては、たとえばネットワークプリントサービスがある。たとえば、外部サーバー１０３Ａはクライアントとして、ユーザーエージェントであるウエブブラウザから印刷対象の帳票データの所在や名称の指定ととともにその帳票データの印刷のリクエストを受信する。それに応じて外部サーバー１０３Ａは帳票サービスシステム１０５にアクセスしてユーザーに要求された帳票データを獲得する。そして要求に応じて指定されたデータとマージしたうえで印刷データに変換し、これも指定されたネットワークにある印刷装置あるいは印刷サーバーに印刷データを送信して印刷させる。もちろんこれは一例であって、外部サービスシステム１０３が提供するサービスは印刷サービスとは限らない。
＜アクセス管理サーバーの機能構成＞
図４は、アクセス管理サーバー１０４Ａの内部構造を示したブロック図である。アクセス管理サーバー１０４Ｂも同様である。アクセス管理リクエスト処理部４０１は、アクセス管理サービスシステム１０４がインターネット１００及びイントラネット１０１を経由して受信した認証および認可リクエストを処理する処理部である。また、アクセス管理リクエスト処理部４０１は、アクセス制御部４０２から返される応答データを呼び出し元に返す。アクセス制御部４０２は、認証データ管理部４０３及び認可データ管理部４０４から取得するデータに基づき、認証および認可リクエストに対して応答データを生成し、アクセス管理リクエスト処理部４０１に応答データを返す。認証データ管理部４０３は、ユーザーアカウントのデータを管理する。具体的にはユーザー固有のＩＤとパスワードの組などである。なおＩＤとパスワードの組をクレデンシャルとも呼ぶ。認可データ管理部４０４は、認可情報のデータを管理する。認可データ管理部４０４は認可情報のみならず更新認可情報のデータも管理する。認可データ管理部４０４は、最新の認可情報および更新認可情報を記憶するのみならず、後述するように、あるユーザーに対して最初に発行された更新認可情報と当該ユーザーに対する最新の更新認可情報との関連付けも記憶している。
＜帳票サーバー１０５の機能構成＞
図５は、帳票サーバー１０５Ａの内部構造を示したブロック図である。帳票サーバー１０５Ｂも同様である。帳票リクエスト処理部５０１は、インターネット１００を経由して帳票データ生成リクエスト及び帳票データ取得リクエストを受信する。帳票制御部５０２は、帳票リクエスト処理部５０１が受信したリクエストに応じて必要な処理を行い、応答データを呼び出し元に返す。また、帳票制御部５０２はイントラネット１０１経由でアクセス管理サービスシステム１０４に対して認証リクエストを送信し、認証結果を受信する。また、アクセス管理サービスシステム１０４に対して認可確認リクエストを送信し、認可確認結果を受信する。帳票データ処理部５０３は、帳票制御部５０２から帳票データ生成リクエストを受信して、帳票データを生成する。また、帳票データ処理部５０３は生成した帳票データを応答として帳票制御部５０２に返す。帳票データ管理部５０４は、帳票データ処理部５０３における帳票データ生成処理に使用される帳票フォームデータ及び帳票データを登録、管理する。また、帳票制御部５０２からの帳票データ取得リクエストを受信して、応答として帳票データを返す。
＜外部サービスシステムにより管理される情報＞
図６は、外部サービスシステム１０３が保持する認可情報、認可コードおよび外部サービスシステムの認証情報のデータ構造をテーブル形式で示した図である。認可情報および認可に関連する情報は認可情報管理テーブル６００、認可コードは認可コードテーブル６１０、外部サービスシステムの認証情報はクライアントクレデンシャルテーブル６２０で管理される。
認可情報管理テーブル６００は、連携対象のシステム名を示す連携先システム名６０１、認可情報を示すアクセストークンＩＤ６０２、更新認可情報を示すリフレッシュトークンＩＤ６０３、初回リフレッシュトークンＩＤ６０４を含む。アクセストークンＩＤ６０３には、アクセス管理サーバーが発行するアクセストークンを保存する。リフレッシュトークンＩＤ６０３には、アクセス管理サーバーが発行するリフレッシュトークンを保存する。初回リフレッシュトークンＩＤ６０４には、最初の認可処理時にアクセス管理サーバーが発行する最初のリフレッシュトークンを保存する。また、リフレッシュ処理を実施すると、アクセストークンＩＤ６０２およびリフレッシュトークンＩＤ６０３は、再発行された認可情報および更新認可情報によりそれぞれ更新される。しかしながら、初回リフレッシュトークンＩＤ６０４には、最初のリフレッシュ処理に利用した更新認可情報が引き継いで記憶される。なおいずれもフィールド名称がトークンＩＤとなっているが、格納しているのはトークンのＩＤではなくトークンそのものである。
認可コードテーブル６１０は、連携対象のシステム名を示す連携先システム名６１１と、アクセス管理サービスシステム１０４が生成する認可コードとを一意に識別する認可コードＩＤ６１２とを含む。
認証情報テーブル６２０は、連携対象のシステム名を示す連携先システム名６２１と、連携対象のシステムに対して外部サービスシステム１０３を認証するためのクライアントＩＤ６２２と、パスワード６２３とを含む。図６の各データ構造に格納されるデータの処理詳細については後述する。なお外部サーバーシステム１０３が管理する認可情報管理テーブル６００の１つのレコードを、本実施形態ではクライアント認可関連情報と呼ぶこともある。
＜アクセス管理サービスシステムにより管理される情報＞
図７、図８、図９にアクセス管理サービスシステム１０４が保持する、認可及び認証に係る各種情報を示す。図７は、アクセス管理サービスシステム１０４が保持するユーザー情報およびシステム情報のデータ構造をテーブル形式で示した図である。ユーザー情報はユーザーテーブル７００、システム情報はクライアントテーブル７１０で管理される。
ここで管理されているユーザー情報とは、アクセス管理サービス１０４が管理しているシステム（ＯＡｕｔｈにおけるリソースサーバー）のユーザーの情報である。本実施形態においては、管理しているシステムの例として帳票サービスシステム１０５のユーザーが登録されている。
ここで管理されているシステム情報とは、ＯＡｕｔｈにおいて、認可サーバー（本例のアクセス管理サービスシステムに相当）がアクセストークンの発行およびリフレッシュ処理の際に行う、クライアントの認証に利用する認証情報である。本実施形態においては、クライアントである外部サービスシステム１０３を識別するためのクライアントＩＤとパスワードとを含む。
ユーザーテーブル７００は、ユーザーＩＤ７０１とパスワード７０２から成るユーザー情報を含む。クライアントテーブル７１０は、クライアントのＩＤを示すクライアントＩＤ７１１と、パスワード７１２から成るシステム情報を含む。図７の各データ構造に格納されるデータの処理詳細については後述する。
図８は、アクセス管理サービスシステム１０４が保持する認可コードのデータ構造をテーブル形式で示した図である。認可コードは認可コードテーブル８００で管理される。
認可コードテーブル８００は、認可コードを一意に識別する値を示す認可コードＩＤ８０１と、認可を実施したユーザーを一意に識別するユーザーＩＤ８０２から成る。認可コードは、リソースサーバーのアクセス権限を有するオーナーによるリソースサーバーへのアクセスの許可、すなわち本例では帳票サービスシステム１０５に対するアクセス権限を有するユーザーによる帳票サービスシステム１０５へのアクセスの許可を示すコードである。すなわち、認可コードに基づいて、リソースサーバーへのアクセス権限がオーナーからクライアントへと委譲される。図８のデータ構造に格納されるデータの処理詳細については後述する。
（認可情報）
図９は、アクセス管理サービスシステム１０４が保持する認可情報のデータ構造をテーブル形式で示した図である。認可情報は認可情報管理テーブル９００で管理される。なお認可情報とはアクセストークンに対応し、更新認可情報とはリフレッシュトークンに対応している。また図９においてフィールド９０１〜９０８の一組の情報を本実施形態では認可関連情報と呼ぶことがある。
認可情報管理テーブル９００は、ひとつのアクセス権限ごとに、認可情報であるアクセストークンＩＤ９０１と、アクセストークン発行日時９０２と、アクセストークン有効日時（すなわち有効期限）９０３とを持つ。また、更新認可情報であるリフレッシュトークンＩＤ９０４と、リフレッシュトークン発行日時９０５と、リフレッシュトークン有効日時９０６とを持つ。さらに認可情報管理テーブル９００は、アクセス権限ごとに、当該アクセストークンによるリソースサーバー（すなわち帳票サービスシステム）へのアクセスを許可したユーザーのユーザーＩＤ９０７と、初回リフレッシュトークンＩＤ９０８を持つ。初回リフレッシュトークンＩＤ９０８には、当該アクセス権限に関する最初のアクセストークンと合わせて発行されたリフレッシュトークンＩＤを保存する。
なお、アクセス管理サービスシステム１０４がアクセストークンのリフレッシュ処理を行うと、アクセストークンおよびリフレッシュトークンともに再発行される。再発行されたアクセストークンも、元となるアクセストークンと同じひとつのアクセス権限に係るものである。しかし再発行されたアクセストークン等の認可関連情報とその元となるアクセストークン等の認可関連情報と区別する場合には、それぞれに「元」や「新」を付することにする。すなわちリフレッシュトークンを用いてリフレッシュ処理が行われると、新アクセストークン及び新リフレッシュトークンが再発行される。再発行前のものはそれぞれ元アクセストークン及び元リフレッシュトークンと呼ぶ。またひとつのアクセス権限に係る最初のアクセストークンおよびリフレッシュトークンをそれぞれ初回アクセストークンおよび初回リフレッシュトークンと呼ぶ。リフレッシュ処理により再発行されたアクセストークン及びリフレッシュトークンは、それらの発行日時や有効日時とともに許可情報管理テーブル９００に保存される。有効日時は、発行日時に所定の期間を加えて得ることができる。ユーザーＩＤ９０７には、リフレッシュ処理のために利用されたリフレッシュトークンに関連付けて格納されているユーザーＩＤを格納し、初回リフレッシュトークンＩＤ９０８には、利用したリフレッシュトークンに関連付けて格納されている初回リフレッシュトークンの値を格納する。ただし、利用したリフレッシュトークンに関連付けて保存されている初回リフレッシュトークンの値が"ｎｕｌｌ"であった場合には、リフレッシュ処理に利用したリフレッシュトークンの値が初回リフレッシュトークンであるので、その値を当該アクセス権限の初回リフレッシュトークンＩＤ９０８として保存する。もちろんｎｕｌｌの代わりに初回リフレッシュトークンを保存しておいてもよい。 また、リフレッシュ前のアクセストークンの有効日時およびリフレッシュトークンの有効日時がいずれも満了している場合には、当該アクセス権限に係る一組の情報はもはや不要なので、認可情報管理テーブル９００から削除できる。リフレッシュ前の元アクセストークンの有効日時が満了していない場合には、その元アクセストークンが使用される可能性があることから、その元アクセストークンに対応した認可関連情報は削除せずにそのまま残す。また認可情報管理テーブル９００にアクセスする際に、トークンの有効日時が満了しているか判定し、満了していればその都度削除してもよい。アクセス権限の認証の際、またはトークンのリフレッシュの際には、有効日時を参照してアクセス権限またはリフレッシュの権限が判定されるので、削除は必須ではない。しかし削除により記憶領域の効率化を図ることができる。なおリフレッシュトークンは、いったん利用されてリフレッシュ処理が行われると無効化される。
ここで図６と図９の認可情報管理テーブルの関係について簡単に説明する。外部サービスシステム１０３すなわちクライアントが管理する認可情報管理テーブル６００には、ひとつのアクセス権限について、当該クライアントが管理する最新のアクセストークンおよびリフレッシュトークン及びその初回リフレッシュトークンがクライアント認可関連情報として格納されている。またアクセス管理サービスシステム１０４すなわち認可サーバーが管理する認可情報管理テーブル９００には、ひとつのアクセス権限について、有効なアクセストークンまたは有効なリフレッシュトークンを含む認可関連情報がすべて格納されている。このため、適正なリフレッシュ処理によりトークンが更新されている限りは、最新のアクセストークン及びリフレッシュトークンについては、後述する手順により、外部サービスシステム１０３（クライアント）とアクセス管理サービスシステム１０４（認可サーバー）との間で同期が保たれている。しかしリフレッシュトークン及びクライアントクレデンシャルの漏えいにより不正なリフレッシュ処理（再発行処理または更新処理とも呼ぶ）が行われるとその同期が失われる。
図６及び図９の認可情報管理テーブルはその状態を例示している。図９の認可情報管理テーブル９００には、"EFGH5678"を初回アクセストークンとするアクセス権限について３組の認可情報が登録されている。このうち最新のアクセストークンは"MNOP3456"であり、最新のリフレッシュトークンは"8901JKL"、初回リフレッシュトークンは"0123ABCD"である。これに対して図６の認可情報管理テーブル６００では、初回リフレッシュトークン"0123ABCD"に対応したアクセストークンは"IJKL9012"であり、リフレッシュトークンは"4567EFGH"である。これらのアクセストークン及びリフレッシュトークンは認可情報管理テーブル９００にも格納されているが、すでに最新のものではない。すなわち、同期は失われている。その原因はたとえば、上述したように漏えいしたリフレッシュトークン及びクライアントクレデンシャルを用いて、本来なら無権限の第三者が要求した不正なリフレッシュ処理などである。
図９のデータ構造に格納されるデータの処理詳細については後述する。
＜アクセストークン発行処理＞
以下、本発明における処理フローについてフローチャートを用いて説明する。
図１０は、アクセス管理サービスシステム１０４が、外部サービスシステム１０３に対して、帳票サービスシステム１０５の利用を許可するアクセストークンを発行するアクセストークン発行フローである。図１０において外部サービスシステム１０３と帳票サービスシステム１０５はそれぞれ別のサービス提供者が運営しているオンラインサービスシステムである。また、帳票サービスシステム１０５はアクセス管理サービス１０４によって、別のサービスを含むユーザーからのアクセスが制御されている。外部サービスシステム１０３は、帳票サービスシステム１０５が提供する帳票データを利用したサービスたとえば印刷サービスをユーザーに対して提供する。
ここで、外部サービスシステム１０３が帳票サービスシステム１０５を利用するためには、外部サービスシステム１０３に対して帳票生成指示を行ったユーザーが、外部サービスシステム１０３および帳票サービスシステム１０５の両方のユーザーでなければならない。また、帳票生成サービスシステム１０５に対して実際に帳票生成リクエストを送信するのは外部サービスシステム１０３である。そのため、外部サービスシステム１０３も帳票サービスシステム１０５のユーザーでなければならない。そのうえで、帳票生成指示を行ったユーザーの権限の範囲内で、帳票サービスシステム１０５を外部サービスシステム１０３が利用できるようにしなくてはならない。具体的には、外部サービスシステム１０３に対してサービスを要求するユーザーは、外部サービスシステム１０３に対して帳票サービスシステム１０５の利用を許可して、外部サービスシステム１０３による帳票サービスシステム１０５の利用の認可をしなければならない。なお、以降の説明において情報機器端末１０２を操作するユーザーを「ユーザー」と呼称する。
ステップＳ１００１において、情報機器端末１０２Ａはウエブブラウザなどのユーザーエージェントを実行しており、ユーザーＡによる操作を受け付けている。ユーザーＡが情報機器端末１０２Ａを操作し、外部サービスシステム１０３に対して帳票生成指示を行うと、その帳票生成指示は、ネットワークを介して外部サービスシステム１０３で実行されている例えばウエブサービスに対して送信される。なお情報機器端末１０２Ａと外部サービスシステム１０３との間は本例ではＨＴＴＰであり、本手順で説明する外部サービスシステム１０３による中核的な処理はそのバックエンドとして実行されるが、これ以降ではＨＴＴＰの部分についての説明は省略する。
ステップＳ１００２において、外部サービスシステム１０３は情報機器端末１０２Ａから帳票生成指示を受け付ける。その後、外部サービスシステム１０３は、帳票サービスシステム１０５に対するアクセストークンを認可情報管理テーブル６００に所持しているかの確認を行う。もし帳票サービスシステム１０５に対するアクセストークンを所持している場合、アクセストークン発行フローを終了する。帳票サービス１０５に対するアクセストークンを所持していない場合、外部サービスシステム１０３はステップＳ１００３において、アクセス管理サービスシステム１０４に対して認可要求を送信する。
ステップＳ１００４において、アクセス管理サービスシステム１０４は外部サービス１０３からの認可要求を受けると、ユーザーＡに対して認証処理を促す認証画面（不図示）を生成し、情報機器端末１０２Ａが備えるＷｅｂブラウザ（不図示）に対して送信して表示させる。
ステップＳ１００５において、ユーザーＡは、情報機器端末１０２ＡのＷｅｂブラウザに表示された認証画面に、ユーザーＩＤとパスワードとを認証情報として入力する。情報機器端末１０２Ａは、アクセス管理サービスシステム１０４に対して入力された認証要求を送る。
ステップＳ１００６において、アクセス管理サービスシステム１０４は情報機器端末１０２から認証要求を受け、ユーザーＩＤおよびパスワードを検証する。具体的には、認証要求に含まれるユーザーＩＤとパスワードの組み合わせが認証データ管理部４０３に格納されたユーザーテーブル７００に登録されているかを判定する。
受信したユーザーＩＤとパスワードの組合せがユーザーテーブル７００に登録されていた場合には、情報機器端末１０２を操作するユーザーＡを帳票サービスシステム１０５のユーザーであると判断し、ステップＳ１００９に進み、処理を継続する。
ステップＳ１００９において、アクセス管理サービス１０４は後述する認可画面１１００を生成し、情報機器端末１０２が備えるＷｅｂブラウザ（不図示）に送信する。
ステップＳ１０１０において、情報機器端末１０２が備えるＷｅｂブラウザは認可画面１１００を受信して表示する。ユーザーが認可画面１１００の認可ボタン１１０２を押下すると、情報機器端末１０２Ａはアクセス管理サービスシステム１０４に対して、認可承認を送信する。
ステップＳ１０１１において、アクセス管理サービス１０４は、受け取った認可承認を基に認可コードを生成し、認可データ管理部４０４で管理される認可コードテーブル８００に、認可したユーザーＩＤと関連付けて格納する。さらにアクセス管理サービス１０４は、情報機器端末１０２Ａが備えるＷｅｂブラウザ（不図示）を外部サービスシステム１０３にリダイレクトさせ、生成した認可コードをステップＳ１００３における要求に対する応答として外部サービスシステム１０３に返す。
ステップＳ１０１２において、外部サービスシステム１０３は受け取った認可コードを認可コードテーブル６１０に格納する。その後、アクセス管理サービスシステム１０４に対して、認可コードと認証情報テーブル６２０に格納されているクライアントＩＤとパスワードとともにアクセストークンの発行要求であるアクセストークン要求を送信する。
ステップＳ１０１３において、アクセス管理サービス１０４はアクセストークン要求を受け、外部サービスシステム１０３の認証を行う。具体的には、アクセストークン要求に含まれるクライアントＩＤとパスワードの組合せが認証データ管理部４０３に格納されたクライアントテーブル７１０に登録されているかを判定する。
クライアントＩＤとパスワードの組み合わせがクライアントテーブル７１０に登録されていた場合には、アクセストークン要求を行った外部サービスシステム１０３を帳票サービスシステム１０５のユーザーであると判断する。アクセス管理サービスシステム１０４は、外部サービスシステム１０３を認証すると、ステップＳ１０１４に進み、処理を継続する。
ステップＳ１０１４において、アクセス管理サービス１０４はアクセストークン要求に含まれる認可コードの検証を行う。具体的には、アクセストークン要求とともに受信した認可コードが認証データ管理部４０３に格納された認可コードテーブル８００に登録されているかを判定する。
認可コードが認可コードテーブル８００に登録されていた場合には、ユーザーによって帳票サービスシステム１０５の利用が許可されていると判断し、ステップＳ１０１６に進み、処理を継続する。
ステップＳ１０１６において、アクセス管理サービスシステム１０４は、アクセストークンおよびリフレッシュトークンを生成し、認可データ管理部４０４で管理される認可情報管理テーブル９００に生成したトークンを格納する。その際、トークンを生成した時刻をアクセストークン発行日時９０２およびリフレッシュトークン発行日時９０５に設定する。また、アクセストークンの有効期間をアクセストークン有効日時９０３に、リフレッシュトークンの有効期間をリフレッシュトークン有効日時９０６に設定する。ユーザー情報として、検証に成功した認可コードを発行したユーザーＩＤをユーザーＩＤ９０７に設定する。そして、初回リフレッシュトークンＩＤ９０８に、最初に発行されたリフレッシュトークン情報を設定する。
本実施形態において、ユーザーが最初に連携システムを利用した際に、アクセストークンおよびリフレッシュトークンが発行された場合は、初回リフレッシュトークンＩＤ９０８には該当するリフレッシュトークンなしを意味する"ｎｕｌｌ"を設定している。ここで、初回リフレッシュトークンＩＤ９０８に、発行したリフレッシュトークン情報としてリフレッシュトークンＩＤ９０４と同じ値を設定してもよい。
その後、アクセス管理サービスシステム１０４は、生成したアクセストークンとリフレッシュトークンをステップＳ１０１３の応答として外部サービス１０３に返す。
ステップＳ１０１７において、外部サービス１０３は受け取ったアクセストークンおよびリフレッシュトークンを、トークン管理部３０５で管理される認可情報管理テーブル６００に格納する。具体的には、受け取ったアクセストークンをアクセストークンＩＤ６０２に設定し、受け取ったリフレッシュトークンをリフレッシュトークンＩＤ６０３および初回リフレッシュトークンＩＤ６０４に設定する。
こうして発行したアクセストークンおよびリフレッシュトークンを保存することで、アクセストークン発行フローを終了する。
一方ステップＳ１００６において、受信したユーザーＩＤとパスワードの組合せがユーザーテーブル７００に登録されていない場合には、情報機器端末１０２を操作するユーザーＡを帳票サービスシステム１０５のユーザーではないと判断する。その後、外部サービスシステム１０３に対し、ステップＳ１００４の応答として認証エラーを返す。ステップＳ１００７において、外部サービスシステム１０３は認証エラーを受け取ると、認証エラー画面（不図示）を生成し、情報機器端末１０２Ａに送る。その後、ステップ１００８において、情報機器端末１０２が備えるＷｅｂブラウザ（不図示）にエラー画面を送信して表示させ、処理を終了する。
またステップＳ１０１３において、クライアントＩＤ、パスワードの組合せがクライアントテーブル７１０に登録されていない場合には、アクセストークン要求を行った外部サービスシステム１０３を帳票サービスシステム１０５のユーザーではないと判断する。その後、認証エラーを外部サービスシステム１０３に送信して、ステップＳ１０１５に進む。
ステップＳ１０１４において、認可コードが認可コードテーブル８００に登録されていなかった場合には、ユーザーによって帳票サービスの利用が許可されていないと判断する。その後、認可エラーを外部サービスシステム１０３に送信して、ステップＳ１０１５に進む。
ステップＳ１０１５において、外部サービスシステム１０３がアクセス管理サービスシステム１０４から認証エラー、あるいは認可エラーを受け取る。外部サービスシステム１０３は、受け取ったエラーに対応した認証エラー画面あるいは認可エラー画面（不図示）を生成し、情報機器端末１０２に送る。
ステップ１００８において、情報機器端末１０２Ａは、受け取ったエラー画面を表示し、処理を終了する。
以上の手順により発行されたアクセストークンをクライアントすなわち外部サービスシステム１０３で保存管理し、リソースサーバーすなわち帳票サービスシステム１０５へのアクセスのために用いることで、外部サービスシステム１０３は、ユーザーのクレデンシャルの開示を受けることなく、ユーザーの帳票サービスシステム１０５に対するアクセス権限を利用することができる。
＜画面例＞
図１１は、アクセス管理サービスシステム１０４がステップＳ１００４において生成する認可画面を示した図である。認可画面１１００は、情報表示部１１０１と認可ボタン１１０２、認可キャンセルボタン１１０３から構成される。情報表示部１１０１は、認可されるサービスと、認可されたサービスが実行するサービスの情報をユーザーに対して示す情報表示部である。本実施形態においては、認可されるサービスとは外部サービスシステム１０３であり、認可されたサービスが実行するサービスとは帳票サービスシステム１０５を指す。認可ボタン１１０２は、認可を承認する際にユーザーによって押下されるボタンである。認可キャンセルボタン１１０３は、ユーザーが認可を拒否する場合に押下されるボタンである。
＜帳票サービスシステムに対するアクセス手順＞
図１２は、ユーザーが外部サービスシステム１０３に対して、帳票サービスシステム１０５の利用を許可する認可処理のフローを示した図である。図１２の手順は、図１０によるトークンの発行手順を含んでおり、さらに帳票サービスシステム１０５に対して外部サービスシステム１０３がアクセスする手順まで含んでいる。
ステップＳ１００１とＳ１００２は図１０で説明したフローと同じである。また、ステップＳ１２０１は図９におけるステップＳ１００３からＳ１０１７までの、アクセストークンの発行フローを示す。図１２においてはこのステップは外部サービスシステム１０３による処理として示されているが、これは記載上の便宜であって、実際には図１０に記載した通りに、他のシステムと連携してトークンを発行している。ステップＳ１２０１により、要求されたサービスに対するアクセストークンがなければ新たに発行される。
ステップＳ１２０２において、外部サービスシステム１０３は、認可情報管理テーブル６００に格納されている、帳票サービスシステム利用のためのアクセストークンを利用し、帳票サービスシステム１０５に対して帳票生成要求を送る。すなわち、クライアントがリソースサーバーに対してサービスを要求するためのアクセス要求を送信する。ここで「利用」するとは、サービス要求のメッセージとともに、その要求について要求元が認可されていることを示すアクセストークンを要求先に送信することである。ここで、アクセストークン「ＩＪＫＬ９０１２」を渡したとする。
ステップＳ１２０３において、帳票サービスシステム１０５は、アクセス管理サービスシステム１０４に対して、帳票生成要求で送られたアクセストークンの検証を要求する。
ステップＳ１２０４において、アクセス管理サービスシステム１０４は、受け取ったアクセストークンの検証を行う。具体的には、受け取ったアクセストークンが認可情報管理テーブル６００に登録されているかの判定を行い、登録されていた場合は、アクセストークンが有効期間内かの判定を行う。アクセストークンが登録されており、かつ有効期間内であった場合は、アクセストークン有効を応答として返す。アクセストークンが登録されていなかった場合や、登録されていたが有効期間外であった場合は、アクセストークン無効を応答として返す。ここで、検証を行った時刻が「２０１１年４月１日１５時」であり、アクセストークン「ＩＪＫＬ９０１２」が渡されたとする。この場合、認可情報管理テーブル９００にはアクセストークン「ＩＪＫＬ９０１２」が登録されているが、アクセストークン有効日時９０３に設定されている時刻を過ぎているため、アクセストークン無効と判断される。
ステップＳ１２０５において、帳票サービスシステム１０５は、アクセス管理サービス１０４から返されたアクセストークン検証結果を受け取る。アクセストークンが有効の場合、帳票作成機能へのアクセスを許可し、ステップＳ１２０６に進む。アクセストークンが無効の場合、外部サービスシステム１０３に対して、アクセストークン無効をステップＳ１２０３の応答として返し、ステップＳ１２０９に進む。
ステップＳ１２０６において、帳票サービスシステム１０５は帳票を生成し、生成した帳票データをステップＳ１２０３の応答として外部サービスシステム１０３に返す。
ステップＳ１２０７において、外部サービスシステム１０３は帳票サービスシステム１０５から帳票データを受け取り、情報機器端末１０２Ａに送信する。
ステップＳ１２０８において、情報機器端末１０２Ａは、情報機器端末１０２Ａが備えるＷｅｂブラウザ（不図示）に受け取った帳票データを表示し、帳票生成指示を正常に終了する。
（トークンの再発行処理）
ステップＳ１２０９において、外部サービスシステム１０３は、アクセストークン無効を受けてアクセス管理サービス１０４に対してリフレッシュ処理を要求する。具体的には、認可情報管理テーブル６００に保存されている、帳票サービスシステム１０５のリフレッシュトークンおよび帳票サービスシステム１０５に対するクライアントＩＤ及びパスワードとともに、リフレッシュ処理要求をアクセス管理サービスシステム１０４に送る。ここで、リフレッシュトークン「４５６７ＥＦＧＨ」を渡したとする。
ステップＳ１２１０において、アクセス管理サービスシステム１０４は、外部サービスシステム１０３の認証を行う。具体的には、リフレッシュ処理要求に含まれるクライアントＩＤとパスワードの組合せが、認証データ管理部４０３に格納されたクライアントテーブル７１０に登録されているかを判定する。
クライアントＩＤ、パスワードの組合せがクライアントテーブル７１０に登録されていた場合には、帳票サービスシステム１０５が外部サービスシステム１０３との連携を許可していると判断し、ステップＳ１２１３に進み、処理を継続する。
クライアントＩＤ、パスワードの組合せがクライアントテーブル７１０に登録されていない場合には、外部サービスシステム１０３に対して認証エラーを返し、ステップＳ１２１１に進む。
ステップＳ１２１１において、外部サービスシステム１０３は認証エラーを受け取ると、認証エラー画面（不図示）を生成し、情報機器端末１０２Ａに送る。その後、ステップ１２１２において、情報機器端末１０２が備えるＷｅｂブラウザ（不図示）にエラー画面を表示し、処理を終了する。
ステップＳ１２１３において、アクセス管理サービスシステム１０４は、リフレッシュ処理要求で送られたリフレッシュトークンの検証を行う。具体的には、受け取ったリフレッシュトークンが認可情報管理テーブル６００に登録されているかの判定を行い、登録されていた場合は、さらにリフレッシュトークンが有効期間内かの判定を行う。受信したリフレッシュトークンが登録されており、かつ有効期間内であった場合は、リフレッシュトークンを有効と判断し、ステップＳ１２１４に進み、処理を継続する。
受信したリフレッシュトークンが登録されていないか、あるいは登録されているが有効期間内でなかった場合は、リフレッシュトークンを無効と判断し、外部サービスシステム１０３に対してトークン無効を応答として返し、ステップＳ１２１７に進む。ここで、「２０１１年４月１日１４時３０分」にリフレッシュトークン「４５６７ＥＦＧＨ」が渡されたとする。この場合、認可情報管理テーブル９００にはリフレッシュトークン「４５６７ＥＦＧＨ」が登録されているが、リフレッシュトークン有効日時９０６に設定されている時刻を過ぎているため、リフレッシュトークン無効と判断される。
ステップＳ１２１４において、アクセス管理サービスシステム１０４は、新たにアクセストークンとリフレッシュトークンを生成し、認可データ管理部４０４で管理される認可情報管理テーブル９００に格納する。その際、認可情報管理テーブル９００から、ステップＳ１２１０で検証したリフレッシュトークンに設定されている初回リフレッシュトークンＩＤ９０８の値を取得し、新たに格納するトークンの初回リフレッシュトークンとして登録する。なお、初回リフレッシュトークンＩＤ９０８の値が"ｎｕｌｌ"であった場合は、検証に利用したリフレッシュトークンを初回リフレッシュトークンとして登録する。
ステップＳ１２１５において、アクセス管理サービス１０４は、検証に利用したリフレッシュトークンを無効にする。具体的には、認可情報管理テーブル９００の対応するリフレッシュトークンについて、リフレッシュトークン有効日時９０６の値をリフレッシュトークン発行日時９０５の値に更新する。なお、本実施形態ではリフレッシュトークンの有効日時を更新することで無効化を行ったが、他の方法で実施してもよい。例えば、認可情報管理テーブル９００にリフレッシュトークン有効フラグの項目を定義し、その項目の値を更新することで無効化を行ってもよい。その後、アクセス管理サービスシステム１０４は、新たに発行したアクセストークンおよびリフレッシュトークンを、ステップＳ１２１０の応答として外部サービスシステム１０３に返す。
ステップＳ１２１６において、外部サービスシステム１０３は、認可情報管理テーブル６００に登録されている、帳票サービスシステム１０５のアクセストークンおよびリフレッシュトークンの値を、受け取ったアクセストークンおよびリフレッシュトークンで更新する。具体的には、認可情報管理テーブル６００に登録されている帳票サービスシステムのアクセストークンＩＤ６０２およびリフレッシュトークンＩＤ６０３に、受け取ったアクセストークンとリフレッシュトークンをそれぞれ設定する。この際初回リフレッシュトークンＩＤ６０４は更新しない。
その後ステップＳ１２０２に進み、外部サービスシステム１０３は再び帳票生成要求を行う。
ステップＳ１２１４において、外部サービスシステム１０３は、リフレッシュトークン無効応答を受けて、認可情報の無効化を要求する。具体的には、認可情報管理テーブル６００に登録されている帳票サービスシステムの初回リフレッシュトークンの値をアクセス管理サービス１０４に送る。ここで、初回リフレッシュトークンとして「０１２３ＡＢＣＤ」を渡したとする。
ステップＳ１２１５において、アクセス管理サービス１０４は、後述のトークン無効化処理を行う。
ステップＳ１２１６において、外部サービスシステム１０３は、帳票サービスシステム１０５の認可情報の削除を行う。具体的には、認可情報管理テーブル６００に登録されている帳票サービスシステム１０５のアクセストークンＩＤ６０２、リフレッシュトークンＩＤ６０３、初回リフレッシュトークンＩＤ６０４の値を削除する。
その後ステップＳ１２０１に進み、外部サービスシステム１０３は再びアクセストークン発行処理を行う。
（アクセストークンの無効化処理）
ステップＳ１２１７では、外部サービスシステム１０３が、本実施形態の特徴である、初回リフレッシュトークンを利用したリフレッシュトークンの無効化処理をアクセス管理サービスステム１０４に対して要求する。ここでは、無効化処理要求とともに、認可情報管理テーブル６００に登録された、帳票サービスシステム１０５に対する初回リフレッシュトークンを送信する。無効化処理要求を受信したアクセス管理サービスステム１０４は、ステップＳ１２１８において、受信したリフレッシュトークンが初回リフレッシュトークンとして登録されたリフレッシュトークンの無効化処理を実行する。この詳細は図１３を参照して後述する。リフレッシュトークンの無効化処理を行ったなら、無効化を完了した旨を外部サービスシステム１０３に応答する。応答を受信した外部サービスシステム１０３は、ステップＳ１２１９において、無効化されたリフレッシュトークンを含むクライアント認可関連情報を認可情報管理テーブル６００から削除する。なお、ステップＳ１２１９の時点では、アクセストークンはすでに無効となっている。この後、あらためて外部サービスステム１０３はステップＳ１２０１に進んでアクセストークン及びリフレッシュトークンを新たに発行する処理を行う。なお本例では不要としているが、リフレッシュ処理要求と同様に、帳票サービスシステム１０５に対するクライアントＩＤとパスワードとの組を併せて送信するように構成してもよい。その場合には、アクセス管理サービスステム１０４は、ステップＳ１２１８の直前に、ステップＳ１２１０と同様に権限の認証を行い、認証が成功したならステップＳ１２１８でリフレッシュトークンの無効化を行う。
＜リフレッシュトークン無効化処理手順＞
図１３は、第１の実施形態におけるリフレッシュトークンの無効化処理、すなわち図１２のステップＳ１２１８の詳細なフローを示した図である。
ステップＳ１３０１において、アクセス管理サービスシステム１０４は、リフレッシュトークンの無効化要求と共に、リフレッシュトークンを受け付ける。ここで、リフレッシュトークン「０１２３ＡＢＣＤ」が渡されたとする。
ステップＳ１３０２において、アクセス管理サービス１０４は、受け取ったリフレッシュトークンが初回リフレッシュトークンである全てのリフレッシュトークンを無効とする。具体的には、受け取ったリフレッシュトークンが、認可情報管理テーブル９００の初回リフレッシュトークンＩＤ９０８に登録されているリフレッシュトークンを無効化する。たとえば無効化は、リフレッシュトークン有効日時９０６の値をリフレッシュトークン発行日時９０５の値に更新することで行う。今回の例では初回リフレッシュトークンＩＤ９０８の値が「０１２３ＡＢＣＤ」であるリフレッシュトークン「４５６７ＥＦＧＨ」、「８９０１ＩＪＫＬ」が対象となる。ただし、リフレッシュトークン「４５６７ＥＦＧＨ」は既に無効となっているため、無効とされるリフレッシュトークンは「８９０１ＩＪＫＬ」のみとなる。
ステップＳ１３０３において、アクセス管理サービスシステム１０４は、受け取ったリフレッシュトークンを無効とする。具体的には、認可情報管理テーブル９００の対応するリフレッシュトークンについて、リフレッシュトークン有効日時９０６の値をリフレッシュトークン発行日時９０５の値に更新する。なお、最初にアクセストークンとリフレッシュトークンを発行した際に、発行したリフレッシュトークンを初回リフレッシュトークンとして登録している場合には、ステップＳ１３０２において当該リフレッシュトークンも無効化されるので本ステップは省略しても良い。また、初回リフレッシュトークンが"ｎｕｌｌ"であるリフレッシュトークンを無効とするフローは、ＯＡｕｔｈで定義されている従来通りの無効化方式である。今回の例では、リフレッシュトークン「０１２３ＡＢＣＤ」が対象となる。ただし、リフレッシュトークン「０１２３ＡＢＣＤ」は既に無効となっているため、本ステップではリフレッシュトークンの無効化は行われない。
なお、受信したリフレッシュトークンが、認可情報管理テーブル９００のどの初回リフレッシュトークンにも該当しない場合にはステップＳ１３０２ではなにも行わない。こうすることで、従来のＯＡｕｔｈの手順で無効化要求を発行するクライアントに対する互換性を維持できる。
これらの処理により、最初に発行されたリフレッシュトークンが元となる一連のリフレッシュ処理で発行されている、全てのリフレッシュトークンが無効となる。
（本実施形態の効果）
リフレッシュトークンが無効である場合は、リフレッシュ処理がされずに有効期限が経過していた場合と、リフレッシュ処理が行われて新リフレッシュトークンが発行された結果、当該リフレッシュトークンが無効化された場合の２パターンとなる。
外部サービスシステム１０３には最新のリフレッシュトークンが記憶されているため、リフレッシュ処理がされずに有効期限が経過していた場合には、帳票サービスシステムの全てのリフレッシュトークンが無効となっているはずである。そのため、帳票サービスシステムの全てのリフレッシュトークンを無効にしても、システムに影響は与えない。
一方、リフレッシュ処理が行われてリフレッシュトークンが無効になっていた場合には、外部サービスシステム１０３が知らないリフレッシュ処理が行われたこととなる。例えば、不正な外部サービスシステム（不図示）がリフレッシュ処理を行った場合などである。この場合、不正な外部サービスシステムが、外部サービスシステム１０３に成り代わって帳票サービスシステム１０５を利用している可能性がある。このような場合でも本実施形態によるリフレッシュトークンの無効化を行う事で、不正に発行したリフレッシュトークンも無効となる。そのため、無効化処理以降の不正な外部サービスシステムによるリフレッシュ処理を防止できる。これにより、帳票サービスが不正な外部サービスシステムによって、不正に利用し続けられてしまうことを防げる。
［実施形態２］
次に、本発明を実施するための第２の実施形態について図面を用いて説明する。第１の実施形態においては、最初に発行されたリフレッシュトークンが元となる一連のリフレッシュ処理で発行されている全てのリフレッシュトークンを無効にしている。
本実施形態では、リフレッシュトークンを無効にする際に、合わせてアクセストークンも無効とすることで、第１の実施形態において、不正な外部サービスシステムによる成りすましをすぐに防ぐ方法を説明する。なお、本実施形態においては、第１の実施形態と同一部分に関する説明は省略し、その差異についてのみ説明する。なお差異は図１３の手順を図１４の手順に置換したことであり、それについて具体例で説明する。
＜無効化処理手順＞
図１４は、第２の実施形態における認可情報無効化処理のフローを示した図である。ステップＳ１３０１からＳ１３０３は図１３と同様である。
ステップＳ１４０１において、アクセス管理サービス１４は、ステップＳ１３０２およびＳ１３０３において無効としたリフレッシュトークンに対応するアクセストークンを無効にする。具体的には、認可情報管理テーブル９００において、無効化対象となったリフレッシュトークンが登録されているデータに対して、アクセストークン有効日時９０３の値をアクセストークン発行日時９０２の値に更新する。なお、本実施形態ではアクセストークンの有効日時を更新することで無効化を行ったが、他の方法で実施してもよい。例えば、アクセストークンテーブル９００にアクセストークン有効フラグの項目を定義し、その項目の値を更新することで無効化を行ってもよい。ここで、ステップＳ１３０１において、「２０１１年４月１日１４時３０分」にリフレッシュトークン「０１２３ＡＢＣＤ」が渡されたとする。この場合、リフレッシュトークン「０１２３ＡＢＣＤ」、「４５６７ＥＦＧＨ」、「８９０１ＩＪＫＬ」が無効化の対象となる。そのため、アクセストークン「ＥＦＧＨ５６７８」、「ＩＪＫＬ９０１２」、「ＭＮＯＰ３４５６」が無効となる。ただし、アクセストークン「ＥＦＧＨ５６７８」、「ＩＪＫＬ９０１２」は既に無効であるため、アクセストークン「ＭＮＯＰ３４５６」のみが無効化される。
これらの処理により、最初に発行されたリフレッシュトークンを元に行われたリフレッシュ処理で発行された、全てのリフレッシュトークンおよび、全てのアクセストークンが無効になる。
実施形態１に記載の方法でリフレッシュトークンを無効にすることで、不正な外部サービスシステムからのリフレッシュ処理を防げる。さらに、実施形態２に記載の方法により、アクセストークンの無効化も合わせて行える。これにより、不正な外部サービスシステムによりリフレッシュ処理が行われて、帳票サービスが不正利用されていた場合に、不正な外部サービスシステムからの帳票サービスの利用をすぐに止められる。
また、本実施形態に係る発明を実装した認可サーバーは、本実施形態に係る発明を実装したクライアントに対応するのみならず、従来のＯＡｕｔｈプロトコルを実装したクライアントに対する互換性も維持することができる。
［その他の実施例］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (10)

  1. クライアント装置からリソースサーバーへのアクセス要求を、該要求と関連して前記クライアント装置から受信した有効な認可情報に基づいて認可する認可サーバーであって、
    認証情報とともにクライアント装置から受信した発行要求に応じて、前記リソースサーバーへアクセスするために利用される認可情報と、新たな認可情報を前記認証情報なしに再発行するために利用される更新認可情報とを発行する発行手段と、
    更新認可情報とともに受信したリフレッシュ処理要求に応じて、新たな更新認可情報及び新たな認可情報を再発行し、再発行された認可情報及び更新認可情報に関連付けて、新たな更新認可情報及び認可情報を再発行するために前記発行手段により発行した更新認可情報を初回更新認可情報として記憶する再発行手段と、
    更新認可情報とともに受信した無効化要求に応じて、受信した前記更新認可情報が初回更新認可情報として関連付けられている更新認可情報を無効化する無効化手段と
    を有することを特徴とする認可サーバー。
  2. 前記無効化手段は、さらに、受信した前記更新認可情報も更に無効化することを特徴とする請求項１に記載の認可サーバー。
  3. 前記無効化手段は、受信した前記更新認可情報が初回更新認可情報として関連付けられている更新認可情報に加えて、受信した前記更新認可情報が初回更新認可情報として関連付けられた認可情報も無効化することを特徴とする請求項１または２に記載の認可サーバー。
  4. 前記再発行手段は、新たな認可情報を再発行した場合、リフレッシュ処理要求とともに受信した更新認可情報を無効化することを特徴とする請求項１乃至３のいずれか一項に記載の認可サーバー。
  5. リソースサーバーに対して、認可サーバーにより発行された認可情報とともにアクセス要求を送信して前記リソースサーバーによるサービスを要求するクライアント装置であって、
    前記認可サーバーにより発行された認可情報と、新たな認可情報を認証情報なしに再発行するために利用される更新認可情報と、前記認可情報を再発行するために前記認可サーバーが最初に発行した初回更新認可情報とを関連付けて記憶する手段と、
    記憶した前記初回更新認可情報とともに無効化要求を前記認可サーバーに送信して、前記初回更新認可情報に関連付けられた更新認可情報の無効化を要求する無効化要求手段と
    を有することを特徴とするクライアント装置。
  6. アクセス要求に対して、前記認可情報が無効であるとの応答を受信した場合、無効であると応答された前記認可情報に関連付けられた更新認可情報とともに、リフレッシュ処理要求を前記認可サーバーに対して送信する手段を更に有し、
    前記リフレッシュ処理要求に対して、前記更新認可情報が無効であると応答された場合に、前記無効化要求手段による更新認可情報の無効化を要求することを特徴とする請求項５に記載のクライアント装置。
  7. クライアント装置からリソースサーバーへのアクセス要求を、該要求と関連して前記クライアント装置から受信した有効な認可情報に基づいて認可する認可サーバーと、前記リソースサーバーに対して、前記認可サーバーにより発行された認可情報とともにアクセス要求を送信して前記リソースサーバーによるサービスを要求するクライアント装置と、前記クライアント装置に対してサービスを提供する前記リソースサーバーとを含むサーバー連携システムであって、
    前記認可サーバーは、
    認証情報とともにクライアント装置から受信した発行要求に応じて、前記リソースサーバーへアクセスするために利用される認可情報と、新たな認可情報を前記認証情報なしに再発行するために利用される更新認可情報とを発行する発行手段と、
    更新認可情報とともに受信したリフレッシュ処理要求に応じて、新たな更新認可情報及び新たな認可情報を再発行し、再発行された認可情報及び更新認可情報に関連付けて、新たな更新認可情報及び認可情報を再発行するために前記発行手段により発行した更新認可情報を初回更新認可情報として記憶する再発行手段と、
    更新認可情報とともに受信した無効化要求に応じて、受信した前記更新認可情報が初回更新認可情報として関連付けられている更新認可情報、及び、受信した前記更新認可情報を無効化する無効化手段とを有し、
    前記クライアント装置は、
    前記認可サーバーにより発行された認可情報と、新たな認可情報を認証情報なしに再発行するために利用される更新認可情報と、前記認可情報を再発行するために前記認可サーバーが最初に発行した初回更新認可情報とを関連付けて記憶する手段と、
    記憶した前記初回更新認可情報とともに無効化要求を前記認可サーバーに送信して、前記初回更新認可情報に関連付けられた更新認可情報の無効化を要求する無効化要求手段とを有することを特徴とするサーバー連携システム。
  8. クライアント装置からリソースサーバーへのアクセス要求を、該要求と関連して前記クライアント装置から受信した有効な認可情報に基づいて認可する認可サーバーとしてコンピューターを機能させるためのプログラムであって、
    認証情報とともにクライアント装置から受信した発行要求に応じて、前記リソースサーバーへアクセスするために利用される認可情報と、新たな認可情報を前記認証情報なしに再発行するために利用される更新認可情報とを発行する発行手段と、
    更新認可情報とともに受信したリフレッシュ処理要求に応じて、新たな更新認可情報及び新たな認可情報を再発行し、再発行された認可情報及び更新認可情報に関連付けて、新たな更新認可情報及び認可情報を再発行するために前記発行手段により発行した更新認可情報を初回更新認可情報として記憶する再発行手段と、
    更新認可情報とともに受信した無効化要求に応じて、受信した前記更新認可情報が初回更新認可情報として関連付けられている更新認可情報を無効化する無効化手段と
    してコンピューターを機能させるためのプログラム。
  9. リソースサーバーに対して、認可サーバーにより発行された認可情報とともにアクセス要求を送信して前記リソースサーバーによるサービスを要求するクライアント装置としてコンピューターを機能させるためのプログラムであって、
    前記認可サーバーにより発行された認可情報と、新たな認可情報を認証情報なしに再発行するために利用される更新認可情報と、前記認可情報を再発行するために前記認可サーバーが最初に発行した初回更新認可情報とを関連付けて記憶する手段と、
    記憶した前記初回更新認可情報とともに無効化要求を前記認可サーバーに送信して、前記初回更新認可情報に関連付けられた更新認可情報の無効化を要求する無効化要求手段と
    してコンピューターを機能させるためのプログラム。
  10. クライアント装置からリソースサーバーへのアクセス要求を、該要求と関連して前記クライアント装置から受信した有効な認可情報に基づいて認可する認可サーバーと、前記リソースサーバーに対して、前記認可サーバーにより発行された認可情報とともにアクセス要求を送信して前記リソースサーバーによるサービスを要求するクライアント装置と、前記クライアント装置に対してサービスを提供する前記リソースサーバーとを有するサーバー連携システムにおけるトークン管理方法であって、
    前記認可サーバーが、認証情報とともにクライアント装置から受信した発行要求に応じて、前記リソースサーバーへアクセスするために利用される認可情報と、新たな認可情報を前記認証情報なしに再発行するために利用される更新認可情報とを発行する発行工程と、
    前記クライアント装置が、前記認可サーバーにより発行された認可情報と、新たな認可情報を認証情報なしに再発行するために利用される更新認可情報と、前記認可情報を再発行するために前記認可サーバーが最初に発行した初回更新認可情報とを関連付けて記憶する工程と、
    前記クライアント装置が、アクセス要求に対して、前記認可情報が無効であるとの応答を受信した場合、無効であると応答された前記認可情報に関連付けられた更新認可情報とともにリフレッシュ処理要求を前記認可サーバーに対して送信する工程と、
    前記認可サーバーが、更新認可情報とともに受信したリフレッシュ処理要求に応じて、新たな更新認可情報及び新たな認可情報を再発行し、再発行された認可情報及び更新認可情報に関連付けて、新たな更新認可情報及び認可情報を再発行するために前記発行工程により発行した更新認可情報を初回更新認可情報として記憶する再発行工程と、
    前記クライアント装置が、記憶した前記初回更新認可情報とともに無効化要求を前記認可サーバーに送信して、前記初回更新認可情報に関連付けられた更新認可情報の無効化を要求する無効化要求工程と、
    前記認可サーバーが、更新認可情報とともに受信した無効化要求に応じて、受信した前記更新認可情報が初回更新認可情報として関連付けられている更新認可情報を無効化する無効化工程と
    を有することを特徴とするトークン管理方法。
JP2012120140A 2012-05-25 2012-05-25 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法 Active JP6006533B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2012120140A JP6006533B2 (ja) 2012-05-25 2012-05-25 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法
CN201380027459.4A CN104350501B9 (zh) 2012-05-25 2013-04-10 授权服务器和客户端设备、服务器协作***和令牌管理方法
KR1020147035695A KR101640383B1 (ko) 2012-05-25 2013-04-10 인가 서버 및 클라이언트 장치, 서버 연계 시스템, 및 토큰 관리 방법
PCT/JP2013/061344 WO2013175901A1 (en) 2012-05-25 2013-04-10 Authorization server and client apparatus, server cooperative system, and token management method
US14/001,658 US9571494B2 (en) 2012-05-25 2013-04-10 Authorization server and client apparatus, server cooperative system, and token management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012120140A JP6006533B2 (ja) 2012-05-25 2012-05-25 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法

Publications (3)

Publication Number Publication Date
JP2013246655A JP2013246655A (ja) 2013-12-09
JP2013246655A5 JP2013246655A5 (ja) 2015-07-09
JP6006533B2 true JP6006533B2 (ja) 2016-10-12

Family

ID=49623602

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012120140A Active JP6006533B2 (ja) 2012-05-25 2012-05-25 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法

Country Status (5)

Country Link
US (1) US9571494B2 (ja)
JP (1) JP6006533B2 (ja)
KR (1) KR101640383B1 (ja)
CN (1) CN104350501B9 (ja)
WO (1) WO2013175901A1 (ja)

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130311382A1 (en) * 2012-05-21 2013-11-21 Klaus S. Fosmark Obtaining information for a payment transaction
EP2843605A1 (en) * 2013-08-30 2015-03-04 Gemalto SA Method for authenticating transactions
IN2013CH05960A (ja) * 2013-12-20 2015-06-26 Samsung R & D Inst India Bangalore Private Ltd
JP6330338B2 (ja) * 2014-01-22 2018-05-30 ブラザー工業株式会社 通信装置
US10404699B2 (en) * 2014-02-18 2019-09-03 Oracle International Corporation Facilitating third parties to perform batch processing of requests requiring authorization from resource owners for repeat access to resources
KR102133755B1 (ko) * 2014-02-19 2020-07-15 삼성전자주식회사 스마트 홈 서비스에서 기기 등록을 위한 접속 정보 관리 방법 및 장치
JP6346478B2 (ja) * 2014-03-20 2018-06-20 キヤノン株式会社 中継装置、中継方法、中継システム、及びプログラム
JP6454076B2 (ja) * 2014-03-20 2019-01-16 キヤノン株式会社 中継装置、通信装置、それらの制御方法、システム、及びプログラム
JP2015201030A (ja) * 2014-04-08 2015-11-12 富士通株式会社 端末装置、情報管理サーバ、端末プログラム、情報管理プログラム、及びシステム
US10346846B2 (en) 2014-04-24 2019-07-09 Swoop Ip Holdings Llc SMS and social media dual authorization, management oversight, and non-password security in email based e-commerce
US9584515B2 (en) * 2014-04-30 2017-02-28 Citrix Systems, Inc. Enterprise system authentication and authorization via gateway
JP6376869B2 (ja) * 2014-07-10 2018-08-22 キヤノン株式会社 データ同期システム、その制御方法、認可サーバー、およびそのプログラム
US9350726B2 (en) * 2014-09-11 2016-05-24 International Business Machines Corporation Recovery from rolling security token loss
US9313193B1 (en) 2014-09-29 2016-04-12 Amazon Technologies, Inc. Management and authentication in hosted directory service
US9942229B2 (en) 2014-10-03 2018-04-10 Gopro, Inc. Authenticating a limited input device via an authenticated application
DE102014114585A1 (de) * 2014-10-08 2016-04-14 Océ Printing Systems GmbH & Co. KG Verfahren zum Betreiben eines Bedienfelds für ein Produktionssystem sowie Steuervorrichtung für ein Produktionssystem
JP2016085641A (ja) * 2014-10-27 2016-05-19 キヤノン株式会社 権限移譲システム、権限移譲システムにて実行される方法、およびそのプログラム
CN104580207B (zh) 2015-01-04 2019-03-19 华为技术有限公司 物联网中的认证信息的转发方法、装置以及转发器
US10218700B2 (en) * 2015-02-23 2019-02-26 Ca, Inc. Authorizations for computing devices to access a protected resource
US11038894B2 (en) * 2015-04-07 2021-06-15 Hewlett-Packard Development Company, L.P. Providing selective access to resources
US20160315930A1 (en) * 2015-04-24 2016-10-27 Somansa Co., Ltd. Cloud data discovery method and system for private information protection and data loss prevention in enterprise cloud service environment
US11954671B2 (en) * 2015-04-27 2024-04-09 Paypal, Inc. Unified login across applications
CN105471833B (zh) 2015-05-14 2019-04-16 瑞数信息技术（上海）有限公司 一种安全通讯方法和装置
JP2016224684A (ja) * 2015-05-29 2016-12-28 キヤノン株式会社 サーバーシステム、サーバーシステムの制御方法、およびプログラム
US10063557B2 (en) * 2015-06-07 2018-08-28 Apple Inc. Account access recovery system, method and apparatus
JP2017004301A (ja) * 2015-06-11 2017-01-05 キヤノン株式会社 認証サーバーシステム、方法、プログラムおよび記憶媒体
JP6675163B2 (ja) * 2015-07-24 2020-04-01 キヤノン株式会社 権限委譲システム、認可サーバの制御方法、認可サーバおよびプログラム
US10104084B2 (en) * 2015-07-30 2018-10-16 Cisco Technology, Inc. Token scope reduction
JP6677496B2 (ja) * 2015-12-08 2020-04-08 キヤノン株式会社 認証連携システム及び認証連携方法、認可サーバー、アプリケーションサーバー及びプログラム
KR102424055B1 (ko) * 2015-12-08 2022-07-25 한국전자통신연구원 두 개의 ａｐｉ 토큰을 이용한 ａｐｉ 인증 장치 및 방법
US10567381B1 (en) * 2015-12-17 2020-02-18 Amazon Technologies, Inc. Refresh token for credential renewal
JP6720606B2 (ja) * 2016-03-18 2020-07-08 富士ゼロックス株式会社 情報処理システム
CN105792178A (zh) * 2016-04-29 2016-07-20 宇龙计算机通信科技(深圳)有限公司 生成和获取用于删除isd-p域的授权的方法及装置
JP6476402B2 (ja) * 2016-05-20 2019-03-06 システムメトリックス株式会社 認証システム
US10469526B2 (en) 2016-06-06 2019-11-05 Paypal, Inc. Cyberattack prevention system
CN106878002B (zh) * 2016-07-05 2020-04-24 阿里巴巴集团控股有限公司 一种权限撤销方法及装置
US10924479B2 (en) * 2016-07-20 2021-02-16 Aetna Inc. System and methods to establish user profile using multiple channels
US10846389B2 (en) 2016-07-22 2020-11-24 Aetna Inc. Incorporating risk-based decision in standard authentication and authorization systems
US20180082053A1 (en) * 2016-09-21 2018-03-22 Telefonaktiebolaget Lm Ericsson (Publ) Application token through associated container
US10462124B2 (en) 2016-12-30 2019-10-29 Google Llc Authenticated session management across multiple electronic devices using a virtual session manager
US10541992B2 (en) * 2016-12-30 2020-01-21 Google Llc Two-token based authenticated session management
CN106657140B (zh) * 2017-01-18 2020-02-28 北京小米移动软件有限公司 应用授权方法及装置
CN108964885B (zh) * 2017-05-27 2021-03-05 华为技术有限公司 鉴权方法、装置、***和存储介质
JP7047302B2 (ja) * 2017-09-25 2022-04-05 富士フイルムビジネスイノベーション株式会社 情報処理装置及び情報処理プログラム
US10038696B1 (en) * 2017-10-10 2018-07-31 Blackberry Limited System and method for controlling access to enterprise networks
CN110046001B (zh) 2018-01-15 2022-03-25 华为技术有限公司 一种授权撤回的方法及装置
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
US11632360B1 (en) 2018-07-24 2023-04-18 Pure Storage, Inc. Remote access to a storage device
CN110955871B (zh) * 2018-09-26 2022-01-28 北京国双科技有限公司 一种数据获取方法及装置
DE102018219067A1 (de) * 2018-11-08 2020-05-14 Robert Bosch Gmbh Transparenzmechanismus zur lokalen Komposition von personenbezogenen, verteilt gespeicherten Nutzerdaten
US10936191B1 (en) 2018-12-05 2021-03-02 Pure Storage, Inc. Access control for a computing system
FR3093887B1 (fr) * 2019-03-15 2021-05-14 Psa Automobiles Sa Procédé pour délivrer, à un dispositif nomade, une autorisation d’accès à un calculateur connecté d’un véhicule
JP7250596B2 (ja) * 2019-04-02 2023-04-03 キヤノン株式会社 画像処理装置、方法およびプログラム
US11677624B2 (en) * 2019-04-12 2023-06-13 Red Hat, Inc. Configuration of a server in view of a number of clients connected to the server
JP7301668B2 (ja) * 2019-08-07 2023-07-03 キヤノン株式会社 システム、制御方法、プログラム
CN110691087B (zh) * 2019-09-29 2022-03-01 北京搜狐新媒体信息技术有限公司 一种访问控制方法、装置、服务器及存储介质
CN110690972B (zh) * 2019-10-11 2022-02-22 迈普通信技术股份有限公司 令牌认证方法、装置、电子设备及存储介质
CN111143793B (zh) * 2019-12-13 2021-05-28 支付宝(杭州)信息技术有限公司 访问控制方法和访问控制装置
US11411736B2 (en) * 2020-03-03 2022-08-09 Microsoft Technology Licensing, Llc Automatic renewal of a verifiable claim
WO2021237676A1 (zh) * 2020-05-29 2021-12-02 Oppo广东移动通信有限公司 请求处理方法、装置、设备及存储介质
US11770377B1 (en) * 2020-06-29 2023-09-26 Cyral Inc. Non-in line data monitoring and security services
CN112671539B (zh) * 2020-11-23 2022-09-20 苏州浪潮智能科技有限公司 一种处理多请求令牌过期续签的方法、***、介质及设备
CN113076555B (zh) * 2021-03-29 2024-02-06 上海明略人工智能(集团)有限公司 一种基于开放接口通讯的安全认证方法与***
TWI823202B (zh) * 2021-12-03 2023-11-21 中華電信股份有限公司 代理授權系統和代理授權方法
CN115174162B (zh) * 2022-06-17 2023-10-24 青岛海尔科技有限公司 基于OAuth协议的授权方法、装置、***及存储介质

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6734886B1 (en) * 1999-12-21 2004-05-11 Personalpath Systems, Inc. Method of customizing a browsing experience on a world-wide-web site
US20020083183A1 (en) * 2000-11-06 2002-06-27 Sanjay Pujare Conventionally coded application conversion system for streamed delivery and execution
JP4299621B2 (ja) * 2003-09-24 2009-07-22 日本電信電話株式会社 サービス提供方法、サービス提供プログラム、ホスト装置、および、サービス提供装置
DE102008020832B3 (de) 2008-04-25 2009-11-19 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Konzept zur effizienten Verteilung einer Zugangsberechtigungsinformation
US8219802B2 (en) * 2008-05-07 2012-07-10 International Business Machines Corporation System, method and program product for consolidated authentication
US9548859B2 (en) * 2008-12-03 2017-01-17 Google Technology Holdings LLC Ticket-based implementation of content leasing
US8527774B2 (en) * 2009-05-28 2013-09-03 Kaazing Corporation System and methods for providing stateless security management for web applications using non-HTTP communications protocols
EP2257026B1 (en) 2009-05-29 2021-01-13 Alcatel Lucent System and method for accessing private digital content
US8839397B2 (en) * 2010-08-24 2014-09-16 Verizon Patent And Licensing Inc. End point context and trust level determination
CN102394887B (zh) 2011-11-10 2014-07-09 杭州东信北邮信息技术有限公司 基于OAuth协议的开放平台安全认证方法和***
US8800009B1 (en) 2011-12-30 2014-08-05 Google Inc. Virtual machine service access

Also Published As

Publication number Publication date
WO2013175901A1 (en) 2013-11-28
CN104350501B9 (zh) 2017-04-19
CN104350501A (zh) 2015-02-11
US20140230020A1 (en) 2014-08-14
JP2013246655A (ja) 2013-12-09
CN104350501B (zh) 2017-03-01
US9571494B2 (en) 2017-02-14
KR20150013855A (ko) 2015-02-05
KR101640383B1 (ko) 2016-07-18

Similar Documents

Publication Publication Date Title
JP6006533B2 (ja) 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法
KR102390108B1 (ko) 정보 처리 시스템 및 제어 방법
JP6141076B2 (ja) システムおよびその制御方法、アクセス管理サービスシステムおよびその制御方法、並びにプログラム
CN102638454B (zh) 一种面向http身份鉴别协议的插件式单点登录集成方法
JP6066647B2 (ja) デバイス装置、その制御方法、およびそのプログラム
JP6061633B2 (ja) デバイス装置、制御方法、およびそのプログラム。
JP6929181B2 (ja) デバイスと、その制御方法とプログラム
JP5604176B2 (ja) 認証連携装置およびそのプログラム、機器認証装置およびそのプログラム、ならびに、認証連携システム
CN109428947A (zh) 权限转移***及其控制方法和存储介质
JP6141041B2 (ja) 情報処理装置及びプログラム、制御方法
JP2019046059A (ja) 権限委譲システム、制御方法、およびプログラム
JP2017027459A (ja) 権限委譲システム、その制御方法、認可サーバおよびプログラム
JP2007257500A (ja) 被認証装置、被認証プログラム、被認証方法、ＷｅｂブラウザプラグインおよびＷｅｂブラウザブックマークレット
JP6240102B2 (ja) 認証システム、認証鍵管理装置、認証鍵管理方法および認証鍵管理プログラム
KR101803535B1 (ko) 일회용 토큰을 이용한 싱글 사인온 서비스 인증방법
JP5036500B2 (ja) 属性証明書管理方法及び装置
JP2008129673A (ja) ユーザ認証システム、ユーザ認証方法、それに用いるゲートウェイ及びプログラムとその記録媒体
JP2018022501A (ja) 複数のサービスシステムを制御するサーバシステム及び方法
JP6128958B2 (ja) 情報処理サーバーシステム、制御方法、およびプログラム
JP2020053100A (ja) 情報処理システムと、その制御方法とプログラム
KR102497440B1 (ko) Did 기반의 사용자 정보 관리 서비스 제공 방법 및 시스템
JP6053205B2 (ja) 情報流通システム、方法および処理プログラム
JP5860421B2 (ja) 復号方法、復号システム
JP2011009939A (ja) 認証用プログラム、認証要求プログラム、認証システム、クライアント装置、認証方法および認証要求方法
KR20100073884A (ko) Ｉｄ 연계 기반의 고객정보 중개 및 동기화 방법

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150525

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150525

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160719

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160722

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: 20160812

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160909

R151 Written notification of patent or utility model registration

Ref document number: 6006533

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151