100% 브라우저 메모리 연산 • 서버 로그 수집 제로 • 즉각적인 실행
Curious Techie개발자 툴박스
Security & AuthenticationIETF RFC 7519 Section 4✓ 빠른 조회 매트릭스 표 (7 개 항목) • KO

JWT 클레임 (Claims) 레퍼런스

RFC 7519 공식 표준 등록 클레임 및 공개 속성 일람

CT
Curious-Techie Engineering Team검증된 작성자

Web Protocols & Security Architecture Research

발행일:
•
수정일:
•6 min read
공식 기술 규격:RFC 9110(IETF)
검토자: Curious-Techie Architecture Peer Review Group

개요 및 범위

RFC 7519 표준은 HTTP 헤더 전송 시 크기를 최소화하기 위해 3글자로 축약된 표준 예약 키(iss, sub, exp 등)를 지정하여 상호 운용성을 보장합니다.

표준 규격표 및 매트릭스

키워드, 상태 코드 또는 지시문 이름으로 실시간 검색

키 / 코드정의 및 세부사항GEO 시맨틱 계층표준 규격 및 참고
iss
iss (Issuer)

Identifies the principal that issued the JWT (e.g. auth.example.com).

"iss": "https://auth.example.com"
●iss
↳JWT claim
↳registered claim
↳token authority issuer
RFC 7519 §4.1.1

Case-sensitive string or URI; receivers must verify this matches their trusted identity provider.

sub
sub (Subject)

Identifies the principal that is the subject of the JWT (e.g. user ID).

"sub": "usr_948194a2b"
●sub
↳JWT claim
↳registered claim
↳principal subject identifier
RFC 7519 §4.1.2

Must be locally unique in the context of the issuer or globally unique.

aud
aud (Audience)

Identifies the recipients that the JWT is intended for (e.g. client ID or API service URI).

"aud": "https://api.example.com/v1"
●aud
↳JWT claim
↳registered claim
↳intended recipient scope
RFC 7519 §4.1.3

If the receiving service is not present in the aud claim, the token MUST be rejected.

exp
exp (Expiration Time)

Identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

"exp": 1791244800
●exp
↳JWT claim
↳registered claim
↳expiration timestamp limit
RFC 7519 §4.1.4

Must be a NumericDate integer (seconds since Unix epoch: 1970-01-01T00:00:00Z UTC).

nbf
nbf (Not Before)

Identifies the time before which the JWT MUST NOT be accepted for processing.

"nbf": 1791241200
●nbf
↳JWT claim
↳registered claim
↳activation timestamp limit
RFC 7519 §4.1.5

NumericDate integer; useful for future-dated activation of subscription passes.

iat
iat (Issued At)

Identifies the time at which the JWT was created and issued.

"iat": 1791241200
●iat
↳JWT claim
↳registered claim
↳token generation timestamp
RFC 7519 §4.1.6

Can be used to determine age of the token or revoke tokens issued prior to a password change.

jti
jti (JWT ID)

Provides a unique identifier for the JWT; useful for one-time tokens and replay prevention.

"jti": "d3b07384-d113-46d4-8da8-da2b7a0f968a"
●jti
↳JWT claim
↳registered claim
↳unique token nonce identifier
RFC 7519 §4.1.7

Allows servers to maintain a blacklist of revoked jti UUIDs.

기술 예제 및 실행 코드

Decoded JWT Payload Example with Standard Claims

json코드 복사
{
  "iss": "https://auth.curious-techie.com",
  "sub": "user_01HZX87QW5B",
  "aud": "https://api.curious-techie.com",
  "exp": 1791244800,
  "nbf": 1791241200,
  "iat": 1791241200,
  "jti": "9f8c6e2b-4a51-419b-b0b3-1e52f75a6c38",
  "role": "admin",
  "email": "alex@curious-techie.com"
}

All registered timestamps are in seconds since 1970 (not milliseconds), adhering to RFC 7519 NumericDate format.

자주 묻는 질문 (FAQ)

표준 규격 Q&A

Are JWT claims encrypted by default?↓
No! Standard JWTs (JWS) are digitally signed, but NOT encrypted. Anyone can Base64URL-decode the payload and read the claims. Never store private passwords or secret keys in JWT claims.
Authoritative Sourcing & Verification

References & Primary Sources

Every source below directly substantiates technical statements and protocol behaviors explained in JWT 클레임 (Claims) 레퍼런스. Curious-Techie prioritizes official Internet standards (IETF RFCs, W3C Recommendations, WHATWG specifications) and established security bodies (OWASP, NIST). Zero sponsored or secondary links.

  1. [1]IETFPrimary SpecificationRFC 7519 • Section 3 & 4
    Verified Primary Source
    Technical Claim Supported:

    Defines the compact, URL-safe format of JSON Web Tokens consisting of three Base64URL segments (Header, Payload, Signature) and registered claims (iss, sub, aud, exp, nbf, iat, jti).

    “A JWT is represented as the concatenation of the Encoded JWT Header, the Encoded JWT Claims Set, and the Encoded JWT Signature or Encoded JWT Encryption Data, with the parts being separated by period ('.') characters.”
  2. [2]IETFPrimary SpecificationRFC 7515 • Section 4 (Cryptographic Signatures)
    Verified Primary Source
    Technical Claim Supported:

    Defines digital signatures and MAC algorithms (HS256, RS256, ES256) used to secure JWT integrity and verify token authorship.

  3. [3]IETFAuthoritative Security StandardRFC 8725 • Security Considerations § 3
    Verified Primary Source
    Technical Claim Supported:

    Mandates explicit algorithm validation on receiving servers, prohibiting the insecure "alg: none" algorithm and enforcing strict signature verification.

  4. [4]OWASPAuthoritative Security StandardOWASP Cheat Sheet Series • Token Storage & Revocation
    Verified Primary Source
    Technical Claim Supported:

    Details token theft mitigation, recommending storage in secure HttpOnly cookies over localStorage and outlining token revocation strategies.