인증(Authentication)
클라이언트가 서버로부터 인증(Authentication)을 받기 위해서는 HTTP 요청 헤더필드에 인증 정보를 포함하여 보내야한다. 만약 서버에 존재하지 않는 사용자라면 서버는 401(Unauthorized) 응답을 한다.
HTML 내부에 document.cookie 를 넣어 간단한 인증정보 확인해보거나 <meta http-equiv="Set-Cookie" content="키=값(ex : 사용자ID)" > 태그 안에 넣어서 확인해볼 수 있다.
HTTP 서버 요청을 통해 확인하고자 한다면 response.writeHead(200, { "Set-Cookie": ["키=값(ex : 사용자ID)"] }); 나 response.setHeader('Set-Cookie', '키=값(ex : 사용자ID)') 를 통해서도 가능하다.
writeHead와 setHeader의 차이
setHeader는 단일 헤더값에 대한 세팅이고,
writeHead는 다중 헤더값을 설정할 때 사용할 수 있다.
참조 : Difference between response.setHeader and response.writeHead?
다만 이 경우, 보안 위험이 존재하기 때문에 등장하게 되는 것이 "암호화(Encryption)" 이다. 암호화는 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환하여, 해당방식에 대한 정보를 소유자 외에는 이해할 수 없다록 알고리즘을 이용해 정보를 관리하는 과정이다. 이러한 일은 해싱을 통해 진행할 수 있다.
해싱(Hashing) 이란 어떠한 문자열에 '임의의 연산'을 적용하여 다른 문자열로 변환하는 것인데, 제3자로부터 받을 수 있는 위협을 방지하게 된다. 해싱을 한다면 3가지 규칙이 존재한다.
- 모든 값에 대해 해시 값을 계산하는데 오래 걸리지 않아야 한다.
- 최대한 해시 값을 피해야하며, 모든 값은 고유한 해시 값을 가진다.
- 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야한다.
하지만 이러한 해싱(암호화)과정에서도 제3자가 그 해싱 기법 혹은 해싱 알고리즘을 알고 있어서 복호화를 할 수 있다면, 무용지물인 셈이다.
이러한 일을 어렵게 하기 위해 "Salt"가 등장한다.
Salt 는 해시하려는 값(원본)에 추가하는 값으로 해싱의 복호화를 어렵게 만들어주기 위해 '첨가'되는 것이다. 기존 암호화하려는 값이 곧바로 '해싱 값'으로 나오는 것을 salt 값을 더해서 추측할 수 없게 하는 것이다.
//기존 암호화
ID : 'kimcoding' => 해싱값 : 'zisndeq'
//slat가 더해진 암호화
let salt = 'eiwlsdkjf'
ID : 'kimcoding' + salt => 해싱값 : 'zisndeqeiwlsdkjf`위처럼 원본값에 임의로 약속된 추가 문자열을 추가하여 해시를 진행하여 기존 해시값과 전혀 다른 해시 값이 반환되어 알고리즘이 노출 되더라도 원본 값을 보호할 수 있도록 하는 안전장치라고 보면 된다.
참조사이트
HTTP 인증 - MDN
쿠키, 세션, 토큰
Cookie
쿠키(Cookie)는 사용자의 정보를 사용자 메모리(브라우저)에 관리하는 것으로 사용자 즉, 클라이언트가 관리하는 정보이다.
- 특정 호스트에서 생성된 쿠키는 이후 모든 요청마다 서버로 재전송
- 이름, 값, 만료날짜, 경로 정보로 구성
쿠키는 사용자가 임의로 수정/삭제가 가능하고, 해킹될 수 있는 위험이 존재한다. 내가 가진 비밀번호, 숨기고 싶은 구매내역 등은 개인이 보관하고 있기에는 위험하니 이를 관리 하기 위해서 등장한 것이 "세션(Session)"이다.
Session
세션(Session)은 서버에서 관리를 진행하는데, 위에서 언급한 비밀번호 등 사용자 정보 중 보안상 중요한 데이터를 관리하는 역할이다.
클라이언트에서 쿠키를 서버로 보내면, 서버는 쿠키를 통해 인증 정보를 확인한 후 일치하는 쿠키가 존재하면 클라이언트에게 세션을 부여한다.(credentials)
다만 쿠키/세션에 담을 정보를 잘 구분해줘야한다. 세션에 너무 많은 정보를 담으면 접속자가 많을 때, 서버 부하가 걸린다.
- 서버가 Client에 대해 유일한 ID를 부여하여 서버 측에서 관리
- 일반적으로 이 유일한 Client ID가 서버에서 존재하는 상황을 Session이라고 칭함
- 각 Client ID의 Session 객체 마다 Data를 관리 할 수 있음
그래서 이 둘의 차이는?
쿠키는 서버와 클라이언트가 대화하기 위한 수단이고, 세션은 서버와 클라이언트가 쿠키 인증 여부를 통해 "연결하냐 마냐"를 결정하는 상태이다. 클라이언트가 서버로 쿠키를 보내면 고유한 세션ID를 부여하여 클라이언트 쿠키에 세션ID를 붙여서 보낸다. 이를 통해 알 수 있는 것은 세션ID는 서버/클라이언트 모두 보유한다는 것이다. 접속 종료나 클라이언트가 이 쿠키를 강제삭제하게 되면 서버에 다시 재요청을 해서 새로운 세션ID를 부여받아야한다.
Token = Hashing
토큰(Token)은 해싱작업으로 인증을 위해 사용되는 암호화된 문자열이다.
- Http 통신의 Stateless 특징과 알맞다 = 유저의 상태를 관리할 필요가 없어서 stateless
- 유저의 인증 정보를 서버나 세션에 담아두지 않음
- 유저의 활성화 여부를 신경쓰지 않고 넘겨진 요청에 담겨진 Token의 정합성만을 확인
- 서버에서 클라이언트의 상태 정보를 저장하지 않고 클라이언트에서 넘겨지는 요청만으로 작업을 처리하게 되는데 이런 경우 클라이언트 상태관리에 관한 비용이 없기 때문에 서버의 확장성이 높음
참조사이트
HTTP 헤더 관련
RESTful API 설계 가이드
HTTP 헤더의 이해
알아둬야 할 HTTP 쿠키 & 캐시 헤더-제로초
[HTTP] 쿠키와 세션
메타태그 / 메타태그 - HTTP Message headers(위키)
nodejs-Header
그외
cookie & session & token
Cookie SameSite설정하기
HTTPS와 SSL 인증서, 그리고 SHA1 알고리즘
[Node.js] 회원가입&로그인(2) - 로그인 + 쿠키, 세션
[Nodejs] 쿠키(Cookie) 사용하기
[Node.js] Session & Cookie
Crypto (nodejs 내장 암호화 모듈) - 공식문서
