토요일 0900부터 일요일 0700까지 철야 풀스택 프로젝트를 하느라 TIL이 늦어졌다.
로그인이라는 생소한 부분을 자진해서 맡았는데, 팀원들에게 많이 배웠다.
여러 사용자가 하나의 서비스를 이용할 때, 서버는 누가 어떤 요청을 보냈는지 파악해야 한다.
이 때 프론트엔드는 자신의 인증 수단을 서버에 보내야 하며, 서버는 이를 통해 요청에 맞는 데이터를 전송한다.
HTTP 통신
HTTP 통신은 응답 후 연결이 끊기며, 이전의 요청과 전혀 관계가 없다. 또한 주체의 정보가 필수다.
HTTP의 메시지는
요청 라인 > 헤더 > 공백 > 바디
로 구성되며, 헤더에는 요청에 대한 정보,
바디에는 서버로 보낼 데이터가 들어간다.
일반적인 인증은 헤더에 인증 수단이 들어간다.
Session / Cookie
Session은 접속 시 서버에 의해 웹 서버에 정보가 저장되며,
Cookie는 서버에 의해 클라이언트의 컴퓨터에 정보가 저장된다.
순서는 다음과 같은데,
- 사용자가 로그인을 하면
- 서버에서 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장해 연결되는 세션 ID를 발행한다.
- 사용자는 서버에서 해당 세션 ID를 받아 쿠키에 저장을 한 후 , 인증이 필요한 요청마다 쿠키를 헤더에 실어 보낸다.
- 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 그에 맞는 정보를 가져온다.
- 인증 완료 후 서버는 사용자에게 맞는 데이터를 보내준다.
토큰 기반 인증 방식
토큰은 무작위로 만들어진 수열로 만들어진다. 대표적으로 Json Web Token이 있다.
JWT는 인증에 필요한 정보들을 암호화한 토큰으로 사용자는 이를 HTTP 헤더에 실어 서버로 보낸다.
토큰을 크게 3가지로 만들어진다.
Header: 토큰의 정보를 암호화할 방식(alg), 타입(type) 등이 들어간다.
Payload: 서버에서 보낼 데이터가 들어간다. 일반적으로 유저의 고유 ID값, 유효기간이 그 예시다.
Verify Signature: Base64 방식으로 인코딩한 Header, Payload, 그리고 SECRET KEY를 더한 후 서명된다.
인증 순서는 다음과 같다.
- 사용자가 로그인을 하면
- 서버에서 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID깞을 부여하여 기타 정보와 함께 Payload에 넣는다.
- JWT토큰의 유효기간을 설정한다.
- 암호화할 SECRET KEY를 이용해 Access Token을 발급한다.
- 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보낸다.
- 서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인한다.
- 검증이 완료되면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다.
우리 프로젝트에서는 JWT TOKEN도 이요하고, Cookie를 통해 사용자를 특정했다.
솔직히 말해서 로그인 개념은 맨땅에 시작하느라 뭐가 뭔지 아직도 아리송하다.
그래도 어렴풋이 프로세스는 머리에 각인이 되어서 다행이다.
