AspNet.Security.OAuth.Providers: Social Login Handlers for ASP.NET Core

The gap between ASP.NET Core's built-in handlers and the long tail of social providers

ASP.NET Core ships with authentication handlers for a handful of identity systems. The moment you want GitHub, Twitter/X or Dropbox sign-in, you are writing OAuth 2.0 plumbing yourself: authorization endpoint, token endpoint, user information endpoint, claim mapping, and the callback path. AspNet.Security.OAuth.Providers exists to remove that work. It is a collection of security middleware, in the project's words, that adds those providers to your ASP.NET Core application through the standard authentication builder. The audience is .NET teams with an existing application, typically MVC or similar, that already calls AddAuthentication and wants social sign-in without maintaining per-provider handler code. The project is Apache-2.0 licensed and lives in the aspnet-contrib organisation, with the latest official release on NuGet and nightly builds on MyGet.

How the handlers plug into the authentication middleware

Each provider is an authentication handler registered through the same extension-method pattern as the built-in schemes. You call AddAuthentication to configure your application's authentication options, then chain a provider method such as AddGitHub, passing a delegate that sets ClientId and ClientSecret. The handler performs the OAuth 2.0 code flow: it redirects the user to the provider's authorization endpoint, receives the callback, exchanges the code for a token, calls the provider's user information endpoint, and turns the result into claims on the resulting principal. The README describes the aspnet-contrib handlers as OAuth 2.0 code flow only. That single sentence is the architectural boundary of the whole package: no OpenID Connect, no client credentials grant, no refresh token grant. The repository layout reflects the breadth of the approach, with a src directory of per-provider implementations, a test directory, a samples directory containing an MVC client that supports multiple social providers, and a docs directory.

Installing a provider and completing a first sign-in

The packages are published on NuGet under the aspnet-contrib profile. Pick the package for the provider you want, add it to your project, then register the handler in your service configuration. The README's own example shows the registration shape:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(options => { /* Authentication options */ })
            .AddGitHub(options =>
            {
                options.ClientId = "49e302895d8b09ea5656";
                options.ClientSecret = "98f1bf028608901e9df91d64ee61536fe562064b";
            });
}

Those two values are placeholders from the documentation. Replace them with the client ID and secret you register with the provider itself; the README does not describe that registration step. The second half is the middleware pipeline, which must call authentication before authorization:

public void Configure(IApplicationBuilder app)
{
    app.UseAuthentication();
    app.UseAuthorization();
}

After that, a challenge against the provider's scheme sends the user through the code flow and back to your callback path. The samples directory holds a complete MVC sample using multiple social providers, which is the fastest way to see the full wiring rather than the fragment above.

Code flow only, and what that leaves on the table

The limitation is stated plainly in the migration section of the README: the aspnet-contrib providers support only the OAuth 2.0 code flow. Everything else is absent. There is no OpenID Connect support, so for providers that implement it you cannot enforce the additional security checks the README associates with it. There is no built-in countermeasure against nonce or token replay attacks, because the handlers are not stateful in the way the OpenIddict client is. There is no token introspection, no token revocation, and no configuration discovery, which means endpoint URIs are hardcoded per provider rather than fetched. None of this makes the handlers broken. It makes them a thinner layer, and the project says so itself rather than letting you discover it after adoption. If your application needs refresh tokens or a non-interactive grant, this package is the wrong tool, and the README points you elsewhere.

OpenIddict as the project's own recommended alternative

The README does not merely mention OpenIddict as a competitor; it encourages developers to use the OpenIddict client for new applications, and devotes a section to migrating. The difference in approach is not cosmetic. OpenIddict fully supports OpenID Connect, is stateful and provides built-in countermeasures against nonce and token replay attacks, supports additional flows including the OpenID Connect hybrid flow, the OAuth 2.0 client credentials grant, the resource owner password credentials grant and the refresh token grant, supports token introspection and revocation, and uses OAuth 2.0 and OpenID Connect server configuration discovery to avoid hardcoding provider endpoint URIs when possible. The aspnet-contrib handlers are the simpler OAuth 2.0-only option. For an application that already depends on the aspnet-contrib scheme names and callback paths, migrating is a real piece of work, which is why the project keeps supporting them. For a new application, the choice is between a thinner handler set and a client library with a broader protocol surface.

Licence, release cadence and the cost of staying current

The project is licensed under the Apache License, which the README summarises as free use, modification and distribution. That is permissive and carries no copyleft obligation on your application; the usual caveat applies that this is a summary, not legal advice, and the full text is at apache.org. Release history shows 10.0.0 on 2025-11-11, 9.4.1 on 2025-09-30 and 9.4.0 on 2025-05-21, and the repository's last push was on 2026-09-28, so the codebase is still moving. The upgrade cost is tied to your ASP.NET Core target: major versions track the framework, so a framework upgrade pulls the provider package with it. Because each provider is a separate implementation in src, a breaking change in one provider's upstream API can require a package update independent of your own release cycle. The README does not document a rollback procedure, so pinning versions in your project file is the only lever the documentation supports.

Where to ask and what the project does not cover

Support runs through Gitter and StackOverflow under the aspnet-contrib tag, and security issues go through the SECURITY.md policy in the .github directory rather than the issue tracker. What the README does not cover is provider-specific setup: it shows ClientId and ClientSecret being assigned, but not how to obtain them, and it does not list which providers are implemented beyond the GitHub, Twitter/X and Dropbox examples. The repository's src directory is the authoritative list. The README also does not document rollback or version pinning behaviour, which matters if you are upgrading a major version across a framework change. Treat the samples directory and the source tree as the practical documentation, and the README as the entry point.

Editorial conclusion

Adopt it if you already have an ASP.NET Core application wired to the built-in authentication middleware and need a specific provider that the package collection covers. Skip it for greenfield work: the README itself encourages new applications to use the OpenIddict client, which supports OpenID Connect, stateful replay countermeasures, token introspection and revocation, and configuration discovery. Before committing, verify which of the two providers you actually need and confirm the package's current version on NuGet.

Frequently asked questions

Official sources

1. aspnet-contrib/AspNet.Security.OAuth.Providers on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases