KR20210018076A

KR20210018076A - 시스템, 제어 방법 및 프로그램

Info

Publication number: KR20210018076A
Application number: KR1020200094200A
Authority: KR
Inventors: 유 다무라
Original assignee: 캐논 가부시끼가이샤
Priority date: 2019-08-07
Filing date: 2020-07-29
Publication date: 2021-02-17
Also published as: JP7301668B2; KR102650408B1; US11558391B2; JP2021026611A; US20210044594A1

Abstract

클라이언트는 리소스 식별자를 지정하여 인가 개시 요청을 수행한다. 인가 개시 요청을 수신한 인가 서버는 지정된 리소스 식별자의 리소스 소유자를 리소스 서버에 문의한다. 리소스 소유자를 해결한 후, 인가 서버는, 해결된 사용자 식별자에 대응하는 사용자 단말에 인가 확인 요청을 수행한다.

Description

시스템, 제어 방법 및 프로그램{SYSTEM, CONTROL METHOD, AND PROGRAM}

본 발명은, 사용자 리소스의 권한의 위양을 가능하게 하는 시스템, 제어 방법, 프로그램에 관한 것이다.

관련 기술의 설명

클라우드 웹 서비스들에서 OAuth 2.0에 기초한 권한 위양이 실현된다. 일본 특허 제5623234호는 시스템 연계를 설정할 때, 사용자는 클라이언트와 인가 서버의 양쪽을 웹브라우저의 사용에 의해 조작하여, 인가 조작을 수행함으로써, 사용자의 권한을 클라이언트에 위양할 수 있는 것을 개시한다. 클라이언트는, 위양된 사용자의 권한을 사용하는 것에 의해, 사용자의 리소스에 액세스할 수 있어, 시스템 연계가 실현된다.

OAuth 2.0에 의해 사용자의 권한을 클라이언트에 위양하기 위해서는, 사용자가 클라이언트에 웹브라우저에 의해 액세스할 필요가 있다. 예를 들어, 멀티-테넌트 시스템(multi-tenant system)에서, 외부 시스템으로부터 각 입주자의 데이터를 해석하기 위해 입주자들의 관리자들의 허가가 필요한 경우가 고려된다. 이 경우, 해석의 타이밍에서 입주자의 관리자가 클라이언트인 외부 시스템에 액세스하는 것을 기대하는 것이 곤란하여, 클라이언트가 자율적으로 권한의 위양을 요청을 수행할 필요가 있다.

또한, 미리 사용자가 특정될 수 있는 경우에, 그 사용자에 권한을 위양하도록 요청할 수 있지만, 클라이언트가 액세스하기를 원하는 리소스가 알려져 있지만, 그 리소스의 소유자가 알려져 있지 않아, 사용자를 지정하여 권한 위양을 요청하는 것이 곤란한 경우가 고려된다. 예를 들어, 데이터가 해석될 입주자가 식별될 수 있지만, 그 관리자인 사용자가 알려져 있지 않은 경우에서는, 전술한 과제가 발생한다.

본 발명은 전술한 과제를 감안하여 이루어진 것이며, 클라이언트가 리소스 소유자를 지정하여 권한 위양을 요청할 수 없는 경우에, 리소스를 지정하여 권한 위양을 요청할 수 있게 하는 것을 목적으로 한다.

본 발명의 실시예에 따른 인가 서버는 사용자의 리소스를 제공하는 리소스 서버, 리소스에 액세스하는 클라이언트, 클라이언트에 의해 리소스에 액세스하는 것이 사용자에 의해 허가된 것을 나타내는 액세스 토큰을 발행하는 인가 서버 및 사용자 단말을 포함하는 시스템에서의 인가 서버이다. 인가 서버는 다음을 포함한다: 클라이언트에 의해 액세스될 리소스에 대응하는 리소스 식별자를 포함하는 인가 개시 요청을 수신하도록 구성된 수신 유닛; 수신 유닛에 의해 수신된 인가 개시 요청에 포함되는 리소스 식별자와 함께, 리소스 식별자에 대응하는 리소스의 소유자인 사용자를 해결하기 위해 수행되는 요청을 리소스 서버에 송신하도록 구성된 송신 유닛; 요청에 대한 응답으로서 취득된 사용자에 관한 정보와 연관된 단말 정보를 특정하도록 구성된 특정 유닛; 특정된 단말 정보에 대응하는 사용자 단말에 대해 인가 확인 요청을 송신하고, 응답으로서 인가 확인의 결과를 수신하도록 구성된 확인 유닛; 및 확인 유닛에 의해 수신된 인가 확인의 결과에 따라 액세스 토큰의 발행을 제어하고, 액세스 토큰이 발행된 경우에, 발행된 액세스 토큰을 인가 개시 요청을 송신했던 클라이언트에 송신하도록 구성된 발행 유닛.

본 발명의 추가적인 특징들은 첨부 도면들을 참조하여 예시적인 실시예들에 대한 이하의 설명으로부터 명백해질 것이다.

도 1은 네트워크 구성을 도시한다.
도 2는 제1 실시예에 따른 인가 서버의 구성을 도시한다.
도 3a는 실시예에 따른 모듈 구성을 도시한다.
도 3b는 실시예에 따른 모듈 구성을 도시한다.
도 3c는 실시예에 따른 모듈 구성을 도시한다.
도 3d는 실시예에 따른 모듈 구성을 도시한다.
도 4a는 실시예에 따른 인가 개시 요청 및 인가 확인 요청의 흐름도이다.
도 4b는 실시예에 따른 인가 개시 요청 및 인가 확인 요청의 흐름도이다.
도 4c는 실시예에 따른 인가 개시 요청 및 인가 확인 요청의 흐름도이다.
도 4d는 실시예에 따른 인가 개시 요청 및 인가 확인 요청의 흐름도이다.
도 5a는 실시예에 따른 액세스 토큰의 발행의 흐름도이다.
도 5b는 실시예에 따른 액세스 토큰의 발행의 흐름도이다.
도 5c는 실시예에 따른 액세스 토큰의 발행의 흐름도이다.
도 5d는 실시예에 따른 액세스 토큰의 발행의 흐름도이다.
도 6은 실시예에 따른 전체 흐름도이다.
도 7은 실시예에 따른 인가 확인 화면의 예이다.
도 8은 제2 실시예에 따른 모듈 구성을 도시한다.
도 9a는 제2 실시예에 따른 리소스 액세스의 흐름도이다.
도 9b는 제2 실시예에 따른 리소스 액세스의 흐름도이다.
도 10a는 제3 실시예에 따른 모듈 구성을 도시한다.
도 10b는 제3 실시예에 따른 모듈 구성을 도시한다.
도 11a는 제3 실시예에 따른, 리소스 소유자가 변경되는 흐름도이다.
도 11b는 제3 실시예에 따른, 리소스 소유자가 변경되는 흐름도이다.

