A wastewater SCADA integration can call a machine-only API with client credentials, but the resident portal must let each homeowner approve data sharing. Why does official DEVCOR task 2.5 require the authorization-code (three-legged) path for that portal?
Select an answer to reveal the explanation.
Short Explanation
Machine-to-machine is a two-person handshake without the homeowner. Three-legged invites the homeowner to the table to say yes. Client-credentials skips that consent, so it is not the official 2.5 happy path.
Full Explanation
Resident portal data sharing needs the homeowner in the loop: the authorization-code grant is three-legged because the resource owner authenticates and approves. Client-credentials is two-legged machine authentication with no consent screen—acceptable for some wastewater SCADA-to-API jobs, but wrong as the official DEVCOR task 2.5 happy path when each homeowner must approve sharing.
Client-credentials does not automatically show homeowners a consent screen; that claim invents user UX the grant simply does not have. Three-legged is not the only grant that can ever return a refresh token; refresh is orthogonal and optional after a successful code exchange. Claiming authorization-code grants never use a client secret is false for confidential clients, which authenticate with the secret on the token hop. When both patterns coexist in the wastewater estate, label each integration’s grant type in inventory so auditors see which APIs are machine-only versus resident-approved. Mixing the two without labeling is how consent requirements get dropped during refactors.
Exam caveat: pick the grant by whether a human resource owner must approve; do not pick by refresh-token mythology or by pretending secrets disappear. Operational check: for the portal path, verify an authorize redirect and consent occur before tokens; for the machine SCADA path, confirm client-credentials never presents a browser consent page.