DID:
First Name:
Last Name:
Age:
``` Add a route to decode the session token and extract the claims in `src/authorization-routes.js`. It verifies the token with the `JWT_SECRET` you set in your `.env` during [Project Setup](/getting-started/tutorial/project-setup.md): ```javascript import { Router } from "express"; import jwt from "jsonwebtoken"; import dotenv from "dotenv"; dotenv.config(); const router = Router(); const JWT_SECRET = process.env.JWT_SECRET; // Secret used to sign/verify our own session token router.get("/decode-access-token", (req, res) => { const authHeader = req.headers["authorization"]; const access_token = authHeader?.split(" ")[1]; if (!access_token) return res.status(401).json({ error: "Unauthorized" }); try { // Verify our own session token. Because we signed it with `exp`, // jwt.verify() also rejects expired tokens automatically. const decoded = jwt.verify(access_token, JWT_SECRET); // We read the holder DID and disclosed claims straight from the payload. // These fields are present only if the verification flow signed them in // (see the hint at the top of this page). res.json({ did: decoded.sub, // the holder's did:key / did:web (if signed in) claims: decoded.claims, // disclosed claims, e.g. { first_name, last_name, age } (if signed in) }); } catch (error) { // Invalid signature or expired token. return res.status(401).json({ error: "Invalid or expired token" }); } }); router.get("/dashboard", (req, res) => { res.sendFile("dashboard.html", { root: "public" }); }); export default router; ``` Finally, mount this router in `src/index.js` under the `/authorization` prefix, next to the issuer and verifier routers: ```javascript // src/index.js — add the import at the top: import authorizationRouter from "./authorization-routes.js"; // ...and mount it with the other routers: app.use("/authorization", express.json(), authorizationRouter); ``` Now, after verification, the user is redirected to `/authorization/dashboard`, and the dashboard displays what the verification flow signed into the session token. A few things to keep in mind: * **Match the claim keys to your schema.** This example reads `first_name`, `last_name`, and `age` — the claims of the `KYCCredential@1.0:sd-jwt` credential that the "kyc" flow in [Setting Up the Verification Flow](/getting-started/tutorial/verification-flow.md) requires (`age ≥ 18`). Use the exact property names from the credential schema you are verifying; if you verify a different credential, render its own claim keys instead. * **The DID shown is the holder's DID** — the `did:key` or `did:web` of the wallet that presented the credential, read from the session token's `sub` claim. * **The disclosed claims come from the verified presentation.** Pass through only the claims the holder chose to disclose (SD-JWT selective disclosure), so the dashboard never sees more than what was presented. > **Best practice:** Give the app session token a short lifetime. The `onKycVerified` helper signs it with `expiresIn: "1h"` — tighten that (e.g. `"15m"`) for sensitive resources. `jwt.verify()` then rejects expired tokens for you, so a leaked token can't grant access to the protected dashboard indefinitely. This session token is internal to your app and is unrelated to the OIDC access token you use to call the Issuer and Verifier APIs. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.empe.io/getting-started/tutorial/dashboard.md?ask=