Account Aggregator Consent vs OAuth Consent, Explained

If you've built an OAuth login, you already have a mental model of "consent": the user sees a screen, approves a set of scopes, and your app gets back a token. Consent, in that world, is a moment — a checkbox that unlocks access. India's Account Aggregator (AA) framework treats consent as something else entirely: a signed, machine-readable contract that spells out exactly what data, for what purpose, for how long, and how often.

Both systems are built on the same cryptographic primitive — a signed JSON document — but they make very different promises. If you're building for Indian financial data, or just deciding how granular your own consent records should be, the contrast is worth understanding. Here's what an OAuth token actually carries, what an AA consent artefact carries, and what the AA model can teach any OAuth system.

Two different ideas of "consent"

OAuth consent is about delegated access. When a user approves your app, they're saying "this client may act on my behalf within these scopes." The protocol's job is to get you a token that proves it. The consent itself is mostly implicit in the grant — RFC 6749 §3.3 defines scope as a way to limit access, not as a contract describing the data exchange. What was consented to, and for how long, is something your server records on the side, if it records it at all.

AA consent is about a specific data exchange. The Account Aggregator framework, built on India's Data Empowerment and Protection Architecture (DEPA) and regulated by the RBI, exists to move a user's financial data from one regulated entity to another — only with explicit, granular consent. So consent here isn't implicit. It's a document: the consent artefact, a signed JSON object that travels with the request and describes the exchange in full.

That difference — implicit-grant vs explicit-signed-contract — is the whole story.

What an OAuth access token carries

After an OAuth flow, your client holds an access token. Decode a typical one and you get something like:

{
  "sub": "user-123",
  "client_id": "app-xyz",
  "scope": "accounts:read transactions:read",
  "exp": 1750000000
}

That's the contract: a subject, a client, a set of scopes, an expiry. Scopes are coarse — transactions:read doesn't say which accounts, which date range, or why. There's no field for purpose, no notion of how many times the token may be used, no "delete this data after 90 days." Revocation exists (RFC 7009) but it's a separate, optional endpoint. The token is a key, not an agreement.

For app login and API access, that's exactly right — you don't want a 30-field contract every time someone signs in. But it means the data-sharing terms live outside the protocol.

What an AA consent artefact carries

The AA consent artefact puts the terms inside the document. A trimmed version looks like this:

{
  "consentStart": "2026-06-25T10:00:00Z",
  "consentExpiry": "2026-09-25T10:00:00Z",
  "consentMode": "VIEW",
  "fetchType": "PERIODIC",
  "consentTypes": ["TRANSACTIONS", "SUMMARY"],
  "fiTypes": ["DEPOSIT"],
  "Purpose": { "code": "101", "text": "Loan underwriting" },
  "FIDataRange": { "from": "2025-06-25", "to": "2026-06-25" },
  "DataLife": { "unit": "MONTH", "value": 3 },
  "Frequency": { "unit": "MONTH", "value": 1 }
}

Read it and you know everything: the data is for loan underwriting (a coded, declared purpose), it's a periodic fetch capped at once a month, covering one year of deposit transactions, the consumer may view but the rules say how long they may retain it (data-life: 3 months), and the whole arrangement expires in 90 days. The artefact is digitally signed (a detached JWS), so any party can verify it wasn't tampered with, and the user can revoke it at the Account Aggregator at any time — revocation is a first-class part of the framework, not an afterthought.

Put the two side by side and the gap is obvious: the OAuth token answers "may this client read transactions?"; the AA artefact answers "who may use which data, for what declared purpose, how often, for how long, and retained until when?"

Same primitive, very different contract

Here's the part that surprises OAuth developers: under the hood, these aren't alien technologies. The AA consent artefact is signed JSON — the same JWS/JWT machinery you already use for ID tokens and access tokens. If you can verify a JWKS-published signature, you can verify a consent artefact.

The difference isn't the cryptography. It's the payload and the lifecycle:

OAuth optimizes for frictionless access. AA optimizes for an auditable, revocable, purpose-bound data exchange — because that's what a regulator requires when the data is your bank statements.

What OAuth builders can borrow

You may never touch the AA network. But under India's DPDP Act, every product that processes personal data now has to answer the same questions the AA artefact bakes in: what purpose, what retention, can the user revoke, is it on record? The AA model is a working blueprint for consent that survives an audit.

Concretely, that means treating consent as a record, not a checkbox:

• Capture the purpose, not just the scope.
• Record an explicit expiry and retention alongside the grant.
• Make revocation a first-class action the user can take, and act on it.
• Store each consent event immutably, with a timestamp and the actor — so you can prove, later, exactly what was agreed.

This is how NamoID models consent internally: every provider connection and data-sharing approval is written to an append-only event store with its timestamp, scope, and purpose. It's not an AA consent artefact, but it carries the same idea — consent you can produce on demand, with the terms attached — which is exactly what a data fiduciary needs when a regulator asks.

When you need which

These aren't competitors; they solve different problems and often sit in the same app:

• OAuth / OIDC — user login, app authorization, API access. The right tool for "let this user sign in and let this client call my API."
• Account Aggregator — regulated sharing of financial data between RBI-supervised entities in India. The right tool for "pull this user's bank statements, with their explicit consent, for underwriting."

A lending app might use OIDC to log the user in and the AA network to fetch their financial data — OAuth for identity, AA for the data exchange. Knowing which guarantees each gives you is what keeps you from reaching for a bearer token where you needed a signed, revocable contract.

FAQ

Is an AA consent artefact just an OAuth scope with more fields? No. A scope limits access; the artefact is a signed agreement with purpose, retention, frequency, and a revocation lifecycle. Different job, even if both are signed JSON.

Does OAuth have anything like data-life? Not in the protocol. Token expiry limits how long the token works, not how long the consumer may retain the data. You have to enforce retention yourself.

Can the user revoke an OAuth grant like an AA consent? Only if you build it. OAuth has token revocation (RFC 7009), but a user-facing "withdraw consent" experience, and honoring it across stored data, is on you. AA makes it part of the framework.

Do I need to be an Account Aggregator to use this thinking? No. The purpose-bound, revocable, recorded-consent model is good practice — and increasingly a DPDP expectation — for any product handling personal data.

Build consent you can prove

OAuth gives you access; it leaves the data-sharing terms outside the protocol. The Account Aggregator framework puts them inside a signed, purpose-bound, revocable artefact — and that's the model DPDP now nudges every product toward. You don't need the AA network to adopt the idea: capture purpose, record retention, honor revocation, and keep it all immutable.

NamoID is built that way — an OIDC issuer with consent and provider connections written to an append-only audit trail, purpose and scope attached. If you're designing how your product records consent, start there.