Laravel API 에서 깨진 auth 흐름을 처음으로 디버깅해야 했을 때,신뢰할 수 있는 토큰을 생성할 수 없어서 오후 시간을 낭비했습니다. 미들웨어는 계속 401 을 반환했고,버그가 내 인증 코드에 있는지,아니면 내가 공급하고 있는 토큰에 있는 특정 기능을 갖춘 알려진 좋은 JWT 가 필요했습니다 sub특정 만료와 내가 제어한 비밀로 인해 문제의 한 측면을 분리할 수 있었습니다. 스택 오버플로 답변에서 무작위 토큰을 복사하면 도움말과 반대가 됩니다. 왜냐하면 내가 가지고 있지 않은 비밀로 서명되었기 때문입니다.
그것이 JWT 생성기가 채우는 간격입니다. 프로덕션 서명 서비스가 아닙니다. JSON 웹 토큰을 소비하는 것을 구축하거나 테스트하는 순간을위한 벤치 도구이며 정확한 주장과 선택한 정확한 비밀과 함께 유효한 온디맨드가 필요합니다. 이 가이드는 도구가 작동하는 방식,JWT 가 조립되고 서명되는 방식,그리고 손으로 토큰을 생성하는 실제 사례를 통해 실시간으로 시간을 절약 할 수 있습니다.
TL;DR: JWT 생성기는 JSON 페이로드와 비밀을 서명된 토큰으로 바꿉니다. 클레임을 붙여넣고 HS256,HS384 또는 HS512 를 선택하고 비밀을 입력한 후 토큰을 복사합니다. The JWT 발전기 브라우저 Web Crypto API 로 서명하므로 페이로드와 비밀이 기계를 떠나지 않습니다. 이를 사용하여 알려진 테스트 토큰을 만듭니다
sub, 정해진 만료 또는 고의로 만료된 경우expAPI's 오류 경로를 실행하려면 토큰을 다시 읽으려면 토큰과 페어링하십시오 JWT 디코더.
JWT 란 무엇이며 발전기는 무엇을 생산합니까?
JSON 웹 토큰은 일련의 주장을 나타내는 URL 안전 컴팩트 한 방법입니다. 구조는 RFC 7519 에 의해 정의되며,서명 된 양식은 거의 모든 사람들이 "a JWT,"에 의해 정의 된 JSON 웹 서명입니다. 서명 된 토큰은 점으로 연결된 세 부분으로 구성됩니다: header.payload.signature.
헤더는 서명 알고리즘과 토큰 유형의 이름을 지정하는 작은 JSON 개체입니다 { "alg": "HS256", "typ": "JWT" }. 페이로드는 주장의 JSON 객체입니다: 토큰이 누구에 관한 것인지,만료될 때,그리고 애플리케이션이 추가하는 사용자 정의 필드가 무엇이든지 헤더와 페이로드 모두 Base64url 로 인코딩되어 있으며,이는 RFC 7515 가 지정하는 것과 정확히 같이 두 문자 대체가 있고 패딩이 없는 일반 base64 서명입니다. 처음 두 부분에 대해 계산된 키 해시입니다.
생성기는 세 가지를 모두 조립합니다. 페이로드와 비밀을 공급하고 헤더를 만들고 두 세그먼트를 모두 인코딩하고 서명을 계산하고 결합합니다. 출력은 곧바로 a에 놓을 수 있는 문자열입니다 Authorization: Bearer 헤더, 테스트 픽스처 또는 a curl 명령어.
앞에서 직설적으로 말할 가치가있는 한 가지: 서명 된 JWT 는 암호화되지 않고 인코딩됩니다. 토큰을 보유한 사람은 누구나 Base64url-페이 로드를 디코딩하고 그 안에있는 모든 주장을 읽을 수 있습니다. 서명은 내용을 숨기지 않습니다. 단지 그 내용이 누군가가 열쇠없이 변경되지 않았 음을 증명합니다. 암호,API 키 또는 JWT 페이로드 안에 사용자를 표시하지 않을 다른 것을 넣지 마십시오.
서명은 어떻게 진행되나요?
이 도구가 서명하는 HMAC 제품군의 경우 서명은 다음과 같습니다 HMAC(secret, header + "." + payload). HMAC 는 RFC 2104 에 의해 정의된 키 해시 구성이며,JWA 사양인 RFC 7518 은 세 개의 JWT 알고리즘 이름을 여기에 매핑한다: HS256 은 SHA-256 과 함께 HMAC 를 사용하고,HS384 는 SHA-384 를 사용하며,HS512 는 SHA-512 를 사용한다.
중요한 속성은 대칭입니다. 동일한 비밀이 서명을 생성하고 확인합니다. 서버가 토큰을 받으면 다시 계산됩니다 HMAC(secret, header + "." + payload) 수신된 처음 두 세그먼트에 대해 결과가 서명 세그먼트와 동일한지 확인합니다. 페이로드의 단일 바이트가 변경된 경우 재계산된 해시가 일치하지 않고 확인이 실패합니다. 이것이 전체 무결성 보장입니다.
대칭이기 때문에,비밀은 전체적인 게임이다. 비밀을 가진 사람은 누구나 당신의 시스템을 위한 유효한 토큰을 주조할 수 있다,그래서 발전기는 웹 암호 API 를 통해서 당신의 브라우저에서 서명을 달리고 결코 아무데도 비밀을 전송하지 않는다. 당신은 당신의 browser's 네트워크 탭을 열어서 이것을 확인할 수 있다 당신이 토큰을 생성하는 동안: 아무 요구도 없다. 이것은 소리가 나는 보다는 더 많은 것,왜냐하면 집에 전화가 당신의 인증에 열쇠를 넘겨줄 무작위 웹 공구에 살아있는 생산 서명 비밀을 풀기 때문이다.
비대칭 알고리즘인 RS256 과 ES256 은 다르게 작동합니다: 개인 키 기호와 일치하는 공개 키가 확인합니다. 많은 서비스가 토큰을 확인해야 하지만 하나만 발행할 수 있어야 할 때 올바른 선택이 됩니다. 이 도구는 의도적으로 이를 제공하지 않습니다. 왜냐하면 이들과 서명한다는 것은 개인 키를 웹 페이지에 붙여넣는 것을 의미하며 이는 결코 시작할 가치가 없는 습관이기 때문입니다.
JWT Generator 사용법
1 단계: 페이로드 쓰기
주장을 JSON 개체로 입력합니다. 최소한의 예는 { "sub": "1234567890", "role": "admin" }. 그만큼 sub 클레임은 주체이며,일반적으로 사용자 id 입니다. 다음과 같이 응용 프로그램이 읽는 사용자 지정 필드를 추가할 수 있습니다 role, scope, tenant_id, 또는 email. 도구는 여기에 넣은 모든 것을 쓰여진 그대로 유지합니다.
2 단계: 시간 주장을 추가합니다
발행 후 공구 스탬프를 남겨주세요 iat 현재 Unix 시간으로. 만료일을 초 단위로 설정하여 an을 추가합니다 exp 지금 계산된 클레임에 해당 오프셋을 더한 값입니다. 15 분 액세스 토큰의 경우 900 을 입력합니다. 1 시간 토큰의 경우 3600 을 입력합니다. 이러한 클레임은 대부분의 인증 버그가 귀결되므로 밀리초가 아닌 에포크 이후 몇 초 만에 올바르게 계산하면 일반적인 실수가 제거됩니다.
3 단계: 알고리즘과 비밀을 선택합니다
HS384 또는 HS512 를 사용할 이유가 없는 한 HS256 을 선택합니다. 필드에 서명 비밀을 입력합니다. 그런 다음 비밀이 해석되는 방식을 선택합니다: 일반 텍스트는 입력한 UTF-8 바이트를 사용하는 반면 base64url 및 hex는 문자열을 먼저 원시 바이트로 디코딩합니다. 많은 시스템이 이미 base64 로 인코딩된 비밀을 저장하고 인코딩된 문자열을 일반 텍스트로 입력하면 일치하지 않는 서명을 생성하기 때문에 이 선택이 중요합니다.
4 단계: 토큰 복사
서명된 JWT 는 헤더와 페이로드의 디코딩된 미리보기와 함께 나타나므로 사용하기 전에 모든 클레임을 확인할 수 있습니다. 복사하여 필요한 곳에 붙여넣습니다.
토큰을 손으로 생성하는 이유는 무엇입니까?
당신의 API's 행복한 경로를 테스트합니다
JWTs 의 유효성을 검사하는 미들웨어를 작성할 때 코드가 수락해야 하는 토큰이 필요합니다. verifier 가 사용하는 것과 동일한 비밀로 서명된 토큰을 valid 로 생성합니다 exp를,그리고 요청을 확인하면 200 을 반환합니다. 그렇지 않은 경우 버그는 토큰이 아닌 확인 논리에 있습니다. 이 단일 격리 단계는 내가 가장 자주 도구에 도달하는 이유입니다.
실패 경로 테스트
강력한 API 는 올바른 이유로 올바른 토큰을 거부합니다. X 로 토큰 생성하기. X 로 토큰 생성하기 exp 이미 과거에 올바른 만료된 토큰 오류를 반환했는지 확인합니다. generate one with a nbf 아직 유효하지 않은 경로를 테스트하기 위해 미래에. 서명 확인 실행을 확인하기 위해 잘못된 비밀로 서명 된 하나를 생성하십시오. 이러한 부정적인 경우는 테스트되지 않은 상태로 배송되는 경우이며 생성기는 32 번째 작업으로 만듭니다.
특정 사용자의 버그를 재현합니다
지원은 특정 역할을 가진 계정에서만 발생하는 문제를 보고합니다. 정확한 토큰 생성 role 클레임 및 영향을 받은 사용자's sub그리고 프로덕션 데이터를 건드리거나 사용자에게 실제 베어러 토큰을 요청하지 않고도 로컬로 요청을 재현할 수 있습니다. 어쨌든 절대 해서는 안 됩니다.
파종 지역 개발
팀의 새로운 개발자는 프런트 엔드 인증이 아직 구축되는 동안 보호된 엔드포인트를 적중하기 위해 작업 토큰이 필요합니다. 로컬 개발 비밀로 서명된 생성된 토큰은 즉시 차단을 해제합니다.
HS256 vs HS384 vs HS512: 어떤 것을 사용해야 합니까?
| 알고리즘 | 해시 | 서명 크기 | 최소 키 길이 | 언제 사용할 것인가 |
|---|---|---|---|---|
| HS256 | SHA-256 | 32 바이트 | 32 바이트 | 기본값. 빠르고 광범위하게 지원되며 거의 모든 용도에 안전합니다 |
| HS384 | SHA-384 | 48 바이트 | 48 바이트 | 정책이나 표준에 SHA-384가 필요한 경우 |
| HS512 | SHA-512 | 64 바이트 | 64 바이트 | 높은 보안 컨텍스트, 또는 이미 SHA-512 에 표준화 된 경우 |
실제적인 대답은 HS256 입니다. 외적인 어떤 것이 다르게 요구하지 않는 한. RFC 7518 은 키가 적어도 해시 출력만큼 길어야 하므로 HS256 의 경우 32 바이트,HS384 의 경우 48,HS512 의 경우 64 바이트입니다. 생성기는 디코딩된 비밀이 최소값보다 짧을 때 경고합니다. 왜냐하면 짧은 키는 알고리즘 이름에 관계없이 서명을 약화시키기 때문입니다. 더 길고,숫자가 높은 알고리즘은 약한 비밀을 고치지 않습니다; 적절한 길이의 무작위 비밀이 중요합니다.
일반적인 실수와 그것을 피하는 방법
가장 빈번한 것은 인코딩으로 인한 비밀 불일치입니다. 프레임워크는 비밀을 base64 로 저장하고 base64 문자열을 일반 텍스트로 붙여 넣으며 이제 키 바이트는 검증자가 사용하는 것과 다릅니다. 서명은 결코 일치하지 않으며 팬텀 버그를 추적하여 도구에서 올바른 비밀 인코딩을 선택하여 수정하므로 원시 키 바이트는 양쪽에서 동일합니다.
두 번째는 초와 밀리초를 혼동하는 것입니다. RFC 7519 에 등록된 시간 클레임은 모두 유닉스 시대 이후 초 단위로 측정됩니다. JavaScript's Date.now() 밀리초를 반환합니다. 계산하면 exp 자신과 1000 로 나누는 것을 잊어 버리면 토큰이 지금부터 5 만 년 후에 만료되는 것처럼 보이며 일부 엄격한 검증자는 거부합니다. 생성기가 주장을 계산하도록하면이를 완전히 피할 수 있습니다.
세 번째는 페이로드를 비공개로 취급하는 것입니다. 그렇지 않습니다. 클레임에 비밀을 저장하려는 유혹을 받으면 중지하십시오. 토큰을 가진 사람은 누구나 읽을 수 있습니다. 토큰 소유자가 보는 것이 편한 것만 저장하고 서버에 진정한 비밀 데이터를 보관하십시오.
JWT가 다른 도구와 함께 적합한 곳
토큰을 생성한 후에는 자연스럽게 다음 단계로 다시 읽어보시기 바랍니다. The JWT 디코더 모든 토큰을 헤더와 페이로드로 분할하고 만료된 토큰을 표시합니다 exp는, 당신이 당신이 의도한 무슨을 생성한 발전기를 확인하는 방법 입니다. 당신이 또한 비밀을 생성하는 경우에, the 해시 생성기 SHA 해시를 클라이언트 측에서 계산합니다 비밀번호 생성기 좋은 HMAC 비밀을 만드는 긴 임의의 문자열의 종류를 생산 처음에. 당신이 Base64url 단계 손으로 이해하려는 경우, 그만큼 Base64 인코더/디코더 헤더와 페이로드를 인코딩된 형태로 바꾸는 동일한 가역 변환을 보여줍니다. 그리고 a 에 드롭하기 위해 임의의 식별자가 필요할 때 sub 또는 jti 주장, 그만큼 UUID 생성기 당신에게 올바른 형식으로 하나를 제공합니다.
브라우저 기반 도구가 민감한 자료를 타사 서버에서 차단하는 이유에 대한 더 넓은 그림을 보려면, 온라인 도구의 데이터 개인 정보 보호 가이드는 클라이언트측 모델을 설명합니다 웹 개발자 툴킷 토큰 작업과 잘 페어링되는 유틸리티를 반올림합니다.
서버는 생성한 토큰을 어떻게 확인합니까?
다른 쪽에서 무슨 일이 일어나는지 아는 것이 도움이 되는데,왜냐하면 비밀과 주장이 정확히 맞아야 하는지를 설명하기 때문이다. API 가 토큰을 받으면 jsonwebtoken,jose, PyJWT 같은 라이브러리가 순서대로 세 가지 토큰을 점으로 분할하고 Base64url-헤더를 디코딩하여 읽는다 alg. 그것은 서명을 다시 계산합니다 header.payload 구성된 비밀을 사용하여 서명 세그먼트에 대해 바이트에 대한 바이트를 비교합니다. 그리고 등록된 주장을 확인합니다: 입니다 exp 과거에는, 는 nbf 미래에는 그렇습니다 iss 그리고 aud API 가 기대하는 것과 일치.
그 검사들 하나하나가 생성기가 제어하게 하는 무언가에 매핑됩니다. 서명에 대한 확인이 실패하면 비밀이나 그 인코딩은 양쪽에 다릅니다. 실패하면 exp는, 토큰이 만료되었습니다, 당신은 그 경로를 테스트하기 위해 의도적으로 발생했을 수 있습니다. 에 실패하는 경우 alg를 사용하면 검증자가 수락하도록 구성되지 않은 알고리즘으로 토큰을 생성했는데,이는 그 자체로 발견하기에 유용한 것입니다. 의도적인 변형으로 토큰을 생성하는 것은 API 가 시행하는 검사와 자동으로 건너뛰는 검사를 정확하게 매핑하는 방법입니다.
에 대한 단어입니다 alg 헤더 구체적으로. RFC 7515 정의 none 서명되지 않은 토큰에 대한 유효한 알고리즘으로서 초기 라이브러리는 주장된 토큰을 신뢰합니다 alg: none 그리고 검증을 완전히 건너뜁니다. 이것이 고전적인 JWT 취약점입니다. 최신 라이브러리는 기본적으로 이를 거부하지만 생성기는 다음을 제공합니다 none API에서 서명되지 않은 토큰을 실행하고 아니요라고 확인할 수 있도록 정확하게 옵션을 선택하세요. API가 이를 수락하면 심각한 버그를 발견한 것입니다.
비밀과 토큰 스토리지를 어떻게 처리해야합니까?
서명하는 비밀은 데이터베이스 암호와 같은 주의를 기울일 가치가 있습니다. 좋은 HMAC 비밀은 기억에 남는 문구가 아닌 길고 무작위적인 문자열입니다. HMAC 보안은 추측할 수 없는 키에 따라 달라지기 때문입니다. 암호 도구로 하나를 생성하고 소스 제어가 아닌 환경 구성에 저장하는 것이 기준선입니다. 회전할 때 이전 비밀로 서명된 모든 토큰은 검증자가 전환하는 순간 무효가 된다는 점을 기억하십시오. 이것이 바로 생산 시스템이 일반적으로 회전 창에서 하나 이상의 유효한 비밀을 지원하는 이유입니다.
클라이언트 측에서는,완성된 토큰을 저장하는 곳이 서명 방법만큼 중요합니다. A token in localStorage 는 페이지의 모든 JavaScript 에서 읽을 수 있으므로 단일 크로스 사이트 스크립팅 결함으로 인해 공격자에게 유효한 자격 증명이 전달됩니다. An httpOnly, Secure, SameSite 쿠키는 스크립트에 보이지 않으며,이는 CSRF 보호가 필요한 비용으로 해당 경로를 닫습니다. 일반적인 패턴은 메모리에 보관된 수명이 짧은 액세스 토큰과 an 에서 수명이 긴 새로 고침 토큰입니다 httpOnly 쿠키. 이 중 어느 것도 토큰을 생성하는 방법을 변경하지 않지만 생성된 토큰을 책임보다는 안전하게 사용할 수 있도록 하는 것은 컨텍스트입니다.
자주 묻는 질문
JWT를 어떻게 생성하나요?
주장을 JSON 객체로 붙여넣고,HS256 과 같은 서명 알고리즘을 선택하고,비밀을 입력합니다. 도구 base64url-헤더와 페이로드를 인코딩하고,HMAC 서명을 계산하고,복사할 수 있도록 완성된 토큰을 반환합니다. 모든 것이 브라우저에서 실행됩니다.
어떤 서명 알고리즘이 지원됩니까?
HS256,HS384, HS512,HMAC 제품군,그리고 서명되지 않은 "none" 테스트용 옵션. RS256 과 ES256 은 개인 키로 서명하기 때문에 의도적으로 제공되지 않으며,개인 키를 웹 페이지에 붙여넣는 것은 보안 위험을 가장 잘 피할 수 있습니다.
내 비밀이 서버로 전송되나요?
아니요. 서명 작업은 Web Crypto API 를 통해 브라우저에서 완전히 실행되므로 비밀과 페이로드는 장치에서 절대 벗어나지 않습니다. DevTools 네트워크 탭에서 확인할 수 있으며,이 도구는 로드된 후에도 오프라인으로 계속 작동합니다.
토큰이 만료되도록 설정하려면 어떻게 해야 하나요?
몇 초 안에 만료 기간을 입력하면 도구에 다음이 추가됩니다 exp 현재 시간에 그 많은 초를 더한 것과 같은 주장을 합니다. 15 분 토큰의 경우 900 을 입력합니다. 생략하려면 필드를 비워 두십시오 exp 전적으로.
왜 비밀이 최소 32 바이트가 되어야 하는가?
RFC 7518 은 적어도 해시 출력만큼 HMAC 키가 필요하며,이는 HS256 의 경우 32 바이트,HS384 의 경우 48 바이트,HS512 의 경우 64 바이트입니다. 더 짧은 비밀은 서명을 약화 시키므로 도구는 디코딩 된 비밀이 너무 짧을 때 경고합니다.
서명되지 않은 토큰을 만들 수 있습니까?
예. alg none 을 선택하면 도구가 빈 서명이 있는 header.payload. token 을 생성합니다. 이는 API 가 서명되지 않은 토큰을 처리하는 방법을 테스트하기 위한 것일 뿐입니다; 대부분의 라이브러리는 기본적으로 alg: none 을 거부하며,당신도 그렇게 해야 합니다.
생성된 JWT는 암호화되어 있나요?
아니요. 서명된 JWT 는 암호화되지 않고 인코딩됩니다: 누구나 헤더와 페이로드를 base64url-디코딩하고 모든 클레임을 읽을 수 있습니다. 서명은 내용이 변경되지 않았음을 증명할 뿐입니다. 페이로드 안에 암호나 비밀을 넣지 마십시오.
