Explore authentication and authorization in App Service Flashcards
Why use the built-in authentication?
Azure App Service allows you to integrate various auth capabilities into your web app or API without implementing them yourself.
It’s built directly into the platform and doesn’t require any particular language, SDK, security expertise, or code.
You can integrate with multiple login providers. For example, Microsoft Entra ID, Facebook, Google, Twitter.
Identity providers
Microsoft identity platform
Facebook
Google
Twitter
Any OpenID Connect provider
GitHub
How identity providers works?
Authenticates users and clients with the specified identity provider(s)
Validates, stores, and refreshes OAuth tokens issued by the configured identity provider(s)
Manages the authenticated session
Injects identity information into HTTP request headers
How can be Identity provider configured?
Can be configured using Azure Resource Manager settings or using a configuration file.
Authentication flow: Without provider SDK
The application delegates federated sign-in to App Service. This is typically the case with browser apps, which can present the provider’s login page to the user. The server code manages the sign-in process, so it’s also called server-directed flow or server flow.
Authentication flow: With provider SDK
The application signs users in to the provider manually and then submits the authentication token to App Service for validation. This is typically the case with browser-less apps, which can’t present the provider’s sign-in page to the user. The application code manages the sign-in process, so it’s also called client-directed flow or client flow. This applies to REST APIs, Azure Functions, JavaScript browser clients, and native mobile apps that sign users in using the provider’s SDK.
Authentication flow: Without provider SDK
Sign user in Redirects client to /.auth/login/<provider>.</provider>
Post-authentication Provider redirects client to /.auth/login/<provider>/callback.</provider>
Establish authenticated session App Service adds authenticated cookie to response.
Serve authenticated content Client includes authentication cookie in subsequent requests (automatically handled by browser).
Authentication flow: With provider SDK
Sign user in Client code signs user in directly with provider’s SDK and receives an authentication token. For information, see the provider’s documentation.
Post-authentication Client code posts token from provider to /.auth/login/<provider> for validation.</provider>
Establish authenticated session App Service returns its own authentication token to client code.
Serve authenticated content Client code presents authentication token in X-ZUMO-AUTH header (automatically handled by Mobile Apps client SDKs).
Authorization behavior
Allow unauthenticated requests
Require authentication: This option rejects any unauthenticated traffic to your application. This rejection can be a redirect action to one of the configured identity providers. In these cases, a browser client is redirected to /.auth/login/<provider> for the provider you choose. If the anonymous request comes from a native mobile app, the returned response is an HTTP 401 Unauthorized. You can also configure the rejection to be an HTTP 401 Unauthorized or HTTP 403 Forbidden for all requests.</provider>
Token store
App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. When you enable authentication with any provider, this token store is immediately available to your app.
Logging and tracing
If you enable application logging, authentication and authorization traces are collected directly in your log files. If you see an authentication error that you didn’t expect, you can conveniently find all the details by looking in your existing application logs.