실시예들의 설명

제1 실시예

이하, 본 발명의 제1 실시예가 도면들을 참조하여 설명될 것이다. 실시예에 따른 권한 위양 시스템은, 도 1에 도시한 바와 같은 구성을 갖는 네트워크 상에 구현된다. 광역 네트워크(wide area network)(100)(WAN(100))에서, 본 발명에서는 월드 와이드 웹(World Wide Web)(WWW) 시스템이 구축된다. 로컬 영역 네트워크(110, 150, 및 170)(LAN(110), LAN(150), 및 LAN(170))는 구성 요소들을 접속시킨다.

리소스 서버(152)는 사용자의 리소스를 관리하며, 클라이언트(111)는 리소스 서버(152) 상의 리소스에 액세스한다. 여기서 클라이언트(111)가 리소스 서버(152) 상의 리소스에 액세스하기 위해서는, 리소스의 소유자인 사용자가 클라이언트(111)에 권한을 위양 할 필요가 있다. 인가 서버(151)는 클라이언트(111)의 요청에 응답하여 리소스로의 액세스의 허가의 증거로서 역할을 하는 액세스 토큰을 발행한다. 사용자 단말(171)은 클라이언트(111)가 권한의 위양을 요청할 때 인가 확인 화면을 표시한다.

인가 서버(151), 리소스 서버(152)는 각각 LAN(150)을 통해 WAN(100)과 접속된다. 또한, 마찬가지로, 클라이언트(111)는 LAN(110)을 통해 WAN(100)과 접속되고, 사용자 단말(171)은 LAN(170)을 통해 WAN(100)과 접속된다. 인가 서버(151) 및 리소스 서버(152)는 개별의 LAN들 상에 구성될 수 있거나, 동일한 LAN 상에 구성될 수 있다는 점에 유의한다. 마찬가지로, 인가 서버(151) 및 리소스 서버(152)는 동일한 PC 또는 서버 컴퓨터 상에 구성될 수 있다. 또한, 인가 서버(151) 및 리소스 서버(152) 각각은 도 1에서는 단일 서버로서 도시되지만, 복수의 서버를 포함하는 서버 시스템일 수 있다. 예를 들어, 인가 서버(151)가 복수의 클러스터링된 서버에 의해 구성될 수 있다. 본 출원의 발명에서 서버 시스템은, 적어도 하나의 서버에 의해 구성되고 특정한 서비스를 제공하는 장치를 지칭한다는 점에 유의한다.

실시예에 따른 이벤트 통지 시스템은, 도 2에 도시한 바와 같은 구성을 갖는 PC를 포함하는 시스템 상에 구현된다. 도 2는 실시예에 따른 인가 서버(151)의 구성을 도시한다. 또한, 클라이언트(111), 리소스 서버(152) 및 사용자 단말(171)의 구성들은 또한 인가 서버(151)의 구성과 유사하다. 도 2에 도시되는 하드웨어 블록도는 일반적인 정보 처리 장치의 하드웨어 블록도에 대응하는 것으로 가정하고, 실시예에 따른 서버 컴퓨터 또는 단말에는 일반적인 정보 처리 장치의 하드웨어 구성이 적용될 수 있다는 점에 유의한다.

도 2에서, CPU(201)는, ROM(203)의 프로그램 ROM에 저장되거나, 또는 하드 디스크(211)로부터 RAM(202)에 로드된 OS나 애플리케이션 등의 프로그램을 실행한다. 여기서, OS는 컴퓨터 상에서 동작하는 오퍼레이팅 시스템의 약어이다. 이하, 오퍼레이팅 시스템은 OS로서 지칭된다. 후술하는 흐름도들의 처리는 프로그램의 실행에 의해 달성된다. RAM(202)은, CPU(201)의 주 메모리, 워크 에어리어 등으로서 기능한다. 키보드 컨트롤러(KBC)(205)는, 키보드(KB)(209) 또는 포인팅 디바이스(도시하지 않음)를 통해 수행되는 키 입력을 제어한다. CRT 컨트롤러(CRTC)(206)는, CRT 디스플레이(210)의 표시를 제어한다. 디스크 컨트롤러(DKC)(207)는 각종 데이터를 저장하는 하드 디스크(HD)(211), 플로피(등록 상표) 디스크(FD) 등에서의 데이터로의 액세스를 제어한다. NC(212)는 네트워크에 접속되고, 네트워크에 접속된 다른 디바이스와 통신하는 것에 대한 제어 처리를 실행한다.

후술하는 설명을 통해서, 달리 특정되지 않는 한 CPU(201)가 하드웨어 관점에서의 동작들을 주로 실행하고, 하드 디스크(HD)(211)에 인스톨된 애플리케이션 프로그램들이 소프트웨어 관점에서의 동작들을 주로 실행한다는 점에 유의한다. 프로그램들을 실행하는 CPU(201)는 소프트웨어 관점에서의 동작들을 실현한다.

도 3a 내지 도 3d는 본 실시예에 따른 클라이언트(111), 인가 서버(151), 및 리소스 서버(152)의 모듈 구성들을 도시한다. 도 3a는 클라이언트(111)의 모듈 구성을 도시하고, 도 3b는 인가 서버(151)의 모듈 구성을 도시하고, 도 3c는 리소스 서버(152)의 모듈 구성을 도시한다. 또한 도 3d는 사용자 단말(171)의 모듈 구성을 도시한다. 클라이언트(111)는 인가 개시 요청 발행 모듈(301), 액세스 토큰 요청 모듈(302), 액세스 토큰 관리 모듈(303), 및 리소스 액세스 모듈(304)을 갖는다. 인가 서버(151)는 인가 요청 관리 모듈(351), 리소스 소유자 해결 모듈(352), 인가 확인 모듈(353), 및 액세스 토큰 발행 모듈(354)을 갖는다. 리소스 서버(152)는 리소스 관리 모듈(371)을 갖는다. 사용자 단말(171)은 인가 조작 수신 모듈(391)을 갖는다.

인가 서버(151)의 인가 요청 관리 모듈(351)은, 클라이언트(111)의 인가 개시 요청 발행 모듈(301)로부터의 요청에 응답하여, 인가 개시 요청을 처리한다. 여기서, 인가 개시 요청은 클라이언트(111)가 액세스하려고 하는 리소스에 관한 정보를 포함한다. 리소스 소유자 해결 모듈(352)은 인가 개시 요청에 포함되는 리소스 정보를 사용하여, 리소스 서버(152)에 대해, 리소스의 리소스 소유자 정보를 문의한다. 여기에서 얻어진 리소스 소유자 정보를 바탕으로, 인가 확인 모듈(353)은, 특정한 사용자 단말(171)에 대해 인가 확인 요청을 수행한다. 인가 확인 요청에 응답하여 사용자가 인가 조작을 수행할 때, 클라이언트(111)는, 인가 서버(151)로부터 액세스 토큰을 취득하도록 허용되고, 리소스 서버(152)에 액세스하도록 허용된다.

