수업 33일차
CRUD를 공부하면서 머리에 무엇인가를 넣고있지만 저장되지는 않는 느낌이다. ㅜ
이론
- 양방향 암호화: 다시 복호화 할수 있는 암호화 방식
단방향 암호화: 암호화 하면 다시 복호화 할수 없는 방식
bcrypt: 비밀번호 암호화
cookie: 클라이언트에 저장되는 데이터 파일
session: 서버에서 관리하는 쿠키 같은 개념
JWT: 인증에 필요한 정보들을 암호화 시킨 토큰
passport: 손쉽게 인증방법을 사용할수 있는 미들웨어
쿠키
서버가 클라이언트에 데이터를 저장할 수 있다. ((Key : Value)작은 데이터 조각)
서버는 쿠키를 이용하여 데이터를 저장하고 원할때 이 데이터를 다시 불러올 수 있다.
- 서버는 인증정보를 담은 쿠키를 클라이언트에게 전달
클라이언트는 전달받은 쿠키를 요청과 같이 서버에 전달
클라이언트와 서버는 연결된다.
쿠키는 오래 유지되고, 인증정보를 탈취하면 매우 위험해질 수 있다.
따라서 민감정보는 넣지 않는다.
HTTP Reponse Header 에 Set-Cookie 속성을 이용하여 클라이언트에 쿠키를 제공한다.
쿠키의 사용 이유
http는 stateless 웹사이트는 유저와 항상 연결되어 있지 않다.
보통 유저가 웹사이트에 방문하여 서버로 요청을 보내면 잠시 웹사이트와 유저가 연결된다. 이때 서버는 요청받은 것을 응답으로 전해주고 연결이 종료된다.
하지만, 유저의 정보가 저장되어야 하는 경우가 있다.
저장을 위해 존재하는 것이 cookie
쿠키 사용처
- 세션 관리(Session management)
서버에 저장해야 할 로그인, 장바구니, 게임 스코어 등의 정보 관리 - 개인화(Personalization)
사용자 선호, 테마 등의 세팅 - 트래킹(Tracking)
사용자 행동을 기록하고 분석하는 용도
1. 클라이언트가 서버에 요청한다.
2. 서버에서 쿠키를 생성하고, 쿠키를 HTTP Header에 실어 보낸다
3. 서버에서 쿠키를 확인하고, 요청 + 쿠키 를 보낸다.
4. 서버에서 쿠키를 확인하고(인증을 확인) ct에 응답을 보낸다.
5. 브라우저가 종료되어도 쿠키가 만료전이라면 ct는 쿠키를 보관한다.
session
쿠키와 달리 웹서버에 데이터들이 객체 형식으로 저장된다.
브라우저를 닫거나, 서버에서 세션을 삭제했을때만 삭제가 되므로,쿠키보다 비교적 보안이 좋다.
저장 데이터에 제한이 없다.
각 클라이언트 고유 Session ID(식별자)를 부여한다.
Session ID로 클라이언트를 구분하여 각 클라이언트 요구에 맞는 서비스 제공한다.
⇒ 사용자의 컴퓨터에는 session ID만 저장되고 나머지는 서버에 저장된다.
session 사용방법
express 에서 세션 사용 방법 : express-session 미들웨어 사용
다운로드 방법 : npm install express-session —save
var express = require('express');
var session = require('express-session');
var app = express();
var port = 3000;
app.use(session({
secret: 'any', // 보안을 위한 키
resave: false, //권장값
saveUninitialized: true //권장값
}))
app.get('/count', function(req,res){
if(req.session.count){
req.session.count++;
} else {
req.session.count=1; // session 객체에 새로운 데이터 추가
}
res.send('count : '+req.session.count);
})
app.listen(port,function(){
console.log(port+'번 포트에 연결되었습니다!');
})Json Web Token
JSON 객체를 통해 가볍고 자가 수용적인 방식으로 정보를 전달하는 웹 표준
자가 수용적(self-contationed): 필요한 정보를 자체적으로 갖고 있다.
디지털 서명되어 확인하고 신뢰할 수 있다.
두 개체 사이에서 쉽게 전달될 수 있다.
Authorization
JWT를 사용하는 가장 큰 이유
클라이언트에서 보내오는 토큰 검증만 하면되기에 서버 자원을 아낄 수 있다.
사용자가 성공적으로 로그인한 경우, JWT가 반환된다.
토큰은 자격 증명이므로 보안 문제 방지를 위해 필요 이상으로 오래 보관하지 않으며, 비밀 정보를 포함하지 않는다.
클라이언트는 일반적으로 Request Header의Authorization에 Bearer를 사용해서 JWT를 전달한다.
Authorization: Bearer <token>
구조
header.payload.signature
각 요소들이 .으로 구분되어 나타난다.
Header
검증 방법에 대한 내용 포함
-
type
토큰 타입 -
algorithm
해싱 알고리즘(토큰 검증)
{
"alg": "HS256",
"typ": "JWT"
}Payload
토큰에 담을 정보
여러 클레임들을 포함한다.
-
claims
엔티티 및 추가 데이터에 대한 설명 (정보의 한 조각)
key/value 구조 -
registered claim
필수는 아니지만 권장되는 미리 등록된 클레임
iss, sub, aud, exp, nbf, iat, jti, ... -
public claim
층돌을 방지하는 방법
-IANA JSON Web Token Registry에서 정의
-충돌 방지 네임스페이스를 포함하는 URI로 정의 (주로 사용하는 방법) -
private claim
클라이언트와 서버간의 협의하에 사용되는 클레임
사용자 정의 클레임 -
Signature
헤더의 인코딩 값, 페이로드의 인코딩 값을 합친 후 비밀키로 해쉬를 하여 생성된 값
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)```