KR101640383B1 - 인가 서버 및 클라이언트 장치, 서버 연계 시스템, 및 토큰 관리 방법 - Google Patents

인가 서버 및 클라이언트 장치, 서버 연계 시스템, 및 토큰 관리 방법 Download PDF

Info

Publication number
KR101640383B1
KR101640383B1 KR1020147035695A KR20147035695A KR101640383B1 KR 101640383 B1 KR101640383 B1 KR 101640383B1 KR 1020147035695 A KR1020147035695 A KR 1020147035695A KR 20147035695 A KR20147035695 A KR 20147035695A KR 101640383 B1 KR101640383 B1 KR 101640383B1
Authority
KR
South Korea
Prior art keywords
authorization information
authorization
server
update
token
Prior art date
Application number
KR1020147035695A
Other languages
English (en)
Other versions
KR20150013855A (ko
Inventor
순스케 모가키
Original Assignee
캐논 가부시끼가이샤
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 캐논 가부시끼가이샤 filed Critical 캐논 가부시끼가이샤
Publication of KR20150013855A publication Critical patent/KR20150013855A/ko
Application granted granted Critical
Publication of KR101640383B1 publication Critical patent/KR101640383B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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
    • 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/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)

Abstract

연계원 시스템에 대하여 연계처 시스템에의 액세스 권한을 이양하는데 필요한 토큰을 생성하는 방법이 있다. 이 방법에서는, 토큰의 유효기간이 경과한 후에, 유저에의 확인 없이 토큰을 갱신하기 위해서, 리프레쉬 토큰을 발행한다. 토큰을 갱신하는데 필요한 정보가 유출되었을 경우, 의도하지 않는 시스템이 토큰을 갱신하고, 연계처 시스템이 부정으로 이용된다. 이 때문에, 유출된 리프레쉬 토큰을 무효화하는 부가 필요하다. 액세스 관리 서비스는, 리프레쉬 토큰을 이용하여 일련의 토큰을 발행시에 재발행된 토큰에 연결된 최초의 인가 처리시에 발행된 리프레쉬 토큰을 기억한다. 그 후, 최초에 발행된 리프레쉬 토큰의 지정을 받으면, 최초에 발행된 리프레쉬 토큰에 연결된 모든 리프레쉬 토큰은 무효화된다.

Description