도 4a는 실시예에 따라, 클라이언트(111)가 인가 서버(151)에 대해 인가 개시 요청을 수행하는 절차의 흐름도이다. 절차는 클라이언트(111)가 리소스 서버(152) 상의 리소스에 액세스하기 전에, 액세스 토큰이 필요해질 때 개시된다.

단계 S401에서, 인가 개시 요청 발행 모듈(301)은, 조작 대상의 리소스 식별자 및 스코프(scope)를 포함하는 인가 개시 요청을, 인가 서버(151)에 대해 송신한다. 여기서 스코프는, 리소스로의 액세스의 범위를 나타낸다.

단계 S402에서, 인가 개시 요청 발행 모듈(301)은, 인가 서버(151)로부터 응답을 수신한다. 이 응답은, 인가 서버(151)에 의해 발행된 인가 요청 식별자를 포함한다.

단계 S403에서, 인가 개시 요청 발행 모듈(301)은, 단계 S402에서 수신된 응답에 포함되는 인가 요청 식별자를, 단계 S401에서의 조작 대상의 리소스 식별자 및 스코프와 함께 저장하고, 절차가 종료된다. 표 1은 클라이언트(111)에 의해 저장되는 인가 요청 관리 테이블의 예이다.

표 1에서는, 리소스 식별자 "/datalake/iot0010/data"에 의해 표시되는 리소스에 대하여, 스코프 "get-data"로 행해진 인가 개시 요청이, 인가 요청 식별자 "auth_req_id_12345"에 연관하여 저장된다. 또한 인가 요청 식별자 "auth_req_id_98765"에 대하여는, "actk111222333"에 의해 표시되는 액세스 토큰이 이미 취득되었다는 것이 표시된다. 여기서, 리소스 식별자에 의해 표시되는 리소스는, 파일 시스템 상의 1개의 파일, 데이터베이스 상의 특정한 레코드, 또는 파일 및 레코드의 집합을 나타낼 수 있다.

도 4b는 실시예에 따른 인가 서버(151)가 인가 개시 요청을 수신하는 절차의 흐름도이다. 절차는 인가 서버(151)가 클라이언트(111)로부터 인가 개시 요청을 수신할 때 개시된다.

단계 S411에서, 인가 요청 관리 모듈(351)은, 클라이언트(111)로부터 인가 개시 요청을 수신한다. 여기서 인가 개시 요청은, 클라이언트(111)의 클라이언트 식별자와, 클라이언트(111)에 대한 조작 대상의 리소스 식별자를 포함한다.

단계 S412에서, 리소스 소유자 해결 모듈(352)은, 단계 S411에서 지정된 리소스의 소유자를, 리소스 서버(152)에 문의한다. 단계 S413에서, 리소스 소유자 해결 모듈(352)은, 단계 S412에서의 문의에 대한 응답으로서, 단계 S411에서 지정된 리소스의 소유자의 사용자 식별자를 수신한다. 단계 S414에서, 인가 요청 관리 모듈(351)은, 단계 S411에서 수신된 인가 개시 요청에 대응하는 인가 요청 식별자를 생성한다.

단계 S415에서, 인가 요청 관리 모듈(351)은, 단계 S414에서 생성된 인가 요청 식별자를, 인가 요청에 관한 정보와 연관하여 저장한다. 여기서 인가 요청에 관한 정보는, 단계 S411에서 수신된 클라이언트 식별자, 조작 대상의 리소스 식별자, 및 스코프와, 단계 S413에서 수신된 사용자 식별자를 포함한다. 표 2는 인가 요청 관리 모듈(351)에 의해 저장되는 인가 확인 상태 관리 테이블의 예이다.

표 2에서는, 클라이언트 식별자 "client_xyz"에 의해 표시되는 클라이언트에 의해, 리소스 식별자 "/datalake/iot0010/data"에 의해 표시되는 리소스에 대하여, 스코프 "get-data"로 행해진 인가 개시 요청이, 인가 요청 식별자 "auth_req_id_12345"와 연관하여 저장된다. 또한, 사용자 식별자 "user_abcde"가 인가 요청 식별자 "auth_req_id_12345"와 연관되고, 이는 리소스 "/datalake/iot0010/data"의 리소스 소유자를 해결한 결과로서, 사용자 식별자가 "user_abcde"인 것을 나타낸다. 인가 요청 식별자 "auth_req_id_12345"의 인가 결과의 "(공란)"은, 사용자가 아직 인가 조작을 수행하지 않았다는 것을 나타낸다. 한편, 인가 요청 식별자 "auth_req_id_98765"의 인가 결과는 "approved"이고, 인가 요청 식별자 "auth_req_id_44444"의 인가 결과는 "disapproved"이고, 이것들은 각각, 사용자가 인가를 허가했다는 것과, 사용자가 인가를 거부했다는 것을 나타낸다.

단계 S416에서, 인가 요청 관리 모듈(351)은, 단계 S411에 대한 응답으로서, 단계 S414에서 생성된 인가 요청 식별자를 클라이언트(111)에 반환하고, 절차가 종료된다.

도 4c는 실시예에 따라, 인가 서버(151)가 인가 확인 요청을 수행하는 절차의 흐름도이다. 절차는 단계 S415에서 인가 요청에 관한 정보가 저장될 때 개시된다.

단계 S421에서 인가 확인 모듈(353)은, 단계 S415에서 저장되는 인가 요청 식별자와 연관된 사용자 식별자를 취득한다. 여기서, 단계 S415에서 저장되는 인가 요청 식별자가 "auth_req_id_12345"일 때, 연관된 사용자 식별자는 "user_abcde"이다.

단계 S422에서, 인가 확인 모듈(353)은, 단계 S421에서 취득된 사용자 식별자로부터, 사용자 단말(171)을 특정한다. 표 3은 사용자 식별자와 사용자 단말(171) 사이의 대응이 저장되는 사용자 관리 테이블의 예이다.

여기서, 사용자 식별자 "user_abcde"에 대응하는 사용자 단말 정보는 "192.168.0.1"인 것이 발견된다. 이러한 방식으로, 단말 정보에 기초하여 사용자가 갖는 사용자 단말이 특정된다. 단계 S423에서, 인가 확인 모듈(353)은, 단계 S415에서 저장되는 인가 요청 식별자와 연관된 클라이언트 식별자 및 스코프를 취득한다. 여기서, 단계 S415에서 저장되는 인가 요청 식별자가 "auth_req_id_12345"일 때, 연관된 클라이언트 식별자 및 스코프는 각각 "client_xyz" 및 "get-data"이다.

