PHP에서 SSO 쿠키 로그인 분석 및 구현

SSO란 무엇인가요?

Single Sign-On SSO(Single Sign-On)는 ID 관리의 일부입니다. SSO에 대한 보다 일반적인 정의는 다음과 같습니다. SSO는 동일한 서버의 다른 애플리케이션에서 보호된 리소스에 액세스하는 동일한 사용자가 한 번만 로그인하면 된다는 것을 의미합니다. 즉, 한 애플리케이션에서 보안 확인을 통과한 후 보호된 리소스에 액세스할 수 있습니다. 다른 애플리케이션에서는 리소스에 접근할 때 확인을 위해 다시 로그인할 필요가 없습니다.

SSO의 목적:

현재 엔터프라이즈 애플리케이션 환경에는 다음과 같은 애플리케이션 시스템이 많은 경우가 많습니다. Taobao, Tmall, Aitaobao 및 기타 제품 및 사무 자동화(OA) 시스템, 재무 관리 시스템, 파일 관리 시스템, 정보 쿼리 시스템 등 이러한 응용 시스템은 기업의 정보 구축에 도움을 주고 기업에 좋은 이익을 가져다줍니다. 그러나 사용자가 이러한 응용 시스템을 사용하는 것은 불편합니다. 사용자는 시스템을 사용할 때마다 신원 확인을 위해 사용자 이름과 비밀번호를 입력해야 하며, 서로 다른 응용 시스템에는 서로 다른 사용자 계정이 있으므로 사용자는 동시에 여러 세트의 사용자 이름과 비밀번호를 기억해야 합니다. 특히 응용 프로그램 시스템 수가 많고 사용자 수가 많은 기업의 경우 이 문제는 특히 두드러집니다. 문제의 원인은 시스템 개발의 실수가 아니라 전반적인 계획의 부족과 통합된 사용자 로그인 플랫폼입니다. SSO 기술을 사용하면 위의 문제를 해결할 수 있습니다.

SSO의 이점:

사용자의 편리성: 실제 사용자 사용 관점에서

사용자가 애플리케이션 시스템을 사용할 때, 한 번 로그인하여 여러 번 사용할 수 있습니다. 사용자는 더 이상 매번 사용자 이름과 사용자 비밀번호를 입력할 필요가 없으며 여러 사용자 이름과 사용자 비밀번호 세트를 기억할 필요도 없습니다. Single Sign-On 플랫폼은 애플리케이션 시스템 사용에 대한 사용자 경험을 향상시킬 수 있습니다.
관리자에게 편리함: 일상적인 유지 관리의 관점에서

현재 많은 대형 인터넷 회사에는 많은 애플리케이션이 있습니다. 예를 들어 다음은 Taobao의 스크린샷입니다.

Tmall Juhuasuan Toutiao와 기타 애플리케이션은 서로 다른 애플리케이션이며 일부는 완전히 다른 도메인 이름을 사용하기도 하지만 Taobao에 등록된 모든 사용자는 동일한 사용자 이름과 비밀번호 세트를 사용합니다. 이러한 시스템 간에 직접 전환하고 로그인 상태를 동기화할 수 없으면 경험이 매우 저하됩니다. 또 다른 예로, 많은 회사에는 인사 시스템, 재무 시스템, 출석 시스템 등 많은 내부 시스템이 있습니다. 직원이 한 시스템에 로그인하고 다른 시스템으로 이동하기 위해 로그인해야 한다면 매우 불편할 것입니다..

이를 바탕으로 SSO(Single Sign On)가 탄생했습니다. 물론, 이 요구 사항을 실현하는 방법은 여러 가지가 있습니다. 쿠키를 사용하는 것은 해결해야 할 주요 문제입니다. 한 도메인의 쿠키를 다른 응용 프로그램에 알리는 방법. 같은 도메인에서)?

따라서 쿠키 메커니즘에 익숙하지 않은 경우 먼저 Google에 검색하여 쿠키가 도메인을 넘지 않도록 설계되는 이유 및 기타 관련 문제에 대한 일반적인 이해를 얻으십시오.

