您好，我是路人，更多优质文章见个人博客：http://itsoku.comI. 개요
SSO는 Single Sign On의 약어이고 OAuth는 Open Authority의 약어입니다. 둘 다 토큰을 사용하여 애플리케이션에 액세스하기 위한 사용자 비밀번호를 대체합니다. 프로세스 측면에서는 매우 유사하지만 개념적으로는 매우 다릅니다. SSO는 누구나 숙지해야 할 개념으로, 로그인 인증을 업무 시스템과 분리하고, 독립적인 로그인 센터를 사용하며, 로그인 센터에 로그인하면 모든 관련 업무 시스템이 로그인 없이도 리소스에 접근할 수 있다는 점을 구현한 것입니다.
OAuth2.0의 원리는 비교적 생소할 수도 있지만 일상생활에서 많이 사용되는데요, 예를 들어 웹사이트에 접속해서 메시지를 남기고 싶지만 등록하고 싶지 않을 때 위챗 인증을 사용하게 됩니다. 위 두 가지 모두 비즈니스 시스템에 계정과 비밀번호가 없고, 계정과 비밀번호는 로그인 센터나 위챗 서버에 저장되어 있는데, 이는 소위 계정 비밀번호 대신 토큰을 사용해 접속하는 것입니다. 응용 프로그램.
2. SSO
둘 사이에는 유사점이 많으므로 아래에서 프로세스를 설명하겠습니다. 먼저 SSO에 대해 설명하자면, SSO와 OAuth2.0을 비교함으로써 OAuth2.0의 원리를 이해하는 것이 더 좋습니다. CAS 프레임워크 등 SSO 구현을 위한 다양한 프레임워크가 있으며, 다음은 CAS 프레임워크의 공식 흐름도입니다. 특별한 주의: SSO는 아이디어이고, CAS는 이 아이디어를 실현하기 위한 프레임워크일 뿐입니다.
위의 과정은 대략 다음과 같습니다.
사용자가 비즈니스 시스템에 들어가기 위해 URL을 입력하면
Protected App, 시스템은 사용자가 로그인되어 있지 않은 것을 발견하고CAS Server자체 주소 서비스 매개변수를 사용 하여 사용자를 싱글 사인온(Single Sign-On) 시스템으로 리디렉션합니다.사용자의 브라우저는 Single Sign-On 시스템으로 리디렉션되고 시스템은 사용자의 로그인 여부를 확인합니다. 이는 SSO(여기서는 CAS) 시스템의 첫 번째 인터페이스로, 사용자가 로그인하지 않은 경우 인터페이스는 다음과 같습니다. 사용자를 로그인 인터페이스로 리디렉션합니다. 로그인된 경우 글로벌 세션을 설정하고 비즈니스 시스템으로 리디렉션합니다.
사용자는 비밀번호를 입력하고 로그인을 제출합니다. 이때 로그인 인터페이스는 SSO 시스템에서 제공됩니다. SSO 시스템만이 사용자의 비밀번호를 저장합니다.
SSO 시스템은 비밀번호가 맞는지 검증하고, 맞다면 SSO 시스템에서 발행한 티켓으로 업무 시스템으로 리다이렉션합니다.
브라우저는 비즈니스 시스템의 로그인 인터페이스로 리디렉션됩니다. 이 로그인 인터페이스는 비밀번호가 필요하지 않지만 SSO 티켓을 전달합니다. 비즈니스 시스템은 티켓을 사용하여 SSO 시스템에 사용자 정보를 요청합니다. 그리고 로그인이 성공하고 브라우저에 반환되었음을 나타내는 로컬 세션을 설정합니다
sessionId( tomcat 에서 호출됨JSESSIONID).이후에는
sessionId비즈니스 시스템과의 상호작용을 통해 모든 상호작용이 가능합니다.
가장 일반적인 예는 Taobao 앱을 열면 홈페이지에 Tmall, Juhuasuan 및 기타 서비스에 대한 링크가 있는데, 이를 클릭하면 바로 건너뛰고 다시 로그인할 수 없습니다.
3. OAuth2.0
OAuth2.0에는 여러 가지 모드가 있습니다. 여기서는 OAuth2.0 인증 코드 모드에 대해 설명합니다. OAuth2.0의 프로세스는 SSO의 프로세스와 유사합니다. OAuth2에는 인증 서버, 리소스 서버 및 인증 서버와 같은 여러 역할이 있습니다. 클라이언트를 사용하는 경우 SSO를 구현할 때 리소스 서버 역할은 필요하지 않으며 Authorization 서버와 클라이언트만으로 충분합니다.
물론 인증을 위해 Authorization Server가 사용되며 클라이언트는 각 응용 시스템이므로 로그인 성공 후 사용자 정보와 사용자 권한만 가져오면 됩니다.
사용자가 WeChat 인증을 사용하기 위해 웹사이트를 클릭하면 여기의 웹사이트는 비즈니스 시스템과 유사하며 WeChat 인증 서버는 Single Sign-On 시스템과 유사합니다.
그 후 WeChat 인증 서버는 로그인 인터페이스와 유사한 인증 확인 페이지를 반환합니다.물론 이 페이지는 비즈니스 시스템이 아닌 WeChat에 속합니다.
사용자는 계좌번호와 비밀번호를 입력하는 것과 유사하게 승인을 확인하고, 제출 후 WeChat은 티켓을 인증하고 반환한 후 비즈니스 시스템으로 리디렉션합니다.
비즈니스 시스템은 티켓으로 WeChat 서버에 접속하고, WeChat 서버는 공식 토큰을 반환하며, 비즈니스 시스템은 토큰을 사용하여 사용자 정보를 얻을 수 있습니다.
OAuth2.0의 네 가지 모드를 간략하게 소개합니다.
인증코드(authorization-code)
인증 코드 방법은 타사 애플리케이션이 먼저 인증 코드를 신청한 다음 해당 코드를 사용하여 토큰을 얻는 것을 의미합니다. 이 방법은 가장 일반적으로 사용되는 프로세스이며 보안이 가장 높으며 백엔드가 있는 웹 애플리케이션에 적합합니다. 인증 코드는 프런트엔드를 통해 전송되고, 토큰은 백엔드에 저장되며, 리소스 서버와의 모든 통신은 백엔드에서 이루어집니다. 이러한 프런트엔드와 백엔드 분리는 토큰 유출을 방지할 수 있습니다.
숨겨진(암시적)
일부 웹 애플리케이션은 백엔드가 없는 순수한 프런트엔드 애플리케이션입니다. 이때, 위의 방법은 사용할 수 없으며, 프론트엔드에 토큰을 저장해야 합니다. RFC 6749는 토큰이 프런트엔드에 직접 발행될 수 있도록 허용하는 두 번째 방법을 지정합니다. 이 메소드는 인증 코드의 중간 단계가 없으므로 (인증 코드) "암시적"(implicit)이라고 합니다.
비밀번호(비밀번호)
애플리케이션을 매우 신뢰하는 경우 RFC 6749를 통해 사용자는 애플리케이션에 자신의 사용자 이름과 비밀번호를 직접 알릴 수도 있습니다. 애플리케이션은 귀하의 비밀번호를 사용하여 "비밀번호"라고 하는 토큰을 신청합니다.
클라이언트 자격 증명
마지막 방법은 프런트 엔드가 없는 명령줄 애플리케이션에 적합한 클라이언트 자격 증명입니다. 즉, 명령줄에서 토큰이 요청됩니다.
간단한 과정
넷째, 여러 명사의 차이점에 대해 이야기해 보세요.
우선 SSO 는 추상적인 아이디어나 솔루션이고, 우리가 해야 할 일은 그 아이디어에 따라 구현하는 것이다.
둘째, OAuth2는 사용자가 타사 애플리케이션에 권한을 부여하여 다른 서버에 있는 리소스에 액세스할 수 있도록 하는 데 사용되는 프로토콜로, Single Sign-On에는 사용되지 않지만 Single Sign-On을 구현하는 데 사용할 수 있습니다. 이 예에서 SSO를 구현하는 과정에서 보호되는 리소스는 사용자의 정보(사용자의 기본 정보 및 사용자 권한 포함)이며, 이 리소스에 액세스하려면 로그인하고 사용자에게 권한을 부여해야 하며, OAuth2 서버가 담당합니다. 토큰 발행 및 기타 작업 JWT를 사용하여 토큰을 생성합니다. 즉, JWT는 사용자의 Access_Token을 전달하는 데 사용됩니다.
마지막으로 Spring Security와 Shiro는 안전한 접근과 접근 제어를 위해 사용되며 모두 Java로 작성된 프레임워크입니다.
더 좋은 기사
↓↓↓ 点击阅读原文，直达个人博客
你在看吗