LEARNING AZURE / BUILD WITH AI
No account neededAbout
Power up with AI / Lesson 5
Power up with AI / 40–55 min

Use managed sign-in and enforce access

Design optional browsing with protected personal actions. Learn how managed sign-in reduces setup while authorization remains an application responsibility.

What you’ll be able to do

  • Distinguish public content from user-owned records.
  • Use a supported managed authentication option.
  • Test authorization with two different users.
Before you beginA small server-backed sample and a non-production identity setup. This is an App Service or Azure Functions lab, not a login feature on Learning Azure. Provider configuration and pricing may require account setup.

Get the idea

Make the public boundary explicit

Everyone can browse a help page, while saving a personal request requires identity. Optional registration does not mean every action is anonymous. Decide the boundary before adding buttons.

Use managed authentication

App Service authentication can integrate with providers such as Microsoft Entra and Google. Follow the chosen provider’s registration and redirect instructions. Managed sign-in handles part of the identity flow; it does not decide which records belong to a person.

Authorize every protected action

A hidden button is not security. The backend must validate the signed-in identity and check ownership for read and write operations. Two users should not gain access to each other’s records by changing a URL or record ID.

Try it yourself

  1. List the sample’s anonymous actions and protected actions. Keep reading public and reserve personal data changes for signed-in users.
  2. Choose one supported provider and follow its official App Service authentication configuration. Use a lab app and exact registered redirect URLs.
  3. Ask the assistant to explain how identity reaches the backend. Do not accept a browser-supplied user ID as trusted identity.
  4. Implement a server-side ownership check for one sample record. Return unauthorized or forbidden responses appropriately.
  5. Test anonymous access, successful sign-in, sign-out, canceled consent, and attempts by a second test user to read or edit the first user’s record.

Example · commands or prompt

Review this app’s access model.
Public: help pages and a sample catalog.
Protected: a user’s own saved requests.
Use the hosting platform’s validated identity on the server.
Show where ownership is checked for reads and writes.
List two-user tests and unauthorized-request tests.
Do not treat hiding frontend controls as authorization.
Check your resultPublic pages remain readable, protected actions require validated identity, and cross-user access is denied by the backend.

Finish the lab

Remove test identities, assignments, and sample resources as appropriate. Record client-secret expiration securely if a provider integration uses a secret.

Quick knowledge check

Does successful sign-in prove a user may edit any record?

Reveal the explanation

No. Authentication establishes identity. Authorization checks whether that identity can perform the particular operation on that record.

Take this with you

Use managed identity features to reduce setup, then enforce the app’s access rules.

Go deeper

AI-assisted lesson · Reference links checked October 3, 2026. Exercises are teaching examples; they have not been executed against your Azure subscription.