세션 / 토큰 기반 인증 방식

로그인/로그아웃을 구현할 때, 서버에서는 어떤 방식으로 이를 개발할까?

크게 세션 기반과 토큰 기반 방식으로 나뉘는데, 어

 

세션 기반 인증

서버가 클라이언트의 세션 정보를 저장하고 있는 stateful 한 방식으로, 서버가 클라이언트의 세션 정보를 기억하고 있다가 처리한다.

 

• 사용자가 POST /api/v1/users/signin 을 통해 로그인을 하게 되면 사용자의 정보를 검증한 후 서버에서는 세션 id 를 발급해주며 이 JSESSIONID 를 브라우저의 쿠키에 저장한다.
• 브라우저는 모든 요청마다 쿠키에 있는 세션 id 를 포함하고 서버는 세션 id 로 유저 정보를 세션 스토리지에서 조회한다.
• 일반적으로 서버 메모리 db 등을 사용해 세션을 저장한다.
• 세션을 만료 시켜서, 클라이언트의 권한을 즉각 회수 할 수 있다.

 

단점

• 분산 환경에서는 세션을 공유 할 수 있는 세션 클러스터링이 필요하므로, 서버의 확장이 어렵다.
• 중앙에서 세션을 관리할 수 있는 db 를 구축해야한다.
• 요청이 많아지면 세션 조회에 따른 db의 부하가 심해진다.

 

 

---

 

토큰 기반 인증

토큰 기반 인증은 서버가 클라이언트의 세션을 저장하지 않기 때문에 stateless 방식이다.

대표적으로 JWT(Json Web Token) 방식이 있다.

 

 

• 사용자가 POST /api/v1/users/signin 을 통해 로그인을 하게 되면 서버는 검증 후 토큰을 발급하고 응답으로 내려준다.
• 클라이언트는 토큰을 저장하고 있다가 다른 요청을 할 때마다 Authorization 헤더에 토큰을 전달한다.
• 서버는 요청마다 전달받은 토큰들을 검증한다.
• 서버가 분산된 환경에서도 서버에서는 클러스터링 처리가 필요 없다
• JWT 토큰 내부에서는 기본적인 정보와 검증된 토큰임을 서명하는 유용한 정보들을 가지고 있으므로, 별도의 I/O 작업을 하지 않아도 된다.

 

단점

• 한번 발행된 토큰은 클라이언트가 보관하므로, 회수하기 어렵다.
• 회수가 어렵고 탈취되면 대처가 어려우므로, 만료 시간을 짧게 할당해야한다.
• 토큰이 길어지면 네트워크의 부하가 커질 수 있다.
• 페이로드는 암호화된 정보가 아니기 때문에, 민감한 정보를 담아서는 안된다.
• JWT의 경우 단일 키를 사용하기 때문에, 시크릿키가 유출되면 보안 취약 사항이 된다.

 

 

---

 

JWT 토큰

3가지로 구성되어있다.

• Header: 토큰의 타입과 서명 알고리즘 등의 정보를 담는다.
• Payload: 토큰 발급자, 유효 기간, 유저 정보 등의 데이터들을 정의하여 담는다.
• Verify Signature: 메시지가 전송 과정에서 해커 등을 통해 바뀌지 않았음을 인증하는 서명이다.

인코딩 된 결과에 각 구성 요소들은 . 으로 구분한다.