Auth
누가 요청을 보내는지 어떻게 구분할까?
- 컴퓨터 IP정보로는 한계가 있음.
- 한 컴퓨터로 여러명이서 사용 할 수 있음.
인증 ( Authentication )
- API 요청에 대해 사용 가능한 사용자인지를 확인하는 절차
- 클라이언트가 주장하는 사용자와 같은 사용자인지 확인
- 요청의 주체가 누구인지 알기위해 HTTP 메세지의 헤더에 인증 수단을 넣어 요청을 보내게 된다.
인가 ( Authorization )
- 사용자가 특정 자원에 대한 접근 권한이 있는지 체크
- 클라이언트가 하고자하는 작업이 해당 클라이언트에게 허가된 작업인지 확인
- 사용자의 권한 레벨에 따라 접근할 수 있는 부분 제한 기능
인증을 거친 후 인증을 거친 사용자에 대한 특정 권한을 부여
인증방법
- 쿠키
- 세션
- 토큰
HTTP 프로토콜의 특징, 약점을 보완하기 위해 이러한 방법을 사용한다. 비연결 지향 (Connectionless) : 클라이언트 request에 맞는 response를 보내고 접속을 끊음 상태 정보 유지 않함 ( Stateless ) : 통신이 끝나면 정보를 유지하지 않는다.
쿠키
- 요청에 대한 응답을 보낼 때 쿠키라는 것을 같이 보내줌
- 쿠키는 단순한 ’키-값’ 쌍 (id=genie) + 클라이언트 로컬에 저장됨
- 일정 시간 동안 저장할 수 있고 클라이언트 쪽에 300개까지 저장 가능 (하나의 쿠키 파일은 4KB까지 가능)
- 서버로부터 쿠키가 오면 웹 브라우저는 쿠키를 저장해두었다가 요청할 때마다 브라우저가 자동으로 쿠키 같이 보냄
- 서버는 미리 클라이언트에 요청자를 추정할 만한 정보를 쿠키로 만들어 보내고, 클라이언트를 쿠키를 받아 요청자 파악
- 쿠키는 요청과 응답의 헤더에 저장됨
세션
- 요청이 오면, 해당 서버 엔진이 클라이언트에게 유일한 ID인 “세션 ID” 부여
- 서버에 사용자 정보를 저장하고 클라이언트와는 세션 ID로만 통신
- 일정 시간 동안 같은 브라우저로 부터 들어오는 요청을 하나의 상태로 보고 그 상태 유지(웹 브라우저 종료할 때까지 유지)
- 클라이언트는 발급받은 세션 ID를 쿠키를 사용하여 저장
- 세션은 서버 메모리에 저장됨. 서버 재시작 되면(메모리 리셋) 세션 데이터 사라짐
- 세션은 서버의 자원을 사용하기 때문에 무분별하게 만들다 보면 서버의 메모리가 감당할 수 없어질 수가 있고 속도가 느려질 수 있음 (세션을 DB에 저장할 수 있지만 이 또한 DB 성능에 무리를 줌)
쿠키 vs 세션
세션은 서버에서 가지고 있는 정보이며 쿠키는 사용자에게 발급된 세션을 열기 위한 열쇠(SESSION ID)를 의미합니다. 쿠키만으로 인증을 사용한다는 말은 서버의 자원은 사용하지 않는다는 것이며, 이는 즉 클라이언트가 인증 정보를 책임지게 됩니다. 그렇게 되면 위의 첫번째 방식처럼 HTTP 요청을 탈취당할 경우 다 털리게 됩니다. 따라서 보안과는 상관없는 단순히 장바구니나 자동로그인 설정 같은 경우에는 유용하게 쓰입니다. 결과적으로 인증의 책임을 서버가 지게하기 위해 세션을 사용하는 겁니다(사용자가 해킹당하는 것보단 서버가 해킹당하는게 훨씬 어려우니까요!) 사용자(클라이언트)는 쿠키를 이용하고, 서버에서는 쿠키를 받아 세션의 정보를 접근하는 방식으로 인증을 합니다.
