Json Web Token의 약자로, 모바일이나 웹의 사용자 인증을 위해 사용하는 암호화된 토큰을 의미. JWT 정보를 리퀘스트에 담아서 사용자의 정보 열람, 수정 등 개인적인 작업 등을 수행할 수 있게 함
✔️ 애플리케이션이 실행될 때 JWT를 static 변수와 로컬 스토리지에 저장하게 됨.
static 변수에 저장하는 이유 ? HTTP 통신을 할 때마다 JWT를 HTTP 헤더에 담아서 보내야 하는데, 이를 로컬 스토리지에서 계속 불러오면 오버헤드가 발생하기 때문임.
JWT는 세 파트로 나누어지고, 각 파트는 .
으로 구분하여 표현함.
토큰의 타입과 해시 암호화 알고리즘
토큰에 담을 정보(registered claim + public claim + private claim)
서명은 헤더 + 페이로드 + secret key를 사용해서 JWT 백엔드에서 발행됨
각 요청 시 서명이 확인되고, 헤더 또는 페이로드의 정보가 클라이언트에 의해 변경된 경우 서명이 무효화 됨
기존 서버에 세션을 저장하는 방식에서 서버 여러 대를 사용하여 요청을 분산하였다면, 어떤 유저가 로그인했을 때 그 유저는 처음 로그인한 서버에만 요청을 내보내도록 설정해야 함. 하지만 토큰을 사용하면 토큰 값만 알고 있다면 어떤 서버로 요청이 들어가던 상관이 없음 !
✅ 토큰 기반 시스템은 유저의 인증 정보를 서버나 세션에 담아두지 않기 때문에 인증 정보를 서버에 담아둬서 생기는 문제점들이 해소가 됨
보안상 쿠키를 전달하지 않아도 되므로 쿠키를 사용함으로서 발생하는 취약점이 사라짐
여러 플랫폼 및 도메인 어플리케이션의 규모가 커지면 여러 디바이스를 호환시키고 더 많은 종류의 서비스를 제공함. 토큰을 사용한다면 그 어떤 디바이스에서도 도메인이 어떻든 토큰만 유효하다면 요청이 정상적으로 처리됨
claim에 넣는 데이터가 많아질수록 JWT 토큰이 길어짐. 길이가 길어지면 네트워크 대역폭 낭비가 심해짐
JWT는 페이로드에 대한 정보를 암호화하지 않아서 중간에 패킷을 가로채면 데이터를 볼 수 있게 됨. 그래서 JWE(JSON Web Encryption)을 통해 암호화하거나 중요 데이터를 페이로드에 넣으면 안됨.
JWT를 사용하는 가장 흔한 시나리오
사용자가 로그인 ➡️ 서버는 사용자의 정보를 기반으로 토큰을 발급 ➡️ 그 후, 사용자가 서버에 요청을 할 때마다 JWT를 포함하여 전달 ➡️ 서버는 클라이언트에서 요청을 받을 때마다 해당 토킁니 유효하고 인증됐는지 검증 및 권한 확인 후 작업 처리
✔️ 서버가 사용자가 로그인이 되어있는지 신경 쓸 필요 없이 사용자가 요청했을 때 토큰만 확인하면 되므로 세션 관리가 필요 없어서 서버 자원과 비용 절감 가능
제3자 인증방식
기본적으로 사용자는 서버를 신뢰할 수 없고, 서버 역시 사용자의 민감한 정보를 관리하는 것은 리소스가 필요함.
그래서 OAuth를 사용해서 신뢰할 수 있는 서버에게 정보를 맡겨놓고 접근할 수 있는 권한을 주는 것
쉽게 말해서, 고객이 안전하게 다른 서비스의 정보를 우리 서비스에 건네주기 위한 방법임.
고객이 자신의 네이버 아이디/비밀번호를 우리 서비스에 알려주지 않아도, 네이버에 있는 고객의 정보를 우리 서비스에서 안전하게 사용하기 위한 방법임
OAuth의 핵심은 Access Token임.
Access Token : 임의의 문자열 값인데, 이 문자열의 정체는 토큰을 발급해준 서비스만 알 수 있음.
✅ 이 Access Token을 이용해서 이 토큰 값과 관련된 고객의 정보를 우리는 해당 서비스에 요청할 수 있음. 해당 서비스는 이 토큰을 검증하고 발급된게 맞다면 해당 고객의 정보를 넘겨줌
즉, Access Token의 존재 자체가 고객이 정보를 넘겨주는 것을 동의함 의 징표임
어떻게 다른 서비스로부터 Access Token을 받을 수 있을까 ➡️ 다른 서비스가 건네주면 됨
예를 네이버로 들면,
네이버의 특정 고객의 Access Token을 받기 위해서는 특정 고객이 네이버 회원임을 인증해야 함. 인증하는 방법 ? 로그인하면 됨
그럼 로그인 하고 토큰 값을 어떻게 받아올래 ? 🤷🏻♀️
HTTP에는 리다이렉트 메세지가 존재함. 서버에서 클라이언트보고 어디로 가라고 지정해주는 것임
리다이렉트를 이용하면 고객이 가만히 있어도 웹브라우저가 알아서 페이지를 이동해줌. 고객이 직접 이동할 필요 ❌
고객이 로그인을 하고, 네이버에서 다시 우리 서비스로 리다이렉트를 해줄 때, URL에 묶어서 토큰값을 보내주면 됨
근데 리다이렉트 되야하는 URL을 우리가 네이버한테 알려줘야 함 ➡️ 똑같이 URL에 redirect_uri을 묶어서 보내주면 됨
💡 악의적인 사용자가 공격해서 redirect_uri을 자신이 원하는 사이트로 바꾸면 어떡하지 ? 🤷🏻♀️
각 사이트는 OAuth를 사용하기 위해 해당 서비스에 등록절차를 밟아야 함
redirect_uri도 사전에 미리 합의롤 보고 기입을 해둠. 이미 합의된 redirect_uri가 아닌 다른 값으로 로그인 요청 페이지한테 보냈다면 그 서비스에서는 정보를 주지 않음
OAuth는 프레임워크라서 비교하는 것이 맞지는 않지만, OAuth를 통해 나온 산출물과 JWT는 차이점이 분명함
✔️ OAuth Token
모호한 토큰임. 즉 어떠한 사용자의 정보 등과 같은 중요한 정보가 있는 명확한 정보를 가지고 있는 토큰이 아님. 그래서 OAuth Token을 사용하는 사용자는 이 토큰이 가지고 있는 정보에 대해서는 아는 바가 전혀 없음
✔️ JWT
얘는 모호한 토큰 ❌ 명확한 정보를 가지고 있음
출처 : https://tech.toktokhan.dev/2021/04/30/JWT/
https://mangkyu.tistory.com/56
https://velog.io/@undefcat/OAuth-2.0-%EA%B0%84%EB%8B%A8%EC%A0%95%EB%A6%AC