Validation , Authentication, Configuration

HK·2022년 6월 4일

client가 server에게 특정한 요청을 보낼 때 body로 보내는 데이터들이 유효한지 확인하는 과정.
DB쪽에서 필요한 데이터가 모두 전달되었는지 확인할 수 있음. 하지만 db에서 유효성 검사를 할 때까지 기다리는 것은 별로임. server에서도 유효성 검사를 빨리 하면 할 수록 좋음(불필요한 비용을 줄일 수 있기 때문에)
client쪽에서도 client만의 유효성 검사를 할 수도 있음. (대부분의 경우 이것은 optional하기 때문에 server에서 반드시 validation을 해줘야 한다.)

Authenication(인증): you are who you say you are- 누구인지 식별
- password, pincode(what you know:알고 있는 것)
- mobile phone, hardware token(what you have: 가지고 있는 것)
- fingerprints, signature(what you are: 생체 정보나 자필 서명)
HTTP는 stateless protocol(상태를 보관하고 있지 않음)임.
- 그렇다면 AUTH는 어떻게 일어나는가?
  - session + cookie
  - JWT

사용자의 세션을 서버에서 보관.
1. client가 서버에 로그인
1. server는 db에 있는 사용자의 id, pw가 일치하는지 확인
1. 유효한 사용자라면 session을 만든다.(session id, user id, expiration정보 포함)
1. session정보를 session이라는 별도의 database에 저장한다.(대부분의 경우)
1. client에게 session과 관련된 정보를 쿠키에 담아 보내준다.
- HTTP Only라는 옵션을 주게 되면 해당 쿠키는 브라우저에 의해서만 읽을 수 있다. js나 프로그램 내에서는 읽을 수 없고 브라우저 내에서만 읽어서 다시 서버에 보낼 수 있는 안전한 방법임.
장점:
- session db에 모든 세션에 대한 정보를 보관하므로 신뢰할 수 있는 데이터임
- 쿠키를 사용하기 때문에 client측에서 별도의 처리를 하지 않아도 브라우저에서 simple하게 대신 함.
- HTTPonly 옵션을 사용하므로 보안이 좋다.
- cookie를 사용하므로 사용자 정보를 직접적으로 전달하지 않고 session id만 사용하므로 보안이 좋다.
단점: Stateful. 한 세션에 정보를 보관하고 있으므로 여러 개의 서버들이 session에 대한 정보를 얻기 위해 하나의 서버에 접속한다. 이 때 네트워크 요청을 하는 과정에서 시간이 많이 걸릴 수 있다.

JSON Web Token
- JSON안의 header, payload, signature에 AUTH정보를 담고 있음.
  - header: 사용하는 algorithm과 type
  - payload: 주고받고자 하는 data가 encoding된 형태로 저장
  - signature: encoding한 헤더와 payload부분, encoding할 때 사용한 서버의 비밀 키(secret)-> 정보의 유효성을 지킬 수 있다.
1. client가 서버에 로그인
1. server는 db에 있는 사용자의 id, pw가 일치하는지 확인
1. 유효한 사용자라면 JWT를 만든다.
1. JWT를 사용자에게 보낸다.
1. 추후에 발생하는 api요청에 대해 JWT를 헤더에 포함한 상태로 server에게 보낸다.
1. Verify: server측에서 JWT가 수정되어있는지, 정보가 정확한지, 만료되지 않았는지 등 유효성 검사 실시
1. 해당 데이터를 client에게 보낸다.
장점: server에 state가 없다. session을 사용할 때는 server에 session이라는 상태가 필요했음. 반면 JWT는 한번 JSON파일을 생성해 client에게 보내주고 다시 검증하는 과정만 거치면 되기 때문에 하나의 서버에 접속하는 과정이 필요 없다. 그냥 server들이 secret key만 가지고 있으면 됨.
단점: client와 server가 계속 JWT를 주고받기 때문에 보안에 취약할 수 있다.

bcrypt: password-hashing function
사용자가 설정한 id와 pw를 암호화 알고리즘을 통해 hashing된 상태로 db에 저장.
- Alg정보/cost/salt/hash로 구성되어 있음
- 해킹 방지를 위해 salt사용(암호화를 더 복잡하게)

server code를 깃허브 등의 open source에 올릴 때 주의해야 할 사항
- secret key도 함께 올리면 사용자의 정보가 유출될 위험이 크다.
- 따라서 secret key관련 정보는 공개적으로 올리지 않는다. local에서만 가지고 있어야 함.(보통 따로 보관해놓음)
server의 설정성/유연성
- salt나 expire에 관한 정보가 코드에 들어 있어서 개발자가 관련 정보를 고치고 싶다면 코드를 고친 후 컴파일해서 다시 배포해야 한다. -> 설정성이 떨어짐+시간이 오래 걸림.
- 따라서 코드를 변경하지 않고도 설정값을 바꿀 수 있게 해야 한다.

기존의 HTTP는 request와 response로 이루어짐. client가 요청을 해야만 server가 대답할 수 있는 상태.
반면에 socket에서는 client와 server가 연결되어 있기만 하다면 server에 변동사항이 생겼을 때 이를 client의 request 없이도 보내줄 수 있다.(원할 때마다 전송 가능)
client와 server용 socket.io를 각각 설치해 연결한다.