External Identity Providers in ASP.NET Core Identity

Back to: ASP.NET Core Identity Tutorials

External Identity Providers in ASP.NET Core Identity

In this article, I will discuss External Identity Providers in ASP.NET Core Identity. Please read our previous article discussing Hybrid Authorization in ASP.NET Core Identity, i.e., combining Role-Based and Claim-Based Authorization in ASP.NET Core Identity.

The Need for External Identity Providers

In the early days of the web, every website had its own user authentication system. Users were required to:

• Create a new account on each site,
• Choose and remember yet another unique password.

For developers, this created a long list of responsibilities:

• Securely storing user passwords (including hashing and salting),
• Building password reset and recovery workflows,
• Managing account lockouts and security controls,
• Guarding against threats like brute force attacks, SQL injection, and phishing.

This approach was not only time-consuming and error-prone, but also introduced significant security risks and maintenance overhead.

Today, users already have trusted, secure digital identities with major providers such as:

• Google
• Microsoft
• GitHub
• Facebook / Meta
• LinkedIn
• Amazon
• Apple

Instead of building and managing authentication systems from scratch, modern applications can delegate authentication to these trusted providers, a concept known as External Identity Providers in ASP.NET Core Identity.

In simple terms: Why force users to create yet another password when they already have secure identities with providers like Google or Microsoft?

By integrating external identity providers:

• Users enjoy a faster, seamless login experience
• Developers reduce security liabilities and implementation effort
• Applications benefit from stronger identity assurance (e.g., multi-factor authentication, anomaly detection)

What Are External Identity Providers?

An External Identity Provider (IdP) is a third-party service that handles user authentication on behalf of your application. Instead of requiring forcing to create yet another username and password, we allow them to sign in using trusted services like Google, Microsoft, Facebook, GitHub, and others.

Real-World Example:

• Imagine going to a club. The bouncer doesn’t verify your age by calling your school. Instead, they trust your government-issued driver’s license, a verified form of identity.
• Similarly, your application doesn’t verify the user directly. It trusts an external identity provider (like Google) to authenticate the user and confirm their identity.

When using external identity providers in ASP.NET Core:

1. Redirect → Your app redirects the user to the identity provider (Google, Microsoft, etc.).
2. Authenticate → The identity provider authenticates the user (e.g., asks for their Google credentials, Facebook credentials based on the chosen provider).
3. Token Issued → Upon successful login, the provider returns a token containing user identity information (e.g., email, name, unique ID).
4. Sign In → Your app validates the token and signs the user in, without ever seeing their password.

Why Do We Need External Identity Providers?

In traditional applications, users sign up by creating a local account with an email and a password. While this works, it comes with several challenges:

• Too Many Passwords → Users get frustrated managing multiple credentials across different sites.
• Poor User Experience (UX) → Lengthy signup forms and verification steps often lead to higher bounce rates.
• Security Burden → Developers and businesses are responsible for securely storing, hashing, and protecting user passwords — a risky and costly responsibility.

External Identity Providers solve these problems by letting users sign in with accounts they already trust, such as Google, Microsoft, Facebook, GitHub, or LinkedIn. This benefits everyone involved. 

By using external providers, the Users, Developers, and Businesses will get the following benefits:

Benefits for Users

• Single Sign-On (SSO): Access multiple applications with one login (e.g., Google or Microsoft).
• Convenience: No need to remember or manage multiple passwords.
• Familiarity & Trust: Users feel safer logging in through well-known providers (e.g., Google Sign-In, Microsoft Login).

Benefits for Developers

• No Password Storage: Offload the responsibility of handling user credentials. Avoids the risk of storing and hashing passwords.
• Enhanced Security: Identity providers handle multi-factor authentication (MFA), password recovery, suspicious login detection, and more.
• Reduced Attack Surface: Less risk of breaches since passwords never touch your system.
• Faster Onboarding: One-click login increases conversion rates.
• Improved Productivity: Developers spend time building business features, not authentication logic.

Benefits for Businesses

• Higher Conversion Rates – Users are more likely to sign up if they don’t have to type long forms
• Brand Trust – Integration with trusted providers like Google and LinkedIn builds user trust.
• Scalability – Easily support onboarding for thousands (or millions) of users without scaling internal authentication systems.

External Identity Providers streamline the login process, reduce security risks, and offer a better experience for users, while freeing developers and businesses to focus on what matters most.

Different External Identity Providers in ASP.NET Core Identity

ASP.NET Core Identity provides built-in support for integrating with various external identity providers. Each provider requires specific configuration steps and packages for integration with ASP.NET Core. The following are some of the most popular providers we can integrate:

Google:

