Template Features

Table of Contents

• Authentication with Social Accounts:
  • GitHub - LinkedIn - Microsoft.
• Preconfigured GitHub Actions:
  • dependabot.yaml - codeql.yaml - ci.yaml - release.yaml.
• Bootstrappers
• Next steps

Authentication with Social Accounts

The Blazor Admin Template includes built-in support for social account authentication. Currently, it supports GitHub, LinkedIn, and Microsoft accounts. The following sections provide setup instructions for each provider.

GitHub Authentication

To enable GitHub authentication, follow the GitHub documentation to create a new OAuth application and obtain the Client ID and Client Secret.

Configure these values under the Authentication:GitHub section in the appsettings.json file of the Blazor project. Example:

{
  ...
  "Authentication": {
	"GitHub": {
      "ClientId": "your-client-id",
      "ClientSecret": "your-client-secret"
    },
	...
  },
  ...
}

⚠️ Important: Avoid storing your client secret in plain text appsettings.json file. Use a secret manager or environment variables to secure sensitive information. When using environment variables, set the Authentication__GitHub__ClientId and Authentication__GitHub__ClientSecret variables in your environment to store the client ID and secret.

LinkedIn Authentication

To enable LinkedIn authentication, first register your application on the LinkedIn Developer Portal to obtain a Client ID and Client Secret.

Configure these values under the Authentication:LinkedIn section in the appsettings.json file of the Blazor project. Example:

{
  ...
  "Authentication": {
	"LinkedIn": {
      "ClientId": "your-client-id",
      "ClientSecret": "your-client-secret"
    },
	...
  },
  ...
}

⚠️ Important: Avoid storing your client secret in plain text appsettings.json file. Use a secret manager or environment variables to secure sensitive information. When using environment variables, set the Authentication__LinkedIn__ClientId and Authentication__LinkedIn__ClientSecret variables in your environment to store the client ID and secret.

For more details on LinkedIn authentication, refer to the official documentation:

• Authorization Code Flow (3-legged OAuth)
• Client Credential Flow (2-legged OAuth)

Microsoft Authentication

To enable authentication with Microsoft accounts, start by registering an application in Microsoft Entra ID. Once registered, note the Application (client) ID, generate a Client Secret under the Certificates & secrets section, and record your Tenant ID.

To enable authentication with Microsoft accounts, first follow the Microsoft Entra ID document to register an application in Microsoft Entra ID. After registration, note the Application (client) ID and generate a Client Secret under Certificates & secrets section. Also, note your Tenant ID.

Add these values under the Authentication:Microsoft section in the appsettings.json file of your Blazor project. Example:

{
  ...
  "Authentication": {
	"Microsoft": {
      "TenantId": "your-tentant-id-or-common",
      "ClientId": "your-client-id",
      "ClientSecret": "your-client-secret"
    }
	...
  },
  ...
}

⚠️ Important: Never store your client secret in plain text in appsettings.json. Use a secret manager or environment variables to protect sensitive information. If using environment variables, set the Authentication__Microsoft__TenantId, Authentication__Microsoft__ClientId and Authentication__Microsoft__ClientSecret variables in your environment to store the tenant ID, client ID and secret.

Note on Tenant ID: You can use your specific Microsoft Entra tenant ID or "common" to allow users from any Microsoft tenant to sign in.

For more information on authentication with Microsoft accounts, refer to the official documentation:

• Microsoft identity platform and OAuth 2.0 authorization code flow

Preconfigured GitHub Actions

The Blazor Admin Template comes with a collection of preconfigured GitHub Actions workflows designed to streamline common development tasks. These workflows automate processes such as building, testing, and deploying your application. The sections below outline each workflow and its specific purpose.

Unless otherwise noted, all workflows are located in the .github/workflows directory of the repository.

Tailor these workflows to fit your project's needs. Feel free to customize triggers, steps, or configurations - or remove workflows entirely if they're not relevant to your setup.

dependabot.yaml

This workflow automatically checks for outdated dependencies in your project and creates pull requests (PRs) to update them. It is located in the .github directory and runs on a weekly schedule (every weekend). You can customize the workflow to better fit your needs, including the schedule, update rules, and more.

For more details, see the official GitHub Dependabot documentation.

The template also includes a companion workflow, automerge-dependabot.yaml, which automatically merges PRs created by Dependabot. This workflow is triggered when the ci.yaml workflow completes successfully for a Dependabot-generated PR.

codeql.yaml

This workflow performs automated security analysis of your code using CodeQL. It is scheduled to run weekly on weekend and on every push and pull request to any branch. The results are available in the Security tab of your GitHub repository.

ci.yaml

This workflow is triggered on every push and pull request to any branch. It builds the solution, runs unit tests, and performs a basic validation of the Dockerfile by building and running the image.

Additionally, it automatically drafts a release by compiling changelog information from commit messages. The release is informational only and is not published.

release.yaml

This workflow is triggered when a pull request (PR) is merged into the release branch. It starts by invoking the ci.yaml workflow to validate the merged changes. If the validation passes, it creates a new release, tags the commit with the appropriate version number, and publishes the release to the GitHub repository.

After the release is published, the workflow creates a PR to the main branch to merge changes from release. Note: This PR is not merged automatically.

Feel free to customize the release process to fit your project's needs.

Bootstrappers

Applications generated with the Blazor Admin Template do not require direct modifications to Program.cs for setup and configuration. Instead, the template adopts a bootstrapper pattern to manage application initialization. This approach allows a clean separation of concerns, making the codebase easier to maintain and extend.

For implementation details and usage examples, see the Bootstrappers section.

Next steps

• Application setup and configuration via bootstrappers.