KR102362456B1 - 권한 위양 시스템, 그 제어 방법 및 저장 매체 - Google Patents

권한 위양 시스템, 그 제어 방법 및 저장 매체 Download PDF

Info

Publication number
KR102362456B1
KR102362456B1 KR1020180102582A KR20180102582A KR102362456B1 KR 102362456 B1 KR102362456 B1 KR 102362456B1 KR 1020180102582 A KR1020180102582 A KR 1020180102582A KR 20180102582 A KR20180102582 A KR 20180102582A KR 102362456 B1 KR102362456 B1 KR 102362456B1
Authority
KR
South Korea
Prior art keywords
client
authorization
server
information
request
Prior art date
Application number
KR1020180102582A
Other languages
English (en)
Other versions
KR20190024821A (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 KR20190024821A publication Critical patent/KR20190024821A/ko
Application granted granted Critical
Publication of KR102362456B1 publication Critical patent/KR102362456B1/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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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
    • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H04L61/1511—
    • 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
    • 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/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/42—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • 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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)

Abstract

권한 위양 시스템은, 클라이언트로부터 인가 서버로 인가 코드 요구를 송신하도록 구성된 송신 유닛과, 인가 코드 응답을 수신하도록 구성된 수신 유닛과, 인가 서버에 의해, 인가 코드 요구에 포함된 수신처 정보에 기초하여, 인가 코드 응답을 반환하도록 구성된 응답 유닛을 포함한다.

Description

