Layered Token

An access token stores an encoded authorization claim in a cookie. Determine whether the server can distinguish an issued claim from one edited by its holder.

Objective

• Decode, modify, and re-encode a simple token.
• Explain why authorization tokens need cryptographic integrity.

Before you begin

Open /challenge/medium/token. Review the Base64 recipe and preserve the progress cookie.

Concepts

Encoding changes representation; it does not authenticate the sender. An unsigned token permits a client to alter a claim and produce equally valid encoded text.

Encoding is reversible. Checksums detect accidental errors. Hashes fingerprint bytes but do not authenticate a source. A MAC provides integrity and origin within a group that shares a secret; any member can create tags. A signature binds bytes to a private-key holder when verification and public-key trust are correct. None of these alone encrypts, proves freshness, or grants authorization.

Suggested tools

• Storage inspector and Base64 tool: Decode and replace only access_token.

Tool practice

Rehearse the worked tool exercise before using challenge data.

Practice a decode/re-encode round trip before editing the challenge cookie. Keep the decoded text separate from the encoded cookie value. After replacing the cookie, check the outgoing Cookie header for spaces, quotes, or line breaks introduced while copying.

Investigation

Observe

Decode the token and identify its key/value structure and ordinary role.

Form a hypothesis

What proof binds that role to a server decision? What higher role is named by earlier modules in this profile?

Test carefully

Preserve the structure, change only the role, re-encode it, and reload.

Progressive hints

Troubleshooting and reset

Remove spaces or quotes introduced by a decoder. Delete only access_token to receive a fresh ordinary token.