- 클라이언트가 서버에 접속할 때 서버에 인증 요청을 보내고
- 서버는 응답으로 해당 클라이언트가 인증되었다는 의미로 고유한 토큰을 부여하는 방식
- 이후 인증이 필요한 요청에서 발급받은 토큰을 Request Header에 함께 전달
- 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정 처리
- 사용자가 아이디와 비밀번호로 로그인 요청
- 서버는 사용자에게 고유한 토큰 발급
- 클라이언트는 서버 측에서 전달받은 토큰을 저장해두고, 인증이 필요한 요청을 할 때마다 해당 토큰을 HTTP 요청 헤더에 포함시켜 전달
- 서버는 전달받은 토큰을 검증하고 응답 전송
- 토큰에는 요청한 사람의 정보가 담겨있기 때문에 서버는 DB를 조회하지 않아도 사용자 판별 가능
- 토큰 자체에 인증에 필요한 데이터가 들어 있고 클라이언트에 저장
- 클라이언트 상태에 대한 세션 정보를 저장하고 조회해야 하는 과정이 없다.
- 클라이언트로부터 받은 토큰의 위조 여부만 판별 (Stateless)
- 토큰 자체의 길이가 길어서 인증 요청이 많아지면 네트워크 부하가 심해진다.
- Payload 자체는 암호화되지 않기 때문에 토큰에 유저의 중요한 정보는 담을 수 없다.
- 클라이언트 측에서 토큰을 탈취 당하면 대처하기 어렵다.
- 토큰의 유효 시간을 제한하여 보안 강화 필요
- JSON Web Token
- 인증에 필요한 정보들을 암호화시킨 JSON 형식의 토큰
.를 구분자로 나누어지는 세가지 문자열의 조합으로 구성헤더Header.내용Payload.서명Signature- 헤더Header: 토큰 타입, 해시 알고리즘 종류
- 내용Payload: 사용자 정보(사용자 권한 정보 등)
- 서명Signature: Header와 Payload 인코딩 + 개인키
- Header에 명시된 해시 함수를 적용하여 암호화한 값
- 비밀키를 추가했기 때문에 외부에서 복호화할 수 없어 토큰의 위변조 여부를 확인 가능
- JWT 형식의 Access Token을 HTTP Header에 추가
- 서버가 클라이언트를 식별하는 방식
- 사용자가 서버에 로그인 인증 요청
- 서버에서 JWT 형식의 Access Token을 생성하여 클라이언트에게 발급
- 클라이언트는 서버로부터 받은 Access Token을 저장
- 이후 인증이 필요한 요청을 할 때마다 Request Header Authoriztion에 토큰을 추가하여 전달
- 서버에서 인증 진행: Access Token의 유효 시간, 위변조 여부 확인 등 확인
- 요청 리소스 응답: 인증이 완료되면 Payload에 들어있는 유저 정보 기반으로 리소스 구성
- Access Token 재발급: Access Token이 만료되면 클라이언트는 Refresh Token으로 새로운 Access Token을 재발급받고 재요청
- Refresh Token 만료: 모든 토큰 삭제, 유저에게 다시 로그인 요청
- 토큰 탈취 문제: 토큰 자체로 클라이언트를 검증하여 권한 인증을 진행하므로 제3자에게 탈취되면 토큰이 만료되기 전까지 해당 유저의 권한 접근 가능
- Access Token의 유효 시간을 짧게 설정
- 토큰 재발급을 위한 Refresh Token을 이중으로 두고 사용
- 클라이언트가 갖고 있는 실제로 유저의 정보가 담긴 토큰
- 인증이 필요한 요청에서 Access Token에 있는 정보를 활용하여 사용자 정보에 맞게 응답 제공
- 탈취 위험이 있으므로 비교적 유효 시간을 짧게 설정하여 관리
- 새로운 Access Token을 발급해주기 위해 사용하는 토큰
- DB에 유저 정보와 함께 저장해두고, 토큰 재발급 요청 시 Refresh Token에 있는 정보로 새로운 Access Token을 발급하여 제공