세션 기반 인증, 토큰 기반 인증, JWT를 통한 인증 절차(with Access Token, Refresh Token)

📖세션 기반 인증

🔎세션이란?

세션이란 서버측에 저장되는 임시상태정보이다. 서버 측에 저장되므로 보안성이 높지만, 확장성이 떨어진다는 단점이 있다.

사용자가 접속하면 서버는 고유한 세션 ID를 생성해 사용자에게 전송한다. 사용자는 쿠키/로컬 스토리지 등에 세션 ID를 저장한다. 세션 ID 자체에는 중요한 정보를 가지고 있지 않으므로 보안성 측면에서 안전하다. 만약, 세션 ID가 탈취 당했다면 서버는 단지 해당 세션을 만료시키면 된다. 사용자는 요청시에 세션 ID와 함께 요청을 전달하며, 서버는 이를 통해 사용자의 정보를 확인할 수 있다.

서버는 세션 정보를 톰캣의 WAS, DB, 메모리 DB 등에 저장할 수 있다. 메모리 DB에는 Redis 등이 있다.

 

✏️쿠키와 세션의 비교

쿠키는 클라이언트에 저장되는 작은 데이터 파일이다. 다음과 같은 특징을 가진다.

• 보안측면: 쿠키는 클라이언트에 저장되므로 탈취당하기 쉽다. 따라서 중요한 정보를 쿠키에 저장하지 않는 것이 좋다. 예를 들어, 쿠키는 XSS공격(웹 사이트에 악의적인 스크립트를 삽입하는 공격)을 통해서 탈취당할 수 있다. 쿠키의 탈취를 막기 위해서는 HTTPOnly 옵션을 통해 HTTP(S) 요청을 통해서만 쿠키에 접근할 수 있게 할 수 있다.
• 용량측면: 쿠키는 4KB의 크기로 비교적 작은 용량을 가진다.
• 자동전송: 동일한 서버 요청시에 쿠키는 자동으로 요청에 포함되어 전송된다. 단, 쿠키는 브라우저의 윈도우별로 관리가 불가능하다.
• 기간설정: 쿠키는 만료 기간을 설정할 수 있다.

세션은 쿠키와 비교했을 때 서버 측에서 관리하므로 보안성이 우수하다.

 

✏️기타: 쿠키와 웹 스토리지 비교

쿠키의 한계

1. 작은 용량

2. 불필요한 트래픽 발생: 자동전송으로 인한 불필요한 트래픽 발생

3. 브라우저의 윈도우마다 독립적인 값 저장 불가

 

웹 스토리지

세션 스토리지: 브라우저의 윈도우마다 독립적으로 관리되며, 윈도우가 사라지면 소멸되는 일시적인 저장소이다. 

로컬 스토리이: 브라우저의 윈도우가 공유하며 브라우저가 윈도우가 닫혀도 사라지지 않는 영구적인 저장소이다. 

 

 

📖토큰 기반 인증

세션 기반 인증에서는 인증 정보를 서버에서 저장하고 관리했다면, 토큰 기반 인증은 클라이언트에 저장된다. 사용자가 접속하면 서버는 고유한 토큰을 발급하여 사용자에게 전달하고, 사용자는 이 토큰을 매 요청마다 포함하여 전송한다.

JWT(Json Web Token)은 토큰 기반 인증 방식 중 하나로, 사용자 인증에 필요한 정보를 JSON 형태로 암호화하여 토큰 형태로 제공하는 방식이다. 

 

📌JWT

JWT란 인증에 필요한 정보들을 암호화시킨 JSON 토큰이다. JWT 기반 인증은 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식이다.

JWT는 JSON 데이터를 Base64 URL-safe Encode를 통해 인코딩하여 직렬화한 것이다. 토큰 내부에는 위변조 방지를 위해 개인키를 통한 전자서명이 들어있다. 따라서 사용자가 JWT를 서버로 전송하면 서버는 서명을 검증하는 과정을 거치게 되며 검증이 완료되면 요청한 응답을 돌려준다.

