[TIL] Week 6 유효성 검사와 JWT

🪜 next()

const validate = (req, res) => {
    const err = validationResult(req)

    if (!err.isEmpty()) {
        return res.status(400).json(err.array()) 
    }
}

지난번 유효성 검사를 추가하면서 에러가 난 경우의 로직을 모듈로 분리시켰는데

에러가 나지 않을 경우 무한 로딩 상태에 빠지고 말았다.

 

express입장에서는 validate에서 최종 응답을 해주는게 아닌가?라고 생각할 수 있기 때문에

최종 응답하는 곳이 아니라면 다음으로 넘어가라고 안내해주어야 한다.

 

express의 매개변수로 올 수 있는 것에는 req, res말고 next도 존재한다. 

 

const validate = (req, res, next) => {
    const err = validationResult(req)

    if (err.isEmpty()) {
     	return next(); // 다음 할 일(미들 웨어, 함수)로 이동
    } else {
        return res.status(400).json(err.array()) 
    }
}

매개변수에 next를 추가해주고 에러가 없다면 넘어가도록 해주었다.

 

validate 미들웨어 : 최종 응답을 보내는 역할 X  👉🏻 next() 호출해 다음 단계 진행
http Method : 최종 응답을 직접 보내는 곳 👉🏻 굳이 next()로 넘길 필요 X 

 

🔐 JWT

로그인을 하는 곳에서 종종 "세션이 만료되었습니다." 라는 문구를 보게된다. 

이는 로그인을 유지할 수 있는 기간이 지나 자동으로 로그아웃되었기 때문에 다시 로그인하라는 문제이다. 

즉, 여기서 말하는 인증이라는 것은 로그인이라고 생각해볼 수 있다.

 

인증과 인가

인증 (= 로그인) Authentication

• 가입된 유저라는 것을 확인하기 위한 것
• 관리자든 고객이든 인증을 통해 사이트에 가입된 사용자라는 것을 증명하는 것

 

인가 Authorization

• 같은 사이트여도 관리자냐 고객이냐에 따라 접근할 수 있는 페이지에 차이 존재 
• 인증 후, 해당 페이지에 접근 권한이 있는지 확인하는 것 

 

쿠키와 세션

쿠키 Cookie

• 웹 서버에 의해 사용자의 컴퓨터에 저장되는, 이름을 가진 작은 크기의 데이터
• 포춘 쿠키처럼 쿠키 안에 내용물(아이디, 로그인한 시점 등)을 담아 다니며 서버와 주고받는다.
• 장점
  • 서버가 저장을 하지 않으니 서버 저장 공간을 절약할 수 있다
  • 서버가 상태를 저장하지 않는다 = Stateless = REST(ful)
• 단점
  • 중간에 누가 가로챌 수 있기 때문에 보안에 취약

 

세션 Session

• 인터넷 서버에서 인터넷 브라우저(클라이언트)와 상호작용할 때 생성되는 일시적인 상태 정보
• 중요한 정보는 서버(금고)에 저장해두고 세션 번호(금고 번호)만 가지고 주고 받는다. 
• 장점
  • 비교적 보안이 좋다 (금고 번호 털리면 이것도 ...)
• 단점
  • 서버에 저장하기 때문에 서버 저장공간을 사용 => Stateless 하지 못하다

 

서로 장단점이 교차되었을 뿐 해결되지 못한다.

서로의 단점들을 보완하여 탄생한 것이 바로 JWT이다.

 

JWT  (Json Web Token)

Json형태(JS 객체 형태)의 데이터를 안전하게 전송하기 위해 웹에서 사용하는 토큰

토큰을 가진 사용자가 "증명"을 하기 위한 수단 

• 인증용 : 입장 가능한 유저인지 판단
• 인가용 : 관리자인지 일반 유저인지 권한 판단

 

장점

