JP6937280B2 - 情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラム - Google Patents

情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラム Download PDF

Info

Publication number
JP6937280B2
JP6937280B2 JP2018171240A JP2018171240A JP6937280B2 JP 6937280 B2 JP6937280 B2 JP 6937280B2 JP 2018171240 A JP2018171240 A JP 2018171240A JP 2018171240 A JP2018171240 A JP 2018171240A JP 6937280 B2 JP6937280 B2 JP 6937280B2
Authority
JP
Japan
Prior art keywords
token
client
information processing
processing device
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
JP2018171240A
Other languages
English (en)
Other versions
JP2020042691A (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.)
Toshiba Corp
Original Assignee
Toshiba Corp
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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2018171240A priority Critical patent/JP6937280B2/ja
Priority to US16/282,778 priority patent/US11336449B2/en
Publication of JP2020042691A publication Critical patent/JP2020042691A/ja
Application granted granted Critical
Publication of JP6937280B2 publication Critical patent/JP6937280B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/321Cryptographic 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/3213Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102Entity profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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 digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3263Cryptographic 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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

本発明の実施の形態は、情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラムに関する。
近年、クライアント側でウェブサービスを実現するためのブラウザアプリケーションが注目されている。このようなブラウザアプリケーションを用いたシステムにおいて、クライアントとサーバとの間の認証に、OAuth2.0(RFC 6749)と称される標準プロトコルを用いる事が知られている。OAuth2.0には、インプリシットフロー(Implict Flow)と称される認可フローが定義されている。インプリシットフローは、認可サーバに認可リクエストを送信した応答として、直接アクセストークンを受け取るフローである。
しかし、インプリシットフローを用いたプロトコルでは、サーバ側で発行可能なアクセストークンの形式が持参式トークン(Bearer Token)であり、アクセストークンの漏洩によるセキュリティ低下が問題であった。
特開2016−115260号公報
本発明が解決しようとする課題は、アクセストークンのセキュリティ向上を図ることができる、情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラムを提供することである。
実施形態の情報処理装置は、クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する。情報処理装置は、受信部と、送信部と、発行部と、を備える。受信部は、前記クライアントに対して発行されたnonceと、前記クライアントが生成した第1公開鍵と、前記nonceを含むクライアント情報に対する第1署名と、を含む前記トークン発行要求を前記クライアントから受信する。送信部は、前記トークン発行要求に含まれる前記第1署名の前記第1公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第1識別情報を含むログイン要求を前記クライアントへ送信する。発行部は、前記クライアントを利用するユーザの認証情報および前記第1識別情報を含む認可許諾要求を前記クライアントから受信したときに、前記第1公開鍵を用いて生成した記名式トークンを前記アクセストークンとして発行する。
情報処理システムの模式図。 情報処理のシーケンス図。 情報処理システムの模式図。 情報処理のシーケンス図。 ハードウェア構成図。
以下に添付図面を参照して、情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラムを詳細に説明する。
(第1の実施の形態)
図1は、本実施の形態の情報処理システム1の一例を示す模式図である。
情報処理システム1は、情報処理装置10と、クライアント端末12と、サービス提供装置14と、リソース提供装置16と、を備える。情報処理装置10と、クライアント端末12と、サービス提供装置14と、リソース提供装置16とはネットワーク18を介して通信可能に接続されている。情報処理システム1は、1または複数のクライアント端末12と、1または複数のサービス提供装置14と、1または複数のリソース提供装置16と、1または複数の情報処理装置10と、を備えた構成であればよい。
情報処理装置10は、OAuthにおける認可サーバとして機能する。
クライアント端末12は、ユーザが操作する端末装置である。クライアント端末12は、クライアント端末12上のウェブブラウザ12Bでクライアントスクリプトを実行し、リソース提供装置16で提供されるリソースを利用する。リソースは、例えば、印刷サービスや帳票サービスなどを実行するためのリソースアプリケーションである。
サービス提供装置14は、OAuthにおける、Web上にホストされ、ウェブブラウザ上で実行されるクライアント(Client)である。
リソース提供装置16は、OAuthにおける、ウェブ上にホストされたクライアントプログラムが実装されたリソースサーバ(Resource Server)である。リソース提供装置16は、クライアント端末12からのリソースリクエストに応じて、クライアント端末12へリソースを提供する。
次に、情報処理システム1を構成する各装置の機能的構成を詳細に説明する。
クライアント端末12は、通信部12Aと、ウェブブラウザ12Bと、OS(Operating System)12Eと、を備える。通信部12Aは、ネットワーク18を介して他の装置とデータを通信する。
クライアント端末12では、CPU(Central Processing Unit)がROM(Read Only Memory)や外部メモリなどに記憶されたOS12Eを実行することで、各アプリケーションを制御する。OS12Eは、例えば、リアルタイムOSや、Linux(登録商標)等の汎用OSである。
ウェブブラウザ12Bは、WWW(world wide web)を利用するためのユーザーエージェントである。ウェブブラウザ12Bは、サービス提供ページ12Cおよび認証ページ12Dを、それぞれサービス提供装置、情報処理装置から読み込んで実行する。
サービス提供ページ12Cは、サービス提供装置14から提供されたウェブサイトのページであり、OAuth Clientの実体である。
本実施の形態では、サービス提供ページ12Cは、クライアント端末12毎に、オリジン(Webサイトの提供元を識別するプロトコル、ホスト、ポート番号の組み合わせ。ここではサービス提供装置)ごとに第1公開鍵と第1秘密鍵とのペアを生成する。第1公開鍵と第1秘密鍵とのペアの生成には、公知の方法を用いればよい。例えば、サービス提供ページ12Cは、W3C Web Cryptography APIを用いて、第1公開鍵と第1秘密鍵とのペアを生成する。
また、サービス提供ページ12Cは、トークン発行要求を情報処理装置10へ送信する。トークン発行要求は、OAuth2.0の認可リクエストに相当する。但し、本実施の形態では、トークン発行要求は、記名式トークンの発行要求である。記名式トークンは、PoP(Proof−of−Possession)トークンと称される場合がある。
具体的には、本実施の形態では、トークン発行要求は、クライアント端末12に対して情報処理装置10から発行されたnonce(number used once)と、第1公開鍵と、nonceを含むクライアント情報に対する第1署名と、を含む。また、トークン発行要求は、記名式トークンの発行要求を示す情報を含む。
nonceは、1回のみ用いられる、ランダム生成された数値または文字列である。
サービス提供ページ12Cは、情報処理装置10からnonceを取得することで、nonceを含むトークン発行要求を情報処理装置10へ送信してもよい。また、サービス提供ページ12Cは、nonceの記憶場所を示す情報を情報処理装置10から受信し、該記憶場所へアクセスすることで、nonceを取得してもよい。
サービス提供ページ12Cは、取得したnonceに第1秘密鍵を用いて第1署名を付与する。第1署名は、nonce、あるいは、nonceに第1公開鍵などのクライアント情報を合わせたデータに対する署名である。第1秘密鍵を用いたnonceへの第1署名の付与には、公知の方法を用いればよい。なお、nonce単体ではなく、第1公開鍵などのクライアント情報にnonceを合わせたデータに署名を付与するように構成してもよい。
また、サービス提供ページ12Cは、情報処理装置10への上記トークン発行要求の送信に対する応答として、情報処理装置10からアクセストークン応答情報を受信する。
アクセストークン応答情報は、情報処理装置10で発行されたアクセストークンの特定情報を含む。アクセストークン特定情報は、アクセストークンを一意に特定可能な情報であればよい。特定情報は、例えば、情報処理装置10からクライアント端末12に対して発行されたアクセストークン、該アクセストークンの記憶場所を示す情報、該アクセストークンの識別情報(第3識別情報)、などである。本実施の形態では、特定情報がアクセストークンである場合を一例として説明する。
サービス提供ページ12Cは、情報処理装置10から受信したアクセストークン応答情報に含まれるアクセストークンを、第1公開鍵に対応付けて記憶する。
そして、サービス提供ページ12Cは、受信したアクセストークンを含むリソースリクエストを、リソース提供装置16へ送信する。本実施の形態では、サービス提供ページ12Cは、リソース提供装置16で発行されたnonceと、情報処理装置10から受信したアクセストークンと、を含むリソースリクエストをリソース提供装置16へ送信する。
該アクセストークンがリソース提供装置16で検証され、検証が成功すると、リソース提供装置16からサービス提供ページ12Cへリソースが提供される。
認証ページ12Dは、情報処理装置10が、サービス提供ページ12Cが情報処理装置10へ送信したトークン発行要求の結果、表示されるWebページである。ログイン要求は、具体的には、認証ページ12Dへのリダイレクト要求であり、この認証ページ12DへのリダイレクトURLには、トークン発行要求の第1識別情報が含まれる。第1識別情報の詳細は後述する。
認証ページ12Dは、情報処理装置10からのリダイレクトの結果、ウェブブラウザ12B上に読み込まれ、情報処理装置10へログインするための認証画面を表示する。ユーザは、認証画面を参照しながらクライアント端末12を操作することで、認証情報を入力する。認証情報は、例えば、ログインに用いるユーザIDおよびパスワード、ログイン認証後に払い出されるセッションID、などである。ユーザIDは、ユーザの識別情報である。
そして、認証ページ12Dは、入力された認証情報(ユーザID、パスワード)と、トークン発行要求の第1識別情報と、を含む認可許諾要求を情報処理装置10へ送信する。
次に、情報処理装置10の機能的構成を説明する。
情報処理装置10は、クライアントから受信したトークン発行要求に対する応答として、アクセストークンを発行する。すなわち、情報処理装置10は、OAuth 2.0のインプリシットフローと同様に、受信したトークン発行要求に対する応答として、直接、アクセストークンを該トークン発行要求の送信元のクライアントへ返信する。
なお、クライアントとは、クライアント端末12およびクライアント端末12にインストールされたウェブブラウザ12B上に読み込まれたサービス提供ページ12Cを示す。本実施の形態では、クライアントを、クライアント端末12と称して説明する。
情報処理装置10は、受信部10Aと、送信部10Bと、nonce発行部10Cと、署名検証部10Dと、発行部10Eと、を備える。
受信部10A、送信部10B、nonce発行部10C、署名検証部10D、および発行部10Eは、CPU(Central Processing Unit)などのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。これらの各部は、専用のIC(Integrated Circuit)などのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち1つを実現してもよいし、各部のうち2以上を実現してもよい。
受信部10Aは、他の装置(クライアント端末12、サービス提供装置14、リソース提供装置16)から各種情報を受信する。本実施の形態では、受信部10Aは、クライアント端末12に対して発行したnonceと、クライアント端末12が生成した第1公開鍵と、nonce(あるいは、nonceに第1公開鍵などクライアント情報を合わせたデータ)に対する第1署名と、を含むトークン発行要求を、クライアント端末12から受信する。上述したように、本実施の形態では、このトークン発行要求は、記名式トークンの発行要求である。
nonce発行部10Cは、クライアント端末12に対してnonceを発行する。nonce発行部10Cは、乱数生成器などを用いて乱数を生成し、生成した乱数を、クライアント端末12に対するnonceとして発行する。
送信部10Bは、他の装置(クライアント端末12、サービス提供装置14、リソース提供装置16)へ各種情報を送信する。本実施の形態では、送信部10Bは、nonceを示すnonce情報を、サービス提供ページ12Cへ送信する。nonce情報は、nonce、nonceの識別情報、または、nonceの記憶場所を示す情報である。本実施の形態では、nonce情報は、nonce発行部10Cで発行したnonceである場合を一例として説明する。
署名検証部10Dは、サービス提供ページ12Cから受信したトークン発行要求に含まれる第1署名を、該トークン発行要求に含まれる第1公開鍵を用いて検証する。すなわち、署名検証部10Dは、第1公開鍵に対応する秘密鍵で署名されているか否か、署名対象データが換算されていないか否かを、第1公開鍵を用いて検証する。第1署名の検証には、公知の方法を用いればよい。
送信部10Bは、サービス提供ページ12Cから受信したトークン発行要求に含まれる第1署名の第1公開鍵を用いた検証結果が成功を示す場合、ログイン要求を認証ページ12Dへ送信する。検証結果が成功を示す、とは、署名検証部10Dによる検証によって、第1署名の対象データが非改竄であり、かつ、第1公開鍵に対応する秘密鍵で署名されていると検証されたことを示す。
ログイン要求は、クライアント端末12を操作するユーザに対する、明示的な認可操作を促す要求である。ログイン要求は、上述したように、トークン発行要求の第1識別情報を含む。具体的には、ログイン要求は、リダイレクト応答(例えば、302 Found応答)であり、リダイレクト先を示すLocationヘッダ値(URL)に、第1識別情報が含まれる。なお、便宜上「ログイン要求」としているが、実質は認可要求であり、認証画面に表示されるのは、サービス提供装置(クライアント)からリソース提供装置上のリソースへのアクセス認可を促す画面である。リダイレクトされた時点で、すでにログイン済みであれば、ログインID、パスワードを入力するログインインタフェースを表示する必要はなく、単に、認可を求める画面が表示される。
第1識別情報は、サービス提供ページ12Cから受信した、第1公開鍵、第1署名、およびnonceを含むトークン発行要求と、認証ページ12Dから受信した認証情報(ユーザID、パスワード)(あるいは、すでにログイン済みであれば、ログインセッション情報)と、を対応付けるための識別情報であればよい。例えば、第1識別情報は、nonce発行部10Cがクライアント端末12に対して発行したnonce、該nonceを識別する第2識別情報、または、サービス提供ページ12Cから受信したトークン発行要求のセッション識別情報、などである。
発行部10Eは、クライアントを利用するユーザの認証情報および第1識別情報を含む認可許諾要求をクライアントから受信したときに、第1公開鍵を用いて生成した記名式トークンを、該クライアントに対するアクセストークンとして発行する。
すなわち、発行部10Eは、クライアント端末12で生成された第1公開鍵を用いて記名式トークンを生成することで、クライアント端末12でのみ使用可能なアクセストークンを発行する。
そして、発行部10Eは、発行したアクセストークンに、情報処理装置10による発行を証明するための証明書を用いて、生成した記名式トークンに第2署名を付与し、第2署名付きのアクセストークンを発行する。なお、この証明書には、情報処理装置10で予め生成した第2公開鍵を用いればよい。
情報処理装置10は、第2公開鍵と第2秘密鍵とのペアを予め生成すればよい。これらの第2公開鍵と第2秘密鍵とのペアの生成には、公知の方法を用いればよい。
なお、第2署名の付与時に、発行部10Eは、生成した記名式トークンのハッシュ値に第2署名を付与することで、第2署名付きのアクセストークンを発行してもよい。
発行部10Eは、クライアント端末12用に発行したアクセストークンと、クライアント端末12の識別に用いるための第1公開鍵と、クライアント端末12から受信した認証情報(ログインIDとパスワード、あるいは、ログインの結果払い出されるセッションID)と、を対応付けて記憶する。そして、発行部10Eは、送信部10Bを介してサービス提供ページ12Cへ、クライアント端末12用に発行したアクセストークンの特定情報を含むアクセストークン応答情報を、クライアント端末12へ送信する。
次に、リソース提供装置16の機能的構成を説明する。
リソース提供装置16は、通信部16Aと、nonce発行部16Bと、アクセストークン検証部16Cと、応答部16Dと、を備える。
通信部16A、nonce発行部16B、アクセストークン検証部16C、および応答部16Dは、CPUなどのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。これらの各部は、専用のICなどのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち1つを実現してもよいし、各部のうち2以上を実現してもよい。
通信部16Aは、ネットワーク18を介して他の装置(クライアント端末12、サービス提供装置14、リソース提供装置16、情報処理装置10)と通信する。
nonce発行部16Bは、nonceを発行する。nonce発行部16Bは、情報処理装置10のnonce発行部10Cと同様にしてnonceを発行する。但し、nonce発行部16Bは、情報処理装置10と連動することなく、一意の乱数を発行し、nonceとして用いる。
アクセストークン検証部16Cは、クライアント端末12から通信部16Aを介して受信したリソースリクエストに含まれるアクセストークンを検証する。例えば、アクセストークン検証部16Cは、nonce発行部16Bで発行したnonceと、情報処理装置10がクライアント端末12用に発行したアクセストークンと、を含むリソースリクエストを、通信部16Aを介して受信する。そして、アクセストークン検証部16Cは、該リソースリクエストに含まれるアクセストークンが、該アクセストークンの送信元のクライアント端末12に発行されたものであるか否かを、情報処理装置10に問い合わせる(具体的には、トークン検証エンドポイントに、アクセストークンを送信し、有効か否かを判定する)。情報処理装置10に、該アクセストークンと該クライアント端末12の認証情報または第1公開鍵が対応付けて記憶されている場合、かつ、トークンの有効期限が切れておらず、トークンがリボーク(無効化)されていない場合、リソース提供装置16は、該アクセストークンがクライアント端末12に発行されたものであるし、検証成功と判断する。
アクセストークン検証部16Cが検証成功と判断すると、応答部16Dは、サービス提供ページ12Cへリソースを提供する。
次に、情報処理システム1で実行される情報処理の手順の一例を説明する。
図2は、情報処理システム1で実行される情報処理の手順の一例を示す、シーケンス図である。
まず、情報処理装置10が、第2公開鍵と第2秘密鍵とのペアを生成する(ステップS100)。一方、クライアント端末12のサービス提供ページ12Cは、第1公開鍵と第1秘密鍵とのペアを生成する(ステップS102)。
次に、サービス提供ページ12Cは、トークン発行要求を情報処理装置10へ送信する(ステップS104)。本実施の形態では、サービス提供ページ12Cは、記名式トークンの発行要求を示す、トークン発行要求を情報処理装置10へ送信する。ステップS104のトークン発行要求は、例えば、“POST /authorizeresponse_type=token&client_id=x&token_type=pop&redirect_uri=https://rp.example.com/cb”と表される。
ステップS104で、サービス提供ページ12Cからトークン発行要求を受信した情報処理装置10のnonce発行部10Cは、クライアント端末12に対するnonceを発行する(ステップS106)。
そして、nonce発行部10Cは、ステップS106で発行したnonceを示すnonce情報を、送信部10Bを介してサービス提供ページ12Cへ送信する(ステップS108)。具体的には、nonce発行部10Cは、応答ヘッダにnonceを含む“401 Unauthorizednonce”応答を、サービス提供ページ12Cへ送信する。
nonce情報は、ステップS106で発行したnonceを示す情報であればよい。具体的には、nonce情報は、nonce、nonceの識別情報、またはnonceの記憶場所を示す情報である。本実施の形態では、nonce情報が、nonceである場合を一例として説明する。
クライアント端末12のサービス提供ページ12Cは、情報処理装置10から受信したnonceに第1秘密鍵を用いて第1署名を付与する(ステップS110)。なお、署名は、nonceのみを対象にする必要はなく、第1公開鍵などクライアント情報を含めたデータを署名対象としてもよい。
そして、クライアント端末12のサービス提供ページ12Cは、第1公開鍵と、ステップS108で受信したnonceと、ステップS110で付与した第1署名と、を含むトークン発行要求を、情報処理装置10へ送信する(ステップS112)。
ステップS112で送信するトークン発行要求は、例えば、“POST /authorize?response_type=token&client_id=x&token_type=pop&alg=RS256&key=KRpub&redirect_uri=https://rp.example.com/cb”と表される。RS256は、第1署名を示す。KRpubは、第1公開鍵を示す。popは、記名式トークンの発行要求を示す。
情報処理装置10の署名検証部10Dは、ステップS112でクライアント端末12の認証ページ12Dから受信したトークン発行要求に含まれる第1署名を、該トークン発行要求に含まれる第1公開鍵を用いて検証する(ステップS114)。ここでは、検証成功したとして、説明を続ける。
そして、情報処理装置10の送信部10Bは、第1識別情報を含むログイン要求を、クライアント端末12の認証ページ12Dへ送信する(ステップS116)。ステップS116では、送信部10Bは、ステップS106で発行したnonce、該nonceの第2識別情報、ステップS104およびステップS112で受信したトーク発行要求の少なくとも一方の通信セッション識別情報、の何れかを、第1識別情報として用いる。
ログイン要求は、例えば、“302 Found”応答、すなわち、リダイレクト応答として表される。Locationヘッダに、認可画面のURLが含まれる。
ログイン要求を受信したクライアント端末12の認証ページ12Dは、情報処理装置10へログインするための認証画面を表示する(ステップS118)。クライアント端末12を操作するユーザは、認証画面を参照しながらクライアント端末12を操作することで、認証情報(ユーザID、パスワード)を入力する。なお、前述の通り、既にログインが行われている場合、認証情報の入力はスキップされ、サービス提供装置からリソース提供装置上のリソースへのアクセス認可を促すインタフェースのみが表示される(これはOAuthの認可画面における一般的な実装である)。
そして、クライアント端末12の認証ページ12Dは、入力された認証情報(ユーザID、パスワード、あるいは、認証後に発行されるセッションID)と、ステップS116で受信したログイン要求に含まれる第1識別情報と、を含む認可許諾要求を、情報処理装置10へ送信する(ステップS120)。
認可許諾要求は、例えば、“POST /grant”と表される。
情報処理装置10の発行部10Eは、認可許諾要求を受信すると、認可許諾要求に含まれる認証情報が、情報処理装置10に予め登録されているか否かを判別することで、クライアント端末12を操作するユーザの情報処理装置10へのログインを許可するか否かを判断する。ここでは、許可すると判断したと想定し、説明を続ける。
そして、情報処理装置10の発行部10Eは、ステップS112で受信したトークン発行要求に含まれる第1公開鍵を用いて記名式トークンを生成することで、クライアント端末12に対するアクセストークンを発行する(ステップS122)。
次に、発行部10Eは、ステップS122で発行したアクセストークンに、ステップS100で生成した第2秘密鍵を用いて第2署名を付与する(ステップS124)。
そして、発行部10Eは、クライアント端末12用に発行したアクセストークンと、クライアント端末12の識別に用いるための第1公開鍵と、クライアント端末12から受信した認証情報(ログインIDとパスワード)と、を対応付けて記憶する(ステップS126)。
情報処理装置10の送信部10Bは、ステップS122およびステップS124で発行した、第2署名の付与されたアクセストークンを含むアクセストークン応答情報を、クライアント端末12へ送信する(ステップS128)。
アクセストークン応答情報は、例えば、“302 Found”リダイレクト応答であり、Locationヘッダの値は、https://rp.example.com/cb#access_token=PoPTokenと表される。rp.example.comは、サービス提供装置14のホストを示す。PoPTokenは、第2署名の付与されたアクセストークンを示す。
クライアント端末12のサービス提供ページ12Cは、ステップS128で受信したアクセストークン応答情報に含まれる、アクセストークンの特定情報によって特定されるアクセストークンと、第1公開鍵と、を対応付けて記憶する(ステップS130)。ステップS130で記憶するアクセストークンは、ステップS122の処理によって情報処理装置10によって発行され、ステップS124の処理によって第2署名の付与されたアクセストークンである。
次に、クライアント端末12のサービス提供ページ12Cは、ステップS130で記憶した、第2署名付きのアクセストークンを含むリソースリクエストを、リソース提供装置16へ送信する(ステップS132)。
ステップS132のリソースリクエストは、例えば、“GET /some−resource”と表される。
ステップS132でリソースリクエストを受信したリソース提供装置16のnonce発行部16Bは、クライアント端末12用のnonceを発行する(ステップS134)。そして、nonce発行部16Bは、ステップS134で発行したnonceを示すnonce情報を、クライアント端末12へ送信する(ステップS136)。ステップS136のnonce情報は、例えば、“401 Unauthorized”エラー応答のヘッダに設定される。本実施の形態では、nonce発行部16Bは、nonceをクライアント端末12へ送信する場合を一例として説明する。
ステップS136でnonceを受信したクライアント端末12のサービス提供ページ12Cは、ステップS130で記憶した、第2署名付きのアクセストークンと、ステップS136で受信したnonceと、を含むリソースリクエストを、リソース提供装置16へ送信する(ステップS138)。
ステップS138のリソースリクエストは、例えば、“GET /some−resource”となる。署名付きのアクセストークンとnonceは、Authorizationヘッダに指定され、例えば、”Authorization: Jpop at=“JWS”,s=“nonce””と表される。JWSは、署名付きアクセストークンを示す。
リソース提供装置16のアクセストークン検証部16Cは、ステップS138で受信したリソースリクエストに含まれる、第2署名付きのアクセストークン検証する(ステップS140、ステップS142)。このとき、アクセストークン検証部16Cは、該第2署名によって証明される情報処理装置10が発行したアクセストークンであるか否かを、情報処理装置10に問い合わせることで、該アクセストークンを検証する。ここでは、検証成功と判断したものと想定し、説明を続ける。
次に、リソース提供装置16の応答部16Dは、サービス提供ページ12Cへリソースを提供する(ステップS144)。例えば、応答部16Dは、“200 OK”をサービス提供ページ12Cへ送信する。
以上説明したように、本実施の形態の情報処理装置10は、クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する。情報処理装置10は、受信部10Aと、送信部10Bと、発行部10Eと、を備える。受信部10Aは、クライアントに対して発行されたnonceと、クライアントが生成した第1公開鍵と、nonceを含むクライアント情報に対する第1署名と、を含むトークン発行要求をクライアントから受信する。送信部10Bは、トークン発行要求に含まれる第1署名の第1公開鍵を用いた検証結果が成功を示す場合、トークン発行要求の第1識別情報を含むログイン要求を前記クライアントへ送信する。発行部10Eは、クライアントを利用するユーザの認証情報および第1識別情報を含む認可許諾要求をクライアントから受信したときに、第1公開鍵を用いて生成した記名式トークンをアクセストークンとして発行する。
このように、本実施の形態の情報処理装置10は、クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する。このため、情報処理装置10は、OAuth2.0で定義されているインプリシットフローと称されるフローに沿った認可フローを実行する。但し、情報処理装置10では、クライアントの認証情報および第1識別情報を含む認可許諾要求をクライアントから受信したときに、クライアントが生成した第1公開鍵を用いて記名式トークンを生成し、該記名式トークンをアクセストークンとして発行する。
このため、本実施の形態の情報処理装置10は、クライアントでのみ利用可能な記名式トークンを生成することで、セキュリティの高いアクセストークンを発行することができる。
従って、本実施の形態の情報処理装置10は、アクセストークンのセキュリティ向上を図ることができる。
また、本実施の形態の情報処理装置10は、クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する。すなわち、情報処理装置10は、OAuth2.0で定義されているインプリシットフローと称されるフローに沿った認可フローを実行する。このため、情報処理装置10は、シンプルな通信方式で、クライアント端末12に対してリソースへアクセスするためのアクセストークンを発行することができる。
(第2の実施の形態)
本実施の形態では、リソース提供装置がアクセストークンの生成およびアクセストークへの署名の付与の少なくとも一方を行う場合を説明する。
図3は、本実施の形態の情報処理システム1Aの一例を示す模式図である。なお、上記実施の形態と同じ機能および構成については、同じ符号を付与し、詳細な説明を省略する。
情報処理システム1Aは、情報処理装置11と、クライアント端末12と、サービス提供装置14と、リソース提供装置17と、を備える。クライアント端末12およびサービス提供装置14は、第1の実施の形態と同様である。情報処理装置11と、クライアント端末12と、サービス提供装置14と、リソース提供装置17と、はネットワーク18を介して通信可能に接続されている。情報処理システム1Aは、1または複数のクライアント端末12と、1または複数のサービス提供装置14と、1または複数のリソース提供装置17と、1または複数の情報処理装置11と、を備えた構成であればよい。
情報処理装置11は、第1の実施の形態の情報処理装置10と同様に、OAuthを実現するためのサーバであり、認可サーバとして機能する。情報処理装置11は、第1の実施の形態の情報処理装置10と同様に、クライアントから受信したトークン発行要求に対する応答として、アクセストークンを発行する。すなわち、情報処理装置11は、OAuth 2.0のインプリシットフローと同様に、受信したトークン発行要求に対する応答として、直接、アクセストークンを該トークン発行要求の送信元のクライアントへ返信する。
情報処理装置11は、受信部10Aと、送信部10Bと、nonce発行部10Cと、署名検証部10Dと、アクセス検証部11Eと、発行部11Fと、を備える。受信部10A、送信部10B、nonce発行部10C、および署名検証部10Dは、第1の実施の形態と同様である。
アクセス検証部11Eは、クライアント端末12によるリソース提供要求対象のリソース提供装置17の第3識別情報を含むトークン発行要求を受信したときに、トークン発行要求の送信元のクライアントが第3識別情報によって識別されるリソース提供装置17へのアクセス権を有するか否かを検証する。
詳細には、本実施の形態では、受信部10Aは、クライアント端末12で生成された第1公開鍵と、クライアント端末12で付与された第1署名と、情報処理装置11がクライアント端末12に対して発行したnonceと、第3識別情報と、を含むトークン発行要求を受信する。
第3識別情報は、クライアント端末12によるリソース提供要求対象のリソース提供装置17の識別情報である。言い換えると、第3識別情報は、クライアント端末12がリソース提供を要求する、リソース提供装置17の識別情報である。
アクセス検証部11Eは、情報処理システム1Aに含まれるリソース提供装置17の各々ごとに、アクセスを許可するクライアント端末12の識別情報を予め記憶すればよい。クライアント端末12の識別情報には、例えば、クライアント端末12で生成された第1公開鍵を用いればよい。すなわち、アクセス検証部11Eは、リソース提供装置17の第3識別情報と、該第3識別情報によって識別されるリソース提供装置17で許可するクライアント端末12で生成した第1公開鍵と、を対応付けて予め記憶する。そして、アクセス検証部11Eは、受信したトークン発行要求に含まれる第3識別情報に対応付けて、該トークン発行要求に含まれる第1公開鍵が記憶されている場合に、アクセス権を有すると検証すればよい。
発行部11Fは、アクセス検証部11Eがアクセス権を有すると検証した場合、第3識別情報によって識別されるリソース提供装置17で利用可能なアクセストークンを発行する。
なお、発行部11Fは、リソース提供装置17にアクセストークンの発行要求を依頼してもよい。本実施の形態では、リソース提供装置17が、アクセストークンの発行および署名付与を行う場合を説明する。
例えば、発行部11Fは、アクセストークン発行時に、クライアント端末12から受信したトークン発行要求に含まれる第3識別情報によって識別されるリソース提供装置17へ、トークン発行要求の送信元のクライアント(クライアント端末12)からのアクセス許可要求を送信する。アクセス許可要求を受信したリソース提供装置17は、該クライアント端末12へのアクセスを許可すればよい。但し、この段階では、リソース提供装置17は、該クライアント端末12へのリソース提供はまだ許可していない状態である。
そして、発行部11Fは、アクセス検証部11Eがアクセス権を有すると検証した場合、クライアント端末12から受信したトークン発行要求に含まれる第3識別情報によって識別されるリソース提供装置17へ、該クライアント端末12で生成した第1公開鍵を用いた記名式トークンの生成を依頼する。例えば、発行部11Fは、クライアント端末12から受信したトークン発行要求に含まれる第1公開鍵を含むアクセストークン生成要求を、リソース提供装置17へ送信する。
また、発行部11Fは、クライアント端末12から受信したトークン発行要求に含まれる第3識別情報によって識別されるリソース提供装置17へ、該リソース提供装置17による発行を証明するための証明書を用いた、記名式トークンへの第3署名の付与を要求する。例えば、発行部11Fは、リソース提供装置17へ、署名付与要求を送信する。
そして、発行部11Fは、リソース提供装置17から第3署名の付与された記名式トークン(アクセストークン)を受信することで、アクセストークンを発行してもよい。
なお、発行部11Fは、アクセストークンの生成を実行し、署名の付与のみ、リソース提供装置17へ依頼してもよい。
次に、リソース提供装置17の機能について説明する。
リソース提供装置17は、通信部16Aと、nonce発行部16Bと、アクセストークン検証部16Cと、応答部16Dと、アクセス許可部17Eと、生成部17Fと、署名付与部17Gと、を備える。通信部16A、nonce発行部16B、アクセストークン検証部16C、および応答部16Dは、第1の実施の形態のリソース提供装置16と同様である。
アクセス許可部17Eは、情報処理装置11からアクセス許可要求を受信すると、該アクセス許可要求に含まれるクライアント端末12の識別情報を、アクセス許可対象のクライアントの識別情報として記憶する。クライアント端末12の識別情報には、例えば、クライアント端末12を操作するユーザの認証情報(ユーザID、パスワード)、クライアント端末12を一意に識別する識別情報、クライアント端末12で生成した第1公開鍵、などを用いればよい。
この記憶処理により、アクセス許可部17Eは、該クライアント端末12からのアクセスを許可する。なお、このアクセス許可は、上述したように、クライアント端末12へのリソース提供を許可した状態ではなく、単に、アクセスを許可することを意味する。
生成部17Fは、クライアント端末12の第1公開鍵を含むアクセストークン生成要求を情報処理装置11から受信すると、該第1公開鍵を用いて、該クライアント端末12用の記名式トークン(アクセストークン)を生成する。
署名付与部17Gは、署名付与要求を情報処理装置11から受信すると、生成部17Fで生成した記名式トークン(アクセストークン)に、リソース提供装置17による発行を証明するための証明書を用いて、第3署名を付与する。この証明書には、リソース提供装置17で予め生成した第3秘密鍵を用いればよい。
なお、リソース提供装置17は、第3公開鍵と第3秘密鍵とのペアを予め生成すればよい。これらの第3公開鍵と第3秘密鍵とのペアの生成には、公知の方法を用いればよい。そして、署名付与部17Gは、予め生成した第3秘密鍵を用いて、アクセストークンに第3署名を付与すればよい。
なお、署名付与部17Gは、生成部17Fで生成した記名式トークンのハッシュ値に第3署名を付与することで、第3署名付きのアクセストークンを生成してもよい。
次に、情報処理システム1Aで実行される情報処理の手順の一例を説明する。
図4は、情報処理システム1Aで実行される情報処理の手順の一例を示す、シーケンス図である。
まず、リソース提供装置17が、第3公開鍵と第3秘密鍵とのペアを生成する(ステップS200)。一方、クライアント端末12のサービス提供ページ12Cは、第1公開鍵と第1秘密鍵とのペアを生成する(ステップS202)。
次に、クライアント端末12のサービス提供ページ12Cは、トークン発行要求を情報処理装置11へ送信する(ステップS204)。本実施の形態では、サービス提供ページ12Cは、記名式トークンの発行要求を示す、トークン発行要求を情報処理装置11へ送信する。
ステップS204で、サービス提供ページ12Cからトークン発行要求を受信した情報処理装置11のnonce発行部10Cは、クライアント端末12に対するnonceを発行する(ステップS206)。そして、nonce発行部10Cは、ステップS206で発行したnonceを示すnonce情報を、送信部10Bを介してサービス提供ページ12Cへ送信する(ステップS208)。nonce情報は、ステップS206で発行したnonceを示す情報であればよい。本実施の形態では、nonce情報が、nonceである場合を一例として説明する。
クライアント端末12のサービス提供ページ12Cは、情報処理装置11から受信したnonceに第1秘密鍵を用いて第1署名を付与する(ステップS210)。
ステップS202〜ステップS210の処理は、上記実施の形態のステップS102〜ステップS110と同様である(図2参照)。
そして、クライアント端末12のサービス提供ページ12Cは、第1公開鍵と、ステップS208で受信したnonceと、ステップS210で付与した第1署名と、を含むトークン発行要求と、クライアント端末12がリソースの提供を要求する対象のリソース提供装置17の第3識別情報と、情報処理装置11へ送信する(ステップS212)。
すなわち、本実施の形態では、サービス提供ページ12Cは、第3識別情報を更に含むトークン発行要求を情報処理装置10へ送信する点が、上記実施の形態のステップS112の処理と異なる(図2参照)。
なお、クライアント端末12のサービス提供ページ12Cは、情報処理システム1Aに接続された複数のリソース提供装置17の一覧を示す情報を表示する。クライアント端末12を操作するユーザは、クライアント端末12を操作することで、リソース提供を要求する対象のリソース提供装置17を選択する。この選択操作により、サービス提供ページ12Cは、リソースの提供を要求する対象のリソース提供装置17の第3識別情報を受付ける。そして、サービス提供ページ12Cは、該第3識別情報を含むトークン発行要求を、情報処理装置11へ送信すればよい。
情報処理装置11の署名検証部10Dは、ステップS212でクライアント端末12の認証ページ12Dから受信したトークン発行要求に含まれる第1署名を、該トークン発行要求に含まれる第1公開鍵を用いて検証する(ステップS214)。ステップS214の処理は、上記実施の形態のステップS114(図2参照)と同様である。ここでは、検証成功したとして、説明を続ける。
そして、情報処理装置11のアクセス検証部11Eは、ステップS212のトークン発行要求の送信元のクライアント端末12が第3識別情報によって識別されるリソース提供装置17へのアクセス権を有するか否かを検証する(ステップS216)。ここでは、アクセス権を有すると検証したと想定し、説明を続ける。
アクセス権を有すると検証すると、情報処理装置11の送信部10Bは、第1識別情報を含むログイン要求を、クライアント端末12の認証ページ12Dへ送信する(ステップS218)。ステップS218では、送信部10Bは、ステップS206で発行したnonce、該nonceの第2識別情報、ステップS204およびステップS212で受信したトーク発行要求の少なくとも一方の通信セッション識別情報、の何れかを、第1識別情報として用いる。
ログイン要求を受信したクライアント端末12の認証ページ12Dは、情報処理装置11へログインするための認証画面を表示する(ステップS220)。クライアント端末12を操作するユーザは、認証画面を参照しながらクライアント端末12を操作することで、認証情報(ユーザID、パスワード)を入力する。
そして、クライアント端末12の認証ページ12Dは、入力された認証情報(ユーザID、パスワード)と、ステップS218で受信したログイン要求に含まれる第1識別情報と、を含む認可許諾要求を、情報処理装置11へ送信する(ステップS222)。
ステップS218〜ステップS222の処理は、上記実施の形態のステップS116〜ステップS120と同様である(図2参照)。
情報処理装置11の発行部11Fは、ステップS212でクライアント端末12から受信したトークン発行要求に含まれる第1公開鍵を含むアクセストークン生成要求と、署名付与要求と、をリソース提供装置17へ送信する(ステップS224)。このとき、情報処理装置11からリソース提供装置17への通信は、特にリソース提供装置がホームネットワークなどのプライベートネットワーク上のデバイスであることを想定した場合、ファイアウォールなどの影響で普通にはアクセスできない場合が多い。このため、リソース提供装置17は、WebSocket等の常時接続通信プロトコルを用いて、情報処理装置11との間に通信チャネルをあらかじめ(電源ONをトリガとして常時)構築しておき、このWebSocket接続を介して、アクセストークン生成要求を行うように構成してもよい。あるいは、トークン発行要求(ステップS204)前の段階で、Webブラウザに読み込まれたサービス提供ページ12C(OAuthクライアント)が、いったんアクセス対象のリソース提供装置17にアクセスを試行し、この時点ではアクセストークンを持っていないので、リソース提供装置17が、情報処理装置の認可エンドポイント(/authorize)にリダイレクトするように構成し、上記アクセス試行をトリガとして、WebSocket接続を構築し、アクセストークン生成要求を受信するように構成してもよい。
リソース提供装置17の生成部17Fは、ステップS224で受信したアクセストークン生成要求に含まれる第1公開鍵を用いて、クライアント端末12用の記名式トークン(アクセストークン)を生成する(ステップS226)。
そして、リソース提供装置17の署名付与部17Gは、ステップS226で生成した記名式トークン(アクセストークン)に、ステップS200で生成した第3秘密鍵を用いて第3署名を付与する。
そして、署名付与部17Gは、生成したアクセストークンと、ステップS224で受信したアクセストークン生成要求に含まれる第1公開鍵と、を対応付けて記憶する(ステップS230)。
そして、リソース提供装置17の通信部16Aは、ステップS226およびステップS228で生成した、第3署名の付与されたアクセストークンを、情報処理装置11へ送信する(ステップS231)。情報処理装置11の発行部11Fは、リソース提供装置17から第3署名の付与されたアクセストークンを受信することで、アクセストークンを発行する(ステップS232)。
なお、上述したように、情報処理装置11の発行部11Fが、記名式トークンを生成することでアクセストークンを発行してもよい。そして、第3署名の付与を、リソース提供装置17へ依頼してもよい。
そして、情報処理装置11の送信部10Bは、ステップS232で受信した、第3署名の付与されたアクセストークンを含むアクセストークン応答情報を、クライアント端末12へ送信する(ステップS234)。
クライアント端末12のサービス提供ページ12Cは、ステップS234で受信したアクセストークン応答情報に含まれる、アクセストークンと、第1公開鍵と、を対応付けて記憶する(ステップS236)。ステップS236で記憶するアクセストークンは、情報処理装置11またはリソース提供装置17によって生成され、リソース提供装置17によって第3署名の付与された、アクセストークンである。
次に、クライアント端末12のサービス提供ページ12Cは、ステップS236で記憶した、第3署名付きのアクセストークンを含むリソースリクエストを、上記第3識別情報によって識別されるリソース提供装置17へ送信する(ステップS238)。
ステップS238でリソースリクエストを受信したリソース提供装置17のnonce発行部16Bは、クライアント端末12用のnonceを発行する(ステップS240)。そして、nonce発行部16Bは、ステップS240で発行したnonceを示すnonce情報を、クライアント端末12へ送信する(ステップS242)。本実施の形態では、nonce発行部16Bは、nonceをクライアント端末12へ送信する場合を一例として説明する。
ステップS242でnonceを受信したクライアント端末12のサービス提供ページ12Cは、ステップS236で記憶した、第3署名付きのアクセストークンと、ステップS242で受信したnonceと、を含むリソースリクエストを、上記第3識別情報によって識別されるリソース提供装置17へ送信する(ステップS244)。
ステップS234〜ステップS244の処理は、上記実施の形態のステップS128〜ステップS138と同様である(図2参照)。
リソース提供装置17のアクセストークン検証部16Cは、ステップS244で受信したリソースリクエストに含まれる、第3署名付きのアクセストークン検証する(ステップS246)。このとき、アクセストークン検証部16Cは、該第3署名を付与されたアクセストークンがステップS230の処理によって記憶されているか否かを判別することで、検証処理を行う。すなわち、本実施の形態では、アクセストークン検証部16Cは、情報処理装置11へ問い合わせることなく、アクセストークンを検証する。ここでは検証成功したものと想定し、説明を続ける。
そして、リソース提供装置17の応答部16Dは、クライアント端末12のサービス提供ページ12Cへリソースを提供する(ステップS248)。
以上説明したように、本実施の形態の情報処理装置11は、リソース提供要求対象のリソース提供装置17の第3識別情報を更に含むトークン発行要求を受信したときに、該第3識別情報によって識別されるリソース提供装置17で利用可能なアクセストークンを発行する。すなわち、情報処理装置11は、該トークン発行要求元のクライアント端末12でのみ利用可能な記名式トークンであり、且つ、該クライアント端末12がリソース提供を要求する対象のリソース提供装置17でのみ利用可能な、アクセストークンを発行する。
このため、本実施の形態の情報処理装置11は、上記実施の形態の効果に加えて、アクセストークンの用途を更に限定することができ、アクセストークンのセキュリティの更なる向上を図ることができる。
また、本実施の形態の情報処理装置11では、トークン発行要求に含まれる第3識別情報によって識別されるリソース提供装置17へ、該トークン発行要求の送信元のクライアント端末12からのアクセス許可要求を送信する。そして、リソース提供装置17では、アクセス許可要求に応じて、該アクセス許可要求に示されるクライアント端末12からのアクセスを許可する。このため、情報処理装置11は、該クライアント端末12からのアクセスを選択的に許可するようにリソース提供装置17を制御することができる。
このため、本実施の形態の情報処理装置11は、上記効果に加えて、更なるセキュリティ向上を図ることができる。
また、本実施の形態では、クライアント端末12がリソース提供を要求する対象のリソース提供装置17が、アクセストークンに第3署名を付与する。このため、本実施の形態でクライアント端末12に対して発行されるアクセストークンは、リソース提供装置17によって第3署名の付与されたアクセストークンとなる。
すなわち、本実施の形態では、リソース提供装置17は、クライアント端末12から受信したリソースリクエストに含まれるアクセストークンの検証の度に、情報処理装置11へ問合せを行う必要がない。また、情報処理装置11は、リソース提供装置17からのアクセストークンの検証に関する問い合わせを受信することがない。このため、本実施の形態の情報処理システム1Aでは、上記効果に加えて、情報処理装置11およびリソース提供装置17の双方の負荷低減を図ることができる。
また、本実施の形態では、リソース提供装置17がアクセストークンを管理する。このため、情報処理装置11は、アクセストークンの管理負荷の低減や、運用および管理コストの低減を図ることができる。
(ハードウェア構成)
図5は、上記実施の形態の情報処理装置10、情報処理装置11、クライアント端末12、サービス提供装置14、リソース提供装置16、およびリソース提供装置17の主要部のハードウェア構成の例を示す図である。上記実施の形態の情報処理装置10、情報処理装置11、クライアント端末12、サービス提供装置14、リソース提供装置16、およびリソース提供装置17は、制御装置401、主記憶装置402、補助記憶装置403、表示装置404、入力装置405及び通信装置406を備える。制御装置401、主記憶装置402、補助記憶装置403、表示装置404、入力装置405及び通信装置406は、バス410を介して接続されている。
制御装置401は補助記憶装置403から主記憶装置402に読み出されたプログラムを実行する。制御装置401は、例えばCPU(Central Processing Unit)等の汎用のプロセッサである。主記憶装置402はROM(Read Only Memory)、及び、RAM(Random Access Memory)等のメモリである。補助記憶装置403はメモリカード、及び、HDD(Hard Disk Drive)等である。
表示装置404は情報を表示する。表示装置404は、例えば液晶ディスプレイである。入力装置405は、情報の入力を受け付ける。入力装置405は、例えばハードウェアキー、キーボード及びマウス等である。なお表示装置404及び入力装置405は、表示機能と入力機能とを兼ねる液晶タッチパネル等でもよい。通信装置406は他の装置と通信する。
上記実施の形態の情報処理装置10、情報処理装置11、クライアント端末12、サービス提供装置14、リソース提供装置16、およびリソース提供装置17で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでCD−ROM、メモリカード、CD−R、及び、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記憶媒体に記憶されてコンピュータ・プログラム・プロダクトとして提供される。
また、上記実施の形態の情報処理装置10、情報処理装置11、クライアント端末12、サービス提供装置14、リソース提供装置16、およびリソース提供装置17で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、該ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上記実施の形態の情報処理装置10、情報処理装置11、クライアント端末12、サービス提供装置14、リソース提供装置16、およびリソース提供装置17が実行するプログラムを、ダウンロードさせずにインターネット等のネットワーク経由で提供するように構成してもよい。
また、上記実施の形態の情報処理装置10、情報処理装置11、クライアント端末12、サービス提供装置14、リソース提供装置16、およびリソース提供装置17で実行されるプログラムを、ROM等に予め組み込んで提供するように構成してもよい。
上記実施の形態の情報処理装置10、情報処理装置11、クライアント端末12、サービス提供装置14、リソース提供装置16、およびリソース提供装置17で実行されるプログラムは、これらの装置の各々の上記機能構成のうち、プログラムにより実現可能な機能を含むモジュール構成となっている。
プログラムにより実現される機能は、制御装置401が補助記憶装置403等の記憶媒体からプログラムを読み出して実行することにより主記憶装置402にロードされる。すなわちプログラムにより実現される機能は、主記憶装置402上に生成される。
上記実施の形態の情報処理装置10、情報処理装置11、クライアント端末12、サービス提供装置14、リソース提供装置16、およびリソース提供装置17の機能の一部を、IC等のハードウェアにより実現してもよい。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
10、11 情報処理装置
10A 受信部
10B 送信部
10E 発行部
16、17 リソース提供装置
17F 生成部
17G 署名付与部