단계 S424에서, 인가 확인 모듈(353)은, 단계 S422에서 특정된 사용자 단말(171)에 대해, 단계 S423에서 취득된 클라이언트 식별자, 리소스 식별자 및 스코프를 포함하여 인가 확인 요청을 송신한다. 인가 확인 요청을 송신하는 방법은, 사용자 단말(171)의 엔드 포인트가 지정된 통신 방법, MQTT(Message Queuing Telemetry Transport)와 같은 PUSH 통지를 사용한 방법, 또는 다른 방법일 수 있다는 점에 유의한다. 임의의 경우에서, 사용자 단말(171)로부터의 액세스 시 통신이 개시되는 것이 아니라, 인가 확인 모듈(353)으로부터 사용자 단말(171)로 통신이 개시되어, 서버 측으로부터 사용자 단말로 통신을 허용하는 통신 방법이 요구된다.

사용자 단말(171)의 인가 조작 수신 모듈(391)은, 취득된 인가 확인 요청에 기초하여, 도 7에 나타낸 바와 같은 인가 확인 화면(1001)을 표시하고, 사용자에 인가를 요청한다. 표시 내용은 인가 확인 요청에 포함되는 클라이언트 식별자 및 리소스 식별자를 참조하는 것에 의해 결정된다.

단계 S425에서, 인가 확인 모듈(353)은, 단계 S424에서 송신된 인가 확인 요청의 응답으로서, 사용자 단말(171)로부터 인가 결과를 수신한다. 단계 S426에서, 인가 확인 모듈(353)은, 단계 S425에서 수신된 인가 결과를, 단계 S415에서 저장되는 인가 요청 식별자와 연관하여 저장하고, 절차가 종료된다. 표 2에서는, 인가 요청 식별자 "auth_req_id_98765"에 대하여, 인가가 허가된 것을 나타내는 "approved"가 저장된다.

도 4d는 실시예에 따라, 리소스 서버(152)가 리소스 소유자를 반환하는 절차의 흐름도이다. 절차는 리소스 서버(152)가 인가 서버(151)로부터, 리소스 소유자의 문의를 수신할 때 개시된다.

단계 S451에서, 리소스 관리 모듈(371)은, 인가 서버(151)로부터 리소스 소유자의 문의를 수신한다. 이 문의는 리소스 식별자를 포함한다. 단계 S452에서, 리소스 관리 모듈(371)은, 단계 S415에서 지정된 리소스 소유자의 사용자 식별자를 취득하고, 사용자 식별자를 인가 서버(151)에 반환하고, 절차가 종료된다. 표 4는 리소스 관리 모듈(371)에서의 리소스 관리 테이블의 예이다. 표 4는, 리소스 식별자 "/datalake/iot0010/data"에 의해 표시되는 리소스의 소유자가 사용자 식별자 "user_abcde"인 것을 나타낸다.

도 5a는 실시예에 따라, 인가 서버(151)가 클라이언트(111)에 인가 완료 통지를 수행하는 절차의 흐름도이다. 절차는 단계 S426에서 인가 결과가 저장될 때 개시된다.

단계 S501에서, 인가 확인 모듈(353)은 단계 S426에서 저장되는 인가 요청 식별자를 취득한다. 단계 S502에서, 인가 확인 모듈(353)은, 단계 S501에서 취득된 인가 요청 식별자와 연관된 클라이언트의 접속처 정보인 클라이언트 엔드 포인트를 취득한다. 표 5는 클라이언트 식별자와 클라이언트 엔드 포인트 사이의 대응이 관리되는, 클라이언트 관리 테이블의 예이다. 표 5는, 클라이언트 식별자 "client_xyz"의 클라이언트 엔드 포인트가, "10.0.0.1"인 것을 나타낸다.

단계 S503에서, 인가 확인 모듈(353)은, 단계 S502에서 취득된 클라이언트 엔드 포인트에 대해, 사용자가 인가를 허가했다는 것을 통지하고, 절차가 종료된다. 여기서, 클라이언트 엔드 포인트에 통지되는 내용은, 단계 S501에서 취득된 인가 요청 식별자, 또는 사용자에 의한 인가에 응답하여 발행된 액세스 토큰일 수 있다는 점에 유의한다. 액세스 토큰이 발행될 때, 후술하는 도 5c에 나타낸 바와 같은 절차가 수행된다.

도 5b는 실시예에 따라, 클라이언트(111)가 인가 서버(151)에 액세스 토큰 요청을 수행하는 절차의 흐름도이다. 절차는 클라이언트(111)가 인가 서버(151)로부터 단계 S503에서의 인가 완료 통지를 수신할 때 개시된다. 대안적으로, 절차는, 클라이언트(111)에 의해 정기적으로 수행될 수 있다.

단계 S511에서, 액세스 토큰 요청 모듈(302)은, 액세스 토큰 요청이 수행되는 인가 요청 식별자를 결정한다. 여기서 절차가 정기적으로 수행되는 경우에는, 인가 요청 식별자는, 표 1에 표시되는 인가 요청 관리 테이블에서 그 액세스 토큰이 취득되지 않는 인가 요청 식별자들로부터 선택된다. 대안적으로, 절차가 인가 서버(151)로부터의 통지 시 개시될 경우에, 인가 서버(151)로부터의 통지에 포함되는 인가 요청 식별자가 사용된다.

단계 S512에서, 액세스 토큰 요청 모듈(302)은, 단계 S511에서 결정된 인가 요청 식별자를 지정하는 것에 의해, 인가 서버(151)에 대해 액세스 토큰 요청을 수행한다. 단계 S513에서, 액세스 토큰 관리 모듈(303)은, 단계 S512에 대한 응답으로서 수신된 액세스 토큰을 저장하고, 절차가 종료된다. 표 1은, 인가 요청 식별자 "auth_req_id_98765"에 대해 취득된 액세스 토큰 "actk111222333"이 저장되는 상태를 나타낸다.

도 5c는 실시예에 따라, 인가 서버(151)가 액세스 토큰을 발행하는 절차의 흐름도이다. 절차는 인가 서버(151)가 클라이언트(111)로부터 액세스 토큰 요청을 수신할 때 개시된다.

단계 S521에서, 액세스 토큰 발행 모듈(354)은, 클라이언트(111)로부터 수신된 액세스 토큰 요청으로부터, 인가 요청 식별자를 취득한다. 단계 S522에서, 액세스 토큰 발행 모듈(354)은 액세스 토큰의 발행을 허용할지 여부를 판단한다.

단계 S523에서, 액세스 토큰 발행 모듈(354)은, 단계 S522의 결과로서, 액세스 토큰의 발행이 허용되는 것으로 판단되는지를 확인한다. 액세스 토큰의 발행이 허용되는 것으로 판단된 경우에, 절차는 단계 S524로 천이한다. 대안적으로, 액세스 토큰의 발행이 허용되지 않는 것으로 판단된 경우에, 절차는 단계 S525로 천이한다.

