JWT
Json 객체에 인증에 필요한 정보들은 담은 비밀키 서명한 토큰 => 인터넷 표준 인증 방식
인증 & 권한 허가
- 인증 : 유저가 누구인지 확인 하는 절차 (회원 가입 & 로그인)
- 비밀번호, 일회용 핀, 인증 앱, 생체인식 등이 있음
- 인가 : 유저에 대한 권한을 허락, 엑세스 제어나 클라이언트 권한을 서로 대체하여 사용
서버에서 특정 파일을 다운로드 할 수 있는 권한을 부여, 개별 사용자에게 관리자 권한으로 애플리케이션에 엑세스 할 수 있는 권한을 부여.
보안 환경에서 권한 인증은 항상 인증 이후 진행.
JWT 프로세스
1. 사용자 아이디와 비밀번호로 로그인
2. 서버 측에서 사용자에게 유일한 토큰을 발급
3. 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장, 서버에 요청시 해당 HTTP 요청 헤더에 포함해서 전달.
4. 서버는 전달 받은 토큰을 검증, 요청에 응답
토큰에 요청한 사람의 정보가 담겨있는 서버는 DB를 조회하지 않고 누가 요청하는지 알 수 있음
로그인 이후 작업은
1. 클라이언트는 JWT를 로컬에 저장
2. API 호출할 때 마다 header에 JWT를 실어 보냄
3. 서버는 헤더를 매번 확인해서 사용자가 신뢰할만한지 체크 & 인증이 되면 API에 대한 응답을 보냄
HTTP 특성
Connectionless + Stateless => 한번 통신이 일어나고 나면 연결이 끊어진다는 것, 다시 연결해도 이전 상태를 유지하지 않아 과거에 어떤 정보를 보냈는지 기억하지 못함
화면 이등해서 새로운 API를 요청하면 신뢰할만한 사용자인지 인증하는 과정을 거쳐야 함
인증된 사용자가 어느 정도 기간동안 재인증 하지 않아도 만든 것이 Access Token
JWT 구조
Header, Payload, Signature
👉 Header
alg : Signature에서 사용하는 알고리즘
typ : 토큰 타입
Signature에서 사용하는 대표적 알고리즘 : RS256(공개키, 개인키) & HS256 (비밀키(대칭키))
*) PS256 : (공개키, 비밀키) 비밀키 -> Signature를 사용 & 제공된 JWT를 끝에 공개 키를 검색해서 사용
👉 Payload
사용자의 정보 조각인 claim
key-value 형식으로 이뤄진 한쌍의 정보
- sub : token 제목
- aud : 토큰 대상자
- iat : 토큰이 발급된 시각
- exp : 토큰의 만료 시각
- jti : JWT ID
페이로드는 정해진 데이터 타입은 없지만 Registered claims, Public claims, Private claims 3가지로 나뉨
👉 Signature
- alg 방식을 활용
헤더와 페이로드의 문자열 합친 후, 헤더에서 선언한 알고리즘 key를 이용해 암호화
Header와 Payload는 단순히 Base64url 인코딩 -> 복호화 가능
Signature는 key가 없으면 복호화 X
*) 복호화 : 암호화된 데이터를 저성적 데이터로 변경
🧨 Header에서 선언한 알고리즘에 따라 key는 개인키가 될 수도 있고, 비밀키가 될 수도 있음.
개인키로 서명했다면 공개키로 유효성 검사, 비밀키로 서명했다면, 비밀키를 갖은 사람만 암호화 복호화, 유효성 검사 가능
🧨 Header와 Payload는 단순히 인코딩 된 값이기 때문에 제 3자가 복호화 및 조작 가능, Signature는 서버측에서 관리하는 비밀키가 유출되지 않는 이상 복호화 할 수 없음
복호화 가능한 사이트
*) 💡 JWT은 서명(인증)이 목적이다.JWT는 Base64로 암호화를 하기 때문에 디버거를 사용해서 인코딩된 JWT를 1초만에 복호화할 수 있다.복호화 하면 사용자의 데이터를 담은 Payload 부분이 그대로 노출되어 버린다. 그래서 페이로드에는 비밀번호와 같은 민감한 정보는 넣지 말아야 한다.그럼 토큰 인증 방식 자체가 빛 좋은 개살구라고 생각할수도 있지만, 토큰의 진짜 목적은 정보 보호가 아닌, 위조 방지이다.바로 위에서 소개했듯이, 시그니처에 사용된 비밀키가 노출되지 않는이상 데이터를 위조해도 시그니처 부분에서 바로 걸러지기 때문이다.
ACCESS TOKEN & REFRESH TOKEN
JWT는 stateless이기 때문에 서버에서 상태를 관리하지 않음. 다시 말해, 엑세스 토큰을 JWT를 사용하여 사용자 검증을 진행하면서 서버에서 토큰 상태를 제어 못함
엑세스 토큰만 사용하면 서버에서 토큰의 상태를 변경할 수 없기 때문에 토큰의 유효시간이 짧다면 사용자는 사버스 사용중에 토큰의 유효시간이 갱신되지 않으니, 로그아웃 되면 불편함이 있을 것이고 길다면 보안상 문제가 발생
- Access Token : 유효기간이 짧음
- Refresh Token : 유효기간 길다
- 평소 API 통신할때 Access Token을 사용, Refresh Token은 Access Token이 만료되어 갱신될때 마다 사용
통신과정에서 탈취 위험성이 큰 Access Token의 만료 기간을 짧게 두고 Refresh Token으로 주기적 재발급 => 피해 최소화
서버 클라이언트 통신
- 로그인 인증에 성공한 클라이언트는 Refresh Token과 Access Token 두 개를 서버로 부터 받음
- Refresh Token과 Access Token을 로컬에 저장
- 헤더에 Access Token을 넣고 API 통신
- 일정 기간이 지나 Access Token 유효기간 만료
- Access Token 유효시간 만료
- Access Token을 받은 서버는 401
- 401을 통해 클라이언트는 유효시간 만료 알 수 있음
- 헤더에 Access Token 대신 Refresh Token을 넣어 API를 재요청
- Refresh Token으로 사용자의 권한을 확인한 서버는 응답쿼리 헤더에 새로운 Access Token을 넣어 응답
- Refresh Token 만료 -> 서버는 동일하게 401 Error Code를 보내고 클라이언트는 재로그인
Refresh Token 탈취 위험성
Refresh Token Rotation은 클라이언트가 Access Token를 재요청할 때마다 Refresh Token도 새로 발급받는 것.
Refresh Token은 더이상 만료 기간이 긴 토큰이 아니게 된다. 따라서 불법적인 사용의 위험은 줄어든다.
출처:
https://inpa.tistory.com/entry/WEB-📚-JWTjson-web-token-란-💯-정리#token_인증 [Inpa Dev 👨💻:티스토리][https://velog.io/@chuu1019/%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90-JWTJson-Web-Token](https://velog.io/@chuu1019/%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90-JWTJson-Web-Token)