Claims (14)

  1. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置であって、
    前記クライアントに対して発行されたnonceと、前記クライアントが生成した第1公開鍵と、前記nonceを含むクライアント情報に対する第1署名と、を含む前記トークン発行要求を前記クライアントから受信する受信部と、
    前記トークン発行要求に含まれる前記第1署名の前記第1公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第1識別情報を含むログイン要求を前記クライアントへ送信する送信部と、
    前記クライアントを利用するユーザの認証情報および前記第1識別情報を含む認可許諾要求を前記クライアントから受信したときに、前記第1公開鍵を用いて生成した記名式トークンを前記アクセストークンとして発行する発行部と、
    を備える情報処理装置。
  2. 前記第1識別情報は、
    前記nonce、前記nonceの第2識別情報、または前記トークン発行要求の通信セッション識別情報、である、
    請求項1に記載の情報処理装置。
  3. 前記送信部は、
    発行された前記アクセストークンの特定情報を含むアクセストークン応答情報を、前記クライアントへ送信する、
    請求項1または請求項2に記載の情報処理装置。
  4. 前記特定情報は、
    発行された前記アクセストークン、または、該アクセストークンの識別情報である、
    請求項3に記載の情報処理装置。
  5. 前記発行部は、
    当該情報処理装置による発行を証明するための証明書を用いて、前記記名式トークンに第2署名を付与し、該第2署名付きの前記アクセストークンを発行する、
    請求項1〜請求項4の何れか1項に記載の情報処理装置。
  6. リソース提供要求対象のリソース提供装置の第3識別情報を含む前記トークン発行要求を受信したときに、前記トークン発行要求の送信元の前記クライアントが前記第3識別情報によって識別される前記リソース提供装置へのアクセス権を有するか否かを検証する検証部を備え、
    前記発行部は、
    前記検証部がアクセス権を有すると検証した場合、前記第3識別情報によって識別される前記リソース提供装置で利用可能な前記アクセストークンを発行する、
    請求項1〜請求項5の何れか1項に記載の情報処理装置。
  7. 前記発行部は、
    前記第3識別情報によって識別される前記リソース提供装置へ、前記トークン発行要求の送信元の前記クライアントからのアクセス許可要求を送信する、
    請求項6に記載の情報処理装置。
  8. 前記発行部は、
    前記検証部がアクセス権を有すると検証した場合、前記第3識別情報によって識別される前記リソース提供装置へ、前記第1公開鍵を用いた前記記名式トークンの生成を依頼し、該リソース提供装置で生成された前記記名式トークンを、前記アクセストークンとして発行する、
    請求項6または請求項7に記載の情報処理装置。
  9. 前記発行部は、
    前記第3識別情報によって識別される前記リソース提供装置へ、該リソース提供装置による発行を証明するための証明書を用いた、前記記名式トークンへの第3署名の付与を要求し、該第3署名付きの前記記名式トークンを、前記アクセストークンとして発行する、
    請求項8に記載の情報処理装置。
  10. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置と通信するリソース提供装置であって、
    前記情報処理装置は、
    前記クライアントに対して発行されたnonceと、前記クライアントが生成した第1公開鍵と、前記nonceを含むクライアント情報に対する第1署名と、を含む前記トークン発行要求を前記クライアントから受信し、前記トークン発行要求に含まれる前記第1署名の前記第1公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第1識別情報を含むログイン要求を前記クライアントへ送信し、
    前記リソース提供装置は、
    前記クライアントを利用するユーザの認証情報および前記第1識別情報を含む認可許諾要求を前記情報処理装置が前記クライアントから受信したときに、前記情報処理装置から受信した、前記クライアントの第1公開鍵を含むアクセストークン生成要求に含まれる前記第1公開鍵を用いて、記名式トークンを生成する生成部と、
    前記記名式トークンに、当該リソース提供装置で生成した第3秘密鍵を用いた第3署名を付与する署名付与部と、
    を備えたリソース提供装置。
  11. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置で実行される情報処理方法あって、
    前記クライアントに対して発行されたnonceと、前記クライアントが生成した第1公開鍵と、前記nonceを含むクライアント情報に対する第1署名と、を含む前記トークン発行要求を前記クライアントから受信するステップと、
    前記トークン発行要求に含まれる前記第1署名の前記第1公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第1識別情報を含むログイン要求を前記クライアントへ送信するステップと、
    前記クライアントを利用するユーザの認証情報および前記第1識別情報を含む認可許諾要求を前記クライアントから受信したときに、前記第1公開鍵を用いて生成した記名式トークンを前記アクセストークンとして発行するステップと、
    を含む情報処理方法。
  12. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行するコンピュータに、
    前記クライアントに対して発行されたnonceと、前記クライアントが生成した第1公開鍵と、前記nonceを含むクライアント情報に対する第1署名と、を含む前記トークン発行要求を前記クライアントから受信するステップと、
    前記トークン発行要求に含まれる前記第1署名の前記第1公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第1識別情報を含むログイン要求を前記クライアントへ送信するステップと、
    前記クライアントを利用するユーザの認証情報および前記第1識別情報を含む認可許諾要求を前記クライアントから受信したときに、前記第1公開鍵を用いて生成した記名式トークンを前記アクセストークンとして発行するステップと、
    を実行させるための情報処理プログラム。
  13. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置と通信するリソース提供装置で実行するリソース提供方法あって、
    前記情報処理装置は、
    前記クライアントに対して発行されたnonceと、前記クライアントが生成した第1公開鍵と、前記nonceを含むクライアント情報に対する第1署名と、を含む前記トークン発行要求を前記クライアントから受信し、前記トークン発行要求に含まれる前記第1署名の前記第1公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第1識別情報を含むログイン要求を前記クライアントへ送信し、
    前記リソース提供方法は、
    前記クライアントを利用するユーザの認証情報および前記第1識別情報を含む認可許諾要求を前記情報処理装置が前記クライアントから受信したときに、前記情報処理装置から受信した、前記クライアントの第1公開鍵を含むアクセストークン生成要求に含まれる前記第1公開鍵を用いて、記名式トークンを生成するステップと、
    前記記名式トークンに、当該リソース提供装置で生成した第3秘密鍵を用いた第3署名を付与するステップと、
    を含むリソース提供方法。
  14. クライアントから受信したトークン発行要求に対する応答としてアクセストークンを発行する情報処理装置と通信するコンピュータに実行させるためのリソース提供プログラムであって、
    前記情報処理装置は、
    前記クライアントに対して発行されたnonceと、前記クライアントが生成した第1公開鍵と、前記nonceを含むクライアント情報に対する第1署名と、を含む前記トークン発行要求を前記クライアントから受信し、前記トークン発行要求に含まれる前記第1署名の前記第1公開鍵を用いた検証結果が成功を示す場合、前記トークン発行要求の第1識別情報を含むログイン要求を前記クライアントへ送信し、
    前記リソース提供プログラムは、
    前記クライアントを利用するユーザの認証情報および前記第1識別情報を含む認可許諾要求を前記情報処理装置が前記クライアントから受信したときに、前記情報処理装置から受信した、前記クライアントの第1公開鍵を含むアクセストークン生成要求に含まれる前記第1公開鍵を用いて、記名式トークンを生成するステップと、
    前記記名式トークンに、前記コンピュータで生成した第3秘密鍵を用いた第3署名を付与するステップと、
    前記コンピュータに実行させるためのリソース提供プログラム。