시스템 관리자는 통합된 사용자 계정 집합만 유지하면 되므로 편리하고 간편합니다. 대조적으로, 이전에는 시스템 관리자가 많은 사용자 계정 세트를 관리해야 했습니다. 각 응용 프로그램 시스템에는 일련의 사용자 계정이 있어 관리에 불편을 줄 뿐만 아니라 관리 허점이 생기기 쉽습니다.

응용 시스템 개발 단순화: 응용 프로그램 확장 관점에서 고려

새로운 응용 시스템 개발 시 Single Sign-On 플랫폼의 사용자 인증 서비스를 직접 활용하여 개발을 단순화할 수 있습니다. 프로세스. Single Sign-On 플랫폼은 통합된 인증 플랫폼을 제공하여 Single Sign-On을 구현합니다. 따라서 응용 시스템에서는 사용자 인증 절차를 개발할 필요가 없습니다. ​
어떻게 달성할 수 있나요?

SSO에는

공유 쿠키

를 구현하는 다음과 같은 방법이 있습니다. 하위 시스템이 모두 상위 도메인 이름 아래에 있는 경우 상위 도메인 아래에 쿠키를 심을 수 있습니다. , 동일한 도메인 이름의 쿠키는 브라우저에서 공유될 수 있으므로 쿠키 암호화 및 복호화 알고리즘을 통해 사용자의 Session ID를 획득하여 SSO를 실현할 수 있습니다.

그러나 나중에 이 방법에는 몇 가지 단점이 있다는 사실이 밝혀졌습니다.
a. 동일한 도메인 이름을 가진 모든 시스템은 수정하기 쉽고 안전하지 않은 SessionID를 얻을 수 있습니다. b. 크로스 플랫폼 도메인을 사용할 수 없습니다.

현재 이 방법을 채택하고 있습니다

이 SSO 구현 단계는 다음과 같습니다.

사용자가 액세스할 때. 특정 하위 시스템에 로그인되어 있지 않으면 사용자가 SSO 로그인 페이지로 이동하도록 안내됩니다.

b. SSO가 이미 로그인되어 있으면 점프합니다. 콜백 주소로 직접 이동하고 인증 티켓을 반환합니다.
d. 로그인하지 않은 경우 사용자가 사용자 이름/비밀번호를 올바르게 입력하면 인증 패스가 콜백 주소로 이동하고 인증 티켓을 반환합니다.
e 하위 시스템은 티켓을 획득하고 SSO를 호출하여 사용자 uid 등의 정보를 획득한 후 성공 후 사용자가 로그인할 수 있도록 허용합니다.

앞서 언급했듯이 쿠키를 통해 SSO를 구현하는 방법은 주로 도메인 간 문제를 해결하는 방법에 관한 것입니다. 먼저 Set-Cookie의 도메인 속성에 대해 이야기해 보겠습니다.

쿠키 도메인

Http 프로토콜이 어느 정도 컨텍스트를 유지할 수 있도록 서버는 응답 헤더에 Set-Cookie를 추가하여 일부 데이터를 클라이언트에 쓸 수 있습니다. , 설정 - 쿠키의

도메인 필드는 쿠키가 위치한 도메인을 나타내는 데 사용됩니다.

Chestnut:

www.cookieexm.com을 방문합니다. 서버가 반환 헤더에 Set-Cookie를 추가하고 도메인이 지정되지 않은 경우 이 쿠키의 기본 도메인은 www입니다. .cookieexm..com, 즉 클라이언트는 www.cookieexm.com을 방문할 때만 이 쿠키를 서버에 반환합니다.
도메인을 .cookieexm.com으로 지정하면 클라이언트는 다음 도메인 이름에 액세스할 때 쿠키를 반환할 수 있습니다: www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com.

그래서 우리는 클라이언트가 쿠키의 도메인을 마지막부터 일치시킨다는 결론을 내립니다. 이를 바탕으로 SSO 로그인을 구현할 수 있습니다.

쿠키에 주의할 사항

은 http 전용으로 설정되어 있습니다

