목차
로그인과 토큰
토큰
누군가의 신원을 증명할 수 있는 데이터 조각을 말합니다.
로그인에 왜 토큰을 사용할까? 
위와같이 로그인을 한 유저가 주문한 후에 배달 진행상황을 물어본다면, 서비스는 유저의 정보를 알 수 있을까요? 알 수없습니다. 왜 그럴까요? 기본적으로 http 요청은 무상태성이라는 특징을 지니고 있기 때문입니다!
알 수없습니다. 왜 그럴까요? 기본적으로 http 요청은 무상태성이라는 특징을 지니고 있기 때문입니다! chatGPT 가 말해주는 http 요청의 stateless 특성
즉 한마디로 말하면, 요청 사이에 유저의 정보를 저장하지 않아서 주문시 유저 인증을 받았다고 하더라도 다음 요청시에는 해당 유저인지 아닌지 알 길이 없다는 것입니다.
이러한 문제는 토큰을 이용하여 해결할 수 있습니다.
토큰에는 유저의 정보가 담겨있기 때문에 서버에서 보내준 토큰을 보관했다가 서버에 요청시 같이 넣어주면 서버는 이를 통해 특정 유저임을 확인하고, 알맞은 응답을 내려줄 수 있습니다.
토큰 기반 로그인의 흐름
전체 흐름 살펴보기
1.
프론트에서 로그인 요청을 합니다.
2.
서버에서는 로그인 유저를 확인하고 토큰 발급 후 응답에 포함하여 프론트에 전달합니다.
3.
프론트는 서버에서 받은 토큰을 적절한 곳에 보관합니다.
4.
그 후 요청시에 보관한 토큰을 꺼내 적절한 곳에 넣어줍니다.
5.
서버에서는 요청시 받은 토큰을 검증합니다.
accessToken 만 있다고 가정한 모식도 입니다!
실제 서비스에서는?
•
로그인 후 로그인 상태 유지
•
자동 로그인
이외에도 고려할 부분이 많습니다!
JWT
JWT 의 구조
HEADER
•
암호화 규칙 : 어떻게 암호화를 처리할 것인지 정하는 알고리즘을 말합니다.
•
토큰 타입
•
시그니쳐가 없어도 디코더로 해독할 수 있습니다.
PAYLOAD
•
토큰 데이터(클레임)
•
시그니쳐가 없어도 디코더로 해독할 수 있습니다. ⇒ 민감정보를 넣으면 안됩니다.
SIGNATURE
•
암호화를 위한 데이터
•
서버에서 이 값이 올바른 값인지 확인하기 위한 데이터 입니다.
•
클라이언트는 secret key 를 알 수 없습니다.
토큰을 어떻게 비교 / 검증 할까?
프론트에서 헤더와 페이로드 그리고 시그니처 가 담겨있는 웹토큰을 서버에 전송합니다. 서버는 프론트에서 받은 헤더와 페이로드 부분을 시크릿 키를 이용하여 시그니처를 생성 합니다. 그 후 프론트에서 받은 토큰의 시그니처 부분과 비교합니다. 이렇게 토큰을 검증 합니다.
토큰 탈취
XSS(Cross Site Scripting)
CSRF(Cross-site Request Forgery)
어떻게 해결하나요?
리프레시 토큰과 어세스 토큰에 대해 알아봅시다.
