A citizen services app requests limited delegated access to a user's calendar-like scheduling resource using standard authorization flows without collecting the user's cloud password. Which protocol best fits this delegated authorization scenario?
Select an answer to reveal the explanation.
Short Explanation
The app should never pocket the citizen's password—it should ask for a limited hall pass to the calendar and nothing more. OAuth 2.0 is that consent-and-token dance: scoped access without handing over the master key. Telnet, anonymous FTP, and SNMP strings are not how modern delegated auth works.
Full Explanation
OAuth 2.0 is the standard protocol for delegated authorization: an application receives scoped tokens to access a user’s resources without collecting or handling the user’s password. A citizen services app that requests limited delegated access to a scheduling resource via standard authorization flows is using that OAuth-style pattern, which protects credentials while enabling consented integration.
Telnet with cleartext passwords forwarded from the mobile client is insecure and not delegated authorization. FTP anonymous login does not provide scoped consent. SNMP community strings as long-term user credentials are inappropriate for portal user delegation.
Exam caveat: OAuth is primarily authorization/delegation; OpenID Connect adds authentication identity layer on top. Know scopes, consent, and token types at a conceptual level for CV0-style questions.
Operational check: register the app with the authorization server, request minimal scopes, complete a consent test as a resident user, confirm the app never sees the user’s password, and revoke tokens in a break-glass drill. Review scopes annually for least privilege.
Educate product owners that OAuth consent screens and scope choices are security decisions for resident data, not merely UX copy—document approved scopes for the citizen services app in the integration catalog.