• Why Use It? Google is widely recognized and frequently used for authentication across various applications, and many users already have Google accounts, making it easy for them to sign in.
• How to Set Up? You need to register your application in the Google API Console. Afterward, you’ll receive a Client ID and Client Secret to configure your ASP.NET Core application.
• Package: Microsoft.AspNetCore.Authentication.Google is used to integrate Google authentication in the ASP.NET Core application.

Facebook:

• Why Use It? Facebook has a vast user base and is a widely trusted social network.
• How to Set Up? You have to create a Facebook App on the Facebook Developer Console, which will give you an App ID and App Secret to integrate with your ASP.NET Core application.
• Package: Microsoft.AspNetCore.Authentication.Facebook is used to integrate Facebook authentication.

Twitter (Currently X):

• Why Use It? Popular among social media users, especially those interested in real-time updates and short-form content.
• How to Set Up? You need to create a developer account at the Twitter Developer Platform and obtain the API Key and API Secret Key to enable Twitter authentication.
• Package: Microsoft.AspNetCore.Authentication.Twitter integrates Twitter login into the ASP.NET Core application.

Microsoft:

• Why Use It? Ideal for apps targeting users within the Microsoft ecosystem or Windows users (Windows, Xbox, Outlook, etc.).
• How to Set Up? Register your application on the Microsoft Identity Platform, get your Client ID and Client Secret, and configure them in your ASP.NET Core application.
• Package: Microsoft.AspNetCore.Authentication.MicrosoftAccount provides integration for Microsoft Account authentication.

GitHub:

• Why Use It? It is useful for applications targeting developers and those in the open-source community.
• How to Set Up? You need to register your application on the GitHub Developer Portal and obtain Client ID and Client Secret.
• Package: Microsoft.AspNetCore.Authentication.GitHub integrates GitHub login in the ASP.NET Core Application.

LinkedIn:

• Why Use It? It is ideal for professional and enterprise applications.
• How to Set Up? You need to register your application via the LinkedIn Developer Portal to obtain the Client ID and Client Secret.
• Package: AspNet.Security.OAuth.LinkedIn provides integration for LinkedIn Account authentication.

Note: Integrating these external authentication providers follows a similar pattern. If you understand how to integrate one of the external authentication providers, implementing others is not that different.

What is OAuth 2.0?

Definition 1: OAuth 2.0 is an authorization framework, not an authentication protocol. Its primary purpose is not to prove who the user is, but to allow one application to access specific resources on behalf of the user, without exposing the user’s password.

Definition 2: It was designed to allow a third-party application to gain limited access to a user’s resources (like profile, calendar, photos, contacts) that are stored on another system (like Google, Facebook, etc.), without ever seeing the user’s password by the third-party application.

Definition 3: OAuth 2.0 is a delegated authorization framework. It enables an Application (Client) to obtain access tokens from an Authorization Server (such as Google), allowing it to call a resource server’s APIs (e.g., Google Calendar, Microsoft Graph) on behalf of a user, without ever seeing the user’s password.

Real-World Example:

Imagine a design app like Canva wants to import images from your Google Drive. Instead of asking you for your Google password, Canva uses OAuth 2.0 to redirect you to Google, where you grant permission.

Once you approve, Google issues a temporary access token to Canva. This token allows limited access to your Drive (e.g., only image files), not your Gmail or Contacts.

This Process Ensures:

• Canva never sees your Google password
• You control what Canva can access and for how long
• You can revoke access at any time via your Google account settings

So,

• OAuth 2.0 is about delegating access, not verifying identity.
• The user provides consent, not credentials.
• The client app gets access to specific resources, not full account access.
• OAuth is commonly used by services like Google, Facebook, Microsoft, and GitHub to protect user data while enabling integrations.

What is OpenID Connect?

OpenID Connect (OIDC) is an authentication layer built on top of the OAuth 2.0 framework. While OAuth 2.0 focuses on authorization (what an app can do on behalf of a user), OIDC focuses on authentication (proving the user’s identity).

OIDC introduces the concept of an ID Token, a JWT (JSON Web Token) that securely contains verified information about the user, such as their unique ID, email, name, and profile picture. Your app can validate this token to log the user in without handling passwords directly.

Real-World Example:

Imagine you’re building a job portal and want users to log in using their Google account.

• You don’t need access to their Google Drive or Calendar.
• You just want to authenticate them and get some basic profile details (email, name, photo).

With OpenID Connect, Google:

• A user signs in with Google using OIDC.
• Google not only gives your app an Access Token (for accessing Google APIs, if needed) but also an ID Token (to confirm who the user is).
• The ID token contains claims such as:
  1. User’s unique ID (sub)
  2. Email
  3. Name
  4. Profile picture
  5. Issuer (who authenticated them)
  6. Expiry time
• Your app now has verified identity information and logs in the user securely without making extra API calls.

So, OIDC = Authentication + Profile Info, while OAuth = Authorization to access data

Think of it this way:

• OAuth is like giving someone a visitor’s badge to enter a building and use the cafeteria (resource access). But that badge doesn’t tell you exactly who the visitor is.
• OpenID Connect, on the other hand, gives you a passport or driver’s license along with the visitor’s badge. Now you know not just what they’re allowed to do, but who they are (name, email, unique ID, even profile picture).

When to Use OAuth 2.0

You use OAuth 2.0 when your main goal is Authorization — Accessing User Resources on another system.

Examples:

• Your app wants to read a user’s Google Drive files.
• A calendar app needs to create events on behalf of the user in their Outlook calendar.
• A photo printing service needs access to a user’s Instagram photos.

When to Use OpenID Connect

You use OpenID Connect when your main goal is Authentication — Verifying User Identity.

Examples:

• Your web app allows “Login with Google” or “Login with Microsoft.”
• You need a user’s verified email address to create a profile in your system.
• An enterprise app aims to integrate Single Sign-On (SSO) to eliminate the need for separate credentials.

OAuth 2.0 and OIDC Support by External Provider:

Not all external provider supports OAuth 2.0 and OIDC Support:

• Google and Microsoft → support both OAuth 2.0 and OIDC.
• Facebook, Twitter, LinkedIn, GitHub → support only OAuth 2.0, so you must use the access token to query their APIs for user info.

For a better understanding, please have a look at the following image:

How External Identity Providers Work in ASP.NET Core Identity

External Identity Providers (Google, Facebook, Microsoft, LinkedIn, etc.) allow users to log in without creating a separate username and password for your application. Instead, they authenticate with a trusted provider, and your application receives verified user details.

Registering Your Application with the Provider

First, you must register your application with each external provider.

• For Google, you register in the Google Cloud Console.
• For Facebook, you register on the Meta for Developers Dashboard.

When registering, you get:

• Client ID – Identifies your app to the provider.
• Client Secret – Used for secure communication between your app and the provider.

These are configured in appsettings.json or Program.cs in ASP.NET Core. Without this setup, your app cannot talk to the provider securely.

When you integrate Google, Facebook, Microsoft, or other external providers into an ASP.NET Core Identity system, the login flow typically goes through the following steps:

Step 1: User Clicks Sign in with [Provider]

• Your application displays social login buttons (e.g., Google, Facebook, Microsoft).
• When the user chooses a provider (say Google), they click “Login with Google”.
• This signals that the authentication process will be handled by Google instead of your application.

At this stage, your application does not authenticate the user. It only sends them to the provider.

Step 2: Redirect to the External Provider’s Login Page

• Once the button is clicked, your application immediately redirects them to the chosen provider’s login page.
• For example, if they choose Google, they are redirected to the official Google Sign-In page.
• This ensures that authentication happens on the provider’s secure login system, not on your app.

At this stage, your app is basically saying to Google: This person wants to log in — please check who they are.

Step 3: User Authenticates with the Provider

• On the provider’s login page, the user enters their credentials (email + password, or other MFA options like OTP, fingerprint, etc.).
• For example, on Google’s page, the user enters their Gmail credentials.
• This is safer because your application never handles or stores the user’s raw password.
• The provider is responsible for validating the credentials using its own security measures.

At this point, the external provider verifies the identity of the user.

Step 4: Provider Redirects Back to Your Application

• If the login is successful, the external provider sends the user back to your application.
• This happens via a callback URL, which you need to configure earlier (for example: /signin-google) while registering your application with the external provider’s platform.
• Along with this redirection, the provider sends a token (an ID token and sometimes an access token) securely.

This token is a secure digital package that contains:

• User’s identity information (e.g., Name, Email, Profile ID, User’s unique ID from Provider).
• Optionally, an Access Token that can be used to call the provider’s APIs (e.g., Google Calendar API, Microsoft Graph, etc.).

This step typically uses OAuth 2.0 or OpenID Connect under the hood.

Step 5: Application Validates the Token and Signs the User In

• ASP.NET Core Identity validates the received token from the provider to ensure it is genuine and untampered.
• If valid:
  • The system checks if this user already has a local account in your database.
  • If yes, the user is signed in immediately.
  • If no, ASP.NET Core Identity may create a new local user record linked to the external provider.
• Finally, the user is authenticated and given access to your application without ever creating a separate username/password.

This way, your app doesn’t need to handle raw passwords, only trusted tokens.

External Identity Providers remove the burden of password management from your app. Instead, trusted providers (Google, Microsoft, Facebook, etc.) verify the user’s identity, issue a secure token, and ASP.NET Core Identity uses that token to sign the user into your application. This improves security, user experience, and trust.

In the next article, I will discuss how to integrate the Google External Authentication Provider in ASP.NET Core Identity. In this article, I explain External Identity Providers in ASP.NET Core Identity. I hope you enjoy this article, External Identity Providers in ASP.NET Core Identity.