OAuth delegates authority via bearer tokens. The trust chain: you trust the authorization server to be honest, you trust the token not to leak, you trust the resource server to validate correctly. Every link is institutional. H33 attestation is mathematical. h33 verify receipt.json answers the question without calling a server.
OAuth trust is delegated: you trust parties to behave correctly. H33 trust is mathematical: verification does not require trusting anyone.
OAuth 2.0 (RFC 6749) is the dominant authorization framework on the internet. Its model is elegant: a resource owner delegates limited access to a third-party client by obtaining an access token from an authorization server. The client presents this token to the resource server, which validates it and grants access. The framework has become so ubiquitous that "Sign in with Google" and "Connect with GitHub" are unremarkable user experiences.
But the trust model underlying OAuth is entirely institutional. Every link in the chain depends on a party behaving correctly. You trust the authorization server (Google, Okta, Auth0) to authenticate the user correctly, to issue tokens with the correct scopes, and to revoke tokens when instructed. You trust the token itself not to leak -- bearer tokens are like cash; anyone who possesses them can use them. You trust the resource server to validate the token correctly, to check expiration, to verify scopes, and to call the introspection endpoint when needed. You trust TLS to protect the token in transit. You trust the client application to store the token securely.
This is not a criticism of OAuth's design. Delegated authorization is a genuine problem, and OAuth solves it well within its design parameters. The observation is that OAuth's security guarantees are institutional, not mathematical. They hold when all parties behave correctly. They fail when any party is compromised, misconfigured, or dishonest.
OAuth 2.0 access tokens are bearer tokens (RFC 6750). The specification is explicit: "Any party in possession of a bearer token (a 'bearer') can use it to get access to the associated resources." This means that a stolen token grants the thief the same access as the legitimate holder. There is no binding between the token and the presenter -- the token is the credential.
Token theft is not a theoretical risk. It is the primary attack vector against OAuth-protected systems. Tokens leak through server logs, browser storage, insecure mobile apps, man-in-the-middle attacks on misconfigured TLS, and compromised third-party libraries. Once stolen, the token can be used until it expires or is revoked. Revocation requires the authorization server to be aware of the compromise -- which typically means the theft must be detected first, and detection depends on monitoring systems that may themselves be compromised.
JWT-based tokens (RFC 7519) add a signature, which prevents tampering but not theft. A stolen JWT is just as useful to an attacker as a stolen opaque token. The signature proves the token was issued by the authorization server, not that the presenter is the intended bearer. Proof-of-possession tokens (DPoP, RFC 9449) address this partially by binding the token to a client key, but adoption is limited and the binding depends on the resource server correctly implementing the DPoP verification.
An H33 attestation receipt is a fundamentally different kind of artifact. It is not a credential that grants access. It is a cryptographic proof of what happened. A receipt contains the operation inputs, the operation type, the output, a timestamp, and three independent post-quantum signatures. The receipt is hash-chained to the previous receipt using SHA3-256, creating an ordered, tamper-evident sequence of operations.
The receipt's validity does not depend on any server. Running h33 verify receipt.json checks three things: (1) the SHA3-256 hash chain is intact -- the receipt links correctly to its predecessor; (2) all three post-quantum signatures (ML-DSA-65, FALCON-512, SLH-DSA-SHA2-128f) verify against the included public keys; and (3) deterministic replay -- given the same inputs and operation, the verifier produces byte-identical output. This verification is offline. It does not call a server. It does not trust anyone. The math either checks out or it does not.
This distinction matters for auditability, legal proceedings, and regulatory compliance. An OAuth token proves that access was authorized at a point in time. An H33 receipt proves what happened during that access, permanently, to any verifier, without requiring the cooperation of any party. The token expires. The receipt is perpetual.
OAuth revocation (RFC 7009) is a server-side operation. The client or the authorization server marks a token as revoked. Resource servers that support token introspection (RFC 7662) must call the authorization server to check revocation status before honoring a token. Resource servers that validate JWTs locally may not learn of revocation until the token expires -- a known gap in the OAuth security model.
H33 attestation receipts are not revocable in the OAuth sense because they are not access credentials. A receipt records a historical fact: this operation happened, with these inputs, producing this output, at this time. Historical facts are not revoked. However, the attestation chain does support revocation-like semantics: if an attestation needs to be superseded (for example, because the operation it attested was later determined to be unauthorized), a subsequent attestation records that determination. The revocation itself is attested, hash-chained, and independently verifiable. Revocation is not a server-side state change that might or might not propagate -- it is a cryptographic record in the chain.
OAuth token validation in the general case requires network access. Opaque tokens require an introspection call to the authorization server. JWTs require access to the authorization server's public keys (typically via the JWKS endpoint). Revocation checking requires an introspection call. If the authorization server is unreachable -- due to network partition, server failure, or adversarial interference -- token validation either fails (denying access) or proceeds without revocation checking (a security risk).
H33 attestation verification is fully offline. The Verifier CLI contains everything needed to verify a receipt: the SHA3-256 hash function, the three PQ signature verification algorithms, and the deterministic replay engine. No network call is made. No server is contacted. The verification is deterministic and self-contained. This means H33 receipts can be verified on air-gapped systems, in disconnected environments, by parties with no relationship to H33 or the organization that generated the attestation.
For legal and regulatory proceedings, this property is decisive. An attorney, a regulator, or an insurance adjuster can independently verify an H33 receipt without trusting H33, the organization, or any intermediary. The verification is mathematical. It does not require a subpoena to the authorization server. It does not require the authorization server to still exist.
OAuth 2.0 and OpenID Connect depend on classical cryptography at every layer. JWT tokens are signed with RS256 (RSA-PKCS1-SHA256) or ES256 (ECDSA-P256-SHA256). TLS transport uses RSA or ECDHE key exchange. Token introspection responses are protected by TLS with classical cipher suites. None of these algorithms are quantum-safe.
The OAuth working group and IETF have not yet standardized post-quantum algorithm support for OAuth. This is not a criticism -- the standardization process is inherently slow, and post-quantum migration for a protocol as widely deployed as OAuth is a massive undertaking. But the gap is real. OAuth tokens signed today with RS256 can be forged by a future quantum computer. For tokens with short lifetimes (minutes to hours), this may be an acceptable risk. For audit trails, compliance records, and legal evidence that reference OAuth-protected operations, the risk compounds over time.
H33 attestation receipts are post-quantum from day one. The three PQ signature families -- ML-DSA-65 (MLWE lattice), FALCON-512 (NTRU lattice), SLH-DSA-SHA2-128f (stateless hash) -- are based on three independent mathematical hardness assumptions. An attacker must break all three simultaneously to forge a receipt. The SHA3-256 hash chain provides additional quantum resistance via Keccak's 256-bit security level, which remains secure under Grover's algorithm at 128-bit equivalent security. The H33-Chaos adversarial validation suite continuously tests the attestation infrastructure against tampering, replay, and forgery attacks.
H33 does not replace OAuth. OAuth solves a specific, important problem: delegated authorization for third-party access to user resources. No other widely adopted standard solves this problem as effectively. Removing OAuth from a system architecture would eliminate the ability for users to authorize third-party applications without sharing their credentials.
H33 operates downstream of OAuth. After OAuth authorizes access, H33 attests what happens during that access. The OAuth token grants entry. The H33 receipt records what occurred inside. In combination, you have both delegated authorization (OAuth) and cryptographic proof of operation (H33). The H33 Post-Quantum API is itself protected by standard OAuth-compatible API key authentication. The attestation receipt specification is designed to complement existing authorization frameworks, not replace them.
Different artifacts for different purposes. One grants access. The other proves what happened.
OAuth bearer tokens are access credentials backed by institutional trust in the authorization server. H33 attestation receipts are cryptographic proofs backed by mathematical properties that any party can verify independently. The two artifacts serve different purposes, operate at different layers, and have fundamentally different trust properties.
A structured comparison across the dimensions that distinguish delegated authority from deterministic attestation.
| Dimension | OAuth 2.0 | H33 Attestation |
|---|---|---|
| Trust model | Delegated institutional trust | Mathematical verification |
| Token/receipt validity | Time-limited bearer (minutes to hours) | Permanent cryptographic proof |
| Revocation model | Server-side state, propagation delay | Hash-chained, revocation is itself attested |
| Offline verification | No -- requires introspection endpoint | Yes -- h33 verify works fully offline |
| Post-quantum readiness | No -- RS256/ES256 vulnerable to Shor | Yes -- 3 PQ families, 3 hardness assumptions |
| Deterministic replay | No -- tokens are not replayable proofs | Yes -- byte-identical output from any verifier |
| Theft impact | Full access until revoked or expired | None -- receipt is proof, not credential |
| Third-party verifiability | Requires auth server cooperation | Any party, no cooperation needed |
| Evidence for legal/regulatory | Token logs, server-dependent | Self-contained cryptographic proof |
| Complementary deployment | Yes -- handles authorization | Yes -- handles operation attestation |
Every claim on this page is backed by published specifications, live verification tools, or independently auditable infrastructure.
In the general case, no. OAuth 2.0 access tokens are opaque bearer tokens that require server-side introspection (RFC 7662) to validate. The resource server must call the authorization server's introspection endpoint to confirm that the token is active, has not been revoked, and has the correct scopes. JWTs used as access tokens can be verified offline if the resource server has the authorization server's public key, but revocation checking still requires a network call. H33 attestation receipts are fully verifiable offline: the h33 verify command checks the SHA3-256 hash chain, validates all three post-quantum signatures, and confirms deterministic replay -- without contacting any server.
A bearer token is a credential: anyone who possesses it can use it to access protected resources. Its validity depends on the authorization server that issued it, and it expires after a configured time period. An attestation receipt is a cryptographic proof: it records what happened, binds the inputs and outputs with post-quantum signatures, and is permanently verifiable by any party. A bearer token grants access. An attestation receipt proves what happened after access was granted. A bearer token is time-limited and revocable. An attestation receipt is permanent and mathematically unforgeable.
No. OAuth 2.0 and OpenID Connect rely on classical cryptographic algorithms for token signing and TLS transport. JWT tokens are typically signed with RS256 (RSA-SHA256) or ES256 (ECDSA-P256-SHA256), both of which are vulnerable to quantum computing attacks via Shor's algorithm. The OAuth framework specifications (RFC 6749, RFC 6750) do not mandate post-quantum algorithms. H33 attestation receipts are signed with three independent post-quantum signature families and hash-chained with SHA3-256, providing quantum resistance based on three independent mathematical hardness assumptions.
H33 does not replace OAuth for authorization. OAuth answers the question: is this client authorized to access this resource on behalf of this user? H33 answers a different question: what happened when the resource was accessed, and was the operation correct? H33 attestation operates downstream of authorization. After OAuth grants access, H33 attests each operation that occurs within that authorized session. The attestation records the operation, not the authorization decision. Organizations use OAuth for access control and H33 for cryptographic proof of what happened after access was granted.
No, and that is not the intent. OAuth and H33 operate at different layers of the trust stack. OAuth handles delegated authorization: granting third-party applications limited access to user resources. H33 handles operation attestation: producing cryptographic proof of what happened during that access. Replacing OAuth with H33 would leave the system without a delegated authorization mechanism. Using OAuth without H33 leaves the system without cryptographic proof of operation correctness. The architecturally sound approach is to use both: OAuth for authorization, H33 for attestation.
Generate an attestation. Verify it offline. Compare it to what your OAuth tokens prove. The difference is structural.