ForHosting KIT · Strumenti per sviluppatori

Firma un JWT

Firmare un JWT significa creare un token con header e payload che scegli tu e sigillarlo con una chiave segreta, così chi lo riceve può verificare che sia autentico e integro. Questo strumento del KIT costruisce il token nel browser, con algoritmi HS256, HS384 o HS512, imposta scadenza e claim e te lo restituisce pronto.

● StabileGratis · nel tuo browser

Esegui gratis nel browser Vedi l'API

Usalo da WebAPIEmailApp prestoTelegram presto

Header, payload, firma: cosa imposti

Definisci l'algoritmo nell'header, i claim nel payload — chi è l'utente (sub), chi emette (iss), a chi è destinato (aud) — e soprattutto la scadenza (exp). Poi fornisci il secret e il KIT calcola la firma. Un consiglio: metti sempre una scadenza breve e un iat, e non caricare il payload di dati inutili, perché il token viaggia a ogni richiesta.

HS256 e le firme simmetriche

Gli algoritmi HS usano una sola chiave segreta condivisa tra chi firma e chi verifica: semplice e velocissimo, ideale quando lo stesso sistema fa entrambe le cose. Se invece emittente e verificatore sono soggetti diversi, di solito si usa una coppia di chiavi asimmetriche, dove firmi con la privata e chiunque verifica con la pubblica. Per test e sviluppo, HS256 è quasi sempre la scelta pratica.

Per prototipare e testare in sicurezza

È perfetto per generare token di prova mentre costruisci l'autenticazione: crei al volo un JWT con i claim che ti servono e lo usi per testare un endpoint protetto. La firma avviene nel browser, quindi il secret non viene mai inviato online né registrato. In produzione, però, i token li emette il tuo backend: qui è per svilupparlo e verificarlo.

Dal backend, via API

$0.002 a richiesta se vuoi emettere token da un processo automatico o da uno script. Per generarne uno al volo mentre programmi, la pagina è gratis e immediata. La superficie principale del KIT è la web; l'API è uno dei canali, come lo saranno app ed email.

Casi d'uso

Testare un endpoint protetto

Uno sviluppatore di Milano sta costruendo le API di un gestionale. Genera un JWT con role: admin e scadenza di un'ora per provare che l'endpoint riservato risponda solo con un token valido.

Token per un ambiente di staging

Il team di Rossi & Figli S.r.l. crea token di prova con utenti fittizi per collaudare i permessi in staging, senza toccare gli account reali.

Simulare un token in scadenza

Per verificare che l'app gestisca bene i token scaduti, uno sviluppatore ne firma uno con exp già passato e controlla che il sistema chieda di riautenticarsi.

Domande frequenti

Che differenza c'è tra HS256 e RS256?

HS256 usa un'unica chiave segreta condivisa per firmare e verificare; RS256 usa una coppia di chiavi, privata per firmare e pubblica per verificare. HS256 è più semplice quando lo stesso sistema fa entrambe le cose.

Posso impostare la scadenza del token?

Sì. Imposti il claim exp e gli altri claim standard come iss, aud, sub e iat. Metti sempre una scadenza: un token senza exp resta valido per sempre, ed è un rischio.

La chiave segreta viene salvata?

No. La firma avviene nel browser: il secret non viene inviato online e non resta da nessuna parte. Chiudi la scheda e sparisce.

Posso usarlo per i token di produzione?

In produzione i token dovrebbe emetterli il tuo backend, dove il secret è custodito in sicurezza. Questo strumento è pensato per sviluppo, test e debug; via API puoi comunque automatizzarne l'emissione.

È gratis?

Nel browser sì, senza registrazione. Via API, per firmare token in automatico, costa $0.002 a richiesta.

Firma anche con chiavi asimmetriche?

Lo strumento firma con gli algoritmi HMAC (HS256, HS384, HS512), i più usati in sviluppo. Per le firme asimmetriche conviene affidarsi al backend, dove la chiave privata resta protetta.

Per sviluppatori — accesso via API

Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.

Endpoint

POSThttps://api.kit.forhosting.com/dev/jwt-sign

Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.

Chiamala dal tuo stack

curl -X POST https://api.kit.forhosting.com/dev/jwt-sign \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d &#39;{"items":["valor-1","valor-2"]}'

const res = await fetch("https://api.kit.forhosting.com/dev/jwt-sign", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "items": [
      "valor-1",
      "valor-2"
    ]
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/jwt-sign",
    headers={"Authorization": f"Bearer {os.environ[&#39;KIT_KEY']}"},
    json={
    "items": [
        "valor-1",
        "valor-2"
    ]
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/jwt-sign", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => &#39;{"items":["valor-1","valor-2"]}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"items":["valor-1","valor-2"]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/jwt-sign", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Esempio di richiesta

{
  "items": [
    "valor-1",
    "valor-2"
  ]
}

Esempio di risposta

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.jwt_sign",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.

Prezzi

per richiesta$0.002

Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.

Errori

HTTP	Codice	Significato
`401`	`unauthorized`	Chiave API mancante o non valida: controlla l'header Authorization.
`402`	`insufficient_balance`	Credito esaurito: ricarica per continuare a eseguire attività.
`404`	`unknown_type`	Tipo di attività sconosciuto: controlla il campo type della richiesta.
`429`	`rate_limited`	Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo.

Leggi la documentazione completa del KIT →

Esegui gratis nel browser