با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
Tink از تولید و تأیید JWT ها پشتیبانی می کند، که یک استاندارد پرکاربرد در وب هستند. پیاده‌سازی JWT Tink زیرمجموعه‌ای از استاندارد JWT تعریف شده در RFC 7519 را ارائه می‌کند که تیم Tink استفاده از آن را ایمن می‌داند و به خوبی در کتابخانه Tink قرار می‌گیرد.
Tink از بخش‌هایی از استاندارد که به ندرت استفاده می‌شوند یا استفاده صحیح از آنها دشوار است، پشتیبانی نمی‌کند. اینها محدودیت ها هستند:
Tink فقط از هدرهای typ , alg و kid پشتیبانی می کند . همه سرصفحه های دیگر پشتیبانی نمی شوند.
Tink اجازه نمی دهد توکن ها قبل از تأیید امضا یا MAC تجزیه شوند.
امضاهای JWT
اگر توکن‌ها توسط موجودیت‌های مختلف تولید و تأیید می‌شوند، باید از کلیدهای نامتقارن با کلیدهای اولیه JwtPublicKeySign و JwtPublicKeyVerify استفاده کنید. کلید خصوصی برای تولید توکن ها و کلید عمومی برای تایید توکن ها استفاده می شود. الگوریتم های پشتیبانی شده توسط این الگوریتم های اولیه عبارتند از: ES256 ، ES384 ، ES512 ، RS256 ، RS384 ، RS512 ، PS256 ، PS384 و PS512 .
یک نوع کلید را انتخاب کنید
امضاهای JWT از انواع کلیدهای متفاوتی نسبت به امضای دیجیتال معمولی در Tink استفاده می کنند. این مورد نیاز است زیرا برخی از ابرداده ها (مانند alg و kid ) باید با کلید ذخیره شوند.
ما استفاده از JWT_ES256 را برای بیشتر موارد استفاده توصیه می کنیم. توکن‌هایی که با این نوع کلید تولید می‌شوند، همیشه یک هدر kid دارند. اگر توکن‌های کمی کوتاه‌تر را بدون هدر kid ترجیح می‌دهید، نوع کلید JWT_ES256_RAW را انتخاب کنید. برای همه انواع کلیدهای پشتیبانی شده، به انواع کلیدهای پشتیبانی شده مراجعه کنید.
توزیع مجموعه کلید عمومی
Tink به مجموعه کلیدهای عمومی اجازه می دهد تا به فرمت JWK Sets تعریف شده در RFC 7517 تبدیل شوند و اکثر کتابخانه های JWT آن را درک می کنند.
Tink از صادرات کلیدهای عمومی JWT در هر قالب دیگری پشتیبانی نمی کند. دلیل این امر این است که سایر قالب‌ها حاوی متادیتای alg و kid برای استفاده در تأیید نیستند، که استفاده از آنها را مستعد خطا می‌کند و ممکن است چرخش کلیدها را دشوارتر کند.
ترجیحاً نه تنها یک بار مجموعه کلیدهای عمومی را به اشتراک بگذارید، بلکه راهی برای به روز رسانی خودکار مجموعه کلیدهای عمومی ارائه دهید. (اگر نه، چرخش به یک کلید جدید بسیار سخت است.) این اغلب با انتشار مجموعه کلید عمومی در یک URL مطمئن و ایمن انجام می شود. سروری که توکن ها را تأیید می کند، باید به طور دوره ای مجموعه کلیدهای عمومی را از آن URL، مثلاً یک بار در روز، دوباره واکشی کند. برای چرخاندن کلید، کلید عمومی جدید باید حداقل یک روز قبل از استفاده برای امضای نشانه ها به مجموعه کلیدهای عمومی اضافه شود. در غیر این صورت، توکن‌های جدید امضا شده با کلید خصوصی جدید توسط سرورهایی که هنوز از مجموعه کلید عمومی قدیمی استفاده می‌کنند رد می‌شوند.
JWT MAC
Tink همچنین از JWT با کلیدهای متقارن با JwtMac اولیه پشتیبانی می کند. فقط در صورتی از این اولیه استفاده کنید که توکن ها توسط یک موجودیت تولید و تأیید شوند. الگوریتم های پشتیبانی شده توسط این اولیه HS256 ، HS384 و HS512 هستند.
یک نوع کلید را انتخاب کنید
انواع کلید MAC JWT با انواع کلیدهای MAC معمولی متفاوت است. ما استفاده از JWT_HS256 را برای بیشتر موارد استفاده توصیه می کنیم.
تاریخ آخرین بهروزرسانی 2025-07-25 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-25 بهوقت ساعت هماهنگ جهانی."],[[["\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)."]]
