1. jwt 토큰의 소통, 인증, 발급 방식
a. 홍길동 유저가 로그인 시
1.1 클라이언트는 적절한 폼 로그인 html을 작성한다.
1.2 클라이언트는 서버로 로그인 요청을 보낸다.
1.3 서버는 클라이언트로부터 받은 로그인 요청에서 로그인 유저의 정보가 담긴 Access, Refresh Token을 제작한다.
1.4 서버는 클라이언트로 로그인 성공 응답과 함께 ac, re 토큰을 반환한다.
1.5 이때 re 토큰은 클라이언트의 쿠키에 등록되어 보내진다.
** 참고**
나는 ac 토큰도 쿠키에 담아서 보냈지만 실제로 ac 토큰은 헤더에 담아서 보내는 것이 일반적이다. 클라이언트 측 쿠키에 엑세스 토큰이 담겨있나 확인차 쿠키에 담은 것이고 실제로는 헤더에 담아서 보내야 한다.
- ac, re 토큰 발급 코드
Cookie accessTokenCookie = new Cookie("accessToken",accessToken);
accessTokenCookie.setHttpOnly(true);
accessTokenCookie.setPath("/");
accessTokenCookie.setMaxAge(Math.toIntExact(jwtUtil.ACCESS_TOKEN_EXPIRE_COUNT/1000)); //30분
Cookie refreshTokenCookie = new Cookie("refreshToken", refreshToken);
refreshTokenCookie.setHttpOnly(true);
refreshTokenCookie.setPath("/");
refreshTokenCookie.setMaxAge(Math.toIntExact(jwtUtil.REFRESH_TOKEN_EXPIRE_COUNT/1000)); //7일
response.addCookie(accessTokenCookie);
response.addCookie(refreshTokenCookie);
- ac, re 토큰을 둘다 쿠키에 저장했다.
- 엑세스, 리프레시 토큰은 쉽게 탈취당하지 않도록 http only 속성으로 쿠키에 저장을 해주었기 때문에, js 브라우저에서나 타인이 쉽게 볼 수 없고 탈취가 어렵다.
HTTP Only란?
- document.cookie와 같은 자바스크립트로 쿠키를 조회하는 것을 막는 옵션
- 브라우저에서 HTTP Only가 설정된 쿠키를 조회할 수 없다.
- 서버로 HTTP Request 요청을 보낼때만 쿠키를 전송한다.
- 이를 통해 XSS(Cross Site Scripting) 공격을 차단할 수 있다.
b. 로그인 후 요청
상황 1 : 로그인 후 요청 보낼 때 (엑세스 토큰이 유효한 경우)
1.1 ac 토큰이 유효하다면 인증/ 인가가 성공하여 응답을 반환한다.
1.2 요청했던 작업을 정상 수행한다.
상황 2 : 로그인 후 요청 보낼 때 (엑세스 토큰이 유효하지 않은 경우)
1.1 ac 토큰 에러 응답을 보낸다
1.2 이때 아래의 과정을 통해 엑세스 토큰 재발급 api로 이동해서 새로운 엑세스 토큰을 발급받아야 한다.
상황 2 -1 : 엑세스 토큰을 리프레시 토큰을 통해 재발급 과정
1-1. 서버는 클라이언트가 액세스 재발급 해주세요 라는 api를 발동시키게 되면, 쿠키에 저장돼있는 refreshToken을 잡아와서 이 refreshToken이 유효한 지 검사한다.
1-2 유효하다면 액세스를 재발급해준다.
1-3 액세스 재발급 api는 Authorization에 Bearer 방식으로 리프레쉬 토큰을 담아서 요청을 보내면 서버에서는 리프레쉬토큰 기간 만료 여부, 유효 여부를 따진다.
1-4 refreshToken기간이 만료됐다면, refreshToken 재발급이 필요하다는 에러를 throw 해야 한다.
1-5 이때 refreshToken이 유효하지 않아서 재발급 해야한다는 말은 사용자를 강제로그아웃 시킨 뒤, 재로그인하도록 만들어야 한다는 것과 똑같다.
어떻게 활용?
그럼 위의 로직을 바탕으로 프로젝트를 구성한다면 CSR 방식과 SSR 방식이 있을 것이다.
일단,
1. CSR 방식
이 방식은 클라이언트와 서버가 분리된 환경에서 api 통신으로 엑세스 토큰은 로컬스토리지, 헤더에 담고 리프레시 토큰은 쿠키에 담아서 보내면 된다.
2. SSR 방식
이 방식에서는 보통 jwt 방식을 잘 사용하지 않는다고 한다. 그래도 구현을 할 수는 있는데, 엑세스 토큰과 리프레시 토큰을 클라이언트 쿠키에 담아주는 방식이다.
근데 일단 이 방식에서는 폼에서 탬플릿엔진(jsp, 타임리프 등)을 사용해서 보여주기 때문에 따로 자바스크립트 코드를 사용해서 쿠키에 담는 방식을 이용해야 한다.
또한 jwt가 stateless 한 특징을 갖고 있는데 SSR 방식에서는 stateless 한 특성이 잘 보이지 않는다.
그래서 SSR 방식에서 jwt 를 사용한다면 왜 사용했는지, 그 이유를 명확히 말할 수 있어야 한다.
일단 나는 SSR 방식에서 jwt 토큰을 발급했기 때문에.. 코드는 아래와 같다.
2. Login form
<!DOCTYPE html>
<html lang="ko" xmlns:th="http://www.thymeleaf.org">
<head>
<meta charset="UTF-8">
<title>로그인</title>
<script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script>
<script src="/static/js/auth.js"></script> // 리프레시 토큰으로 엑세스 토큰 재발급
</head>
<body>
<form id="loginForm" action="/api/login" method="post">
<input type="text" id="username" name="username" placeholder="아이디" required />
<input type="password" id="password" name="password" placeholder="비밀번호" required />
<button type="button" onclick="loginUser()">로그인</button>
</form>
<script>
function loginUser() {
var username = document.getElementById('username').value;
var password = document.getElementById('password').value;
var data = {
username: username,
password: password
};
axios.post('/api/login', data)
.then(response => {
// 로그인 성공 시 토큰을 쿠키에 저장
var accessToken = response.data.accessToken;
var refreshToken = response.data.refreshToken;
document.cookie = "accessToken=" + accessToken + "; HttpOnly; path=/";
document.cookie = "refreshToken=" + refreshToken + "; HttpOnly; path=/";
// 성공 시 다음 페이지로 이동 혹은 필요한 작업 수행
window.location.href = '/api/users/home';
})
.catch(error => {
console.error('로그인 에러:', error);
// 실패 시 에러 처리 혹은 사용자에게 알림
alert('로그인 실패. 다시 시도해주세요.');
});
}
</script>
</body>
</html>
- 나는 SSR 방식으로 프로젝트를 진행 중이기 때문에 폼에서 axios, fetch 등으로 쿠키를 클라이언트에 보내주는 작업을 했어야 한다.
- 그래서 위의 폼에서의 자바스크립트 코드를 보면 엑세스, 리프레시 토큰을 앤드포인트에서 받아와 클라이언트 쿠키에 넣어주는 역할을 하고 있다.
- 참고로 위의 코드에서는 단순히 로그인 시에 엑세스와 리프레시 토큰을 받아오는 코드만 있고 엑세스 토큰이 만료되면 리프레시 토큰으로 재발하는 과정은 없다.
- 아래에 있는 코드가 재발급 과정에 맞는 코드이다.
- 아래 코드는 모든 요청마다 쿠키를 검증하는데, 이때 쿠키에 엑세스 토큰의 요청이 만료되면 리프레시 토큰의 유무를 판단하여 엑세스 토큰을 재발급하던지, 로그아웃을 하는 방향으로 진행된다.
// Axios 인터셉터를 설정하여 요청 전에 Access Token의 유효성을 검사하고 만료 시 갱신
axios.interceptors.request.use(
async config => {
// 쿠키에서 accessToken을 읽어온다.
var token = getCookie('accessToken');
if (token) {
config.headers['Authorization'] = 'Bearer ' + token;
}
try {
// Access Token이 만료되었는지 확인하는 로직 추가
var exp = parseJwt(token).exp;
var now = Date.now() / 1000;
if (exp < now) {
// Access Token이 만료되었으므로 Refresh Token을 사용해 갱신
var refreshToken = getCookie('refreshToken');
if (refreshToken) {
const response = await axios.post('/api/refreshToken', null, {
headers: {
'Authorization': 'Bearer ' + refreshToken
}
});
var newAccessToken = response.data.accessToken;
// 새로 발급받은 Access Token을 요청 헤더에 포함
config.headers['Authorization'] = 'Bearer ' + newAccessToken;
} else {
throw new Error('리프레시 토큰이 존재하지 않습니다.');
}
}
} catch (error) {
console.error('토큰 갱신 오류:', error);
}
return config;
},
error => {
return Promise.reject(error);
}
);
// 쿠키에서 값 읽기
function getCookie(name) {
let cookieArr = document.cookie.split(";");
for (let i = 0; i < cookieArr.length; i++) {
let cookiePair = cookieArr[i].split("=");
if (name == cookiePair[0].trim()) {
return decodeURIComponent(cookiePair[1]);
}
}
return null;
}
// JWT 파싱
function parseJwt(token) {
try {
return JSON.parse(atob(token.split('.')[1]));
} catch (e) {
return null;
}
}
나처럼 백엔드와 프론트엔드가 분리된 환경이 아니라면 jwt 토큰을 사용하는 것에 있어서 깊은 생각을 해봐야 할 것이다. !
'Spring > Security' 카테고리의 다른 글
Spring Security + OAuth2 + JWT 를 사용한 로그인, 로그아웃 구현 - 1편 (0) | 2024.08.09 |
---|---|
Spring Security + OAuth2 + Session 를 사용한 로그인, 로그아웃 구현 - google (0) | 2024.08.08 |
Spring : JWT를 왜 사용해야 할까? (0) | 2024.07.27 |
Spring Security + OAuth2 + Session 를 사용한 로그인, 로그아웃 구현 - Kakao, Naver (0) | 2024.07.26 |
Spring : OAuth2 로그인 방식 (0) | 2024.07.26 |