1. HTTP 특성
1) 개념
-인터넷 상에서 데이터를 주고 받기 위한
서버/클라이언트 모델을 따르는 프로토콜
-비연결성 및 무상태성이라는 특징을 가지고 있음
:요청에 대한 응답을 처리하게 되면, 연결이 끊어져버리기에
클라이언트에 대한 이전의 상태 정보 및 현재 통신의 상태가 남아있지 않음
-하지만 서버는 클라이언트를 식별할 수 없어 문제점 또한 존재
:로그인을 하더라도 다음 요청에서는 해당 클라이언트를 기억하지 못해
새로고침을 진행할 경우 로그인이 유지되지 못함.
HTTP의 비연결성 및 무상태성 특징을 보완한 기술인 Cookie와 Session 덕분
*HTTP 구조
2)Stateless & Stateful
-네트워크 프로토콜
-세션 상태와 세션 정보에 관한 개념 이해 필요
(1) 세션 상태
-클라이언트와 서버간 통신 인증이 된 상태 의미
-인증된 상태에서 데이터 송수신 가능
(2) 세션 정보
-한 세션 내에서 클라이언트가 서버에 전송할 데이터 정보 의미
-서버는 세션 유지 시간이 지나거나, 클라언트가 전송하려했던 데이터를 모두 수신할 때까지
클라언트와 세션 상태 유지
① Stateful
-세션이 종료될 때까지,
클라이언트의 세션 정보를 저장하는 네트워크 프로토콜
② Stateless
-서버가 클라이언트의 세션상태 및 세션정보를 저장하지 않는
네트워크 프로토콜
-서버로 가는 모든 요청이 이전 리퀘스트와 독립적으로 다뤄진다는 뜻
(요청끼리 응답이 없음, 메모리가 없다)
-즉, 요청에 대한 응답만 처리하는 방식
-각 통신은 선행되거나 후속으로 따라오는 통신과 관련 없음
-클라이언트가 송신하려 했던 모든 데이터가 서버쪽에 수신되어 있는지 확인 X
2. Cookie
1) 개념
-사용자 정보를 브라우저에서 관리
-서버가 사용자의 위치에 정보를 저장하고 불어올 수 있는 수단
-구성 : 이름, 값, 만료날짜, 경로 정보
[쿠키 설명) 로그인]
-쿠키를 이용해서 서버는 너의 브라우저에 데이터를 넣을 수 있음.
응답에는 모든 데이터와 너가 찾던 페이지 정보가 있음.
브라우저에 쿠키를 저장한 후,
해당 웹 사이트를 방문할 때마다
브라우저는 해당 쿠키를 요청과 함께 보내게 됨.
쿠키는 도메인에 따라 제약이 됨, 유효기간 존재
인증뿐만 아니라, 여러가지 정보를 저장할 수 있음.
ex) 웹사이트 언어설정을 바꾸면 서버는 쿠키를 주고 선택한 언어 저장
-그저 세션 ID를 전달하기 위한 매개체
-브라우저에만 존재
2) 진행과정
-마지막으로 보낸 사용자의 request는
그 위의 response에서 받은 쿠키를 자동적으로 넣어 요청
이런 쿠키는 사용자(Client)에서 관리, 크롬 등 웹브라우저 설정으로 쿠키 지움
-또한 브라우저가 서버와 연결이 되었을 때,
서버측에서 쿠키가 존재하지 않을 경우 자동으로 쿠키 생성
(요청에 대한 데이터를 response할 때 그 쿠키와 같이 보냄)
그리고 그 이후 Client가 서버에 특정 요청을 보낼 때마다
따로 액션을 취하지 않아도 자동으로 그 쿠키 정보가 http 요청에 담겨 전송
3. Session
1) Session ID
-서버가 Client에 대해 유일한 ID를 부여하여 서버 측에서 관리
[세션 설명) 로그인]
-서버는 들어오는 쿠키를 보고,
세션 ID와 함께 오는 쿠키를 확인
아직까지 서버는 우리가 누구인지 모르지만
세션ID가 있는 쿠키를 지닌 요청이 있다는 것만 앎.
세션 ID를 가지고 세션 DB를 확인 후 서버가 누구인지 파악,
해당 요청이 끝나고 다른 페이지로 이동 이 모든 프로세스가 반복됨
-세션을 이용해 iOS, android 앱을 만들 수 있음
-현재 로그인한 유저들의 모든 세션 ID를 DB에 저장한다는 것
-세션에서는 세션 ID만 주면 됨,
세션에 대한 모든 정보는 세션 DB에 저장되어 있음
-요청이 있을 때마다 DB를 찾아야 함
- Server
중요한 유저 정보는 모두 서버에 있음
2) 개념
-클라이언트와 서버 간의 관계를 유지하기 위한 방법
-사용자의 정보 중 보안상 중요한 데이터 관리
-활성화 되었다는 의미
클라이언트와 서버가 서로 연결 되었을 때, 접속이 유지되는 것을 의미
4. Session / Cookie 인증 과정
1) 사용자 로그인 (request)
2) 서버에서 사용자의 정보를 확인
3) 사용자의 정보를 세션 저장소에 보관
4) 고유의 세션 ID를 생성 및 발급
5) 세션 ID를 담은 '쿠키' 정보를 사용자 로그인에 대한 response(응답) 보내기
-인증이 필요할 때마다 쿠키를 헤더에 담아 요청
6) 사용자 재접속 및 및 로그인 (request + 쿠키)
: 위에서 받은 쿠키 정보를 가지고 옴
7) 사용자가 준 쿠키를 세션 저장소에서 대조, 검증
8) 사용자의 요청을 담은 response
-주소를 직접 치고 들어가는 GET 요청 시, (서버 접속) 재로그인 할 필요 없을 때
-HTTP 프로토콜 header의 setCookie를 통해
브라우저의 쿠키에 세션 아이디 기록
-브라우저는 request 요청을 보낼 시
header에 cookie를 자동으로 포함하여 보내게 되고
<cors일 경우 credentials등 세팅필요>
서버에서는 cookie의 세션 아이디를 토대로 사용자의 로그인 등을 판별할 수 있음
*인증 정보를 포함하기 위한 cors 설정
https://developer.mozilla.org/ko/docs/Web/HTTP/CORS#%EC%9D%B8%EC%A6%9D%EC%A0%95%EB%B3%B4%EB%A5%BC_%ED%8F%AC%ED%95%A8%ED%95%9C_%EC%9A%94%EC%B2%AD
5. Token
1) 개념
-인증을 위해 사용되는 암호화 된 문자열
-특정 정보들을 해싱해서 Client와 Server를 왕복한다는 것
*해싱
-알고리즘과 암호 방식을 결합하면 다양한 방식으로 보안, 인증 가능
[토큰 설명) 로그인]
-네이티브 앱에 쿠키가 없어서 사용, 서버에 토큰을 보내는 것
-이상하게 생긴 string(문자열)
해당 토큰을 서버에 보내고
서버는 세션 DB에서 해당 토큰과 일치하는 유저를 찾음
2) 특징
(1) HTTP 통신의 Stateless 특징과 알맞음 (Session/Cookie 동일)
즉, 쿠키에 토큰을 담아 상태관계 유지
-Client가 토큰을 지니고 있으며
그 정보만을 가지고 연결 상태에 연연하지 않으며
Server는 확인 후 동일하면 Server에서 API 설계 가능
(2) 유저의 인증 정보를 Server 혹은 Session에 담아두지 않음
(3) 유저의 활성화 여부를 신경쓰지 않고
넘겨진 요청에 담겨진 Token의 정합성만 확인
-특정 요청에 대해서만
이 Token이 변형된건지 혹은 정상적인 것인지 확인 후 진행
(4) 서버에서 Client의 상태 정보를 저장하지 않고
Client로부터 전달받은 요청만으로 작업을 처리하는데,
이 경우 Client의 상태 관리에 대한 비용이 없기 때문에 Server 확장성이 높음
-만약 Session으로 관리했을 때,
로그인 요청 여부와 어디까지 요청을 했는지 가공하는 부분에서도 코드를 짜야 되기 때문에
비효율성 증대
-하지만, Token을 사용한다면 그냥 token의 정합성만 따지고
사용자에 관한 session 관리 코드를 짤 필요가 없음
그저 Token 확인 후 요청한 걸 db에 반환해주면 됨
-Express 사용시, 토큰 체킹하는 미들웨어만 앞에 넣어주기
*세션 토큰 자체 정보만으로 인증하면
보안자체가 취약해질 수 있는데
이 세션에 대해서 30분동안만 이용할 수 있게 하는 등의
세션 유지방법을 고안해야 함
6. JWT 기반 인증
1) 개념
-JWT(JSON Web Token)란
인증에 필요한 정보들을 암호화시킨 토큰
-JWT 기반 인증은 쿠키/세션 방식과 유사하게
JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트 식별
[JWT 설명) 로그인]
-유저가 늘어남에 따라 세션에서 더 많은 DB리소스가 필요해서 등장
-JWT로 유저인증을 처리하면,
세션 DB를 갖을 필요가 없고
서버는 유저 인증한다고 많은 일을 하지 않아도 됨
-서버에서 요청할 때마다 보내야하는 것
-쿠키는 길이에 제약이 있지만, JWT는 제약이 없어서 길어도 됨
-서버는 유저를 인증하는데 필요한 정보를 토큰에 저장,
그리고 해당토큰을 우리에게 줌,
페이지를 요청하면 서버는 해당 토큰이 유효한지만 검증
-암호화가 되지 않았기 때문에, 누구나 열어서 해당 컨텐츠를 볼 수 있음
2) 구조
-JWT는 '.'을 구분자로 나누어지는 세 가지 문자열의 조합
실제 디코딩된 JWT는 다음과 같은 구조를 지님
(1) Header
{
"alg" : "HS256"
"typ" : "JWT
}-'alg' 과 'typ' 는 각각 정보를 암호화할 해싱 알고리즘 및 토큰 타입 지정
(2) Payload
{
"sub" : "1234567890"
"name" : "John Doe"
"iat" : 1516239022
}-토큰에 담을 정보를 지니고 있음
-주로 클라이언트의 고유 ID 값 및 유효기간 등이 포함되는 영역
-key:value 형식으로 이루어진 한 쌍의 정보를 Claim이라 칭함
(3) Signature
-인코딩된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성
-Header & Payload) 단순히 인코딩된 값이기 때문에
제 3자가 복호화 및 조작 가능
Signature) 서버 측에서 관리하는 비밀키가 유출되지 않는 이상
복호화할 수 없음
-토큰의 위조 변조 여부를 확인하는데 사용
3) 인증과정
(1) 클라이언트 로그인 요청이 들어오면,
서버는 검증 후 클라이언트 고유 ID 등의 정보를 Payload에 담음
(2) 암호화할 비밀키를 사용해 Access Token(JWT) 발급
(3) 클라이언트는 전달받은 토큰을 저장해주도
서버에 요청할 때마다 토큰을 요청 헤더에 포함시켜 함께 전달
(4) 서버는 토큰의 Signature를 비밀키로 복호화한 다음,
위변조 여부 및 유효기간 등 확인
(5) 유효한 토큰이라면 요청에 응답
7. session & JWT 장.단점
1) Session
-로그인된 유저의 모든 정보 저장
해당 정보를 활용해서 새로운 기능들을 추가할 수 있음
ex) 특정 유저를 로그아웃 시키고 싶을 때, 세션 삭제
인스타그램의 로그인된 모든 디바이스 중 원하지 않는 디바이스를 강제 로그아웃 가능
넷플릭스처럼 계정 공유 숫자 제한 가능 (현재 로그인을 몇명이 했고 시청하는지)
+redis(Remote Dictionary Server의 약자)
='키-값' 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈소스 기반의 비관계형 DB 관리 시스템
2) JWT
-생성된 토큰을 추적하지 않음
-서버는 토큰의 유효여부만 알고 있음
-DB를 따로 구매할 필요는 없지만 강제 로그아웃은 진행할 수 없음
(해당 토큰이 만료되기 전까지는 가져올 수 있음)
-데이터를 사인하고 유저에게 보내고 해당 데이터를 돌려받을 때,
유효성 검증 가능 = DB 없이도 모든 것이 가능
ex) 카카오톡 QR코드
8. 공통점
-Web Authentication (인증)