단계 S524에서, 액세스 토큰 발행 모듈(354)은, 단계 S521에서 취득된 인가 요청 식별자와 연관된 사용자 식별자 및 스코프에 대응하는 액세스 토큰을 발행한다. 또한, 액세스 토큰 발행 모듈(354)은 발행된 액세스 토큰을 클라이언트(111)에 반환하고, 절차가 종료된다. 표 6은 액세스 토큰 발행 모듈(354)에 의해 발행된 액세스 토큰이 관리되는, 액세스 토큰 관리 테이블의 예이다.

표 6은, 사용자 "user_abcde"이 스코프 "get-data"의 권한을 위양했다는 것을 나타내는 액세스 토큰이, 액세스 토큰 식별자 "actk111222333"로서 발행되는 것을 나타낸다. 단계 S524에서 클라이언트(111)에 반환되는 액세스 토큰은, 액세스 토큰 식별자만일 수도 있거나, 액세스 토큰 식별자에 더하여 사용자 식별자 및 스코프를 포함하는 구조화된 데이터일 수도 있다는 점에 유의한다. 단계 S525에서, 액세스 토큰 발행 모듈(354)은, 액세스 토큰의 발행이 허용되지 않는 것을 클라이언트(111)에 통지하고, 절차가 종료된다.

도 5d는 실시예에 따라, 액세스 토큰의 발행을 허용하는지 여부가 판단되는 단계 S522의 상세 절차의 흐름도이다. 단계 S531에서, 액세스 토큰 발행 모듈(354)은, 표 2의 인가 확인 상태 관리 테이블을 참조하는 것에 의해, 지정된 인가 요청 식별자에 대응하는 인가 결과를 확인한다.

단계 S532에서, 액세스 토큰 발행 모듈(354)은, 단계 S531에서 확인된 인가 결과가 인가가 허가된 것을 나타내는지를 판단한다. 인가가 허가된 것이 표시되는 경우에, 절차는 단계 S533으로 천이하고, 그렇지 않으면 절차는 단계 S534로 진행한다. 단계 S533에서, 액세스 토큰 발행 모듈(354)은, 액세스 토큰의 발행이 허용되는 것으로 판단하고, 절차가 종료된다. 단계 S534에서, 액세스 토큰 발행 모듈(354)은, 액세스 토큰의 발행이 허용되지 않는 것으로 판단하고, 절차가 종료된다.

도 6은 실시예에 따라, 클라이언트(111)가 인가 개시 요청을 수행하고 그 후 액세스 토큰을 획득하여, 리소스에 액세스할 때의 전체의 흐름을 도시한다. 클라이언트(111)는 (1)에서 인가 서버(151)에 대해 인가 개시 요청을 수행하고, 응답으로서 (2)에서 인가 요청 식별자를 취득한다. (1)은 단계 S401 및 단계 S411에 대응하고, (2)는 단계 S402 및 단계 S416에 대응한다.

인가 서버(151)는 인가 개시 요청을 수신하면, 인가 개시 요청에 포함되는 리소스 식별자의 리소스 소유자를 해결하기 위해서, (3)에서 리소스 서버(152)에 리소스 소유자를 문의한다. 또한, 응답으로서, 인가 서버(151)는 (4)에서 리소스 소유자의 사용자 식별자를 수신한다. (3)은 단계 S412 및 단계 S451에 대응하고, (4)는 단계 S413 및 단계 S452에 대응한다.

인가 서버(151)는 리소스 소유자가 해결될 때, (5)에서 리소스 소유자와 연관된 사용자 단말(171)에 대해 인가 확인 요청을 수행한다. 사용자 단말(171)에서는, 도 7에 도시된 인가 확인 화면(1001)이 표시되고, 사용자가 인가 조작을 수행한다. 사용자에 의해 인가 조작을 수행한 결과는, (6)으로서 인가 서버(151)에 반환된다. (5)는 단계 S424에 대응하고, (6)은 단계 S425에 대응한다. 인가 서버(151)는 (6)에서 인가 결과를 수신하면, (7)에서 클라이언트(111)에 인가 완료 통지를 수행한다. (7)은 단계 S503에 대응한다.

클라이언트(111)는 (7)에서 인가 완료 통지를 수신하면, 또는 정기적으로, (8)에서 인가 서버(151)에 대해 액세스 토큰 요청을 수행한다. 또한, 클라이언트(111)는 응답으로서 (9)에서 액세스 토큰을 수신한다. (8)은 단계 S512 및 단계 S521에 대응하고, (9)는 단계 S513 및 단계 S524에 대응한다. (9)에서 액세스 토큰을 수신한 클라이언트(111)는, (10)에서 리소스 서버(152)에 대해 리소스 액세스를 수행하고, 응답으로서 (11)에서 리소스를 취득한다.

실시예에 따르면, 클라이언트가 액세스하기 원하는 리소스가 알려져 있지만, 리소스의 소유자가 알려져 있지 않는 경우에도, 인가 개시 요청이 수행될 수 있다. 즉, 사용자를 지정하여 권한의 위양을 요청하는 대신, 리소스 식별자를 지정하여 인가 개시 요청을 수행하는 것에 의해 액세스 토큰이 취득될 수 있다.

제2 실시예

이어서, 본 발명의 제2 실시예가 도면들을 참조하여 설명될 것이다. 제1 실시예의 것과 공통인 부분에 대해서는 설명이 생략될 것이고, 이하에서는 차이 부분만이 설명될 것이라는 점에 유의한다. 리소스 서버 상에서 리소스의 소유자가 변경된 경우를 고려할 때, 변경 전의 리소스 소유자에 의해 인가 시 발행된 액세스 토큰에 의해, 리소스로의 액세스가 허용되어서는 안된다.

제2 실시예는, 전술한 과제를 감안하여 이루어진다. 도 8은 제2 실시예에 따른, 리소스 서버(152)의 모듈 구성을 도시한다. 리소스 서버(152)는 리소스 관리 모듈(371)에 더하여, 리소스 액세스 제어 모듈(372)을 갖는다. 도 9a는 제2 실시예에 따라, 클라이언트(111)가 리소스 서버(152)로의 리소스 액세스를 수행하는 절차의 흐름도이다. 절차는 클라이언트(111)가 액세스 토큰을 취득할 때 개시된다.

단계 S901에서, 리소스 액세스 모듈(304)은, 단계 S513에서 취득된 액세스 토큰을 사용하여 리소스 서버(152)에 리소스 액세스를 수행한다. 여기서, 리소스 액세스는 액세스 토큰 및 조작 대상의 리소스의 식별자를 포함한다. 또한, 액세스 토큰은 액세스 토큰 식별자만 포함할 수 있거나, 액세스 토큰 식별자에 더하여 사용자 식별자 및 스코프를 포함하는 구조화된 데이터일 수 있다. 여기에서 액세스 토큰은, 액세스 토큰 식별자에 더하여 사용자 식별자 및 스코프를 포함하는 구조화된 데이터인 것으로 가정한다. 구조화된 액세스 토큰의 예는 이하와 같다:

{"accessTokenId":"actk111222333","userId":"user_abcde","scope":"get-data"}

단계 S902에서, 리소스 액세스 모듈(304)은, 단계 S901에서 리소스가 취득될 수 있는지 여부를 판단한다. 리소스가 취득될 수 있는 경우에, 절차는 단계 S903으로 진행하고, 리소스가 취득될 수 없는 경우에, 절차는 단계 S904로 천이한다. 단계 S903에서, 리소스 액세스 모듈(304)은 단계 S901에서 취득된 리소스에 대해, 원하는 처리를 수행하고, 절차가 종료된다.

단계 S904에서, 리소스 액세스 모듈(304)은, 리소스가 취득될 수 없는 원인이, 리소스 소유자의 변경인지를 판단한다. 원인이 리소스 소유자의 변경인 경우에, 절차는 단계 S905로 천이하고, 원인이 다른 것인 경우에, 절차가 종료된다.

단계 S905에서, 리소스 액세스 모듈(304)은, 새로운 리소스 소유자의 권한의 위양을 받기 위해서, 단계 S901에서 액세스될 리소스를 지정하여 인가 개시 요청을 수행한다. 인가 개시 요청의 절차는 도 4a에 도시한 바와 같다.

도 9b는 제2 실시예에 따라, 리소스 서버(152)에서의 리소스 액세스 처리의 절차의 흐름도이다. 절차는 리소스 서버(152)가 클라이언트(111)로부터 리소스 액세스를 수신할 때 개시된다.

단계 S911에서, 리소스 관리 모듈(371)은, 클라이언트(111)로부터 리소스 액세스를 수신한다. 이하에서는, 클라이언트(111)에 의한 리소스 액세스의 대상이 되는 리소스는, "/datalake/iot0011/data"에 의해 표시되는 리소스인 것으로 가정한다. 단계 S912에서, 리소스 액세스 제어 모듈(372)은, 단계 S911에서 수신된 리소스 액세스에 포함되는 액세스 토큰을 추출한다.

단계 S913에서, 리소스 액세스 제어 모듈(372)은, 단계 S912에서 추출된 액세스 토큰과 연관된 사용자 식별자를 확인한다. 여기에서는, 액세스 토큰이 구조화된 데이터이고 액세스 토큰에 직접 기재된 사용자 식별자가 추출되는 것으로 가정한다. 액세스 토큰이 {"accessTokenId":"actk111222333","userId":"user_abcde","scope":"get-data"}일 때, 사용자 식별자로서 "user_abcde"이 추출된다.

단계 S914에서, 리소스 액세스 제어 모듈(372)은, 단계 S911에서 수신된 리소스 액세스의 대상이 되는 리소스의 리소스 소유자를 취득한다. 표 7은, 리소스 소유자가 변경된 후의 리소스 관리 테이블의 예를 나타낸다.

표 7에서는, 리소스 소유자가 변경되기 전의 표 4와 비교하여, "/datalake/iot0011/data"에 의해 표시되는 리소스의 소유자가 변경된다. 새로운 리소스 소유자의 사용자 식별자는 "user_fghij"이다. 여기서, 단계 S911에서 대상이 된 리소스가 "/datalake/iot0011/data"이기 때문에, 취득되는 사용자 식별자는 "user_fghij"이다.

단계 S915에서, 리소스 액세스 제어 모듈(372)은, 단계 S913에서 추출된 사용자 식별자를, 단계 S914에서 추출된 사용자 식별자와 비교한다. 그들 양자가 일치하는 경우에, 절차는 단계 S916으로 천이하고, 그들 양자가 불일치하는 경우에, 절차는 단계 S917로 천이한다. 여기에서는 각각의 사용자 식별자들이 "user_abcde" 및 "user_fghij"이고, 따라서 불일치한 것으로 판단된다.

단계 S916에서, 리소스 관리 모듈(371)은, 클라이언트(111)에 리소스를 반환하고 절차가 종료된다. 단계 S917에서, 리소스 관리 모듈(371)은, 리소스 소유자가 변경되기 때문에 리소스 액세스가 허용되지 않는 것을 클라이언트(111)에 통지하고, 절차가 종료된다. 여기서, 리소스 액세스가 허용되지 않는 것을 통지받은 클라이언트(111)는, 도 9a의 절차의 단계 S905에 따라, 단계 S901에서 액세스될 리소스의 리소스 식별자를 지정하여 인가 개시 요청을 수행한다는 점에 유의한다. 인가 개시 요청의 절차는 도 4a에 도시한 바와 같다.

제2 실시예에 따르면, 리소스 서버 상에서 리소스의 소유자가 변경된 경우에, 변경 전의 리소스 소유자에 의한 인가 시 발행된 액세스 토큰을 사용한 리소스로의 액세스가 허용되지 않아, 보안이 향상된다.

제3 실시예

이어서, 본 발명의 제3 실시예가 도면들을 참조하여 설명될 것이다. 제1 또는 제2 실시예의 것과 공통인 부분에 대해서는 설명이 생략될 것이고, 이하에서는 차이 부분만이 설명될 것이라는 점에 유의한다.

리소스의 소유자가 변경된 후, 새로운 리소스의 소유자에 인가가 요청되는 타이밍이, 클라이언트(111)가 리소스 서버(152)에 액세스한 타이밍으로 설정되는 경우, 다음 문제가 발생한다. 즉, 새로운 리소스의 소유자가 인가 조작을 수행할 때까지, 클라이언트(111)는 리소스에 액세스할 수 없다.

제3 실시예는, 전술한 과제를 감안하여 이루어진다. 도 10a 및 도 10b는 제3 실시예에 따른, 인가 서버(151) 및 리소스 서버(152)의 모듈 구성들을 도시한다. 도 10a는 인가 서버(151)의 모듈 구성을 도시하고, 인가 서버(151)는 인가 요청 갱신 모듈(355)을 갖는다. 도 10b는 리소스 서버(152)의 모듈 구성을 도시하고, 리소스 서버(152)는 리소스 소유자 변경 모듈(373)을 갖는다.

도 11a는 제3 실시예에 따라, 리소스 서버(152)에서 리소스 소유자가 변경되는 절차의 흐름도이다. 절차는 리소스 서버(152)가 리소스 소유자의 변경을 수신할 때 개시된다.

단계 S1101에서, 리소스 소유자 변경 모듈(373)은 리소스 소유자의 변경을 수신한다. 여기에서는, 리소스 "/datalake/iot0011/data"의 소유자가 "user_klmno"로 변경되는 것으로 가정한다. 단계 S1102에서, 리소스 소유자 변경 모듈(373)은 지정된 리소스의 소유자를 변경한다. 표 8은, 리소스 소유자가 변경된 후의 리소스 관리 테이블의 예를 나타낸다.

