spring boot 는 어떻게 JWT 를 바탕 으로 단일 로그 인 을 실현 하 는 지 상세 하 게 설명 합 니 다.

머리말
최근 에 우리 팀 은 담당 하 는 관리 시스템 A 에 다른 시스템 B 를 통합 시 켜 사용자 가 더욱 편리 하 게 사용 할 수 있 도록 여러 시스템 의 중복 로그 인 을 피하 기 위해 이러한 효 과 를 얻 기 를 바 랍 니 다.사용 자 는 한 번 만 로그 인하 면 이 두 시스템 에서 조작 할 수 있 습 니 다.이것 이 바로 단일 로그 인(Single Sign-On)이 이 루 는 효과 임 이 분명 하 다.바로 대 놓 고 단일 로그 인 지식 을 배 울 수 있다.
본 편의 주요 내용 은 다음 과 같다.
SSO 소개
SSO 의 몇 가지 실현 방식 비교

JWT 기반 spring boot 단일 로그 인 실전

주의:
SSO 라 는 개념 이 등장 한 지 오래 되 었 고 현재 각종 플랫폼 이 매우 성숙 하 게 실현 되 었 다.예 를 들 어 OpenSso,OpenAM,Kerberos,CAS 등 은 물론 성숙 한 것 이 복잡 함 을 의미 하 는 경우 가 많다.본 고 는 이러한 성숙 한 방안 의 사용 을 토론 하지 않 고 SSO 가 CS 응용 에서 의 사용 도 고려 하지 않 는 다.
SSO 가 뭐야?
한 번 로그 인 하면 다른 신뢰 할 수 있 는 플랫폼 에 로그 인 하지 않 아 도 된다 는 것 이다.예 를 들 어 우리 가 타 오 바 오 에 로그 인 한 후에 티몰 홈 페이지 를 열 면 이미 로그 인 상 태 를 발견 할 수 있다.SSO 는 기업 업무 통합 에 비교적 유행 하 는 서비스 솔 루 션 이다.
어떻게 SSO 를 실현 합 니까?
우 리 는 현재 http 프로 토 콜 이 무 상태 라 는 것 을 알 고 있 습 니 다.즉,첫 번 째 요청 과 두 번 째 요청 은 완전히 독립 되 고 관련 이 없 지만 현실 에서 우리 의 업무 논 리 는 모두 상태 가 있 습 니 다.그러면 쿠키-session 체 제 를 도입 하여 상 태 를 유지 하고 브 라 우 저 는 session Id 를 저장 하 며 배경 에는 이 session Id 와 관련 된 데 이 터 를 저장 합 니 다.백 엔 드 에 요청 할 때마다 이 sessionId 를 휴대 하면 상 태 를 유지 할 수 있 습 니 다.그 다음 에 쿠키 가 생 겼 습 니 다.브 라 우 저 는 요청 을 보 낼 때 쿠키 의 데 이 터 를 요청 에 자동 으로 넣 고 서버 에 보 내 며 수 동 으로 설정 하지 않 아 도 됩 니 다.
그리고 SSO 를 실현 하 는 핵심 이 무엇 인지 생각해 볼 수 있 습 니 다.정 답 은 한 플랫폼 A 를 로그 인 시 킨 후에 다른 플랫폼 에서 도 플랫폼 A 의 로그 인 정 보 를 얻 을 수 있 습 니 다(쿠키-session 체제 에서 session Id).
프로젝트 공유 쿠키
쿠키-session 메커니즘 을 바탕 으로 하 는 시스템 에서 시스템 에 로그 인 한 후에 sessionId 를 쿠키 에 저장 합 니 다.만약 에 우리 가 다른 시스템 에서 도 이 쿠키 를 얻 을 수 있다 면 증빙서류 정 보 를 얻 을 수 있 고 다시 로그 인 할 필요 가 없습니다.브 라 우 저의 쿠키 는 이러한 효 과 를 실현 할 수 있 습 니 다(웹 크로스 필드 및 쿠키 학습 참조).
쿠키 는 도 메 인 이름(또는 부자 도 메 인 이름)과 다른 포트 에서 쿠키 를 공유 할 수 있 습 니 다.이 점 은 http 의 같은 도 메 인 정책 과 다 릅 니 다(http 요청 은 프로 토 콜,도 메 인 이름,포트 가 다 르 면 크로스 도 메 인 으로 간주 합 니 다).따라서 여러 개의 응용 프론트 페이지 를 같은 도 메 인 이름(또는 부자 도 메 인 이름)에 배치 한 다음 에 session 을 공유 하면 단일 로그 인 을 할 수 있 습 니 다.구 조 는 다음 과 같다.

위 방안 의 뚜렷 한 제한 은 프론트 페이지 뿐만 아니 라 배경 에 도 세 션 을 공유 해 야 한 다 는 것 이다.(jwt 로 세 션 을 처리 할 수 있 지만 새로운 문 제 를 도입 할 것 이다.여 기 는 전개 되 지 않 는 다)이 방안 은 너무 간단 해서 더 이상 설명 하지 않 는 다.
방안 2 는 리 셋 에 기초 하여 실현 된다.
위의 글 을 통 해 알 수 있 듯 이 단일 로그 인 을 실현 하려 면 사용자 의 신분증 을 각 시스템 에 공유 하여 배경 에 현재 누가 방문 하고 있 는 지 알 게 해 야 한다.로그 인 을 한 번 하고 여기저기 방문 하 는 효 과 를 얻 을 수 있어 서 정말 편리 합 니 다.session 메커니즘 에 서 는 session Id 를 공유 하고 여러 배경 에서 같은 session 원본 을 사용 하면 됩 니 다.여기 서 우 리 는 새로운 JWT 기반 token 방식 으로 이 루어 집 니 다.JWT 를 모 르 는 사람 은 이 편 을 볼 수 있 습 니 다.자바-jwt 생 성 과 검증,쉽게 말 하면 jwt 는 변경 할 수 없 는 정 보 를 휴대 할 수 있 습 니 다(변경 하면 검증 실패).그래서 우 리 는 사용자 id 등 민감 하지 않 은 정 보 를 jwt 에 직접 넣 고 배경 세 션 을 제거 할 수 있 습 니 다.그리고 우리 가 해 야 할 일 은 jwt 를 각 플랫폼 페이지 에 공유 하면 된다.시스템 구 조 는 다음 과 같다.

이 구조 에서 업무 시스템 A 와 업무 시스템 B 는 아무런 관계 가 없 으 며 그들 은 모두 SSO 인증 플랫폼 과 만 접촉 하기 때문에 임의로 배치 할 수 있 고 같은 지역 의 제한 이 없다.신분증 을 어떻게 공유 해 야 하 는 지 물 어 봐 야 할 것 같 습 니 다.여 기 는 url 인 자 를 통 해 소란 을 피 워 야 합 니 다.
문자 요약 은 다음 과 같다.jwt 는 인증 플랫폼 전단 에 저 장 된 localstore(localstore,cookie,sessionstore 모두 가능 한 것 은 아니다).그리고 업무 플랫폼 은 자신의 리 셋 주 소 를 가지 고 인증 센터 의 프론트 데스크 로 이동 한 다음 에 ujwt 를 url 매개 변수 로 하여 그 리 셋 주소 로 뛰 어 들 면 jwt 의 공 유 를 완성 할 수 있다.
글 자 를 이해 하지 못 할 수도 있 습 니 다.다음은 전체 과정의 노정 도 입 니 다.

위의 프로 세 스 도 를 통 해 jwt 가 어떻게 공 유 했 는 지 대충 알 수 있 을 것 이 라 고 믿 습 니 다.아직 모 르 는 것 은 계속 보 세 요.아래 의 spring boot 가 실현 한 간단 한 SSO 인증 입 니 다.주로 두 가지 시스템 이 있 습 니 다.SSO 인증 센터,시스템 A(시스템 A 가 서로 다른 포트 로 운행 하면 시스템 A,B,C,D 입 니 다).
실전
SSO 인증 센터 구현
spring boot 프레임 워 크 를 먼저 구축 합 니 다.간단 한 프로젝트 이기 때문에 spring boot 웹 의 기본 의존 을 제외 하고 다음 과 같은 추가 의존 만 필요 합 니 다.

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.4</version>
</dependency>
<dependency>
<groupId>com.auth0</groupId>
<artifactId>java-jwt</artifactId>
<version>3.7.0</version>
</dependency>

완전한 POM 파일 입 니 다.github 에서 보십시오.
백 스테이지 구현
백 스테이지 에서 하 는 일 은 많 지 않 습 니 다.다음 과 같은 5 가지 방법 만 있 습 니 다.

/login:로그 인 성공 후 jwt token 을 발급 합 니 다

demo 에 서 는 사용자 이름 비밀 번 호 를 간단하게 비교 할 뿐 로그 인 에 성공 했다 고 생각 되면 token 으로 돌아 갑 니 다.
jwt 의 유효성 검사
전 송 된 jwt-token 이 효과 가 있 는 지 확인 하고 실 효 된 jwt 목록 으로 돌아 갑 니 다.

/refreshjwt:jwt 새로 고침

이 jwt 가 곧 만 료 되 는 지 판단 합 니 다.만 료 되 려 면 새로운 jwt 를 생 성하 여 되 돌려 줍 니 다.

/inValid:특정한 jwt 를 실효 시 킵 니 다

jwt 가 어떻게 효력 을 잃 는 지 는 줄곧 비교적 번 거 로 운 문제 로 각각 장단 점 이 있다.이 예 에 서 는 jwt 마다 무 작위 비밀 키 secret 를 만 들 고 jwtCsecret 를 redis 에 저장 합 니 다.jwt 를 무효 로 하려 면 이 기록 을 redis 에서 삭제 하면 됩 니 다.(이렇게 하면 복호화 할 때 secret 를 얻 을 수 없습니다)그러나 이렇게 무 상태의 인증 체 제 를 상태 로 만 들 었 다.
결론 적 으로 SSO 백 엔 드 는 주로 두 가지 일 만 했 습 니 다.사용자 이름 비밀 번 호 를 검증 하고 jwt 로 돌아 갑 니 다.jwt 가 합 법 적 인지 검증 합 니 다.구체 적 인 코드 는 github 의 sso 디 렉 터 리 아래 코드 를 보십시오.
 전면 실현
프론트 데스크 의 논 리 는 비교적 복잡 해서 이해 하기 쉽 지 않 고 모 르 는 것 은 위의 흐름 도 를 몇 번 더 본다.
다시 SSO 의 포인트 로 돌아 가기:로그 인 상 태 를 공유 합 니 다.프론트 데스크 에서 로그 인 상태(여기 서 jwt 문자열)를 어떻게 공유 해 야 합 니까?브 라 우 저의 제한 으로 쿠키 외 에 데 이 터 를 직접 공유 하 는 방법 이 없습니다.직접 공유 하지 않 았 으 니 간접 적 인 방법 이 있 을 거 야!
이 방법 이 바로 반전 이다.시스템 A 의 프론트 데스크 는 SSO 의 프론트 데스크 로 이동 할 때 현재 경 로 를 url 매개 변수 로 sso 프론트 데스크 에 전달 합 니 다.sso 프론트 데스크 는 jwt 를 얻 은 후에 시스템 A 가 전달 하 는 url 경로 로 이동 하고 jwt 를 url 매개 변수 로 가 져 옵 니 다.이것 은 jwt 의 공 유 를 완 성 했 고 sso 에서 시스템 A 로 공유 되 었 습 니 다.
예 를 들 어:네가 배달 을 시 켰 는데 다른 사람 이 어떻게 배달 을 해 줄 거 야?분명히 당신 이 남 긴 주 소 는 다른 사람 이 밥 을 가지 고 이 주소 로 보 내 면 맛 있 는 음식 을 먹 을 수 있 을 것 입 니 다.이것 은 jwt 의 전달 과 매우 안면 이 있다.
시스템 A:jwt 주세요.빨리 보 내 주세요.http://localhost:8081/test1/이 주소 에
SSO:좋아,이 주 소 는 합 법 적 인 것 이 야.jwt 를 보 낼 수 있어.바로 넘 어 갈 게.http://localhost:8081/test1/?jwt=abcdefj.asdf.asdfasf
시스템 A:좋아 좋아,좋아.
다른 악성 시스템 C 가 같은 형식 으로 SSO 로 이동 하면 jwt 를 가 져 오 려 면 주지 말 아야 할 구덩이 가 있 습 니 다.그래서 되 돌아 갈 때 이 반전 주소 가 합 법 적 인지 판단 해 야 합 니 다.jwt 에 게 줄 수 있 는 지,백 스테이지 에 판단 을 요청 할 수도 있 고 sso 프론트 데스크 에 직접 합 법 적 인 주 소 를 쓸 수도 있 습 니 다.demo 에 서 는 이 판단 과정 이 없습니다.
비 즈 니스 시스템 구현
비 즈 니스 시스템 코드 는 매우 간단 합 니 다.주로 차단 기 를 사용 하여 http 요청 을 차단 하고 token 을 추출 하여 sso 인증 센터 에 token 이 효과 적 인지,유효 하 게 실행 되 었 는 지 검증 합 니 다.그렇지 않 으 면 오 류 를 전단 으로 되 돌려 줍 니 다.너무 간단 해서 코드 를 붙 이지 않 습 니 다.github 에 가서 보면 알 수 있 습 니 다.
효과.
위 에서 말 한 한 줄 은 모두 원리 라 고 했 는데 사실은 이 어려움 도 원리 부분 에서 어렵 고 코드 실현 은 그리 복잡 하지 않다.여 기 는 코드 를 붙 이지 않 고 github 에 직접 가 봐 야 합 니 다.
여기 위의 몇 가지 효과 그림:
시스템 A 첫 로그 인 시스템

첫 번 째 로그 인 을 볼 수 있 습 니 다.넘 어가 야 돼 요.  sso 인증 센터 에서 사용자 이름 비밀 번 호 를 입력 하여 로그 인 인증 을 했 습 니 다.로그 인 성공 후 인터페이스 요청 이 성공 하 였 습 니 다.
A 의 시작 포트 를 8082 로 바 꾼 후 다시 시작 하여 시스템 B 로 합 니 다.

이번 에는 로그 인 이 필요 없 이 인증 센터 로 뛰 어 든 뒤 바로 뛰 어 오 르 는 것 을 볼 수 있 으 며,alert 를 없 애 면 점프 과정 이 보이 지 않 는 다.
마지막 으로 임의의 시스템 에서 로그아웃 하면 모든 시스템 이 로그 인 할 것 이다.
시스템 A 가 시스템 에 로그 인 한 후 시스템 B,시스템 C 는 더 이상 사용자 이름 비밀 번 호 를 입력 하지 않 고 로그 인 할 필요 가 없 음 을 알 수 있다.만약 속도 가 충분 하 다 면 SSO 로 다시 뛰 어 오 는 과정 조차 알 아차 리 지 못 할 것 이다.
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.