前言

[Azure 筆記] 前言

---

原文

Explore authentication and authorization in App Service

---

小結

這篇的內容有點多
一次看不完的話就分幾次看吧🤭

Azure App Service 有提供一個內建的用戶認證系統
你可以在少量或沒有任何coding 的情況下
利用這個系統為你的 app 建立一個用戶認證系統來讓你的用戶登入你的 app
當然，你還是可以選擇使用各項 framework 內建的或是任何你想用的系統
不過 Azure 內建的這個也是其中一個選擇

這個系統可被用於任何 programming languages
如果你使用這個系統
用戶的身份認證會在你的程式碼被執行之前進行
它提供了幾個身份提供者的認證
你可以同時啟用一種或多種身份提供者
它們分別是

• Microsoft identity platform
• Facebook
• Google
• Twitter
• Any OpenID Connect provider
• GitHub

使用這個系統有兩種方式
它們是 with SDK 和 without SDK

• With SDK
  • 用戶會先登入相應的身份提供者，然後身份資訊會被傳到你的 app
  • 這種方式適合 browser-less apps
  • 應用程式(客戶端)會處理登入相關的程序，所以也被稱為 client-directed flow 或 client flow
  • 適用於 REST API、Azure Functions、JavaScript 瀏覽器用戶端，以及使用提供者 SDK 登入使用者的原生行動應用程式
• Without SDK
  • 把登入交給 App Service
  • 適合 browser apps
  • 伺服器程式碼管理登入流程，所以也被稱為 server-directed flow 或 server flow

兩種方式的流程有點不同
我知道大家會懶得去爬了
小弟就把該比較表格的連結放到這裏了
With or without SDK compare table

未認證請求

在使用 Azure 這個身份認證系統的時候
你可以選擇怎樣去處理未經驗證的請求
要注意的是，這個設定會應用在所有的請求之上

允許未經驗證的請求 (Allow unauthenticated requests)

這個選項會批準未驗證的請求呼叫你的 app
但如果用戶是一個已經過驗證的用戶的話
用戶的驗證資訊會被放到 HTTP headers 一起被傳到你的 app

需要驗證 (Require authentication)

這個選項會拒絕所有未經驗證的請求
他會被重新引導到指定身份驗證提供者的登入 URL

如果請求是來自 mobile app 的話
就會返回 HTTP 401 Unauthorized
你也可以設置為返回 HTTP 403 Forbidden

Token store

Azure App Service 內建有一個 token store
它存放了用戶的 token

只要你啟用了上文的驗證系統
這個 token store 就會被自動啟用

Logging and tracing

若你啟用了 application logging
驗證系統的 logging 就會被寫入 application logs

---

文本抄錄

Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal, or no code in your web app, RESTful API, mobile back end, and Azure Functions.

Why use the built-in authentication?

You are not required to use the built-in authentication.
Many web frameworks are bundled with security features, and you can use them if you like.
Also, you can write your own utilities.

Using the built-in authentication allowing you to focus on the rest of your application.

• Azure App Service allows you to integrate various auth capabilities into your web app or API without implementing them yourself.
• 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

The following identity providers are available by default:

Provider	Sign-in endpoint	How-To guidance
Microsoft identity platform	/.auth/login/aad	App Service Microsoft identity platform login
Facebook	/.auth/login/facebook	App Service Facebook login
Google	/.auth/login/google	App Service Google login
Twitter	/.auth/login/twitter	App Service Twitter login
Any OpenID Connect provider	/.auth/login/<providerName>	App Service OpenID Connect login
GitHub	/.auth/login/github	App Service GitHub login

When you use these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. You can provide your users with any number of these sign-in options.

How it works

The authentication and authorization module runs in the same sandbox as your application code.
When it’s enabled, every incoming HTTP request passes through it before being handled by your application code.
This module handles several things for your app:

• 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

The module runs separately from your application code and can be configured using Azure Resource Manager settings or using a configuration file.

Authentication flow

The authentication flow is the same for all providers, but differs depending on whether you want to sign in with the provider’s SDK.

• 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.
• 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.

The following table shows the steps of the authentication flow.

Step	Without provider SDK	With provider SDK
Sign user in	Redirects client to /.auth/login/<provider>.	Client code signs user in directly with provider’s SDK and receives an authentication token. For information, see the provider’s documentation.
Post-authentication	Provider redirects client to /.auth/login/<provider>/callback.	Client code posts token from provider to /.auth/login/<provider> for validation.
Establish authenticated session	App Service adds authenticated cookie to response.	App Service returns its own authentication token to client code.
Serve authenticated content	Client includes authentication cookie in subsequent requests (automatically handled by browser).	Client code presents authentication token in X-ZUMO-AUTH header (automatically handled by Mobile Apps client SDKs).

For client browsers, App Service can automatically direct all unauthenticated users to /.auth/login/<provider>. You can also present users with one or more /.auth/login/<provider> links to sign in to your app using their provider of choice.

Authorization behavior

In the Azure portal, you can configure App Service with many behaviors when an incoming request isn’t authenticated.

Allow unauthenticated requests: This option defers authorization of unauthenticated traffic to your application code. For authenticated requests, App Service also passes along authentication information in the HTTP headers. This option provides more flexibility in handling anonymous requests. It lets you present multiple sign-in providers to your users.

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.

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.