JWT 기본 개념/인증,인가

JWT(JSON  Web Token)?

인증에 필요한 방식으로 특정유저가 로그인 할 때, 정말로 인증된 사용자인지 검증할 때 사용.

로그인한 정보가 정말로 인증된 사용자인지 검증할때 사용

• 사용예시
  • 인증된(로그인한) 유저만 게시글을 작성 -> 특정회원으로 로그인 됨을 증명 
  • 인증된 관리자만 데이터베이스에 접근 -> 관리자로 로그인 됨을 증명

장점 / 단점 

• 장점
  
  • 가볍고 클라이언트 어플리케이션에서 사용하기 쉽다 (예) 모바일 어플리케이션
  • 토큰에 모든정보가 들어가 있어서 토큰을 이용해서 인증(검증)이 가능하다.
    • 4가지 단계의 인증절차
      • 요청(클라이언트,사용자) -> 확인(서버) -> 토큰(서버가 사용자를 확인하고 토큰발급) -> 저장(사용자의 브라우저에 저장)
  • 토큰 만료 시스템이 있다.
• 단점
  • 단일 키를 이용하여, 노출되면 시스템 전체가 위험에 노출된다.
  • 토큰이 복잡하여 이해하기가 쉽지 않다.
    • 개발자가 암호서명 알고리즘에 정통하지 않으면 자신도 모르게 시스템을 위험에 빠뜨릴 수 있다.
  • 메세지를 모든 클라이언트에게 푸쉬 불가능, 서버 측 클라이언트도 관리할 수 없다 

구성

• 구성 -> 토큰을 받으면 https://jwt.io/ 에서 아래 처럼 디코드 된 것을 확인 가능
• eyJhbGciO.I6IkpvaG4gRG2MjM5MDIyfQ.POk6yJV_adQssw5c
  • Header.Payload.Signature

/* Header (알고리즘, 토큰 타입)*/
{
    "alg": "HS256", // 서명(signature) 생성 시 사용한 해시 알고리즘 : HS256 지원
    "typ": "JWT" // 토큰 타입 : < JWT 만 지원>
}

/* Payload (내용, 데이터) */
{
  "id": 1,
  "iat": 1699358134, // 토큰 발행 시간
  "exp": 1700222134 // 토큰 만료 시간 (옵션)
}

/* VERIFY SIGNATURE */
/* header와 payload에 입력된 값을 암호화 하고
 secret 부분은 검증(보안서명을 통해 메세지가 전송 과정에서 바뀌지 않은 것을 확인)*/
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
)

 

 

인증/ 작동 과정

 

• 요청(클라이언트,사용자) -> 확인(서버) -> 토큰(서버가 사용자를 확인하고 토큰발급) -> 저장(사용자의 브라우저에 저장)

 

사용이유

• 임시 엑세스를 자주 허용하는 관리자에게 유용
  • 날짜, 시간 또는 특별 이벤트에 따라 사용자 수의 변동 폭이 크면 액세스를 반복해서 허용 또는 취소해야 할 경우 유용

• SAML (security assertion markup language token) 보다 간결하고 데이터 크기도 훨씬작다.
• 확장성이 좋다.
• 데이터 위조 변조를 방지

사용시 주의사항

1. alg:none ( header ) : 가끔 어떤 사이트들은 alg 가 none 일 경우 인가해주는 경우 존재
2. Decoding : JWT 디코딩은 쉬운 편이다. 그래서 민감한 정보를 많이 넣느 것을 주의하고 최소한의 정보만 넣어야 한다.
3. 시크릿키 문제: 개발자가 시크릿 키를 대충 구현하면 공격받기 쉽다.
   1. 공유금지, 길게 설정하기
4. 탈취에 유의 
   1. 블랙리스트 생성, 유효기간 짧게 설정, 훔치기 힘든 저장소( http only cookie)에 JWT 저장

 

 

 

 

참고자료

JWT공식문서

네이버 cloud platform

wikipeida

IBM

github: node-jsonwebtoken

okta

https://velog.io/@j_user0719/JWT-%EC%82%AC%EC%9A%A9%EC%8B%9C-%EC%A3%BC%EC%9D%98%EC%82%AC%ED%95%AD