Two different questions
Authentication answers “who is this?”. NIST’s glossary, quoting FIPS 200, defines it as verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.
Authorization answers “what may they do?”. The same glossary gives, from CNSSI 4009-2022, the decision to permit or deny a subject access to system objects such as a network, data, application or service.
NIST’s Digital Identity Guidelines keep the two apart. SP 800-63-3 states that authentication does not determine the claimant’s authorizations or access privileges, and that this is a separate decision; the relying party uses the authenticated identity, with other factors, to make it. That revision has been superseded by SP 800-63-4 as of August 1, 2025, but the distinction is a useful one to design around.
The difference matters more offline, because the two depend on different kinds of information, and that information goes stale at different speeds.
Authentication with no server
Offline authentication works when the verifier already holds what it needs to check a claim: a public key, a list of trusted keys or a trust anchor. The other party proves possession of the matching private key, by signing a fresh challenge or the message itself, and the verifier checks the result locally. Ed25519 signatures are one scheme used for this.
Getting the right key onto the verifier is the hard part. That is an enrolment question, answered by a QR code scanned in person, a key installed at the factory, a certificate chain, or binding a device key to an account while a server was reachable.
Authorization with no server
An authorization decision needs the permission to be available where the decision is made. Offline, that leaves two places for it to live.
A policy on the verifying device. The device keeps a list of enrolled identities and what each may do. This is simple and keeps the decision with the device that is being acted on, but the list is only as current as its last update.
A token the requester carries. The permission travels with the request, signed by someone the verifier trusts. RFC 6749, the OAuth 2.0 framework, describes an access token as a string representing an authorization issued to the client, with specific scopes and durations of access. It also allows a token to self-contain the authorization information in a verifiable manner, meaning data plus a signature. A self-contained, signed token can be checked by a verifier that cannot reach the server that issued it.
Capability tokens push this further.
- Macaroons, from a Google research paper, are bearer credentials that embed caveats restricting when, where, by whom and for what purpose a service should honour them. They support decentralised delegation, but they are built from chained MACs (message authentication codes), so checking one needs the secret key of the service that minted it.
- UCAN uses public-key signatures instead. Its specification says that because offline operation and self-verifiability are requirements, it adopts a certificate capability model, where each token carries a verifiable chain of delegations back to the resource owner.
What goes stale offline
| Authentication | Authorization | |
|---|---|---|
| Question | Who is this? | What may they do? |
| What the verifier needs locally | Trusted keys | A current policy, or a token it can verify |
| How fast it changes | When keys are rotated or lost | Whenever roles, shifts or access change |
| Offline failure | An impostor with a stolen key | The right person with an out-of-date permission |
A key changes when it is rotated, lost or compromised. A permission changes whenever someone’s role, shift or assignment does. A technician moved off a site still authenticates perfectly: their key is valid, and only their permission has changed. An offline device holding an old policy, or a token that has not expired, will still let them in. Offline Protocol’s security documentation states the general rule: an offline verifier cannot learn a new central revocation until it receives updated information, and verifying a device’s key does not establish a person’s role or permission.
The usual mitigations limit how long a stale decision can last:
- Short-lived tokens. UCAN’s specification recommends minimising the time a token is valid and reducing its authority to the minimum the task needs.
- Narrow scopes. Grant one action on one resource, not general access.
- Bind tokens to a key. A bearer token works for whoever holds it. RFC 6749 notes that additional authentication credentials may be required for a client to use a token, so pair the token with a signature from the holder’s own key.
- Plan for revocation. Decide how removals reach devices, as covered in revoking access when devices are offline.
Keep the two checks separate in code as well. A valid signature tells you who sent a request. It never tells you, by itself, that the request should be carried out.