KR102313859B1 - 권한 위양 시스템, 그 제어 방법 및 클라이언트 - Google Patents

권한 위양 시스템, 그 제어 방법 및 클라이언트 Download PDF

Info

Publication number
KR102313859B1
KR102313859B1 KR1020180102419A KR20180102419A KR102313859B1 KR 102313859 B1 KR102313859 B1 KR 102313859B1 KR 1020180102419 A KR1020180102419 A KR 1020180102419A KR 20180102419 A KR20180102419 A KR 20180102419A KR 102313859 B1 KR102313859 B1 KR 102313859B1
Authority
KR
South Korea
Prior art keywords
client
authorization
authorization code
user
server
Prior art date
Application number
KR1020180102419A
Other languages
English (en)
Other versions
KR20190024817A (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 KR20190024817A publication Critical patent/KR20190024817A/ko
Application granted granted Critical
Publication of KR102313859B1 publication Critical patent/KR102313859B1/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/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/45—Structures or tools for the administration of authentication
    • 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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
    • 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
    • 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/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G06F21/608—Secure printing
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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
    • 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/3247—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 digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Power Engineering (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

인가 코드 응답이 클라이언트로 송신되고, 클라이언트는 인가 코드 응답에 포함되는 파라미터와, 송신 유닛에 의해 송신된 인가 코드 응답에 포함되는 파라미터를 사용하여, 인가 코드 응답이 인가 코드 요구에 대응하는 것을 검증한다.

Description

권한 위양 시스템, 그 제어 방법 및 클라이언트{AUTHORITY TRANSFER SYSTEM, CONTROL METHOD THEREFOR, AND CLIENT}
본 개시내용은 웹 서비스로의 액세스 권한을 검증하는 권한 위양 시스템, 그 제어 방법 및 클라이언트에 관한 것이다.
개개의 웹 서버는 웹 서비스를 제공하기 위해 개방 API(Application Programming Interface)를 제공하고, 웹 서비스들은 개방 API를 통해 서로 제휴할 수 있다. 이 경우에 보안의 관점에서, 하나의 웹 서비스가 관리하는 사용자의 인증 정보를 핸드오버하지 않고서, 다른 웹 서비스에 의해 하나의 웹 서비스로의 액세스를 인가하기 위한 조치가 요구될 수 있다.
그러한 조치를 달성하기 위해, 웹 서비스들 사이의 제휴를 구현하기 위해 표준 프로토콜(OAuth 2.0)이 채택된다. OAuth 2.0은, 사용자의 인증 정보를 그 사용자의 동의에 의해 웹 서비스들 사이에서 안전하게 핸드오버(또는 위양)하기 위한 메커니즘이고, 그 상세는 후술될 것이다.
OAuth 2.0에 따르면, 사용자가 인가 조작을 수행할 때, 웹 서비스 B는 인가 코드를 수신한다. 인가 코드는 웹 서비스 A로의 액세스가 사용자에 의해 인가된 것을 증명하기 위한 코드이다. 수신한 인가 코드와, 웹 서비스 B를 증명하기 위한 정보를 사용하여, 웹 서비스 B는 웹 서비스 A에 대하여 인가 토큰의 발행 요구를 송신한다. 인가 토큰은, 웹 서비스 A가 제공하는 개방 API에 웹 서비스 B가 액세스하는 것을 인가하기 위한 토큰이다. 웹 서비스 B가 인가 토큰을 수신하고, 따라서 웹 서비스 B가 웹 서비스 A의 API에 액세스하는 것이 인가된다. 웹 서비스 B를 증명하기 위한 정보는, 웹 서비스 B를 고유하게 식별하기 위한 ID, 은닉 정보인 시크릿, 또는 디지털 증명서에 의한 디지털 서명일 수 있다.
본 명세서에서, "권한 위양"이라는 용어는, 사용자에 의해 수행되는 인가 조작에 의해 웹 서비스 B가 웹 서비스 A의 API에 액세스하는 것을 인가하는 것을 지칭한다. OAuth 2.0에서는, 사용자에 의해 수행되는 인가 조작에 응답하여 인가 코드를 발행하고, 인가 코드로부터 인가 토큰을 발행하도록 구성되는 서버를 인가 서버로서 지칭한다. 개방 API를 제공하도록 구성되는 서버를 리소스 서버로서 지칭하고, 개방 API에 액세스하는 주체를 클라이언트로서 지칭한다. 전술한 예에서, 웹 서비스 A를 제공하는 서버가 인가 서버 및 리소스 서버에 대응하고, 웹 서비스 B를 제공하는 서버가 클라이언트에 대응한다.
도 1을 참조하여, OAuth 2.0에 따른 처리 플로우인 인가 코드 승인(Authorization Code Grant)을 설명할 것이다. 먼저, OAuth 2.0을 구현하기 위한 사전 조작으로서, 인가 서버에 클라이언트를 OAuth 2.0 클라이언트로서 등록하기 위한 등록 요구가 송신된다(S0.0). 더 구체적으로는, 클라이언트의 기동 시, 또는 후술하는 S1.1의 인가 플로우의 개시 시에 클라이언트가 미등록된 경우에, 클라이언트 등록 요구가 인가 서버의 등록 엔드 포인트(도 1에서는 "EP")에 대하여 송신된다. 등록 요구의 송신은, 예를 들어, 클라이언트가 능동적으로 인가 서버와 통신하는 것에 의해, 또는 사용자가 웹 브라우저를 통해 인가 서버에 액세스하고 클라이언트를 등록하는 것에 의해 수행될 수 있다.
S0.0에서의 등록 요구는, 후술하는 인가 확인 화면에 표시되는 클라이언트명, 설명, 아이콘 화상 및 필수 파라미터인 리다이렉트 URI(Uniform Resource Identifier)를 포함한다. 리다이렉트 URI는, 인가 서버로부터의 인가 코드 응답을 클라이언트가 수신하기 위해, 인가 서버가 인가 코드 응답을 송신하는 응답처를 지정하는 응답처 정보(어드레스)이다. 인가 코드 응답이 후술될 것이다. 클라이언트 등록 요구를 수신한 인가 서버는 클라이언트를 식별하는 클라이언트 ID와, 클라이언트를 인증하는 은닉 정보인 클라이언트 시크릿을 발행하고, 클라이언트 등록 응답으로서 클라이언트 ID 및 클라이언트 시크릿을 클라이언트에 반환한다(S0.1). 인가 서버는, S0.1에서 수신한 클라이언트 ID와 클라이언트 시크릿과, S0.0에서 수신한 정보 및 리다이렉트 URI를 서로 연관하여 유지한다. 클라이언트는, S0.1에서 수신한 클라이언트 ID와 클라이언트 시크릿을 유지한다. 여기까지, OAuth 2.0을 구현하는 사전 조작인 클라이언트 등록 플로우가 설명되었다.
이어서, 인가 서버에서 사용자를 인증하기 위한 플로우를, 도 1을 참조하여 설명할 것이다. 사용자는 클라이언트에 로그인할 수 있다(S1.0). 클라이언트는, 로그인 사용자를 식별하기 위한 정보인 로그인 컨텍스트를 생성하고 유지한다. 생성된 로그인 컨텍스트로부터 로그인 사용자를 식별하는 정보(예컨대, 로컬 사용자 ID)를 획득할 수 있다. 사용자는, 웹 브라우저를 통해 인가를 개시하기 위한 URI(이후, 인가 개시 URI)에 액세스할 수 있고, OAuth 2.0에 따라 인가 플로우를 개시할 수 있다(S1.1). 클라이언트는 인가 플로우를 개시하기 위한 인가 개시 URI로의 액세스에 응답하여, 인가 서버의 인가 엔드 포인트에 대하여 인가 코드 요구를 송신한다(S1.2). 인가 코드 요구는, 클라이언트 ID, 리다이렉트 URI, 스테이트(state) 파라미터를 포함한다.
스테이트 파라미터는 인가 코드 요구와 인가 코드 응답을 고유하게 연관시키기 위한 정보이며, CSRF(cross-site request forgery) 공격, 및 토큰 치환(이하, "인가 코드 치환") 공격을 방지하기 위해 사용가능하다. 그 때문에, 스테이트 파라미터는 추측불가능하고 중복하지 않는 값이다. 후술하는 인가 코드 응답에서 클라이언트가 수신하는 스테이트 파라미터와 S1.2에서의 인가 코드 요구에서 클라이언트가 송신한 스테이트 파라미터 사이의 일치가 검증된다. 또한, 인가 코드 요구를 실행한 사용자를 식별하기 위해서, 클라이언트에 의해 발행되는 스테이트 파라미터는 리다이렉트 URI 및 로그인 컨텍스트와 연관하여 클라이언트에 의해 관리된다.
S1.2에서 인가 코드 요구를 수신한 인가 서버는, 사용자가 인가 서버에 로그인하고 있지 않았을 경우, 웹 브라우저에 사용자를 인증하기 위한 로그인 화면으로 응답한다(S1.3). 사용자는, 웹 브라우저를 통해 사용자 ID 및 패스워드를 입력하고, 인가 서버에 대하여 인증 요구를 실행할 수 있다(S1.4). 인증 요구를 수신한 인가 서버는, S1.4에서 수신한 사용자 ID와 패스워드와의 조합과, 사전 등록된 조합 사이의 일치를 검증한다. S1.4에서 수신한 사용자 ID와 패스워드와의 조합이, 사전 등록된 조합에 일치하는 경우에는, 인가 서버는 인가 토큰을 발행한다. 발행된 인가 토큰은 웹 브라우저의 쿠키(Cookie)에 응답된다.
인가 서버는 사용자에 대하여 클라이언트의 인가를 동의하기 위한 인가 확인 화면으로 웹 브라우저 상에서 응답한다(S1.5). S1.2에서 수신한 클라이언트 ID와 리다이렉트 URI와의 조합이, 인가 서버에 사전 등록된 클라이언트 ID와 리다이렉트 URI와의 조합에 일치하지 않는 경우에는, 인가 서버는 웹 브라우저 상에 에러 화면으로 응답한다. 이에 의해, 무효한 URI로의 리다이렉트(전송)를 방지할 수 있다. 로그인 사용자가 이미 동일한 클라이언트 ID를 사용하는 것에 의해 인가 조작을 실행한 경우에, S1.5에서의 처리가 생략될 수 있다. 인가된 사용자 ID와 클라이언트 ID의 조합을 이하, 동의 정보로서 지칭할 것이다.
S1.6에서의 사용자에 의해 수행된 인가 조작 후, 인가 서버는 인가 코드를 발행하고, 클라이언트에 대하여 인가 코드 응답으로서 인가 코드와 스테이트 파라미터를 송신한다(S1.7). 더 구체적으로, 인가 코드와 스테이트 파라미터를 리다이렉트 URI에 쿼리 파라미터로서 추가하고, 그 후 리다이렉트 URI에 의해 지정된 응답처에 인가 코드와 스테이트 파라미터가 리다이렉트되도록 웹 브라우저에 송신한다. S1.7에서 발행된 인가 코드는, 인가 서버에서 클라이언트 ID, 사용자 ID, 및 리다이렉트 URL과 연관하여 보존된다. 인가 서버는 동의 정보를 추가로 보존한다.
리다이렉트 URI에 대하여 인가 코드 응답을 수신한 클라이언트는, 인가 코드 응답에 포함되는 스테이트 파라미터와, 클라이언트가 관리하는 스테이트 파라미터가 일치하는지를 검증한다. 검증의 결과로서, 스테이트 파라미터들이 일치하는 경우, 클라이언트는 인가 서버의 토큰 엔드 포인트에 대하여 토큰 요구를 송신한다(S2.0). 토큰 요구는 클라이언트 ID, 클라이언트 시크릿, S1.7에서 획득한 인가 코드, 및 S1.2에서 수신한 리다이렉트 URI를 포함한다.
S2.0에서 토큰 요구를 수신한 인가 서버는, 클라이언트 ID와 클라이언트 시크릿의 조합이 사전 등록된 조합과 일치하는지를 검증한다. 검증의 결과로서, 그것들이 일치하는 것으로 결정되면, 클라이언트가 인가된다. 인가 서버는, 그것이 S2.0에서 수신한 인가 코드를 유지할지를 검증하고, 유지할 경우에, 그 인가 코드는 만료되지 않았는지, 그리고 인가 토큰과 연관된 클라이언트 ID와 리다이렉트 URI가 S2.0에서의 토큰 요구에서 수신한 것들과 일치하는지를 검증한다. 이 검증을 통해, S1.2에서의 인가 코드 요구를 송신한 클라이언트와 S2.0에서의 토큰 요구를 송신한 클라이언트가 일치하는지를 인가 서버가 검증할 수 있다.
검증이 성공한 경우, 인가 서버는 클라이언트에 대하여 인가 토큰을 발행하고, 인가 토큰으로 토큰 응답으로서 클라이언트에 응답한다(S2.1). 여기서, 인가 서버는 인가 토큰을 다시 획득하기 위한 리프레시 토큰을 클라이언트에 대하여 발행할 수 있고, 리프레시 토큰으로 토큰 응답으로서 응답한다. 클라이언트는, S2.1에서 수신한 인가 토큰을 사용하여 리소스 서버가 제공하는 개방 API에 액세스할 수 있다. 인가 토큰을 발행한 후에, 인가 서버에 의해 관리되는 인가 코드가 파기되어 리플레이(replay) 공격을 방지할 수 있다.
S2.1에서의 토큰 응답에 리프레시 토큰이 포함되는 경우, 클라이언트에서 로그인 컨텍스트와 리프레시 토큰이 서로 연관하여 관리된다. 따라서, 다음 및 후속 경우들에서의 API로 액세스하는 경우, 인가 조작(S1.2 내지 S1.7)을 수행하지 않고 인가 토큰을 다시 획득할 수 있다. 더 구체적으로는, S1.1에서의 인가 개시에 응답하여, 클라이언트는 사용자의 로그인 컨텍스트와 리프레시 토큰이 서로 연관되는지를 확인한다. 연관되지 않는 경우에는, OAuth 2.0에 따른 플로우(S1.2에서의 처리 및 이후의 단계들)가 수행된다. 사용자의 로그인 컨텍스트와 리프레시 토큰이 서로 연관된 경우에는, 인가 서버의 토큰 엔드 포인트에 대하여 리프레시 요구가 송신된다(S2.2). 이 리프레시 요구는 클라이언트 ID, 클라이언트 시크릿 및 리프레시 토큰을 포함한다.
리프레시 요구를 수신한 인가 서버는, 클라이언트 ID와 클라이언트 시크릿의 조합이 S0.1에서 사전 등록된 조합과 일치하는지를 검증한다. 일치가 확인되고 클라이언트가 인가되면, 인가 서버는 수신된 리프레시 토큰이 인가 서버에서 유지되는지를 검증하고, 유지되는 경우에는, 그 리프레시 토큰은 만료되지 않았는지, 그리고 리프레시 토큰과 연관된 클라이언트 ID가 리프레시 요구에서의 클라이언트 ID와 일치하는지를 검증한다. 이들 검증들이 모두 성공한 경우, 인가 서버는 인가 토큰을 발행하고, 클라이언트에 토큰 응답으로서 인가 토큰을 송신한다. 여기서, 인가 토큰을 다시 획득하기 위해 새로운 리프레시 토큰이 재발행될 수 있고, 토큰 응답과 동시에 클라이언트에 대하여 송신될 수 있다. 인가 서버에서 새로운 리프레시 토큰이 발행된 후에, 인가 서버는 리플레이 공격을 방지하기 위해, 관리되고 있었던 리프레시 토큰을 파기할 수 있다. OAuth 2.0에 따른 인가 코드 승인의 처리 플로우가 설명되었다. OAuth 2.0에 따른 처리 플로우는, 인가 서버가 관리하는 사용자의 인증 정보를 클라이언트에 송신하는 대신, 인가 서버가 인가 토큰을 발행할 수 있게 하고, 클라이언트가 발행된 인가 토큰을 사용하여 리소스 서버가 제공하는 개방 API에 액세스할 수 있게 한다. 일본 특허 공개 제2016-6624호는, OAuth 2.0에 따른 처리 플로우를 사용하여, 복수의 외부 서비스 시스템과 제휴하는 정보 처리 시스템을 개시한다.
권한 위양 시스템에서 파라미터들을 관리하기 위한 비용 절감이 요구된다. 예를 들어, 도 1에 도시된 OAuth 2.0에 기초한 처리 플로우에서, S1.2에서 인가 서버의 인가 엔드 포인트에 인가 코드 요구를 송신하기 위한 스테이트 파라미터가 설정된다. 스테이트 파라미터에 대해 설정할 값은 추측불가능하고 중첩되지 않아야 하며 클라이언트에 의해 수신한 인가 코드 응답과, 클라이언트에서 인가 서버로 송신된 인가 코드 요구를 클라이언트에서 연관시키는데 사용할 수 있다. 그러나, 스테이트 파라미터의 값은 인가 코드 요구가 실행될 때마다 발행되어야 하고, 또한 클라이언트가 삭제될 때까지 클라이언트에 유지되며, 이는 클라이언트에 대한 관리 비용과 관련된 부하를 부과할 수 있다.
본 개시내용은 이하의 구성을 갖는다. 권한 위양 시스템은: 적어도 프로세서 및 적어도 프로세서에 결합되고 명령어들을 저장한 적어도 메모리를 포함하며,
이 명령어들은 적어도 프로세서에 의해 실행될 때,: 클라이언트에 의한 리소스 서버로의 액세스가 사용자에 의해 허가될 때 인가 서버에 의해 인가 코드를 발행하기 위한 인가 코드 요구를, 클라이언트로부터 인가 서버로 송신하고; 인가 코드 요구에 대한 응답인 인가 코드 응답을, 인가 서버로부터 클라이언트로 수신하고; 클라이언트에 사용자가 로그인할 때 로그인 컨텍스트를 생성하는 역할을 하도록 협력하며, 송신에 의해 송신되는 인가 코드 요구는, 인가 코드 요구를 인가 코드 응답과 연관시키기 위한 파라미터 값으로서 로그인 컨텍스트가 설정된 파라미터와 서명 정보를 포함하고, 인가 서버에서 서명 정보가 검증된 후에, 인가 코드 요구에 대응하는 인가 코드 응답이 클라이언트에 송신되고,
클라이언트는, 수신에 의해 수신된 인가 코드 응답에 포함되는 파라미터와, 송신에 의해 송신된 인가 코드 응답에 포함된 파라미터를 사용하여, 인가 코드 응답이 인가 코드 요구에 대응하는 것을 검증한다.
본 개시내용의 추가적인 특징들은 첨부 도면을 참조하여 예시적인 실시예들의 다음 설명으로부터 명백해질 것이다.
도 1은 OAuth 2.0에 기초한 인가 코드 승인의 처리 플로우이다.
도 2는 실시예 1에 따른 권한 위양 시스템을 도시하는 구성도이다.
도 3은 권한 위양 시스템에 포함된 디바이스들의 하드웨어 구성을 도시한다.
도 4a 내지 도 4d는 권한 위양 시스템에 포함되는 디바이스들의 소프트웨어 모듈 구성을 도시한다.
도 5a 및 도 5b는 웹 브라우저가 표시하는 사용자 인증 화면과, 클라이언트의 인가 확인 화면의 예들을 도시한다.
도 6은 실시예 1에 따른 OAuth 2.0에 기초한 인가 코드 승인의 처리 플로우를 도시한다.
도 7은 실시예 1에 따른 인가 코드 요구를 포함하는 JWT의 일례를 도시한다.
도 8은 실시예 1에 따른 인가 토큰을 포함하는 JWT의 일례를 도시한다.
도 9는 실시예 1에 따른, 클라이언트에서 리다이렉트 URI를 결정하는 처리 플로우를 도시한다.
도 10은 실시예 2에 따른, OAuth 2.0에 기초한 인가 코드 승인의 처리 플로우를 도시한다.
도 11은 실시예 2에 따른 인가 코드 요구를 포함하는 JWT의 일례를 도시한다.
도 12는 인가 서버에서의 동의 정보의 판정 플로우를 도시한다.
도 13은 실시예 4에 따른, OAuth 2.0에 기초한 인가 코드 승인의 처리 플로우를 도시한다.
본 개시내용은, 인가 코드 요구를 인가 코드 응답과 연관하기 위한 스테이트 파라미터와 같은 파라미터들의 역할을 유지할 수 있고, 동시에 클라이언트에서의 파라미터들의 발행 및 관리를 위한 비용을 감소시킬 수 있다.
본 개시내용을 구현하기 위한 최선의 방식들이 도면을 참조하여 후술될 것이다.
먼저 도 2를 참조하여, 본 개시내용의 실시예에 따른 권한 위양 시스템에 대해서 설명할 것이다. WAN(Wide Area Network)(100)은 WWW(World Wide web)시스템에 의해 구축된다. WAN(100)과 디바이스들(200 내지 500)은 LAN(Local Area Network)(101)을 통해 접속된다.
인가 서버(200)는 OAuth 2.0을 구현하기 위한 서버이며, 인증 요구의 수신 및 인가 코드들의 발행 및 관리 등의 처리를 수행하도록 구성된다. 리소스 서버(300)는 웹 서비스를 제공하기 위한 개방 API를 갖는다. 도 2에서는, 인가 서버(200)와 리소스 서버(300)는 LAN(101)을 통해 접속되지만, 그것들이 WAN(100)을 통해 접속될 수 있다. 인가 서버(200)는 LAN(101)을 통해 도시하지 않은 데이터베이스 서버에 추가로 접속될 수 있어, 인가 서버(200)가 자신의 기능을 구현하기 위해 사용하는 데이터를 그 데이터베이스 서버에 저장될 수 있게 한다. 도 2에서는 인가 서버(200)와 리소스 서버(300)를 별개의 서버들로서 제공하지만, 그 서버들의 기능들은 하나의 서버에서 구현될 수 있다.
클라이언트(400)는 OAuth 2.0에 기초한 클라이언트에 대응하고, 예를 들어 프린터, MFP(Multi-Function Printer/Periphral), PC(Personal Computer) 또는 스마트폰일 수 있다. 단말기(500)는 OAuth 2.0에 기초한 사용자 에이전트에게 대응한다. 사용자는 단말기(500)를 통해, 인가 서버(200)에 대한 사용자 인증 요구 및 클라이언트(400)에 대해 수행될 로그인 조작과 같은, 디바이스들의 기능들을 사용할 수 있다. 단말기(500)는 구체적으로는 예를 들어, PC 또는 스마트폰일 수 있다.
클라이언트(400) 및 단말기(500)는 각각 웹 브라우저(410) 및 웹 브라우저(510)를 포함한다. 사용자는 웹 브라우저(410) 또는 웹 브라우저(510)를 조작해서 후술될 인가 조작을 실행할 수 있다. 클라이언트(400)와 단말기(500)는 LAN(101)을 통해 접속된다. 이후, 웹 브라우저(410) 및 웹 브라우저(510)는, 그것들 중 어느 한쪽에 의해 조작이 수행될 수 있는 경우에, 참조 부호들 없이 "웹 브라우저"로서 간단히 지칭될 것이다.
다음으로 도 3을 참조하여, 인가 서버(200), 리소스 서버(300), 클라이언트(400), 및 단말기(500)의 하드웨어 구성을 설명할 것이다. 도 3은 일반적인 정보 처리 장치를 도시하는 블록도이며, 본 실시예에 따른 디바이스들은 일반적인 정보 처리 장치의 하드웨어 구성이나 IaaS(Infrastructure as a Service)로서 제공되는 정보 처리 장치의 가상적인 하드웨어 구성을 적용할 수 있다. 도 3을 참조하여, 클라이언트(400)를 예로서 설명할 것이지만, 리소스 서버(300), 인가 서버(200) 및 단말기(500) 모두는 동일한 하드웨어 구성을 갖는다.
CPU(Central Processing Unit)(2001)는, RAM(Random Access Memory)(2002), ROM(Read Only Memory)(2003), 외부 메모리(external memory)(2011) 등으로부터 프로그램을 판독하고 프로그램의 명령어들을 실행하여, 클라이언트(400)에 대한 제어를 행하도록 구성된다. 후술될 시퀀스는 그러한 프로그램의 명령어들이 실행됨으로써 구현될 수 있다. CPU(2001)는 시스템 버스(2004)에 접속되는 블록들을 제어하도록 추가로 구성된다.
RAM(2002)은, CPU(2001)가 명령어들을 실행하기 위해 사용가능한 워크 메모리이다. ROM(2003)이나 외부 메모리(2011)에 보존된 OS(Operating System)나 애플리케이션 등의 프로그램이 RAM(2002)에 로딩될 수 있고, 그 프로그램의 명령어들을 CPU(2001)가 순차적으로 판독하고 실행할 수 있다. ROM(2003)은, 애플리케이션 프로그램 및 OS를 포함하는 내장된 프로그램 및 데이터를 저장하도록 구성된 저장 디바이스이다. ROM(2003)은 플래시 메모리 또는 소거 가능 ROM일 수 있다. RAM(2002) 또는 ROM(2003)은 CPU(2001)에 연결되고 CPU(2001)에 의해 실행될 때 명령어들을 저장하고 다양한 유닛들로서 작동하거나 다음에서 설명되는 동작들을 수행하도록 제휴하는 메모리일 수 있다.
키보드 컨트롤러(KBC)((2005))는, 키보드(KB)(2009) 및 도시하지 않은 포인팅 디바이스로부터의 입력들을 제어하도록 구성된다. CRTC(cathode ray Tube Controller)(2006)는 CRT 디스플레이(2010)에 의해 표시되는 디스플레이를 제어하도록 구성된다. DKC(disk controller)(2007)는 외부 메모리(2011)에 대한 데이터 액세스들을 제어하도록 구성된다. 네트워크 컨트롤러(NC)(2008)는 WAN(100)이나 LAN(101)을 통해 디바이스에 접속된 다른 디바이스들과의 통신을 제어하기 위한 처리를 실행하도록 구성된다. 디바이스가 IaaS로서 제공되는 가상적인 정보 처리 장치인 경우에는, 디바이스는 KBC(2005) 및 CRTC(2006)를 갖지 않을 수 있지만, NC(2008)를 통해 디바이스에 접속되는 단말기에 포함된 키보드나 CRT 디스플레이를 통해 조작될 수 있다.
후술하는 설명들에서, 달리 명시되지 않는 한, 디바이스들의 기능들은 하드웨어에서의 CPU(2001)에 의해 주로 실행되거나, 소프트웨어에서의 RAM(2002), ROM(2003), 외부 메모리(2011) 등에 설치된 프로그램에 의해 주로 실행될 수 있다.
다음으로 도 4a 내지 도 4d를 참조하여, 인가 서버(200), 리소스 서버(300), 클라이언트(400) 및 단말기(500)의 기능들에 대해서 설명할 것이다. 인가 서버(200)는 인가 서버 유닛(210) 및 HTTP 서버 유닛(220)을 갖는다. HTTP 서버 유닛(220)은 WAN(100)을 통해 클라이언트(400)와 단말기(500)에 접속되고, 웹 브라우저나 후술될 클라이언트 애플리케이션(420)과 HTTP 통신을 수행하도록 구성된 기능이다. HTTP 서버 유닛(220)은 SSL/TLS에 기초한 통신을 수행할 수 있고, 도시하지 않은 증명서 저장소를 갖는다.
인가 서버 유닛(210)은 HTTP 서버 유닛(220)을 통해 웹 브라우저(510)로부터의 요구를 수신하고, 수신한 요구에 대한 결과로 응답하도록 구성된 기능이다. 더 구체적으로는, 사용자 인증 요구를 HTTP 서버 유닛(220)이 웹 브라우저(510)로부터 수신하고, 인증이 성공한 사용자에 대한 사용자 정보와 연관된 인가 토큰을 생성하고, 웹 브라우저(510)에 인가 토큰을 통지하도록 구성된다. 인가 토큰은 여기서, 사용자가 인가 서버(200)에 로그인한 것을 나타내는 토큰 또는 사용자가 인가 서버(200)에 의해 인증되어 있는지를 검증하기 위한 토큰일 수 있다. 인가 토큰을 사용함으로써 인가 서버(200)는 사용자를 식별하는 것이 가능하게 된다. 한편, 인가 코드는, 인증된 사용자에 의해 수행된 인가 조작을 통해 권한 위양된 클라이언트(400)가 사용자를 대신해서 리소스 서버(300)의 API에 액세스하도록 허가된 것을 나타내는 토큰이다. 인가 서버 유닛(210)은, 인가 토큰에 서명 정보를 추가하기 위한 비밀 키를 유지하도록 추가로 구성될 수 있다. 이 경우에는, 이 비밀 키가 사용되어 인가 토큰에 서명 정보를 추가할 수 있고, 서명 정보를 갖는 인가 토큰이 클라이언트(400)에 대하여 발행될 수 있다.
리소스 서버(300)는 리소스 서버 유닛(310)을 갖는다. 리소스 서버 유닛(310)은, 웹 서비스를 제공하기 위한 개방 API를 제공하도록 구성된 기능이다. 리소스 서버 유닛(310)은, 인가 서버(200)와 마찬가지로, HTTP 서버 유닛을 가질 수 있고, HTTP 서버 유닛을 통해 외부 디바이스로 그리고 이로부터 송신 및 수신을 수행하도록 구성될 수 있다.
클라이언트(400)는 웹 브라우저(410), 클라이언트 애플리케이션(420) 및 인증 유닛(430)을 갖는다. 웹 브라우저(410)는 WWW를 사용하기 위한 사용자 에이전트에 의해 구현되는 기능이며, 단말기(500)에 포함되는 웹 브라우저(510)의 기능과 동일하다. 웹 브라우저(410)는 사용자의 조작에 응답하여, 인가 서버(200) 및 클라이언트 애플리케이션(420)과 통신하도록 구성된다. 클라이언트 애플리케이션(420)은, 리소스 서버(300)에 의해 제공되는 개방 API를 실행하여 클라이언트 애플리케이션(420)에 의해 제공되는 기능으로 조합한 웹 서비스를 사용자에 제공하도록 구성된다. 본 실시예에 따르면, 클라이언트 애플리케이션(420)은 OAuth 2.0에 기초한 클라이언트에 대응한다.
인증 유닛(430)은 사용자를 인증하기 위한 기능이다. 사용자는 클라이언트(400)의 기능을 사용하기 위해서, 클라이언트(400)에 의해 제시된, 도시되지 않은 입력 화면을 통해 로컬 사용자 ID와 로컬 사용자 패스워드를 입력할 수 있다. 입력에 응답하여 클라이언트(400)는, 인증 유닛(430)에 사전 등록된 정보(로컬 사용자 ID와 로컬 사용자 패스워드)와 입력 정보 사이의 비교에 의해 사용자에 대한 인증 처리를 수행하고, 로그인 컨텍스트를 생성한다. 인증 처리는, IC 카드를 사용한 인증이나 지문에 기초한 생체 인증과 같은 임의의 다른 형태들로 수행될 수 있다.
로그인 컨텍스트는, 클라이언트(400)에서 로컬 사용자를 식별하기 위한 정보이며, 예를 들어 로컬 사용자 ID를 포함할 수 있다. 로그인 컨텍스트는 클라이언트 애플리케이션(420)과 인증 유닛(430)에 의해 공유된다. 본 실시예에 따르면, 클라이언트(400)에서의 로그인 처리는 사용자에 의해 직접 클라이언트(400)를 조작하는 것에 의해 실행되는 것으로 설명하였지만, 사용자는 웹 브라우저(510)를 통해 원격으로 클라이언트(400)에 로그인할 수 있다. 이 경우, 인증 유닛(430)은 도시하지 않은 로그인 화면으로 웹 브라우저(510)에 응답한다. 사용자는 그 로그인 화면을 통해 사용자에 의해 입력된 로컬 사용자 ID와 로컬 사용자 패스워드에 기초하여 인증된다. 이러한 경우, 인증 유닛(430)에서 로그인 컨텍스트가 생성되고, 클라이언트 애플리케이션(420)과 인증 유닛(430)에 의해 공유된다.
실시예 1
실시예 1에 따르면, 클라이언트의 URI의 변경으로 인한 OAuth 2.0에 기초한 처리의 복잡함이, 이 처리를 실행하는 데 있어서의 안전성을 손상시키지 않고서 해결될 수 있다. 유사한 부호들은 이 실시예 및 도 1에 설명된 유사한 처리 플로우들을 지칭하고, 그 반복적인 상세한 설명은 생략할 것이다.
먼저, 도 5a 및 도 5b를 참조하여, 인가 서버(200)가 사용자를 인증하기 위한 로그인 화면과, 사용자에 대하여 클라이언트(400)의 인가에 관한 동의에 관해 묻기 위한 인가 확인 화면이 설명된다.
도 5a는 사용자가 인가 서버(200)에 로그인하기 위해 사용가능하고 웹 브라우저에 표시되는 로그인 화면의 일례를 도시한다. 로그인 화면은, 사용자가 웹 브라우저를 통해 인가 서버(200)의 인가 엔드 포인트에 인가 코드 요구를 송신하고, 사용자가 인가 서버(200)에 로그인하지 않은 경우에 웹 브라우저에 표시될 것이다. 로그인 화면(5000)은, 사용자 ID 입력 필드(5001), 패스워드 입력 필드(5002), 로그인 조작을 실행하기 위한 로그인 버튼(5003)을 포함한다. 로그인 버튼(5003)이 눌러진 후에 수행되는 처리에 대해서는 후술할 것이다.
도 5b는 사용자의 인증 결과로서, 인가 서버(200)가 웹 브라우저에 응답하는 인가 확인 화면의 일례를 도시한다. 인가 확인 화면((5100))은, 사용자에 대하여 동의를 구하는 콘텐츠를 갖고, 이 콘텐츠는 인가될 클라이언트(400)의 클라이언트명(5101), 클라이언트(400)에 관한 설명(5102) 및 아이콘 화상(5103)을 포함한다. 인가 확인 화면(5100)은, 사용자가 클라이언트(400)의 인가를 인가하고 거부하기 위해 사용가능한 허가 버튼(5104) 및 거부 버튼(5105)을 추가로 포함한다. 허가 버튼(5104)이 눌러진 때 그리고 거부 버튼(5105)이 눌러진 때 수행되는 처리에 대해서는 후술할 것이다.
이어서, 도 6을 참조하여 본 개시내용의 특징들을 갖는 OAuth 2.0에 기초한 인가 코드 승인의 처리 플로우를 설명할 것이다. 유사한 부호들은 도 1 및 도 6에서의 유사한 부분들을 지칭하고, 임의의 반복적인 상세한 설명은 생략할 것이다. 도 1에서의 S0.0, S0.1, S1.2, S2.0, 및 S2.2에서의 처리는 후술될 S3.0, S3.1, S4.0, S5.0, 및 S5.1에서의 처리에 의해 치환되어, 본 실시예에 따른 OAuth 2.0에 기초한 처리 플로우를 실행할 수 있다.
먼저, OAuth 2.0을 실행하는 사전 조작들로서 클라이언트(400)를 등록하는 플로우에 대해서 도 6을 참조하여 설명할 것이다. 본 실시예에 따르면, 클라이언트(400)가 예를 들어, 능동적으로 인가 서버(200)와 통신하여 클라이언트(400)에 대한 등록 요구를 실행한다. 그러나, 사용자가 웹 브라우저를 통해 인가 서버(200)에 액세스하여 클라이언트(400)에 대한 등록 요구를 실행할 수 있다. 클라이언트(400)를 등록하는 플로우는, 클라이언트(400)의 기동 시, 또는 S1.1에서의 인가 플로우의 개시 시 클라이언트(400)가 아직 등록되지 않은 경우에 개시한다.
클라이언트(400)는 인가 서버(200)에 클라이언트(400)의 등록 요구를 송신한다(S3.0). 등록 요구를 수신한 인가 서버(200)는 클라이언트(400)를 식별하기 위한 클라이언트 ID와, 클라이언트(400)를 인증하기 위한 암호 키와 복호 키(공개 키와 비밀 키)의 키 페어를 생성한다. 이 실시예에 따르면, 비밀 키와 암호 키를 예시적으로 설명할 것이다. 인가 서버(200)는, 생성된 클라이언트 ID와 비밀 키를 등록 응답으로서 클라이언트(400)에 반환한다(S3.1). 클라이언트(400)에서는 클라이언트 ID와 비밀 키가 서로 연관하여 보존되는 한편, 인가 서버(200)에서는 클라이언트 ID와 공개 키가 서로 연관하여 보존된다. 본 실시예는 클라이언트 ID를 "client_01"로서 가정하여 설명될 것이다. 클라이언트(400)에 유지된 연관 정보의 일례를 표 1에 도시하고, 인가 서버(200)에 유지된 연관 정보의 일례를 표 2에 도시한다.
Figure 112018086081028-pat00001
Figure 112018086081028-pat00002
등록 응답으로서 클라이언트(400)에 송신되는 정보는, 전술한 형태로 제한되지 않는다. 예를 들어, 비밀 키의 주체 정보로서 클라이언트 ID를 내장할 수 있고, 등록 응답으로서 비밀 키만을 클라이언트(400)에 송신할 수 있다. 대안적으로, 인가 서버(200)는 사전에 비밀 키를 생성할 수 있고, 클라이언트(400)에 대한 등록 플로우(S3.0 내지 S3.1)를 실행하지 않고서, 클라이언트가 제조되는 동안 비밀 키가 클라이언트(400)에 사전 설치될 수 있다. 여기까지 클라이언트(400)에 대한 등록 플로우가 설명되었다.
관련 기술에서, 클라이언트(400)의 사전 등록 동안(S0.0)에 리다이렉트 URI와 클라이언트(400)에 관한 정보를 인가 서버(200)에 송신하고, 송신된 정보는 인가 서버(200)에서 관리된다. 반대로, 본 개시내용에 따른 사전 등록(S3.0)은 그 정보를 송신하지 않고, 송신된 정보를 인가 서버(200)에서 관리하지 않는다.
이어서, 도 6을 참조하여, 사용자가 클라이언트(400)에 로그인하는 단계로부터, 클라이언트(400)가 인가 서버(200)에 대하여 인가 코드 요구를 송신하는 단계까지의 처리 플로우를 설명할 것이다. 사용자는 클라이언트(400)에 로그인한다(S1.0). 여기서 로컬 사용자 ID는 "local_user_01"인 것으로 가정한다. 클라이언트(400)는 로컬 사용자 ID가 식별될 수 있는 로그인 컨텍스트를 생성하고 유지한다. 그것은 로그인 컨텍스트가 사용자에 의해 수행되는 로그 아웃 조작에 응답하여, 또는 이 컨텍스트에 대해 사전 설정된 유효 기한 후에 소멸될 수 있도록 구성될 수 있다.
이어서, 사용자는 웹 브라우저를 통해 클라이언트(400)의 인가를 개시하는 URI에 액세스한다(S1.1). 여기서 사용자 에이전트가 웹 브라우저(410)일 경우, 사용자는 웹 브라우저(410)를 기동하여 URI에 액세스할 수 있거나, 또는 웹 브라우저(410)의 북마크를 사용하여 URI에 액세스할 수 있다. 대안적으로, 클라이언트 애플리케이션(420)의 도시하지 않은 사용자 인터페이스가 조작되어, 웹 브라우저(410) 기동하여 인가 처리를 개시할 수 있다. 사용자 에이전트가 웹 브라우저(510)일 경우에는, 웹 브라우저(410)는 웹 브라우저(510)에 의해 수행되는 원격 액세스를 수신하고, 웹 브라우저(510)에서 인가 개시에 대한 URI를 입력하여 액세스할 수 있거나, 또는 이에 대응하는 북마크를 사용하여 액세스할 수 있다. 대안적으로, 클라이언트 애플리케이션(420)은 웹 브라우저(510)에 의한 원격 액세스에, 도시되지 않은 화면으로 응답하고, 사용자는 그 화면에 내장된 인가 개시에 대한 URI로의 링크를 눌러 액세스할 수 있다.
S1.1에서의 클라이언트(400)가 인가 개시 URI로의 액세스를 수신하면, 클라이언트(400)는 인가 서버(200)의 인가 엔드 포인트에 대하여 인가 코드 요구를 송신한다(S4.0). 더 구체적으로는, 인가 서버(200)의 인가 엔드 포인트로의 리다이렉트 지시를 웹 브라우저에 송신한다. S4.0에서 송신된 인가 코드 요구는, 인가 코드 응답에 응답 타입으로서 인가 코드를 지정하기 위한 정보와, 인가 코드 요구를 인가 코드 응답과 고유하게 연관시키기 위한 스테이트 파라미터를 포함한다.
S4.0에서 송신된 인가 코드 요구는 JWT(JSON web Token)를 추가로 포함한다. 더 구체적으로, OAuth 2.0 JWT 프로파일에서 client_assertion_type:jwt-bearer를 선언하고, 그 client_assertion에 대해 JWT를 파라미터로서 설정한다. 도 7은 JWT를 파라미터로서 설정할 때의 인가 코드 요구의 일례를 나타낸다. JWT는 헤더부("Header"로부터 시작함), 페이로드부("Payload"로부터 시작함), 디지털 서명부("Encoded"로부터 시작함)을 포함하고, 그 전부가 Base 64에 의해 표시되는 인코딩 방법에 따라 인코딩된다.
페이로드부에는, "iss"(발행자를 나타냄) 및 "sub"(주체를 나타냄)에는 클라이언트 ID "client_01"이 설정된다. "aud"(사용자를 나타냄)에는, 인가 서버(200)의 인가 엔드 포인트의 URI가 설정되고, "exp"("유효 기한"을 나타냄) 및 "iat"(발행 일시를 나타냄)에는 정보가 설정된다. "client_name"에는 클라이언트명이 설정되고, "description"에는 클라이언트(400)의 설명이 설정된다. 도 7을 참조하여, 클라이언트(400)의 클라이언트명으로서 "디바이스 XX"가 설정되고, 클라이언트(400)에 관한 설명으로서 "YY에 위치된
Figure 112018086081028-pat00003
디바이스 XX"가 설정된다. "redirect_uri"에는 리다이렉트 URI가 설정되고, 여기서 예를 들어, "https://192.168.1.1/redirect"가 설정된다. 필요에 따라 "icon_image"에는 아이콘 화상에 관한 정보가 아이콘 화상의 화상 형식과 함께 설정된다. 아이콘 화상에 관해 설정되는 정보는, 아이콘 화상이 존재하는 경우 URI일 수 있거나, 또는 인가 서버(200)에 화상이 유지되는 경우 그 화상을 식별하기 위한 정보일 수 있다.
이러한 정보들을 설정한 후에, 헤더부 및 페이로드부에서의 문자열들을 Base64에 따라 인코딩하고, 그 문자열들에 대하여 클라이언트(400)에 유지되는 비밀 키를 사용하여 디지털 서명을 부여한다. S4.0에서 JWT를 획득한 인가 서버(200)는, 클라이언트 ID에 기초하여 공개 키를 식별하고, 그 공개 키를 사용하는 것에 의해 JWT에 포함되는 디지털 서명을 검증하여 클라이언트(400)를 인증하고, JWT에서의 문자열들이 변경되지 않은 것을 검증한다. 그 결과, S4.0에서의 인가 코드 요구의 JWT에 포함되는 리다이렉트 URI는 클라이언트(400)가 설정한 것이며, 변경되지 않은 것이 검증될 수 있다.
여기까지, 사용자가 클라이언트(400)에 로그인하는 단계로부터, 클라이언트(400)가 인가 서버(200)에 대하여 인가 코드 요구를 송신하는 단계까지의 플로우가 설명되었다. JWT에 기초하여, 인가 코드 요구에 포함되는 리다이렉트 URI가 신뢰될 수 있다. 따라서, 인가 서버(200)는 그것을 리다이렉트 URI와 비교하지 않을 수 있고, 인가 서버(200)에 리다이렉트 URI를 사전에 등록하지 않을 수 있다. 그 결과, 클라이언트(400)의 URI가 변경되고, 따라서 리다이렉트 URI가 변경된 경우에도, 변경된 클라이언트(400)의 URI를 사용하여 인가 서버(200)에 인가 코드 요구를 송신할 수 있다.
클라이언트명, 설명 및 아이콘 화상과 같은, 인가 확인 화면에 표시되는 클라이언트(400)에 관한 정보를 기입하기 위해 사용되는 언어는, 클라이언트(400)에 저장되는 로컬 사용자에 의해 사용되는 언어에 관한 언어 정보나, 웹 브라우저에서의 Accept-Language 헤더에 설정된 언어 정보(웹 브라우저로부터의 요구에 포함된 언어 정보)에 기초하여 결정될 수 있다. 이는 S4.0에서의 인가 코드 요구에 포함되는 클라이언트(400)에 관한 정보가 언어 정보에 기초하여 기입될 수 있다는 것을 의미한다. 따라서, 인가 서버(200)는 클라이언트(400)에 관한 정보를 수신하여, 클라이언트(400)에 로그인한 로컬 사용자에 적응된 인가 확인 화면을 사용자에 제시할 수 있다.
이어서, 웹 브라우저를 통해 사용자에 로그인 화면을 제시하는 것으로부터 클라이언트(400)에 인가 코드를 발행하는 것까지의 처리에 대해서, 도 6을 참조하여 설명할 것이다. 인가 엔드 포인트에 대하여 인가 코드 요구를 수신한 인가 서버(200)는, 사용자가 인가 서버(200)에 로그인하고 있지 않은 경우에는 로그인 화면을 제시한다(S1.3). 도 5a는 로그인 화면의 일례를 도시한다. 사용자는 로그인 화면(5000)에 사용자 ID와 패스워드를 입력하고, 로그인 버튼(5003)을 눌러 인가 서버(200)에 인증 요구를 송신할 수 있다(S1.4). 인증 요구를 수신한 인가 서버(200)는, 사용자 ID와 패스워드의 조합을 인가 서버(200)에 사전에 등록된 정보와 비교하고, 그것들이 일치하는 경우에, 인가 토큰을 발행한다. 발행된 인가 토큰은 응답으로서 웹 브라우저의 쿠키에 반환된다. 여기서, 인가 토큰은 랜덤하고 추측불가능한 문자열일 수 있거나, 로그인 사용자의 식별 정보와 로그인 일시를 포함한 암호화된 문자열일 수 있다. 전자의 경우, 인가 토큰은 로그인 사용자의 식별 정보(또는 본 실시예에서는 사용자 ID)와 조합하여 인가 서버(200)에 유지된다. 본 실시예에서의 사용자 ID는 여기서 "user_01"로서 가정한다.
인가 서버(200)는 인가 확인 화면으로 웹 브라우저에 응답한다(S1.5). 도 5b는 인가 확인 화면의 일례를 도시한다. 그러나, S4.0에서의 인가 코드 요구에서 수신된 JWT의 디지털 서명을 공개 키로 검증될 때 그리고 그것이 무효로서 결정된 경우, 도시하지 않은 에러 화면이 반환되고 처리를 종료한다. 디지털 서명 검증 처리에 의해, 무효한 URI로의 리다이렉트를 방지할 수 있다. JWT에서의 디지털 서명이 유효한 경우가 후술될 것이다.
S4.0에서의 인가 코드 요구에서 수신된 JWT에 포함되는 값들(클라이언트명(5101), 설명(5102) 및 아이콘 화상(5103))에 기초하여 인가 확인 화면 (5100)이 웹 브라우저에 표시된다. 여기서, 사용자가 거부 버튼(5105)을 누르는 경우, 그리고 클라이언트 ID와 리다이렉트 URI의 조합이 사전에 등록된 대응하는 것과 일치하는 경우에는, 사용자가 클라이언트(400)의 인가를 거부한 것을 나타내는 정보를 인가 서버(200)가 리다이렉트 URI에서의 쿼리 파라미터에 추가한다. 그 후, 인가 서버(200)는 그 리다이렉트 URI에서 지정된 응답처에 정보를 리다이렉트하라는 지시로 웹 브라우저에 응답한다.
전술한 바와 같이, 그러한 JWT의 사용은, 무효한 인가 코드 요구를 거부할 수 있게 하고, 인가 코드 요구가 거부된 것을 나타내는 표시 화면을 웹 브라우저에 제공할 수 있다. S4.0에서의 요구가 거부되지 않는 경우에도, 인가 확인 화면을 통해 사용자가 인가를 거부하고 인가가 거부된 것을 나타내는 정보를 웹 브라우저에 송신할 수 있다.
한편, 사용자가 허가 버튼(5104)을 누른 경우에는, 인가 조작이 실행되고(S1.6), 인가 서버(200)는 인가 코드를 발행한다. S1.6에서 발행된 인가 코드 및 S4.0에서의 인가 코드 요구에서 수신된 스테이트 파라미터가 쿼리 파라미터들로서 리다이렉트 URI에 추가되고, 그 리다이렉트 URI에서 지정된 응답처에 인가 코드 및 스테이트 파라미터를 리다이렉트하라는 지시가 웹 브라우저로 반환된다(S1.7). 발행된 인가 코드는 클라이언트 ID, 사용자 ID 및 리다이렉트 URI와 연관하여 인가 서버(200)에 보존된다. 인가 서버(200)에 보존된 인가 코드는, 후술될 토큰 요구에 응답하여 수행되는 클라이언트(400)의 검증에 사용될 수 있다. 여기서, 예를 들어, 클라이언트 ID "client_01", 사용자 ID "user_01" 및 리다이렉트 URI "https://192.168.1.1/redirect"와 연관하여 인가 코드가 보존된다. 인가 코드는 추측불가능한, 랜덤한 문자열이어야 하고, 유효 기한을 가질 수 있다. 인가 서버(200)는, 사용자에 의해 인가가 동의된 것으로 결정하고 동의 정보(사용자 ID와 클라이언트 ID)를 로그인 사용자에 관한 정보로서 등록한다.
S1.7에서 인가 코드 응답을 수신한 클라이언트(400)는, 인가 서버(200)의 토큰 엔드 포인트에 대하여 토큰 요구를 송신한다(S5.0). 이 토큰 요구는 인가 플로우가 인가 코드 승인에 기초한 것을 나타내는 정의 "grant_type=authorization_code" 및 획득한 인가 코드 및 클라이언트 인증 정보를 포함하는 JWT(JSON web Token)를 포함한다. 여기서, 더 구체적으로는 OAuth 2.0 JWT 프로파일에서 선언된 client_assertion_type:jwt-bearer에서 client_assertion에 JWT를 파라미터로서 설정한다. 도 8은 JWT에 의해 나타난 토큰 요구의 일례를 나타낸다. 도 7의 인가 코드 요구와 중복하는 부분의 임의의 반복적인 상세한 설명은 생략될 것이다.
S5.0에서 토큰 요구를 수신한 인가 서버(200)는, 클라이언트 ID로부터 식별된 공개 키를 사용하여 JWT에서의 서명을 검증한다. 검증이 성공하고 클라이언트(400)가 인증되면, 인가 서버(200)는 인가 토큰을 발행하고, 클라이언트(400)에 토큰 응답을 송신한다(S2.1). 클라이언트(400)는 인가 서버(200)의 토큰 엔드 포인트에 대하여 리프레시 요구를 송신한다(S5.1). 리프레시 요구에서의 클라이언트(400)에 대한 인증 방법이, S2.2에서는 클라이언트 ID와 시크릿의 조합에 기초하여 비교를 수행하여 클라이언트(400)를 인증한다. 한편, S5.1에서는 클라이언트 ID에 추가된 디지털 서명이 비밀 키를 사용하는 거서에 의해 검증되어, 클라이언트(400)를 인증한다. 이 처리는, 웹 브라우저에 로그인 화면을 제시하고, 그 후 클라이언트(400)에 인가 코드를 발행한다.
이어서, 인가 코드 요구에서 설정되는 리다이렉트 URI를 결정하기 위한 처리에 대해서, 도 9를 참조하여 설명할 것이다. 도 9에서의 처리는 클라이언트(400)에서 리다이렉트 URI를 결정하는 처리 플로우이다. 이 처리는, 클라이언트(400)가 인가 플로우에 대한 개시 요구(S1.1)을 수신할 때 개시된다(S9.1). 클라이언트(400)는 인가 플로우에 대한 개시 요구에서의 Host 헤더를 획득한다(S9.2). 클라이언트(400)는 획득된 Host 헤더의 도메인부가 "localhost"인지를 판정한다(S9.3). 도메인부 "localhost"는, 프로그램이 실행될 디바이스를 나타내는 호스트명에 대응하고, 이 경우, 인가 플로우에 대한 개시 요구가 송신된 웹 브라우저를 나타낸다. S9.3에서의 판정 결과로부터, 인가 플로우에 대한 개시 요구가 송신된 웹 브라우저를 식별할 수 있다. 여기서, 웹 브라우저(410)가 인가 플로우에 대한 개시 요구를 클라이언트(400)에 송신한 것으로 가정한다. Host 헤더가 "localhost"인 경우에는, 리다이렉트 URI의 도메인부가 "localhost"인 것으로 결정한다(S9.8). 예를 들어, 리다이렉트 URI는 "https://localhost/redirect"일 수 있다.
S9.3에서 Host 헤더의 도메인부가 "localhost"가 아닌 경우, 클라이언트(400)는 Host 헤더의 도메인부가 IP 어드레스인지를 판정한다(S9.4). IP 어드레스가 아닐 경우에는, S9.2에서 획득된 Host 헤더가 사용되어, 도시하지 않은 DNS 서버에 문의하여 IP 어드레스를 획득한다(S9.5). 예를 들어, Host 헤더가 "www.canon.jp:443"인 경우, 도메인(Fully Qualified Domain Name: FQDN)인 "www.canon.jp"에 대하여 포트 번호 "443"이 추가된다. 이 경우, Host 헤더의 일부로서 도메인부가 추출되고, 도메인부로 DNS 서버에 문의한다. IP 어드레스가 획득된 후, 후술될 S9.6에서의 처리가 실행된다.
S9.4에서 Host 헤더의 도메인부가 IP 어드레스인 경우, 클라이언트(400)에 사전 설정되는 IP 어드레스와 획득된 IP 어드레스가 클라이언트(400)에서 비교된다(S9.6). IP 어드레스들이 일치하는지 여부가 클라이언트(400)에서 판정된다(S9.7). IP 어드레스들이 일치하지 않은 경우에, S9.1에서 수신된 액세스가 무효한 것으로 판정하고, 처리는 에러로 종료된다(S9.9). IP 어드레스가 일치한 경우에는, S9.1에서 수신된 액세스가 유효한 것으로 판정하고, S9.2에서 획득한 Host 헤더의 도메인부를 갖는 URI가 생성된다. 생성된 URI는 리다이렉트 URI로서 결정된다(S9.8). 여기까지, 클라이언트(400)에서의 리다이렉트 URI를 결정하는 방법이 설명되었다. 이 방법에 따르면, IP 어드레스나 호스트명이 변경될 때에도, OAuth 2.0에 기초한 처리 플로우에서의 인가 플로우에 대한 개시 요구에 응답하여 리다이렉트 URI를 결정할 수 있다.
이 실시예는, OAuth 2.0에 기초한 인가 코드 승인의 처리 플로우에서, 안전성을 손상시키지 않고서, 리다이렉트 URI 및 인가 확인 화면에 제시되는 클라이언트에 관한 정보의 사전 등록 및 관리에 대한 필요를 제거할 수 있고, 동적인 변경들을 용이하게 처리할 수 있다.
실시예 2
도 1 및 도 6을 참조하여 설명된 OAuth 2.0에 기초한 처리 플로우에서는, S1.2(또는 도 6에서는 S4.0)에서 인가 서버의 인가 엔드 포인트에 대하여 인가 코드 요구를 송신하기 위해 스테이트 파라미터가 설정된다. 스테이트 파라미터는 인가 코드 요구를 인가 코드 응답과 고유하게 연관시키기 위한 추측불가능하고 중복하지 않는 값을 갖는다. 그러나, 스테이트 파라미터의 값이 인가 코드 요구가 실행될 때마다 발행되어야 하고 스테이트 파라미터의 값이 삭제될 때까지, 클라이언트(400)에 유지되어야 하여, 클라이언트(400)에의 관리 비용에 관한 부하를 부과한다. 실시예 2에 따라, 클라이언트(400)에서의 스테이트 파라미터의 값을 발행하고 관리하는 비용을 감소시키기 위한 처리를 설명할 것이다. 실시예 2가 종래 기술(도 1)과의 조합을 참조하여 설명될 것이지만, 실시예 2는 실시예 1(도 6)과 조합될 수 있다.
도 10을 참조하여, 실시예 2에 따른 OAuth 2.0에 기초한 인가 코드 승인의 처리 플로우를 설명할 것이다. 유사한 부호들은 도 1 및 도 10에서의 유사한 부분들을 지칭하고, 임의의 반복적인 상세한 설명은 생략할 것이다. 실시예 2에 따른 클라이언트(400)의 사전 등록은, 종래 기술에 기초한 패턴(S0.0 내지 S0.1)으로 수행되지만 실시예 1에 따른 패턴(S3.0 내지 S3.1)으로 수행될 수 있으며, 따라서 그 임의의 반복적인 설명은 생략할 것이다. 사용자가 클라이언트(400)에 로그인(S1.0)하는 시간으로부터 클라이언트(400)에 대하여 인가 개시 요구를 송신(S1.1)할 때까지의 처리는, 종래 기술 또는 실시예 1의 방식과 동일한 방식으로 수행되고, 임의의 반복적인 설명은 생략할 것이다.
클라이언트(400)가 S1.1에서 인가 개시에 대한 URL로의 액세스를 수신할 때, 클라이언트(400)는 인가 서버(200)의 인가 엔드 포인트에 대하여 인가 코드 요구를 송신한다(S7.0). 더 구체적으로는, 웹 브라우저를 통해 인가 엔드 포인트로의 리다이렉트가 수행된다. S7.0에서의 인가 코드 요구는, 응답 타입으로서 인가 코드를 지정하기 위한 정보와, 클라이언트(400)를 고유하게 식별하기 위한 클라이언트 ID, 인가 코드 요구를 인가 코드 응답과 고유하게 연관하기 위한 정보인 스테이트 파라미터 및 리다이렉트 URL을 포함한다. 그러나, 로그인 컨텍스트는 스테이트 파라미터의 값으로서 설정된다. 로그인 컨텍스트는 클라이언트(400)에 로그인한 사용자에 관한 정보를 유지하는 데이터 오브젝트이며, 예컨대 로컬 사용자 ID나 로컬 사용자의 e-메일 어드레스와 같은 로컬 사용자를 식별하는 로컬 사용자 정보를 포함한다. JWT는 인가 코드 요구에서 송신되는 클라이언트 ID와, 스테이트 파라미터로서 설정된 로그인 컨텍스트를 포함한다. JWT에서의 파라미터의 설정에 대해서는, 도 11을 참조하여 후술할 것이다.
S7.0에서 인가 코드 요구를 수신한 인가 서버(200)는, S1.3 내지 S1.6에서의 처리를 수행하는 것에 의해 인가 서버(200)에 로그인한 사용자에 대하여 클라이언트(400)의 인가를 요구한다. 사용자는 클라이언트(400)를 인가하여, 인가 조작을 실행할 수 있다. S1.6에서의 인가 조작이 실행되면, 인가 서버(200)는 인가 코드를 발행한다. 발행된 인가 코드는 클라이언트 ID, 사용자 ID 및 리다이렉트 URL과 연관하여 보존된다. 이러한 경우, 클라이언트 ID "client_01", 사용자 ID "user_01" 및 리다이렉트 URL "https://192.168.1.1/redirect"와 연관하여 인가 코드가 보존된다.
인가 코드 및 S7.0에서 스테이트 파라미터의 값으로서 설정된 로그인 컨텍스트를 리다이렉트 URL에 리다이렉트하라는 지시가 웹 브라우저에 응답으로서 송신된다(S7.1). 여기서, 인가 서버(200)는 인가 코드와 스테이트 파라미터에 대하여 공개 키를 사용하는 것에 의해 디지털 서명을 추가한다. 리다이렉트 URL에서 인가 코드 응답을 수신한 클라이언트(400)는 클라이언트(400)에 유지되는 비밀 키를 사용하는 것에 의해 디지털 서명 값을 검증하고, S7.1에서 수신된 인가 코드 응답의 콘텐츠가 변경되지 않은지를 검증한다. 더 구체적으로, 클라이언트(400)는, 클라이언트(400)에 보존된 로그인 컨텍스트와 S7.1에서 수신된 로그인 컨텍스트가 일치하는 것을 검증하고, 인가 코드 요구와 인가 코드 응답이 서로 연관되는 것으로 결정할 수 있다.
S7.1에서 수신된 인가 코드 응답의 콘텐츠가 변경되지 않은 것이 검증된 후에 인가 서버(200)로부터 클라이언트(400)로 인가 토큰을 발행하는 처리(S2.0 내지 S2.2)가 실시예 1에 따른 패턴(S5.0 내지 S5.1, S2.1)으로 수행될 수 있기 때문에, 임의의 반복적인 설명은 생략할 것이다. 여기까지, 실시예 2에 따른 OAuth 2.0에 기초한 인가 코드 승인의 처리 플로우가 설명되었다.
다음으로, 도 11을 참조하여, S7.0에서의 인가 코드 요구에서 클라이언트(400)로부터 인가 서버(200)로 송신되는 JWT의 일례를 설명할 것이다. 도 8에서의 문자열과 동일한, JWT에 포함된 동일한 문자열의 임의의 반복적인 상세한 설명은 생략될 것이다. 페이로드부에서, iss(발행자) 및 sub(주체)뿐만아니라 스테이트가 설정된다. 이러한 경우, aud(사용자)에는 인가 서버(200)의 인가 엔드 포인트의 "https://xxx.com/authrization"이 설정된다. 또한, 스테이트에는 로그인 컨텍스트로서 "user://local_user_01, mail: local_user_01@abc.com"이 설정된다. 헤더부 및 페이로드부에서의 문자열들은 Base 64에 따라 인코딩되고, 그 문자열들에 대하여 클라이언트(400)에 유지되는 비밀 키를 사용하는 것에 의해 디지털 서명이 제공된다. 여기까지, S7.0에서의 인가 코드 요구에서 클라이언트(400)로부터 인가 서버(200)에 송신되는 JWT의 예가 설명되었다.
도 11이 JSON(JavaScript(등록 상표) Object Notation) 형식의 텍스트 데이터에 기입된 로그인 컨텍스트를 나타내지만, 로그인 컨텍스트는 그 형식을 갖는 것으로 한정되지 않는다. 클라이언트(400)가 S7.1에서의 인가 코드 응답을 수신할 때 로컬 사용자를 식별하기 위해 로그인 컨텍스트가 클라이언트(400)에 의해 사용되고, 예를 들어 로그인 컨텍스트에 가역, 또는 비가역 암호화를 수행하는 것에 의해 취득된 임의의 값일 수 있다.
실시예 2에 따르면, 클라이언트(400)에 의해 유지되는 기존 로그인 컨텍스트가 스테이트 파라미터의 값으로서 설정되어, 클라이언트(400)에서 스테이트 파라미터에 대해 설정되기 위한 새로운 값을 생성할 필요가 제거될 수 있고, 따라서 클라이언트(400)에서의 생성 및 관리에 대한 비용을 감소시킬 수 있다.
로그인 컨텍스트는 로컬 사용자가 고유하게 식별될 수 있고, 다른 것들과 중복하지 않는 정보이다. 로그인 컨텍스트는 클라이언트(400)에 로컬 사용자가 로그인할 때 클라이언트(400)에서 OS(도시하지 않음)에 의해 생성될 수 있고, 로컬 사용자가 로그오프할 때 소멸된다. 로컬 사용자에 의해 수행되는 로그인 조작에 응답한 로그인 컨텍스트의 생성은, 로그인 로컬 사용자가 웹페이지에 대해 액세스 권한을 갖는 웹페이지를 웹 브라우저 상에서 공중에 개방하게 한다. 로컬 사용자에 의해 수행되는 로그오프 조작에 응답하여 로그인 컨텍스트가 소멸되어, 로컬 사용자가 액세스 권한을 갖는 웹페이지가, 웹페이지를 다른 사용자들에게 개방하게 하는 것이 방지될 수 있고, 보안이 보장될 수 있다.
한편, 스테이트 파라미터는 인가 코드 요구를 인가 코드 응답과 고유하게 연관시키기 위해 추측불가능하고 중복하지 않는 값을 갖는다. 즉, 본 실시예에 따르면, 스테이트 파라미터의 값이 로그인 컨텍스트에 의해 치환되어, 스테이트 파라미터의 특성(다른 것들과 중복하지 않는 정보)이 유지될 수 있고, 클라이언트(400)에서의 스테이트 파라미터의 값들을 생성하고 관리하는 비용이 감소될 수 있다.
인가 코드 요구와 인가 코드 응답에서 JWT의 사용은, OAuth 2.0에 기초한 처리의 실행에서 안전성을 손상시키지 않고서, 인가 서버(200)와 클라이언트(400) 사이에서, 사용자 정보를 포함하는 스테이트 파라미터의 안전한 교환을 가능하게 한다.
실시예 3
일부 경우에서, 사용자 ID를 클라이언트(400)의 로컬 사용자 ID와 고유하게 연관하여 인가 서버(200)에 보존하는 것 대신에, 하나의 사용자 ID가 복수의 로컬 사용자 ID와 연관될 수 있다. 더 구체적으로는, 일부 경우에, 클라이언트(400)에서는 각 사용자마다 로컬 사용자 ID가 등록될 수 있지만, 인가 서버(200)에서는 각 사용자마다 사용자 ID를 발행하는 것 대신에, 공통의 사용자 ID가 복수의 로컬 사용자 ID에 사용될 수 있다. 예를 들어, 복수의 어카운트(사용자 ID) 생성의 복잡함 때문에, 하나의 부문 내에서 업무를 위해 공통인 어카운트가 생성될 수 있고, 복수의 부원에 의해 공유될 수 있다.
그 결과, 동의 정보(클라이언트 ID와 사용자 ID를 포함함)가 클라이언트(400)의 복수의 사용자에 의해 공유된다. 그 후, 하나의 사용자가 인가 조작을 실행하고 있어도, 동의 정보에 포함되는 사용자 ID를 공유하는 다른 사용자가 인가 조작을 실행하는 문제가 발생한다.
사용자 ID가 공유되는 것을 방지하기 위해, 인가 서버(200)에 사용자 ID들이 개별적으로 저장될 수 있지만, 이는 각 사용자마다 사용자 ID의 발행을 필요로 하고, 사용자 ID들의 생성 및 관리를 위한 비용을 요구한다. 실시예 3에 따르면, 인가 서버(200)에서 새로운 사용자 ID를 생성 및 관리하지 않고서, 복수의 사용자에 의해 사용자 ID가 공유될 수 있다.
먼저, 인가 서버(200)에서 관리되는 동의 정보에 대해서 설명할 것이다. 표 3은 인가 서버(200)에 저장되는 동의 정보의 일례이다.
Figure 112018086081028-pat00004
표 3에서, "client_id"는 클라이언트 ID를 나타내고, "user_id"는 인가 서버(200)에 등록된 사용자의 사용자 ID를 나타내고, "login_context"는 S7.0에서의 인가 코드 요구에 응답하여 인가 서버(200)에 의해 송신되는 로그인 컨텍스트를 나타낸다. 로그인 컨텍스트는, 클라이언트(400)에 로그인한 로컬 사용자에 관한 로컬 사용자 정보를 포함한다. "login_context"에 설정된 값의 부재는, 로그인 컨텍스트가 동의 정보로서 고려되지 않는 것을 의미하고, "login_context"에 설정된 값의 존재는 로그인 컨텍스트가 동의 정보로서 고려되는 것을 의미한다. 플래그 "consent"는 S1.5에서의 인가 확인 화면에서 사용자가 인가를 동의하는지를 나타낸다. "1"을 갖는 플래그 "consent"는 클라이언트(400)의 인가가 동의된 것을 나타내지만, "0"을 갖는 플래그 "consent"는 인가가 거부된 것을 나타낸다. 표 3에서의 동의 정보 테이블에서의 레코드들의 부재는, 사용자가 아직 인가하지 않은 것을 나타낸다. 동의 정보 테이블의 대안적인 형태로서, "consent"가 제공되지 않을 수 있다. 그 형태에 따르면, 사용자가 클라이언트(400)의 인가를 거부한 경우에 동의 정보 테이블로부터 레코드가 삭제된다.
표 3에서의 동의 정보는, 인가 서버(200)가 사용자에 의해 수행되는 인가 조작을 수신(S1.6)할 때 생성된다. S1.6에서는, 클라이언트 ID와 사용자 ID를 포함하는 동의 정보가 인가 서버(200)에서 관리된다. 이 실시예에 따르면, 클라이언트 ID와 사용자 ID에 추가하여, S7.0(도 10)에서 수신된 로그인 컨텍스트가 표 3에서와 같이 동의 정보로서 관리된다.
동의 정보에서 로그인 컨텍스트가 포함되는지를 판정하는 기준은, 클라이언트(400)에 로그인 컨텍스트가 사전 설정되는지에 따른다. 인가 서버(200)는, 클라이언트(400)에 로그인 컨텍스트가 존재하는지를 주로 다음의 2개 형태에 기초하여 판정할 수 있다. 하나의 형태는, S0.0에서 클라이언트(400)에 관한 정보를 등록할 때 클라이언트(400)는 로그인 컨텍스트를 갖는 멀티 사용자 디바이스인 것을 인가 서버(200)에 통지한다.
두 번째 형태에 따르면, 웹 브라우저가 인가 서버(200)에 대하여 인가 요구를 송신할 때, 스테이트 파라미터와, 스테이트 파라미터의 값이 로그인 컨텍스트인 것을 통지하는 다른 파라미터가 추가적으로 송신된다. 여기서 이 실시예에 따르면, 형태들 중 하나에 기초한 인가 서버(200)는 클라이언트(400)에 로그인 컨텍스트가 존재한다고 판정하고, 사용자에 관한 동의 정보에 로그인 컨텍스트가 포함되는 것으로 가정한다.
도 12를 참조하여, 웹 브라우저에 인가 확인 화면을 표시할지를 판정하는 플로우를 설명할 것이다. 도 12에서의 플로우는, S12.1에서 인가 서버(200)가 인가 코드 요구를 수신한 후에, S12.2에서 로그인 화면을 표시할지를 판정하기 위해 실행되는 것이다. 도 5a는 로그인 화면의 일례를 도시한다. 웹 브라우저에 그 로그인 화면을 통해 사용자 ID와 패스워드가 입력될 때, 인가 서버(200)는 인증 요구를 웹 브라우저로부터 수신한다(S12.3). S12.1, S12.2 및 S12.3에서의 처리는, 도 10에서의 S7.0, S1.3 및 S1.4에서의 처리와 동일하기 때문에, 임의의 반복적인 상세한 설명은 생략할 것이다.
인가 서버(200)는 S12.3에서 수신된 사용자 ID와 S7.0에서 수신된 로그인 컨텍스트와 클라이언트 ID가, 동의 정보로서 인가 서버(200)에 사전에 보존되는 사용자 ID, 클라이언트 ID 및 로그인 컨텍스트와 일치하는지를 판정한다(S12.4).
사전 등록된 동의 정보가, S12.3에서의 사용자 ID와 S7.0에서의 로그인 컨텍스트와 클라이언트 ID와 일치하는 것으로 S12.4에서 판정되는 경우에, 처리는 S12.5로 진행한다. 여기서, 인가 서버(200)에 동의 정보로서 등록된 일치된 사용자 ID, 클라이언트 ID 및 로그인 컨텍스트는, 사용자 ID와 로그인 컨텍스트에 의해 식별되는 사용자가 클라이언트 ID에 의해 식별되는 클라이언트(400)를 사용하는 것에 의해 인가 조작을 이미 실행한 것을 나타낸다.
한편, S12.4에서, 사전 등록된 동의 정보가, S12.3에서의 사용자 ID와 S7.0에서의 로그인 컨텍스트와 클라이언트 ID와 일치하는 것으로 판정되지 않은 경우에는, 사용자가 아직 인가 조작을 실행하지 않은 것으로 판정한다. 그 후, S12.3에서의 사용자 ID와 S7.0에서의 로그인 컨텍스트와 클라이언트 ID에 기초하여 새로운 동의 정보를 생성한다(S12.9). 새롭게 생성된 동의 정보는, 표 3에 도시된 일례인 동의 정보에 레코드로서 추가된다.
S12.4에서 일치된 동의 정보가 판정된 후, 사전 등록된 동의 정보가 사용자에 의해 그 인가가 동의된 정보인지가 판정된다(S12.5). 더 구체적으로는, 표 3에서의 consent의 값을 확인한다. consent가 "1"을 갖는 경우, 인가 확인 화면(S1.5)과 인가 조작(S1.6)을 실행하지 않고서, 클라이언트(400)에의 인가 코드 응답이 실행된다. 그 후 처리 플로우는 종료된다.
한편, consent가 "0"을 갖는 경우 또는 S12.9에서 새로운 동의 정보가 생성된 경우에는, 인가에 대한 동의를 묻기 위한 화면인 인가 확인 화면이 웹 브라우저에 반환된다(S12.6). 사용자의 조작에 기초하여 동의 결과가 수신되고(S12.7), 동의 결과는 인가 서버(200)에 보존된다(S12.8). 표 3은 보존되는 동의 정보의 일례를 도시한다. S12.6 및 S12.7에서의 처리는, 도 10에서의 S1.5 및 S1.6에서의 처리와 동일하기 때문에, 임의의 반복적인 상세한 설명은 생략할 것이다. 웹 브라우저에 인가 확인 화면을 표시할지를 판정하는 플로우가 설명되었다.
실시예 3에 따를면, 로그인 컨텍스트는 그때까지의 동의 정보(사용자 ID와 클라이언트 ID를 포함함)에 추가된다. 사용자 ID와 로그인 컨텍스트에 대해 불일치할 때마다, 인가 동의 화면이 표시될 수 있고, 사용자 정보를 새로 생성하고 관리하지 않고서, 복수의 사용자에 의해 동의 정보가 공유되는 것이 방지될 수 있다.
실시예 4
실시예 4에 따르면, 인가 서버(200)에서의 인가 코드들의 생성 및 관리 부하들의 감소를 위해 인가 토큰을 발행하는 데 인가 코드가 사용되지 않는다.
도 13을 참조하여, 실시예 4에 따르면 OAuth 2.0에 기초한 인가 코드 승인의 처리를 설명할 것이다. 유사한 부호들은 전술한 실시예들 및 이 실시예에서 유사한 부분들을 지칭하고, 임의의 반복적인 상세한 설명은 생략할 것이다. 실시예 4가 종래 기술(도 1)과의 조합을 참조하여 후술되지만, 실시예 4는 이에 한정되지 않고, 실시예 1(도 6), 실시예 2(도 10), 또는 실시예 3과 조합될 수 있다.
먼저, S1.1에서 인가 플로우에 대한 개시 요구가 클라이언트(400)에 송신된 후에, 클라이언트(400)가 인가 코드 요구를 인가 서버(200)에 송신한다(S7.2). S7.2에서 송신되는 정보는 S1.2에서의 정보와 동일하지만, 인가 코드 요구의 응답 타입으로서 "code" 대신에, "id_token"이 지정된다. 인가 코드 요구의 응답 타입으로서 "id_token"을 지정하는 것은, 인가 서버(200)가 인가 코드 응답에서 인가 코드 대신, 사용자 ID를 클라이언트(400)에 송신할 수 있게 한다.
S1.3 내지 S1.6에서 사용자가 클라이언트(400)의 인가를 동의한 후, 인가 서버(200)는 클라이언트(400)에 인가 코드 응답을 송신한다(S7.3). 이러한 경우, 인가 서버(200)는 사용자 ID(user_id) 및 스테이트 파라미터를, 리다이렉트 URL에 리다이렉트하라는 지시로 웹 브라우저에 응답한다. 더 구체적으로는 인가 서버(200)는, 사용자 ID와 스테이트 파라미터에 대하여 클라이언트(400)의 공개 키를 사용하는 것에 의해 디지털 서명을 추가한다.
S7.3에서의 인가 코드 응답을 수신한 클라이언트(400)는, 클라이언트(400)가 유지하는 비밀 키를 사용하는 것에 의해 디지털 서명을 검증하고, 인가 코드 응답의 콘텐츠가 변경되어 있지 않은 것을 검증한다. 클라이언트(400)는, 인가 코드 요구에서 송신한 스테이트 파라미터와 인가 코드 응답에서 수신한 스테이트 파라미터가 일치하는 것을 추가로 검증하여, 인가 코드 요구와 인가 코드 응답이 서로 연관되는 것으로 판정한다.
인가 코드 요구와 인가 코드 응답이 서로 연관된 것으로 판정된 후, 클라이언트(400)는 인가 서버(200)의 토큰 엔드 포인트에 대하여 토큰 요구를 송신한다(S7.4). 이 토큰 요구는 인가 플로우가 인가 코드 승인인 것을 나타내는 "grant_type=authorization_code"를 포함한다. OAuth 2.0의 규칙에는 "grant_type"의 값은 "authorization_code"이지만, 본 실시예에 따르면, 인가 토큰을 발행하기 위해서 사용되는 것은 인가 코드 대신 사용자 ID이다.
토큰 요구는 클라이언트 시크릿, 클라이언트 ID 및 S7.3에서 획득한 사용자 ID로서 JWT(JSON web Token)을 추가로 포함한다. 더 구체적으로, 여기서 OAuth 2.0 JWT 프로파일에서 선언된 client_assertion_type:jwt-bearer에서, client_assertion에 JWT를 파라미터로서 설정한다. 여기서, 클라이언트 ID는 "client_01"이고, 사용자 ID는 "user_01"인 것으로 가정한다. 클라이언트(400)는, 클라이언트(400)에 의해 유지되는 비밀 키를 사용하는 것에 의해 클라이언트 ID 및 사용자 ID에 대하여 디지털 서명을 추가한다.
S7.4에서 토큰 요구를 수신한 인가 서버(200)는, 클라이언트 ID로부터 식별된 공개 키를 사용하는 것에 의해 토큰 요구에 추가된 디지털 서명을 검증하여, 클라이언트(400)를 인증한다. 수신된 클라이언트 ID와 사용자 ID가 사용되어 동의 정보를 획득하여, 사용자가 클라이언트(400)의 인가를 동의하는지를 판정한다. 사용자가 인가를 동의하는 것으로 판정된 경우, 인가 서버(200)는 인가 토큰을 발행하고, 토큰 응답으로서 발행된 인가 토큰을 클라이언트(400)에 송신한다(S7.5). 여기서, 인가 토큰을 다시 획득하기 위한 리프레시 토큰을 발행하지 않는다. 이는, 도 1을 참조하여 설명된 인가 코드 승인의 플로우가, 인가 코드를 사용하는 것에 의해 인가 토큰을 발행하고, 인가 코드는 인가 토큰이 발행될 때 디스에이블되기 때문이다. 따라서, 다시 인가 코드 승인의 처리 플로우를 실행하는 처리를 생략하기 위해서 리프레시 토큰을 발행하고, 인가 서버(200)와 클라이언트(400)가 리프레시 토큰을 저장한다. 그러나 본 실시예에 따르면, 인가 토큰은 동의 정보(클라이언트 ID와 사용자 ID를 포함함)에 기초하여 발행된다. 따라서, 다시 인가 토큰을 획득하기 위해, 인가 서버(200)에 관리되는 동의 정보를 사용하는 것에 의해 토큰 요구가 실행될 수 있다.
여기까지, 인가 토큰을 발행하기 위해 인가 코드를 사용하지 않는 처리가 설명되었다. 실시예 4에 따르면, 인가 서버(200)는 인가 코드와 리프레시 토큰의 발행 및 보관 처리를 생략할 수 있고, 이는 인가 서버(200)에서의 인가 코드들과 리프레시 토큰들의 관리 비용을 감소시킬 수 있다. 클라이언트(400)에서의 리프레시 토큰 저장 처리의 생략은, 클라이언트(400)에서 관리 비용을 더 감소시킬 수 있다.
실시예 4와 실시예 3(동의 정보에 로그인 컨텍스트를 포함함)의 조합은, S7.4에서의 토큰 요구에서 클라이언트 ID, 사용자 ID 및 로그인 컨텍스트를 송신한다.
다른 실시예들
리다이렉트 URL 및 클라이언트(400)에 관한 정보가 JWT에 포함되는 실시예(실시예 1), 로그인 컨텍스트가 스테이트 파라미터로서 설정되는 실시예(실시예 2), 및 인가 코드를 발행하지 않고서 인가 토큰이 발행되는 실시예(실시예 4)를 포함하는 전술한 실시예들 중, 임의의 조합들이 가능하다.
인가 코드 요구 시에, 인가의 범위를 나타내는 스코프(scope) 파라미터를 지정할 수 있다. 예를 들어, 인가 코드 요구 시에 지정된 스코프 파라미터를 인가 코드, 인가 토큰, 및 리프레시 토큰과 연관하여 관리할 수 있다. 표시된 인가 확인 화면(5100)에서 스코프 파라미터에 의해 나타나는 인가의 범위를 표시할 수 있다.
본 개시내용의 실시예(들)는, 전술한 실시예(들) 중 하나 이상의 기능을 실행하기 위해 저장 매체(보다 완전하게는 '비일시적 컴퓨터 판독가능 저장 매체'라 칭할수도 있음)에 기록된 컴퓨터 실행가능 명령어들(예를 들어, 하나 이상의 프로그램)을 판독 및 실행하고 그리고/또는 전술한 실시예(들) 중 하나 이상의 기능을 실행하는 하나 이상의 회로(예를 들어, 주문형 집적 회로(ASIC))를 포함하는 시스템 또는 장치의 컴퓨터에 의해, 그리고 예를 들어 전술한 실시예(들) 중 하나 이상의 기능을 실행하기 위해 저장 매체로부터 컴퓨터 실행가능 명령어들을 판독 및 실행함으로써 그리고/또는 전술한 실시예(들) 중 하나 이상의 기능을 실행하기 위해 하나 이상의 회로를 제어함으로써 시스템 또는 장치의 컴퓨터에 의해 실행되는 방법에 의해 실현될 수도 있다. 컴퓨터는 하나 이상의 프로세서(예를 들어, 중앙 처리 유닛(CPU), 마이크로 처리 유닛(MPU))를 포함할 수 있고 컴퓨터 실행가능 명령어를 판독 및 실행하기 위한 별도의 컴퓨터 또는 별도의 프로세서의 네트워크를 포함할 수 있다. 컴퓨터 실행가능 명령어들은 예를 들어 네트워크 또는 저장 매체로부터 컴퓨터에 제공될 수 있다. 저장 매체는, 예를 들어 하드 디스크, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 분산형 컴퓨팅 시스템의 스토리지, 광디스크(예를 들어, 콤팩트디스크(CD), 디지털 다기능 디스크(DVD) 또는 블루레이 디스크(BD)™), 플래시 메모리 디바이스, 메모리 카드 등 중 하나 이상을 포함할 수 있다.
(기타의 실시예)
본 발명은, 상기의 실시형태의 1개 이상의 기능을 실현하는 프로그램을, 네트워크 또는 기억 매체를 개입하여 시스템 혹은 장치에 공급하고, 그 시스템 혹은 장치의 컴퓨터에 있어서 1개 이상의 프로세서가 프로그램을 읽어 실행하는 처리에서도 실현가능하다.
또한, 1개 이상의 기능을 실현하는 회로(예를 들어, ASIC)에 의해서도 실행가능하다.
본 개시내용이 예시적인 실시예들을 참조하여 설명되었지만, 본 개시내용이 개시된 예시적인 실시예들로 한정되지 않음을 이해해야 한다. 이하의 청구항의 범위는 이러한 모든 변형과 동등한 구조 및 기능을 포함하도록 최광의로 해석되어야 한다.

Claims (13)

  1. 권한 위양 시스템으로서,
    적어도 프로세서 및
    상기 적어도 프로세서에 결합되고, 명령어들을 저장한 적어도 메모리
    를 포함하며,
    상기 명령어들은, 상기 적어도 프로세서에 의해 실행될 때,
    클라이언트에 의한 리소스 서버로의 액세스가 사용자에 의해 허가될 때 인가 서버에 의해 인가 코드를 발행하기 위한 인가 코드 요구를, 상기 클라이언트로부터 상기 인가 서버로 송신하는 송신 수단;
    상기 인가 코드 요구에 대한 응답인 인가 코드 응답을, 상기 인가 서버로부터 상기 클라이언트로 수신하는 수신 수단;
    상기 클라이언트에 상기 사용자가 로그인할 때 로그인 컨텍스트를 생성하는 생성 수단의 역할을 하도록 협력하며,
    상기 송신 수단에 의해 송신되는 상기 인가 코드 요구는, 상기 인가 코드 요구를 상기 인가 코드 응답과 연관시키기 위한 파라미터의 값으로서 상기 로그인 컨텍스트가 설정된 상기 파라미터와 서명 정보를 포함하고,
    상기 인가 서버에서 상기 서명 정보가 검증된 후에, 상기 인가 코드 요구에 대응하는 상기 인가 코드 응답이 상기 클라이언트로 송신되고,
    상기 클라이언트는,
    상기 수신 수단에 의해 수신된 상기 인가 코드 응답에 포함되는 파라미터와, 상기 송신 수단에 의해 송신된 상기 인가 코드 응답에 포함된 파라미터를 사용하여, 상기 인가 코드 응답이 상기 인가 코드 요구에 대응하는 것임을 검증하는, 권한 위양 시스템.
  2. 제1항에 있어서,
    상기 서명 정보는,
    상기 클라이언트에 의해 유지되는 암호 키를 사용하는 것에 의해 상기 인가 코드 요구에 추가되고,
    상기 인가 서버는,
    상기 인가 서버에 의해 유지되는 복호 키를 사용하는 것에 의해 상기 인가 코드 요구에 추가되는 상기 서명 정보를 검증하는, 권한 위양 시스템.
  3. 제1항에 있어서,
    상기 송신 수단은,
    상기 클라이언트에 의한 상기 리소스 서버로의 액세스를 상기 인가 서버에 의해 허가하기 위한 인가 코드 요구를, 사용자 에이전트를 통해 상기 클라이언트로부터 상기 인가 서버로 송신하고,
    상기 파라미터는 스테이트(state) 파라미터이며,
    상기 로그인 컨텍스트는,
    로컬 사용자 ID와 상기 로컬 사용자의 e-메일 어드레스 중 적어도 하나를 포함하고 상기 로컬 사용자를 고유하게 식별하는 정보인, 권한 위양 시스템.
  4. 제1항에 있어서,
    상기 인가 서버에 의해 수신된 파라미터에 설정된 상기 로그인 컨텍스트는, 상기 클라이언트에 의한 상기 리소스 서버로의 액세스를 허가하기 위해 사용되는 동의 정보에 포함되는, 권한 위양 시스템.
  5. 제4항에 있어서,
    상기 동의 정보는,
    상기 클라이언트를 식별하는 클라이언트 ID와, 상기 인가 서버에 로그인하는 사용자를 식별하는 사용자 ID를 적어도 포함하는, 권한 위양 시스템.
  6. 제5항에 있어서,
    상기 클라이언트는, 상기 클라이언트 ID와 상기 사용자 ID를 포함하고 상기 클라이언트가 인가 토큰을 획득하도록 사용가능한 토큰 요구와, 서명 정보를 상기 인가 서버에 송신하며,
    상기 권한 위양 시스템은 발행 수단을 추가로 포함하고, 상기 발행 수단은,
    상기 토큰 요구를 수신한 상기 인가 서버가 암호 키를 사용하는 것에 의해 상기 토큰 요구와 함께 수신한 상기 서명 정보를 검증한 후에, 그리고
    상기 발행 수단이, 상기 토큰 요구에 포함되는 상기 클라이언트 ID에 의해 식별되는 상기 클라이언트에 의한 상기 리소스 서버로의 액세스가 상기 토큰 요구에 포함되는 상기 사용자 ID에 의해 식별되는 상기 사용자에 의해 인가되는 것으로 결정한 후에,
    상기 인가 서버로부터 상기 클라이언트로 상기 인가 토큰을 발행하는, 권한 위양 시스템.
  7. 제6항에 있어서,
    상기 인가 토큰은,
    상기 클라이언트가 상기 리소스 서버에 액세스하도록 인가되는 것을 나타내는 토큰인, 권한 위양 시스템.
  8. 제6항에 있어서,
    상기 발행 수단은,
    상기 발행 수단이, 상기 토큰 요구에 포함되는 상기 클라이언트 ID와 사용자 ID에 의해 식별되는 동의 정보에 대하여, 상기 클라이언트에 의한 상기 리소스 서버로의 액세스를 상기 사용자가 인가한 것을 나타내는 플래그가 추가되는 것으로 결정한 후에, 상기 인가 토큰을 발행하는, 권한 위양 시스템.
  9. 제1항에 있어서,
    상기 송신 수단에 의해 송신되는 상기 인가 코드 요구는, 상기 인가 코드 응답을 반환하기 위해 상기 인가 서버에 의해 사용되는 응답처(response destination)를 지정하는 응답처 정보와 서명 정보를 포함하고,
    상기 권한 위양 시스템은, 상기 인가 서버에서 상기 서명 정보가 검증된 후에, 상기 인가 서버에 의해, 상기 인가 코드 요구에 포함되는 상기 응답처 정보에 기초하여 상기 송신 수단에 의해 송신된 인가 코드 요구에 대한 인가 코드 응답을 송신하는 수단을 추가로 포함하는, 권한 위양 시스템.
  10. 권한 위양 시스템에 대한 제어 방법으로서,
    클라이언트에 의한 리소스 서버로의 액세스가 사용자에 의해 허가될 때, 인가 서버에 의해 인가 코드를 발행하기 위한 인가 코드 요구를 상기 클라이언트로부터 상기 인가 서버로 송신하는 송신 단계;
    상기 인가 코드 요구에 대한 응답인 인가 코드 응답을, 상기 인가 서버로부터 상기 클라이언트로 수신하는 수신 단계; 및
    상기 클라이언트에 상기 사용자가 로그인할 때 로그인 컨텍스트를 생성하는 생성 단계
    를 포함하고,
    상기 송신 단계에 의해 송신되는 상기 인가 코드 요구는,
    상기 인가 코드 요구를 상기 인가 코드 응답과 연관시키기 위한 파라미터의 값으로서 상기 로그인 컨텍스트가 설정된 상기 파라미터와 서명 정보를 포함하고,
    상기 인가 서버에서 상기 서명 정보가 검증된 후에, 상기 인가 코드 요구에 대응하는 상기 인가 코드 응답이 상기 클라이언트로 송신되고,
    상기 클라이언트는,
    상기 수신 단계에 의해 수신된 상기 인가 코드 응답에 포함되는 파라미터와, 상기 송신 단계에 의해 송신된 상기 인가 코드 응답에 포함되는 파라미터를 사용하여, 상기 인가 코드 응답이 상기 인가 코드 요구에 대응하는 것임을 검증하는, 권한 위양 시스템에 대한 제어 방법.
  11. 클라이언트로서,
    클라이언트에 의한 리소스 서버로의 액세스가 사용자에 의해 허가될 때, 인가 서버에 의해 인가 코드를 발행하기 위한 인가 코드 요구를 상기 클라이언트로부터 상기 인가 서버로 송신하는 송신 수단; 및
    상기 인가 코드 요구에 대한 응답인 인가 코드 응답을 수신하는 수신 수단
    을 포함하고,
    상기 송신 수단에 의해 송신되는 상기 인가 코드 요구는,
    상기 인가 코드 요구를 상기 인가 코드 응답과 연관시키기 위한 파라미터의 값으로서 로그인 컨텍스트가 설정된 상기 파라미터와 서명 정보를 포함하고,
    상기 인가 서버에서 상기 서명 정보가 검증된 후에, 상기 클라이언트는 상기 인가 코드 요구에 대응하는 상기 인가 코드 응답을 상기 인가 서버로부터 수신하고,
    상기 클라이언트는, 상기 수신 수단에 의해 수신된 상기 인가 코드 응답에 포함되는 파라미터와, 상기 송신 수단에 의해 송신된 상기 인가 코드 응답에 포함되는 파라미터를 사용하여, 상기 인가 코드 응답이 상기 인가 코드 요구에 대응하는 것임을 검증하는, 클라이언트.
  12. 제11항에 있어서,
    상기 송신 수단은,
    상기 클라이언트에 의한 상기 리소스 서버로의 액세스를 상기 인가 서버에 의해 허가하기 위한 인가 코드 요구를, 사용자 에이전트를 통해 상기 클라이언트로부터 상기 인가 서버로 송신하고,
    상기 파라미터는 스테이트 파라미터이며,
    상기 로그인 컨텍스트는,
    로컬 사용자 ID와 상기 로컬 사용자의 e-메일 어드레스 중 적어도 하나를 포함하고 상기 로컬 사용자를 고유하게 식별하는 정보인, 클라이언트.
  13. 제1항에 있어서,
    상기 생성 수단은,
    상기 사용자에 의한 허가에 따라, 상기 클라이언트가 상기 리소스 서버에 의해 제공되는 개방 웹 서비스를 사용하도록 인가하는 처리를 위한 인가 플로우가 개시되기 전에, 상기 클라이언트에 상기 사용자가 로그인할 때 로그인 컨텍스트를 생성하는, 권한 위양 시스템.
KR1020180102419A 2017-08-31 2018-08-30 권한 위양 시스템, 그 제어 방법 및 클라이언트 KR102313859B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017167284A JP2019046059A (ja) 2017-08-31 2017-08-31 権限委譲システム、制御方法、およびプログラム
JPJP-P-2017-167284 2017-08-31

Publications (2)

Publication Number Publication Date
KR20190024817A KR20190024817A (ko) 2019-03-08
KR102313859B1 true KR102313859B1 (ko) 2021-10-18

Family

ID=65514830

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020180102419A KR102313859B1 (ko) 2017-08-31 2018-08-30 권한 위양 시스템, 그 제어 방법 및 클라이언트

Country Status (4)

Country Link
US (1) US10785204B2 (ko)
JP (1) JP2019046059A (ko)
KR (1) KR102313859B1 (ko)
CN (1) CN109428891B (ko)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11108762B2 (en) 2018-06-05 2021-08-31 The Toronto-Dominion Bank Methods and systems for controlling access to a protected resource
JP7170550B2 (ja) * 2019-01-28 2022-11-14 キヤノン株式会社 管理装置およびその制御方法
CN110225045A (zh) * 2019-06-18 2019-09-10 平安科技（深圳）有限公司 全链路数据鉴权方法、装置、设备及存储介质
JP7218679B2 (ja) * 2019-06-21 2023-02-07 富士通株式会社 情報処理装置、情報処理方法、および情報処理プログラム
EP3994593B1 (en) * 2019-07-05 2023-08-30 Visa International Service Association System, method, and computer program product for third-party authorization
CN110798447B (zh) * 2019-09-18 2021-10-08 广州朗国电子科技有限公司 一种基于网络通信的智能终端本地授权方法、装置及系统
CN113015974B (zh) 2019-10-21 2024-05-28 谷歌有限责任公司 针对隐私保护的可验证同意
CN110852724B (zh) * 2019-11-19 2023-03-14 深圳前海环融联易信息科技服务有限公司 一种流程转授权的方法、装置、计算机设备及存储介质
US11463258B2 (en) 2020-03-13 2022-10-04 Ebay Inc. Secure token refresh
CN111949958B (zh) * 2020-08-14 2023-08-18 中国工商银行股份有限公司 Oauth协议中的授权认证方法及装置
CN112564916A (zh) * 2020-12-01 2021-03-26 上海艾融软件股份有限公司 应用于微服务架构的访问客户端认证系统
CN113612744B (zh) * 2021-07-23 2023-09-22 天津中新智冠信息技术有限公司 远程授权系统和方法
US20230093470A1 (en) * 2021-09-17 2023-03-23 Salesforce, Inc. Account authorization mapping
CN113569204B (zh) * 2021-09-27 2022-06-10 北京华安天成智能技术有限公司 远程生产授权管理系统及方法
JP2023140742A (ja) * 2022-03-23 2023-10-05 東芝テック株式会社 画像形成装置
CN115996141B (zh) * 2022-11-18 2024-09-20 深圳市蓝凌软件股份有限公司 文件访问认证方法、装置、设备和存储介质
CN117331964B (zh) * 2023-12-01 2024-02-27 成都明途科技有限公司 数据查询方法、装置、设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170142108A1 (en) * 2015-11-16 2017-05-18 Mastercard International Incorporated Systems and Methods for Authenticating an Online User Using a Secure Authorization Server

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6066647B2 (ja) * 2012-09-27 2017-01-25 キヤノン株式会社 デバイス装置、その制御方法、およびそのプログラム
US8615794B1 (en) * 2013-01-09 2013-12-24 Ping Identity Corporation Methods and apparatus for increased security in issuing tokens
JP6439370B2 (ja) 2014-05-28 2018-12-19 株式会社リコー 情報処理システム、情報処理方法、情報処理装置及びプログラム
US9912648B2 (en) * 2014-07-15 2018-03-06 Square, Inc. Two-factor authentication with push notification for a security code
JP2017004301A (ja) * 2015-06-11 2017-01-05 キヤノン株式会社 認証サーバーシステム、方法、プログラムおよび記憶媒体
CN106714075B (zh) * 2015-08-10 2020-06-26 华为技术有限公司 一种处理授权的方法和设备
CN105978947A (zh) * 2016-04-27 2016-09-28 努比亚技术有限公司 对同一账号登录设备数量控制的方法及移动终端
CN105897757B (zh) * 2016-06-12 2019-01-04 上海携程商务有限公司 授权认证系统及授权认证方法
CN106534143A (zh) * 2016-11-28 2017-03-22 上海斐讯数据通信技术有限公司 一种跨应用认证授权的方法和系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170142108A1 (en) * 2015-11-16 2017-05-18 Mastercard International Incorporated Systems and Methods for Authenticating an Online User Using a Secure Authorization Server

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
D. Hardt, "The OAuth 2.0 Authorization Framework", IETF RFC 6749(2012.10.)*

Also Published As

Publication number Publication date
CN109428891A (zh) 2019-03-05
US20190081943A1 (en) 2019-03-14
KR20190024817A (ko) 2019-03-08
CN109428891B (zh) 2022-05-10
JP2019046059A (ja) 2019-03-22
US10785204B2 (en) 2020-09-22

Similar Documents

Publication Publication Date Title
KR102313859B1 (ko) 권한 위양 시스템, 그 제어 방법 및 클라이언트
KR102362456B1 (ko) 권한 위양 시스템, 그 제어 방법 및 저장 매체
KR102390108B1 (ko) 정보 처리 시스템 및 제어 방법
US8997196B2 (en) Flexible end-point compliance and strong authentication for distributed hybrid enterprises
US10003587B2 (en) Authority transfer system, method, and authentication server system by determining whether endpoints are in same or in different web domain
EP3462701B1 (en) Device, control method of the same, and program
US8468359B2 (en) Credentials for blinded intended audiences
CN111316267A (zh) 使用委托身份的认证
EP3759629B1 (en) Method, entity and system for managing access to data through a late dynamic binding of its associated metadata
KR20210116407A (ko) 온라인 서비스 서버와 클라이언트 간의 상호 인증 방법 및 시스템
US10785213B2 (en) Continuous authentication
JP7043480B2 (ja) 情報処理システムと、その制御方法とプログラム
KR101545897B1 (ko) 주기적인 스마트카드 인증을 통한 서버 접근 통제 시스템
US20220116217A1 (en) Secure linking of device to cloud storage
KR102199747B1 (ko) Otp 기반의 가상키보드를 이용한 보안 방법 및 시스템

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant