로그인 구현 방식
로그인 구현 방식에는
세션 방식과 JWT 토큰을 사용하는 방식이 있습니다.
일단 세션 방식에 대해 먼저 알아보겠습니다.
세션 방식이란?
: 세션은 서버의 메모리에 생성되는 저장 공간입니다.
바로 이 저장공간에 로그인한 유저의 정보가 저장됩니다.
사용자가 로그인을 하게 되면
서버는 쿠키에 세션ID를 실어서 브라우저에게 보냅니다.
세션 방식을 사용하는 이유가 뭘까요?
일단 HTTP 프로토콜의 특징을 이해해야 합니다.
Stateless (무상태 프로토콜)
: 어떠한 이전 요청과도 무관한 각각의 요청을
독립적인 트랜잭션으로 취급하는 통신 프로토콜이빈다.
즉 서버에 세션 상태가 없는 상태를 의미합니다.
Stateless 구조는 서버의 response가
클라이언트와의 세션 state와 독립적입니다.
서버는 요청이 오면 응답을 보내는 역할만 수행하고,
세션 관리는 오로지 클라이언트에게 책임이 있습니다.
HTTP 프로토콜은 클라이언트와 서버의 통신이 끝나자마자
상태 정보를 잊어버립니다.
User1이 방금 전까지 서버와 통신을 했더라도
연결이 끊기자마자 User1이 누구인지 까먹고
다시 해당 클라이언트의 정보를 요구하는 것입니다.
페이지를 이동할때마다
내가 누구냐고 물어보면 상당히 귀찮을 것입니다.
이를 해결하기 위해 나온 방식이 세션 기반 인증 방식입니다.
세션/쿠키 방식 동작원리
(1) 세션에 로그인 정보를 저장하고 그 정보를 이용합니다.
(2) 로그인을 하면 세션 ID가 생성되어 frontend에 쿠키로 전달되고,
그 난수가 세션에 저장됩니다.
(3) 클라이언트 요청이 있을때마다 withCredentials 설정을 통해
함께 전달된 쿠키를 세션에 저장된 정보와 확인합니다.
(4) 이후 확인이 되면, DB에서 해당 유저정보를 가져와
Request의 user에 값을 넣어줍니다.
JWT 방식이란?
: JSON Web Token의 약자로써
JSON 객체에 사용자 정보의 일부를 담는 방식입니다.
말 그대로 인증에 필요한 정보를 토큰에 담아 암호화시켜 사용합니다.
세션 방식이 아닌 JWT 방식을 사용하게 된 이유가 뭘까요?
일단 세션 방식을 사용하게 되면 2가지의 문제점이 있습니다.
세션은 서버의 메모리 내부에 저장이 되기 때문에,
유저가 수천명일 경우 메모리에 부하가 걸릴 수 있다는 문제점이 있습니다.
또한 서비스의 규모가 커져서 서버를 여러대로 확장하게 되면,
세션을 분산시키는 기술을 따로 설계해야합니다.
이를 해결하고자 나온 방식이 JWT라는 로그인 방식입니다.
JWT 구조
HEADER , PAYLOAD , SIGNATURE
xxxxx. yyyyy. zzzzz
위처럼 각각의 구성요소가 점으로 구분되어 있습니다.
1. HEADAER
: 토큰의 타입이나 서명 생성에 어떤 알고리즘이 사용되었는지 저장합니다.
2. PAYLOAD
: Claim이라는 사용자에 대한, 혹은 토큰에 대한 프로퍼티를
key- value의 형태로 저장합니다.
Claim은 말 그대로 토큰에서 사용할 정보의 조각입니다.
3. SIGNATURE
: 점을 구분자로 해서 헤더와 페이로드를 합친 문자열을 서명한 값이빈다.
서명은 헤더의 alg에 정의된 알고리즘과 비밀키를 이용하여 생성하고
Base64 URL-safe로 인코딩을 합니다.
jwt 복호화 하는 사이트는
아래 링크입니다.
생성된 토큰을 입력하면,
아래와 같이 jwt에 담긴 값을 확인할 수 있습니다 :)
JWT.IO
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
jwt.io
Access Token과 Refresh Token
(1) Access Token
: 사용자가 서버에 요청(Request)를 보낼 때,
Header에 함께 보내는 접근용 토큰입니다.
만료 시간을 10분 정도로 짧게 두어 자주 발급하게 합니다.
따라서 토큰을 탈취 당하더라도 금방 만료되기 때문에 안정성이 유지됩니다.
(2) Refresh Token
: Access Token이 만료되었을 때 재발급 받기 위한 인증용 토큰입니다.
평소 요청에서 Request에 포함되어 있지 않다면 Access Token만 재발급받는 용도로 사용합니다.
만료 기간이 끝나면 사용자에게 로그인을 다시 요청하면 됩니다.
(대부분 Refresh Token을 DB에 저장해서 관리합니다)
https://1-7171771.tistory.com/159
JWT(Json Web Token) 기초
JWT JWT(Json Web Token)란 인증에 필요한 정보들을 암호화 시킨 토큰을 의미한다. JWT 기반 인증은 쿠키/세션 방식과 유사하게 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별한다. 구
1-7171771.tistory.com
Access Token과 Refresh Token 수행 과정
1. 로그인하면 Access Token과 Refresh Token을 발급 받습니다.
Refresh Token은 DB에 저장합니다.
2. 요청 시 헤더에 액세스 토큰을 담아서 보냅니다.
3. 액세스 토큰 만료시, 액세스 토큰과 refresh 토큰을 함께 보내서
토큰 재발급을 요청합니다.
4. 기간만 만료된, 유효한 액세스 토큰이고,
DB에 저장된 refresh 토큰과 같으면서 유효한 refresh 토큰이라면
1번 과정처럼 액세스 토큰과 refresh 토큰을 재발급 받습니다.
5. 유효하지 않은 refresh 토큰이라면, 재로그인을 요청받습니다.
https://kukekyakya.tistory.com/entry/Spring-boot-access-token-refresh-token-발급받기jwt
Spring Boot jwt 사용하기 access token, refresh token 발급
로그인 요청시 access token(jwt)과 refresh token을 발급받는 기능을 구현해보겠습니다. 기존에 access token을 발급 받는 기능까지는 구현을 했었지만, 액세스 토큰의 짧은 만료 기간으로 인해 계속해서
kukekyakya.tistory.com
JWT 방식의 장점
1. 세션/쿠키 기반의 경우 Redis와 같은 세션 스토리지를 따로 관리해야하지만,
JWT의 경우 클라이언트의 로컬 스토리지에 저장하기에
별도의 저장소를 관리하지 않아도 됩니다.
JWT 방식의 단점
1. JWT의 경우 한 번 발급되면 강제로 삭제하는 방법이 없습니다.
-> 따라서 Access Token 의 유효기간을 10~15분으로 짧게 설정하고
refresh Token을 관리하는 방식을 사용합니다.
2. JWT의 긴 길이로 인해
인증이 필요한 요청이 많아질수록
서버의 자원사용률이 높아집니다.
https://akdl911215.tistory.com/290
stateless(무상태) 란?
stateless란 위키백과에서 검색해보면, stateless는 아래처럼 나온다. 컴퓨팅에서 무상태 프로토콜(stateless protocol)은 어떠한 이전 요청과도 무관한 각각의 요청을 독립적인 트랜잭션으로 취급하는 통
akdl911215.tistory.com
'여니의 프로그래밍 study > Spring & Spring Boot' 카테고리의 다른 글
| Controller, Service, ServiceImpl, DAO, VO에 대해 알아보자 (0) | 2023.05.04 |
|---|---|
| [스프링부트] 개발하며 만난 에러 기록집 ( = 계속 업데이트 될 예정) (0) | 2022.06.01 |
| [스프링부트] Error parsing HTTP request header (0) | 2022.03.23 |
| [스프링부트] PostsApiControllerTest.java (조회기능) + h2 데이터베이스 콘솔 사용법 (0) | 2022.03.23 |
| [스프링부트] PostApiController Test 작성 (게시글 수정 기능) (0) | 2022.03.22 |