표 8에서는, 표 7과 비교하여, "/datalake/iot0011/data"에 의해 표시되는 리소스의 소유자가 변경된다. 새로운 리소스 소유자의 사용자 식별자는 "user_klmno"이다. 단계 S1103에서, 리소스 소유자 변경 모듈(373)은, 리소스 소유자가 변경된 것을 인가 서버(151)에 통지한다.

도 11b는 제3 실시예에 따라, 인가 서버(151)에서 인가 요청이 갱신되는 절차의 흐름도이다. 절차는 인가 서버(151)가 리소스 서버(152)로부터, 리소스 소유자의 변경 통지를 수신할 때 개시된다. 제1 실시예 및 제2 실시예에서는, 클라이언트(111)로부터 인가 개시 요청이 수신된 그러한 조건 하에, 사용자 단말(171)의 특정 처리 및 인가 확인 요청의 송신 처리가 수행된다. 반면, 제3 실시예는 변경 통지를 수신할 때 특정 처리 및 송신 처리가 개시되는 것을 특징으로 하며, 따라서, 인가 개시 요청이 수신된 타이밍에서 클라이언트(111)에 액세스 토큰을 송신하는 것을 가능하게 한다.

단계 S1111에서, 인가 요청 갱신 모듈(355)은, 리소스 서버(152)로부터 리소스 소유자의 변경 통지를 수신한다. 여기서, 리소스 소유자의 변경 통지는, 리소스 "/datalake/iot0011/data"의 소유자가 "user_klmno"로 변경된 것을 나타내는 것으로 가정한다. 단계 S1112에서, 인가 요청 갱신 모듈(355)은, 표 1의 인가 확인 상태 관리 테이블로부터, 소유자가 변경된 리소스에 대응하는 인가 요청을 추출한다. 여기에서는, 인가 요청 식별자들 "auth_req_id_98765" 및 "auth_req_id_44444"가 추출된다.

단계 S1113에서, 인가 요청 갱신 모듈(355)은, 단계 S1112에서 추출된 인가 요청의 사용자 식별자 및 인가 결과를 갱신한다. 표 9는 갱신 후의 인가 확인 상태 관리 테이블의 예이다.

표 9에서는, 인가 요청 식별자들이 "auth_req_id_98765" 및 "auth_req_id_44444"인 인가 요청들에서, 사용자 식별자가 "user_klmno"를 나타낸다. 또한, 인가 결과는 "(공란)"을 나타낸다. 이것은 새로운 리소스 소유자인 "user_klmno"에 대해 아직 인가 확인이 수행되지 않았기 때문이다.

단계 S1114에서, 인가 요청 갱신 모듈(355)은 단계 S1113에서 갱신된 인가 요청에 대해, 도 4c에서 나타내는 인가 확인 요청 절차를 실행한다.

도 4c에서 나타내는 인가 확인 요청 절차에서는, 새로운 리소스 소유자에 대해 인가 확인 요청이 송신된다는 점에 유의한다. 여기서, 새로운 리소스 소유자가 인가 조작을 수행할 때, 인가 서버(151)는, 도 5a에 나타낸 바와 같이, 클라이언트(111)에 대해, 새로운 리소스 소유자가 인가를 허가했다는 것을 통지한다.

여기서, 통지의 내용은, 단계 S501에서 취득된 인가 요청 식별자일 수 있거나, 사용자에 의한 인가에 응답하여 발행된 액세스 토큰일 수 있다. 통지 전에 미리 액세스 토큰이 발행될 때, 도 5c에 나타낸 바와 같은 절차가 수행된다. 대안적으로, 클라이언트(111)는, 인가 서버(151)에 대해, 임의의 타이밍에서 도 5b에 나타내는 바와 같은 액세스 토큰 요청을 송신할 수 있다. 여기서 인가 서버(151)는, 도 11b에서 인가 요청과 연관된 리소스 소유자가 갱신되었을 때, 새로운 리소스 소유자의 액세스 토큰을 발행한다.

제3 실시예에 따르면, 리소스 서버 상에서 리소스 소유자가 변경된 경우에, 변경에 신속히 대응하는 것이 가능하다. 즉, 변경 후에 새로운 리소스 소유자에 대해 인가 확인 요청을 수행하는 것이 가능하여, 클라이언트(111)에 의해 액세스 토큰 요청이 수행되기 전에 리소스 소유자에 의한 인가 조작을 완료하는 것이 가능하게 된다. 따라서, 편리성이 향상된다.

본 발명이 예시적인 실시예들을 참조하여 설명되었지만, 본 발명은 개시된 예시적인 실시예들로 제한되지 않는다는 것을 이해해야 한다. 이하의 청구항들의 범위는 모든 이러한 수정들 및 등가의 구조들 및 기능들을 포괄하도록 최광의로 해석되어야 한다.

Claims

