https://hudi.blog/session-based-auth-vs-token-based-auth/
인증 : 쉽게 정의하자면 로그인 기능, 이게 없으면 네이버에서 메일이든 클라우드든 뭐든 누를때 마다 매번 ID,PW 입력해야 할 것
인가 : 로그인된 사용자가 가진 권한으로 어디까지 접근이 가능한지?
세션 기반 | 토큰 기반 | |
인증 정보 저장 위치 | 서버 | 클라이언트(쿠키 혹은 로컬 스토리지) |
쿠키 형태로 사용자에게 주는 정보 | 저장된 세션 정보 식별자인 Session ID | 인증된 사용자 증명을 위한 정보와, 최소한의 정보 포함 |
서버에서의 인증 방법 | 브라우저는 서버에 요청 시 HTTP Cookie 헤더에 Session ID를 함께 서버에 전송하고, 서버는 세션 정보 저장소에 해당 Session ID에 해당하는 세션 정보가 존재한다면 인증된 사용자로 판단 | 유저가 로그인을 하면 서버에서는 토큰을 생성한 뒤 저장하지(stateless) 않고 토큰값을 내려준다. 사용자는 가진 토큰을 HTTP Authorization 헤더에 넣어서 서버로 Request 하면, 서버는 토큰이 위변조 되었거나 만료 시각이 지난 토큰이 아닌지 확인 후 토큰에 있는 사용자 인증 정보를 확인해서 인가 토큰은 세션 ID와 달리 설명할 수 있는 데이터(user name같은) 값들을 포함한다. |
장점 | 서버에서 인증 정보 전부 관리하기에 보안에서 토큰 방식보다 우수함, 로그인된 상태의 지속성을 확인할 수 있음 ( 중복 로그인 시도 되었다고 튕기게 하는 기능, 동시 접속자수 제한 기능 구현 가능), Session ID는 사용자의 어떤 유의미한 정보를 포함하고 있는 값이 아니라, 서버에서 세션(사용자) 정보를 찾는 Key로만 활용하기 때문에 탈취당해도 토큰보다는 더 안전함. |
인증 정보 서버에서 관리할 필요 없기에 인증 기능 구현에 편리함, 세션이 필요하지 않거나 높은 보안이 필요하지 않은 서비스면 JWT가 효율성에서 유리 서버 분산&클러스터 환경에서 세션보다 확장성에 유리함 |
단점 | 서버에 세션(사용자) 정보를 저장할 공간이 필요하다. -> 서비스를 이용하는 사용자가 많다면 저장할 공간도 더 많이 필요하다. 분산 서버일때는 세션을 공유하는데 어려움이 있다. |
세션이 필요한 기능이나, 높은 보안이 필요한 서비스에서는 사용하지 못한다.(유저의 정보가 일부 포함되어 있기 때문) 한 번 발급한 토큰흔 회수가 어려움, 그래서 토큰 유효기간을 짧게 설정하여 사용 |
https://hudi.blog/self-made-jwt/
https://velog.io/@hahan/JWT%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80
'보안 > Security-인증' 카테고리의 다른 글
IAM Role 설명 (0) | 2024.03.17 |
---|---|
JWT의 구조 정리 (0) | 2023.07.30 |
Spring에서 JWT Token 사용하기 위한 설정 정리 (1) | 2022.11.20 |
Spring Security 페이지 권한 설정 방법 (authorization) (0) | 2022.11.20 |
댓글