권한 위양 시스템, 그 제어 방법 및 저장 매체{AUTHORITY TRANSFER SYSTEM, CONTROL METHOD THEREFOR, AND STORAGE MEDIUM}
본 개시내용은 웹 서비스로의 액세스 권한을 검증하는 권한 위양 시스템, 그 제어 방법 및 저장 매체에 관한 것이다.
개개의 웹 서버는 웹 서비스를 제공하기 위해 개방 API를 제공하고, 웹 서비스들은 개방 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를 포함한다. 리다이렉트 URI는, 인가 서버로부터의 인가 코드 응답을 클라이언트가 수신하기 위해, 인가 서버가 인가 코드 응답을 송신하는 응답처(response destination)를 지정하는 응답처 정보(어드레스)이다. 인가 코드 응답이 후술될 것이다. 클라이언트 등록 요구를 수신한 인가 서버는 클라이언트를 식별하는 클라이언트 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에 기초한 인가 코드 승인의 처리 플로우이다.
도 2는 실시예에 따른 권한 위양 시스템을 도시하는 구성도이다.
도 3은 권한 위양 시스템에 포함된 디바이스들의 하드웨어 구성을 도시한다.
도 4a 내지 도 4d는 권한 위양 시스템에 포함되는 디바이스들의 소프트웨어 모듈 구성을 도시한다.
도 5a 및 도 5b는 웹 브라우저가 표시하는 사용자 인증 화면과, 클라이언트의 인가 확인 화면의 예들을 도시한다.
도 6은 실시예에 따른 OAuth 2.0에 기초한 인가 코드 승인의 처리 플로우를 도시한다.
도 7은 실시예에 따른 인가 코드 요구를 포함하는 JWT의 일례를 도시한다.
도 8은 실시예에 따른 인가 토큰을 포함하는 JWT의 일례를 도시한다.
도 9는 실시예에 따른, 클라이언트에서 리다이렉트 URI를 결정하는 처리 플로우를 도시한다.
도 1에 도시된 처리 플로우에서, 클라이언트의 URI를 변경하는 것은 인가 서버에 등록된 리다이렉트 URI의 변경을 필요로 할 수 있다. 따라서, 클라이언트의 URI가 변경될 때마다, 리다이렉트 URI를 변경하라는 요구가 인가 서버에 송신되어야 하고, 이는 시간과 노동이 든다. 클라이언트의 URI를 변경하는 것을 필요로 하는 예로서, 클라이언트가 프린터나 MFP 등의 디바이스인 경우, 클라이언트의 위치의 변경으로 인해 URI에 대한 호스트가 변경될 수 있다. 다른 예로서, 디바이스의 IP 어드레스가 DHCP 등의 프로토콜에 기초하여 자동으로 결정되는 경우에, 디바이스에 대한 전원을 스위치 온/오프(ON/OFF)하는 것은, 디바이스의 IP 어드레스를 변경시킬 수 있고, 그 결과, URI에 대한 호스트의 변경을 초래한다. 본 개시내용은, 처리의 실행에서의 안전성을 손상시키지 않고, 클라이언트의 URI가 변경된 경우에 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, PC 또는 스마트폰일 수 있다. 단말기(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(2001)는, RAM(2002), ROM(2003), 외부 메모리(external memory)(2011) 등으로부터 프로그램을 판독하고 프로그램의 명령어들을 실행하여, 클라이언트(400)에 대한 제어를 행하도록 구성된다. 후술될 시퀀스는 그러한 프로그램의 명령어들이 실행됨으로써 구현될 수 있다. CPU(2001)는 시스템 버스(2004)에 접속되는 블록들을 제어하도록 추가로 구성된다.
RAM(2002)은, CPU(2001)가 명령어들을 실행하기 위해 사용가능한 워크 메모리이다. ROM(2003)이나 외부 메모리(2011)에 보존된 OS나 애플리케이션 등의 프로그램이 RAM(2002)에 로딩될 수 있고, 그 프로그램의 명령어들을 CPU(2001)가 순차적으로 판독하고 실행할 수 있다. ROM(2003)은, 애플리케이션 프로그램 및 OS를 포함하는 내장된 프로그램 및 데이터를 저장하도록 구성된 저장 디바이스이다.
키보드 컨트롤러(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 112018086187418-pat00001
Figure 112018086187418-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 112018086187418-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 및 인가 확인 화면에 제시되는 클라이언트에 관한 정보의 사전 등록 및 관리에 대한 필요를 제거할 수 있고, 동적인 변경들을 용이하게 처리할 수 있다.
다른 실시예들
인가 코드 요구 시에, 인가의 범위를 나타내는 스코프(scope) 파라미터를 지정할 수 있다. 예를 들어, 인가 코드 요구 시에 지정된 스코프 파라미터를 인가 코드, 인가 토큰, 및 리프레시 토큰과 연관하여 관리할 수 있다. 표시된 인가 확인 화면(5100)에서 스코프 파라미터에 의해 나타나는 인가의 범위를 표시할 수 있다.
본 발명의 실시예(들)는, 전술한 실시예(들) 중 하나 이상의 기능을 실행하기 위해 저장 매체(보다 완전하게는 '비일시적 컴퓨터 판독가능 저장 매체'라 칭할수도 있음)에 기록된 컴퓨터 실행가능 명령어들(예를 들어, 하나 이상의 프로그램)을 판독 및 실행하고 그리고/또는 전술한 실시예(들) 중 하나 이상의 기능을 실행하는 하나 이상의 회로(예를 들어, 주문형 집적 회로(ASIC))를 포함하는 시스템 또는 장치의 컴퓨터에 의해, 그리고 예를 들어 전술한 실시예(들) 중 하나 이상의 기능을 실행하기 위해 저장 매체로부터 컴퓨터 실행가능 명령어들을 판독 및 실행함으로써 그리고/또는 전술한 실시예(들) 중 하나 이상의 기능을 실행하기 위해 하나 이상의 회로를 제어함으로써 시스템 또는 장치의 컴퓨터에 의해 실행되는 방법에 의해 실현될 수도 있다. 컴퓨터는 하나 이상의 프로세서(예를 들어, 중앙 처리 유닛(CPU), 마이크로 처리 유닛(MPU))를 포함할 수 있고 컴퓨터 실행가능 명령어를 판독 및 실행하기 위한 별도의 컴퓨터 또는 별도의 프로세서의 네트워크를 포함할 수 있다. 컴퓨터 실행가능 명령어들은 예를 들어 네트워크 또는 저장 매체로부터 컴퓨터에 제공될 수 있다. 저장 매체는, 예를 들어 하드 디스크, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 분산형 컴퓨팅 시스템의 스토리지, 광디스크(예를 들어, 콤팩트디스크(CD), 디지털 다기능 디스크(DVD) 또는 블루레이 디스크(BD)™), 플래시 메모리 디바이스, 메모리 카드 등 중 하나 이상을 포함할 수 있다.
(기타의 실시예)
본 발명은, 상기의 실시형태의 1개 이상의 기능을 실현하는 프로그램을, 네트워크 또는 기억 매체를 개입하여 시스템 혹은 장치에 공급하고, 그 시스템 혹은 장치의 컴퓨터에 있어서 1개 이상의 프로세서가 프로그램을 읽어 실행하는 처리에서도 실현가능하다.
또한, 1개 이상의 기능을 실현하는 회로(예를 들어, ASIC)에 의해서도 실행가능하다.
본 발명은 실시예들을 참조하여 설명되었지만, 본 발명이 개시된 실시예들로 한정되지 않는다는 것을 이해할 수 있을 것이다. 물론, 본 발명이 단지 예로서 기술되었으며, 상세한 변형예는 본 발명의 범주 내에서 이루어질 수 있다는 것이 이해될 것이다.

Claims (11)

  1. 클라이언트, 사용자 에이전트, 리소스 서버 및 상기 클라이언트가 상기 리소스 서버에 액세스하도록 인가하는 인가 서버를 포함하는 권한 위양 시스템으로서,
    상기 클라이언트를 위한 공개 키를 관리하도록 구성된 관리 수단;
    응답처(response destination) 정보, 서명 정보, 및 상기 클라이언트를 식별하기 위한 클라이언트 식별 정보를 포함하는 인가 코드 요구를, 상기 클라이언트로부터 상기 사용자 에이전트를 통해 상기 인가 서버로 송신하도록 구성된 송신 수단;
    상기 인가 서버에 의해, 상기 인가 코드 요구에 포함된 클라이언트 식별 정보에 대응하는 공개 키를 사용함으로써, 상기 인가 코드 요구에 포함된 서명 정보를 검증하도록 구성된 검증 수단;
    상기 인가 서버에 의해, 상기 검증 수단에 의한 검증에 따라 상기 응답처 정보에 의해 지정된 응답처에 기초하여 상기 클라이언트에 인가 코드 응답을 반환하도록 구성된 응답 수단; 및
    상기 클라이언트에 의해, 상기 인가 코드 응답을 수신하도록 구성된 수신 수단을 포함하고,
    상기 인가 코드 응답에 포함된 인가 코드는, 상기 클라이언트에 의한 상기 리소스 서버로의 액세스를 위한 인가 토큰을 요구하는 데 사용되는, 권한 위양 시스템.
  2. 삭제
  3. 제1항에 있어서,
    상기 인가 서버에 상기 클라이언트에 관한 정보를 등록하라는 상기 클라이언트로부터의 클라이언트 등록 요구를 수신한 후에,
    상기 인가 서버는, 상기 클라이언트를 식별하기 위한 클라이언트 식별 정보 및 상기 클라이언트를 인증하기 위한 비밀 키와 공개 키를 생성하도록 구성되고, 상기 관리 수단은, 상기 클라이언트 식별 정보와 상기 공개 키를 서로 연관하여 관리하도록 구성되고,
    상기 인가 서버는, 상기 클라이언트 등록 요구에 대한 응답으로서 상기 클라이언트 식별 정보와 상기 비밀 키를 상기 클라이언트에 송신하도록 구성되고,
    상기 비밀 키는, 상기 서명 정보를 상기 인가 코드 요구에 추가하도록 상기 클라이언트에 의해 사용되는, 권한 위양 시스템.
  4. 삭제
  5. 제1항에 있어서,
    상기 사용자 에이전트는, 상기 클라이언트에 의한 상기 리소스 서버로의 액세스를 인가하는 것을 동의하기 위해 사용자에 의해 사용가능한 인가 확인 윈도우를 표시하도록 구성되는 표시 수단을 포함하고,
    상기 인가 코드 요구는, 상기 표시 수단에 의해 표시된 상기 인가 확인 윈도우에 제시되는 상기 클라이언트에 관한 정보와, 상기 클라이언트에 관한 상기 정보를 제시하기 위해 사용되는 언어를 지정하는 언어 정보를 포함하는, 권한 위양 시스템.
  6. 제5항에 있어서,
    상기 언어 정보는, 상기 클라이언트에 사전 설정된 언어 정보 및 상기 사용자 에이전트로부터의 요구에 포함된 언어 정보 중 하나인, 권한 위양 시스템.
  7. 제1항에 있어서,
    상기 응답처 정보는, 상기 인가 서버로부터의 상기 인가 코드 응답의 응답처를 지정하는 리다이렉트 URI인, 권한 위양 시스템.
  8. 제7항에 있어서,
    상기 리다이렉트 URI는, 상기 클라이언트에 의해, 상기 인가 서버에 의해 상기 액세스를 인가하기 위한 인가 처리를 개시하기 위한 요구를 포함하는 상기 사용자 에이전트의 호스트(Host) 헤더에 기초하여 결정되고,
    상기 리다이렉트 URI가 상기 호스트 헤더에 기초하여 결정되지 않는 경우에, 상기 클라이언트는 새로운 IP 어드레스를 획득하도록 구성되고, 획득된 상기 IP 어드레스에 기초하여 상기 리다이렉트 URI가 결정되는, 권한 위양 시스템.
  9. 제5항에 있어서,
    상기 클라이언트에 관한 상기 정보는, 클라이언트명 또는 상기 클라이언트에 관한 설명을 포함하는, 권한 위양 시스템.
  10. 클라이언트, 사용자 에이전트, 리소스 서버 및 상기 클라이언트가 상기 리소스 서버에 액세스하도록 인가하는 인가 서버를 포함하는 권한 위양 시스템에 대한 제어 방법으로서,
    상기 클라이언트를 위한 공개 키를 관리하는 단계;
    응답처 정보, 서명 정보, 및 상기 클라이언트를 식별하기 위한 클라이언트 식별 정보를 포함하는 인가 코드 요구를, 상기 클라이언트로부터 상기 사용자 에이전트를 통해 상기 인가 서버로 송신하는 단계;
    상기 인가 서버에 의해, 상기 인가 코드 요구에 포함된 클라이언트 식별 정보에 대응하는 공개 키를 사용함으로써, 상기 인가 코드 요구에 포함된 서명 정보를 검증하는 단계;
    상기 인가 서버에 의해, 상기 검증하는 단계에서의 검증에 따라 상기 응답처 정보에 의해 지정된 응답처에 기초하여 상기 클라이언트에 인가 코드 응답을 반환하는 단계; 및
    상기 클라이언트에 의해, 상기 인가 코드 응답을 수신하는 단계를 포함하고,
    상기 인가 코드 응답에 포함된 인가 코드는, 상기 클라이언트에 의한 상기 리소스 서버로의 액세스를 위한 인가 토큰을 요구하는 데 사용되는, 권한 위양 시스템에 대한 제어 방법.
  11. 삭제
KR1020180102582A 2017-08-31 2018-08-30 권한 위양 시스템, 그 제어 방법 및 저장 매체 KR102362456B1 (ko)

Applications Claiming Priority (2)

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

Publications (2)

Publication Number Publication Date
KR20190024821A KR20190024821A (ko) 2019-03-08
KR102362456B1 true KR102362456B1 (ko) 2022-02-14

Family

ID=63517671

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020180102582A KR102362456B1 (ko) 2017-08-31 2018-08-30 권한 위양 시스템, 그 제어 방법 및 저장 매체

Country Status (5)

Country Link
US (1) US11088847B2 (ko)
EP (1) EP3451617B1 (ko)
JP (1) JP6904857B2 (ko)
KR (1) KR102362456B1 (ko)
CN (1) CN109428947B (ko)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6904183B2 (ja) * 2017-09-12 2021-07-14 富士通株式会社 情報処理装置、プログラム及び情報処理方法
US10831789B2 (en) 2017-09-27 2020-11-10 Oracle International Corporation Reference attribute query processing for a multi-tenant cloud service
US10715564B2 (en) * 2018-01-29 2020-07-14 Oracle International Corporation Dynamic client registration for an identity cloud service
US11423111B2 (en) 2019-02-25 2022-08-23 Oracle International Corporation Client API for rest based endpoints for a multi-tenant identify cloud service
US11792226B2 (en) 2019-02-25 2023-10-17 Oracle International Corporation Automatic api document generation from scim metadata
JP7301668B2 (ja) * 2019-08-07 2023-07-03 キヤノン株式会社 システム、制御方法、プログラム
JP7322283B2 (ja) * 2019-09-03 2023-08-07 グーグル エルエルシー 安全な識別情報検索のためのシステムおよび方法
US11687378B2 (en) 2019-09-13 2023-06-27 Oracle International Corporation Multi-tenant identity cloud service with on-premise authentication integration and bridge high availability
US11870770B2 (en) 2019-09-13 2024-01-09 Oracle International Corporation Multi-tenant identity cloud service with on-premise authentication integration
CN112579996B (zh) * 2019-09-29 2023-11-03 杭州海康威视数字技术股份有限公司 临时授权方法及装置
CN110661817B (zh) * 2019-10-25 2022-08-26 新华三大数据技术有限公司 资源访问方法、装置及服务网关
CN111343156B (zh) * 2020-02-11 2022-07-08 中国联合网络通信集团有限公司 注册认证的方法、服务器、终端设备及可读存储介质
US11121863B1 (en) 2020-03-12 2021-09-14 Oracle International Corporation Browser login sessions via non-extractable asymmetric keys
WO2021224544A1 (en) * 2020-05-05 2021-11-11 Nokia Technologies Oy Registration in communication networks
CN114513299B (zh) * 2020-10-28 2024-01-30 华为技术有限公司 基于开放式授权的数据传输方法及电子设备
CN112560009A (zh) * 2020-12-22 2021-03-26 Oppo广东移动通信有限公司 一种鉴权方法、终端、客户端及计算机存储介质
US11997080B2 (en) * 2020-12-30 2024-05-28 Citrix Systems, Inc. Uniform resource locator validation
CN112929165B (zh) * 2021-01-29 2024-04-30 中汽创智科技有限公司 一种基于远程车辆的动态授权***及方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016085638A (ja) * 2014-10-27 2016-05-19 キヤノン株式会社 サーバー装置、端末装置、システム、情報処理方法及びプログラム
US20170171201A1 (en) * 2015-12-09 2017-06-15 Canon Kabushiki Kaisha Authorization delegation system, information processing apparatus, authorization server, control method, and storage medium

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6961783B1 (en) 2001-12-21 2005-11-01 Networks Associates Technology, Inc. DNS server access control system and method
US20040210663A1 (en) * 2003-04-15 2004-10-21 Paul Phillips Object-aware transport-layer network processing engine
JP2006033085A (ja) * 2004-07-12 2006-02-02 Canon Inc 画像処理装置及びその制御方法
US10068220B2 (en) * 2006-10-11 2018-09-04 Visa International Service Association Systems and methods for brokered authentication express seller links
US8539559B2 (en) 2006-11-27 2013-09-17 Futurewei Technologies, Inc. System for using an authorization token to separate authentication and authorization services
US20090271847A1 (en) * 2008-04-25 2009-10-29 Nokia Corporation Methods, Apparatuses, and Computer Program Products for Providing a Single Service Sign-On
WO2011062251A1 (ja) * 2009-11-18 2011-05-26 日本電気株式会社 通信システム、アプリケーションサーバ、サービスサーバ、認証方法及びコンピュータ・プログラム
US8839376B2 (en) 2012-06-29 2014-09-16 Cable Television Laboratories, Inc. Application authorization for video services
CN103795692B (zh) 2012-10-31 2017-11-21 中国电信股份有限公司 开放授权方法、***与认证授权服务器
JP6439370B2 (ja) 2014-05-28 2018-12-19 株式会社リコー 情報処理システム、情報処理方法、情報処理装置及びプログラム
JP6335657B2 (ja) 2014-05-30 2018-05-30 キヤノン株式会社 権限委譲システム、方法、認証サーバーシステム、およびプログラム
US9838205B2 (en) * 2014-09-16 2017-12-05 Keypasco Ab Network authentication method for secure electronic transactions
US20160239840A1 (en) * 2015-02-17 2016-08-18 Ca, Inc. System and method of securely transferring payment for an online transaction

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016085638A (ja) * 2014-10-27 2016-05-19 キヤノン株式会社 サーバー装置、端末装置、システム、情報処理方法及びプログラム
US20170171201A1 (en) * 2015-12-09 2017-06-15 Canon Kabushiki Kaisha Authorization delegation system, information processing apparatus, authorization server, control method, and storage medium

Also Published As

Publication number Publication date
US20190068377A1 (en) 2019-02-28
JP6904857B2 (ja) 2021-07-21
CN109428947A (zh) 2019-03-05
US11088847B2 (en) 2021-08-10
EP3451617B1 (en) 2021-03-24
JP2019046060A (ja) 2019-03-22
KR20190024821A (ko) 2019-03-08
EP3451617A1 (en) 2019-03-06
CN109428947B (zh) 2022-06-14

Similar Documents

Publication Publication Date Title
KR102362456B1 (ko) 권한 위양 시스템, 그 제어 방법 및 저장 매체
KR102313859B1 (ko) 권한 위양 시스템, 그 제어 방법 및 클라이언트
KR102390108B1 (ko) 정보 처리 시스템 및 제어 방법
US10754934B2 (en) Device, control method of the same, and storage medium
JP6061633B2 (ja) デバイス装置、制御方法、およびそのプログラム。
KR101611872B1 (ko) Ｆｉｄｏ와 인증서를 이용한 인증 방법
US20150324554A1 (en) Registration of devices in a digital rights management environment
KR20220167366A (ko) 온라인 서비스 서버와 클라이언트 간의 상호 인증 방법 및 시스템
US11258798B2 (en) Method, entity and system for managing access to data through a late dynamic binding of its associated metadata
KR20150117045A (ko) 웹 매쉬업 환경에서의 사용자 인증 시스템 및 그 방법
JP7043480B2 (ja) 情報処理システムと、その制御方法とプログラム
KR101545897B1 (ko) 주기적인 스마트카드 인증을 통한 서버 접근 통제 시스템
JP5793593B2 (ja) ユーザ識別情報を安全に検証するためのネットワーク認証方法
CN112970017A (zh) 设备到云存储的安全链接
KR102199747B1 (ko) Otp 기반의 가상키보드를 이용한 보안 방법 및 시스템

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