프로젝트를 진행하다 보면 로그인 기능을 구현할 때 JWT를 사용하게 된다.
이전 프로젝트에서는 JWT의 개념을 정확히 이해하지 않고 사용해서 이번 기회에 정리해보고자 한다.
인증 방식의 종류
1. Cookie 인증 방식
웹 사이트의 쿠키에 인증 정보를 저장하는 방식이다.
처음 브라우저가 로그인을 시도할 때, 로그인이 성공하면 서버가 응답 헤더에 로그인 정보를 담는다.
이후 클라이언트는 이 쿠키를 요청 헤더에 포함하여 보내고, 서버는 이 쿠키 정보를 바탕으로 클라이언트를 식별할 수 있다.
단점
- 쿠키는 브라우저에서 쉽게 확인할 수 있기 때문에 보안에 취약하다.
- 용량 제한이 있다.
- 브라우저 간 지원 형태가 다르다.
2. Session 인증 방식
세션은 쿠키와 달리 브라우저가 아니라 서버에 정보를 저장하는 방식을 의미한다.
쿠키의 보안 취약 문제를 해결할 수 있는 방식이다.
사용자가 로그인 요청을 보내고, 이 요청이 성공한다면 세션에 정보를 저장한다. 그리고 브라우저 쿠키에는 sessionId만 저장한다.
브라우저 쿠키에 저장된 sessionId를 통해 브라우저는 요청을 보낼 때마다 sessionId와 서버 세션에 저장된 sessionId를 비교하여 인증을 수행한다.
sessionId는 개인정보를 담고 있지 않기 때문에 보안에 유리하다.
단점
- 세션 ID 자체를 탈취할 경우 보안 문제가 생길 수 있다.
- 요청이 많아지면 서버에 부하가 심해진다.
JWT의 개념
JSON Web Token: 인증에 필요한 정보들을 암호화시킨 JSON Token
JWT.IO
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
jwt.io
JWT(JSON Web Token)는 당사자 간에 정보를 JSON 개체로 안전하게 전송하기 위한 간결하고 독립적인 방법을 정의하는 개방형 표준( RFC 7519 )입니다.
권한 부여, 정보 교환에 유용하게 사용된다. 인증된 사용자에게 권한을 부여하고, 인증된 사용자 간의 정보 교환에 토큰 인증이 활용된다.
JWT 구조
- Header
알고리즘, 타입으로 구성
{
"alg": "HS256",
"typ": "JWT"
}
알고리즘: 암호화 알고리즘
타입: 토큰 유형
- Payload
토큰에서 사용할 정보의 조각들인 Claim (데이터)
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
- Signature
헤더에서 정의한 알고리즘 방식을 활용하여 사용
서버의 유일한 key 값을 합쳐서 암호화
JWT 과정
- 로그인 요청
- JWT(Access-token, refresh-token) 생성, 클라이언트에게 발급
- 클라이언트는 JWT를 저장(로컬 스토리지/쿠키)
- API를 서버에 요청할 때마다 헤더에 JWT를 담아서 요청을 보냄
- 서버는 요청에 포함된 JWT와 서버의 JWT를 비교하여 인증
JWT 장점
- 데이터 위변조를 막을 수 있다. (Header, Payload, Signature 암호화)
- 인증 정보에 대한 별도의 저장소가 필요하지 않다. (서버 부하 X)
- Stateless 서버 - 서버 확장성이 우수
- 쿠키와 달리 브라우저마다 통일 가능
JWT 단점
- 토큰의 길이가 길어질 수 있다.
- payload를 디코딩하면 데이터를 확인할 수 있다. -> 중요 정보는 포함하지 않아야 한다
- 토큰 탈취에 대한 대처
Access-Token + Refresh-Token
이 중 토큰 탈취에 대해 대처할 수 있는 방법이 refresh token을 사용하는 것이다.
- Access Token : 클라이언트가 갖고 있는 실제로 인증에 활용하는 토큰, 클라이언트가 요청을 보낼 때 헤더에 포함하는 토큰
- Refresh Token: Access Token이 만료되었을 때 새로운 토큰을 발급하기 위해 사용, 보통 데이터베이스에 기록
Access Token은 그 토큰 자체로 인증에 활용되기 때문에 이 토큰이 탈취당했을 경우에는 보안에 취약해질 수 있다.
그래서 Access Token의 유효 기간을 짧게 하고, Refresh Token을 사용하여 새로운 토큰을 발급해줌으로써 보안을 강화하는 것이다.
과정 (refresh-token 활용)
- 로그인 요청
- 로그인 요청 허용 -> Access Token, Refresh Token 발급, DB에 Refresh Token 저장
- 사용자는 Refresh Token을 안전한 위치 (ex. http-only cookie)에 저장한다.
- access token을 사용하여 데이터를 요청한다.
- access token이 만료된 경우 서버는 요청을 허용하지 않는다.
- 사용자는 refresh token을 활용하여 다시 access token을 발급받는다.
- 서버는 클라이언트가 보낸 요청의 refresh token과 db의 token을 비교하여 동일한 경우 새로운 access token을 발급한다.
'BackEnd' 카테고리의 다른 글
[BackEnd] Cookie & Session 쿠키 세션 (0) | 2022.09.06 |
---|---|
[BackEnd] Servlet & JSP (0) | 2022.09.06 |
[네트워크] GET 방식과 POST 방식의 차이 (0) | 2022.09.05 |