jwt

세션 기반 인증과 토큰 기반 인증(feat. 인증과 인가)

로드존슨 2023. 4. 12. 21:00
728x90

세션기반 인가와 토큰기반 인가에 대해 알아보기 이전에 먼저 인증과 인가가 무엇인지 알아야할 필요가 있다.

단어가 비슷해서 행위가 비슷할 수 있지만 그 뜻이 무엇인지 알아보자.

 

 

인증 과 인가는 요약하자면 시스템의 자원을 적절하고 유효한 사용자에게 전달하고 공개하는 방법


인증과 인가의 사전적 의미를 보자면 

 

인증 (authentication): 사용자가 자신이 주장하는 신원이나 정보의 진위여부를 확인하는 과정이다.

 

사전적의미는 와닿지는 않지만  쉽게 말하자면 내가 로그인 화면에서 id와 passwrod를 입력해서 제출을 하면 user1 이라는 것을 입증을 하게 된다. 이러한 행위 즉, 인증은 쉽게 말하자면  로그인 이다.

 

 

인가 (accreditation)인가는 인증 작업 이후에 행해지는 작업이며 사용자에게 특정 리소스나 기능에 엑세스 할 수 있는 권한을 부여하는 프로세스를 말한다.

 

인증은 사용자의 신원을 검증하는 행위  ,
인가는 요청한 리소스에 엑세스 할 수 있는 권한 

 

 

세션과 토큰을 애기해야 하는데 왜 인증, 인가를 애기하지??

이는 HTTP 비상태성(Stateless)  특성 때문이다. 

 

상태성과 비상태성의 차이
상태성: 매일 아침에 학교에 가기전에 집을 청소하고, 남은 청소작업을 다음날에 이어서 하는 것과 같이
             이전 상태와 관련된 정보를 계속 유지하는것 
비상태성: 매일 아침에 학교에 가기전에 집을 청소하고, 다음날에는 처음부터 다시 청소하는 것과 같이
             이전 상태와 관련된 정보를 유지하지 않고 각각의 작업이 독립적으로 처리되는 것

그렇다면 HTTP 프로토콜이 비상태성이어야 하는 이유는 무엇일까?

변경된 가장 큰 이유는 확장성과 간결성이다.

 

 

1.확장성 : 상태성 프로토콜에서는 서버가 각 클라이언트의 상태 정보를 유지해야 하므로, 클라이언트 수가 많아질수록 서버의 부하가 증가한다. 반면에 비상태성 프로토콜에서는 서버가 상태정보를 유지하지 않기 때문에, 서버의 확장성이 높아진다.

 

2.간결성 : 비상태성 프로토콜에서는 클라이언트와 서버간의 각각의 요청이 독립적으로 처리되고, 이전 요청과 상태를 유지 하지 않는다. 이로 인해 프로토콜이 간단하고 쉽게 구현될 수 있다. 또한 클라이언트와 서버간의 통신이 단순하고 명확해지므로, 개발자가 애플리케이션을 개발하고 유지보수하는 데에도 편리함을 제공한다.

 

비상태성 프로토콜은 서버의 부하를 줄이고 확장성을 향상시키는 등의 이점을 제공하므로 , 현대적인 웹 애플리케이션 개발에 많이 사용되고 있다. 또한 RESTful API 등의 웹 서비스 디자인에도 비상태성 프로토콜이 많이 활용되어 간결하고 확장 가능한 웹서비스를 구축할 수 있다.

 

 

HTTP 는  비상태성이라는 특성때문에  HTTP는 바로 직전에 발생한 통신을 기억하지 못한다. 따라서 HTTP 단독으로는 요청한 클라이언트가 이전에 이미 인증과정을 거쳤는지 알 수 없다. 

 

 

세션 기반인증은 인증 정보를 서버에 저장하는 방식이라면, 
토큰 기반 인증은 인증정보를 클라이언트가 직접 들고 있는 방식이다.

 

세션기반인증

 

https://hackernoon.com/using-session-cookies-vs-jwt-for-authentication-sd2v3vci

 

세션기반 인증은 사용자의 인증 정보가 서버의 세션 저장소에 저장되는 방식이다.

 

1.사용자가 로그인을 하면, 해당 인증 정보를 서버의 세션 저장소에 저장하고

2.사용자에게 저장된 세션 정보의 식별자인 Session ID를 발급한다.

3.발급된 Session ID는 브라우저에 쿠키 형태로 저장되지만 , 실제 인증 정보는 서버에 저장되어 있다.

