spring security를 알아보자 - 12

ㅇ JSON Web Token 기반 인증

인증방법으로 세션과 토큰의 차이는 이미 포스팅해놓은게 있으니 패스. 그리고 JWT를 적용해서 어플을만든 경험도 있기에 간단하게  짚고 넘어가보겠다. 

 

ㅇ 토큰?

토큰은 클라이언트 애플리케이션에서 백엔드 시스템으로 보호된자료에 접근할때마다 보낼 수 있도록 설정되어있다. 토큰이 유효하다면 백엔드 서버는 올바른 응답을 해줄 수 있다. 

 

ㅇ 토큰을 사용함으로써 얻는 장점

자격증명이 되면 실제 자격증명을 공유하지 않고도 토큰을 주고받는것으로도 클라이언트와 백엔드 서버가 작업할 수 있게된다. 또한 백엔드 애플리케이션도 인증을 반복해서 하지 않아도 된다.  그리고 토큰을 사용하여 엔드 유저의 유저정보 혹은 역할정보를 저장할 수 있다. Spring Security 에서 기본으로 만드는 JsessionId 에는 이런 유연성이 없다. 그리고 토큰을 재사용할 수 있다는 점이 있다. 예를 들어, 구글에서 운영하는 지메일이나,다른 구글서비스를 사용할때 토큰을 재사용할 수 있다는 것이다. 

 

ㅇ JWT?

웹 요청에 사용되는데 내부적으로 이 토큰은 데이터를 JSON형식으로 유지한다. REST서비스의 도움으로 JSON형식으로 통신하기 위해 설계되었다. 가장 큰 특징으로는 토큰 자체의 내부에서 유저와 관련된 데이터를 저장 및 공유할 수 있도록 도와준다.

JWT는 세 부분으로 나뉜다. 

https://fusionauth.io/articles/tokens/jwt-components-explained

헤더랑, 페이로드, 시그니처 이 세부분으로 나뉜다. 점으로 구분이된다.

헤더에는 토큰에 대한 정보(알고리즘, 타입 등)

페이로드에는 저장을 원하는 유저의 모든 정보를 저장한다.

시그니처에는 헤더와 바디의값이 있는 JWT토큰을 생성할 때 마다 토큰에 디지털 서명을하는데 그 서명이 시그니처다. 그래서 나중에 누군가 토큰을 조작하려고하면 감지가 가능하다. 

헤더와 페이로드의 정보들은 Base64로 인코딩되어 토큰이 완성된다.

 

시그니처는 선택적이며 클라이언트가 방화벽이나 토큰을 조작하지 않을거라면 시그니처를 꼭 쓸필요는 없다. 

이 시그니처를 만들땐 HMACSHA256(base64헤더 + . + base64페이로드, secret) 이공식을 사용해 만들어진다. 이건 백엔드 애플리케이션만 만들수 있다. 그래서 이 시그니처로 해커의 공격을 쉽게 감지해서 그 세션을 취소시킬 수 있다.