Spring/Security

[Security] JWT - 이해하기 3(JWT란)

석석's 2021. 12. 9. 12:19

저번시간까지 RSA , HMAC 방식에 대해 알아보았다. 

이번시간에는 JWT(JSON WEB TOKEN) 에 대해 알아볼것이다.

https://oneseok.tistory.com/67?category=933442

 

[Security] JWT - 이해하기 1(RSA)

RSA란? - 공개키로 암호화하는 시스템의 하나로 개인키 개념까지 넣어 전자서명으로 인증까지 해결하는 알고리즘이다. 말이 너무 어려워 그림과 함께 천천히 내용을 풀어보려고 한다. 이 개념을

oneseok.tistory.com

https://oneseok.tistory.com/68?category=933442

 

[Security] JWT - 이해하기 2(HMAC)

HMAC을 이해 하기 위해서는 MAC에대해 먼저 알아야한다. MAC 이란?  - "Message Authentication Code" 의 줄인말로 , 메세지를 인증하기 위해 사용하는 정보이다.  - 송신측에서 MAC정보를 메세지에 붙혀 보내

oneseok.tistory.com

 

 

JWT 란?

  • Json Web Token의 약자로 당사자간의 주고받을 정보를 Json 형태의 객체로 안전하게 전송하기 위한 방법이다.
  • 정보를 암호화하여 비밀리에 전송하는것에 초점을 두기보단 디지털 전자서명에 초점을 둔 방식이다.

 

JWT을 언제 사용하면 좋을까?

  1.  권한부여 : 사용자가 인증이 되면 토큰을 부여하여 앞으로 서비스에 요청시 토큰값을 같이 보내면 서비스에 접근할 수 있게 권한을 부여한다.
  2.  송신측과 수신측이 정보를 안전하게 전송하고 싶을때 사용하면 좋다 , RSA의 방식인 비대칭 방식으로 서명할 수 있기 때문에 발신자가 신뢰된 사람인지 알수가있다 또한 Hash값 비교를 통해 정보가 위변조 되지 않았는지 판단 할 수 있다.

 

 

JWT의 구조

1. Header

- 서명할때 사용된 알고리즘이 무엇인지 나타내는 영역입니다.(Base64Url 로 인코딩)

- typ과 alg 두 가지 정보로 구성된다. alg는 헤더(Header)를 암호화 하는 것이 아니고, Signature를 해싱하기 위한 알고리즘을 지정하는 것이다.

 

2. Payload

- 사용자의 정보 및 데이터들이 포함되는 영역입니다(Base64Url 로 인코딩)

- 토큰에서 사용할 정보의 조각들인 클레임(Claim) 이 담겨있습니다.

Registered claims(등록된 클레임) Public claims(공개 클레임) Private claims(비공개 클레임)
필수는 아니지만 권장하는 클레임 집합 공개 클레임은 사용자 정의 클레임으로. 공개용 정보 전달을 위해 사용된다. 충돌 방지를 위해 URI 포맷을 이용해야 한다 비공개 클레임은 등록된 클레임도 아니고, 공개 클레임도 아닌 당사자간에 정보를 공유하기 위해 만들어진 사용자지정 클레임이다. 공개 클레임과 달리 이름이 중복되어 충돌이 될 수 있으니 유의 해야 한다.
  • iss : 토큰 발급자 (issure)
  • sub : 토큰 제목 (subject) , 유니크값을 많이 사용
  • aud : 토큰 대상자 (audience)
  • exp : 토큰 만료시간 (expiration)
  • nbf : Not Before 를 의미 하며, 토큰 활성 날짜와 비슷한 개념이다. 
  • iat : 토큰이 발급된 시간 (issued at)
  • jti : JWT 의 고유 식별자로서, 주로 중복적인 처리를 방지하기 위하여 사용 된다. 일회용 토큰에 사용하면 유용하다.



 { 
"https://seok.com/xxx/yyy" : ture
}

 { 
"username" : "Jone Doe"
}

 

 

 

3. Signiture - Base64Url로 인코딩된 Header,Payload 와 Secret-key 를 가지고 헤더에 명시된 알고리즘을 적용하여 서명하는것 입니다.

     

    - 예를들어 HMAC SHA256 알고리즘을 사용할경우 이렇게 나타냅니다.

      Signiture 과정을 통해 나중에 수신시 메세지의 위변조를 판단하고  , 개인키로 암호화 했을경우 송신자가 누구인지 판단 가능해진다.

 

 

 

 

JWT의 완성형태

JWT 의 형태

 

 

JWT를 사용하여 인증처리방법

  - JWT는 서명에 초점을 둔 방식이라 암호화에 취약하다. 그래서 일반적으로 클라이언트가 토큰을 오래 가지고 있으면 안된다.

 

  - 일반적으로 로그인시 서버쪽에서는 Bearer 키워드를 붙혀 Authorization 헤더에 JWT를 같이 담아 보내야합니다. 

Authorization 헤더

 

JWT를 이용한 인증처리 시나리오

 

HS256 알고리즘을 이용한 토큰인증처리

  1. 클라이언트가 로그인 요청
  2. 로그인이 완료되면 서버가 JWT 를 생성함 이때 header에는 HS256 , payload에는 user정보 , signiture에는 header+payload+ 서버만 알고있는특정키 로 HS256암호화를 한다. 이후 header , payload , signiture에 각각 base64Url 인코딩을 적용함
  3. 클라이언트에게 전송해주고 JWT토큰을 발급받은 클라이언트는 자신만에 저장소에 저장해둠(쿠키나 로컬스토리지)
  4. 클라이언트가 마이페이지 접근시 서버에게 요청정보와 저장해둔 JWT 토큰을 같이 실어보냄
  5. 서버에서 클라이언트로부터 넘어온 JWT 토큰을 가지고 bas64Url로 암호화되있는 header,payload,signiture를 복호화후 header+payload+서버만 알고있는 특정키 로 HS256암호화 후 복호화한 signiture 부분과 비교해서 똑같으면 인증은 통과 시킨다!!
  6. 인증이 완료되었으니 클라이언트가 필요한 마이페이지 접근을 위해 DB에서 부터 payload에 있는 user정보를 통해 조회하여 넘겨준다!

 

RSA를 이용한 토큰인증 처리

  1. 발급시 Header에는 RSA를 적고 Payload 에는 유저정보 , Signiture에 header+payload 만 합쳐 서버만의 "개인키로" 잠궈 발급하면된다.
  2. 클라이언트로 부터 요청이 오면 서버입장에서는 자신만의 "공개키" 로 "개인키" 로 잠겨져 있는 signiture 부분을 풀어서(서명) 풀리면 서버가 발급한게 맞으니 인증처리를 해주면 된다.