인가 서버 및 클라이언트 장치, 서버 연계 시스템, 및 토큰 관리 방법{AUTHORIZATION SERVER AND CLIENT APPARATUS, SERVER COOPERATIVE SYSTEM, AND TOKEN MANAGEMENT METHOD}
본 발명은, 예를 들면, 복수의 온라인 서비스 시스템을 매시업(mash up)해서 실현되는 온라인 시스템에 있어서, 복수의 온라인 서비스 시스템간의 액세스를 제어하는데 필요한 인가 서버 및 클라이언트 장치, 서버 연계 시스템, 및 토큰 관리 방법에 관한 것이다.
최근, 클라우드 서비스라고 불리는, 인터넷을 거쳐서 소프트웨어의 기능을 제공하는 시스템이 주목을 모으고 있다. 최근에는, 복수의 클라우드 서비스를 연계시켜서, 새로운 시스템을 제공하는 경우가 증가하고 있다.
클라우드 서비스를 연계시킬 때 서비스를 제공하는 시스템간의 액세스 제어를 안전하고 용이하게 행하는 구조로서 "ＯＡｕｔｈ"라고 불리는 기술이 이용 가능하다("Ｔｈｅ ＯＡｕｔｈ 2.0 Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｄｒａｆｔ-ｉｅｔｆ-ｏａｕｔｈ-v2-25", Ｅ．Ｈａｍｍｅｒ, 2012년 10월 9일, <ＵＲＬ ｈｔｔｐ://ｔｏｏｌｓ.ｉｅｔｆ.ｏｒｇ/ｈｔｍｌ/ｄｒａｆｔ-ｉｅｔｆ-ｏａｕｔｈ-v2-25>).
ＯＡｕｔｈ는, 연계처의 시스템의 액세스 권한에 한하여, 연계원의 시스템에 대하여 유저의 액세스 권한을 이양하는 기술이다. 이 기술에 의해, 연계원의 시스템은, 연계처의 시스템에 대하여 해당 유저의 권한으로 액세스할 수 있고, 연계처 시스템이 제공하는 서비스를 이용한 서비스를 유저에게 제공할 수 있다. ＯＡｕｔｈ에 의거한 시스템의 액세스 권한 이양의 구성을, 연계처의 시스템의 인증 기구가 구비할 때, 연계처의 시스템에 있어서의 유저ID나 패스워드등의, 시큐리티에 관련된 인증 정보를 연계원의 시스템에 기억시키지 않고, 안전하게 시스템간의 연계를 실현할 수 있다. ＯＡｕｔｈ에서는, 연계원의 시스템으로부터의 액세스를 허가하는데 필요한 인가 정보에 대해 유효기간을 설정하고, 인가 정보의 유효기간이 만기가 된 후에 인가정보를 재발행하는 구조나, 인가 정보 및 인가 정보의 재발행을 무효로 하는 구조도 설정하고 있다.
한편, ＯＡｕｔｈ와는 다른 별도의 인증 기술로서, 이용 허가에 유효기간을 설정하는 방법이 알려져 있다. 이 방법에 있어서, 각 시스템에서 이용 허가의 유효기간을 연장하는 방법이나, 유효기간이 만기가 된 후라도 일정 기간내에 검증을 생략해서 다시 이용을 허가하는 방법이 종래부터 알려져 있다(일본국 공개특허공보 특개 2011-519087호를 참조).
그렇지만, 기존의 ＯＡｕｔｈ에 있어서의, 인가 정보의 유효기간이 만기가 된 후에 인가 정보를 재발행하는 구성에는 시큐리티의 면에서 과제가 있다. 보다 구체적으로는, 클라이언트의 인증 정보 및 갱신 인가 정보가 누설했을 경우, 악의가 있는 유저가 인가 정보를 부정하게 재발행하기도 한다. 클라이언트의 인증 정보 및 갱신 인가 정보의 누설에 대응하기 위해서 서버 시스템내에서 관리하고 있는 클라이언트의 인증 정보를 변경할 경우, 이러한 변경은 서버 시스템의 운용에 심각하게 영향을 주게 된다.
본 발명은, 전술한 과제를 해결할 수 있는 인가 시스템을 제공한다. 보다 구체적으로는, 본 발명은, 안전성을 높인 인가 서버 및 클라이언트 장치, 서버 연계 시스템, 및 토큰 관리 방법을 제공한다.
본 발명은 이하의 구성을 구비한다.
즉, 클라이언트 장치로부터 리소스 서버에의 액세스 요구를, 상기 요구와 관련지어서 상기 클라이언트 장치로부터 수신한 유효 인가 정보에 의거하여 인가하는 인가 서버는, 인증 정보와 함께 클라이언트 장치로부터 수신한 발행 요구에 따라, 리소스 서버에 액세스하기 위해서 이용되는 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보를, 발행하는 발행 수단; 갱신 인가 정보와 함께 수신한 리프레쉬 처리 요구에 따라, 새로운 갱신 인가 정보 및 새로운 인가 정보를 재발행하고, 재발행된 인가 정보 및 갱신 인가 정보에 관련지어, 새로운 갱신 인가 정보 및 인가 정보를 재발행하기 위해서 상기 발행 수단에 의해 발행한 갱신 인가 정보를 첫회 갱신 인가 정보로서 기억하는 재발행 수단; 및 갱신 인가 정보와 함께 수신한 무효화 요구에 따라, 수신한 상기 갱신 인가 정보가 첫회 갱신 인가 정보로서 관련된 갱신 인가 정보를 무효화하는 무효화 수단을 구비한다.
다른 관점에 의하면, 본 발명은 이하의 구성을 구비한다.
즉, 리소스 서버에 대하여, 인가 서버에 의해 발행된 인가 정보와 함께 액세스 요구를 송신해서 상기 리소스 서버에 의한 서비스를 요구하는 클라이언트 장치는, 상기 인가 서버에 의해 발행된 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보와, 상기 인가 정보를 재발행하기 위해서 상기 인가 서버가 최초에 발행한 첫회 갱신 인가 정보를 서로 관련시켜 기억하는 수단; 및 기억된 상기 첫회 갱신 인가 정보와 함께 무효화 요구를 상기 인가 서버에 송신하고, 상기 첫회 갱신 인가 정보에 관련된 갱신 인가 정보의 무효화를 요구하는 무효화 요구 수단을 구비한다.
또 다른 관점에 의하면, 본 발명은 이하의 구성을 구비한다.
즉, 클라이언트 장치로부터 리소스 서버에의 액세스 요구를, 상기 요구와 관련지어서 상기 클라이언트 장치로부터 수신한 유효 인가 정보에 의거하여 인가하는 인가 서버와, 리소스 서버에 대하여, 인가 서버에 의해 발행된 인가 정보와 함께 액세스 요구를 송신해서 상기 리소스 서버에 의한 서비스를 요구하는 클라이언트 장치와, 상기 클라이언트 장치에 대하여 서비스를 제공하는 상기 리소스 서버를 포함하는 서버 연계 시스템으로서, 상기 인가 서버는, 인증 정보와 함께 클라이언트 장치로부터 수신한 발행 요구에 따라, 리소스 서버에 액세스하기 위해서 이용되는 인가 정보와, 새로운 인가 정보를 상기 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보를 발행하는 발행 수단; 갱신 인가 정보와 함께 수신한 리프레쉬 처리 요구에 따라, 새로운 갱신 인가 정보 및 새로운 인가 정보를 재발행하고, 재발행된 인가 정보 및 갱신 인가 정보에 관련지어서, 새로운 갱신 인가 정보 및 인가 정보를 재발행하기 위해서 상기 발행 수단에 의해 발행한 갱신 인가 정보를 첫회 갱신 인가 정보로서 기억하는 재발행 수단; 및 갱신 인가 정보와 함께 수신한 무효화 요구에 따라, 수신한 상기 갱신 인가 정보가 첫회 갱신 인가 정보로서 관련되어 있는 갱신 인가 정보를 무효화하는 무효화 수단을 구비하고, 상기 클라이언트 장치는, 상기 인가 서버에 의해 발행된 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보와, 상기 인가 정보를 재발행하기 위해서 상기 인가 서버가 최초에 발행한 첫회 갱신 인가 정보를 서로 관련시켜 기억하는 수단; 및 기억된 상기 첫회 갱신 인가 정보와 함께 무효화 요구를 상기 인가 서버에 송신하고, 상기 첫회 갱신 인가 정보에 관련된 갱신 인가 정보의 무효화를 요구하는 무효화 요구 수단을 구비한다.
또 다른 관점에 의하면, 본 발명은 이하의 구성을 구비한다.
즉, 클라이언트 장치로부터 리소스 서버에의 액세스 요구를, 상기 요구와 관련지어서 상기 클라이언트 장치로부터 수신한 유효 인가 정보에 의거하여 인가하는 인가 서버와, 상기 리소스 서버에 대하여, 상기 인가 서버에 의해 발행된 인가 정보와 함께 액세스 요구를 송신해서 상기 리소스 서버에 의한 서비스를 요구하는 클라이언트 장치와, 상기 클라이언트 장치에 대하여 서비스를 제공하는 상기 리소스 서버를 가지는 서버 연계 시스템에 있어서의 토큰 관리 방법은, 상기 인가 서버가, 인증 정보와 함께 클라이언트 장치로부터 수신한 발행 요구에 따라, 리소스 서버에 액세스하기 위해서 이용되는 인가 정보와, 새로운 인가 정보를 상기 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보를 발행하는 발행 단계; 상기 클라이언트 장치가, 상기 인가 서버에 의해 발행된 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보와, 상기 인가 정보를 재발행하기 위해서 상기 인가 서버가 최초에 발행한 첫회 갱신 인가 정보를 서로 관련시켜 기억하는 단계; 상기 클라이언트 장치가, 액세스 요구에 따라 상기 인가 정보가 무효라는 것을 나타내는 응답을 수신했을 경우, 상기 인가 정보가 무효라는 것을 나타내는 상기 응답에 대응한 상기 인가 정보에 관련된 갱신 인가 정보와 함께 리프레쉬 처리 요구를 상기 인가 서버에 대하여 송신하는 단계; 상기 인가 서버가, 갱신 인가 정보와 함께 수신한 리프레쉬 처리 요구에 따라, 새로운 갱신 인가 정보 및 새로운 인가 정보를 재발행하고, 재발행된 인가 정보 및 갱신 인가 정보에 관련지어, 새로운 갱신 인가 정보 및 인가 정보를 재발행하기 위해서 상기 발행 단계에서 발행한 상기 갱신 인가 정보를 첫회 갱신 인가 정보로서 기억하는 재발행 단계; 상기 클라이언트 장치가, 기억된 상기 첫회 갱신 인가 정보와 함께 무효화 요구를 상기 인가 서버에 송신하고, 상기 첫회 갱신 인가 정보에 관련된 갱신 인가 정보의 무효화를 요구하는 무효화 요구 단계; 및 상기 인가 서버가, 갱신 인가 정보와 함께 수신한 무효화 요구에 따라, 수신한 상기 갱신 인가 정보가 첫회 갱신 인가 정보로서 관련된 갱신 인가 정보를 무효화하는 무효화 단계를 포함한다.
본 발명에 의하면, 클라이언트의 인증 정보 및 갱신 인가 정보가 누설했을 경우에도, 인가 정보가 부정하게 재발행되는 것을 막을 수 있다.
또한, 본 발명에 의하면, 클라이언트의 인증 정보가 변경될 필요가 없으므로, 클라이언트의 시스템을 정지시키지 않고, 작은 영향 범위내에서 갱신 인가 정보의 누설에 대응할 수 있다.
본 발명의 또 다른 특징들은, 첨부도면을 참조하여 이하의 예시적 실시예들의 설명으로부터 명백해질 것이다.
도 1은 시스템 전체의 블록도;
도 2는 서버의 하드웨어 구성을 나타내는 블록도;
도 3은 외부 서버의 소프트웨어 구성을 나타내는 블록도;
도 4는 액세스 관리 서버의 소프트웨어 구성을 나타내는 블록도;
도 5는 장표 서버의 소프트웨어 구성을 나타내는 블록도;
도 6a, 6b 및 6c는 외부 서비스 시스템(103)이 보유하는 데이터 구조를 나타낸 테이블;
도 7a 및 7b는 액세스 관리 서비스 시스템(104)이 보유하는 어카운트 테이블;
도 8은 액세스 관리 서비스 시스템(104)이 보유하는 인가 코드의 데이터 구조를 나타낸 테이블;
도 9는 액세스 관리 서비스 시스템(104)이 보유하는 인가 정보의 데이터 구조를 나타낸 테이블;
도 10a 및 10b는 액세스 토큰 발행 처리의 흐름도;
도 11은 인가 화면의 일례를 나타내고;
도 12a 및 12b는 본 발명에 의해 제어된 인가 처리의 흐름도;
도 13은 제1실시예에 따른 인가 정보 무효화 처리의 흐름도;
도 14는 제2실시예에 따른 인가 정보 무효화 처리의 흐름도;
도 15는 ＯＡｕｔｈ의 액세스 권한 이양 시퀀스를 나타내는 블록도;
도 16은 ＯＡｕｔｈ의 과제 1을 나타내는 블록도; 및
도 17은 ＯＡｕｔｈ의 과제 2를 나타내는 블록도다.
이하, 본 발명의 과제의 실제의 예들의 일부를 소개한다. ＯＡｕｔｈ에 의해 액세스 권한 이양을 행할 때, 연계처 시스템은, 연계원 시스템의 권한 확인과, 연계원 시스템을 이용하는 유저의 권한 확인을 행한다. 연계원 시스템은, 유저가 직접 액세스해서 서비스를 요구하는 시스템이다. 연계처 시스템은, 연계원 시스템과 연계하여, 연계원 시스템에 대하여 서비스 등(리소스를 포함한다)을 제공하는 시스템이다. 이후의 설명에서는, ＯＡｕｔｈ의 정의에 따라, 연계원 시스템을 클라이언트, 연계처 시스템을 리소스 서버, 리소스 서버의 인증 정보 및 인가 정보를 관리하는 서버를 인가 서버라고 부른다. 이때, 인가 서버가 관리하는 인증 정보는, 리소스 서버를 이용하는 유저와 시스템을 인증하는데 필요한 시큐리티 정보를 포함한다. 예를 들면, 그 인증 정보는, 유저ID 및 패스워드를 포함한다. 인가 서버가 관리하는 인가 정보는, ＯＡｕｔｈ의 권한 이양 시퀀스에 따라 인가 서버가 발행하고, 리소스 서버에의 액세스를 허가하는데 필요한 정보를 포함한다. 인가 정보를, ＯＡｕｔｈ에서는 액세스 토큰이라고 부른다. 클라이언트는 리소스 서버에 액세스할 때에, 리소스 서버에 액세스 토큰을 송신한다. 리소스 서버는, 수신한 액세스 토큰을 확인시키기 위해 인가 서버에 요구하고, 액세스 허가 여부를 판정한다. 이에 따라, 클라이언트는 인가 서버가 관리하고 있는 인증 정보를 모르게, 리소스 서버를 이용할 수 있다.
도 15를 참조하여, 이하, ＯＡｕｔｈ의 권한 이양 시퀀스에 관하여 설명한다. 또한, 연계원 시스템을 이용하고 있는 유저를 이후에 리소스 오너(또는, 간단히 오너라고도 부른다)라고 부르고, 유저가 조작하고 있는 정보 처리 단말이 구비하는 웹 브라우저를 이후에 유저 에이전트라고 부른다.
처리 단계1501에 있어서, 오너가 유저 에이전트를 거쳐서 클라이언트를 조작하고 있다. 이 상태에서, 클라이언트가 리소스 서버를 이용하기 위해서, ＯＡｕｔｈ의 시퀀스를 시작한다. 처리 단계1502에 있어서, 클라이언트가 유저 에이전트를 인가 서버에 리다이렉트(redirect)시킨다. 이 경우에, 클라이언트는, 클라이언트 자신을 유일하게 식별하는데 사용된 클라이언트ID와 리다이렉트ＵＲＬ을 인가 서버에 보낸다.
처리 단계1503에 있어서, 인가 서버는, 유저 에이전트를 거쳐서 오너를 인증한다. 오너의 인증은, 예를 들면, 유저 에이전트에게 인증 화면을 표시하고, 오너에 대하여 인가 서버가 관리하고 있는 유저ID와 패스워드의 입력을 촉구하는 방법으로 행해진다. 오너의 인증에 성공하면, 인가 서버는 인증한 오너가 리소스 서버에 대하여 적절한 액세스 권한을 갖는지를 판정한다.
처리 단계1504에 있어서, 인가 서버는, 유저 에이전트를 거쳐서, 액세스 권한을 가진다고 판정된 오너에 대하여, 클라이언트에 의한 리소스 서버에의 액세스의 인가 확인을 행한다. 오너에의 인가 확인은, 예를 들면, 인가 확인 화면을 표시하고, 오너에게 인가 버튼의 가압을 촉구하는 방법에 의해 행해진다. 오너가 인가를 행하면, 인가 서버는 인가 코드를 생성한다. 인가 코드는, 오너가 클라이언트에 대하여, 리소스 서버에의 액세스를 허가한 것을 나타내는 정보다.
처리 단계1505에 있어서, 인가 서버는, 처리 단계1502에서 클라이언트로부터 받은 리다이렉트ＵＲＬ에 대하여, 생성된 인가 코드를 보낸다.
처리 단계1506에 있어서, 클라이언트는 인가 서버에 대하여, 리소스 서버 이용에 필요한 인가 정보의 송신을 요구한다. 이 경우, 클라이언트는 수신한 인가 코드와, 클라이언트의 인증 정보를 보낸다. 클라이언트의 인증 정보는, 예를 들면 클라이언트ID와 패스워드를 포함한다. 인가 서버는, 수신한 인가 코드의 확인과, 클라이언트의 인증을 행한다. 클라이언트의 인증에 성공하면, 인가 서버는 리소스 서버가 클라이언트에 대하여 연계를 허가하고 있는지를 확인한다. 인가 코드가 유효하고, 또 리소스 서버가 클라이언트에 대하여 연계를 허가하고 있는 것이 확인되면, 인가 서버는 리소스 서버에 대한 인가 정보를 생성한다.
처리 단계1507에 있어서, 인가 서버는 생성한 인가 정보를 클라이언트에 보낸다.
처리 단계1508에 있어서, 클라이언트는 인가 정보를 리소스 서버에 보내서, 리소스 서버의 이용 요구를 발행한다.
처리 단계1509에 있어서, 리소스 서버는 액세스 허가를 판정하기 위해서, 인가 서버에 대하여 상기 수신한 인가 정보를 보낸다. 인가 서버는 수신한 인가 정보의 확인을 행한다.
처리 단계1510에 있어서, 인가 서버는 리소스 서버에 인가 정보의 확인 결과를 되돌린다. 리소스 서버는 인가 정보의 확인 결과에 따라, 클라이언트에 대하여 액세스 허가의 승인 여부를 판단한다.
ＯＡｕｔｈ에서는, 처리 단계1509, 1510과 같이, 인가 서버에서의 액세스 토큰의 확인만으로 리소스 서버에 대한 액세스 허가 여부를 판단하고 있다. 이 때문에, 액세스 토큰이 인증된 클라이언트이외의 시스템에 유출되면, 의도하지 않는 클라이언트가 액세스 토큰을 발행한 인증된 클라이언트인 양 행세하고, 리소스 서버를 이용할 수 있다. 이러한 문제로 인해, ＯＡｕｔｈ는 안전을 위해 액세스 토큰의 유효기간을 짧게 설정하는 것을 권장하고 있다. 한편, 액세스 토큰의 유효기간이 짧으면, 오너가 한번 인가한 시스템에서도, 처리 단계1504에서 오너에 대한 인가 확인이 매회 발생하기 때문에, 불편해진다. 이 때문에, ＯＡｕｔｈ는, 처리 단계1506에서의 액세스 토큰 발행시에, 액세스 토큰과 함께 액세스 토큰 갱신을 인가하는 갱신 인가 정보를 발행하는 방법을 제공하고 있다. 이후, 이 갱신 인가 정보를 리프레쉬 토큰이라고 부른다. 리프레쉬 토큰은, 오너에 대한 인가 확인을 하지 않고, 액세스 토큰을 발행하는데 필요한 정보다. 인가 서버는, 리프레쉬 토큰과 함께 발행된 액세스 토큰과 같은 권한을 갖거나, 그 보다 좁힌 권한을 갖는, 새로운 액세스 토큰을 발행한다.
리프레쉬 토큰을 사용해서 새로운 액세스 토큰을 발행할 때는, 클라이언트는, 인가 서버에 대하여, 리프레쉬 토큰과, 클라이언트의 인증 정보를 보낸다. 클라이언트의 인증 정보는, 예를 들면, 클라이언트의 ID와 패스워드를 포함한다. 인가 서버는, 리프레쉬 토큰의 확인과 클라이언트의 인증을 행한다. 클라이언트의 인증에 성공하면, 인가 서버는 리소스 서버가 클라이언트에 대하여 연계를 허가하고 있는지를 확인한다. 리프레쉬 토큰이 유효하고, 또 리소스 서버가 클라이언트에 대하여 연계를 허가하고 있는 것이 확인되면, 인가 서버는 새로운 액세스 토큰과 리프레쉬 토큰을 발행한다. 이 경우에, 인가 서버는 이용된 리프레쉬 토큰을 무효로 한다. 이후, 리프레쉬 토큰을 사용해서 액세스 토큰의 재발행을 하는 처리를, 리프레쉬 처리라고 부른다. 또한, 토큰의 재발행을, 토큰의 갱신 혹은 토큰의 리프레쉬라고 부르는 경우도 있지만, 이것들은 본 실시예에서는 같은 뜻이다.
이 경우에, 리프레쉬 토큰 및 클라이언트의 인증 정보가 유출했을 경우, 부정한 클라이언트가 인증된 클라이언트인 양 행세하여 리프레쉬 처리를 실행할 수 있다. 리프레쉬 처리를 실행한 부정한 클라이언트는, 발행된 액세스 토큰을 사용해서 인증된 클라이언트인 양 행세하여 리소스 서버를 이용할 수 있다. 또한, 부정한 클라이언트는, 리프레쉬 처리에 의해 발행된 새로운 리프레쉬 토큰을 이용하여 인증된 클라이언트인 양 행세해서 리소스 서버를 계속 이용할 수 있다. 한층 더, 부정한 클라이언트가 발행한 액세스 토큰을 제공하는 것만으로, 여러가지 클라이언트가, 리소스 서버를 부정하게 이용할 수 있다.
ＯＡｕｔｈ가 공개하고 있는 범위내에서 리프레쉬 토큰 및 클라이언트의 인증 정보의 유출에 대응하기 위해서는, 2개의 방법이 있다. 첫번째 방법에서는, 리프레쉬 토큰을 지정하고, 지정한 리프레쉬 토큰과, 그 리프레쉬 토큰과 페어가 되는 액세스 토큰을 각각 무효로 한다. 이 방법에 의해, 리프레쉬 토큰이 무효화되므로, 리프레쉬 처리를 막을 수 있다.
그러나, 이 방법에는 과제가 있다. 이하, 도 16을 참조하여 본 방법의 과제를 설명한다. 처리 단계1601에 있어서, 부정한 클라이언트가 인가 서버에 대하여 리프레쉬 처리의 실행을 요구한다. 부정한 클라이언트는, 클라이언트로부터 유출된 인증 정보 및 리프레쉬 토큰을 소유하고 있는 시스템이라고 가정한다. 부정한 클라이언트는 인증된 클라이언트의 인증 정보를 이용하고 있으므로, 인가 서버에서의 클라이언트 인증에 성공한다. 한층 더, 리프레쉬 토큰은 인증된 것이기 때문에, 인가 서버에서의 리프레쉬 토큰 확인도 성공한다. 이에 따라, 인가 서버는, 리프레쉬 처리를 행하고, 새로운 액세스 토큰과 리프레쉬 토큰을 발행한다. 그 후에, 인가 서버는 리프레쉬 처리에 이용된 리프레쉬 토큰을 무효로 한다. 처리 단계1602에 있어서, 인가 서버는 부정한 클라이언트에 대하여, 발행된 액세스 토큰과 리프레쉬 토큰을 건네준다.
이 상태에서, 처리 단계1603에 있어서, 클라이언트가 리프레쉬 토큰과 액세스 토큰의 무효화를 요구한다. 그러나, 클라이언트가 소유하는 리프레쉬 토큰은, 처리 단계1601에서의 리프레쉬 처리에 의해 이미 무효화되어 있다. 또한, 클라이언트는, 처리 단계1601의 리프레쉬 처리로 발행된 리프레쉬 토큰을 알 수 없다. 이 때문에, 클라이언트는, 부정한 클라이언트가 1회라도 리프레쉬 처리를 실행하면, 그 이후의 리프레쉬 처리를 무효화할 수 없다.
두번째 방법에서는, 인증된 클라이언트의 인증 정보를 갱신한다. 예를 들면, 인가 서버에서 클라이언트의 패스워드를 변경하면, 변경전의 인증 정보밖에 모르는 부정한 클라이언트에 의한 리프레쉬 처리를 막을 수 있다. 이 방법에 의하면, 부정한 클라이언트가 리프레쉬 처리를 실행할 경우에도, 리프레쉬 처리를 막을 수 있다.
그러나, 이 방법은 영향 범위가 넓다고 하는 과제를 가진다. 이하, 도 17을 참조하여 본 방법의 과제를 설명한다. 처리 단계1701에서 오너A가 클라이언트를 이용하고, 처리 단계1702에서 클라이언트가, 이전에 발행한 액세스 토큰을 사용해서 리소스 서버에의 액세스를 요구한다고 가정한다. 처리 단계1703에 있어서, 리소스 서버는 액세스 허가의 여부를 판정하기 위해서 액세스 토큰을 인가 서버에 보낸다. 그 액세스 토큰은 무효라고 가정한다. 이 때문에, 처리 단계1704에 있어서, 인가 서버는 리소스 서버에 무효 액세스 토큰 메시지를 회신한다. 리소스 서버는, 액세스 토큰이 무효이기 때문에, 그 액세스를 거부한다. 처리 단계1705에 있어서, 리소스 서버는, 클라이언트에 무효 액세스 토큰 메시지를 회신하고, 그 액세스를 거부한다.
처리 단계1706에 있어서, 클라이언트는, 액세스 토큰이 무효이기 때문에, 리프레쉬 토큰을 이용해서 액세스 토큰의 재발행을 시험해 본다. 클라이언트는 인가 서버에 리프레쉬 토큰과 클라이언트의 인증 정보를 보내어, 리프레쉬 처리의 실행을 요구한다. 그 리프레쉬 토큰이 무효라고 가정한다. 리프레쉬 토큰이 무효인 경우에는, 이미 리프레쉬 처리가 실행되었으므로 무효화되었거나, 리프레쉬 토큰의 유효기한이 경과해서 무효이다. 인가 서버는, 처리 단계1707에서 클라이언트에 리프레쉬 토큰 무효 메시지를 회신한다.
클라이언트는, 그 리프레쉬 토큰 무효 메시지를 받으면, 리프레쉬 처리의 부정한 실행 가능성을 검지한다. 그 때문에, 처리 단계1708에 있어서, 클라이언트는, 인가 서버에 대하여 클라이언트의 인증 정보의 변경을 요구한다. 인증 정보의 변경은, 예를 들면 패스워드 변경이다. 인가 서버는, 클라이언트의 인증 정보 변경 요구를 받아, 자신이 관리하고 있는 클라이언트의 인증 정보를 갱신한다. 그 후에, 인가 서버는, 처리 단계1709에서 클라이언트에 대하여, 클라이언트의 인증 정보 변경 종료 통지를 보낸다.
이때, 인가 서버에서의 클라이언트 인증은, 액세스 토큰 발행 타이밍과, 리프레쉬 처리 타이밍에서 실행된다. 이 때문에, 패스워드를 변경하기 위해서, 이것들의 처리를 정지시켜야 한다. 즉, 처리 단계1708과 1709의 사이는 클라이언트에서의 이것들의 처리가 정지된다. 이 경우에, ＯＡｕｔｈ는, 하나의 클라이언트를 복수의 오너가 이용하는 모델이다. 예를 들면, 처리 단계1701의 클라이언트 이용과 병행하여, 오너B로부터의 클라이언트 이용 요구의 처리 단계1710과, 오너C로부터의 클라이언트 이용 요구의 처리 단계1711이 실행된다. 이 때문에, 오너A의 인가에 의해 발행된 리프레쉬 토큰이 무효였을 경우에도, 처리 단계1708과 1709의 사이는, 오너B와 오너C로부터의 요구에 따라 액세스 토큰 발행 처리와 리프레쉬 처리도 정지된다. 즉, 만약 클라이언트를 정지하면, 이것은 클라이언트를 이용하는 모든 오너에게 영향을 미친다.
본 발명은, 이러한 과제를 해결할 수 있는 것으로, 클라이언트의 인증 정보 및 리프레쉬 토큰이 유출했을 경우에, 좁은 영향 범위내에서 액세스 토큰의 재발행을 막고, 시스템의 부정이용을 막는 구조를 제공한다.
이하, 본 발명을 실시하기 위한 최선의 형태에 대해서 도면을 참조하여 설명한다.
[제1 실시예]
인터넷상에서, 여러가지 서비스 제공자가 여러가지 온라인 서비스를 제공하고 있다. 이러한 온라인 서비스는, 단일의 서비스 제공자가 운영하고 있는 스탠드 얼론 온라인 서비스와, 복수의 서비스 제공자가 운영하고 있는 복수의 온라인 서비스를 조합하여서 1개의 솔루션을 실현하는 수법도 포함한다. 후자의 솔루션을 "매시업"이라고 하고, 표면상으로는 마치 1개의 웹 사이트 혹은 웹 서비스처럼 보인다. 그렇지만, 실제의 백엔드(backend)에서는, 복수의 온라인 서비스가 연계 및 연동하여 필요한 기능을 조합함으로써, 그 솔루션을 실현한다. 또한, 이 경우의 온라인 서비스는, 웹 사이트, 웹 어플리케이션, 웹 서비스등이 제공하는 기능군이다. 웹 사이트, 웹 어플리케이션, 웹 서비스등은, 서버 컴퓨터로 실행된 소프트웨어 프로그램이다. "매시업"에 의해 구성된 시스템을, 본 실시예에서는 서버 연계 시스템 혹은 간단히 연계 시스템이라고도 부른다.
<온라인 서비스 시스템의 구성 예>
도 1은, 각종 온라인 서비스를 포함하는 네트워크 구성을 나타낸다. 인터넷(100)은, 인터넷등의 외부적으로 접속 가능한 퍼블릭(public) 네트워크다. 인트라네트(101)는 ＬＡＮ등의 외부적으로 접속불가능한 프라이빗(private) 네트워크다. 정보단말(102)은, 퍼스널 컴퓨터나 모바일 단말등을 포함하고, 인터넷(100)을 통하여 온라인 서비스를 이용할 때에 사용된다. 본 예에서는 2대의 단말 102A와 단말 102B가 도시되어 있다. 그러나, 이들 단말 중 어느 한쪽을 사용해도 되므로, 특별히 구별을 하지 않는 한 정보단말(102)이라고 칭한다. ＯＡｕｔｈ에 있어서는, 정보단말(102)을 조작하는 유저를 오너, 정보단말(102)이 구비하는 웹 브라우저를 유저 에이전트라고 부른다. 외부 서비스 시스템(103)은, (후술하는) 장표 서비스 시스템(105)을 온라인에서 매시업한 온라인 서비스 시스템이다. 이 시스템을, ＯＡｕｔｈ에서의 클라이언트라고 부른다. 또한, 본 실시예에서는, 이러한 시스템을, 클라이언트가 장치인 것을 명확히 하기 위해서 클라이언트 장치라고 부르는 경우도 있다. 외부 서비스 시스템(103)은, 1대 또는 복수대의 외부 서버로 구성되고, 부하 분산장치(108)에 의해 인터넷(100)으로부터의 리퀘스트를 분산해서 처리하도록 구성되어 있다. 또한, 도 1에서 외부 서비스 시스템(103)은 외부 서버 103A와 103B의 2대로 구성되지만, 실제로는 1대 또는 복수대의 외부 서버로 구성된다.
액세스 관리 서비스 시스템(104)은, 유저의 인증 정보 및 인가 정보를 관리하는 서비스 시스템이다. ＯＡｕｔｈ에 있어서는, 이 시스템을, 인가 서버라고 부른다. 액세스 관리 서비스 시스템(104)은 1대 또는 복수대의 액세스 관리 서버로 구성되고, 부하 분산장치(108)에 의해 인터넷(100) 및 인트라네트(101)로부터의 리퀘스트를 분산하여 처리하도록 구성되어 있다. 또한, 도 1에서 액세스 관리 서비스 시스템(104)은 액세스 관리 서버 104A와 104B의 2대로 구성되어 있지만, 실제로는 1대 또는 복수대의 액세스 관리 서버로 구성된다.
장표 서비스 시스템(105)은, 인터넷(100)을 통해 정보단말(102) 혹은 외부 서비스 시스템(103)으로부터의 리퀘스트에 따라 장표를 생성하는 온라인 서비스 시스템이다. ＯＡｕｔｈ에 있어서는, 이 시스템을 리소스 서버라고 부른다. 장표 서비스 시스템(105)은 1대 또는 복수대의 장표 서버로 구성되고, 부하 분산장치(108)에 의해 인터넷(100)으로부터의 리퀘스트를 분산하여 처리하도록 구성되어 있다. 또한, 장표 서비스 시스템(105)은 인트라네트(101)를 통해서 리퀘스트를 다른 부하 분산장치(108)에 의해 분산 및 처리할 수 있다. 또한, 도 1에서 장표 서비스 시스템(105)은 장표 서버 105A와 105B의 2대로 구성되어 있지만, 실제로는 1대 또는 복수대의 장표 서버로 구성된다. 본 예에서는, 리소스 서버로서 장표 서비스 시스템을 예시하고, 웹을 거쳐서 서비스를 제공하는 서버이면 어떠한 다른 서버도 적용가능하다.
<서버 컴퓨터의 하드웨어 구성>
도 2는, 도 1에 나타낸 각종 서버를 구성하는 웹 사이트, 웹 어플리케이션, 웹 서비스등의 소프트웨어 프로그램을 실행하는 서버 컴퓨터의 정보처리 기능의 논리구성을 보이고 있다.
유저 인터페이스(201)는, 디스플레이, 키보드, 마우스등에 의한, 정보의 입출력에 필요한 하드웨어다. 이것들의 하드웨어를 구비하지 않는 컴퓨터는, 리모트 데스크탑등에 의해, 다른 컴퓨터로부터 접속 및 조작할 수 있다. 네트워크 인터페이스(202)는, ＬＡＮ등의 네트워크에 접속하여, 다른 컴퓨터와 네트워크 기기와의 통신을 행하는 하드웨어다. ＣＰＵ(203)는, ＲＯＭ(204), ＲＡＭ(205), 이차 기억장치(206)등으로부터 로딩된 프로그램을 실행하고, 각종 서비스를 실현한다. ＲＯＭ(204)은, 임베디드 프로그램 및 데이터가 기록되어 있는 기억장치다. ＲＡＭ(205)은, 일시 메모리 영역이다. 이차 기억장치(206)는, ＨＤＤ로 대표되는 외부 기억장치다. 각부는 입출력 인터페이스(207)를 통해서 접속되어 있다.
<외부 서버의 기능 구성>
도 3은, 외부 서버103A의 내부구조를 나타낸 블록도다. 리퀘스트 처리부(301)는, 외부 서비스 시스템(103)이 인터넷(100)을 경유해서 수신한 기능 리퀘스트를 처리하는 처리부다. 기능 제어부(302)는 리퀘스트 처리부(301)로부터의 요구를 받고, 필요한 처리를 실행하고, 응답 데이터를 호출원에 회신시킨다. 기능 연계 데이터 관리부(303)는, 외부 서비스 시스템(103)이 연계하고 있는 시스템에 대한 리퀘스트를 생성하는데 필요한 데이터를 관리한다. 인가 코드 관리부(304)는, 인가 코드의 데이터를 관리한다. 토큰 관리부(305)는 인가 정보의 데이터를 관리한다. 외부 서버103B는, 외부 서버103A와 다른 기능을 제공할 수 있다. 그렇지만, 본 예에서는, 외부 서버103B는, 외부 서버103A와 같은 구성을 가지고, 같은 기능을 제공해서 부하를 분산시킨다. 외부 서버103A가 제공하는 기능으로서는, 예를 들면, 네트워크 프린트 서비스가 있다. 예를 들면, 외부 서버103A는, 클라이언트로서, 유저 에이전트인 웹 브라우저로부터 인쇄 대상의 장표 데이터의 소재나 명칭의 지정과 함께 그 장표 데이터의 인쇄의 리퀘스트를 수신한다. 이 요구에 따라, 외부 서버103A는 장표 서비스 시스템(105)에 액세스해서 유저가 요구한 장표 데이터를 획득한다. 그리고, 외부 서버103A는, 그 장표 데이터를, 그 요구에 따라 지정된 데이터와 머지된(merged) 후에 인쇄 데이터로 변환하고, 지정된 네트워크에 있는 인쇄장치 혹은 인쇄 서버에 인쇄 데이터를 송신해서 인쇄시킨다. 물론, 이것은 일례이며, 외부 서비스 시스템(103)이 제공하는 서비스는 그 인쇄 서비스에 한정되지 않는다.
<액세스 관리 서버의 기능 구성>
도 4는, 액세스 관리 서버104A의 내부구조를 나타낸 블록도다. 액세스 관리 서버104B도 마찬가지다. 액세스 관리 리퀘스트 처리부(401)는, 액세스 관리 서비스 시스템(104)이 인터넷(100) 및 인트라네트(101)를 경유해서 수신한 인증 및 인가 리퀘스트를 처리하는 처리부다. 또한, 액세스 관리 리퀘스트 처리부(401)는, 액세스제어부(402)로부터 회신된 응답 데이터를 호출원에 회신한다. 액세스제어부(402)는, 인증 데이터 관리부(403) 및 인가 데이터 관리부(404)로부터 취득된 데이터에 근거하여, 인증 및 인가 리퀘스트에 대하여 응답 데이터를 생성하여, 액세스 관리 리퀘스트 처리부(401)에 그 응답 데이터를 회신한다. 인증 데이터 관리부(403)는, 유저 어카운트의 데이터를 관리한다. 보다 구체적으로는, 각 유저 어카운트는, 예를 들면, 유저 고유의 ID와 패스워드의 조를 포함한다. 또한, ID와 패스워드의 조를 크리덴셜(credential)이라고도 부른다. 인가 데이터 관리부(404)는, 인가 정보의 데이터를 관리한다. 인가 데이터 관리부(404)는 인가 정보와 아울러 갱신 인가 정보의 데이터도 관리한다. 인가 데이터 관리부(404)는, 최신의 인가 정보 및 갱신 인가 정보를 기억할뿐만아니라, 후술하는 바와 같이, 어떤 유저에 대하여 최초에 발행된 갱신 인가 정보와 해당 유저에 대한 최신의 갱신 인가 정보간의 관계를 기억하고 있다.
<장표 서버105의 기능 구성>
도 5는, 장표 서버105A의 내부구조를 나타낸 블록도다. 장표 서버105B도 마찬가지다. 장표 리퀘스트 처리부(501)는, 인터넷(100)을 경유해서 장표 데이터 생성 리퀘스트 및 장표 데이터 취득 리퀘스트를 수신한다. 장표제어부(502)는, 장표 리퀘스트 처리부(501)가 수신한 리퀘스트에 따라 필요한 처리를 실행하고, 응답 데이터를 호출원에 회신한다. 장표제어부(502)는 인트라네트(101)를 경유해서 액세스 관리 서비스 시스템(104)에 대하여 인증 리퀘스트를 송신하고, 인증 결과를 수신한다. 또한, 장표제어부(502)는, 액세스 관리 서비스 시스템(104)에 대하여 인가 확인 리퀘스트를 송신하고, 인가 확인 결과를 수신한다. 장표 데이터 처리부(503)는, 장표제어부(502)로부터 장표 데이터 생성 리퀘스트를 수신하고, 장표 데이터를 생성한다. 또한, 장표 데이터 처리부(503)는 생성된 장표 데이터를 응답으로서 장표제어부(502)에 회신한다. 장표 데이터 관리부(504)는, 장표 데이터 처리부(503)에 있어서의 장표 데이터 생성 처리에 사용되는 장표 포맷 데이터 및 장표 데이터를 등록 및 관리한다. 또한, 장표 데이터 관리부(504)는, 장표제어부(502)로부터의 장표 데이터 취득 리퀘스트를 수신하고, 응답으로서 장표 데이터를 회신한다.
<외부 서비스 시스템에 의해 관리되는 정보>
도 6a 내지 6c는, 외부 서비스 시스템(103)이 보유하는 인가 정보와 인가 코드, 및 외부 서비스 시스템의 인증 정보의 데이터 구조를, 테이블 형식으로 나타낸 도다. 인가 정보 및 인가에 관련되는 정보는 인가 정보 관리 테이블(600)과 인가 코드 테이블(610)을 사용하여 관리되고, 외부 서비스 시스템의 인증 정보는 클라이언트 크리덴셜 테이블(620)을 사용하여 관리된다.
인가 정보 관리 테이블(600)은, 연계 대상의 시스템 이름을 나타내는 연계처 시스템명(601), 인가 정보를 나타내는 액세스 토큰ID(602), 갱신 인가 정보를 나타내는 리프레쉬 토큰ID(603), 및 첫회 리프레쉬 토큰ID(604)를 포함한다. 액세스 토큰ID(603)에는, 액세스 관리 서버가 발행하는 액세스 토큰을 보존한다. 리프레쉬 토큰ID(603)에는, 액세스 관리 서버가 발행하는 리프레쉬 토큰을 보존한다. 첫회 리프레쉬 토큰ID(604)에는, 최초의 인가 처리시에 액세스 관리 서버가 발행한 최초의 리프레쉬 토큰을 보존한다. 리프레쉬 처리를 실시하면, 액세스 토큰ID(602) 및 리프레쉬 토큰ID(603)는, 재발행된 인가 정보 및 갱신 인가 정보에 의해 각각 갱신된다. 그렇지만, 첫회 리프레쉬 토큰ID(604)에는, 최초의 리프레쉬 처리에 이용된 상기 갱신 인가 정보가 연속적으로 기억된다. 또한, 이들 필드명이 "토큰ID"를 포함하지만, 이들 필드는 토큰 ID 대신에 토큰 자신을 격납하고 있다.
인가 코드 테이블(610)은, 연계 대상의 시스템 이름을 나타내는 연계처 시스템명(611)과, 액세스 관리 서비스 시스템(104)이 생성하는 인가 코드를 유일하게 식별하는데 사용된 인가 코드ID(612)를 포함한다.
인증 정보 테이블(620)은, 연계 대상의 시스템 이름을 나타내는 연계처 시스템명(621)과, 연계 대상의 시스템에 대하여 외부 서비스 시스템(103)을 인증하는데 필요한 클라이언트ID(622) 및 패스워드(623)를 포함한다. 도 6a 내지 6c에 도시된 각 데이터 구조에 격납된 데이터의 처리 상세에 관해서는 후술한다. 또한, 외부 서버 시스템(103)이 관리하는 인가 정보 관리 테이블(600)의 1개의 레코드를, 본 실시예에서는 클라이언트 인가 관련 정보라고도 한다.
<액세스 관리 서비스 시스템에 의해 관리되는 정보>
도 7a, 7b, 도 8 및 도 9는, 액세스 관리 서비스 시스템(104)이 보유하고, 인가 및 인증에 관련된 각종 정보를 나타낸다. 도 7a 및 7b는, 액세스 관리 서비스 시스템(104)이 보유하는 유저 정보 및 시스템 정보의 데이터 구조를 테이블 형식으로 나타낸 도다. 유저 정보는 유저 테이블(700)을 사용하여 관리되고, 시스템 정보는 클라이언트 테이블(710)을 사용하여 관리된다.
또한, 관리되는 유저 정보는, 액세스 관리 서비스(104)가 관리하고 있는 시스템(ＯＡｕｔｈ에 있어서의 리소스 서버)의 각 유저의 정보다. 본 실시예에 있어서는, 관리하고 있는 시스템의 예로서, 장표 서비스 시스템(105)의 유저가 등록되어 있다.
또한, 관리되는 시스템 정보는, 인가 서버(본 예의 액세스 관리 서비스 시스템에 해당)가 액세스 토큰의 발행 및 리프레쉬 처리시에 실행하는, 클라이언트의 인증에 이용된 인증 정보다. 본 실시예에서는, 그 시스템 정보는, 클라이언트인 외부 서비스 시스템(103)을 식별하는데 필요한 클라이언트ID와 패스워드를 포함한다.
유저 테이블(700)은, 유저ID(701)와 패스워드(702)로 이루어진, 유저 정보를 포함한다. 클라이언트 테이블(710)은, 클라이언트의 ID를 나타내는 클라이언트ID(711)와, 패스워드(712)로 이루어진, 시스템 정보를 포함한다. 도 7a 및 7b에 도시된 각 데이터 구조에 격납된 데이터의 처리 상세에 관해서는 후술한다.
도 8은, 액세스 관리 서비스 시스템(104)이 보유하는 인가 코드의 데이터 구조를 테이블 형식으로 나타낸 도다. 인가 코드는, 인가 코드 테이블(800)을 사용하여 관리된다.
인가 코드 테이블(800)은, 인가 코드를 유일하게 식별하는데 사용된 값을 나타내는 인가 코드ID(801)와, 인가를 실행한 유저를 유일하게 식별하는데 사용된 유저ID(802)로 이루어진다. 인가 코드는, 리소스 서버의 액세스 권한을 가지는 오너에 의한 리소스 서버에의 액세스의 허가, 즉, 본 예에서는 장표 서비스 시스템(105)에 대한 액세스 권한을 가지는 유저에 의한 장표 서비스 시스템(105)에의 액세스의 허가를 나타내는 코드다. 즉, 인가 코드에 의거하여, 리소스 서버에의 액세스 권한이 오너로부터 클라이언트에 이양된다. 도 8에 도시된 데이터 구조에 격납된 데이터의 처리 상세에 관해서는 후술한다.
(인가 정보)
도 9는, 액세스 관리 서비스 시스템(104)이 보유하는 인가 정보의 데이터 구조를 테이블 형식으로 나타낸 도다. 인가 정보는 인가 정보 관리 테이블(900)을 사용하여 관리된다. 또한, 인가 정보는 액세스 토큰에 대응하고, 갱신 인가 정보는 리프레쉬 토큰에 대응한다. 또한, 도 9에 있어서, 필드901∼908의 1조의 정보를, 본 실시예에서는 인가 관련 정보라고도 한다.
인가 정보 관리 테이블(900)은, 액세스 권한마다, 인가 정보인 액세스 토큰ID(901)와, 액세스 토큰 발행 일시(902)와, 액세스 토큰 유효 일시(즉, 유효기한)(903)를 가진다. 또한, 갱신 인가 정보인 리프레쉬 토큰ID(904)와, 리프레쉬 토큰 발행 일시(905)와, 리프레쉬 토큰 유효 일시(906)를 가진다. 한층 더, 인가 정보 관리 테이블(900)은, 액세스 권한마다, 해당 액세스 토큰에 의한 리소스 서버(즉, 장표 서비스 시스템)에의 액세스를 허가한 유저의 유저ID(907)와, 첫회 리프레쉬 토큰ID(908)을 가진다. 첫회 리프레쉬 토큰ID(908)에는, 해당 액세스 권한에 관련하여 최초의 액세스 토큰과 함께 발행된 리프레쉬 토큰ID를 보존한다.
또한, 액세스 관리 서비스 시스템(104)이 액세스 토큰의 리프레쉬 처리를 행하면, 액세스 토큰 및 리프레쉬 토큰 모두가 재발행된다. 재발행된 액세스 토큰도, 소스 액세스 토큰과 같은 하나의 액세스 권한에 관련된다. 그러나, 재발행된 액세스 토큰 등의 인가 관련 정보와 그 소스 액세스 토큰 등의 인가 관련 정보를 구별할 경우에는, "새로운" 및 "이전의"가, 그 정보들에 첨부된다. 즉, 리프레쉬 토큰을 사용해서 리프레쉬 처리가 실행되면, 새로운 액세스 토큰 및 새로운 리프레쉬 토큰이 재발행된다. 재발행전의 액세스 토큰 및 리프레쉬 토큰을, 각각 이전의 액세스 토큰 및 이전의 리프레쉬 토큰이라고 부른다. 또한, 하나의 액세스 권한에 관련된 최초의 액세스 토큰 및 리프레쉬 토큰을, 각각 첫회 액세스 토큰 및 첫회 리프레쉬 토큰이라고 부른다. 리프레쉬 처리에 의해 재발행된 액세스 토큰 및 리프레쉬 토큰은, 그것들의 발행 일시 및 유효 일시와 함께 인가 정보 관리 테이블(900)에 보존된다. 유효 일시는, 그 발행 일시에 소정의 기간을 더해서 얻어질 수 있다. 유저ID(907)는, 리프레쉬 처리에 이용된 리프레쉬 토큰에 관련지어서 격납된 유저ID를 보존하고, 첫회 리프레쉬 토큰ID(908)는, 이용된 리프레쉬 토큰에 관련지어서 격납된 첫회 리프레쉬 토큰의 값을 보존한다. 그렇지만, 그 이용된 리프레쉬 토큰에 관련지어서 보존되어 있는 첫회 리프레쉬 토큰의 값이 "ｎｕｌｌ"이었을 경우에는, 리프레쉬 처리에 이용된 리프레쉬 토큰의 값이 첫회 리프레쉬 토큰이고, 그 값은 해당 액세스 권한의 첫회 리프레쉬 토큰ID(908)로서 보존된다. 물론, ｎｕｌｌ 대신에 첫회 리프레쉬 토큰을 보존하여도 된다. 리프레쉬 처리전의 액세스 토큰의 유효일시 및 리프레쉬 토큰의 유효일시가 모두 만료한 경우에는, 해당 액세스 권한에 관련된 1조의 정보는, 더 이상 필요하지 않고, 인가 정보 관리 테이블(900)로부터 삭제될 수 있다. 리프레쉬 처리전의 이전의 액세스 토큰의 유효일시가 만료하지 않은 경우에는, 그 이전의 액세스 토큰이 사용될 가능성이 있으므로, 그 이전의 액세스 토큰에 대응한 인가 관련 정보는 삭제되지 않고 그대로 남긴다. 인가 정보 관리 테이블(900)에 액세스할 때에, 각 토큰의 유효일시가 만료하였는지를 판정하고, 만료하였으면 대응한 토큰을 삭제해도 좋다. 액세스 권한의 인증시, 또는 토큰의 리프레쉬 처리시에, 유효일시를 참조해서 액세스 권한 또는 리프레쉬 권한이 판정되므로, 삭제는 필수적이지 않다. 그러나, 삭제에 의해 기억영역의 효율을 향상시킬 수 있다. 또한, 리프레쉬 토큰이 일단 이용되어서 리프레쉬 처리가 이루어지면, 그 리프레쉬 토큰은 무효화된다.
이하, 도 6a와 도 9에 도시된 인가 정보 관리 테이블의 관계에 대해서 간단하게 설명한다. 외부 서비스 시스템(103), 즉 클라이언트가 관리하는 인가 정보 관리 테이블(600)에는, 하나의 액세스 권한에 관련지어 최신의 액세스 토큰 및 리프레쉬 토큰과 그것의 첫회 리프레쉬 토큰이 클라이언트 인가 관련 정보로서 격납되어 있다. 액세스 관리 서비스 시스템(104), 즉 인가 서버가 관리하는 인가 정보 관리 테이블(900)에는, 하나의 액세스 권한에 관련지어서 유효 액세스 토큰 또는 유효 리프레쉬 토큰을 포함하는 인가 관련 정보 모두가 격납되어 있다. 이 때문에, 적정한 리프레쉬 처리에 의해 토큰이 갱신되어 있는 한은, 최신의 액세스 토큰 및 리프레쉬 토큰에 대해서는, 후술하는 시퀀스에 의해, 외부 서비스 시스템(103)(클라이언트)과 액세스 관리 서비스 시스템(104)(인가 서버)과의 사이에서 동기가 유지되어 있다. 그러나, 리프레쉬 토큰 및 클라이언트 크리덴셜의 누설로 인해 부정한 리프레쉬 처리(재발행 처리 또는 갱신 처리라고도 부른다)가 실행되면, 그 동기가 잃어버려진다.
도 6a 및 도 9에 도시된 인가 정보 관리 테이블은 그 상태를 예시하고 있다. 도 9에 도시된 인가 정보 관리 테이블(900)에는, "EFGH5678"을 첫회 액세스 토큰이라고 하는 액세스 권한에 관련지어서 3조의 인가 정보가 등록되어 있다. 이들 정보 중, 최신의 액세스 토큰은 "MNOP3456"이며, 최신의 리프레쉬 토큰은 "8901IJKL"이고, 첫회 리프레쉬 토큰은 "0123ABCD"이다. 이에 대하여, 도 6a에 도시된 인가 정보 관리 테이블(600)에서는, 첫회 리프레쉬 토큰"0123ABCD"에 대응한 액세스 토큰은 "IJKL9012"이며, 대응한 리프레쉬 토큰은 "4567EFGH"이다. 이것들의 액세스 토큰 및 리프레쉬 토큰이 인가 정보 관리 테이블(900)에도 격납되어 있지만, 그 토큰들은 최신의 것은 아니다. 즉, 동기는 잃어버려져 있다. 이러한 잃어버려진 동기의 원인은, 예를 들면, 상기한 바와 같이, 누설된 리프레쉬 토큰 및 클라이언트 크리덴셜을 사용하여, 원래 무권한의 제3자가 요구한 부정한 리프레쉬 처리등이다.
도 9의 데이터 구조에 격납된 데이터의 처리 상세에 관해서는 후술한다.
<액세스 토큰 발행 처리>
이하, 본 발명에 있어서의 처리 시퀀스에 대해서 흐름도를 참조하여 설명한다.
도 10a 및 10b는, 액세스 관리 서비스 시스템(104)이 발행하고, 외부 서비스 시스템(103)에 대하여 장표 서비스 시스템(105)의 이용을 허가하는데 필요한, 액세스 토큰을 발행하는 액세스 토큰 발행 시퀀스를 나타낸다. 도 10a 및 10b에 있어서, 외부 서비스 시스템(103)과 장표 서비스 시스템(105)은, 다른 서비스 제공자가 운영하고 있는 온라인 서비스 시스템이다. 액세스 관리 서비스 시스템(104)은, 별도의 서비스를 포함하는 유저로부터의 장표 서비스 시스템(105)에의 액세스를 제어한다. 외부 서비스 시스템(103)은, 장표 서비스 시스템(105)이 제공하는 장표 데이터를 이용한 서비스, 예를 들면 인쇄 서비스를 유저에 제공한다.
이 경우에, 외부 서비스 시스템(103)에 대하여 장표 서비스 시스템(105)의 이용을 허가하기 위해서는, 외부 서비스 시스템(103)에 대하여 장표 생성 지시를 내린 유저는, 외부 서비스 시스템(103) 및 장표 서비스 시스템(105)의 양쪽의 유저이어야 한다. 또한, 외부 서비스 시스템(103)은, 장표 서비스 시스템(105)에 대하여 실제로 장표 생성 리퀘스트를 송신한다. 이 때문에, 외부 서비스 시스템(103)은, 장표 서비스 시스템(105)의 유저이어야 한다. 게다가, 장표 생성 지시를 내린 유저의 권한의 범위내에서, 장표 서비스 시스템(105)을 외부 서비스 시스템(103)이 이용할 수 있어야 한다. 보다 구체적으로는, 외부 서비스 시스템(103)에 대하여 서비스를 요구하는 유저는, 외부 서비스 시스템(103)에 대하여 장표 서비스 시스템의 이용을 허가하고, 외부 서비스 시스템(103)에 의한 장표 서비스 시스템(105)의 이용을 인가해야 한다. 또한, 이후의 설명에 있어서, 정보단말(102)을 조작하는 유저를 "유저"라고 한다.
단계S1001에 있어서, 정보단말102A는 웹 브라우저등의 유저 에이전트를 실행하고, 유저A에 의한 조작을 접수하고 있다. 유저A가 정보단말102A를 조작하고, 외부 서비스 시스템(103)에 대하여 장표 생성 지시를 내리면, 그 장표 생성 지시는, 네트워크를 거쳐서 외부 서비스 시스템(103)에서 실행된, 예를 들면, 웹 서비스에 대하여 송신된다. 또한, 정보단말102A와 외부 서비스 시스템(103)은 본 예에서는 ＨＴＴＰ를 거쳐 접속되고, 본 시퀀스에서 설명하는 외부 서비스 시스템(103)에 의한 핵심 처리는 그 백엔드로서 실행된다. 그렇지만, 이후에서는 ＨＴＴＰ의 부분에 관해서는 설명하지 않는다.
단계S1002에 있어서, 외부 서비스 시스템(103)은 정보단말102A로부터 장표 생성 지시를 접수한다. 그 후에, 외부 서비스 시스템(103)은, 장표 서비스 시스템(105)에 대한 액세스 토큰을 인가 정보 관리 테이블(600)에 소유하고 있는지를 확인한다. 만약 외부 서비스 시스템(103)이 장표 서비스 시스템(105)에 대한 액세스 토큰을 소유하고 있는 경우, 액세스 토큰 발행 시퀀스를 종료한다. 외부 서비스 시스템(103)이 장표 서비스 시스템(105)에 대한 액세스 토큰을 소유하지 않고 있는 경우, 외부 서비스 시스템(103)은 단계S1003에 있어서, 액세스 관리 서비스 시스템(104)에 대하여 인가 요구를 송신한다.
단계S1004에 있어서, 액세스 관리 서비스 시스템(104)은 외부 서비스 시스템(103)으로부터의 인가 요구를 접수하면, 유저A에 대하여 인증 처리를 촉진시키는 인증 화면(도면에 나타내지 않는다)을 생성하여, 정보단말102A가 구비하는 웹 브라우저(도면에 나타내지 않는다)에 대하여 그 인증 화면을 송신해서 그 브라우저의 화면에 표시시킨다.
단계S1005에 있어서, 유저A는, 정보단말102A의 웹 브라우저에 표시된 인증 화면에, 유저ID와 패스워드를 인증 정보로서 입력한다. 정보단말102A는, 액세스 관리 서비스 시스템(104)에, 입력된 인증 요구를 보낸다.
단계S1006에 있어서, 액세스 관리 서비스 시스템(104)은 정보단말(102)로부터 인증 요구를 수신하고, 유저ID 및 패스워드를 검증한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은 인증 요구에 포함되는 유저ID와 패스워드의 조합이 인증 데이터 관리부(403)에 격납된 유저 테이블(700)에 등록되어 있는지를 판정한다.
수신한 유저ID와 패스워드의 조합이 유저 테이블(700)에 등록되어 있을 경우에는, 액세스 관리 서비스 시스템(104)은 정보단말(102)을 조작하는 유저A를 장표 서비스 시스템(105)의 유저라고 판단하고, 단계S1009에 진행되어, 처리를 계속한다.
단계S1009에 있어서, 액세스 관리 서비스 시스템(104)은, (후술하는) 인가 화면(1100)을 생성하여, 정보단말(102)이 구비하는 웹 브라우저(도면에 나타내지 않는다)에 송신한다.
단계S1010에 있어서, 정보단말(102)이 구비하는 웹 브라우저는 인가 화면(1100)을 수신해서 표시한다. 유저가 인가 화면(1100)의 인가 버튼(1102)을 누르면, 정보단말102A는 액세스 관리 서비스 시스템(104)에 대하여, 인가 승인을 송신한다.
단계S1011에 있어서, 액세스 관리 서비스 시스템(104)은, 수신한 인가 승인을 기초로 인가 코드를 생성하고, 인가 데이터 관리부(404)에 의해 관리된 인가 코드 테이블(800)에, 인가한 유저ID와 관련지어 격납한다. 한층 더, 액세스 관리 서비스 시스템(104)은, 정보단말102A가 구비하는 웹 브라우저(도면에 나타내지 않는다)를 외부 서비스 시스템(103)에 리다이렉트시켜, 그 생성된 인가 코드를 단계S1003에 있어서의 요구에 대한 응답으로서 외부 서비스 시스템(103)에 회신한다.
단계S1012에 있어서, 외부 서비스 시스템(103)은 수신한 인가 코드를 인가 코드 테이블(610)에 격납한다. 그 후에, 외부 서비스 시스템(103)은 액세스 관리 서비스 시스템(104)에 대하여, 인가 코드와 인증 정보 테이블(620)에 격납되어 있는 클라이언트ID 및 패스워드와 함께 액세스 토큰의 발행 요구인 액세스 토큰 요구를 송신한다.
단계S1013에 있어서, 액세스 관리 서비스 시스템(104)은 액세스 토큰 요구를 수신하고, 외부 서비스 시스템(103)을 인증한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은 액세스 토큰 요구에 포함되는 클라이언트ID와 패스워드의 조합이 인증 데이터 관리부(403)에 격납된 클라이언트 테이블(710)에 등록되어 있는지를 판정한다.
클라이언트ID와 패스워드의 조합이 클라이언트 테이블(710)에 등록되어 있었을 경우에는, 액세스 관리 서비스 시스템(104)은 액세스 토큰 요구를 발행한 외부 서비스 시스템(103)을 장표 서비스 시스템(105)의 유저라고 판단한다. 액세스 관리 서비스 시스템(104)이 외부 서비스 시스템(103)을 인증한 후, 단계S1014에 진행되고, 처리를 계속한다.
단계S1014에 있어서, 액세스 관리 서비스 시스템(104)은 액세스 토큰 요구에 포함되는 인가 코드를 검증한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은 액세스 토큰 요구와 함께 수신한 인가 코드가 인증 데이터 관리부(403)에 격납된 인가 코드 테이블(800)에 등록되어 있는지를 판정한다.
인가 코드가 인가 코드 테이블(800)에 등록되어 있었을 경우에는, 액세스 관리 서비스 시스템(104)은 유저에 의해 장표 서비스 시스템(105)의 이용이 허가되어 있다고 판단하고, 단계S1016에 진행되고, 처리를 계속한다.
단계S1016에 있어서, 액세스 관리 서비스 시스템(104)은, 액세스 토큰 및 리프레쉬 토큰을 생성하고, 인가 데이터 관리부(404)에 의해 관리된 인가 정보 관리 테이블(900)에 그 생성한 토큰을 격납한다. 이 경우에, 액세스 관리 서비스 시스템(104)은 토큰을 생성한 시간을 액세스 토큰 발행 일시(902) 및 리프레쉬 토큰 발행 일시(905)에 설정한다. 또한, 액세스 관리 서비스 시스템(104)은, 액세스 토큰의 유효기간을 액세스 토큰 유효 일시(903)에, 리프레쉬 토큰의 유효기간을 리프레쉬 토큰 유효 일시(906)에 설정한다. 액세스 관리 서비스 시스템(104)은, 유저 정보로서, 검증에 성공한 인가 코드를 발행한 유저ID를 유저ID(907)에 설정한다. 그리고, 액세스 관리 서비스 시스템(104)은, 첫회 리프레쉬 토큰ID(908)에, 최초에 발행된 리프레쉬 토큰 정보를 설정한다.
본 실시예에 있어서, 유저가 최초에 연계 시스템을 이용했을 때에, 액세스 토큰 및 리프레쉬 토큰이 발행된 경우에는, 첫회 리프레쉬 토큰ID(908)에는 해당하는 리프레쉬 토큰이 이용가능하지 않음을 의미하는 "ｎｕｌｌ"을 설정하고 있다. 이때, 첫회 리프레쉬 토큰ID(908)에, 발행한 리프레쉬 토큰 정보로서 리프레쉬 토큰ID(904)와 같은 값을 설정해도 좋다.
그 후에, 액세스 관리 서비스 시스템(104)은, 생성한 액세스 토큰과 리프레쉬 토큰을 단계S1013의 응답으로서 외부 서비스 시스템(103)에 회신한다.
단계S1017에 있어서, 외부 서비스 시스템(103)은 수신한 액세스 토큰 및 리프레쉬 토큰을, 토큰 관리부(305)에 의해 관리된 인가 정보 관리 테이블(600)에 격납한다. 보다 구체적으로는, 외부 서비스 시스템(103)은 수신한 액세스 토큰을 액세스 토큰ID(602)에 설정하고, 수신한 리프레쉬 토큰을 리프레쉬 토큰ID(603) 및 첫회 리프레쉬 토큰ID(604)에 설정한다.
이렇게 해서 발행한 액세스 토큰 및 리프레쉬 토큰을 보존함으로써, 액세스 토큰 발행 시퀀스는 종료한다.
한편, 단계S1006에 있어서, 수신한 유저ID와 패스워드의 조합이 유저 테이블(700)에 등록되지 않고 있을 경우에는, 액세스 관리 서비스 시스템(104)은, 정보단말102A를 조작하는 유저A가 장표 서비스 시스템(105)의 유저가 아니라고 판단한다. 그 후에, 액세스 관리 서비스 시스템(104)은, 외부 서비스 시스템(103)에 대하여, 단계S1004의 응답으로서 인증 에러를 회신한다. 단계S1007에 있어서, 외부 서비스 시스템(103)은 인증 에러를 수신하면, 인증 에러 화면(도면에 나타내지 않는다)을 생성하여, 정보단말102A에 보낸다. 그 후에, 단계1008에 있어서, 정보단말(102)이 구비하는 웹 브라우저(도면에 나타내지 않는다)는 에러 화면을 수신해서 표시시켜, 처리를 종료한다.
한편, 단계S1013에 있어서, 클라이언트ID와 패스워드의 조합이 클라이언트 테이블(710)에 등록되지 않고 있을 경우에는, 액세스 관리 서비스 시스템(104)은, 액세스 토큰 요구를 발행한 외부 서비스 시스템(103)이 장표 서비스 시스템(105)의 유저가 아니라고 판단한다. 그 후에, 액세스 관리 서비스 시스템(104)은, 인증 에러를 외부 서비스 시스템(103)에 송신하고, 단계S1015에 진행된다.
단계S1014에 있어서, 인가 코드가 인가 코드 테이블(800)에 등록되지 않고 있었을 경우에, 액세스 관리 서비스 시스템(104)은, 유저에 의해 장표 서비스의 이용이 허가되지 않고 있다고 판단한다. 그 후에, 액세스 관리 서비스 시스템(104)은, 인가 에러를 외부 서비스 시스템(103)에 송신하고, 단계S1015에 진행된다.
단계S1015에 있어서, 외부 서비스 시스템(103)은, 액세스 관리 서비스 시스템(104)으로부터 인증 에러 혹은 인가 에러를 수신한다. 외부 서비스 시스템(103)은, 수신한 에러에 대응한 인증 에러 화면 혹은 인가 에러 화면(도면에 나타내지 않는다)을 생성하여, 정보단말(102)에 보낸다.
단계1008에 있어서, 정보단말102A는, 수신한 에러 화면을 표시하여, 처리를 종료한다.
이상의 시퀀스에 의해 발행된 액세스 토큰을, 클라이언트, 즉 외부 서비스 시스템(103)에 의해 보존 및 관리하고, 리소스 서버, 즉 장표 서비스 시스템(105)에의 액세스에 사용하므로, 외부 서비스 시스템(103)은, 유저의 크리덴셜의 개시를 받지 않고, 유저의 장표 서비스 시스템(105)에 대한 액세스 권한을 이용할 수 있다.
<화면 예>
도 11은, 액세스 관리 서비스 시스템(104)이 단계S1004에 있어서 생성한 인가 화면을 나타낸 도다. 인가 화면(1100)은, 정보표시영역(1101), 인가 버튼(1102) 및 인가 캔슬 버튼(1103)으로 구성된다. 정보표시영역(1101)은, 인가되는 서비스와, 인가된 서비스가 실행하는 서비스의 정보를 유저에 대하여 나타낸다. 본 실시예에 있어서는, 인가되는 서비스는 외부 서비스 시스템(103)을 가리키고, 인가된 서비스가 실행하는 서비스는 장표 서비스 시스템(105)을 가리킨다. 유저는, 인가를 승인할 때에 인가 버튼(1102)을 누른다. 유저는, 인가를 거부할 때에 인가 캔슬 버튼(1103)을 누른다.
<장표 서비스 시스템에 대한 액세스 시퀀스>
도 12a 및 도 12b는, 유저가 외부 서비스 시스템(103)에 대하여, 장표 서비스 시스템(105)의 이용을 허가할 때 실행된 인가 처리의 시퀀스를 나타낸다. 도 12a 및 도 12b에 도시된 시퀀스는, 도 10a 및 도 10b에 도시된 토큰의 발행 순서와, 또한 장표 서비스 시스템(105)에 대하여 외부 서비스 시스템(103)이 액세스할 때 실행된 시퀀스를 포함한다.
단계S1001과 S1002는 도 10a를 사용하여 설명한 시퀀스와 같다. 또한, 단계S1201은 도 10a 및 도 10b에 있어서의 단계S1003으로부터 S1017까지의 액세스 토큰의 발행 시퀀스를 나타낸다. 도 12a 및 도 12b는 기재상의 편의를 위해 이 단계가 외부 서비스 시스템(103)의 처리로서 나타나 있지만, 실제로는 도 10a 및 도 10b에 기재한 것처럼, 다른 시스템과 연계해서 토큰을 발행하고 있다. 요구된 서비스에 대한 액세스 토큰이 이용가능하지 않으면, 단계S1201에서는 새로운 액세스 토큰이 발행된다.
단계S1202에 있어서, 외부 서비스 시스템(103)은, 인가 정보 관리 테이블(600)에 격납되어 있고 장표 서비스 시스템을 이용하는데 필요한 액세스 토큰을 사용하여, 장표 서비스 시스템(105)에 대하여 장표 생성 요구를 보낸다. 즉, 클라이언트가 리소스 서버에 대하여 서비스를 요구하는데 필요한 액세스 요구를 송신한다. 이때, "이용"이란, 서비스 요구 메시지와 함께, 그 요구에 관련지어 요구원에 인가되어 있는 것을 나타내는 액세스 토큰을 요구처에 송신하는 것이다. 외부 서비스 시스템(103)은, 액세스 토큰 "ＩＪＫＬ9012"를 건네 준다고 가정한다.
단계S1203에 있어서, 장표 서비스 시스템(105)은, 액세스 관리 서비스 시스템(104)에 대하여, 장표 생성 요구와 함께 보내진 액세스 토큰의 검증을 요구한다.
단계S1204에 있어서, 액세스 관리 서비스 시스템(104)은, 수신한 액세스 토큰을 검증한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은, 수신한 액세스 토큰이 인가 정보 관리 테이블(600)에 등록되어 있는지를 판정한다. 그 액세스 토큰이 등록되어 있는 경우에, 액세스 관리 서비스 시스템(104)은 액세스 토큰이 유효기간내인가를 판정한다. 액세스 토큰이 등록되어 있고, 또 유효기간내인 경우에는, 액세스 관리 서비스 시스템(104)은, 액세스 토큰 유효 메시지를 응답으로서 회신한다. 액세스 토큰이 등록되지 않은 경우나, 등록되어 있었지만 유효기간외인 경우에, 액세스 관리 서비스 시스템(104)은 액세스 토큰 무효 메시지를 응답으로서 회신한다. 상기 검증시각이 "2011년 4월 1일 15시"이며, 액세스 토큰 "ＩＪＫＬ9012"가 건네졌다고 가정한다. 이 경우, 인가 정보 관리 테이블(900)에는 액세스 토큰 "ＩＪＫＬ9012"가 등록되어 있지만, 액세스 토큰 유효 일시(903)에 설정되고 있는 시각을 경과하였지만, 액세스 토큰이 무효라고 판단된다.
단계S1205에 있어서, 장표 서비스 시스템(105)은, 액세스 관리 서비스 시스템(104)으로부터 회신된 액세스 토큰 검증 결과를 수신한다. 액세스 토큰이 유효일 경우, 장표 서비스 시스템(105)은, 장표 생성 기능의 액세스를 허가하고, 단계S1206에 진행된다. 액세스 토큰이 무효일 경우, 장표 서비스 시스템(105)은, 외부 서비스 시스템(103)에 대하여, 액세스 토큰 무효 메시지를 단계S1203의 응답으로서 회신하고, 단계S1209에 진행된다.
단계S1206에 있어서, 장표 서비스 시스템(105)은 장표를 생성하고, 생성한 장표 데이터를 단계S1203의 응답으로서 외부 서비스 시스템(103)에 회신한다.
단계S1207에 있어서, 외부 서비스 시스템(103)은 장표 서비스 시스템(105)으로부터 장표 데이터를 수신하여, 정보단말102A에 송신한다.
단계S1208에 있어서, 정보단말102A는, 그 정보단말102A의 웹 브라우저(도면에 나타내지 않는다)에 상기 수신한 장표 데이터를 표시하여서, 장표 생성 지시를 정상적으로 종료한다.
(토큰의 재발행 처리)
단계S1209에 있어서, 외부 서비스 시스템(103)은, 액세스 토큰 무효 메시지를 받으면, 액세스 관리 서비스 시스템(104)에 대하여 리프레쉬 처리의 실행을 요구한다. 보다 구체적으로는, 외부 서비스 시스템(103)은, 인가 정보 관리 테이블(600)에 보존되어 있는 장표 서비스 시스템(105)의 리프레쉬 토큰 및 장표 서비스 시스템(105)에 대한 클라이언트ID 및 패스워드와 함께, 리프레쉬 처리 요구를 액세스 관리 서비스 시스템(104)에 보낸다. 외부 서비스 시스템(103)은, 리프레쉬 토큰 "4567ＥＦＧＨ"을 건네준다고 가정한다.
단계S1210에 있어서, 액세스 관리 서비스 시스템(104)은, 외부 서비스 시스템(103)을 검증한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은, 리프레쉬 처리 요구에 포함된 클라이언트ID와 패스워드의 조합이, 인증 데이터 관리부(403)에 격납된 클라이언트 테이블(710)에 등록되어 있는지를 판정한다.
클라이언트ID와 패스워드의 조합이 클라이언트 테이블(710)에 등록되어 있는 경우에는, 액세스 관리 서비스 시스템(104)은, 장표 서비스 시스템(105)이 외부 서비스 시스템(103)과의 연계를 허가한다고 판단하고, 단계S1213에 진행되고, 처리를 계속한다.
상기 클라이언트ID와 패스워드의 조합이 클라이언트 테이블(710)에 등록되지 않은 경우에, 액세스 관리 서비스 시스템(104)은, 외부 서비스 시스템(103)에 대하여 인증 에러를 회신하고, 단계S1211에 진행된다.
단계S1211에 있어서, 외부 서비스 시스템(103)은 인증 에러를 수신하면, 인증 에러 화면(도면에 나타내지 않는다)을 생성하여, 정보단말102A에 보낸다. 그 후에, 단계1212에 있어서, 정보단말(102)이 구비하는 웹 브라우저(도면에 나타내지 않는다)에 에러 화면을 표시하고, 처리를 종료한다.
단계S1213에 있어서, 액세스 관리 서비스 시스템(104)은, 리프레쉬 처리 요구와 함께 보내진 리프레쉬 토큰을 검증한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은, 수신한 리프레쉬 토큰이 인가 정보 관리 테이블(600)에 등록되어 있는지를 판정한다. 리프레쉬 토큰이 등록되어 있는 경우에, 액세스 관리 서비스 시스템(104)은, 한층 더 리프레쉬 토큰이 유효기간내인가를 판정한다. 수신한 리프레쉬 토큰이 등록되고, 또 유효기간내인 경우에는, 액세스 관리 서비스 시스템(104)은, 리프레쉬 토큰을 유효라고 판단하고, 단계S1214에 진행되고, 처리를 계속한다.
수신한 리프레쉬 토큰이 등록되어 있지 않은 경우, 혹은 그 토큰이 등록되어 있지만 유효기간외인 경우에, 액세스 관리 서비스 시스템(104)은, 리프레쉬 토큰을 무효라고 판단하고, 외부 서비스 시스템(103)에 대하여 토큰 무효 메시지를 응답으로서 회신한다. 그리고, 단계S1217에 진행된다. "2011년 4월 1일 14시 30분"에 리프레쉬 토큰 "4567ＥＦＧＨ"를 수신한다고 가정한다. 이 경우, 비록 인가 정보 관리 테이블(900)에는 리프레쉬 토큰 "4567ＥＦＧＨ"가 등록되어 있지만 리프레쉬 토큰 유효 일시(906)에 설정되고 있는 시각을 경과하였지만, 리프레쉬 토큰이 무효라고 판단된다.
단계S1214에 있어서, 액세스 관리 서비스 시스템(104)은, 새로운 액세스 토큰과 리프레쉬 토큰을 생성하여, 인가 데이터 관리부(404)에 의해 관리된 인가 정보 관리 테이블(900)에 격납한다. 이 경우에, 액세스 관리 서비스 시스템(104)은, 인가 정보 관리 테이블(900)로부터, 단계S1210에서 검증한 리프레쉬 토큰과 관련지어 설정된 첫회 리프레쉬 토큰ID(908)의 값을 취득하여, 새롭게 격납된 토큰의 첫회 리프레쉬 토큰으로서 등록한다. 이때, 첫회 리프레쉬 토큰ID(908)의 값이 "ｎｕｌｌ"인 경우에는, 액세스 관리 서비스 시스템(104)은, 검증에 이용한 리프레쉬 토큰을 첫회 리프레쉬 토큰으로서 등록한다.
단계S1215에 있어서, 액세스 관리 서비스 시스템(104)은, 검증에 이용한 리프레쉬 토큰을 무효로 한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은, 인가 정보 관리 테이블(900)에서의 대응하는 리프레쉬 토큰에 관련지어 리프레쉬 토큰 유효 일시(906)의 값을 리프레쉬 토큰 발행 일시(905)의 값으로 갱신한다. 또한, 본 실시예에서는 리프레쉬 토큰의 유효일시를 갱신함으로써 리프레쉬 토큰을 무효화했지만, 다른 방법으로 리프레쉬 토큰을 무효화해도 된다. 예를 들면, 인가 정보 관리 테이블(900)에 리프레쉬 토큰 유효 플래그의 항목을 정의하고, 그 항목의 값을 갱신함으로써 리프레쉬 토큰을 무효화해도 된다. 그 후에, 액세스 관리 서비스 시스템(104)은, 새롭게 발행한 액세스 토큰 및 리프레쉬 토큰을, 단계S1210의 응답으로서 외부 서비스 시스템(103)에 회신한다.
단계S1216에 있어서, 외부 서비스 시스템(103)은, 인가 정보 관리 테이블(600)에 등록되어 있는, 장표 서비스 시스템(105)의 액세스 토큰 및 리프레쉬 토큰의 값을, 수신한 액세스 토큰 및 리프레쉬 토큰에 의해 갱신한다. 보다 구체적으로는, 외부 서비스 시스템(103)은, 인가 정보 관리 테이블(600)에 등록되어 있는 장표 서비스 시스템의 액세스 토큰ID(602) 및 리프레쉬 토큰ID(603)에, 수신한 액세스 토큰과 리프레쉬 토큰을 각각 설정한다. 이 경우에, 외부 서비스 시스템(103)은, 첫회 리프레쉬 토큰ID(604)을 갱신하지 않는다.
그 후, 단계S1202에 되돌아가고, 외부 서비스 시스템(103)은 다시 장표 생성 요구를 행한다.
단계S1217에 있어서, 외부 서비스 시스템(103)은, 리프레쉬 토큰 무효 응답을 받으면, 인가 정보의 무효화를 요구한다. 보다 구체적으로는, 외부 서비스 시스템(103)은, 인가 정보 관리 테이블(600)에 등록되어 있는 장표 서비스 시스템의 첫회 리프레쉬 토큰의 값을 액세스 관리 서비스 시스템(104)에 보낸다. 외부 서비스 시스템(103)은, 첫회 리프레쉬 토큰의 값으로서 "0123ＡＢＣＤ"를 건네준다고 한다.
단계S1218에 있어서, 액세스 관리 서비스 시스템(104)은, (후술하는) 토큰 무효화 처리를 행한다.
단계S1219에 있어서, 외부 서비스 시스템(103)은, 장표 서비스 시스템(105)의 인가 정보를 삭제한다. 보다 구체적으로는, 외부 서비스 시스템(103)은, 인가 정보 관리 테이블(600)에 등록되어 있는 장표 서비스 시스템(105)의 액세스 토큰ID(602), 리프레쉬 토큰ID(603), 및 첫회 리프레쉬 토큰ID(604)의 값을 삭제한다.
그 후, 단계S1201에 되돌아가서, 외부 서비스 시스템(103)은 다시 액세스 토큰 발행 처리를 실행한다.
(액세스 토큰의 무효화 처리)
단계S1217에 있어서, 외부 서비스 시스템(103)은, 본 실시예의 특징적 특징으로서 첫회 리프레쉬 토큰을 이용한 리프레쉬 토큰의 무효화 처리의 실행을 액세스 관리 서비스 시스템(104)에 대하여 요구한다. 이 경우에, 외부 서비스 시스템(103)은, 무효화 처리 요구와 함께, 토큰이 인가 정보 관리 테이블(600)에 등록된, 장표 서비스 시스템(105)에 대한 첫회 리프레쉬 토큰을 송신한다. 무효화 처리 요구를 수신한 액세스 관리 서비스 시스템(104)은, 단계S1218에 있어서, 첫회 리프레쉬 토큰으로서 등록된 상기 수신한 리프레쉬 토큰의 리프레쉬 토큰 무효화 처리를 실행한다. 이 처리의 상세는 도 13을 참조해서 후술한다. 리프레쉬 토큰의 무효화 처리를 완료한 후, 액세스 관리 서비스 시스템(104)은, 무효화 완료 응답을 외부 서비스 시스템(103)에 회신한다. 응답을 수신한 외부 서비스 시스템(103)은, 단계S1219에 있어서, 무효화된 리프레쉬 토큰을 포함하는 클라이언트 인가 관련 정보를 인가 정보 관리 테이블(600)로부터 삭제한다. 또한, 단계S1219의 시점에서는, 액세스 토큰은 이미 무효화되어 있다. 그 후, 단계S1201에 되돌아가고, 외부 서비스 시스템(103)은 액세스 토큰 및 리프레쉬 토큰을 다시 발행하는 처리를 실행한다. 본 예에서는 이러한 송신이 불필요하지만, 외부 서비스 시스템(103)은, 리프레쉬 처리 요구와 같이, 장표 서비스 시스템(105)에 대한 클라이언트ID와 패스워드와의 조를 함께 송신하여도 좋다. 이 경우에, 액세스 관리 서비스 시스템(104)은, 단계S1218의 직전에, 단계S1210과 같이 권한을 인증한다. 인증이 성공했다면, 액세스 관리 서비스 시스템(104)은, 단계S1218에서 리프레쉬 토큰을 무효화한다.
<리프레쉬 토큰 무효화 처리 시퀀스>
도 13은, 제1실시예에 따른 리프레쉬 토큰의 무효화 처리, 즉 도 12b의 단계S1218의 상세한 시퀀스를 나타낸다.
단계S1301에 있어서, 액세스 관리 서비스 시스템(104)은, 리프레쉬 토큰의 무효화 요구와 함께, 리프레쉬 토큰을 접수한다. 리프레쉬 토큰 "0123ＡＢＣＤ"가 건네졌다고 가정한다.
단계S1302에 있어서, 액세스 관리 서비스 시스템(104)은, 수신한 리프레쉬 토큰인 첫회 리프레쉬 토큰인 모든 리프레쉬 토큰을 무효로 한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은, 인가 정보 관리 테이블(900)의 첫회 리프레쉬 토큰ID(908)에 등록된 상기 수신한 리프레쉬 토큰을 무효화한다. 예를 들면, 무효화는, 리프레쉬 토큰 유효 일시(906)의 값을 리프레쉬 토큰 발행 일시(905)의 값으로 갱신하는 것으로 행한다. 현재의 예에서, 첫회 리프레쉬 토큰ID(908)의 값 "0123ＡＢＣＤ"에 대응한 리프레쉬 토큰 "4567ＥＦＧＨ"와 "8901ＩＪＫＬ"이 대상으로서 선택된다. 그렇지만, 리프레쉬 토큰 "4567ＥＦＧＨ"가 이미 무효화되었기 때문에, 리프레쉬 토큰 "8901ＩＪＫＬ"만이 무효화된다.
단계S1303에 있어서, 액세스 관리 서비스 시스템(104)은, 수신한 리프레쉬 토큰을 무효로 한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은, 인가 정보 관리 테이블(900)에서의 대응한 리프레쉬 토큰에 관련지어, 리프레쉬 토큰 유효 일시(906)의 값을 리프레쉬 토큰 발행 일시(905)의 값으로 갱신한다. 또한, 최초에 액세스 토큰과 리프레쉬 토큰을 발행하고, 그 발행한 리프레쉬 토큰을 첫회 리프레쉬 토큰으로서 등록하고 있는 경우에는, 단계S1302에 있어서 해당 리프레쉬 토큰도 무효로 하므로, 본 단계는 생략해도 좋다. 또한, 첫회 리프레쉬 토큰 "ｎｕｌｌ"에 해당한 리프레쉬 토큰을 무효화하는 시퀀스는, ＯＡｕｔｈ에서 정의되어 있는 종래의 무효화 방식이다. 현재의 예에서, 리프레쉬 토큰 "0123ＡＢＣＤ"가 대상으로서 선택된다. 그렇지만, 리프레쉬 토큰 "0123ＡＢＣＤ"는 이미 무효화되어 있으므로, 본 단계에서는 리프레쉬 토큰이 무효화되지 않는다.
또한, 수신한 리프레쉬 토큰이, 인가 정보 관리 테이블(900)에서 어느 첫회 리프레쉬 토큰에도 해당하지 않을 경우에는, 단계S1302에서는 아무것도 실행하지 않는다. 이렇게 하여, 종래의 ＯＡｕｔｈ의 시퀀스에서 무효화 요구를 발행하는 클라이언트와의 호환성을 유지할 수 있다.
이것들의 처리에 의해, 최초에 발행된 리프레쉬 토큰에 의거한 일련의 리프레쉬 처리에 의해 발행된 모든 리프레쉬 토큰은 무효화된다.
(본 실시예의 효과)
리프레쉬 토큰은, 2개의 패턴, 즉 리프레쉬 처리가 되지 않고 유효기한이 경과하였을 경우와, 리프레쉬 처리가 행해져서 새로운 리프레쉬 토큰의 발행 결과로서 해당 리프레쉬 토큰이 무효화되었을 경우에, 무효이다.
외부 서비스 시스템(103)이 최신의 리프레쉬 토큰을 기억하므로, 리프레쉬 처리 없이 유효기한이 경과하였을 경우에는, 장표 서비스 시스템의 모든 리프레쉬 토큰이 무효이어야 한다. 이 때문에, 장표 서비스 시스템의 모든 리프레쉬 토큰이 무효인 경우에도, 그 시스템에 영향은 주지 않는다.
한편, 리프레쉬 처리의 결과로서 리프레쉬 토큰이 무효인 경우에는, 외부 서비스 시스템(103)에 대한 미지의 리프레쉬 처리가 실행된다. 예를 들면, 부정한 외부 서비스 시스템(도면에 나타내지 않는다)이 이러한 경우에 리프레쉬 처리를 실행한다. 이 경우, 부정한 외부 서비스 시스템이, 외부 서비스 시스템(103) 대신에 장표 서비스 시스템(105)을 이용할 가능성이 있다. 이러한 경우에도, 본 실시예에 따른 리프레쉬 토큰의 무효화를 행함으로써, 부정으로 발행한 리프레쉬 토큰도 무효화된다. 이 때문에, 무효화 처리후의 부정한 외부 서비스 시스템에 의한 리프레쉬 처리를 방지할 수 있다. 따라서, 장표 서비스가 부정한 외부 서비스 시스템에 의해, 계속적으로 부정으로 이용되는 것을 막을 수 있다.
[제2실시예]
다음에, 본 발명을 실시하는데 필요한 제2실시예에 대해서 도면을 참조하여 설명한다. 제1실시예에 있어서는, 최초에 발행된 리프레쉬 토큰에 의거하여 일련의 리프레쉬 처리로 발행되어 있는 모든 리프레쉬 토큰을 무효화 한다.
본 실시예에서는 리프레쉬 토큰을 무효화 할 때에, 함께 액세스 토큰을 무효화함으로써 상기 제1실시예에 있어서의 부정한 외부 서비스 시스템에 의한 스푸핑(spoofing) 즉시 막는 방법을 설명한다. 또한, 본 실시예에 있어서는, 제1실시예와 동일부분에 관한 설명은 생략하고, 그 차이에 대해서만 설명한다. 이때, 그 차이는 도 13의 시퀀스를 도 14의 시퀀스로 치환한 것이며, 이하 그 시퀀스의 실제의 예에 대해서 설명한다.
<무효화 처리 시퀀스>
도 14는, 제2실시예에 따른 인가 정보 무효화 처리의 시퀀스를 나타낸다. 단계S1301 내지 S1303은 도 13과 같다.
단계S1401에 있어서, 액세스 관리 서비스 시스템(104)은, 단계S1302 및 S1303에 있어서 무효로 된 리프레쉬 토큰에 대응하는 액세스 토큰을 무효화 한다. 보다 구체적으로는, 액세스 관리 서비스 시스템(104)은, 무효화된 리프레쉬 토큰이 인가 정보 관리 테이블(900)에 등록된 데이터에 관련지어 액세스 토큰 유효 일시(903)의 값을 액세스 토큰 발행 일시(902)의 값으로 갱신한다. 또한, 액세스 토큰의 유효일시를 갱신함으로써 무효화를 행했지만, 다른 방법으로 실시해도 좋다. 예를 들면, 인가 정보 관리 테이블(900)에 액세스 토큰 유효 플래그의 항목을 정의하고, 그 항목의 값을 갱신함으로써 무효화를 실시해도 된다. 단계S1301에 있어서, "2011년 4월 1일 14시30분"에 리프레쉬 토큰 "0123ＡＢＣＤ"가 건네준다고 가정한다. 이 경우, 리프레쉬 토큰 "0123ＡＢＣＤ", "4567ＥＦＧＨ" 및 "8901ＩＪＫＬ"이 무효화 대상으로서 선택된다. 이 때문에, 액세스 토큰 "ＥＦＧＨ5678", "ＩＪＫＬ9012" 및 "ＭＮＯＰ3456"이 무효화된다. 그렇지만, 액세스 토큰 "ＥＦＧＨ5678" 및 "ＩＪＫＬ9012"는 이미 무효되었기 때문에, 액세스 토큰 "ＭＮＯＰ3456"만이 무효화된다.
이것들의 처리에 의해, 최초에 발행된 리프레쉬 토큰을 바탕으로 실행된 리프레쉬 처리에 의해 발행된, 모든 리프레쉬 토큰 및 모든 액세스 토큰이 무효화된다.
제1실시예에 기재된 방법으로 리프레쉬 토큰을 무효화함으로써, 부정한 외부 서비스 시스템으로부터의 리프레쉬 처리를 막을 수 있다. 한층 더, 제2실시예에 기재된 방법에 의해, 액세스 토큰도 무효화될 수 있다. 이에 따라, 부정한 외부 서비스 시스템에 의해 리프레쉬 처리가 행해지고, 장표 서비스가 부정으로 이용되었을 경우에도, 부정한 외부 서비스 시스템으로부터의 장표 서비스의 이용을 즉시 정지시킬 수 있다.
또한, 본 실시예에 따른 발명을 실시한 인가 서버는, 본 실시예에 따른 발명을 실시한 클라이언트를 지원할뿐만 아니라, 종래의 ＯＡｕｔｈ프로토콜을 실시한 클라이언트와의 호환성도 유지할 수 있다.
[기타의 실시예]
또한, 본 발명의 국면들은, 메모리 디바이스에 기록된 프로그램을 판독 및 실행하여 상기 실시예(들)의 기능들을 수행하는 시스템 또는 장치(또는 CPU 또는 MPU 등의 디바이스들)의 컴퓨터에 의해서, 또한, 시스템 또는 장치의 컴퓨터에 의해 수행된 단계들, 예를 들면, 메모리 디바이스에 기록된 프로그램을 판독 및 실행하여 상기 실시예(들)의 기능들을 수행하는 방법에 의해, 실현될 수도 있다. 이를 위해, 상기 프로그램은, 예를 들면, 네트워크를 통해 또는, 여러 가지 형태의 메모리 디바이스의 기록매체(예를 들면, 컴퓨터 판독 가능한 매체)로부터, 상기 컴퓨터에 제공된다.
본 발명을 예시적 실시예들을 참조하여 기재하였지만, 본 발명은 상기 개시된 예시적 실시예들에 한정되지 않는다는 것을 알 것이다. 아래의 청구항의 범위는, 모든 변형예, 동등한 구조 및 기능을 포함하도록 폭 넓게 해석해야 한다.
본 출원은, 여기서 전체적으로 참고로 포함된, 2012년 5월 25일에 제출된 일본국 특허출원번호 2012-120140의 이점을 청구한다.

Claims (10)

  1. 클라이언트 장치로부터 리소스 서버에의 액세스 요구를, 상기 요구와 관련지어서 상기 클라이언트 장치로부터 수신한 유효 인가 정보에 의거하여 인가하는 인가 서버로서,
    인증 정보와 함께 상기 클라이언트 장치로부터 수신한 발행 요구에 따라, 리소스 서버에 액세스하기 위해서 이용되는 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보를, 발행하는 발행 수단;
    갱신 인가 정보와 함께 수신한 리프레쉬 처리 요구에 따라, 새로운 갱신 인가 정보 및 새로운 인가 정보를 재발행하고, 재발행된 인가 정보 및 갱신 인가 정보에 관련지어, 새로운 갱신 인가 정보 및 인가 정보를 재발행하기 위해서 상기 발행 수단에 의해 발행한 갱신 인가 정보를 첫회 갱신 인가 정보로서 기억하는 재발행 수단; 및
    갱신 인가 정보와 함께 수신한 무효화 요구에 따라, 상기 무효화 요구와 함께 수신한 상기 갱신 인가 정보가 상기 첫회 갱신 인가 정보로서 관련된 갱신 인가 정보를 무효화하는 무효화 수단을 구비하는, 인가 서버.
  2. 제 1 항에 있어서,
    상기 무효화 수단은, 상기 무효화 요구와 함께 수신한 상기 갱신 인가 정보도 더 무효화하는, 인가 서버.
  3. 제 1 항에 있어서,
    상기 무효화 수단은, 상기 무효화 요구와 함께 수신한 갱신 인가 정보가 첫회 갱신 인가 정보로서 관련된 갱신 인가 정보에 더해서, 상기 무효화 요구와 함께 수신한 갱신 인가 정보가 첫회 갱신 인가 정보로서 관련된 인가 정보를 무효화하는, 인가 서버.
  4. 제 1 항에 있어서,
    상기 재발행 수단은, 새로운 인가 정보를 재발행했을 경우, 리프레쉬 처리 요구와 함께 수신한 갱신 인가 정보를 무효화하는, 인가 서버.
  5. 리소스 서버에 대하여, 인가 서버에 의해 발행된 인가 정보와 함께 액세스 요구를 송신해서 상기 리소스 서버에 의한 서비스를 요구하는 클라이언트 장치로서,
    상기 인가 서버에 의해 발행된 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보와, 상기 인가 정보를 재발행하기 위해서 상기 인가 서버가 최초에 발행한 첫회 갱신 인가 정보를 서로 관련시켜 기억하는 수단; 및
    기억된 상기 첫회 갱신 인가 정보와 함께 무효화 요구를 상기 인가 서버에 송신하고, 상기 첫회 갱신 인가 정보에 관련된 갱신 인가 정보의 무효화를 요구하는 무효화 요구 수단을 구비하는, 클라이언트 장치.
  6. 제 5 항에 있어서,
    액세스 요구에 따라, 상기 인가 정보가 무효라는 것을 가리키는 응답을 수신했을 경우, 상기 인가 정보가 무효라는 것을 가리키는 상기 응답에 대응하는 상기 인가 정보에 관련된 갱신 인가 정보와 함께, 리프레쉬 처리 요구를 상기 인가 서버에 대하여 송신하는 수단을 더 구비하고,
    상기 리프레쉬 처리 요구에 따라, 상기 갱신 인가 정보가 무효라는 것을 가리키는 응답이 수신되었을 경우에, 상기 무효화 요구 수단은 갱신 인가 정보의 무효화를 요구하는, 클라이언트 장치.
  7. 클라이언트 장치로부터 리소스 서버에의 액세스 요구를, 상기 요구와 관련지어서 상기 클라이언트 장치로부터 수신한 유효 인가 정보에 의거하여 인가하는 인가 서버와, 리소스 서버에 대하여, 인가 서버에 의해 발행된 인가 정보와 함께 액세스 요구를 송신해서 상기 리소스 서버에 의한 서비스를 요구하는 클라이언트 장치와, 상기 클라이언트 장치에 대하여 서비스를 제공하는 상기 리소스 서버를 포함하는 서버 연계 시스템으로서,
    상기 인가 서버는,
    인증 정보와 함께 상기 클라이언트 장치로부터 수신한 발행 요구에 따라, 리소스 서버에 액세스하기 위해서 이용되는 인가 정보와, 새로운 인가 정보를 상기 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보를 발행하는 발행 수단;
    갱신 인가 정보와 함께 수신한 리프레쉬 처리 요구에 따라, 새로운 갱신 인가 정보 및 새로운 인가 정보를 재발행하고, 재발행된 인가 정보 및 갱신 인가 정보에 관련지어서, 새로운 갱신 인가 정보 및 인가 정보를 재발행하기 위해서 상기 발행 수단에 의해 발행한 갱신 인가 정보를 첫회 갱신 인가 정보로서 기억하는 재발행 수단; 및
    갱신 인가 정보와 함께 수신한 무효화 요구에 따라, 상기 무효화 요구와 함께 수신한 상기 갱신 인가 정보가 첫회 갱신 인가 정보로서 관련되어 있는 갱신 인가 정보를 무효화하는 무효화 수단을 구비하고,
    상기 클라이언트 장치는,
    상기 인가 서버에 의해 발행된 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보와, 상기 인가 정보를 재발행하기 위해서 상기 인가 서버가 최초에 발행한 첫회 갱신 인가 정보를 서로 관련시켜 기억하는 수단; 및
    기억된 상기 첫회 갱신 인가 정보와 함께 무효화 요구를 상기 인가 서버에 송신하고, 상기 첫회 갱신 인가 정보에 관련된 갱신 인가 정보의 무효화를 요구하는 무효화 요구 수단을 구비하는, 서버 연계 시스템.
  8. 클라이언트 장치로부터 리소스 서버에의 액세스 요구를, 상기 요구와 관련지어서 상기 클라이언트 장치로부터 수신한 유효 인가 정보에 의거하여 인가하는 인가 서버로서 컴퓨터를 기능시키기 위한 프로그램을 기억하는 컴퓨터 판독 가능한 기록매체로서,
    인증 정보와 함께 상기 클라이언트 장치로부터 수신한 발행 요구에 따라, 리소스 서버에 액세스하기 위해서 이용되는 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보를, 발행하는 발행 수단;
    갱신 인가 정보와 함께 수신한 리프레쉬 처리 요구에 따라, 새로운 갱신 인가 정보 및 새로운 인가 정보를 재발행하고, 재발행된 인가 정보 및 갱신 인가 정보에 관련지어, 새로운 갱신 인가 정보 및 인가 정보를 재발행하기 위해서 상기 발행 수단에 의해 발행한 갱신 인가 정보를 첫회 갱신 인가 정보로서 기억하는 재발행 수단; 및
    갱신 인가 정보와 함께 수신한 무효화 요구에 따라, 상기 무효화 요구와 함께 수신한 상기 갱신 인가 정보가 첫회 갱신 인가 정보로서 관련된 갱신 인가 정보를 무효화하는 무효화 수단으로서 상기 컴퓨터를 기능시키기 위한 프로그램을 기억하는, 컴퓨터 판독 가능한 기록매체.
  9. 리소스 서버에 대하여, 인가 서버에 의해 발행된 인가 정보와 함께 액세스 요구를 송신해서 상기 리소스 서버에 의한 서비스를 요구하는 클라이언트 장치로서 컴퓨터를 기능시키기 위한 프로그램을 기억하는 컴퓨터 판독 가능한 기록매체로서,
    상기 인가 서버에 의해 발행된 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보와, 상기 인가 정보를 재발행하기 위해서 상기 인가 서버가 최초에 발행한 첫회 갱신 인가 정보를 서로 관련시켜 기억하는 수단; 및
    기억된 상기 첫회 갱신 인가 정보와 함께 무효화 요구를 상기 인가 서버에 송신하고, 상기 첫회 갱신 인가 정보에 관련된 갱신 인가 정보의 무효화를 요구하는 무효화 요구 수단으로서 상기 컴퓨터를 기능시키기 위한 프로그램을 기억하는, 컴퓨터 판독 가능한 기록매체.
  10. 클라이언트 장치로부터 리소스 서버에의 액세스 요구를, 상기 요구와 관련지어서 상기 클라이언트 장치로부터 수신한 유효 인가 정보에 의거하여 인가하는 인가 서버와, 상기 리소스 서버에 대하여, 상기 인가 서버에 의해 발행된 인가 정보와 함께 액세스 요구를 송신해서 상기 리소스 서버에 의한 서비스를 요구하는 클라이언트 장치와, 상기 클라이언트 장치에 대하여 서비스를 제공하는 상기 리소스 서버를 가지는 서버 연계 시스템에 있어서의 토큰 관리 방법으로서,
    상기 인가 서버가, 인증 정보와 함께 클라이언트 장치로부터 수신한 발행 요구에 따라, 리소스 서버에 액세스하기 위해서 이용되는 인가 정보와, 새로운 인가 정보를 상기 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보를 발행하는 발행 단계;
    상기 클라이언트 장치가, 상기 인가 서버에 의해 발행된 인가 정보와, 새로운 인가 정보를 인증 정보 없이 재발행하기 위해서 이용되는 갱신 인가 정보와, 상기 인가 정보를 재발행하기 위해서 상기 인가 서버가 최초에 발행한 첫회 갱신 인가 정보를 서로 관련시켜 기억하는 단계;
    상기 클라이언트 장치가, 액세스 요구에 따라 상기 인가 정보가 무효라는 것을 나타내는 응답을 수신했을 경우, 상기 인가 정보가 무효라는 것을 나타내는 상기 응답에 대응한 상기 인가 정보에 관련된 갱신 인가 정보와 함께 리프레쉬 처리 요구를 상기 인가 서버에 대하여 송신하는 단계;
    상기 인가 서버가, 갱신 인가 정보와 함께 수신한 리프레쉬 처리 요구에 따라, 새로운 갱신 인가 정보 및 새로운 인가 정보를 재발행하고, 재발행된 인가 정보 및 갱신 인가 정보에 관련지어, 새로운 갱신 인가 정보 및 인가 정보를 재발행하기 위해서 상기 발행 단계에서 발행한 상기 갱신 인가 정보를 첫회 갱신 인가 정보로서 기억하는 재발행 단계;
    상기 클라이언트 장치가, 기억된 상기 첫회 갱신 인가 정보와 함께 무효화 요구를 상기 인가 서버에 송신하고, 상기 첫회 갱신 인가 정보에 관련된 갱신 인가 정보의 무효화를 요구하는 무효화 요구 단계; 및
    상기 인가 서버가, 갱신 인가 정보와 함께 수신한 무효화 요구에 따라, 상기 무효화 요구와 함께 수신한 상기 갱신 인가 정보가 첫회 갱신 인가 정보로서 관련된 갱신 인가 정보를 무효화하는 무효화 단계를 포함하는, 토큰 관리 방법.
KR1020147035695A 2012-05-25 2013-04-10 인가 서버 및 클라이언트 장치, 서버 연계 시스템, 및 토큰 관리 방법 KR101640383B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2012120140A JP6006533B2 (ja) 2012-05-25 2012-05-25 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法
JPJP-P-2012-120140 2012-05-25
PCT/JP2013/061344 WO2013175901A1 (en) 2012-05-25 2013-04-10 Authorization server and client apparatus, server cooperative system, and token management method

Publications (2)

Publication Number Publication Date
KR20150013855A KR20150013855A (ko) 2015-02-05
KR101640383B1 true KR101640383B1 (ko) 2016-07-18

Family

ID=49623602

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147035695A KR101640383B1 (ko) 2012-05-25 2013-04-10 인가 서버 및 클라이언트 장치, 서버 연계 시스템, 및 토큰 관리 방법

Country Status (5)

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

Families Citing this family (67)

* 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 (ko) * 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 삼성전자주식회사 스마트 홈 서비스에서 기기 등록을 위한 접속 정보 관리 방법 및 장치
JP6454076B2 (ja) * 2014-03-20 2019-01-16 キヤノン株式会社 中継装置、通信装置、それらの制御方法、システム、及びプログラム
JP6346478B2 (ja) * 2014-03-20 2018-06-20 キヤノン株式会社 中継装置、中継方法、中継システム、及びプログラム
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
WO2016164000A1 (en) * 2015-04-07 2016-10-13 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 キヤノン株式会社 サーバーシステム、サーバーシステムの制御方法、およびプログラム
US10498738B2 (en) * 2015-06-07 2019-12-03 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
KR102424055B1 (ko) * 2015-12-08 2022-07-25 한국전자통신연구원 두 개의 ａｐｉ 토큰을 이용한 ａｐｉ 인증 장치 및 방법
JP6677496B2 (ja) * 2015-12-08 2020-04-08 キヤノン株式会社 認証連携システム及び認証連携方法、認可サーバー、アプリケーションサーバー及びプログラム
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 システムメトリックス株式会社 認証システム
US10187421B2 (en) * 2016-06-06 2019-01-22 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
CN114706634A (zh) 2018-01-15 2022-07-05 华为技术有限公司 一种系统、程序以及计算机可读存储介质
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广东移动通信有限公司 请求处理方法、装置、设备及存储介质
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协议的授权方法、装置、系统及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8800009B1 (en) 2011-12-30 2014-08-05 Google Inc. Virtual machine service access

Family Cites Families (10)

* 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
ES2853200T3 (es) 2009-05-29 2021-09-15 Alcatel Lucent Sistema y procedimiento para acceder a contenido digital privado
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协议的开放平台安全认证方法和系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8800009B1 (en) 2011-12-30 2014-08-05 Google Inc. Virtual machine service access

Also Published As

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

Similar Documents

Publication Publication Date Title
KR101640383B1 (ko) 인가 서버 및 클라이언트 장치, 서버 연계 시스템, 및 토큰 관리 방법
JP5458888B2 (ja) 証明書生成配布システム、証明書生成配布方法およびプログラム
JP6643373B2 (ja) 情報処理システムと、その制御方法とプログラム
JP6061633B2 (ja) デバイス装置、制御方法、およびそのプログラム。
CN102265255B (zh) 通过凭证的逐步到期来提供联合认证服务的系统和方法
JP6141076B2 (ja) システムおよびその制御方法、アクセス管理サービスシステムおよびその制御方法、並びにプログラム
JP5604176B2 (ja) 認証連携装置およびそのプログラム、機器認証装置およびそのプログラム、ならびに、認証連携システム
US8499147B2 (en) Account management system, root-account management apparatus, derived-account management apparatus, and program
US20150119019A1 (en) Method and Device for Control of a Lock Mechanism Using a Mobile Terminal
JP5170648B2 (ja) 権限委譲システム、権限委譲方法および権限委譲プログラム
KR100561629B1 (ko) 보안 정보 통합 관리 시스템 및 그 방법
JP2007110377A (ja) ネットワークシステム
KR102651448B1 (ko) 블록 체인 기반 탈중앙화 인가 프로토콜 방법 및 장치
JP2015133034A (ja) 情報処理システム及び認証方法
KR20080019362A (ko) 대체 가능한 지역 도메인 관리 시스템 및 방법
EP4240245A1 (en) Method for suspending protection of an object achieved by a protection device
JP5036500B2 (ja) 属性証明書管理方法及び装置
JP2008129673A (ja) ユーザ認証システム、ユーザ認証方法、それに用いるゲートウェイ及びプログラムとその記録媒体
JP7043480B2 (ja) 情報処理システムと、その制御方法とプログラム
US20090327725A1 (en) Content object management method, right object providing method, content object revocation method based thereon, and device using the same
JP2004171524A (ja) サービス提供装置、サービス提供方法、サービス提供プログラム及び記録媒体
Wich et al. Towards secure and standard-compliant implementations of the PSD2 Directive
JP6128958B2 (ja) 情報処理サーバーシステム、制御方法、およびプログラム
KR102497440B1 (ko) Did 기반의 사용자 정보 관리 서비스 제공 방법 및 시스템
JP6053205B2 (ja) 情報流通システム、方法および処理プログラム

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20190710

Year of fee payment: 4