JWT는 .를 구분자로 나누어지는 세 가지 문자열의 조합니다. .를 기준으로 Header, Payload, Signature로 나누어진다. Header에는 JWT에서 사용할 타입과 해시 알고리즘의 종류가 담겨있으며, Payload는 서버에서 첨부한 사용자의 권한 정보와 데이터가 담겨 있다. 마지막으로 Signature에는 Header, Payload를 Base64 URL-safe Encode를 한 이후 Header에 명시된 해시함수를 이용하고, 개인키(Private Key)로 서명한 전자서명이 담겨있다.

 

✏️Access Token의 한계

❗사용자의 잦은 로그아웃 경험, 보안 문제

Access Token은 발급 이후 Token 자체로 사용자 권한을 인증한다. 이때, Access Token이 탈취되면 토큰이 만료되기 전까지 토큰을 획득한 사람은 누구나 접근이 가능해진다. Token 유효기간을 짧게 하는 것은 Token 탈취에 대한 해결책이 될 수 있지만, Token 유효 기간을 짧게 하면 그만큼 잦은 로그아웃으로 인해 사용자가 불편해진다.

 

✏️Refresh Token의 도입

목적

Refresh Token의 목적은 Access Token의 유효 기간을 짧게 만들어 보안을 강화하면서도 사용자가 잦은 로그아웃 경험을 하지 않도록 함에 있다.

Access Token이 리소스에 접근하기 위해 사용되는 Token이라면, Refresh Token은 기존 클라이언트가 갖고 있던 Access Token이 만료되었을 때 Access Token을 새로 발급받기 위해 사용되는 Token이다.

 

유효기간

Refresh Token은 Access Token 대비 긴 유효 기간을 갖는다. Refresh Token을 사용하는 상황에서는 일반적으로 Access Token의 유효기간은 30분 이내 Refresh Token의 유효기간은 2주 정도로 설정한다고 한다. 당연히 서비스 성격에 따라 적절한 유효기간을 설정해야 한다.

 

한계

Refresh Token 도입을 통해 Access Token의 유효시간을 짧게 만들었지만 짧은 유효 시간동안 Access Token이 탈취당할 가능성이 있다. 또한 Refresh Token이 탈취당한다면 공격자는 Access Token을 발급받을 수 있다는 문제점이 존재한다.

 

🔎JWT를 통한 인증 절차(with Access Token, Refresh Token)

[프론트엔드]: 백엔드에 ID와 비밀번호를 전달한다.

[백엔드]: ID와 비밀번호를 검증하고 Access Token과 Refresh Token, Access Token의 만료시간을 반환해준다. 이때 생성한 Refresh Token은 DB에 {ID, Refresh Token}으로 저장한다.

[프론트엔드]: 반환받은 Access Token을 매 api 호출마다 헤더에 붙여서 전송한다.

[백엔드]: api 호출시 헤더의 Access Token을 확인하고 유효한지, 만료기간이 지났는지를 확인 후 api를 동작시킨다.

[프론트엔드]: Access Token의 만료 기간이 지났다면 백엔드에 Refresh Token으로 Access Token을 재요청한다.

[백엔드]: Refresh Token이 DB에 있는지 확인 후, 맞다면 Access Token과 새로운 Access Token 만료 시간을 반환한다.

[프론트엔드]: 새로 발급받은 Access Token을 매 api 호출마다 헤더에 붙여서 전송한다.

 

 

✨참고

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Access-Token-Refresh-Token-%EC%9B%90%EB%A6%AC-feat-JWT

[WEB] 📚 Access Token & Refresh Token 원리 (feat. JWT)

https://hudi.blog/refresh-token/

Access Token의 문제점과 Refresh Token

https://han-um.tistory.com/17

JWT의 개념, 프론트엔드에서 해야 할 일