KR20200002680A - 멀티 도메인 서비스들을 위한 단일 인증 방법 그리고 이를 구현한 시스템 - Google Patents

멀티 도메인 서비스들을 위한 단일 인증 방법 그리고 이를 구현한 시스템 Download PDF

Info

Publication number
KR20200002680A
KR20200002680A KR1020190077914A KR20190077914A KR20200002680A KR 20200002680 A KR20200002680 A KR 20200002680A KR 1020190077914 A KR1020190077914 A KR 1020190077914A KR 20190077914 A KR20190077914 A KR 20190077914A KR 20200002680 A KR20200002680 A KR 20200002680A
Authority
KR
South Korea
Prior art keywords
service
authentication
token
client
login
Prior art date
Application number
KR1020190077914A
Other languages
English (en)
Other versions
KR102232763B1 (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 KR20200002680A publication Critical patent/KR20200002680A/ko
Application granted granted Critical
Publication of KR102232763B1 publication Critical patent/KR102232763B1/ko

Links

Images

Classifications

    • 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/41—User authentication where a single sign-on provides access to a plurality of computers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

멀티 도메인 서비스들의 단일 인증을 주관하는 주관 인증 서버가, 상기 멀티 도메인 서비스들의 인증 서버들과 연동하여 단일 인증하는 방법으로서, 클라이언트의 로그인 요청에 포함된 주 계정에 대해 인증하고, 인증 성공한 상기 클라이언트로 로그인 토큰을 발급하는 단계, 상기 멀티 도메인 서비스들 중에서, 상기 로그인 토큰이 발급된 상기 주 계정에 연결된 서비스들을 제1 서비스 리스트로 생성하고, 상기 제1 서비스 리스트와 함께 단일 인증 토큰을 상기 클라이언트에게 발급하는 단계, 상기 제1 서비스 리스트에 포함된 임의 서비스의 인증 서버로부터, 단일 인증 토큰 검증 요청을 수신하면, 상기 단일 인증 토큰 검증 요청에 포함된 토큰이 상기 클라이언트로 발급한 상기 단일 인증 토큰인지 검증하는 단계, 그리고 검증 성공한 경우, 상기 임의 서비스를 상기 주 계정의 세션에 추가하고, 상기 세션의 키를 상기 임의 서비스의 인증 서버로 전달하는 단계를 포함한다. 상기 클라이언트는 사용자 단말의 브라우저이다. 상기 임의 서비스의 인증 서버는 상기 클라이언트를 위한 상기 세션의 키를 설정하고, 상기 클라이언트에 상기 임의 서비스를 이용할 수 있는 인증 쿠키를 생성할 수 있다.

Description

멀티 도메인 서비스들을 위한 단일 인증 방법 그리고 이를 구현한 시스템{SINGLE-SIGN-ON METHOD AND SYSTEM FOR MULTI-DOMAIN SERVICES}
본 발명은 단일 인증(Single Sign On, SSO) 기술에 관한 것이다.
SSO(Single Sign On)는 하나의 계정 로그인으로 여러 서비스들을 이용 가능하게 하는 기술로서, 단일 인증, 통합 인증, 싱글사인온, 단일 계정 로그인 등으로 부른다.
SSO는 다양하게 구현될 수 있다. 예를 들어, 단말의 브라우저는 로그인 시 발급된 고유키를 쿠키로 생성하고, 쿠키를 통해 각 서비스 사이트에 접속하며, 로그아웃 시 쿠키를 삭제한다. 대체로 복수의 서비스 사이트들이 동일 도메인에서 제공되는 경우, 쿠키를 통해 SSO를 쉽게 구현할 수 있다.
최근에는 서로 다른 도메인에서 제공되는 서비스간 연동 시도나 기업 합병 등으로, 이미 개별적인 인증 체계로 구축된 복수의 서비스 사이트들을 통합하고 단일 인증할 필요가 생기고 있다. 하지만, 다른 도메인에서 제공되는 서비스 사이트들의 경우, 크로스 도메인(cross domain) 문제가 있고, 크로스 도메인 문제를 해결하기 위한 CORS(Cross Origin Resource Sharing)는 쿠키 발급 제한 등의 제약이 존재하여 SSO 구현이 쉽지 않다. 또한, 각 서비스 사이트가 고유의 인증 서버에 의해 접근 관리되는 상황에서, 멀티 도메인 서비스들의 서로 다른 인증 서버들을 통합 인증하고, 통합적으로 세션 관리하는 것이 쉽지 않다.
해결하고자 하는 과제는 멀티 도메인 서비스들의 단일 인증 로그인 및 로그아웃, 그리고 로그인 복구 절차 또는 재인증 절차에 사용되는 느린(lazy) 단일 인증 로그인을 제공하고, 단일 인증된 멀티 도메인 서비스들의 세션을 통합 관리하는 방법 및 그리고 이를 구현한 시스템을 제공하는 것이다.
한 실시예에 따라, 멀티 도메인 서비스들의 단일 인증을 주관하는 주관 인증 서버가, 상기 멀티 도메인 서비스들의 인증 서버들과 연동하여 단일 인증하는 방법으로서, 클라이언트의 로그인 요청에 포함된 주 계정에 대해 인증하고, 인증 성공한 상기 클라이언트로 로그인 토큰을 발급하는 단계, 상기 멀티 도메인 서비스들 중에서, 상기 로그인 토큰이 발급된 상기 주 계정에 연결된 서비스들을 제1 서비스 리스트로 생성하고, 상기 제1 서비스 리스트와 함께 단일 인증 토큰을 상기 클라이언트에게 발급하는 단계, 상기 제1 서비스 리스트에 포함된 임의 서비스의 인증 서버로부터, 단일 인증 토큰 검증 요청을 수신하면, 상기 단일 인증 토큰 검증 요청에 포함된 토큰이 상기 클라이언트로 발급한 상기 단일 인증 토큰인지 검증하는 단계, 그리고 검증 성공한 경우, 상기 임의 서비스를 상기 주 계정의 세션에 추가하고, 상기 세션의 키를 상기 임의 서비스의 인증 서버로 전달하는 단계를 포함한다. 상기 클라이언트는 사용자 단말의 브라우저이다. 상기 임의 서비스의 인증 서버는 상기 클라이언트를 위한 상기 세션의 키를 설정하고, 상기 클라이언트에 상기 임의 서비스를 이용할 수 있는 인증 쿠키를 생성한다.
상기 단일 인증 토큰인지 검증하는 단계는 상기 제1 서비스 리스트에 포함된 각 서비스의 인증 서버로부터, 비동기적으로 상기 단일 인증 토큰 검증 요청을 수신할 수 있다.
상기 단일 인증 방법은 상기 클라이언트의 로그아웃 요청을 전달받는 단계, 그리고 상기 주 계정의 로그인 시 생성된 상기 세션에 추가된 서비스들을 제2 서비스 리스트로 생성하고, 상기 제2 서비스 리스트를 상기 클라이언트에게 전달하는 단계를 더 포함할 수 있다. 상기 클라이언트는 상기 제2 서비스 리스트에 포함된 각 서비스의 인증 서버로 해당 서비스의 로그아웃을 요청할 수 있다.
상기 단일 인증 방법은 상기 클라이언트의 로그아웃 요청을 전달받는 단계, 그리고 상기 주 계정의 로그인 시 생성된 상기 세션을 삭제하여 단일 인증 로그아웃하는 단계를 더 포함할 수 있다. 상기 세션은 상기 세션의 키를 받은 서비스들이 추가된 공용 세션일 수 있다.
상기 단일 인증 방법은 상기 클라이언트에 상기 로그인 토큰을 발급한 이후, 상기 클라이언트로부터 특정 서비스에 대한 느린(lazy) 단일 인증 시작 요청을 수신하는 단계, 그리고 상기 단일 인증 토큰 또는 신규 단일 인증 토큰을 상기 클라이언트에게 발급하는 단계를 더 포함할 수 있다. 상기 클라이언트는 상기 특정 서비스의 서버에 접속한 상태에서, 상기 주관 인증 서버에 관련된 서비스 서버에서 제공하는 로그인 확인 인터페이스를 호출하여 상기 느린 단일 인증 시작을 요청할 수 있다. 또는 상기 클라이언트는 상기 특정 서비스의 서버에 접속한 상태에서, 상기 주관 인증 서버에 관련된 서비스 서버에서 제공하는 단일 인증 로그인 페이지로 이동(redirect)하여 호출하여 상기 느린 단일 인증 시작을 요청할 수 있다.
다른 실시예에 따라, 멀티 도메인 서비스들 중 특정 서비스의 인증 서버가, 상기 멀티 도메인 서비스들의 단일 인증을 주관하는 주관 인증 서버와 연동하여, 단일 인증하는 방법으로서, 클라이언트로부터 단일 인증 토큰을 포함하는 단일 인증 요청을 수신하는 단계, 상기 주관 인증 서버로 상기 클라이언트가 상기 단일 인증 토큰에 대한 소유권을 가지는 지 소유권 검증을 요청하는 단계, 상기 주관 인증 서버로부터, 소유권 검증 결과를 수신하고, 상기 소유권 검증 결과가 성공인 경우, 상기 클라이언트를 위해 상기 소유권 검증 결과에 포함된 세션 키를 설정하는 단계, 그리고 상기 클라이언트에 상기 특정 서비스를 이용할 수 있는 인증 쿠키를 생성하는 단계를 포함한다. 상기 클라이언트는 사용자 단말의 브라우저이다. 상기 특정 서비스의 계정은 주 계정에 연결되어 있으며, 상기 단일 인증 토큰은 상기 주관 인증 서버가 상기 클라이언트에서 요청한 상기 주 계정에 대한 로그인 성공 후, 상기 클라이언트에게 발급한 토큰이다. 상기 세션 키는 상기 주 계정의 로그인 시 생성된 세션의 키이다.
상기 클라이언트는 iFrame을 이용하여 상기 특정 서비스의 인증 서버로 상기 단일 인증 요청할 수 있다.
상기 단일 인증 방법은 상기 인증 쿠키를 생성한 이후, 상기 클라이언트로부터 로그아웃 요청을 수신하는 단계, 그리고 상기 클라이언트에 대한 로그아웃 처리하고, 상기 클라이언트로 로그아웃 응답하는 단계를 더 포함할 수 있다. 상기 클라이언트는 상기 주관 인증 서버로 로그아웃 요청하여 수신한 서비스 리스트를 기초로 상기 단일 인증 요청을 전송할 수 있다.
또 다른 실시예에 따라. 사용자 단말의 브라우저가 멀티 도메인 서비스들로 단일 인증하는 방법으로서, 멀티 도메인 서비스들의 단일 인증을 주관하는 주관 서비스 시스템으로, 주 계정에 대한 로그인 요청하고, 상기 주관 서비스 시스템으로부터 상기 주 계정에 대한 로그인 토큰을 발급받는 단계, 상기 주관 서비스 시스템으로, 상기 로그인 토큰 및 클라이언트 정보를 포함하는 단일 인증 시작 요청을 전송하고, 상기 주관 서비스 시스템으로부터 상기 주 계정에 연결된 서비스들을 포함하는 제1 서비스 리스트와 함께 단일 인증 토큰을 발급받는 단계, 그리고 상기 제1 서비스 리스트에 포함된 각 서비스의 인증 서버로, 상기 단일 인증 토큰을 포함하는 단일 인증 요청을 전송하고, 해당 서비스의 인증 서버로부터 발급된 해당 서비스의 인증 쿠키를 설정하는 단계를 포함한다.
상기 단일 인증 방법은 상기 주관 서비스 시스템으로 로그아웃 요청하고, 상기 주관 서비스 시스템으로부터 상기 주 계정의 로그인 시 생성된 상기 세션에 추가된 서비스들을 포함하는 제2 서비스 리스트를 수신하는 단계, 그리고 상기 제2 서비스 리스트에 포함된 각 서비스의 인증 서버로 해당 서비스의 로그아웃을 요청하는 단계를 더 포함할 수 있다.
상기 단일 인증 방법은 상기 멀티 도메인 서비스들 중 특정 서비스의 서비스 서버에 접속한 상태에서, 상기 서비스 서버로부터 로그인 필요 응답을 수신하는 단계, 상기 주관 서비스 시스템으로 상기 특정 서비스에 대한 느린(lazy) 단일 인증 시작을 요청하는 단계, 상기 주관 서비스 시스템으로부터 상기 단일 인증 토큰 또는 신규 단일 인증 토큰을 발급받는 단계, 그리고 상기 특정 서비스의 인증 서버로 상기 특정 서비스에 대해 발급받은 토큰을 포함하는 단일 인증 요청을 전송하고, 상기 특정 서비스의 인증 서버로부터 발급된 상기 특정 서비스의 인증 쿠키를 설정하는 단계를 더 포함할 수 있다.
상기 느린 단일 인증 시작을 요청하는 단계는 상기 로그인 토큰을 JSONP로 전달함으로써 상기 느린 단일 인증 시작을 요청할 수 있다.
상기 느린 단일 인증 시작을 요청하는 단계는 상기 특정 서비스의 서비스 페이지에서 상기 주관 서비스 시스템의 단일 인증 로그인 페이지로 이동(redirect)한 후, 상기 로그인 토큰을 상기 주관 서비스 시스템으로 전달함으로써 상기 느린 단일 인증 시작을 요청할 수 있다.
상기 느린 단일 인증 시작을 요청하는 단계는 상기 로그인 토큰을 JSONP로 전달할 수 없는 경우, 상기 특정 서비스의 서비스 페이지에서 상기 주관 서비스 시스템의 단일 인증 로그인 페이지로 이동(redirect)한 후, 상기 로그인 토큰을 상기 주관 서비스 시스템으로 전달함으로써 상기 느린 단일 인증 시작을 요청할 수 있다.
실시예에 따르면 사용자는 주 계정에 대한 로그인만으로 주 계정에 연결된 멀티 도메인 서비스들을 이용할 수 있다.
실시예에 따르면 서비스 제공자는 서로 다른 도메인에서 개별적인 인증 체계로 구현된 복수의 서비스들을 단일 인증 체계로 통합할 수 있다. 실시예에 따르면 단일 인증 시스템은 복수 인증 서버들의 연동을 통해 단일 인증 로그인 및 단일 인증 로그아웃할 수 있고, 단일 인증된 서비스들을 주 계정의 로그인 세션에 통합 관리할 수 있다.
실시예에 따르면 단일 인증 시스템은 느린(lazy) 단일 인증 로그인 방법을 통해, 로그인 시점에 단일 인증에 실패한 서비스에 대한 로그인 복구를 제공할 수 있고, 재인증이 요구되는 서비스에 대한 재인증 절차를 제공할 수 있다. 특히 단일 인증 로그인 단계에서 서비스 사이트에 접속 장애가 있거나, 단말에 설치된 브라우저(클라이언트)의 문제로 일부 서비스에 대한 단일 인증이 실패하더라도, 브라우저는 비동기적인 느린 단일 인증 로그인을 통해, 해당 서비스의 로그인 절차를 복구할 수 있다. 실시예에 따르면 단일 인증 가능한 복수의 서비스들 중에서, 로그인이 필요한 이벤트가 발생하면 로그인을 요구하는 서비스나 주기적으로 재인증을 요구하는 서비스가 있다면, 브라우저는 비동기적인 느린 단일 인증 로그인을 통해, 해당 서비스의 로그인 절차를 진행할 수 있다.
도 1은 한 실시예에 따른 단일 인증 시스템 구성도이다.
도 2는 한 실시예에 따른 단일 인증 로그인 흐름도이다.
도 3은 한 실시예에 따른 단일 인증 로그아웃 흐름도이다.
도 4와 도 5 각각은 한 실시예에 따른 느린(lazy) 단일 인증 로그인의 흐름도이다.
아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다. 또한, 명세서에 기재된 "…부", "…기", "모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.
단말은 컴퓨터 판독 가능한 저장 매체에 저장되는 프로그램, 그리고 프로세서, 메모리, 디스플레이, 통신 모듈 등의 하드웨어를 포함한다. 프로세서는 하드웨어들과 협력하여 프로그램을 구동한다. 디스플레이는 프로그램에서 제공하는 사용자 인터페이스 화면을 표시하고, 사용자 입력을 수신한다. 통신 모듈은 통신망을 통해 본 발명에 설명하는 각종 서버와 통신한다. 설명에서, 프로그램은 서버에서 제공하는 정보를 화면에 표시하고, 입력 정보를 서버에 전송하는 브라우저(Browser) 프로그램일 수 있다.
단말은 다양한 형태로 구현될 수 있고, 랩탑 컴퓨터, 데스크탑 컴퓨터, 모바일 단말 등 각종 형태의 컴퓨터, 웨어러블 디바이스, TV 단말 등의 형태로 구현될 수 있다.
도 1은 한 실시예에 따른 단일 인증 시스템 구성도이다.
도 1을 참고하면, 단일 인증 시스템은 다양한 서비스들 각각을 개별적으로 제공하는 서비스 시스템들이 연동하도록 구축된다. 여기에서는 3개의 서비스 시스템들(10, 20, 30)을 가정하여 설명한다. 사용자 단말(40)은 브라우저를 통해, 다양한 서비스 사이트들(예를 들면, kakao.com, daum.net, melon.com)에 접속한다. 서비스 사이트들은 다른 도메인들에 존재할 수 있다.
각 서비스 시스템은 서비스 이용에 요구되는 로그인 등의 각종 인증처리를 담당하는 인증 서버(100, 200, 300), 해당 서비스를 사용자 단말에 제공하는 서비스 서버(130, 230, 330), 그리고 해당 서비스에 필요한 데이터를 저장하는 데이터베이스(150, 250, 350)를 포함할 수 있고, 각 서비스 시스템을 구성하는 서버와 데이터베이스는 다양하게 설계될 수 있다.
설명에서는 각 서비스 시스템이 서비스 고유의 인증 서버(100, 200, 300)를 가지고 있고, 각 인증 서버가 각 서비스 가입자에 대한 접속 인증을 개별적으로 수행한다고 가정한다. 인증 서버(100)는 주(main) 계정을 통해 다른 서비스들에서 발급된 계정들의 연결 정보를 관리하고, 사용자 단말(40)의 브라우저에서 입력된 주 계정을 통해 서비스 시스템들(10, 20, 30)이 제공하는 복수의 서비스들로의 단일 인증 로그인, 단일 인증 로그아웃 등의 단일 인증 절차를 주관할 수 있다. 여기서, 서비스 서버(130)가 사용자 단말(40)의 브라우저에 표시되는 로그인 페이지를 제공하고, 로그인 페이지에서 입력된 주 계정 정보를 인증 서버(100)로 전달한다. 앞으로 인증 서버(100)를 주관 인증 서버, 서비스 서버(130)를 주관 서비스 서버, 그리고 데이터베이스(150)를 주관 서비스 데이터베이스라고 부르고, 이들을 포함하는 서비스 시스템(10)을 주관 서비스 시스템이라고 부를 수 있다. 사용자 단말(40) 또는 사용자 단말(40)의 브라우저는 인증 서버(100, 200, 300), 서비스 서버(130, 230, 330)와 통신하는 클라이언트(client)이다. 브라우저는 사용자 단말(40)에 설치된 프로그램으로서, 브라우저의 종류는 다양할 수 있고, 브라우저 개발사에서 제공하는 범용 브라우저일 수 있다.
멀티 도메인 서비스들을 예로 들면, 주관 인증 서버(100)가 주 계정(예를 들면, 카카오 계정) 기반의 인증 및 세션 관리 서버이고, 인증 서버(200)가 서비스A(예를 들면, daum.net)로의 접속을 관리하는 서버이며, 인증 서버(300)가 서비스B(예를 들면, melon.com)로의 접속을 관리하는 서버일 수 있다. 예를 들어, 카카오 계정이 다음 서비스 계정 및 멜론 서비스 계정과 연결된 주 계정인 경우, 카카오 계정으로 로그인된 상태에서, 브라우저와 인증 서버들(100, 200, 300) 사이의 연동을 통해 다음 서비스와 멜론 서비스의 단일 인증이 진행된다. 따라서, 사용자는 다음 서비스와 멜론 서비스로 별도 로그인할 필요 없이, 해당 서비스들을 이용할 수 있다.
서비스 계정들이 통합되면, 단일 인증은 주관 인증 서버(100) 및 주관 서비스 서버(130)에서 시작한다. 서비스A 및 서비스B의 인증 서버(200, 300)는 주관 인증 서버(100)와 연동하여, 브라우저에서 전달받은 값들을 검증하고, 검증 결과를 통해 해당 서비스 사이트로의 접속(로그인)을 허용한다. 구체적으로, 주관 인증 서버(100)가 주 계정(예를 들면, 카카오 계정)에 대해 로그인 토큰 및 로그인 세션을 생성한 후, 주 계정에 연결된 서비스A 및 서비스B가 있으면, 단일 인증을 위한 토큰(SSO 토큰)을 발급한다. 이후, 서비스A 및 서비스B의 인증 서버(200, 300)는 사용자 단말의 브라우저로부터 전달된 SSO 토큰을 주관 인증 서버(100)로부터 검증받고, 검증 결과를 기초로 SSO 토큰을 발급받은 사용자 단말의 브라우저를 통해 접속을 허용한다. 여기서, SSO 토큰은 비동기적으로 해당 서비스의 인증 서버로 전달될 수 있고, 전달되는 방식은 브라우저의 특성에 맞게 결정될 수 있다.
한편, 데이터베이스(150)는 주관 인증 서버(100)에서 생성된 인증 및 세션 관리 정보를 저장한다. 특히, 로그인된 주 계정 및 주 계정에 대응하여 생성된 로그인 세션을 공용 세션(글로벌 세션)으로 관리한다. 데이터베이스(150)는 주 계정 및 연결 계정을 저장할 수 있다. 공용 세션은 로그인 세션에 연결된 여러 서비스들을 추가한 세션이다. 따라서, 주관 인증 서버(100)는 공용 세션을 삭제(expire)함으로서, 단일 인증 로그아웃할 수 있다.
계정 및 세션 정보 이외에도, 데이터베이스(150)는 표 1과 같이, 주관 인증 서버(100)가 클라이언트에 발급한 로그인 토큰, SSO 토큰 및 클라이언트 식별을 위한 클라이언트 정보(예를 들면, IP 주소, 브라우저 정보, OS 정보 등) 등을 관리할 수 있다.
계정 계정 로그인 토큰 SSO 토큰 클라이언트 정보 공용 세션 정보
계정1 계정 로그인 토큰1 SSO 토큰1 클라이언트1 공용 세션 키1;
계정서비스(kakao.com)
서비스A(daum.net)
서비스B(melon.com)
계정2 계정 로그인 토큰2 SSO 토큰2 클라이언트2 공용 세션 키2;
계정서비스(kakao.com)
서비스B(melon.com)
사용자 단말(40)에 탑재된 브라우저(클라이언트)는 다양한 프로토콜로 인증 서버들과 통신할 수 있다. 특히, 동일-출처 정책(same-origin policy)과 같이 크로스 도메인(cross domain) 문제가 있어, 도메인간 호출이나 접근 제약이 브라우저에 존재한다. 이를 해결하기 위해, 브라우저는 특정 포맷(예를 들면, JSONP)으로 로그인 요청, 로그아웃 요청, SSO 인증 요청하고, 쿠키를 전송할 수 있다. 브라우저는 서비스들의 로그인 페이지들을 특정 태그(예를 들면, iFrame)로 호출하고, 특정 태그를 통해 본 발명의 단일 인증 절차를 구현할 수 있다. 또는 브라우저는 리디렉션(redirection)을 통해 본 발명의 단일 인증 절차를 구현할 수 있다.도 2는 한 실시예에 따른 단일 인증 로그인 흐름도이다.
도 2를 참고하면, 사용자 단말(40)의 브라우저가 단일 인증을 주관하는 주관 서비스 서버(130)에 접속하고, 계정에 대한 로그인 요청을 한다(S110). 로그인 요청은 이메일, 전화번호 또는 비밀번호 등의 계정 정보를 포함할 수 있다. 주관 서비스 서버(130)는 사용자 단말(40)의 브라우저에 단일 인증용 로그인 페이지를 제공한다.
주관 서비스 서버(130)는 주관 인증 서버(100)에게 로그인 요청에 포함된 계정 인증을 요청한다(S112). 계정 인증 요청은 로그인 요청에 포함된 계정 정보를 포함할 수 있다.
주관 인증 서버(100)는 계정 인증 요청에 포함된 계정을 확인하고, 계정 인증 성공 시, 계정에 대한 로그인 토큰을 주관 서비스 서버(130)로 전달한다(S114). 또한 주관 인증 서버(100)는 인증 성공 시, 계정에 대한 로그인 세션을 생성한다. 계정 인증 실패 시, 사용자 단말(40)의 브라우저는 로그인 요청을 재시도할 수 있도록 로그인 페이지를 표시한다.
주관 서비스 서버(130)는 로그인 토큰을 사용자 단말(40)의 브라우저에 전달한다(S116). 계정 로그인 토큰은 브라우저에 쿠키로 설정된다.
계정 인증을 완료한 사용자 단말(40)의 브라우저는 주관 서비스 서버(130)에 단일 인증(SSO) 시작 요청을 한다(S120). SSO 시작 요청은 로그인 토큰, 그리고 클라이언트 정보를 포함할 수 있다. 클라이언트 정보는 사용자 단말(40) 또는 브라우저의 정보로서, 예를 들면, IP 주소, 브라우저 정보 또는 OS 정보 등을 적어도 하나 포함할 수 있다.
주관 서비스 서버(130)는 SSO 시작 요청에 대응하여, 주관 인증 서버(100)에게 단일 인증을 위한 SSO 토큰 발급을 요청한다(S122). SSO 토큰 발급 요청은 SSO 요청에 포함된 로그인 토큰, 클라이언트 정보를 포함할 수 있다.
주관 인증 서버(100)는 로그인 토큰을 발급한 계정의 연결 서비스들을 확인한다(S124).
주관 인증 서버(100)는 계정에 연결된 서비스A와 서비스B를 SSO 서비스 리스트로 생성하고, SSO 서비스 리스트와 SSO 토큰을 주관 서비스 서버(130)로 전달한다(S126). 주관 인증 서버(100)는 발급한 SSO 토큰 소유권을 관리하는데, SSO 토큰 발급을 요청한 클라이언트 정보에 SSO 토큰을 매핑한 후, SSO 토큰 소유권 검증 시, 매핑된 클라이언트 정보를 이용할 수 있다. SSO 서비스 리스트는 서비스 API url 주소 또는 서비스 심볼 스트링으로 작성될 수 있다. 이때, 주관 인증 서버(100)는 계정에 연결된 복수의 서비스들이 존재하는 경우, 각 서비스가 SSO 인증 가능한 상태인지 확인하고, SSO 인증이 가능한 서비스들만을 SSO 서비스 리스트로 생성할 수 있다. 만약, 계정에 연결된 복수의 서비스들이 존재하더라도, SSO 인증 가능한 서비스가 없는 경우, 주관 인증 서버(100)는 SSO 토큰을 발급하지 않고, 주관 서비스 서버(130)에게 SSO 인증 불필요를 통보할 수 있다.
주관 서비스 서버(130)는 SSO 시작 요청의 응답으로, SSO 서비스 리스트와 SSO 토큰을 사용자 단말(40)의 브라우저에 전달한다(S128). SSO 서비스 리스트는 서비스A의 인증 서버(200)의 접속 주소, 서비스B의 인증 서버(300)의 접속 주소를 포함할 수 있다. SSO 토큰은 브라우저에 쿠키로 설정될 수 있다.
SSO 토큰을 발급받은 사용자 단말(40)의 브라우저는 SSO 서비스 리스트에 포함된 서비스B의 인증 서버(300)와 서비스A의 인증 서버(200)로 SSO 인증 요청을 한다(S130, S140). SSO 인증 요청은 발급받은 SSO 토큰을 포함하고, 비동기적으로 진행되며, S130과 S140의 진행 순서는 바뀔 수 있다. 이때, 사용자 단말(40)의 브라우저는 인증 서버(200)와 인증 서버(300) 각각의 로그인 인터페이스를, SSO 토큰을 담은 특정 태그(예를 들면, iFrame)로 호출하는 방식으로 SSO 인증 요청할 수 있다. 브라우저가 비동기적으로 SSO 인증 요청하므로, SSO 인증 과정에서 일부 서비스의 장애 또는 클라이언트에 문자가 있더라도 다른 서비스의 SSO 인증에 영향을 주지 않을 수 있다. 또한, 브라우저가 비동기적으로 SSO 인증 요청하므로, SSO 인증이 필요한 시점에 해당 서비스로 SSO 인증 요청을 할 수 있는 유연한 인증 체계를 구현할 수 있다.
서비스B의 인증 서버(300)는 SSO 인증 요청한 클라이언트가 SSO 토큰에 대한 소유권을 가지는지 주관 인증 서버(100)에 SSO 토큰의 소유권 검증을 요청한다(S132). 소유권 검증 요청은 SSO 토큰, 그리고 SSO 토큰을 전송한 클라이언트 정보를 포함할 수 있다.
주관 인증 서버(100)는 발급한 SSO 토큰에 매핑된 클라이언트 정보를 기초로, 소유권 검증 요청에 포함된 SSO 토큰의 소유권 검증하고, 소유권 검증 성공인 경우, 서비스B를 SSO 토큰이 발급된 계정의 공용 세션에 추가한다(S134).
주관 인증 서버(100)는 SSO 토큰의 소유권 검증 결과를 서비스B의 인증 서버(300)로 응답한다(S136). SSO 토큰을 전송한 클라이언트가 소유자로 검증된 경우, SSO 토큰의 소유권 검증 결과는 소유권 검증 성공과 함께, 공용 세션 키를 포함할 수 있다. SSO 토큰을 전송한 클라이언트가 소유자가 아닌 경우, SSO 토큰의 소유권 검증 결과는 소유권 검증 실패를 포함한다.
서비스B의 인증 서버(300)는 사용자 단말(40)의 브라우저(클라이언트)를 위한 공용 세션 키를 설정한다(S138). 서비스B의 인증 서버(300)는 주관 인증 서버(100)로부터 공용 세션 키를 얻을 수 있다. 한편, SSO 토큰에 공용 세션 키가 포함되는 경우, 서비스B의 인증 서버(300)는 SSO 토큰의 소유권 검증 결과가 성공인 경우, SSO 토큰에 포함된 세션 키를 설정할 수 있다.
서비스B의 인증 서버(300)는 사용자 단말(40)의 브라우저에 서비스B 인증 쿠키를 생성한다(S139). 서비스B 인증 쿠키는 서비스B의 인증 서버(300)가 고유한 방식으로 생성한다.
서비스B의 인증 서버(300)와 마찬가지로, 서비스A의 인증 서버(200)는 주관 인증 서버(100)에 SSO 토큰의 소유권 검증을 요청한다(S142).
주관 인증 서버(100)는 발급한 SSO 토큰들에 매핑된 클라이언트 정보들을 기초로, 소유권 검증 요청에 포함된 SSO 토큰의 소유권 검증하고, 소유권 검증 성공인 경우, 서비스A를 SSO 토큰이 발급된 계정의 공용 세션에 추가한다(S144).
주관 인증 서버(100)는 소유권 검증 성공과 공용 세션 키를 포함하는 소유권 검증 결과를 서비스A의 인증 서버(200)로 응답한다(S146).
서비스A의 인증 서버(200)는 사용자 단말(40)의 브라우저(클라이언트)를 위한 글로벌 세션 키를 설정(S148)하고, 사용자 단말(40)의 브라우저에 서비스A 인증 쿠키를 생성한다(S149). 서비스A 인증 쿠키는 서비스A의 인증 서버(200)가 고유한 방식으로 생성한다.
사용자 단말(40)의 브라우저는 타겟 페이지로 이동하거나, 서비스A 인증 쿠키와 서비스B 인증 쿠키를 이용하여 서비스A와 서비스B의 페이지로 이동할 수 있다. 즉, 사용자는 서비스A와 서비스B의 페이지에서 추가적인 로그인 절차를 거칠 필요 없이, 해당 서비스를 이용할 수 있다.
이와 같이, 단일 인증 시스템은 서비스A의 인증 서버(200)와 서비스B의 인증 서버(300)가 개별적으로 존재하더라도, 인증 서버간의 연동을 통해 인증 체계를 통합하고 단일 인증할 수 있다. 특히, 각 인증 서버가 인증 쿠키를 고유의 방식으로 브라우저에 설정하도록 함으로써, 각 인증 서버가 이미 존재하는 인증 체계를 유지하면서도 단일 인증할 수 있다. 이러한 방법에 따라 로그인 시점에 계정에 연결된 서비스 사이트들이 인증 쿠키를 발급할 수 있다. Javascript를 사용한 비동기 방식이 사용될 수 있으나, 비동기 단일 인증은 다양한 기술로 구현될 수 있다.
한편, 동기적 단일 인증 로그인도 가능하다. 주관 인증 서버(100)는 로그인 계정에 연결된 서비스A 및 서비스B의 상태를 체크해서, 단일 인증 처리가 가능한 서비스들만을 SSO 서비스 리스트로 생성한다. 주관 인증 서버(100)는 계정에 연결된 서비스들 중에서 서비스A와 서비스B를 SSO 서비스 리스트로 생성하고, SSO 서비스 리스트와 SSO 토큰을 사용자 단말(40)의 브라우저로 전달한다. SSO 토큰은 로그인 세션 키(공용 세션 키)를 포함할 수 있고, SSO 서비스 리스트에 포함된 서비스 순서대로 해당 서비스의 인증 서버로 전달된다. SSO 토큰은 해당 서비스의 인증 쿠키 발급 후, SSO 서비스 리스트에 포함된 서비스들의 인증이 완료될 때까지, 다음 서비스로 순차 이동할 수 있다.
도 3은 한 실시예에 따른 단일 인증 로그아웃 흐름도이다.
도 3을 참고하면, 사용자 단말(40)의 브라우저가 도 2의 단일 인증 로그인한 이후, 주관 서비스 서버(130)로 로그 아웃 요청한다(S210). 사용자 단말(40)의 브라우저는 사용자로부터 로그인 세션에 대한 로그아웃 동작을 입력받거나, 지정된 로그아웃 상황이 되면, 주관 서비스 서버(130)에서 제공하는 로그아웃 페이지로 진입할 수 있다.
주관 서비스 서버(130)는 주관 인증 서버(100)에게 클라이언트의 로그아웃 요청에 대한 인증을 요청한다(S212).
주관 인증 서버(100)는 로그아웃 요청에 포함된 클라이언트 정보를 기초로 로그아웃 요청을 인증하고, 인증 결과를 주관 서비스 서버(130)로 전달한다(S214). 인증 성공인 경우, 인증 결과는 인증 성공 및 공용 세션에 추가된 SSO 서비스 리스트(서비스 API url 주소 또는 서비스 심볼 스트링)를 포함할 수 있다. 공용 세션에 추가된 SSO 서비스 리스트는 SSO 토큰을 기초로 사용자 단말(40)의 브라우저에 대해 공용 세션 생성한 서비스들을 포함한다. 인증 결과에 인증 실패가 포함된 경우, 주관 서비스 서버(130)는 사용자 단말(40)의 브라우저로 로그아웃 실패 페이지를 제공한다.
인증 성공인 경우, 주관 서비스 서버(130)는 사용자 단말(40)의 브라우저로 로그아웃 페이지를 제공하고, 공용 세션에 추가된 SSO 서비스 리스트를 전달한다(S216).
사용자 단말(40)의 브라우저는 공용 세션에 추가된 SSO 서비스 리스트를 기초로 해당 서비스의 인증 서버로 로그아웃 요청한다(S220, S230). 로그아웃 요청은 비동기적으로 진행된다.
서비스A의 인증 서버(200)는 로그아웃 요청에 대해 로그아웃 처리하고 사용자 단말(40)의 브라우저로 로그아웃 응답한다(S222). 서비스A의 인증 서버(200)는 사용자 단말(40)의 브라우저에 발급한 서비스A 인증 쿠키를 삭제할 수 있다. 서비스B의 인증 서버(300)는 사용자 단말(40)의 브라우저에 생성한 세션을 삭제할 수 있다. 서비스B의 인증 서버(300)는 별도의 로그아웃 처리 절차가 필요하지 않은 경우, 서비스B 인증 쿠키만 삭제할 수 있다.
서비스B의 인증 서버(300)는 로그아웃 요청에 대해 로그아웃 처리하고 사용자 단말(40)의 브라우저로 로그아웃 응답한다(S232). 서비스B의 인증 서버(300)는 사용자 단말(40)의 브라우저에 발급한 서비스B 인증 쿠키를 삭제한다. 서비스B의 인증 서버(300)는 사용자 단말(40)의 브라우저에 생성한 세션을 삭제할 수 있다. 서비스B의 인증 서버(300)는 별도의 로그아웃 처리 절차가 필요하지 않은 경우, 서비스B 인증 쿠키만 삭제할 수 있다.
단일 로그아웃 절차를 완료한 사용자 단말(40)의 브라우저는 타겟 페이지로 이동한다.
다른 실시예에 따르면, 리디렉션(redirection)으로 단일 인증 로그아웃할 수 있다. 로그아웃 요청에 대한 인증 성공 시, 사용자 단말(40)의 브라우저는 공용 세션에 추가된 SSO 서비스 리스트를 반환받는다. SSO 서비스 리스트가 return url에 묶여서 전달되면, SSO 서비스 리스트에 남아있는 서비스가 없을 때까지, 로그아웃 요청이 각 서비스의 인증 서버로 이동(redirect)하면서, 로그아웃 절차가 반복될 수 있다.
또 다른 실시예에 따르면, 공용 세션 삭제 방식으로 단일 인증 로그아웃할 수 있다. 예를 들면, 주관 인증 서버(100)는 로그아웃 요청에 포함된 클라이언트 정보를 기초로 로그아웃 요청을 인증하고, 로그아웃 요청에 대한 인증 성공 시, 데이터베이스(150)에서 로그아웃 대상의 정보(예를 들면, 공용 세션 정보)를 삭제(파기)할 수 있다. 그리고, 주관 인증 서버(100)는 로그아웃 인증 성공인 경우, 인증 결과를 주관 서비스 서버(130)로 전달하고, 주관 서비스 서버(130)가 사용자 단말(40)의 브라우저로 로그아웃 성공 페이지를 제공할 수 있다.
이와 같이, 단일 인증 시스템은 사용자 단말(40)의 브라우저가 단일 인증 로그인한 이후, 로그인 계정에 대한 로그아웃 요청하면, 단일 인증으로 로그인된 멀티 도메인 서비스들까지 한꺼번에 로그아웃할 수 있다. 즉, 단일 인증 시스템은 로그인된 클라이언트의 로그인 세션을 여러 도메인들의 서비스들이 추가되는 공용 세션으로 관리하기 때문에, 로그인 계정에 대해 생성된 로그인 세션이 종료하면, 로그인 세션에 추가된 서비스들까지 한꺼번에 종료(expire)시킬 수 있다.
도 4와 도 5 각각은 한 실시예에 따른 느린(lazy) 단일 인증 로그인의 흐름도이다.
도 4를 참고하면, 로그인 계정(예를 들면, 카카오 계정)에 연결된 적어도 하나의 서비스가 있더라도, 어느 서비스(예를 들면, 서비스B)는 도 2와 같이, 계정 인증 성공 시 바로 SSO 인증을 진행하지 않을 수 있다. 즉, 로그인 계정에 대한 인증 성공 후, 특정 서비스에 대해 선택적으로 진행되는 단일 인증 로그인을 느린(lazy) 단일 인증 로그인이라고 부른다.
예를 들면, 서비스B의 인증 서버(300)는 사용자가 로그인이 필요한 특정 이벤트(예를 들면, 댓글달기, 자주 듣는 음악 등록 등)를 요청하는 경우에 로그인하도록 설정되거나, 사용자가 명시적 로그인 시도를 하는 경우에 로그인하도록 설정된 경우, 서비스B는 연결된 주 계정의 인증 성공 시 바로 SSO 인증할 필요 없이, 느린 단일 인증 로그인하도록 설정될 수 있다. 또는, 서비스B의 인증 서버(300)는 주기적으로 재인증하도록 설정된 경우, 서비스B는 연결된 주 계정의 로그인 세션이 유지된 상태에서, 느린 단일 인증 로그인으로 SSO 재인증할 수 있다.
사용자 단말(40)의 브라우저가 계정에 대한 로그인 인증 후 발급된 계정 로그인 토큰을 저장하고 있다고 가정하고, 서비스B가 느린(lazy) 단일 인증 로그인한다고 가정한다. 여기서, 계정 로그인 토큰은 도 2의 단계(S110~S116)에 의해 사용자 단말(40)의 브라우저에 쿠키로 설정된다.
사용자 단말(40)의 브라우저는 서비스B의 서비스 서버(330)로 로그인 요청하거나, 로그인이 필요한 특정 이벤트를 요청한다(S310). 로그인 요청은 명시적인 로그인 시도 동작으로서, 사용자 단말(40)의 브라우저가 서비스B의 서비스 서버(330)가 제공하는 웹페이지에서 사용자에 의한 로그인 요청을 입력받거나, 사용자 단말(40)의 브라우저가 서비스B의 서비스 서버(330)가 제공하는 웹페이지로 이동한 경우일 수 있다. 로그인이 필요한 특정 이벤트는 예를 들면, 댓글달기, 자주 듣는 음악 등록 등일 수 있다.
서비스B의 서비스 서버(330)는 사용자 단말(40)의 브라우저의 요청을 기초로 로그인 필요 여부를 판단하는데, 요청에 자신이 발급한 유효한 서비스B 인증 쿠키가 없으므로, 로그인 필요 응답을 한다(S312). 서비스B의 서비스 서버(330)는 인증 쿠키가 없거나 유효하지 않은(invalid) 인증 쿠키인 경우, 로그인이 필요하다는 응답을 반환한다.
로그인 필요 응답을 수신한 사용자 단말(40)의 브라우저는 주관 서비스 서버(130)에 느린(lazy) 단일 인증(SSO) 시작 요청을 한다(S320). 느린 SSO 시작 요청은 로그인 토큰, 그리고 클라이언트 정보를 포함할 수 있다. 이때, 사용자 단말(40)의 브라우저는 특정 포맷(예를 들면, JSONP)을 이용하여 쿠키로 설정된 로그인 토큰을 주관 서비스 서버(130)로 전달함으로써, 느린 SSO 시작 요청할 수 있다. 주관 서비스 서버(130)가 로그인 확인 인터페이스(API)를 제공하는 경우, 사용자 단말(40)의 브라우저는 특정 포맷(예를 들면, JSONP)을 이용하여 주관 서비스 서버(130)에 로그인 확인 API를 호출할 수 있다.
주관 서비스 서버(130)는 주관 인증 서버(100)에게 느린 SSO 시작 요청한 서비스B를 위한 SSO 토큰 발급을 요청한다(S322). 이때, 주관 서비스 서버(130)는 SSO 토큰 발급 요청 전에, 주관 인증 서버(100)에게 느린 SSO 시작 요청에 포함된 정보(예를 들면, 로그인 토큰, 서비스B, 클라이언트 정보 등)의 검증을 요청하고, 검증 성공 시, 주관 인증 서버(100)에게 서비스B를 위한 SSO 토큰 발급을 요청할 수 있다.
주관 인증 서버(100)는 서비스B의 단일 인증을 위해 발급된 SSO 토큰을 주관 서비스 서버(130)로 전달한다(S324). 주관 인증 서버(100)는 SSO 토큰을 신규 발급하는 경우, 클라이언트 정보에 SSO 토큰을 매핑해 둔다. 이미 주 계정으로 로그인된 사용자 단말(40)인 경우, 사용자 단말(40)의 브라우저로 SSO 토큰이 반환된다. 만약, 주 계정으로 로그인된 사용자 단말(40)이 아니라면, 주 계정으로 로그인이 필요하므로, 도 2의 로그인 절차로 이동한다.
주관 서비스 서버(130)는 느린 SSO 시작 요청의 응답으로, SSO 토큰을 사용자 단말(40)의 브라우저에 전달한다(S326).
사용자 단말(40)의 브라우저는 서비스B의 인증 서버(300)로 SSO 토큰을 포함한SSO 인증 요청을 한다(S330).
서비스B의 인증 서버(300)는 SSO 인증 요청한 클라이언트가 SSO 토큰에 대한 소유권을 가지는지 주관 인증 서버(100)에 SSO 토큰의 소유권 검증을 요청한다(S332). 소유권 검증 요청은 SSO 토큰, 그리고 SSO 토큰을 전송한 클라이언트 정보를 포함할 수 있다.
주관 인증 서버(100)는 발급한 SSO 토큰에 매핑된 클라이언트 정보를 기초로, 소유권 검증 요청에 포함된 SSO 토큰의 소유권 검증하고, 소유권 검증 성공인 경우, 서비스B를 SSO 토큰이 발급된 계정의 공용 세션에 추가한다(S334).
주관 인증 서버(100)는 SSO 토큰의 소유권 검증 결과를 서비스B의 인증 서버(300)로 응답한다(S336). SSO 토큰의 소유권 검증 결과는 소유권 검증 성공과 함께, 공용 세션 키를 포함할 수 있다.
서비스B의 인증 서버(300)는 사용자 단말(40)의 브라우저를 위한 공용 세션 키를 설정한다(S338).
서비스B의 인증 서버(300)는 사용자 단말(40)의 브라우저에 서비스B 인증 쿠키를 생성한다(S339).
이후, 사용자 단말(40)의 브라우저는 서비스B 인증 쿠키를 통해 서비스B의 서비스 서버(330)의 각종 로그인 서비스들을 접근할 수 있다.
한편, 도 4의 단계(S320)은 사용자 단말(40)의 브라우저가 쿠키로 설정된 계정 로그인 토큰을 특정 포맷(예를 들면, JSONP)을 이용하여 주관 서비스 서버(130)로 전달함으로써, 느린 SSO 시작 요청하는데, 일부 브라우저는 특정 포맷(예를 들면, JSONP)을 호출 시, 쿠키를 전달하지 않도록 기본 설정되어 있을 수 있다. 이 경우, 다음 도 5와 같이, 리디렉션(redirection) 방식으로 로그인 토큰이 전달될 수 있다.
도 5를 참고하면, 서비스B의 서비스 서버(330)로부터 로그인 필요 응답을 수신하는 도 4의 단계(S312) 이후, 사용자 단말(40)의 브라우저는 서비스B의 페이지에서 주관 서비스 서버(130)의 단일 인증 로그인 페이지로 이동(redirect)한 후, 느린(lazy) 단일 인증(SSO) 시작 요청을 한다(S410). 사용자 단말(40)의 브라우저는 리디렉션 방식으로 주관 서비스 서버(130)의 단일 인증 로그인 페이지(sso login url)로 이동한다. 리디렉션 방식에 의한 느린 SSO 시작 요청은, 도 4의 특정 포맷(예를 들면, JSONP)을 이용한 호출 방식에 의한 느린 SSO 시작 요청의 실패 후, 진행될 수 있다. 또는 느린 SSO 시작 요청은 특정 포맷(예를 들면, JSONP) 호출 방식과 리디렉션 방식 중에서 선택될 수 있다.
주관 서비스 서버(130)는 주관 인증 서버(100)에게 느린 SSO 시작 요청한 서비스B를 위한 SSO 토큰 발급을 요청한다(S412). 이때, 주관 서비스 서버(130)는 주관 인증 서버(100)에게 계정 로그인 토큰의 검증을 요청하고, 계정 로그인 토큰의 검증 성공 시, 주관 인증 서버(100)에게 서비스B를 위한 SSO 토큰 발급을 요청할 수 있다.
주관 인증 서버(100)는 서비스B의 단일 인증을 위해 발급된 SSO 토큰을 주관 서비스 서버(130)로 전달한다(S414). 주관 인증 서버(100)는 SSO 토큰을 신규 발급하는 경우, SSO 토큰에 클라이언트 정보를 매핑해 둔다.
주관 서비스 서버(130)는 SSO 토큰을 담아 사용자 단말(40)의 브라우저를 서비스B의 페이지로 이동(redirect)시킨다(S416).
사용자 단말(40)의 브라우저는 서비스B의 인증 서버(300)로 SSO 토큰을 포함한SSO 인증 요청을 한다(S420).
서비스B의 인증 서버(300)는 SSO 인증 요청한 클라이언트가 SSO 토큰에 대한 소유권을 가지는지 주관 인증 서버(100)에 SSO 토큰의 소유권 검증을 요청한다(S422). 소유권 검증 요청은 SSO 토큰, 그리고 SSO 토큰을 전송한 클라이언트 정보를 포함할 수 있다.
주관 인증 서버(100)는 발급한 SSO 토큰에 매핑된 클라이언트 정보를 기초로, 소유권 검증 요청에 포함된 SSO 토큰의 소유권 검증하고, 소유권 검증 성공인 경우, 서비스B를 SSO 토큰이 발급된 계정의 공용 세션에 추가한다(S424).
주관 인증 서버(100)는 SSO 토큰의 소유권 검증 결과를 서비스B의 인증 서버(300)로 응답한다(S426). SSO 토큰의 소유권 검증 결과는 소유권 검증 성공과 함께, 공용 세션 키를 포함할 수 있다.
서비스B의 인증 서버(300)는 사용자 단말(40)의 브라우저를 위한 공용 세션 키를 설정한다(S428).
서비스B의 인증 서버(300)는 사용자 단말(40)의 브라우저에 서비스B 인증 쿠키를 생성한다(S429).
이후, 사용자 단말(40)의 브라우저는 서비스B 인증 쿠키를 통해 서비스B의 서비스 서버(330)의 각종 로그인 필요 서비스들에 접근할 수 있다.
이와 같이, 도 4와 도 5를 참고하면, 단일 인증 시스템은 주 계정으로의 로그인 즉시 적용되는 active SSO와 주 계정으로의 로그인 후 개별 서비스에 접속하기 위해 적용되는 passive SSO를 구현할 수 있다. 주 계정으로의 로그인 시, 주 계정에 연결된 일부 서비스가 장애 상태라고 하더라도, 느린 단일 인증 절차를 통해 단일 인증이 정상적으로 이루어질 수 있다. 특히, 주관 인증 서버(100)는 느린 단일 인증 절차를 통해, 로그인 세션에 단일 인증된 서비스들을 저장하여 로그인 이후에도 단일 인증에 의한 세션을 통합 관리할 수 있고, 개별 서비스의 인증 만료/미인증시 인증세션 복구 프로세스를 제공할 수 있다.
이상에서 설명한 본 발명의 실시예는 장치 및 방법을 통해서만 구현이 되는 것은 아니며, 본 발명의 실시예의 구성에 대응하는 기능을 실현하는 프로그램 또는 그 프로그램이 기록된 기록 매체를 통해 구현될 수도 있다.
이상에서 본 발명의 실시예에 대하여 상세하게 설명하였지만 본 발명의 권리범위는 이에 한정되는 것은 아니고 다음의 청구범위에서 정의하고 있는 본 발명의 기본 개념을 이용한 당업자의 여러 변형 및 개량 형태 또한 본 발명의 권리범위에 속하는 것이다.

Claims (14)

  1. 멀티 도메인 서비스들의 단일 인증을 주관하는 주관 인증 서버가, 상기 멀티 도메인 서비스들의 인증 서버들과 연동하여 단일 인증하는 방법으로서,
    클라이언트의 로그인 요청에 포함된 주 계정에 대해 인증하고, 인증 성공한 상기 클라이언트로 로그인 토큰을 발급하는 단계,
    상기 멀티 도메인 서비스들 중에서, 상기 로그인 토큰이 발급된 상기 주 계정에 연결된 서비스들을 제1 서비스 리스트로 생성하고, 상기 제1 서비스 리스트와 함께 단일 인증 토큰을 상기 클라이언트에게 발급하는 단계,
    상기 제1 서비스 리스트에 포함된 임의 서비스의 인증 서버로부터, 단일 인증 토큰 검증 요청을 수신하면, 상기 단일 인증 토큰 검증 요청에 포함된 토큰이 상기 클라이언트로 발급한 상기 단일 인증 토큰인지 검증하는 단계, 그리고
    검증 성공한 경우, 상기 임의 서비스를 상기 주 계정의 세션에 추가하고, 상기 세션의 키를 상기 임의 서비스의 인증 서버로 전달하는 단계를 포함하고,
    상기 클라이언트는 사용자 단말의 브라우저이고,
    상기 임의 서비스의 인증 서버는 상기 클라이언트를 위한 상기 세션의 키를 설정하고, 상기 클라이언트에 상기 임의 서비스를 이용할 수 있는 인증 쿠키를 생성하는, 단일 인증 방법.
  2. 제1항에서,
    상기 단일 인증 토큰인지 검증하는 단계는
    상기 제1 서비스 리스트에 포함된 각 서비스의 인증 서버로부터, 비동기적으로 상기 단일 인증 토큰 검증 요청을 수신하는, 단일 인증 방법.
  3. 제1항에서,
    상기 클라이언트의 로그아웃 요청을 전달받는 단계, 그리고
    상기 주 계정의 로그인 시 생성된 상기 세션에 추가된 서비스들을 제2 서비스 리스트로 생성하고, 상기 제2 서비스 리스트를 상기 클라이언트에게 전달하는 단계를 더 포함하며,
    상기 클라이언트는 상기 제2 서비스 리스트에 포함된 각 서비스의 인증 서버로 해당 서비스의 로그아웃을 요청하는, 단일 인증 방법.
  4. 제1항에서,
    상기 클라이언트의 로그아웃 요청을 전달받는 단계, 그리고
    상기 주 계정의 로그인 시 생성된 상기 세션을 삭제하여 단일 인증 로그아웃하는 단계를 더 포함하며,
    상기 세션은 상기 세션의 키를 받은 서비스들이 추가된 공용 세션인, 단일 인증 방법.
  5. 제1항에서,
    상기 클라이언트에 상기 로그인 토큰을 발급한 이후, 상기 클라이언트로부터 특정 서비스에 대한 느린(lazy) 단일 인증 시작 요청을 수신하는 단계, 그리고
    상기 단일 인증 토큰 또는 신규 단일 인증 토큰을 상기 클라이언트에게 발급하는 단계를 더 포함하고,
    상기 클라이언트는
    상기 특정 서비스의 서버에 접속한 상태에서, 상기 주관 인증 서버에 관련된 서비스 서버에서 제공하는 로그인 확인 인터페이스를 호출하여 상기 느린 단일 인증 시작을 요청하거나,
    상기 특정 서비스의 서버에 접속한 상태에서, 상기 주관 인증 서버에 관련된 서비스 서버에서 제공하는 단일 인증 로그인 페이지로 이동(redirect)하여 호출하여 상기 느린 단일 인증 시작을 요청하는, 단일 인증 방법.
  6. 멀티 도메인 서비스들 중 특정 서비스의 인증 서버가, 상기 멀티 도메인 서비스들의 단일 인증을 주관하는 주관 인증 서버와 연동하여, 단일 인증하는 방법으로서,
    클라이언트로부터 단일 인증 토큰을 포함하는 단일 인증 요청을 수신하는 단계,
    상기 주관 인증 서버로 상기 클라이언트가 상기 단일 인증 토큰에 대한 소유권을 가지는 지 소유권 검증을 요청하는 단계,
    상기 주관 인증 서버로부터, 소유권 검증 결과를 수신하고, 상기 소유권 검증 결과가 성공인 경우, 상기 클라이언트를 위해 상기 소유권 검증 결과에 포함된 세션 키를 설정하는 단계, 그리고
    상기 클라이언트에 상기 특정 서비스를 이용할 수 있는 인증 쿠키를 생성하는 단계를 포함하며,
    상기 클라이언트는 사용자 단말의 브라우저이고,
    상기 특정 서비스의 계정은 주 계정에 연결되어 있으며,
    상기 단일 인증 토큰은 상기 주관 인증 서버가 상기 클라이언트에서 요청한 상기 주 계정에 대한 로그인 성공 후, 상기 클라이언트에게 발급한 토큰이며,
    상기 세션 키는 상기 주 계정의 로그인 시 생성된 세션의 키인, 단일 인증 방법.
  7. 제6항에서,
    상기 클라이언트는 iFrame을 이용하여 상기 특정 서비스의 인증 서버로 상기 단일 인증 요청하는, 단일 인증 방법.
  8. 제6항에서,
    상기 인증 쿠키를 생성한 이후, 상기 클라이언트로부터 로그아웃 요청을 수신하는 단계, 그리고
    상기 클라이언트에 대한 로그아웃 처리하고, 상기 클라이언트로 로그아웃 응답하는 단계를 더 포함하고,
    상기 클라이언트는 상기 주관 인증 서버로 로그아웃 요청하여 수신한 서비스 리스트를 기초로 상기 단일 인증 요청을 전송하는, 단일 인증 방법.
  9. 사용자 단말의 브라우저가 멀티 도메인 서비스들로 단일 인증하는 방법으로서,
    멀티 도메인 서비스들의 단일 인증을 주관하는 주관 서비스 시스템으로, 주 계정에 대한 로그인 요청하고, 상기 주관 서비스 시스템으로부터 상기 주 계정에 대한 로그인 토큰을 발급받는 단계,
    상기 주관 서비스 시스템으로, 상기 로그인 토큰 및 클라이언트 정보를 포함하는 단일 인증 시작 요청을 전송하고, 상기 주관 서비스 시스템으로부터 상기 주 계정에 연결된 서비스들을 포함하는 제1 서비스 리스트와 함께 단일 인증 토큰을 발급받는 단계, 그리고
    상기 제1 서비스 리스트에 포함된 각 서비스의 인증 서버로, 상기 단일 인증 토큰을 포함하는 단일 인증 요청을 전송하고, 해당 서비스의 인증 서버로부터 발급된 해당 서비스의 인증 쿠키를 설정하는 단계
    를 포함하는, 단일 인증 방법.
  10. 제9항에서,
    상기 주관 서비스 시스템으로 로그아웃 요청하고, 상기 주관 서비스 시스템으로부터 상기 주 계정의 로그인 시 생성된 상기 세션에 추가된 서비스들을 포함하는 제2 서비스 리스트를 수신하는 단계, 그리고
    상기 제2 서비스 리스트에 포함된 각 서비스의 인증 서버로 해당 서비스의 로그아웃을 요청하는 단계
    를 더 포함하는 단일 인증 방법.
  11. 제9항에서,
    상기 멀티 도메인 서비스들 중 특정 서비스의 서비스 서버에 접속한 상태에서, 상기 서비스 서버로부터 로그인 필요 응답을 수신하는 단계,
    상기 주관 서비스 시스템으로 상기 특정 서비스에 대한 느린(lazy) 단일 인증 시작을 요청하는 단계,
    상기 주관 서비스 시스템으로부터 상기 단일 인증 토큰 또는 신규 단일 인증 토큰을 발급받는 단계, 그리고
    상기 특정 서비스의 인증 서버로 상기 특정 서비스에 대해 발급받은 토큰을 포함하는 단일 인증 요청을 전송하고, 상기 특정 서비스의 인증 서버로부터 발급된 상기 특정 서비스의 인증 쿠키를 설정하는 단계
    를 더 포함하는, 단일 인증 방법.
  12. 제11항에서,
    상기 느린 단일 인증 시작을 요청하는 단계는
    상기 로그인 토큰을 JSONP로 전달함으로써 상기 느린 단일 인증 시작을 요청하는, 단일 인증 방법.
  13. 제11항에서,
    상기 느린 단일 인증 시작을 요청하는 단계는
    상기 특정 서비스의 서비스 페이지에서 상기 주관 서비스 시스템의 단일 인증 로그인 페이지로 이동(redirect)한 후, 상기 로그인 토큰을 상기 주관 서비스 시스템으로 전달함으로써 상기 느린 단일 인증 시작을 요청하는, 단일 인증 방법.
  14. 제13항에서,
    상기 느린 단일 인증 시작을 요청하는 단계는
    상기 로그인 토큰을 JSONP로 전달할 수 없는 경우, 상기 특정 서비스의 서비스 페이지에서 상기 주관 서비스 시스템의 단일 인증 로그인 페이지로 이동(redirect)한 후, 상기 로그인 토큰을 상기 주관 서비스 시스템으로 전달함으로써 상기 느린 단일 인증 시작을 요청하는, 단일 인증 방법.
KR1020190077914A 2018-06-29 2019-06-28 멀티 도메인 서비스들을 위한 단일 인증 방법 그리고 이를 구현한 시스템 KR102232763B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20180075238 2018-06-29
KR1020180075238 2018-06-29

Publications (2)

Publication Number Publication Date
KR20200002680A true KR20200002680A (ko) 2020-01-08
KR102232763B1 KR102232763B1 (ko) 2021-03-26

Family

ID=69154339

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020190077914A KR102232763B1 (ko) 2018-06-29 2019-06-28 멀티 도메인 서비스들을 위한 단일 인증 방법 그리고 이를 구현한 시스템

Country Status (1)

Country Link
KR (1) KR102232763B1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102146940B1 (ko) * 2020-03-16 2020-08-24 주식회사 스태비 토큰 위변조 검증 방법
CN112487390A (zh) * 2020-11-27 2021-03-12 网宿科技股份有限公司 一种微服务切换方法及系统
CN113312571A (zh) * 2021-05-12 2021-08-27 武汉联影医疗科技有限公司 页面管理方法、装置、计算机设备和存储介质
KR102449740B1 (ko) * 2022-07-01 2022-10-04 주식회사 악어디지털 전자 메일 처리 방법 및 전자 메일 처리 장치

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040053720A (ko) * 2003-01-13 2004-06-24 이창화 복수의 웹서버로의 사용자 인증 처리 방법과 그 시스템
KR20090046407A (ko) * 2007-11-06 2009-05-11 한국전자통신연구원 Ｓｓｏ서비스 방법 및 시스템
KR20100040413A (ko) * 2008-10-10 2010-04-20 주식회사 케이티 오픈아이디를 지원하는 단일 사용승인 아이디 인증 방법
KR20150112131A (ko) * 2014-03-26 2015-10-07 에스케이플래닛 주식회사 웹 서비스 이용시 사용자 인증을 위한 시스템 및 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040053720A (ko) * 2003-01-13 2004-06-24 이창화 복수의 웹서버로의 사용자 인증 처리 방법과 그 시스템
KR20090046407A (ko) * 2007-11-06 2009-05-11 한국전자통신연구원 Ｓｓｏ서비스 방법 및 시스템
KR20100040413A (ko) * 2008-10-10 2010-04-20 주식회사 케이티 오픈아이디를 지원하는 단일 사용승인 아이디 인증 방법
KR20150112131A (ko) * 2014-03-26 2015-10-07 에스케이플래닛 주식회사 웹 서비스 이용시 사용자 인증을 위한 시스템 및 방법

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102146940B1 (ko) * 2020-03-16 2020-08-24 주식회사 스태비 토큰 위변조 검증 방법
CN112487390A (zh) * 2020-11-27 2021-03-12 网宿科技股份有限公司 一种微服务切换方法及系统
CN113312571A (zh) * 2021-05-12 2021-08-27 武汉联影医疗科技有限公司 页面管理方法、装置、计算机设备和存储介质
KR102449740B1 (ko) * 2022-07-01 2022-10-04 주식회사 악어디지털 전자 메일 처리 방법 및 전자 메일 처리 장치

Also Published As

Publication number Publication date
KR102232763B1 (ko) 2021-03-26

Similar Documents

Publication Publication Date Title
US11665146B2 (en) Migrating authenticated content towards content consumer
US7827318B2 (en) User enrollment in an e-community
US7793095B2 (en) Distributed hierarchical identity management
KR102232763B1 (ko) 멀티 도메인 서비스들을 위한 단일 인증 방법 그리고 이를 구현한 시스템
JP4782986B2 (ja) パブリックキー暗号法を用いたインターネット上でのシングルサインオン
US7356694B2 (en) Security session authentication system and method
US10637845B2 (en) Privacy-aware ID gateway
US20080301784A1 (en) Native Use Of Web Service Protocols And Claims In Server Authentication
US20110265155A1 (en) Service provider access
EP2669837B1 (en) Cooperation system, cooperation method threreof, information processing system, and program thereof
CN105556894A (zh) 网络连接自动化
US9971901B2 (en) Content management apparatus and content management method
US20150149530A1 (en) Redirecting Access Requests to an Authorized Server System for a Cloud Service
US9916308B2 (en) Information processing system, document managing server, document managing method, and storage medium
JPWO2009107219A1 (ja) 認証装置，認証方法およびその方法を実装した認証プログラム
CN113411324B (zh) 基于cas与第三方服务器实现登录认证的方法和系统
CN109450890B (zh) 单点登录的方法和装置
JP2005346570A (ja) 認証システム、認証方法及びコンピュータプログラム
CN110753045A (zh) 不同域之间单点登录的方法
CA2431311C (en) Distributed hierarchical identity management
JP2000106552A (ja) 認証方法
CN101969426A (zh) 分布式用户认证系统及其方法
US20220321345A1 (en) Secure exchange of session tokens for claims-based tokens in an extensible system
CA2458257A1 (en) Distributed hierarchical identity management
US10623396B2 (en) System and method for controlling system

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