인증과 인가
인증
- 사용자의 신원을 검증하는 행위
ex) 로그인, 아이디와 패스워드를 서버로 전송하면 서버에서는 유저가 맞는지 검증하는 과정을 거치게 된다.
인가
- 인증된 사용자에 대해 권한을 부여하는 것
ex) 로그인된 사용자는 글 작성,수정,삭제 등의 권한이 부여된다.
세션기반 인증
사용자가 로그인을 하면, 인증정보를 서버의 세션저장소에 저장하고, 인증정보를 식별하는 Session ID를 발급한다. Session ID는 쿠키에 담겨 브라우저에 전달된다.
인증 절차를 마친 후(로그인된 상태), 요청마다 HTTP Cookie 헤더에 Session ID를 포함해 서버로 전송한다. 서버는 Session ID를 인증하고 인증된 사용자는 다시 Session ID가 쿠키에 담겨 브라우저로 전달된다.
토큰기반 인증
사용자가 로그인을 하면, 서버에서는 개인정보를 포함하여 암호화시킨 토큰을 생성하고 토큰을 브라우저로 전달한다. 토큰은 브라우저에서 로컬 스토리지, 또는 쿠키에 저장될 수 있다.
인증 절차를 마친 후(로그인된 상태), 요청마다 토큰을 HTTP의 Authorization 헤더에 넣어 보낸다.
서버에서는 토큰이 위변조 되었거나, 만료 시간이 지나면 토큰을 보내지 않아 인가하지않고, 인증에 성공하면 토큰값을 보내 사용자를 인가한다.
세션기반 인증 vs 토큰기반 인증
사이즈 : 세션 < 토큰
- Session ID에 비해 토큰이 용량이 훨씬 크기 때문에 값을 주고받는 과정에서 더 많은 네트워크 트래픽을 사용하게 된다. -> 요청이 많은 경우 응답속도가 느려질 수 있다.
보안 : 세션 > 토큰
- 세션 인증방식은 인증정보를 서버에서 관리하고 있기 대문에 Session ID가해커에게 탈취되어도 해당 세션을 무효화 시키면 된다.
- 반면에 토큰 인증방식은 토큰이 인증정보를 가지고 있고, 토큰을 클라이언트가 가지고 있기 때문에 해커에게 탈취되었을 때 피해를 입게 된다.
- 특히 JWT를 사용하는 경우 Payload에 개인을 식별하기 위한 정보를 기입하게 되는데, Payload는 별도로 암호화 되어있지 않기 때문에 민감한 데이터를 실어서는 안된다. 즉, 세션에 비해 인증정보에 실을 수 있는 데이터가 제한된다.
서버부담 : 세션 < 토큰
- 세션 인증방식은 인증정보를 서버에서 보관하기 때문에 사용자가 많아질수록 서버에 부하를 주게 된다.
- 반면에 토큰 인증방식은 클라이언트가 인증정보를 보관하기 때문에 사용자가 많아져도 세션에 비해 서버에 부담이 증가하지 않는다.
- 세션 인증방식의 단점을 보완하기 위해 세션정보를 Redis와 같은 별도의 저장공간을 활용하여 관리할수있다.
확장성
일반적으로 웹 어플리케이션은 서비스가 커지면서 여러대의 서버가 요청을 처리하게 된다. 이 때 세션인증방식은 별도의 작업을 해주지 않으면 세션정보를 가지고 있는 서버는 하나이기 때문에 세션 불일치 문제를 겪게 된다. 이를 해결하는 방법으로는 Sticky Session, Session Clustering, 세션 스토리지 외부 분리 등이 있다. 반변에 토큰 인증방식은 클라이언트가 정보를 보관하기 때문에 불일치 문제에서 자유롭다.
rkdghwnd's dev story