4.브라우저는 인증절차를 마친 이후의 요청마다 HTTP Cookie 헤더에 Session ID를 함께 서버에 전송한다.

5.서버는 요청을 전달 받고 , Session ID 에 해당하는 세션 정보가 세션 저장소에 존재한다면 인증된 사용자로 판단한다.

 

 

 

토큰기반인증

https://hackernoon.com/using-session-cookies-vs-jwt-for-authentication-sd2v3vci

세션 기반 인증과 달리 토큰기반인증은 인증 정보를 클라이언트가 직접 들고 있는 방식이다.

이때 인증 정보가 토큰의 형태로 브라우저의 로컬 저장소(혹은 쿠키)에 저장된다. 대표적인 토큰인 경우 JWT가 있다.

 

토큰 기반 인증에서는 사용자가 가지고 있는 토큰을 HTTP의 Authorization 헤더에 실어 보낸다. 이 헤더를 수신 서버는 토큰이 위변조 되었거나, 만료 시각이 지나지 않은지 확인한 이후 토큰에 담겨있는 사용자 인증 정보를 확인해 사용자를 인증한다.

 

 

세션기반 인증 vs 토큰기반 인증

 

 

사이즈 

세션의 경우 Cookie 헤더에 세션 ID만 실어보내면 되므로 트랙픽을 적게 사용한다. 하지만 JWT는 사용자 인증정보와 토큰의 발급시각, 만료시각 등 정보가 세션 ID에 비해 비대하므로 세션 방식보다 훨씬 더 많은 네트워크 트래픽을 사용한다.

 

안전성과 보안문제

세션의 경우 모든 인증 정보를 서버에서 관리하기 때문에 보안 측면에서 조금 더 유리하다. 설령 세션 ID가 해커에게 탈취된다고 하더라도, 서버측에서 해당 세션을 무효처리하면 된다.

 

하지만 토큰의 경우 그렇지 않다. 토큰은 서버가 트래킹하지 않고, 클라이언트가 모든 인증정보를 가지고 있다.따라서 토큰이 한번 해커에게 탈취 되면 해당 토큰이 만료되기전까지는 속수무책으로 피해를 입을수 있다.

 

확장성

그럼에도불구하고 최근 모던 웹 어플리케이션이 토큰 기반 인증을 사용하는 이유가 바로 이 확장성이다. 

일반적으로 웹 어플리케이션의 서버 확장 방식은 수평 확장을 사용한다.

즉, 한대가 아닌 여러대의 서버가 요청을 처리하게 된다.

이때 별도의 작업을 해주지 않는다면, 세션기반 인증방식은 세션 불일치 문제를 겪게 된다.이를 해결하기 위해서 Sticky Session, Session Clustering, 세션 스토리지 외부 분리 등의 작업을 해주어야 한다.

 

하지만 토큰 기반 인증 방식의 경우 서버가 직접 인증 방식을 저장하지 않고 , 클라이언트가 저장하는 방식을 취하고 있기 때문에 이런 세션 불일치 문제로부터 자유롭다. 이런 특징으로 토큰 기반 인증 방식은 HTTP의 비상태성을 그대로 활용할 수 있고 따라서 높은 확장성을 가질수 있다.

 

서버의 부담

세션 기반 인증 방식은 서비스가 세션 데이터를 직접 저장하고, 관리한다. 따라서 세션 데이터의 양이 많아지면 많이질수록 서버의 부담이 증가할 것이다.

 

하지만 토큰 기반 인증 방식은 서버가 인증 데이터를 가지고 있는 대신, 클라이언트가 인증데이터를 직접 가지고 있다.

따라서 유저의 수가 얼마나 되던 서버의 부담이 증가하지 않는다. 따라서 서버의 부담 측면에서는 세션 기반 인증 방식보다는 토큰 기반 인증 방식이 조금 더 유리함을 알 수 있다.

 

 

https://www.okta.com/kr/identity-101/authentication-vs-authorization/

 

인증과 인가 (권한 부여) 비교 – 특징 및 차이점 | Okta Identity Korea

인증과 인가는 IAM 환경에서 명확히 구분되는 보안 프로세스로, 인증 (Authentication) 단계에서는 사용자의 신원을 확인하며, 인가 (Authorization) 단계에서는 신원이 확인된 사용자에게 리소스에 액세

www.okta.com

https://hudi.blog/session-based-auth-vs-token-based-auth/

728x90