2022.05.13 「Session과 Token(Jwt) & 인증과 인가」

현재 진행 중인 프로젝트에서 로그인을 진행 중인데 기존에 로그인은 세션으로만 진행했었다. 로그인을 구현하는 방식은 여러 가지라고 배웠는데 그중 세션만 이용해봤기 때문에 토큰을 이용한 인증 경험도 필요하다고 생각을 했다.
그중 내 서비스에 대해 또 서비스 확장성에 대해 확실히 맞는 인증 방식을 결정해야겠다고 생각을 했고, 세션과 토큰의 사용처와 개념에 대해 정리를 해보려고 한다.

 

인증과 인가

인증(Authentication) 

서비스의 사용자가 맞는지 확인하는 과정

대게 로그인하는 과정

 

인가(Authorization) 

인증이 완료된 사용자에게 리소스 접근 가능하도록 사용 권한을 부여하는 작업

액세스가 허용된 데이터 및 해당 데이터로 할 수 있는 모든 작업을 지정함

 

HTTP의 특성

http는 stateless 하다.

즉 각 통신의 상태가 저장되지 않는다. 

로그인 처리에 문제가 있을 것이다.

 

=> 이 특성을 해결하기 위한 Session과 Token

 

Session

세션 방식의 인증은 Session Database를 필요로 한다. 

보통 세션에 사용자 정보를 젖아하고 SessionID를 가진 쿠키를 클라이언트에게 보내어 클라이언트는 Cookie jar에 저장한다. 쿠키는 자동으로 매 요청마다 보내지기 때문에 세션을 통한 로그인 인증이 이루어진다. 

즉 클라이언트는 쿠키를 이용하고, 서버는 쿠키를 통해 세션 정보를 접근할 수 있다.

 

장점

1. 쿠키가 노출되더라도 의미 없는 값이므로 안전하다.

2. 고유한 ID 값을 발급받기 때문에 바로 서버 자원 접근이 용이하다.

 

단점

1. 세션 하이재킹 공격 가능

2. 서버에서 추가적인 저장공간이 필요하다.

3. 서버 업스케일 시 인증 처리에 문제가 생길 수 있다. 다른 서버에 저장한 세션은 현재 서버 세션 DB에 없기 때문에

(사실상 이게 제일 중요)

 

Token(Jwt -> JSON Web Token)

Jwt란 인증에 필요한 정보를 암호화시킨 토큰이다. 

클라이언트는 Access Token(Jwt Token)을 헤더에 실어 서버에 전송

토큰은 제한된 수명을 가지고, 만료되면 새로 생성해야 한다. (Refresh Token)

 

JWT Token

1. Header :: Header, Payload, Verify Signature를 암호화할 방식(alg), 타입(Type) 등을 포함합니다.
2. Payload :: 서버에서 보낼 데이터 - 일반적으로 user의 id, 유효기간 포함
3. Verify Signature :: Base64 방식으로 인코딩한 Header, Payload, Secret key를 더한 후 서명됩니다.

=> Header & Payload는 암호화되지 않으므로 디코딩하여 확인 가능하다. 중요한 정보를 저장하지 못함.

 

Token 인증 절차

1. 클라이언트 로그인
2. 서버는 정보를 읽어 사용자 확인 후 고유 ID를 부여 후 기타 정보와 함께 Payload에 첨가
3. JWT 토큰 유효기간 설정
4. 서버에 있는 고유한 암호화할 Secret Key를 통해 Access Token 발급
5. 클라이언트는 이를 받아 저장 후 매 요청마다 토큰을 서버에 보냄
6. 서버는 해당 토큰의 Verify Signature를 Secret Key로 복호화 후 조작 여부 및 유효 기간 확인
7. 검증 완료 후 Payload를 디코딩해 클라이언트에 맞는 데이터를 가져온다. 

=> 토큰은 세션과 달리 DB에 저장되는 것이 아닌 토큰 자체에 유저의 정보가 저장된다. 

 

장점

1. 간편하다. (저장소 필요 없음, 서버 확장 & 유지보수 시 유리)

2. 확장성이 뛰어남

(토큰 기반 다른 인증 시스템 접근 가능)

 

단점

1. Payload 정보가 제한적이다.

2. JWT 길이가 길기 때문에 요청이 많을수록 서버의 자원 낭비가 발생함.

 

 

나는 어떤 인증방식을 사용할까?

정리한 개념으로 이루어 봤을 때 토큰을 사용해서 인증을 하는 방식으로 결정했다.

프로젝트 규모가 커질 경우를 대비할 생각이다. 혼자서 하는 프로젝트라 스케일이 작을 수도 있지만 더 크게 키워갈 수도 있는 것이고, 무엇보다 성능을 중요시하기 때문에 인증 정보를 저장할 DB가 따로 필요 없기 때문에 유지보수에 유리하다는 생각을 했다. 

또 다른 도메인의 로그인이 토큰을 통해서 가능하기 때문에 이 또한 이점이라 생각했다.

 

참조 : https://d-dual.tistory.com/3

[ 사용자 인증 / 인가 ] Session & Cookie VS Token