🥽[JWT] - 토큰 기반 인증

[정의]

JSON Web Token

인증에 필요한 정보들을 암호화시킨 JSON 토큰

JWT 토큰을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식

(JWT 토큰 = Access Token)

[구조]

. 을 구분자로 Header, Payload, Signature 로 나뉜다.

• Header : JWT에서 사용할 타입과 해시 알고리즘의 종류
• Payload : 서버에서 첨부한 사용자 권한 정보와 데이터 → 실제로 사용될 정보들
  • key-value 로 이루어진 한 쌍을 Claim 이라고 한다.
  • 등록된 클레임
    • iss(issuer; 발행자)
    • exp(expireation time; 만료 시간)
    • sub(subject; 제목)
    • iat(issued At; 발행 시간)
    • jti(JWI ID)
  • 공개 클레임
    • 공개용 정보 전달을 위함
    • 클레임 이름을 주로 URI로 지음
  • 비공개 클레임
    • 공개되면 안 되는 클레임
    • 클라이언트-서버 간 통신에 사용
• Signature : Header & Payload 를 인코딩한 후 Header에 명시된 해시함수를 적용하고, 비밀키로 해시값 생성
  

-> 토큰의 위변조 여부 확인에 사용

[인증 과정]

1. 사용자가 서버에 로그인 인증 요청
2. 서버에서 Header, Payload, Signature 정의 후 JWT(액세스 + 리프레시)를 생성하여 쿠키에 담아 클라이언트로 전송

• 서버는 리프레시 토큰을 DB에 별도 저장

3.클라이언트는 JWT를 로컬 스토리지에 저장

• 서버에 API 요청 시 Authorization header 에 Access Token을 담아 전송

4.서버는 토큰의 액세스 토큰의 유효성 검사

• 유효 X → 토큰 만료 에러 반환
  • 클라이언트는 리프레시 토큰으로 새로운 액세스 토큰 발급 요청
  • 서버는 DB의 리프레시 토큰과 비교 후 유효하다면 새로운 액세스 토큰 발급
• 유효 O → 요청 처리

[궁금증]

리프레시 토큰이 탈취당한다면 무용지물 아닐까 ?

YES !

토큰 기반 인증의 특징 중 하나는 “무상태성” 이다.

사용자의 인증 정보가 담긴 토큰이 서버가 아닌 클라이언트에게 있기 때문에, 서버에서 따로 저장할 필요가 없다. 즉, stateless 인 것이다.

따라서 액세스 토큰을 탈취당하면 서버는 확인할 방법이 없다. 이를 위해 리프레시 토큰이라는 개념이 생겼다.

액세스 토큰의 유효기간(보통 30분)을 짧게 한다면 탈취당하더라도 오래 사용하지 못할 것이다. 하지만 사용장 입장에서는 유효기간이 끝날 때마다 토큰을 재발급해야 하는 번거로움이 있다. 따라서 리프레시 토큰의 유효기간을 길게 하여(보통 2주) 액세스 토큰이 만료되면 새로운 액세스 토큰을 발급할 수 있도록 하는 것이다. 결론적으로는 클라이언트 입장에서는 로그인 상태가 유지되는 것처럼 느껴진다.

하지만 리프레시 토큰은 “무효화” 할 수 있다는 장점이 있다. 리프레시 토큰은 서버에서도 저장을 하고 있다. 따라서 리프레시 토큰이 탈취당했을 때, 탈취당했다는 어떠한 요청이 오면 토큰을 무효화 시킬 수 있다는 것이다.

⇒ Refresh Token이 탈취되더라도 서버의 검증으로 AccessToken 재발급을 방지할 수 있다.

토큰은 어디에 저장될까 ?

Access Token은 요청 header의 authorization에 담긴다. → 공식 규격

Refresh Token은 http only cookie로 넘겨주면 js를 통한 접근이 불가능해지므로 스크립트 삽입 공격(XSS)은 막을 수 있다. 또한 http secure → https로만 통신하는 방법을 통해 쿠키에 보관하는 것이 좋다. 이렇게 하면 탈취 가능성은 거의 없다고 한다.

토큰의 유효성은 어떻게 검증할까 ?

토큰 기반 인증에서 리프레시 토큰 없이 무상태로 운영한다면, 서버는 클라이언트가 보낸 토큰을 어떤 데이터를 바탕으로 검증을 하는건지 궁금했다.

1. 서명 검증
   1. 서버는 토큰의 Signature를 서버에만 있는 비밀키를 사용해 검증 → 토큰의 위변조 확인 가능
2. Payload의 만료시간 확인
   1. 토큰의 exp 를 확인하여 유효 기간이 지났는지 판단

⇒ 즉, 토큰 그 자체가 데이터로 이루어져 있기 때문에, 토큰 자체로 인증을 처리함

[추가 보안 강화 방법]

1. JWT 토큰에 JTI (JWT ID) 포함 : 토큰 고유 식별자를 추가해 재사용 방지
2. 토큰 만료 시간 관리 : Access Token은 짧게, Refresh Token은 길게
3. 2FA(Two-Factor Authentication) : 추가 인증 단계 도입

---

[출처]

• https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC#jwt_json_web_token_%EC%9D%B4%EB%9E%80

• https://pizza7311.me/post/dev/refresh-and-access-token

• https://stella-ul.tistory.com/entry/Access-Token%EC%9D%98-%EC%B7%A8%EC%95%BD%EC%A0%90%EA%B3%BC-Refresh-Token%EC%9D%84-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%8D%A8%EC%95%BC%ED%95%98%EB%8A%94%EC%A7%80

• https://velog.io/@thekim12/Refresh-Token-%EB%B3%B4%EC%95%88%EC%9D%98-%ED%95%B5%EC%8B%AC-%ED%83%88%EC%B7%A8%EB%A5%BC-%EB%A7%89%EB%8A%94-%EA%B2%83