Microsoft Entra ID authentication in Azure Functions (all languages, without EasyAuth)

[georgeollis]

Motivation

Today, securing Azure Functions with Microsoft Entra ID typically requires one of two approaches:

EasyAuth (App Service Authentication)

Simple to enable, but:

• Limited per‑function control
• Harder to test locally
• Awkward for advanced scenarios (multi‑tenant, custom claims, mixed auth)

Custom JWT validation in code

Flexible, but:

• Boilerplate repeated across functions and repos
• Inconsistent patterns between languages
• Easy to misconfigure (issuer, audience, JWKS, clock skew, etc.)

[nzthiago]

Thanks @georgeollis - do you have a recommended approach and user experience?

[georgeollis]

Sorry @nzthiago - I forgot to add examples.

Problem Statement

Using Microsoft Entra ID authentication via EasyAuth introduces too much abstraction for Azure Functions.

When Microsoft Entra ID authentication is enabled, developers must still configure the Function endpoint with AuthLevel.ANONYMOUS in the code. While authentication and authorization are enforced externally by the Azure platform, this is confusing and counter‑intuitive from a developer perspective. It gives the impression that the endpoint is unauthenticated, even though access is actually protected upstream.

This disconnect makes the security model harder to reason about, particularly for teams that rely on code to communicate behavior and intent.

---

Current Example (EasyAuth)

@app.route(route="hello_world", auth_level=func.AuthLevel.ANONYMOUS)
def hello_world(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

    name = req.params.get('name')
    if not name:
        try:
            req_body = req.get_json()
        except ValueError:
            pass
        else:
            name = req_body.get('name')

    if name:
        return func.HttpResponse(
            f"Hello, { confusion and increases cognitive load for developers and reviewers.

---

Proposed Improvement: Native Entra Authentication in Code

Azure Functions should allow Microsoft Entra ID authentication and authorization to be expressed directly in code, similar to existing Function and Admin auth levels.

This could be achieved by introducing:

• A new auth_level=ENTRA
• A roles property that maps directly to App Roles defined in the associated Microsoft Entra application registration

Example Proposal

import azure.functions as func
import logging

app = func.FunctionApp()

@app.route(
    route="hello_world",
    auth_level=func.AuthLevel.ENTRA,
    roles=["Reader"]
)
def hello_world(req: func.HttpRequest) -> func.HttpResponse:
    ...**

• The roles parameter corresponds to App Roles configured on the Microsoft Entra application registration
• Role enforcement is performed using claims (e.g. roles or groups) from the validated access token

While it is technically possible to implement this behaviour today by manually inspecting headers and JWT claims, this approach is:

• Difficult to maintain
• Error‑prone
• Inconsistently implemented across teams
• Poorly discoverable for developers

This logic should be abstracted by the platform, not re‑implemented in every function.

---

Configuration Considerations

Additional configuration could be supplied via host.json, for example:

• Microsoft Entra Application (Client) ID
• Authority / tenant configuration
• Token validation settings

Secrets such as client secrets or certificates should not be stored in host.json. These should instead be provided via:

• Environment variables
• Azure Key Vault references

Any non‑secret metadata required for Entra authentication could reside in host.json if necessary.

---

Summary

• EasyAuth hides critical security behavior behind infrastructure configuration
• Marking Entra‑protected endpoints as ANONYMOUS in code is misleading
• Authentication and authorization intent should be explicit and visible in code
• Native Entra auth levels and role‑based authorization would significantly improve developer experience, security clarity, and maintainability

This approach would align Azure Functions with modern application frameworks, where authentication and authorization are first‑class, code‑level concerns.