단일 로그인의 세 가지 실현 방식

앞말
B/S 시스템에서 로그인 기능은 일반적으로 쿠키를 기반으로 이루어집니다.사용자가 로그인에 성공하면 일반적으로 로그인 상태를 Session에 기록하거나 사용자에게 Token을 서명합니다. 어떤 방식이든 클라이언트에 정보 (Session ID 또는 Token) 를 저장하고 클라이언트에게 이후의 모든 요청에 그것을 휴대하도록 요구합니다.이러한 상황에서 쿠키를 사용하는 것이 가장 편리하기 때문에 우리는 일반적으로 Session의 ID나 Token을 쿠키에 저장하고 서버가 요청을 받은 후에 쿠키의 정보를 검증함으로써 사용자의 로그인 여부를 판단한다.
단일 로그인(Single Sign On, SSO)은 동일한 계정 플랫폼 아래의 여러 응용 시스템에서 사용자가 한 번만 로그인하면 서로 신뢰하는 모든 응용 시스템에 접근할 수 있는 것을 말한다.예를 들어 바이두 카페와 바이두 지도는 바이두 회사 산하의 두 가지 다른 응용 시스템이다. 만약에 사용자가 바이두 카페에 로그인한 후에 그가 바이두 지도를 방문할 때 다시 로그인할 필요가 없다면 바이두 카페와 바이두 지도 사이에 단일 등록이 이루어졌다는 것을 설명한다.
단일 로그인의 본질은 여러 응용 시스템에서 로그인 상태를 공유하는 것이다.사용자의 로그인 상태가 Session에 기록되어 있다면 공유 로그인 상태를 실현하려면 Session을 공유해야 한다. 예를 들어 Session을 Redis에 서열화하여 여러 응용 시스템이 같은 Redis를 공유하고 Redis를 직접 읽어서 Session을 얻을 수 있다.물론 이것만으로는 부족하다. 서로 다른 응용 시스템이 서로 다른 도메인 이름을 가지고 있기 때문이다. 비록 Session이 공유되었지만 Session ID는 브라우저 쿠키에 저장되기 때문에 역할 영역의 제한이 존재하기 때문에 도메인 이름을 뛰어넘어 전달할 수 없다. 즉, 사용자가 app1.com에서 로그인하면 Session ID는 브라우저에서만 app1에 액세스합니다.com 시 요청 헤더에서 자동으로 휴대되며, 브라우저가 app2에 접근할 때입니다.com에서는 Session ID를 가져오지 않습니다.단일 로그인을 실현하는 관건은 Session ID(또는 Token)를 여러 도메인에서 공유하는 방법에 있습니다.
구현 방법 1: 상위 도메인 쿠키
구체적으로 실현되기 전에 쿠키의 역할에 대해 이야기해 봅시다.
쿠키의 역할 영역은domain 속성과path 속성이 공동으로 결정합니다.도메인 속성의 유효한 값은 현재 도메인 또는 상위 도메인의 도메인 이름/IP 주소입니다. Tomcat에서 도메인 속성은 기본적으로 현재 도메인의 도메인 이름/IP 주소입니다.path 속성의 유효한 값은 "/"로 시작하는 경로입니다. Tomcat에서 path 속성은 기본적으로 현재 웹 응용 프로그램의 상하문 경로입니다.
쿠키의domain 속성을 현재 도메인의 부모 도메인으로 설정하면 부모 도메인 쿠키라고 간주합니다.쿠키의 특징은 부역의 쿠키가 자역에 공유된다는 것이다. 다시 말하면 자역은 자동으로 부역의 쿠키를 계승한다.
쿠키의 이러한 특징을 이용하여 Session ID(또는 Token)를 상위 도메인에 저장하면 되지 않을까 하는 생각은 어렵지 않습니다.맞아요. 쿠키의domain 속성을 부역의 도메인 이름 (주 도메인 이름) 으로 설정하고 쿠키의 path 속성을 루트 경로로 설정하면 모든 하위 도메인 응용 프로그램이 이 쿠키에 접근할 수 있습니다.그러나 이것은 응용 시스템의 도메인 이름을 하나의 공통된 메인 도메인 이름 아래에 세워야 한다. 예를 들어tieba.baidu.com과 맵.baidu.com, 그것들은 모두baidu에 세워졌다.com이라는 메인 도메인 이름 아래에서 이러한 방식으로 단일 로그인을 할 수 있습니다.
요약: 이 실현 방식은 비교적 간단하지만 주 도메인 이름은 지원되지 않습니다.
구현 방식 2: 인증 센터
우리는 인증 센터를 배치할 수 있다. 인증 센터는 로그인 요청을 전문적으로 처리하는 독립된 웹 서비스이다.
사용자는 인증 센터에서 통일적으로 로그인을 하고 로그인에 성공하면 인증 센터에서 사용자의 로그인 상태를 기록하고 Token을 쿠키에 기록합니다.(이 쿠키는 인증 센터이고 응용 시스템은 접근할 수 없음을 주의하십시오.)
응용 시스템은 현재 요청에 Token이 있는지 확인합니다. 만약 그렇지 않다면 사용자가 현재 시스템에 로그인하지 않았다는 것을 설명하고 페이지를 인증 센터로 이동합니다.이 조작은 인증센터의 쿠키를 자동으로 가져갈 수 있기 때문에 인증센터는 쿠키에 따라 사용자가 로그인했는지 알 수 있다.인증센터에서 사용자가 로그인하지 않은 것을 발견하면 로그인 페이지로 돌아가 사용자가 로그인할 때까지 기다립니다. 사용자가 로그인한 것을 발견하면 다시 로그인하지 않고 대상 URL로 되돌아갑니다. 그리고 점프하기 전에 Token을 생성하여 대상 URL의 뒷면에 연결하여 대상 응용 시스템에 전송합니다.
응용 시스템이 Token을 받은 후에 인증 센터에 Token의 합법성을 확인하고 사용자의 위조를 방지해야 한다.오류가 없음을 확인한 후 응용 프로그램은 사용자의 로그인 상태를 기록하고 Token을 쿠키에 쓴 다음 이번 접근을 실행합니다.(이 쿠키는 현재 응용 프로그램입니다. 다른 응용 프로그램은 접근할 수 없습니다.)사용자가 현재 응용 시스템에 다시 접근할 때 자동으로 이 Token을 가지고 응용 시스템은 Token이 사용자가 로그인한 것을 검증하기 때문에 인증 센터에 아무 일도 없을 것이다.
여기에서 두 가지 인증 센터의 개원 실현을 소개한다.

Apereo CAS는 기업급 단일 로그인 시스템으로 CAS의 뜻은'Central Authentication Service'입니다. 예일대 실험실의 프로젝트였다가 JASIG 조직에 양도되었고 프로젝트는 JASIG CAS로 이름이 바뀌었고 그 후에 이 조직이 Apereo 기금회에 합병되면서 프로젝트도 Apereo CAS로 이름이 바뀌었습니다.

XXL-SSO는 간단한 단일 로그인 시스템으로 대중 평가 엔지니어 허설리가 개인적으로 개발했고 코드가 비교적 간단하며 안전 제어를 하지 않았기 때문에 프로젝트에 직접 응용하는 것을 추천하지 않는다. 여기에 열거한 것은 참고만 제공한다.

요약: 이러한 실현 방식은 상대적으로 복잡하고 크로스 도메인을 지원하며 확장성이 좋으며 단일 로그인의 표준 방법이다.
구현 방법 3: LocalStorage 도메인 간
앞에서 단일 로그인을 실현하는 관건은 세션 ID(또는 Token)를 여러 도메인에서 공유하는 방법에 있다고 말했습니다.
부모 도메인 쿠키는 확실히 좋은 해결 방안이지만 크로스 도메인은 지원하지 않습니다.그렇다면 쿠키를 크로스오버할 수 있는 기음 기교가 있을까?
안타깝게도 브라우저는 쿠키에 대한 크로스 도메인 제한이 갈수록 엄격해지고 있습니다.Chrome 브라우저는 쿠키에 SameSite 속성을 추가했습니다. 이 속성은 모든 크로스 도메인 요청의 쿠키 전달(하이퍼링크 제외)을 거의 금지하고 HTTPs 프로토콜을 사용할 때만 AJAX 크로스 도메인 요청에서 서버가 전송하는 쿠키를 받아들일 수 있습니다.
단, 앞뒤가 분리된 상황에서 쿠키를 전혀 사용하지 않을 수 있으며, Session ID (또는 Token) 를 브라우저의 Local Storage에 저장하여 앞뒤가 백엔드에 요청할 때마다 Local Storage의 데이터를 서비스 측에 주동적으로 전달할 수 있습니다.이것들은 모두 프런트엔드에 의해 제어된다. 백엔드가 해야 할 일은 단지 사용자가 로그인한 후에 Session ID(또는 Token)를 응답체에 놓고 프런트엔드에 전달하는 것이다.
이런 장면에서 단일 로그인은 완전히 전단에서 실현할 수 있다.프런트엔드에서 Session ID (또는 Token) 를 받으면 Local Storage 에 쓰는 것 외에도 여러 도메인 내의 Local Storage 에 특수한 방법으로 쓸 수 있습니다.
주요 코드는 다음과 같습니다.


//   token
var token = result.data.token;

//  iframe， iframe HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
//  postMessage() token iframe
setTimeout(function () {
 iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
 iframe.remove();
}, 6000);

//  iframe HTML ， ， token localStorage
window.addEventListener('message', function (event) {
 localStorage.setItem('token', event.data)
}, false);

프런트엔드는 iframe +postMessage () 방식을 통해 같은 Token을 여러 도메인 아래의 Local Storage에 기록합니다. 프런트엔드는 백엔드에 요청을 보내기 전에 Local Storage에서 Token을 읽고 요청에 휴대합니다. 이렇게 하면 같은 Token이 여러 도메인에 공유됩니다.
요약: 이 실현 방식은 완전히 전단에서 제어되고 백엔드 참여가 거의 필요하지 않으며 크로스 필드도 지원한다.
보충: 도메인 이름 계층 지정
전문적인 측면에서 (컴퓨터 네트워크의 정의에 따라).com、.cn은 1급 도메인 이름입니다.com.cn、baidu.com은 2급 도메인 이름,sina입니다.com.cn、tieba.baidu.com은 3급 도메인 이름이다. 이와 같이 N급 도메인 이름은 N-1급 도메인의 직접 하위 도메인 이름이다.
사용자의 측면에서 볼 때, 일반적으로 독립적으로 등록할 수 있는 주역 이름을 일급 도메인 이름으로 한다. 예를 들어baidu.com、sina.com.cn은 모두 1급 도메인 이름이라고 할 수 있으며, 주 도메인 이름 아래에 만들어진 직접 하위 도메인 이름은 2급 도메인 이름입니다. 예를 들어tieba입니다.baidu.com은 2급 도메인 이름입니다.
잘못된 뜻을 피하기 위해서, 본인은 "주 도메인 이름 대체"1급 도메인 이름을 사용할 것입니다.
이상은 바로 단일 로그인의 세 가지 실현 방식에 대한 상세한 내용입니다. 더 많은 단일 로그인 실현에 관한 자료는 저희 다른 관련 글에 주목하세요!

단일 로그인의 세 가지 실현 방식

좋은 웹페이지 즐겨찾기