aspnetcore/security/authentication/social/index.md
By Valeriy Novytskyy and Rick Anderson
This article explains how to build an ASP.NET Core app that enables users to sign in using OAuth 2.0 with credentials from external authentication providers.
Facebook, Twitter, Google, and Microsoft providers are covered in the following sections and use the starter project created in this article. Other providers are available in third-party packages such as OpenIddict, AspNet.Security.OAuth.Providers and AspNet.Security.OpenId.Providers.
Enabling users to sign in with their existing credentials is convenient for the users and shifts many of the complexities of managing the sign-in process onto a third party.
Open a command shell. For Visual Studio Code, you can use the integrated terminal.
Change directories (cd) to a folder for the sample app.
For Windows, run the following command:
dotnet new webapp -o WebApp1 -au Individual -uld
For macOS and Linux, run the following command:
dotnet new webapp -o WebApp1 -au Individual
dotnet new command uses the -o|--output option to create a new Razor Pages project in the WebApp1 folder.-au Individual creates the code for Individual authentication.-uld uses LocalDB, a lightweight version of SQL Server Express for Windows. Omit -uld to use SQLite.For more information, see dotnet new <TEMPLATE>.
[!INCLUDEForward request information when behind a proxy or load balancer section]
Social login providers assign Application Id and Application Secret tokens during the registration process. The exact token names vary by provider. These tokens represent the credentials that the app uses to access the provider's API. The tokens constitute user secrets that can be linked to your app configuration with the help of Secret Manager. User secrets are a more secure alternative to storing the tokens in a configuration file, such as appsettings.json.
[!IMPORTANT] Secret Manager is only for local development and testing. Protect staging and production secrets with the Azure Key Vault configuration provider, which can also be used for local development and testing if you prefer not to use the Secret Manager locally.
For guidance on storing the tokens assigned by each login provider, see xref:security/app-secrets.
Use the following articles to configure login providers and the app:
When the app requires multiple providers, chain the provider extension methods on xref:Microsoft.Extensions.DependencyInjection.AuthenticationServiceCollectionExtensions.AddAuthentication%2A:
builder.Services.AddAuthentication()
.AddGoogle(options =>
{
// Google configuration options
})
.AddFacebook(options =>
{
// Facebook configuration options
})
.AddMicrosoftAccount(options =>
{
// Microsoft Account configuration options
})
.AddTwitter(options =>
{
// Twitter configuration options
});
For detailed configuration guidance on each provider, see their respective articles.
When you register with an external login provider, you don't have a password registered with the app. This alleviates you from creating and remembering a password for the site, but it also makes you completely dependent on the external login provider for site access. If the external login provider is unavailable, you won't be able to sign in to the app.
To create a password and sign in using your email that you set during the sign-in process with external providers: