A harbor-radio companion app is a public mobile client, yet its app registration lists only a web redirect URI and treats the app as a confidential client with a client secret. What should the security engineer correct on the registration?

App registration platform and redirect URI settings must match the real client. A public mobile client should use a mobile/public-client platform with the correct redirect URI and must not be treated as a confidential client that holds a client secret in the binary. For the harbor-radio companion app that currently lists only a web redirect URI and a client secret, correct the registration to a mobile/public-client platform, set the proper redirect URI, and stop using a confidential client secret that cannot be protected on a phone.

Keeping the web platform and embedding the secret in the mobile binary fails security and still mismatches public-client guidance—any secret shipped in a mobile package should be considered extractable. Moving redirect URI validation into an NSG allowing only a vendor CDN IP range fails by concept: NSGs filter Azure virtual-network traffic; they do not perform OAuth redirect URI validation for Entra app registrations. Converting the mobile app into a daemon confidential client that uses only application permissions fails the interactive public-client nature of a companion app that signs in harbor operators.

Exam caveat: public clients should use PKCE and must not rely on a confidential client secret; platform type and redirect URIs are part of the security boundary AZ-500 expects you to get right. Operational check: set the mobile/public platform and redirect URI, remove the client secret from the registration and from any mobile build configuration, test sign-in on a device, and confirm tokens issue through the public-client flow without a confidential secret.