Remember approvals without making them permanent
A person can choose to remember an approval so a familiar tool does not ask the same question every time. Wildo remembers the client, target and approved identity scopes together, with an expiry.
A broader request or a different target needs another decision. The person can inspect and withdraw the stored approval.
Example — A tool asks for additional identity information
Approval for basic profile information covers the same request next time. If the tool also asks for email, the existing grant does not silently expand to cover it.
For engineers
The lookup is keyed by user, client and resource. Only an unexpired grant covering every requested scope returns true; a failed read returns false so the person is asked again:
This implementation excerpt from oidc-authorization-code.backend.service.ts shows the decision in context; explanatory source comments are omitted.
public async hasCoveringConsentGrant(userId: string, clientId: string, resource: string | undefined, requestedScopes: string[]): Promise<boolean> {
try {
const grant = await this.readConsentGrant(userId, clientId, resource);
if (!grant) return false;
if (grant.expiresAt && new Date(grant.expiresAt).getTime() <= Date.now()) return false;
const granted = new Set(grant.scopes ?? []);
return requestedScopes.every((s) => granted.has(s));
} catch {
return false;
}
}
Keep the target in the business key
| Later request | Existing approval covers it? |
|---|---|
| Same client and target, fewer approved scopes | Yes, while unexpired |
| Same client and target, additional scope | No; approval is needed |
| Same client, another target endpoint | No; it is a different delegation |
| Expired or unreadable grant | No; the prompt remains |
The opt-in checkbox stores or widens the grant when the person approves. Widening combines the newly approved scopes with the existing set and renews expiry using auth.consentGrantLifetimeDays or the framework default. A unique user/client/resource key and conflict reread handle simultaneous initial approvals.
Let the person inspect and withdraw their approvals
Use the person’s ordinary application session, not the delegated token issued to the external tool. The owner-facing list operation is:
curl "$BACKEND_URL/oauth-consent-grants" \
-H "Authorization: Bearer $USER_TOKEN"
The resource is scoped to the authenticated user even though its URL has no user-ID segment. Its standalone ownership relationship keeps that parent out of the path; the backend still confines the result to the caller. READ, LIST and DELETE require APP_USER; creating or updating remembered grants is reserved for the internal consent-decision flow.
Let the person choose an approval from that result by client, target resource and approved scopes. Keep the selected record’s _id as GRANT_ID, then withdraw it with:
curl -X DELETE "$BACKEND_URL/oauth-consent-grants/$GRANT_ID" \
-H "Authorization: Bearer $USER_TOKEN"
Refresh the list to confirm the selected approval is gone. Do not treat a client ID or resource URL as the grant record ID, and do not submit another person’s user ID to choose the owner. On a later authorization request, that deleted record can no longer justify skipping consent; other client/user consent policies still apply.
Set the approval lifetime deliberately
The default is 180 days. The optional backend-authored auth.consentGrantLifetimeDays accepts an integer from 1 to 3650. Keep the existing authentication configuration and add the property there; the setting applies when a grant is created or renewed by approval. It does not rewrite an existing record’s expiresAt merely because configuration changed.
Separate remembered approval from token authority
The grant belongs to the user as a resource they can list and revoke. Withdrawing it removes the reason to skip a future prompt; it is not itself the access token. Identity scopes in the record control identity information, while operation access follows the user’s roles at request time.
Remembering approval does not create a refresh token or extend an already-issued token’s lifetime.