[SpringBoot] Cookie / Session / JWT

[인증과 인가]

• 이번 포스팅에서는 웹 어플리케이션의 인증 방식에 대해서 몇 가지 알아보고자 합니다.
• 인증 방식을 알아가기에 앞서 인증과 인가가 무엇인지, 웹 어플리케이션 인증에는 어떤 특수성이 있는지 살펴봅시다.
• 인증이란 해당 사용자가 실제 사용자인지 인증하는 개념으로써, 사용자의 신원을 검증하는 프로세스다. 우리가 흔히 접하는 ID와 비밀번호로 로그인을 하는 동작들이 인증에 해당된다.
• 인가는 인증 이후에 프로세스로, 인증된 사용자가 어떠한 자원에 접근할 수 있는지 확인하는 절차다. 흔히 웹 어플리케이션에서 관리자에게 부여되는 권라자 권한이 인가에 해당된다.

 

[웹 어플리케이션 인증의 특수성]

• 일반적으로 서버와 클라이언트 구조로 되어있다.
• HTTP 프로토콜을 이용하여 통신하기 때문에 비연결성과 무상태의 특징을 지닌다.
• 비연결성은 서버와 클라이언트가 연결되어 있지 않다는 뜻으로, 만약 서버와 클라이언트가 계속 연결되어 있다면 서버의 비용이 기하급수적으로 늘어난다.
• 리소스의 절약을 위해서 서버는 하나의 요청에 하나의 응답을 보내고 연결을 끊는 특징을 가지고있다.
• 무상태는 서버가 클라이언트의 이전 상태를 저장하지 않는다는 뜻으로, 클라이언트가 직전에 무슨 요청을 보냈는 지 알 수가 없다.
• 기존의 상태를 저장하는 것은 서버의 비용과 부담을 증가시키기 때문에 기존의 상태가 없다고 가정하는 프로토콜을 구현한다.

 

[쿠키(Cookie)]

• 쿠키는 사용자가 웹 어플리케이션에 접속 시 사용자의 개인 장치에 다운로드되고 클라이언트(브라우저)에 저장되는 작은 텍스트 파일이다.
• 브라우저는 서버에서 받은 쿠키를 저장했다가, 동일한 서버로 재요청할 때 쿠키를 함께 전송한다.
• 사용자가 로그인을 하면, 서버는 ID와 PW 정보를 쿠키를 담아 브라우저로 다시 보내고, 브라우저에서는 요청할 때마다 로그인 정보가 담긴 쿠키를 함께 서버로 보낸다.
• 브라우저에서 매번 요청을 할 때마다 서버 입장에서는 로그인 정보가 담긴 쿠키를 담게 되는 것이다.
• 쿠키의 장점은 기존 로그인 정보를 그대로 사용하기 때문에 인증을 위한 추가적인 데이터 저장이 필요가 없다는 것이다.
• 쿠키의 단점은 사용자의 주요 정보를 매번 요청에 담기 때문에 보안상 문제가 있으며, 브라우저에서 쿠키 정보를 쉽게 변경, 삭제할 수 있고 가로채기를 당할 수도 있다.

 

[세션(Session)]

• 세션은 일정 시간동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술이다.
• 쿠키는 사용자의 정보를 컴퓨터의 메모리, 브라우저에 저장하지만 세션은 서버측에 저장한다.
• 서버에서 생성한 세션 ID는 클라이언트의 쿠키 값으로 저장되고, 클라이언트에서 요청을 보낼 때 이 세션 쿠키를 함께 보낸다.
• 서버에서는 클라이언트별로 세션 쿠키 값이 저장되어 있기 때문에 요청으로 온 세션 쿠키 값을 보고 어떤 클라이언트인지 식별할 수 있다.
• 세션의 장점은 사용자의 로그인 정보를 주고 받지 않기 때문에 쿠키에 비해 상대적으로 보안상 안전하며, 사용자마다 고유한 세션 ID가 발급되기 때문에 요청이 들어올 때마다 회원 DB를 찾지 않아도 된다.
• 세션의 단점은 사용자를 식별할 수 있는 값인 세션 ID를 생성하고, 서버에 저장해야하는 작업이 생겨, 요청이 많아지면 서버 부하가 심해질 수도 있다.

세션 인증 방식 (출처 : https://tansfil.tistory.com/58)

 

[JWT]

• JWT는 JSON Web Token의 줄임말로써 JSON 객체로 정보를 주고 받을 때, 안정하게 전송하기 위한 방식이다.
• HMAC, RSA 등의 암호화 방식을 사용하여 서명하고 로그인 기능 구현 등에 자주 사용된다.
• JWT 토큰(Access Token)을 HTTP 헤더에 담아 서버가 클라이언트를 식별한다.
• JWT는 Header, Payload, Signature로 이루어져 있으며 각각 점으로 구분된다.

 

• Header는 토큰 타입, 해쉬 알고리즘(HS256 또는 RSA 등)으로 구성되어 있다.
• Payload는 claim이 포함되는 영역으로, 토큰에 담을 정보를 갖고 있고, 클라이언트 고유 ID값이나 유효 기간 등이 포함되는 영역이다.
• 여기서 말하는 claim은 key-value형식으로 이루어진 한 쌍의 정보로, 엔티티에 대한 속성을 설명한다.
• Signature는 인코딩된 Header와 Payload를 더한 다음, secret key로 해싱해서 생성한다. 이 때, 해싱 방법은 Header에서 지정한 해쉬 알고리즘 방법으로 진행한다.
• Header와 Payload는 단순히 인코딩된 값이여서 누구든 복호화가 가능하나, Signature는 서버 측에서 관리하는 secret key가 있어야만 복호화가 가능하다.
• Signature 부분을 통해 토큰의 위변조 여부도 파악할 수 있다.  

JWT 구조

 

• JWT 인증 방식 순서는 다음과 같다.
• 클라이언트가 ID, PW를 이용하여 로그인 요청을 서버에게 보낸다.
• 회원 DB에서 사용자를 확인하고, 로그인이 성공했을 때 서버는 로그인 정보를 Payload에 담고 Secret key를 사용해서 Access Token(JWT)을 발급한다.
• 서버가 JWT를 클라이언트에게 전달하는데 이 때, 전달방법은 개발자가 정한다.
• 클라이언트는 전달받은 토큰을 저장하고, 클라이언트가 서버에 요청할 때마다 토큰을 요청 Header에 Authorization에 포함시켜 함께 전달한다.
• 서버는 클라이언트가 전달한 토큰의 Signature를 Secret key로 복호화한 후, 위변조 여부 및 유효기간을 검증한다.
• 토큰 검증에 성공하면 JWT에서 사용자 정보를 확인하고 요청에 응답한다.
• JWT의 장점은 동시 접속자가 많을 때 서버 부하를 낮출 수 있고, 클라이언트와 서버가 다른 도메인을 사용할 때 사용이 가능하다. 또한 인증 정보를 서버에 별도로 저장할 필요가 없다.
• JWT의 단점은 구현 복잡도가 증가하고, JWT에 담는 내용이 커질수록 네트워크 비용이 증가하게 된다.
• 또한 이미 생성된 JWT를 일부만 만료시킬 방법이 없다. 다시 말해 유효기간을 너무 길게 잡으면 안되고, Secret key가 유출됐을 때 JWT 조작이 가능하다.

JWT 인증 방식 (출처 : https://tansfil.tistory.com/58)