토큰 인증 방식
- 사용자는 아이디와 비밀번호로 로그인합니다.
- 서버 측은 클라이언트에 고유한 토큰을 발행합니다.
- 클라이언트는 토큰을 쿠키나 메모리에 저장하고 서버에 요청을 할 때 HTTP 요청 헤더에 토큰을 삽입하여 전송합니다.
- 서버는 받은 토큰을 확인하고 요청에 응답합니다.
토큰에는 요청자에 대한 정보가 포함되어 있기 때문에 서버는 DB를 조회하지 않고도 누가 요청했는지 알 수 있습니다.
토큰 방식의 단점
- 쿠키/세션과 달리 토큰 자체의 데이터 길이가 길기 때문에 인증 요청이 많을수록 네트워크 부하가 커집니다.
- 페이로드 자체가 암호화되지 않았기 때문에 중요한 정보를 포함할 수 없습니다.
- 토큰은 도난당했을 때 처리하기 어렵습니다. 따라서 유용한 수명을 제한함으로써 극복됩니다.
JWT(JSON 웹 토큰)
- 인증에 필요한 정보를 암호화하는 JSON 토큰
- 서버가 HTTP 헤더에 JWT 토큰을 포함하여 클라이언트를 식별하는 방법
- JSON 데이터는 Base64 URL-safe Encode로 인코딩 및 직렬화되며 개인 키가 포함된 디지털 서명도 토큰에 포함되어 위변조를 방지합니다.
- 사용자가 JWT 토큰을 서버로 보내면 서버는 서명 확인 과정을 거치고 확인이 완료되면 요청한 응답을 반환합니다.
- 헤더, 페이로드 및 서명으로 구성됩니다.
- 서명은 토큰이 위조 또는 변경되었는지 확인하는 데 사용됩니다.
- 서버는 서버의 키 값을 사용하여 클라이언트로부터 받은 JWT 헤더와 페이로드의 서명을 다시 생성하고 비교하고 일치하면 인증을 통과합니다.
JWT는 Base64로 인코딩되므로 디버거를 통해 직접 해독할 수 있습니다.
페이로드 부분은 복호화를 통해 바로 드러나기 때문에 비밀번호와 같은 민감한 정보는 포함되어서는 안됩니다.
왜냐하면! 토큰의 목적은 정보 보호가 아니라 위조 방지입니다.
서명에 사용된 개인키가 공개되지 않는 한 데이터가 위조되더라도 즉시 서명 부분에서 필터링됩니다.
JWT 토큰 인증 방법
- 사용자는 ID와 PW를 입력하여 서버에 로그인 인증을 요청합니다.
- 서버는 클라이언트로부터 요청을 받으면 액세스 토큰과 새로 고침 토큰을 발급합니다.
- 헤더, 페이로드 및 서명을 정의합니다.
헤더, 페이로드 및 서명은 쿠키에 배치되고 클라이언트에 출력되는 JWT를 생성하기 위해 다시 Base64로 인코딩됩니다.
- 헤더, 페이로드 및 서명을 정의합니다.
- 클라이언트는 서버에서 받은 JWT를 로컬 저장소(쿠키 또는 다른 위치)에 저장합니다.
- 클라이언트가 서버에 요청하면 액세스 토큰이 포함된 인증 헤더를 보냅니다.
- 서버는 헤더에 있는 클라이언트가 보낸 JWT가 서버에서 발급한 토큰인지 확인하여 일치하면 인증에 통과하고 그렇지 않으면 인증에 실패합니다.
- 클라이언트가 서버에 요청할 때 액세스 토큰시간이 되면 고객은 갱신 토큰새 액세스 토큰도 서버에서 발급됩니다.
JWT 혜택
- 모바일 애플리케이션 환경에서도 잘 작동합니다.
- 서명은 헤더와 페이로드로 생성되므로 데이터 위변조를 방지할 수 있습니다.
- 토큰에 대한 기본 정보, 전송할 정보, 토큰이 검증되었음을 증명하는 서명 등 필요한 모든 정보를 가지고 있습니다.
- 별도의 인증 정보 저장이 필요하지 않습니다.
JWT 단점
- 더 큰 토큰 길이는 네트워크에 부담을 줄 수 있습니다.
- 페이로드 자체가 암호화되지 않고 Base64로 인코딩되어 있기 때문에 중간에 페이로드를 훔치면 데이터를 볼 수 있으니 중요한 데이터는 페이로드에 넣지 말아야 합니다.
- 토큰 자체를 도난 당하면 대처하기 어렵습니다.
- 액세스 토큰만 사용하는 경우 토큰을 획득한 사람은 토큰이 만료될 때까지 액세스 권한을 얻을 수 있습니다.
- 토큰은 갈취 문제에 대응하기 위해 만료 시간이 있지만 유효 기간이 짧으면 사용자가 자주 로그인해야 합니다.
- 따라서 보안을 강화하기 위해 새로 고침 토큰을 사용합니다.
액세스 토큰 및 새로 고침 토큰
JWT는 토큰 도용의 위험도 있기 때문에 이를 액세스 토큰과 새로 고침 토큰으로 구분하여 인증하는 방식이 실무에 널리 퍼져 있습니다.
최초 로그인 시 Access Token과 동시에 발급되는 Refresh Token은 유효기간이 길고 Access Token을 재발급하는 토큰 역할을 합니다.
예시) Refresh 토큰 수명을 2주로 설정하고 액세스 토큰 수명을 1시간으로 설정한 경우,
액세스 토큰이 1시간 후에 만료되더라도 새로 고침 토큰의 만료일까지 새로운 액세스 토큰을 발급받을 수 있습니다.
액세스 토큰의 도난 위험은 동일하지만 짧은 유효 기간 내에서만 사용할 수 있으므로 조금 더 안전합니다.
액세스 토큰: 클라이언트가 보유한 실제 사용자 정보를 포함하는 토큰입니다. 클라이언트로부터 요청을 받으면 서버는 토큰의 정보를 사용하여 사용자 정보에 적절하게 응답합니다.
갱신 토큰: 새로운 엑세스 토큰을 발급하기 위해 사용하는 토큰으로 수명이 짧은 엑세스 토큰에 대한 새로운 토큰을 발급하기 위해 사용합니다. 토큰은 일반적으로 사용자 정보와 함께 데이터베이스에 기록됩니다.
JWT 토큰 인증 방법 액세스 토큰 + R업데이트 토큰
참조
(WEB) JWT 토큰 인증이란? – 이해하기 쉬운
인증 방법 유형(쿠키 & 세션 & 토큰) 일반적으로 서버가 클라이언트 인증을 확인하는 데는 쿠키, 세션 및 토큰의 세 가지 방법이 있습니다. JWT를 배우기 전에 먼저 쿠키와 세션이 통신하는 방식을 검토하십시오.
inpa.tistory.com
서버인증 2부(액세스토큰 + 리프레시토큰)
안녕하세요! 이전 포스트에서는 세션/쿠키 인증과 토큰 기반 인증(주로 JWT)에 대해 알아보았습니다. 앱, 웹 또는 서버를 개발할 때 사용해야 하는 권한 부여는 매우 중요합니다.
tansfil.tistory.com
OAuth 서버 인증 방식
서버 인증 3부(SNS 로그인, OAuth 2.0)
여러분, 안녕하세요. 오늘은 기본인증의 마지막 단계인 SNS 로그인과 OAuth에 대해 써보려고 합니다. SNS 로그인을 구현해 본 적이 있다면 OAuth에 대해 들어봤을 것입니다.
tansfil.tistory.com
전면에서 보안 로그인(ft. React)
LocalStorage냐 쿠키냐 그것이 문제로다
velog.io