Isolate DigiLocker Verification Across SaaS Tenants
Design tenant boundaries for DigiLocker credentials, verification attempts, results, and cleanup. Test cross-customer access before onboarding new applications.
Bind each DigiLocker verification to the tenant, application, environment, and user that started it. Check that binding at creation, return, retrieval, and cleanup.
An OAuth grant describes upstream access. Your application still determines which local caller can read a result. OAuth security guidance also describes the need to protect credentials and keep grants within their intended boundaries. OAuth 2.0 Security Best Current Practice.
Assign ownership at each boundary
| Resource | Ownership to record | Check to make |
|---|---|---|
| Provider connection | Approved client and environment | Caller can use the configured connection |
| Verification attempt | Tenant, application, and user | Caller matches the original attempt |
| Callback state | One pending attempt | State is current and can be consumed once |
| Result | Owning application and purpose | Caller may retrieve the result at this time |
| Cleanup task | Original attempt and scoped credential reference | Worker targets the correct tenant and grant |
Resolve the tenant from trusted application context. A tenant identifier sent by the browser can help route a request after the server verifies it.
Test a guessed verification identifier
Use two synthetic tenants. Tenant A starts a verification. Tenant B obtains the identifier from a test fixture and calls the result endpoint with B's own credentials.
The lookup must restrict access to the owning application. The same rule applies to cancellation and result deletion. An opaque identifier reduces guessing. It does not replace the ownership check.
Repeat the test with applications that share a workspace. A tenant-level check alone can miss an application boundary.
Review lifecycle actions
- Rotate a connection in Test.
- Confirm existing attempts use their intended configuration.
- Disable a connection for new requests.
- Confirm approved cleanup can still finish.
- Check that a worker cannot act on another tenant's records.
Consider the data included in operational events. Use references and bounded outcome codes. Keep document contents and credentials in the systems that own them.
Keep Test and Live separate
Store distinct connection and approval records for each environment. A provider can use the same network host for different arrangements. Your application should still preserve the logical environment boundary.
Capture the configuration used for each attempt so support can reproduce the decision. DigiLocker production readiness.
Review your tenant design with NamoID
NamoID engineers can help review your application, environment, and customer boundaries. Bring a synthetic two-tenant example and the operations each tenant should be able to perform. Message the NamoID team in Slack