Basic, Bearer, OAuth and authorisation

A token does not grant every resource.

UnderstandStudy an examplePractise

Understand the concept

Basic uses base64 encoding, not encryption, so secure transport is necessary. Bearer tokens can be used by whoever possesses them within their authority. Never put them in URLs or public logs. Signed JWT contents are not automatically encrypted.

OAuth delegates authorisation; OpenID Connect adds identity functionality. PKCE, validated redirect URIs, state/nonce and token checks have distinct roles. Validate issuer, audience, expiry and signature where appropriate.

Then enforce resource-level access: a valid User role does not grant another user’s order. Design logout, refresh and revocation. These examples show contracts without real secrets.

WHEN TO USE IT

Separate authentication from resource access.

COMMON PITFALL

Equating JWT decoding with validation.

01 / PRACTICE

One topic. Three levels of depth.

HTTP / illustrative example

Authorization: Bearer <example-token>

A placeholder; never publish real tokens.

This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.

02 / YOUR TURN

Try it yourself first.

Does a signed JWT containing email prove encryption?

Show the solution and explanation

Worked solution

Signature ≠ encryption

No; a signature provides validation properties, not content confidentiality.

RasimAtaberkŞahin

Understand the concept

One topic. Three levels of depth.

Try it yourself first.