Access Token 방식

 

1. 사용자 로그인

2. 서버 측에서 계정 정보 확인 (Id, Password 등)

3-1. 사용자의 고유한 Id값 부여 후 Payload에 정보 삽입

3-2. JWT토큰의 유효기간 설정

4. secret key 를 통해 암호화된 Access Token을 HTTP 응답 헤더로 전송

5. 사용자는 인증이 필요한 요청마다 가지고 있는 Access Token을 HTTP 요청 헤더로 전송

6. 서버 측에서 해당 ㅗ큰의 Verify Signature를 secret key로 복호화 후, 조작 여부, 유효 기간 확인

7. 검증이 완료된다면 Payload 디코딩하여 사용자 Id에 맞는 데이터 전송

 

 

왜 사용할까?

서버 확장 시, 세션, 쿠키를 사용한 인증 방식의 경우 분산된 시스템 설계 필요 >> 설계 과정이 복잡

클라이언트 측에서 인증 정보를 가지고 있기 때문에 세션, 쿠키를 이용한 인증과는 달리 별도의 저장소 관리가 필요 없음 

따라서 서버 확장성 용이

 

 

Access Token + Refresh Token 방식

Access Token을 이용한 인증 방식의 경우, 클라이언트에서 인증 정보를 관리

보안 관점에서 토큰 탈취에 취약

 

이를 해결하기 위해 Access Token의 유효기간을 짧게 설정하고

Refresh Token을 따로 발급하여 Access Token 이 만료 되었을 때 새로운 Access Token을 발급받기 위한 정보로 활용

 

 

 

 

++ 위의 Access Token 만 활용한 응답 방식에서 요청 만료 시, 

 

1. 서버 측에서 Access Token 만료 확인

2. Access Token 만료 응답

3. 만료 응답 받은 사용자는 Access Token, Refresh Token 을 활용하여 Access Token 신규 발급 요청

4. 서버측에서 Refresh Token 확인 후 새로운 Access Token 발급하여 응답

 

이 과정이 추가

 

 

 

'끄적 > BE' 카테고리의 다른 글

Persistence Context (영속성 컨텍스트)  (0) 2023.01.01
Spring MVC  (0) 2022.12.29
JPA, Spring Data Jpa  (0) 2022.12.28
JPA  (0) 2022.12.28
JWT  (0) 2022.12.28

+ Recent posts