• 암호화가 되어 보안에 강하다
• 서버가 상태를 저장하지 않는다 = Stateless = HTTPful
• 서버의 부담을 줄여 줄 수 있다 

 

🔧 구조

그럼 JWT가 어떻게 생겼는지  공식 홈페이지를 통해 확인해보자.

JSON Web Tokens - jwt.io

 

왼쪽이 암호화된 토큰이고 오른쪽은 복호화된 토큰이다.

 

HEADER

• 토큰을 암호화하는데 사용한 알고리즘, 토큰의 형태(보통 JWT)
• HS256은 암호화하는 여러 알고리즘 중 하나

 

PAYLOAD

• 사용자 정보 
• 이름, 로그인한 시점, 권한 등 사용자를 인증하기 위해 적는 정보
• 비밀번호는 여기에 잘 담지 않는다

 

VERIGY SIGNATURE

• 만약 페이로드의 데이터가 변경된다면 이 서명값도 함께 변경
• 누군가 악의적으로 같은 알고리즘으로 데이터를 변경했다하더라도 서명값이 달라지기 때문에 인정 X 

 

🚀 절차

1. 클라이언트가 서버에 로그인 요청

• POST /login
• HTTP body (userName, password)

2. 서버는 내부 로직을 확인 후 JWT(토큰) 발행

• 언제 로그인을 했는지 = JWT 발행 시점

3. 로그인 성공

• 로그인 성공했으니 당분간 로그인 상태를 유지
• JWT 발행해주고 그 이후론 JWT를 가져오도록 한다
  • 서버는 해당 정보를 저장해두지 않고 이후 클라이언트가 가져올 때 자신이 한 서명인지 확인 후 맞으면 들여보내준다

4. 클라이언트가 서버에 다른 요청 

• HTTP header에 JWT를 들고 다른 요청 (= 나 이미 인증됐으니 로그인 안해도 되겠지?)

5. 서버는 자신이 한 서명이 맞는 지 확인

• 자신의 서명이 맞으면 요청 수행, 아니면 수행 X

 

⌨️ 구현

npm instal jsonwebtoken

jsonwebtoken

 

var jwt = require('jsonwebtoken');
var token = jwt.sign({foo : 'bar'}, 'shhhh');

 JWT모듈을 소환해 token을 생성하였다. 

여기서 sign의 매개변수는 다음과 같다.

1. payload

2. secretOrPrivateKey

3. options

 

JWT를 그냥 암호화 알고리즘만으로 하기엔 혹시 모를 상황에 대비하여 나만의 암호키를 추가하도록 되어있다. 

그래서 위 코드를 보면 'shhhh'가 내가 설정한 암호값이 된다.

 

콘솔로 찍어보니 토큰이 잘 생성되고 있다.

그럼 이 토큰을 JWT 홈페이지에서 다시 복호화 해보자.

 

우측 PAYLOAD에 내가 설정한 bar가 잘 들어간 것을 볼 수 있다.

여기서 iat은 issued at의 약자로 발급된 시간을 초로 표현한 값이다. 

 

그런데 하단에 Invalid Signature라고 뜬다. 

내가 추가한 암호키를 넣어주지 안아 그런 것 같으니 VERIFY SIGNATURE에 내 암호키를 넣어줘보겠다.

 

그러자 Signature Verfied로 바꼈다 !

 

그럼 매번 이 사이트에서 와서 확인해야하나? 

해당 모듈엔 검증하는 코드도 있다.

 

var decoded = jwt.verify(token, 'shhhh');

토큰과 암호키를 매개변수로 주면 PAYLOAD값이 반환된다.

 

 

⚙️ .env

명색이 암호키인데 저 파일이 깃허브에 올라간다면? 만천하에 다 공개되는 것이 아닌가

아무래도 해당 값을 별도로 빼주고 깃허브에 올라가지 않도록 관리해주어야 할 것 같다.

 

.env는 enviornment의 약자로 환경 변수 '설정값' 이란 의미를 담고 있다.

개발을 하다 DB계정이나 암호키처럼 외부에 유출되면 안되는 중요한 환경변수들을 따로 관리하는 파일이다.

환경 변수 파일이다 보니 프로젝트 최상위 패키지에 위치하도록 해야한다.

❗ 유출되면 안되기 때문에 .gitignore에 반드시 추가해 깃허브에 올라가지 않도록 해야한다.

 

.env에 있는 변수들을 가져다 사용하기 위해 사용하는 모듈도 있다.

npm i dotenv

dotenv

 

💡 .env파일에선 대문자 + 스네이크 케이스를 사용하며 주석은 #을 사용한다.

 

PRIVATE_KEY = 'shhhh' # JWT 암호키

앞서 사용했던 암호키를 .env 파일에 추가하고

 

var dotenv = require('dotenv');

dotenv.config(); // dotenv 설정 사용할거라고 선언

var token = jwt.sign({ foo : 'bar'}, process.env.PRIVATE_KEY);

사용할 땐 dotenv모듈을 불러와 해당 설정을 사용할거라는 선언을 해준 뒤 

process.env.변수명으로 불러와 사용해주면 되다.

 

 

🍪 쿠키 Cookie

그럼 로그인할 때 발생하는 토큰은 어디에 다아 주는 것이 좋을까 

res에 담아 주기에는 프론트에게 전달해주는 내용과 겹치니 쿠키에 담아주도록 하자.

 

cookie-parser

그냥 쿠키에 담아주는 것엔 따로 모듈이 필요하진 않지만 

추후 req에서 쿠키를 가져다 사용할 때, 쿠키에 있는 내용을 확인해서 사용해야 할 때에는 parser가 필요하다

 

담는 방법은 간단하다.

res.cookie("token", token);

res.cookie에 담아주면 되는데 쿠키에는 다양한 값들이 담겨있을 수 있기 때문에

정확히 무엇인지 함께 작성해서 보내주어야 한다. 

 

그럼 이제 body가 아닌 cookie에 토큰이 담겨져 온다.

 

여기서 또 확인해봐야할 설정들이 있는데 바로 우측에 있는 HttpOnly랑 Secure이다.

 

HttpOnly

• 프론트엔드가 아닌 API호출만 허락할 것인지 
• false 👉🏻 화면단에 공격(XSS공격)이 들어오면 쿠키도 함께 공격 받음
• true  👉🏻httpAPI로만 요청을 받기 때문에 XSS공격에는 반응하지 않음

 

Secure

• HTTPS환경에서 보낼 것인지 HTTP환경에서 보낼 것인지
  • HTTPS의 S가 Secure의 약자 
• false 👉🏻 HTTP
• true  👉🏻 HTTPS

 

이런 설정 값은 앞에 쿠키에 담아주는 것 뒤에 함께 작성해주면 된다.

res.cookie("token", token, {httpOnly : true});

 

 

⌛ JWT 유효기간 

토큰을 발급해주고 기간을 정해주지 않는다면 영원히 로그인 상태가 유지될 것이다.

공공장소에서 깜빡하고 로그아웃안하면 정말 아찔한 상황이 펼쳐친다.

그렇기 때문에 토큰을 발급할 때에는 어느 기간동안만 유효할 것인지 설정해주어어한다.

 

const token = jwt.sign({
    email : loginUser.email,
    name : loginUser.name
}, process.env.PRIVATE_KEY, {
    expiresIn : '30m', // 30분 뒤 만료
    issuer : "mingyeong" // 토큰 발행자
});

토큰 발급해주는 매개변수 가장 마지막에 옵션으로 추가해주면 된다.

유효 기간과 더불어 누가 발행해 주었는지도 함께 추가해줄 수 있다.

 

설정해준 기간만큼 유효기간이 찍혀있는 것을 볼 수 있다.