Patient Portal Web Channel Authentication and PHI Exposure
A hospital's patient portal embeds the web channel. The portal generates a URL with userId=MRN12345, and the digital assistant's custom component getAppointments reads that value from the component payload and calls the EHR API. Channel authentication is disabled because 'patients log in to the portal'. During a pilot, a patient changed the query string and saw another patient's appointment list. The same skill is used in MS Teams for 1,200 schedulers, where the component receives a Teams user ID; schedulers need to look up patients by name, while patients must only see their own records. The digital assistant has 25,000 patient users. The team plans to go live in six weeks and wants to keep the portal public for scheduling before login.
1. What is the security flaw, and which trust boundary has been crossed? What should not be trusted in the current design?
Read the worked answer
The flaw is trusting a client-supplied identifier. The web channel URL and query string are controlled by the browser, so userId=MRN12345 proves nothing. The portal login protects the portal, not the digital assistant endpoint. The bot is a separate service and has no evidence that the caller is the patient whose MRN appears in the URL. The custom component then uses that untrusted value to call the EHR API, so the bot becomes a direct object-reference bypass.
Do not trust userId, sessionId, channel user ID, or any identifier that arrives from the client for PHI authorization. The only trustworthy identity is one established by channel authentication and validated by the backend. Also do not trust that a Teams user ID implies scheduler authorization; role must be checked from a trusted claim. The EHR API must enforce authorization as well, because a compromised or misconfigured bot should not be able to read any patient's record.
2. Design authentication and channel-specific authorization for patients and schedulers while preserving pre-login scheduling.
Read the worked answer
Enable authentication on the web channel using OIDC or OAuth with the hospital identity provider. The channel validates the token and passes a trusted user principal to the skill. The getAppointments custom component must use that authenticated principal, not a payload userId, and the EHR API must check the same principal and scope.
Split the experience by authentication state and role. For unauthenticated patients, expose only non-PHI intents such as locations, hours, and starting a new appointment request. Do not expose appointment lookup, prescription status, or record summaries. For authenticated patients, allow self-service only on their own record. For MS Teams schedulers, enable Teams SSO and require a scheduler role claim; allow patient search by name only after that role check, and log the search. Use separate skills or routing rules for patient and scheduler audiences so a scheduler intent cannot be invoked by a patient. Test by replaying requests with a tampered userId, an expired token, and a valid token for the wrong role.
3. What deployment and secret-management controls should be in place before the six-week go-live?
Read the worked answer
Treat the channel client secret, identity provider secret, and EHR credentials as deployment secrets in OCI Vault or an equivalent secret store, never in exported assistant content or source code. Rotate the web channel secret and EHR credentials before production, and define an owner for rotation. Promote the digital assistant through test and production versions; validate that channel authentication settings and callback URLs are configured in each environment, because channel configuration does not automatically become safe just because a skill was exported. Run a security test that includes tampering with the query string, replaying an expired token, and calling the component directly outside the bot. Add monitoring for authorization failures and unusual patient-record access volume. Keep a rollback version and a documented procedure to disable the web channel if PHI exposure is suspected.