Cookie 인증 쿠키는 Key-Value 형식의 문자열 덩어리이다. 클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일이다. 각 사용자마다의 브라우저에 정보를 저장하니 고유 정보 식별이 가능한 것이다.
Cookie 인증 방식
브라우저(클라이언트)가 서버에 요청(접속)을 보낸다.
서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다.
이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다.서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별하거나 정보를 바탕으로 추천 광고를 띄우거나 한다.
세션에 대해서
Session 인증 이러한 쿠키의 보안적인 이슈 때문에, 세션은 비밀번호 등 클라이언트의 민감한 인증 정보를 브라우저가 아닌 서버 측에 저장하고 관리합니다 서버의 메모리에 저장하기도 하고, 서버의 로컬 파일이나 데이터베이스에 저장하기도 한다. 핵심 골자는 민감한 정보는 클라이언트에 보내지말고 서버에서 모두 관리한다는 점이다.
세션 객체는 어떤 형태로 이루어져 있을까 ?
세션 객체는 Key에 해당하는 SESSION ID와 이에 대응하는 Value로 구성되어 있다.
Value에는 세션 생성 시간, 마지막 접근 시간 및 User가 저장한 속성 등 이 Map 형태로 저장된다.
Session 인증 방식
유저가 웹사이트에서 로그인하면 세션이 서버 메모리(혹은 데이터베이스) 상에 저장된다. 이때, 세션을 식별하기 위한 Session Id를 기준으로 정보를 저장한다.
서버에서 브라우저에 쿠키에다가 Session Id를 저장한다.
쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 쿠키에 담아 전송한다.
서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id를 비교하여 인증을 수행한다.
지금까지 Session은 메모리에서 관리되는줄 알았습니다. DB에도 저장이 되고 key-value 형태로 있는지 알게되었습니다. 기본적으로 ID 값만으로 인증을 유지하는 줄 알았습니다.
Session 방식의 단점
쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 개인정보를 담고 있지 않는다.그러나 해커가 세션 ID 자체를 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재한다. (이는 서버에서 IP특정을 통해 해결 할 수 있긴 하다)
서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다.
JWT (JSON Web Token)에 대해서
JWT(JSON Web Token)란인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다. 그리고 JWT 기반 인증은 JWT 토큰(Access Token)을HTTP 헤더에 실어서버가 클라이언트를 식별하는 방식이다
JWT는 JSON 데이터를Base64 URL-safe Encode를 통해 인코딩하여 직렬화(일자로 쭉)한 것이며, 토큰 내부에는 위변조 방지를 위해 개인키를 통한전자서명도 들어있다. 따라서 사용자가 JWT 를 서버로 전송하면서버는 서명을 검증하는 과정을 거치게 되며 검증이 완료되면 요청한 응답을 돌려준다.
Base64 URL-safe Encode란?
Base64 URL-safe Encode 는 일반적인 Base64 Encode 에서 URL 에서 오류없이 사용하도록 '+', '/' 를 각각 '-', '_' 로 표현한 것이다.
JWT 구조
JWT는 . 을 구분자로 나누어지는 세 가지 문자열의 조합이다. . 을 기준으로 좌측부터 Header, Payload, Signature를 의미한다.
Header에는 JWT 에서 사용할 타입과 해시 알고리즘의 종류가 담겨있습니다
Payload는 서버에서 첨부한 사용자 권한 정보와 데이터가 담겨있습니다.
Signature에는 Header, Payload 를 Base64 URL-safe Encode 를 한 이후 Header 에 명시된 해시함수를 적용하고, 개인키(Private Key)로 서명한 전자서명이 담겨있습니다.
전자서명에는비대칭 암호화 알고리즘을 사용하므로 암호화를 위한 키와 복호화를 위한 키가 다르다. 암호화(전자서명)에는 개인키를, 복호화(검증)에는 공개키를 사용한다.
JWT를 이용한 인증 과정
사용자가 ID, PW를 입력하여 서버에 로그인 인증을 요청한다.
서버에서 클라이언트로부터 인증 요청을 받으면, Header, PayLoad, Signature를 정의한다.Hedaer, PayLoad, Signature를 각각 Base64로 한 번 더 암호화하여 JWT를 생성하고 이를 쿠키에 담아 클라이언트에게 발급한다.
클라이언트는 서버로부터 받은 JWT를 로컬 스토리지에 저장한다. (쿠키나 다른 곳에 저장할 수도 있음)API를 서버에 요청할때Authorization header에 Access Token을 담아서 보낸다.
서버가 할 일은 클라이언트가 Header에 담아서 보낸 JWT가 내 서버에서 발행한 토큰인지 일치 여부를 확인하여 일치한다면 인증을 통과시켜주고 아니라면 통과시키지 않으면 된다.인증이 통과되었으므로 페이로드에 들어있는 유저의 정보들을 select해서 클라이언트에 돌려준다.
클라이언트가 서버에 요청을 했는데, 만일 액세스 토큰의 시간이 만료되면 클라이언트는 리프래시 토큰을 이용해서
서버로부터 새로운 엑세스 토큰을 발급 받는다.
캐시(cache)에 대해서
한 번 전송 받은 데이터를 저장해 놨다가 필요할 때 꺼내쓰기 쉽게 만든 구조입니다.
일반적으로 사용자 입장에서 가장 가까이 접하는 캐시는 브라우저 캐시입니다. 사용자가 컴퓨터나 스마트폰에서 인터넷 서핑할 때 받아온 데이터는 브라우저에 캐시 형태로 저장됩니다. 쿠키와 같이 캐시도 각 브라우저의 설정 화면에서 조작해 비울 수 있습니다. 캐시 덕분에 사용자는 같은 사이트를 다시 방문하거나 동영상을 다시 시청할 때 추가로 통신비를 지출하지 않고 로딩 없이 콘텐츠를 이용할 수 있습니다.
쿠키와 캐시의 차이 쿠키와 캐시 모두 정보를 저장하여 재활용하는 기술이지만, 쿠키는 사용자의 수고를 덜어주는 데 목적을 두고 캐시는 데이터의 전송량을 줄이고 서비스 이용 속도를 높이는 데 목적을 둡니다.
