Session
- 서버가 클라이언트에 유일하고 암호화된 ID를 부여
- 중요 데이터는 서버에서 관리
Session-based Authentication
서버는 아이디 및 비밀번호의 해시를 이미 알고있다면 매번 로그인할 필요가 없습니다.
쿠키와 세션의 차이
-
쿠키: http의 stateless 한 것을 보완해주는 도구, 클라이언트에 저장, 서버에 부담을 덜어주고 쿠키는 인증이 아니다.
-
세션: 접속 상태를 서버가 가지고, 서버에 저장, 신뢰할 수 있는 유저인지 서버에서 추가로 확인, 하나의 서버에서 접속 상태를 가지고 분산에 불리하다.
인증에 따라 리소스 접근 권한이 달라집니다.
- 서버는 사용자가 인증에 성공했음을 알고 있어야 합니다.
- 클라이언트는 인증 성공을 증명할 수단을 갖고 있어야 합니다.
(사용자가 인증에 성공한 상태를 세션 이라고 합니다.)
서버는 일종의 저장소에 세션을 저장합니다. 주로 in-memory, 또는 세션 스토어에 저장합니다.
세션이 만들어지면, 각 세션을 구분할 수 있는 세션 아이디도 만들어지는데 클라이언트에 세션 성공을 증명할 수단으로서 세션 아이디를 전달합니다.
웹사이트에서 로그인을 유지하기 위한 수단으로 쿠키를 사용합니다. 쿠키에는 서버에서 발급한 세션 아이디를 저장합니다. (쿠키에 세션 아이디 정보가 없거나 만료된 경우, 서버는 해당 요청이 인증되지 않음을 알려준다.)
로그아웃
세션 아이디가 담긴 쿠키는 클라이언트에 저장되어 있으며, 서버는 세션을 저장하고 있습니다.(서버는 세션 아이디로만 요청을 판단합니다.)
- 서버의 세션 정보를 삭제해야 합니다.
- 클라이언트의 쿠키를 갱신합니다.
서버가 클라이언트의 쿠키를 임의로 삭제할 수 없지만, set-cookie로 세션 아이디의 키값을 무효한 값으로 변경은 할 수 있습니다.
express-session
express-session은 세션을 관리해주는 모듈입니다.
세션을 위한 미들웨어, 세션을 쉽게 만들어준다.
필요한 경우 세션 아이디를 쿠키에 저장하고, 해당 세션 아이디에 종속되는 고유한 세션 객체를 서버 메모리에 저장합니다. 세션 객체는 서로 독립적인 객체이므로 각각 다른 데이터를 저장할 수 있습니다.
req.session이 세션 객체이며, 세션 데이터를 저장하거나 불러오기 위해 사용합니다.
- 세션 객체에 값을 담는 법
- 세션 객체 값을 불러오는 법
- 세션을 파괴하는 법
CSRF
다른 사이트(Cross-Site)에서 유저가 보내는 요청(Request)을 조작(Forgery) 하는 것
CSRF 공격을 하기 위한 조건
-
쿠키를 사용한 로그인
-
예측할 수 있는 요청/parameter를 가지고 있어야 한다.
CSRF 막는 방법
-
CSRF 토큰 사용하기
서버측에서 CSRF 공격을 보호하기 위한 문자열을 유저의 브라우저와 웹앱에 제공 -
Same-Site Cookie 사용하기
같은 도메인에서 세션/쿠키 사용할 수 있다.
Web Application Security란?
- 개발자들이 웹 사이트, 모바일 어플, 웹API 등을 만들 때 해커들의 공격을 막기 위해 Security 필수 사항이다.
Token-based Authentication
세션 기반 인증이 서버에 유저 정보를 담는 인증 방식이라면, 토큰 기반 인증은 클라이언트에서 인증 정보를 보관하는 방법입니다.
토큰은 유저 정보를 암호화한 상태로 담을 수 있고, 암호화했기 때문에 클라이언트에 담을 수 있습니다.
토큰 기반 인증을 사용하는 이유
- 세션 기반 인증 = 서버에 유저 정보를 담는 방식
- "서버 부담을 클라이언트에게 전가"
- 대표적인 토큰 기반 인증 = JWT(JSON Web Token)
JWT(JSON Web Token)
- Access Token
- Refresh Token
Access Token은 보호된 정보(유저의 이메일, 연락처, 사진)들에 접근할 수 있는 권한 부여를 사용합니다. 보안을 위해 비교적 짧은 유효 기간을 부여합니다. 따라서 Refresh Token이 존재합니다.
그럼에도 불구하고 Refresh Token의 탈취문제가 있기 때문에 Refresh Token을 사용하지 않는 곳도 존재합니다.
- Header
- 어떤 종류의 토큰인가?
ex)
{"alg": "HS256", "typ": "JWT"}- Payload
- 정보, 권한, 기타 필요한 정보 등 (민감한 정보는 넣지 말자.)
ex)
{
"sub": "SomeInformation",
"name": "Phillip",
"iat": 151623391
}- Signature
- Header, Payload를 인코딩한 결과 (Salt 값의 조합으로 암호화된 값)
HMASHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)토큰 기반 인증 절차
- 클라이언트가 데이터를 담아 서버에 요청을 보낸다.
- 서버는 데이터가 맞는지 확인 후 암호화 된 토큰을 생성한다.
- JWT Token 생성 후 클라이언트에 전달
(클라이언트는 로컬 스토리지 등 다양한 공간에 저장한다.) - 클라이언트는 JWT Token과 데이터를 담아 서버에 요청한다.
- 서버는 JWT Token 해독 후 맞는 경우 그에 따른 응답을 클라이언트에 보내준다.
토큰 기반 인증의 장점
-
무상태성 & 확장성
서버는 클라이언트에 대한 정보를 저장할 필요가 없다. 서버의 부담이 줄어든다. -
안정성
암호화 한 토큰을 사용한다. -
어디서나 생성 가능
토큰을 생성하는 서버가 꼭 토큰을 만들지 않아도 된다. -
권한 부여
토큰의 payload 안에 어떤 정보에 접근 가능한지, 권한을 부여할 수 있다.