사용자의 리소스를 제공하는 리소스 서버, 상기 리소스에 액세스하는 클라이언트, 상기 클라이언트에 의해 상기 리소스에 액세스하는 것이 상기 사용자에 의해 허가된 것을 나타내는 액세스 토큰을 발행하는 인가 서버 및 사용자 단말을 포함하는 시스템에서의 인가 서버로서,
상기 클라이언트에 의해 액세스될 상기 리소스에 대응하는 리소스 식별자를 포함하는 인가 개시 요청을 수신하도록 구성된 수신 유닛;
상기 수신 유닛에 의해 수신된 상기 인가 개시 요청에 포함되는 상기 리소스 식별자와 함께, 상기 리소스 식별자에 대응하는 상기 리소스의 소유자인 상기 사용자를 해결하기 위해 수행되는 요청을 상기 리소스 서버에 송신하도록 구성된 송신 유닛;
상기 요청에 대한 응답으로서 취득된 상기 사용자에 관한 정보와 연관된 단말 정보를 특정하도록 구성된 특정 유닛;
상기 특정된 단말 정보에 대응하는 상기 사용자 단말에 대해 인가 확인 요청을 송신하고, 응답으로서 인가 확인의 결과를 수신하도록 구성된 확인 유닛; 및
상기 확인 유닛에 의해 수신된 상기 인가 확인의 결과에 따라 상기 액세스 토큰의 발행을 제어하고, 상기 액세스 토큰이 발행된 경우에, 상기 발행된 액세스 토큰을 상기 인가 개시 요청을 송신했던 상기 클라이언트에 송신하도록 구성된 발행 유닛을 포함하는 인가 서버.
제1항에 있어서,
사용자 식별자와 상기 단말 정보가 연관되는 사용자 관리 테이블을 저장하도록 구성된 저장 유닛을 추가로 포함하고,
상기 특정 유닛은, 상기 요청에 대한 응답으로서 상기 사용자 식별자를 취득하고, 상기 취득된 사용자 식별자와 연관된 상기 단말 정보를 상기 사용자 관리 테이블에 기초하여 특정하는 인가 서버.
제1항 또는 제2항에 있어서,
상기 특정된 단말 정보에 대응하는 상기 사용자 단말에 대해 상기 인가 확인 요청이 송신되는 경우, 상기 사용자 단말로부터의 액세스 없이, 상기 인가 확인 요청이 송신되는 인가 서버.
제1항 또는 제2항에 있어서,
상기 발행된 액세스 토큰을 사용하는 것에 의해 상기 리소스를 취득할 수 없는 상기 클라이언트로부터 상기 인가 개시 요청이 수신되는 경우, 상기 송신 유닛은, 상기 리소스의 소유자인 상기 사용자를 해결하기 위해 수행되는 상기 요청을 상기 리소스 서버에 다시 송신하는 인가 서버.
제1항 또는 제2항에 있어서,
상기 리소스 서버로부터 상기 리소스의 상기 소유자의 변경의 통지가 수신되는 경우, 상기 클라이언트로부터 상기 인가 개시 요청이 수신되기 전에, 상기 사용자 단말에 대해 상기 인가 확인 요청이 송신되는 인가 서버.
제5항에 있어서,
상기 클라이언트로부터 상기 인가 개시 요청이 수신되는 타이밍에서 상기 인가 확인 요청에 대한 응답으로서 상기 인가 확인의 결과가 수신되고, 상기 인가 확인의 결과가 허가를 나타내는 것이 확인된 경우, 미리 발행된 상기 액세스 토큰이 송신되는 인가 서버.
사용자의 리소스를 제공하는 리소스 서버, 상기 리소스에 액세스하는 클라이언트, 상기 클라이언트에 의해 상기 리소스에 액세스하는 것이 상기 사용자에 의해 허가된 것을 나타내는 액세스 토큰을 발행하는 인가 서버 및 사용자 단말을 포함하는 시스템에서의 상기 인가 서버에 의해 실행가능한 제어 방법으로서,
상기 클라이언트에 의해 액세스될 상기 리소스에 대응하는 리소스 식별자를 포함하는 인가 개시 요청을 수신하는 수신 단계;
상기 수신 단계에서 수신된 상기 인가 개시 요청에 포함되는 상기 리소스 식별자와 함께, 상기 리소스 식별자에 대응하는 상기 리소스의 소유자인 상기 사용자를 해결하기 위해 수행되는 요청을 상기 리소스 서버에 송신하는 송신 단계;
상기 요청에 대한 응답으로서 취득된 상기 사용자에 관한 정보와 연관된 단말 정보를 특정하는 특정 단계;
상기 특정된 단말 정보에 대응하는 상기 사용자 단말에 대해 인가 확인 요청을 송신하고, 응답으로서 인가 확인의 결과를 수신하는 확인 단계; 및
상기 확인 단계에서 수신된 상기 인가 확인의 결과에 따라서 상기 액세스 토큰의 발행을 제어하고, 상기 액세스 토큰이 발행된 경우, 상기 인가 개시 요청을 송신했던 상기 클라이언트에 상기 발행된 액세스 토큰을 송신하는 발행 단계를 포함하는 방법.
제7항에 있어서,
상기 인가 서버로 하여금, 사용자 식별자와 상기 단말 정보가 연관되는 사용자 관리 테이블을 저장하게 하는 저장 단계를 추가로 포함하고,
상기 특정 단계에서는, 상기 요청에 대한 응답으로서 상기 사용자 식별자가 취득되게 되고, 상기 취득된 사용자 식별자와 연관된 상기 단말 정보가 상기 사용자 관리 테이블에 기초하여 특정되게 되는 방법.
제7항 또는 제8항에 있어서,
상기 특정된 단말 정보에 대응하는 상기 사용자 단말에 대해 상기 인가 확인 요청이 송신되는 경우, 상기 사용자 단말로부터의 액세스 없이, 상기 인가 확인 요청이 송신되게 되는 방법.
제7항 또는 제8항에 있어서,
상기 발행된 액세스 토큰을 사용하여 상기 리소스를 취득할 수 없는 상기 클라이언트로부터 상기 인가 개시 요청이 수신되는 경우, 상기 송신 단계에서는, 상기 리소스의 소유자인 상기 사용자를 해결하기 위해 수행되는 상기 요청이 상기 리소스 서버에 다시 송신되게 되는 방법.
제7항 또는 제8항에 있어서,
상기 리소스 서버로부터 상기 리소스의 상기 소유자의 변경의 통지가 수신되는 경우, 상기 클라이언트로부터 상기 인가 개시 요청이 수신되기 전에, 상기 사용자 단말에 대해 상기 인가 확인 요청이 송신되게 되는 방법.
제11항에 있어서,
상기 클라이언트로부터 상기 인가 개시 요청이 수신되는 타이밍에서 상기 인가 확인 요청에 대한 응답으로서 상기 인가 확인의 결과가 수신되고, 상기 인가 확인의 결과가 허가를 나타내는 것이 확인된 경우, 미리 발행된 상기 액세스 토큰이 송신되게 되는 방법.
사용자의 리소스를 제공하는 리소스 서버, 상기 리소스에 액세스하는 클라이언트, 상기 클라이언트에 의해 상기 리소스에 액세스하는 것이 상기 사용자에 의해 허가된 것을 나타내는 액세스 토큰을 발행하는 인가 서버 및 사용자 단말을 포함하는 시스템에서의 상기 인가 서버에 의해 실행가능한 저장 매체에 저장되는 프로그램으로서,
상기 인가 서버로 하여금 상기 클라이언트에 의해 액세스될 상기 리소스에 대응하는 리소스 식별자를 포함하는 인가 개시 요청을 수신하게 하는 수신 단계;
상기 인가 서버로 하여금 상기 수신 단계에서 수신된 상기 인가 개시 요청에 포함되는 상기 리소스 식별자와 함께, 상기 리소스 식별자에 대응하는 상기 리소스의 소유자인 상기 사용자를 해결하기 위해 수행되는 요청을 상기 리소스 서버에 송신하게 하는 송신 단계;
상기 인가 서버로 하여금 상기 요청에 대한 응답으로서 취득된 상기 사용자에 관한 정보와 연관된 단말 정보를 특정하게 하는 특정 단계;
상기 인가 서버로 하여금 상기 특정된 단말 정보에 대응하는 상기 사용자 단말에 대해 인가 확인 요청을 송신하게 하고, 응답으로서 인가 확인의 결과를 수신하게 하는 확인 단계; 및
상기 인가 서버로 하여금 상기 확인 단계에서 수신된 상기 인가 확인의 결과에 따라서 상기 액세스 토큰의 발행을 제어하게 하고, 상기 액세스 토큰이 발행된 경우, 상기 인가 개시 요청을 송신했던 상기 클라이언트에 상기 발행된 액세스 토큰을 송신하게 하는 발행 단계를 포함하는, 인가 서버에 의해 실행가능한 저장 매체에 저장되는 프로그램.