title | description | services | author | ms.author | ms.service | ms.topic | ms.date |
---|---|---|---|---|---|---|---|
Custom authentication in Azure Static Web Apps |
Learn to configure custom authentication for Azure Static Web Apps |
static-web-apps |
aaronpowell |
aapowell |
static-web-apps |
conceptual |
10/08/2021 |
Azure Static Web Apps provides managed authentication that uses provider registrations managed by Azure. To enable more flexibility over the registration, you can override the defaults with a custom registration.
-
Custom authentication also allows you to configure custom providers that support OpenID Connect. This configuration allows the registration of multiple external providers.
-
Using any custom registrations disables all pre-configured providers.
Note
Custom authentication is only available in the Azure Static Web Apps Standard plan.
Custom identity providers are configured in the auth
section of the configuration file.
To avoid putting secrets in source control, the configuration looks into application settings for a matching name in the configuration file. You may also choose to store your secrets in Azure Key Vault.
To create the registration, begin by creating the following application settings:
Setting Name | Value |
---|---|
AZURE_CLIENT_ID |
The Application (client) ID for the Azure AD app registration. |
AZURE_CLIENT_SECRET |
The client secret for the Azure AD app registration. |
Next, use the following sample to configure the provider in the configuration file.
Azure Active Directory providers are available in two different versions. Version 1 explicitly defines the userDetailsClaim
, which allows the payload to return user information. By contrast, version 2 returns user information by default, and is designated by v2.0
in the openIdIssuer
URL.
{
"auth": {
"identityProviders": {
"azureActiveDirectory": {
"userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"registration": {
"openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>",
"clientIdSettingName": "AZURE_CLIENT_ID",
"clientSecretSettingName": "AZURE_CLIENT_SECRET"
}
}
}
}
}
Make sure to replace <TENANT_ID>
with your Azure Active Directory tenant ID.
{
"auth": {
"identityProviders": {
"azureActiveDirectory": {
"registration": {
"openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
"clientIdSettingName": "AZURE_CLIENT_ID",
"clientSecretSettingName": "AZURE_CLIENT_SECRET"
}
}
}
}
}
Make sure to replace <TENANT_ID>
with your Azure Active Directory tenant ID.
For more information on how to configure Azure Active Directory, see the App Service Authentication/Authorization documentation on using an existing registration.
To configure which accounts can sign in, see Modify the accounts supported by an application and Restrict your Azure AD app to a set of users in an Azure AD tenant.
Note
While the configuration section for Azure Active Directory is azureActiveDirectory
, the platform aliases this to aad
in the URL's for login, logout and purging user information. Refer to the authentication and authorization section for more information.
To create the registration, begin by creating the following application settings:
Setting Name | Value |
---|---|
APPLE_CLIENT_ID |
The Apple client ID. |
APPLE_CLIENT_SECRET |
The Apple client secret. |
Next, use the following sample to configure the provider in the configuration file.
{
"auth": {
"identityProviders": {
"apple": {
"registration": {
"clientIdSettingName": "APPLE_CLIENT_ID",
"clientSecretSettingName": "APPLE_CLIENT_SECRET"
}
}
}
}
}
For more information on how to configure Apple as an authentication provider, see the App Service Authentication/Authorization documentation.
To create the registration, begin by creating the following application settings:
Setting Name | Value |
---|---|
FACEBOOK_APP_ID |
The Facebook application ID. |
FACEBOOK_APP_SECRET |
The Facebook application secret. |
Next, use the following sample to configure the provider in the configuration file.
{
"auth": {
"identityProviders": {
"facebook": {
"registration": {
"appIdSettingName": "FACEBOOK_APP_ID",
"appSecretSettingName": "FACEBOOK_APP_SECRET"
}
}
}
}
}
For more information on how to configure Facebook as an authentication provider, see the App Service Authentication/Authorization documentation.
To create the registration, begin by creating the following application settings:
Setting Name | Value |
---|---|
GITHUB_CLIENT_ID |
The GitHub client ID. |
GITHUB_CLIENT_SECRET |
The GitHub client secret. |
Next, use the following sample to configure the provider in the configuration file.
{
"auth": {
"identityProviders": {
"github": {
"registration": {
"clientIdSettingName": "GITHUB_CLIENT_ID",
"clientSecretSettingName": "GITHUB_CLIENT_SECRET"
}
}
}
}
}
To create the registration, begin by creating the following application settings:
Setting Name | Value |
---|---|
GOOGLE_CLIENT_ID |
The Google client ID. |
GOOGLE_CLIENT_SECRET |
The Google client secret. |
Next, use the following sample to configure the provider in the configuration file.
{
"auth": {
"identityProviders": {
"google": {
"registration": {
"clientIdSettingName": "GOOGLE_CLIENT_ID",
"clientSecretSettingName": "GOOGLE_CLIENT_SECRET"
}
}
}
}
}
For more information on how to configure Google as an authentication provider, see the App Service Authentication/Authorization documentation.
To create the registration, begin by creating the following application settings:
Setting Name | Value |
---|---|
TWITTER_CONSUMER_KEY |
The Twitter consumer key. |
TWITTER_CONSUMER_SECRET |
The Twitter consumer secret. |
Next, use the following sample to configure the provider in the configuration file.
{
"auth": {
"identityProviders": {
"twitter": {
"registration": {
"consumerKeySettingName": "TWITTER_CONSUMER_KEY",
"consumerSecretSettingName": "TWITTER_CONSUMER_SECRET"
}
}
}
}
}
For more information on how to configure Twitter as an authentication provider, see the App Service Authentication/Authorization documentation.
You can configure Azure Static Web Apps to use a custom authentication provider that adheres to the OpenID Connect (OIDC) specification. The following steps are required to use an custom OIDC provider.
- One or more OIDC providers are allowed.
- Each provider must have a unique name in the configuration.
- Only one provider can serve as the default redirect target.
You're required to register your application's details with an identity provider. Check with the provider regarding the steps needed to generate a client ID and client secret for your application.
Once the application is registered with the identity provider, create the following application secrets in the application settings of the Static Web App:
Setting Name | Value |
---|---|
MY_PROVIDER_CLIENT_ID |
The client ID generated by the authentication provider for your static web app. |
MY_PROVIDER_CLIENT_SECRET |
The client secret generated by the authentication provider's custom registration for your static web app. |
If you register additional providers, each one needs an associated client ID and client secret store in application settings.
Important
Application secrets are sensitive security credentials. Do not share this secret with anyone, distribute it within a client application, or check into source control.
Once you have the registration credentials, use the following steps to create a custom registration.
-
You need the OpenID Connect metadata for the provider. This information is often exposed via a configuration metadata document, which is the provider's Issuer URL suffixed with
/.well-known/openid-configuration
. Gather this configuration URL. -
Add an
auth
section of the configuration file with a configuration block for the OIDC providers, and your provider definition.{ "auth": { "identityProviders": { "customOpenIdConnectProviders": { "myProvider": { "registration": { "clientIdSettingName": "MY_PROVIDER_CLIENT_ID", "clientCredential": { "clientSecretSettingName": "MY_PROVIDER_CLIENT_SECRET" }, "openIdConnectConfiguration": { "wellKnownOpenIdConfiguration": "https://<PROVIDER_ISSUER_URL>/.well-known/openid-configuration" } }, "login": { "nameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "scopes": [], "loginParameterNames": [] } } } } } }
- The provider name,
myProvider
in this example, is the unique identifier used by Azure Static Web Apps. - Make sure to replace
<PROVIDER_ISSUER_URL>
with the path to the Issuer URL of the provider. - The
login
object allows you to provide values for: custom scopes, login parameters, or custom claims.
Identity providers require a redirect URL to complete the login or logout request. Most providers require that you add the callback URLs to an allowlist. The following endpoints are available as redirect destinations.
Type | URL pattern |
---|---|
Login | https://<YOUR_SITE>/.auth/login/<PROVIDER_NAME_IN_CONFIG>/callback |
Logout | https://<YOUR_SITE>/.auth/logout/<PROVIDER_NAME_IN_CONFIG>/callback |
If you are using Azure Active Directory, use aad
as the value for the <PROVIDER_NAME_IN_CONFIG>
placeholder.
Note
These URLs are provided by Azure Static Web Apps to receive the response from the authentication provider, you don't need to create pages at these routes.
To use a custom identity provider, use the following URL patterns.
Action | Pattern |
---|---|
Login | /.auth/login/<PROVIDER_NAME_IN_CONFIG> |
Logout | /.auth/logout |
User details | /.auth/me |
Purge user details | /.auth/purge/<PROVIDER_NAME_IN_CONFIG> |
If you are using Azure Active Directory, use aad
as the value for the <PROVIDER_NAME_IN_CONFIG>
placeholder.
[!div class="nextstepaction"] Set user roles programmatically