Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Tink hỗ trợ tạo và xác minh JWT, đây là một tiêu chuẩn được sử dụng rộng rãi trên web. Việc triển khai JWT của Tink cung cấp một tập hợp con của tiêu chuẩn JWT được xác định trong RFC 7519 mà nhóm Tink cho là an toàn khi sử dụng và phù hợp với thư viện Tink.
Tink không hỗ trợ những phần của tiêu chuẩn ít được sử dụng hoặc khó sử dụng đúng cách. Sau đây là những điểm hạn chế:
Tink chỉ hỗ trợ các tiêu đề typ, alg và kid. Tất cả các tiêu đề khác đều không được hỗ trợ.
Tink không cho phép phân tích cú pháp mã thông báo trước khi chữ ký hoặc MAC được xác minh.
Chữ ký JWT
Nếu mã thông báo được tạo và xác minh bởi các thực thể khác nhau, thì bạn nên sử dụng các khoá bất đối xứng với các nguyên tắc JwtPublicKeySign và JwtPublicKeyVerify.
Khoá riêng tư được dùng để tạo mã thông báo và khoá công khai được dùng để xác minh mã thông báo. Thuật toán được các nguyên tắc này hỗ trợ là: ES256, ES384, ES512, RS256, RS384, RS512, PS256, PS384 và PS512.
Chọn một loại khoá
Chữ ký JWT sử dụng các loại khoá khác với chữ ký số thông thường trong Tink. Điều này là cần thiết vì một số siêu dữ liệu (chẳng hạn như alg và kid) cần được lưu trữ bằng khoá.
Bạn nên sử dụng JWT_ES256 cho hầu hết các trường hợp sử dụng. Mã thông báo được tạo bằng loại khoá này luôn có tiêu đề kid. Nếu bạn muốn mã thông báo ngắn hơn một chút mà không có tiêu đề kid, hãy chọn loại khoá JWT_ES256_RAW. Để biết tất cả các loại khoá được hỗ trợ, hãy xem phần Các loại khoá được hỗ trợ.
Phân phối bộ khoá công khai
Tink cho phép chuyển đổi các khoá công khai sang và từ định dạng JWK Sets được xác định trong RFC 7517 mà hầu hết các thư viện JWT đều hiểu.
Tink không hỗ trợ xuất khoá JWT công khai ở bất kỳ định dạng nào khác. Lý do là các định dạng khác không chứa siêu dữ liệu alg và kid để dùng trong quá trình xác minh. Điều này khiến việc sử dụng các định dạng đó dễ xảy ra lỗi hơn và có thể khiến việc xoay khoá trở nên khó khăn hơn.
Tốt nhất là bạn không chỉ chia sẻ bộ khoá công khai một lần mà còn cung cấp cách tự động cập nhật bộ khoá công khai. (Nếu không, việc xoay sang một khoá mới sẽ rất khó.) Việc này thường được thực hiện bằng cách xuất bản bộ khoá công khai trên một URL đáng tin cậy và bảo mật. Sau đó, máy chủ xác minh mã thông báo phải định kỳ tìm nạp lại bộ khoá công khai từ URL đó, ví dụ: mỗi ngày một lần. Để xoay khoá, bạn cần thêm khoá công khai mới vào bộ khoá công khai ít nhất một ngày trước khi khoá này được dùng để ký mã thông báo. Nếu không, các mã thông báo mới được ký bằng khoá riêng tư mới sẽ bị các máy chủ vẫn sử dụng bộ khoá công khai cũ từ chối.
JWT MAC
Tink cũng hỗ trợ JWT bằng các khoá đối xứng với nguyên thuỷ JwtMac. Chỉ sử dụng nguyên tắc cơ bản này nếu mã thông báo được tạo và xác minh bởi cùng một thực thể. Các thuật toán được hỗ trợ bởi nguyên tắc này là HS256, HS384 và HS512.
Chọn một loại khoá
Các loại khoá MAC JWT khác với các loại khoá MAC thông thường. Bạn nên sử dụng JWT_HS256 cho hầu hết các trường hợp sử dụng.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-07-25 UTC."],[[["\u003cp\u003eTink supports creating and validating JSON Web Tokens (JWTs) using a secure subset of the RFC 7519 standard.\u003c/p\u003e\n"],["\u003cp\u003eIt offers both asymmetric and symmetric key cryptography options for signing and verifying JWTs, with various algorithms like ES256, RS256, HS256, and others.\u003c/p\u003e\n"],["\u003cp\u003eTink emphasizes secure key management practices, including using distinct key types for JWTs and enabling public keyset distribution in the JWK Sets format for easier sharing and rotation.\u003c/p\u003e\n"],["\u003cp\u003eHowever, it has certain limitations, such as supporting only the JWS Compact Serialization format and specific headers, while excluding features like JWE and the 'None' algorithm.\u003c/p\u003e\n"],["\u003cp\u003eFor optimal security, Tink enforces signature/MAC verification before parsing tokens and recommends periodic public keyset updates to facilitate key rotation and minimize disruptions.\u003c/p\u003e\n"]]],["Tink supports generating and verifying JWTs, implementing a secure subset of the standard. It utilizes JWS Compact Serialization, excluding JWS JSON Serialization and JWE. Supported headers are `typ`, `alg`, and `kid`; the `None` `alg` value is unsupported. Asymmetric keys (`JwtPublicKeySign`, `JwtPublicKeyVerify`) should be used between different entities, with supported algorithms including `ES256`, `RS256`, and `PS256`. Symmetric keys (`JwtMac`) are for same-entity usage, supporting `HS256`. Tink offers JWK Sets format conversion for public keys and recommends automated public keyset updates.\n"],null,["# JSON Web Tokens (JWTs)\n\nTink supports generating and verifying JWTs, which are a widely used standard on\nthe web. Tink's JWT implementation provides a *subset* of the JWT standard\ndefined in [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519 \"JSON Web Token (JWT)\") that the Tink team considers safe to use, and\nthat fits well into the Tink library.\n\nTink does not support parts of the standard that are rarely used or difficult to\nuse correctly. These are the limitations:\n\n- Tink only supports the [JWS Compact Serialization](https://datatracker.ietf.org/doc/html/rfc7515#section-3.1 \"JWS Compact Serialization\") format. [JWS\n JSON Serialization](https://datatracker.ietf.org/doc/html/rfc7515#section-3.2 \"JWS JSON Serialization\") and [JWE](https://datatracker.ietf.org/doc/html/rfc7516 \"JSON Web Encryption (JWE)\") are not supported.\n- Tink does not support the `None` value in the `alg` header.\n- Tink only supports the headers `typ`, `alg`, and `kid`. All other headers are not supported.\n- Tink does not allow tokens to be parsed before the signature or MAC is verified.\n\n### JWT Signatures\n\nIf tokens are generated and verified by different entities, then you should use\nasymmetric keys with the primitives `JwtPublicKeySign` and `JwtPublicKeyVerify`.\nThe private key is used to generate tokens, and the public key is used to verify\ntokens. The [algorithms](https://datatracker.ietf.org/doc/html/rfc7518#section-3) supported by these primitives are: `ES256`,\n`ES384`, `ES512`, `RS256`, `RS384`, `RS512`, `PS256`, `PS384` and `PS512`.\n\n#### Choose a key type\n\nJWT signatures use *different* key types than the normal digital signature in\nTink. This is needed because some metadata (such as `alg`and `kid`) needs to be\nstored with the key.\n\nWe recommend using `JWT_ES256` for most use cases. Tokens generated with this\nkey type always have a `kid` header. If you prefer slightly shorter tokens\nwithout a `kid` header, choose the key type `JWT_ES256_RAW`. For all supported\nkey types, see [Supported Key Types](/tink/supported-key-types#jwt_signature).\n\n#### Public keyset distribution\n\nTink allows public keysets to be converted to and from the JWK Sets format\ndefined in [RFC 7517](https://datatracker.ietf.org/doc/html/rfc7517#section-5), which most JWT libraries understand.\n| **Note:** Tink's JSON keyset serialization format is *not* a JWK Set and other libraries will probably not be able to read it.\n\nTink does not support exporting public JWT keys in any other format. The reason\nfor this is that other formats don't contain the `alg` and `kid` metadata to be\nused in the verification, which makes using them more error-prone and may make\nit more difficult to rotate keys.\n\nIt is preferable to not just share the public keyset once, but to provide a way\nto *automatically* update the public keyset. (If not, rotating to a new key is\nvery hard.) This is often done by publishing the public keyset on a trusted and\nsecured URL. A server that verifies tokens then has to periodically re-fetch the\npublic keyset from that URL, for example once per day. To rotate the key, the\nnew public key needs to be added to the public keyset *at least one day before*\nit is used to sign tokens. Otherwise the new tokens signed with the new private\nkey will be rejected by servers that still use the old public keyset.\n| **Note:** Some implementations re-fetch the public key as soon as a token with an unknown `kid` header is received. Implementing this logic is not possible in Tink, since the token is not parsed before it is verified. We don't recommend doing this anyway, as it may result in lots of extra requests to the keyset URL if malicious tokens with random `kid` headers are sent.\n\n### JWT MAC\n\nTink also supports JWT with symmetric keys with the primitive `JwtMac`. Only use\nthis primitive if the tokens are generated and verified by the same entity. The\n[algorithms](https://datatracker.ietf.org/doc/html/rfc7518#section-3) supported by this primitive are `HS256`, `HS384` and\n`HS512`.\n\n#### Choose a key type\n\nJWT MAC key types are *different* from normal MAC key types. We recommend using\n`JWT_HS256` for most use cases.\n\n### Example use cases\n\nSee [I want to create and verify JWTs](/tink/create-jwts)."]]
