Token Strategy for a Multi-Channel API
A healthcare scheduling API serves three channels: a patient mobile app (public client, cannot keep secrets), a clinician web portal (server-side, can hold secrets), and 9 partner EHR integrations (server-to-server, each with its own identity). Current design issues one long-lived static API key per channel, embedded in the mobile app binary. A penetration test extracted the mobile key and used it to read other patients' appointments by changing an ID in the path. The API gateway has no per-user context today. Compliance requires audit trails tying each request to a user. Mobile sessions must expire after 15 minutes of inactivity.
1. Redesign the authentication and authorization model per channel. Address the extracted-key vulnerability and the IDOR symptom specifically.
Read the worked answer
The static key is both a credential and an authorization decision, which is why extraction led to cross-patient reads. Separate the two.
- Mobile (public client): static embedded secrets are unrecoverable once shipped. Move to an authorization-code flow with PKCE so no secret lives in the binary; issue short-lived access tokens (for example 15 minutes) plus refresh tokens, and bind tokens to the authenticated patient identity. The 15-minute inactivity rule maps to access-token lifetime and refresh-token idle timeout.
- Clinician portal (confidential client): authorization-code flow with a client secret held server-side; tokens carry clinician identity and role claims.
- Partner EHRs (machine-to-machine): client-credentials flow with per-partner client IDs and secrets (or certificates), scoped to only the operations each partner needs.
Fixing the IDOR: authentication alone does not stop ID substitution. Enforce object-level authorization at the API layer: derive the patient ID from the token subject and reject requests where the path ID does not match the caller's permitted scope (patient self, or clinician with an explicit care relationship). Never trust a client-supplied ID as the authorization basis. Add per-request identity claims to logs to satisfy the audit requirement.
2. How would you scope tokens and gateway policy so a compromised partner credential has limited blast radius, and what would you monitor?
Read the worked answer
Scoping: give each partner its own client identity and a token whose scopes enumerate only the operations and data domains it needs (for example read appointments for its attributed patients, not write, not other partners' patients). Keep access-token lifetimes short so a stolen token expires quickly, and require the partner to re-authenticate. Apply per-client rate limits and quotas at the gateway so one partner cannot exhaust shared capacity. Where supported, bind tokens to the partner's registered redirect/network context and reject tokens presented from unexpected sources.
Blast-radius reasoning: a leaked credential should yield only that partner's permitted slice, for a bounded time, at a bounded rate - not the whole API. Independent identities also make revocation surgical: revoke one client without disrupting the other eight.
Monitoring: alert on anomalous patterns per client - sudden volume spikes, access to patient IDs outside the partner's normal attribution set, geographic or IP shifts, repeated authorization failures, and token reuse from multiple sources. Correlate gateway logs with identity claims so an incident can be traced to a specific credential and user. Include a tested revocation runbook, since detection without fast revocation leaves the window open.