Understanding the differences, risks, benefits, and when to use each

Azure Static Web Apps supports two main authentication/authorization approaches during deployment:

1. GitHub Identity (OIDC or GitHub Actions permissions)
2. Azure Token (Service Principal / Azure AD App Registration)

They both let GitHub Actions deploy your app, but they work very differently.

1. GitHub Identity (OIDC)

✔️ What it is

GitHub Actions uses OpenID Connect (OIDC) to request a short‑lived Azure token at deploy time, without storing any secrets. Azure trusts GitHub’s identity provider and issues a temporary token.

⭐ Benefits

• No secrets stored in GitHub
  Nothing to rotate, leak, or accidentally commit.
• Short‑lived tokens
  Tokens expire quickly, reducing blast radius.
• Least privilege by design
  You grant GitHub Actions a specific role on a specific resource.
• Automatic rotation
  No manual maintenance.
• Recommended by Microsoft for modern deployments
  It’s the “secure-by-default” option.

⚠️ Risks / Limitations

• Requires Azure setup
  You must configure a federated identity credential on an Entra ID app.
• Only works with GitHub Actions
  If you switch CI/CD providers, you must reconfigure.
• More complex initial setup
  Especially if you’re not familiar with Entra ID.

🧭 When to use GitHub Identity

Use it when:

• You deploy from GitHub Actions (most SWA users do).
• You want maximum security with no secrets.
• You want zero maintenance authentication.
• You’re building a long‑term, production‑grade pipeline.

This is the best practice for modern Azure deployments.

2. Azure Token (Service Principal)

✔️ What it is

A Service Principal (SP) is an Azure AD application with a client ID and client secret. GitHub Actions uses this secret to authenticate to Azure.

⭐ Benefits

• Simple to understand
  It’s just a username/password for Azure.
• Works with any CI/CD provider
  GitHub, Azure DevOps, GitLab, Jenkins, etc.
• Good for legacy pipelines
  Many older workflows rely on SPs.

⚠️ Risks / Limitations

• Secrets must be stored in GitHub
  Even in encrypted secrets, this is a risk.
• Secrets can leak
  Through logs, PRs, misconfigured workflows, or compromised GitHub accounts.
• Secrets must be rotated manually
  Developers often forget.
• Long‑lived credentials
  If compromised, attackers have persistent access.

🧭 When to use Azure Token

Use it when:

• You need multi‑platform CI/CD (not just GitHub).
• You have existing SP‑based pipelines and can’t migrate yet.
• You need fine‑grained control over the identity (e.g., custom API permissions).

This is the legacy but still valid option.

Side‑by‑Side Comparison

Feature	GitHub Identity (OIDC)	Azure Token (Service Principal)
Secrets stored in GitHub	❌ None	✔️ Yes (client secret)
Token lifetime	Short-lived	Long-lived
Rotation	Automatic	Manual
Setup complexity	Medium	Low
Works outside GitHub	❌ No	✔️ Yes
Security posture	⭐ Strong	⚠️ Weaker
Recommended by Microsoft	✔️ Yes	⚠️ Only for legacy

How to Secure Each Approach

GitHub Identity (OIDC)

• Restrict trust to specific GitHub repo + branch
  (e.g., only main can request tokens)
• Assign least-privilege roles
  Usually Contributor or Static Web App Contributor.
• Use environment protection rules
  Require approvals for production deployments.
• Use branch protection
  Prevent unauthorized pushes to the trusted branch.

This is already extremely secure.

Azure Token (Service Principal)

If you must use SPs, harden them:

• Store secrets only in GitHub Encrypted Secrets
• Rotate secrets every 90 days
• Use least-privilege roles
• Enable Conditional Access (IP restrictions, MFA for portal access)
• Use Managed Identity inside Azure where possible
• Avoid using the same SP for multiple apps

SPs can be secure, but they require disciplin

Which Should You Use?

Given your background—structured learning, Azure-focused, building a real-world CMS project—the best choice is:

👉 Use GitHub Identity (OIDC) for all new Static Web App deployments.

It’s:

• more secure
• easier to maintain
• aligned with modern Azure DevOps practices
• ideal for production workloads

Use a Service Principal only if:

• you need cross-platform CI/CD
• you’re integrating with tools outside GitHub
• you’re migrating legacy pipelines