JP2018171240A 2018-09-13 2018-09-13 情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラム Active JP6937280B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2018171240A JP6937280B2 (ja) 2018-09-13 2018-09-13 情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラム
US16/282,778 US11336449B2 (en) 2018-09-13 2019-02-22 Information processing apparatus, computer program product, and resource providing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018171240A JP6937280B2 (ja) 2018-09-13 2018-09-13 情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラム

Publications (2)

Publication Number Publication Date
JP2020042691A JP2020042691A (ja) 2020-03-19
JP6937280B2 true JP6937280B2 (ja) 2021-09-22

Family

ID=69772277

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018171240A Active JP6937280B2 (ja) 2018-09-13 2018-09-13 情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラム

Country Status (2)

Country Link
US (1) US11336449B2 (ja)
JP (1) JP6937280B2 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10904754B2 (en) 2018-11-28 2021-01-26 International Business Machines Corporation Cellular network authentication utilizing unlinkable anonymous credentials
US11177964B2 (en) * 2019-01-25 2021-11-16 International Business Machines Corporation Blockchain based authentication
US10769873B1 (en) 2019-06-28 2020-09-08 Alibaba Group Holding Limited Secure smart unlocking
US11757635B2 (en) * 2020-03-13 2023-09-12 Mavenir Networks, Inc. Client authentication and access token ownership validation
US11463258B2 (en) 2020-03-13 2022-10-04 Ebay Inc. Secure token refresh
US11770377B1 (en) * 2020-06-29 2023-09-26 Cyral Inc. Non-in line data monitoring and security services
IL275954A (en) 2020-07-09 2022-02-01 Google Llc Anonymous event confirmation with group signatures
IL275947A (en) 2020-07-09 2022-02-01 Google Llc Anonymous Event Confirmation
US11171964B1 (en) * 2020-12-23 2021-11-09 Citrix Systems, Inc. Authentication using device and user identity
US20230291548A1 (en) * 2022-03-08 2023-09-14 Western Digital Technologies, Inc. Authorization requests from a data storage device to multiple manager devices
CN114978675B (zh) * 2022-05-20 2023-06-20 辽宁华盾安全技术有限责任公司 一种访问认证方法、装置、电子设备及存储介质

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070255951A1 (en) * 2005-11-21 2007-11-01 Amiram Grynberg Token Based Multi-protocol Authentication System and Methods
JP4766249B2 (ja) * 2006-03-01 2011-09-07 日本電気株式会社 トークン譲渡方法、トークン譲渡システム及び権限認証許可サーバ
US8595816B2 (en) * 2007-10-19 2013-11-26 Nippon Telegraph And Telephone Corporation User authentication system and method for the same
JP4461465B1 (ja) * 2009-03-17 2010-05-12 サイバーステーション株式会社 Webシステム、命令対象システム、及び、コンテンツデータ提供方法
US20100250949A1 (en) * 2009-03-31 2010-09-30 Torino Maria E Generation, requesting, and/or reception, at least in part, of token
JP2012108739A (ja) * 2010-11-18 2012-06-07 Nippon Telegr & Teleph Corp <Ntt> ディジタル動画アクセス制御システムおよびプログラム
JP2015194879A (ja) * 2014-03-31 2015-11-05 富士通株式会社 認証システム、方法、及び提供装置
US9450760B2 (en) * 2014-07-31 2016-09-20 Nok Nok Labs, Inc. System and method for authenticating a client to a device
JP2016115260A (ja) 2014-12-17 2016-06-23 キヤノン株式会社 権限移譲システム、権限移譲システムに用いられる認可サーバー、リソースサーバー、クライアント、媒介装置、権限移譲方法およびプログラム
US20160277413A1 (en) 2015-03-20 2016-09-22 Kabushiki Kaisha Toshiba Access Permission Device, Access Permission Method, Program, and Communicating System
JP2016177795A (ja) 2015-03-20 2016-10-06 株式会社東芝 アクセス認可装置、アクセス認可方法、プログラムおよび通信システム
JP2018081643A (ja) * 2016-11-18 2018-05-24 キヤノン株式会社 認可サーバーおよびその制御方法、プログラム、並びに権限委譲システム

Also Published As

Publication number Publication date
US11336449B2 (en) 2022-05-17
US20200092101A1 (en) 2020-03-19
JP2020042691A (ja) 2020-03-19

Similar Documents

Publication Publication Date Title
JP6937280B2 (ja) 情報処理装置、リソース提供装置、情報処理方法、情報処理プログラム、リソース提供方法、リソース提供プログラム
US11082225B2 (en) Information processing system and control method therefor
US10785037B2 (en) Managing secure content in a content delivery network
US10581827B2 (en) Using application level authentication for network login
KR102362456B1 (ko) 권한 위양 시스템, 그 제어 방법 및 저장 매체
US8200834B2 (en) Method and system for secure server-based session management using single-use HTTP cookies
JP5357246B2 (ja) 統合認証のためのシステム、方法およびプログラム製品
KR101467174B1 (ko) 통신 수행 방법 및 그 장치와, 통신 수행 제어 방법 및 그장치
JP5119028B2 (ja) 画像形成システム、画像形成装置、画像形成プログラムおよび画像形成方法
US10754934B2 (en) Device, control method of the same, and storage medium
US9338165B2 (en) Common internet file system proxy authentication of multiple servers
US11277404B2 (en) System and data processing method
US20100100950A1 (en) Context-based adaptive authentication for data and services access in a network
KR20190024817A (ko) 권한 위양 시스템, 그 제어 방법 및 클라이언트
US10305913B2 (en) Authentication control device and authentication control method
CN114785590A (zh) 登录方法、装置、设备、存储介质
JP7043480B2 (ja) 情報処理システムと、その制御方法とプログラム
US9882891B2 (en) Identity verification
GB2498566A (en) Authenticating a user at a proxy using cookies
WO2011077305A1 (en) Methods and apparatuses for providing content for user terminals

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200701

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210428

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210511

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210709

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210830

R151 Written notification of patent or utility model registration

Ref document number: 6937280

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151