DigiLocker Consent Expiry, Revocation and Sessions
Track DigiLocker access tokens, consent expiry, and application sessions as separate lifetimes. Plan revocation and check what remains after the journey ends.
Track the DigiLocker token, document consent, and your application's signed-in session separately. Each can expire or end while another is still active. Check the conditions for the action you are about to perform.
The requester specification describes token expiry, consent validity, and revocation operations. The applicable contract determines which operations your client can use. Requester v2.4 specification
Put each lifetime in the design
| Item | Owner | Question before use |
|---|---|---|
| Application session | Your application | Is this user still signed in and allowed to continue? |
| Provider access token | Provider and requester | Is the token valid for the intended request? |
| Document consent | Provider and requester | Is the grant still valid for this document and purpose? |
| Verification attempt | Your integration | Is this attempt open and bound to the original user? |
| Stored result | Your application or processor | Is access still permitted under the retention policy? |
Compare time values using consistent units. Save the provider timestamp in its documented form before normalizing it. Test boundary times and clock differences.
Handle a grant that ends first
In a synthetic case, the user's local session runs until 17:00. Consent ends at 16:00, while the provider token has a later expiry.
At 16:05 the user can still use unrelated application features. A new document fetch for the expired grant must stop. If the task still needs a document, give the person an approved route to start a new request.
A refreshed token also needs the applicable permission checks. Token refresh cannot serve as evidence that a particular document permission was granted for a new purpose.
Plan cleanup for each ending
- Identify the token and grant tied to the attempt.
- Close the attempt to new document requests.
- Follow the provider's approved revocation procedure.
- Track any pending cleanup using a bounded status.
- Apply the retention policy to any local result.
Document what happens on decline, cancellation, and timeout. If revocation fails, record the pending state and follow a controlled retry policy. Keep that operation separate from a retry of the document fetch.
Test the boundaries
Test local sign-out while a provider session remains. Test cancellation after a token exchange. Test a retained result reaching its deletion date after the grant has already expired.
Each test should have its own expected result. Use your application policy and the provider contract to define the correct outcome. Application session and SSO revocation.
Review expiry handling with NamoID
NamoID engineers can help map the lifetimes in your workflow and review how cancellation, revocation, and result retention interact. Share a synthetic timeline and the failure case you need to handle. Message the NamoID team in Slack