로그인 자격 증명(예: 티켓 또는 사용자 이름)은 암호화되어야 합니다.

쿠키는 개인 데이터를 저장할 수 없습니다

특정 솔루션

다음 하위 시스템 **.a1.a2 **.b1.b2가 필요하다고 가정합니다. **.c1 .c2 간에 싱글 사인온을 구현하려면 먼저 싱글 사인인을 위한 인증 시스템(sso.s1.s2)이 필요합니다. 시스템이 현재 로그인되어 있지 않다고 가정하고 예를 들어 www.a1.a2에 액세스합니다.

각 단계의 효과를 각각 살펴보세요.

Request www.a1 .a2

www.a1.a2는 요청을 받고 로그인 쿠키가 있는지 확인합니다. 아직 로그인하지 않은 경우 SSO 인증 센터
SSO로 리디렉션됩니다. 로그인 창을 제공하며, 사용자는 사용자 이름과 비밀번호를 입력합니다. SSO 시스템은 사용자 이름과 비밀번호를 확인합니다

로그인에 성공하면 사용자 인증과 동시에 SSO 시스템의 쿠키가 먼저 클라이언트에 배치됩니다. 정보는 리디렉션을 통해 비즈니스 당사자에게 전달됩니다. 이 전송은 일반적으로 암호화된 쿼리 문자열을 통해 쿠키(다른 도메인)를 통해 전달될 수 없습니다.

사업측 검증 시스템은 SSO 인증 정보를 받아 인증한다
사업측은 인증을 통과한 후 인증 결과의 쿠키를 .a1.a2에 쓴다. SSO 인증이 완료되었습니다
비즈니스 시스템 www.a1.a2로 리디렉션됩니다. 이전 결론에 따르면 .a1.a2로 끝나는 모든 비즈니스 시스템은 이 인증된 쿠키를 사용할 수 있습니다

응답

참고:
너무 민감하지 않은 일부 시스템은 SSO 인증에서 비즈니스 시스템으로 직접 리디렉션되어 SSO 인증 정보를 가져올 수 있습니다.

위 내용에 따라 이때 사용자가 www.b1.b2 애플리케이션에 접속하면 아래 그림과 같이

은 www.a1.a2에 액세스하는 것과 동일합니다. 차이점은 현재 sso.s1.s2에 이미 쿠키가 있고 쿠키 확인을 직접 사용하기 때문에 SSO 인증으로 리디렉션할 때 더 이상 사용자 이름을 입력할 필요가 없다는 것입니다.

위는 쿠키 기반의 간단한 로그인 시스템입니다.

이러한 여러 문제를 집중적으로 해결해야 합니다

대량의 임시 신뢰 데이터를 효율적으로 저장하는 방법
정보 전송 프로세스가 변조되지 않도록 방지하는 방법
SSO 시스템이 로그인 시스템과 Bintang 시스템을 신뢰하게 만드는 방법
첫 번째 문제의 경우 일반적으로 memcached와 유사한 분산 캐시 솔루션을 사용할 수 있습니다. 이는 확장 가능한 데이터 볼륨을 위한 메커니즘을 제공할 수 있을 뿐만 아니라 효율적인 액세스

세 번째 문제의 경우 일반적으로 디지털 인증서 서명 또는 md5와 같은 방법을 통해 두 가지 질문이 사용됩니다. 이를 위해서는 반환 시 md5로 확인해야 하는 매개변수를 암호화해야 합니다. 로그인 URL을 입력하고 이를 토큰과 함께 반환합니다. 로그인해야 하는 시스템이 최종적으로 신뢰 관계를 확인할 때 SSO 시스템은 정보가 수정되었는지 여부를 식별할 수 있습니다. 토큰 확인

마지막 질문에 대해 간단히 말하면 화이트리스트에 있는 시스템만 프로덕션 신뢰 관계를 요청할 수 있습니다. 마찬가지로 화이트리스트에 있는 시스템만 로그인에서 제외될 수 있습니다.

SSO 쿠키 로그인 분석 및 PHP 구현에 관한 더 많은 기사를 보려면 PHP 중국어 웹사이트를 주목하세요!