angularx-social-login and the provider matrix behind Angular social sign-in

One service, five providers, one configuration object

The @abacritt/angularx-social-login module supports authentication with Google, Facebook, Amazon, Microsoft and VK out of the box, and can be extended to other providers. The project description calls it a social login and authentication module for Angular 21, and there is a live demo linked from the README.

The design is a single service, SocialAuthService, and a single configuration object, SocialAuthServiceConfig, which is provided at bootstrap. Each provider gets an id and a provider instance:

import { SocialLoginModule, SocialAuthServiceConfig } from '@abacritt/angularx-social-login';
import {
  GoogleLoginProvider,
  FacebookLoginProvider
} from '@abacritt/angularx-social-login';

The configuration carries a couple of global switches and then a providers array. autoLogin is set to false in the example, and lang is set to en. Inside the array, each entry pairs the provider's PROVIDER_ID constant with a constructed provider instance, here a GoogleLoginProvider and a FacebookLoginProvider each given a client id. The onError callback receives the error, and the whole object is cast with as SocialAuthServiceConfig.

The useValue provider token is the string 'SocialAuthServiceConfig', which is worth noting. A string token rather than an InjectionToken is a small design choice with consequences: it works, it is what the library documents, and it does not give you compile-time safety on the token name.

The module itself is imported into your NgModule alongside the provider classes, and the SocialLoginModule appears in the imports array of the module that needs it. The README also points to the Discussions page for questions rather than issues, which is a small signal about how the project expects to be used.

Signing in is one method call, except for Google

The service API is small. For most providers, sign-in is a single call with the provider id:

import { SocialAuthService } from "@abacritt/angularx-social-login";
import { FacebookLoginProvider } from "@abacritt/angularx-social-login";

  signInWithFB(): void {
    this.authService.signIn(FacebookLoginProvider.PROVIDER_ID);
  }

  signOut(): void {
    this.authService.signOut();
  }

Google is the exception, and the README is unusually direct about why. GoogleLoginProvider has no signIn() method as other providers do, because the login flow is triggered by a button that the Google Identity Services client generates. Calling SocialAuthService.signIn(GoogleLoginProvider.PROVIDER_ID) will have no effect.

Instead, the component template gets a directive, GoogleSigninButtonDirective, exported from the GoogleSigninButtonModule, wrapping the sign in button:

<asl-google-signin-button type='icon' size='medium'></asl-google-signin-button>

The directive is configurable through a documented set of attributes, and the table gives the type, size, shape, text, width, theme and logo_alignment options with their allowed values and defaults, and the README links to Google's own button generator and the attribute reference. The button will only work if the GoogleLoginProvider is registered in SocialAuthServiceConfig.

This is the single most important thing to know before wiring the library into a template. The Google path is delegated to Google's own client rather than driven by the library, which is why the button is required and why the signIn call does nothing. It also means the Google flow is the one you cannot drive from a button click handler of your own.

Token handling is three separate methods

Once a user is signed in, the library exposes token operations that are worth reading as a set rather than individually.

There is a manual refresh of the auth token, through refreshAuthToken(GoogleLoginProvider.PROVIDER_ID), which the README describes as something that can be triggered once a user is logged in. There is a request for an access token, through getAccessToken, for the scopes specified in GoogleInitOptions.scopes, and the access token can then be reused to make calls to Google APIs. And there is a refresh of the access token, described as the token being refreshed, or revoked, once it has been obtained.

The access token example shows what the token is for. The component requests the token, stores it in a private field, and then uses it as a bearer token in an HttpClient call to the Google Calendar API:

  getAccessToken(): void {
    this.authService.getAccessToken(GoogleLoginProvider.PROVIDER_ID).then(accessToken => this.accessToken = accessToken);
  }

The distinction between the auth token and the access token is the part that matters for a backend integration. The auth token identifies the session with the provider, and the access token is the bearer credential your server can use to act on the user's behalf. A library that hands you the access token directly, as this one does, saves you from implementing the OAuth exchange client side, and it also means the token is present in the browser, which is a decision your threat model has to agree with.

The docs also say you must subscribe to the authentication state, and the Google button section repeats that requirement, so the subscription is not optional scaffolding but part of how the library reports sign-in and sign-out.

The compatibility matrix is the real documentation

The table in the README maps library versions to Angular versions, and it is the most useful thing in the repository for anyone deciding whether to adopt the module.

The mapping runs from the current line backwards. Version 2.5.X targets Angular 20, 2.4.X targets Angular 19, 2.3.X targets Angular 18, 2.2.X targets Angular 17, and 2.1.X covers Angular 16 and 17. Before the scoped package, angularx-social-login:4 covered Angular 12 and 13, version 3 covered 9, 10 and 11, and version 2 covered 5 through 8. Version 1 covered 13, 14 and 15.

Two things follow from that table. The library is not a single package for all time; the name changed when the package moved into the @abacritt scope, so an old tutorial will import angularx-social-login and a current one imports @abacritt/angularx-social-login. And the library version is tied to an Angular major, which means upgrading Angular means moving to a different library line.

The repository's package.json reflects the same idea from the inside. It is a private workspace named @abacritt/angularx-social-login-ws, and its dependencies and devDependencies are all on Angular 20, with the CLI and compiler packages at version 20 and the testing stack on Jest 30 with jest-preset-angular and the @angular-builders/jest builder. The scripts show an Angular CLI library project with a dedicated build-lib script and a deploy script that publishes from the dist/angularx-social-login directory.

The release history is consistent with the matrix. Version 2.5.0 updated to Angular 20 in July 2025, 2.5.1 was a tentative fix for runtime issues in September 2025, and 2.6.0 updated Angular to version 21 in March 2026. The last push was on 2026-10-21, so the source tree is ahead of the last release.

What the repository shows about the project itself

The top level of the repository describes a maintained library rather than a demo. Alongside the README and the CHANGELOG there is a docs directory, a microsoft-provider.md file at the root, an e2e directory, a projects directory for the Angular library layout, a src directory for the demo application, and separate test configuration files for Jest and for the TypeScript spec compiler.

The presence of a separate microsoft-provider.md is informative. It suggests that some providers need more explanation than a code sample, which is consistent with the rest of the README, where the Google path needs a directive, a subscription and a note that signIn does nothing.

The tooling is conventional for an Angular library in 2025. ESLint with the angular-eslint set of packages and a parser, husky for git hooks, lint-staged, jest with the Angular builder and jest-preset-angular, ng-packagr for the packaging, and a.browserslistrc, an.eslintrc.json, an.npmignore and an.editorconfig. The @types/google.accounts package in the devDependencies is a direct consequence of the Google Identity Services client the library integrates with, and the protractor and jasmine-spec-reporter entries in the dependency list show the residue of an earlier end to end testing approach alongside the newer Jest setup.

The README documents the size of the provider set. Five providers ship out of the box, the topics cover Google and Facebook login specifically, and the Microsoft provider has its own document. Whether a provider such as Apple or a custom OIDC issuer is supported is not something the visible documentation answers, so anyone with a specific provider requirement should check the docs directory and the source rather than assume.

Where angularx-social-login is the wrong tool

The first wrong case is an Angular version the matrix does not cover. The table is explicit about which library line works with which Angular major, and a mismatch here is not a soft warning, it is a build that fails or a runtime that misbehaves, which is probably what the 2.5.1 tentative fix for runtime issues was about. A team on an Angular major the library does not list, or one that has already moved past 2.6.0, should treat the matrix as a hard boundary.

The second wrong case is a requirement for a provider the library does not ship. The README says the set can be extended to other providers, but extension means writing a provider class, and that is work the library does not do for you. If your application needs Apple sign-in, a SAML or OIDC enterprise provider, or a provider the library has never heard of, the cost of extending can exceed the cost of integrating that one provider's SDK directly.

The third is a security model that does not want tokens in the browser. Because the library exposes getAccessToken and lets you use the returned value as a bearer token in a browser side HTTP call, the access token exists in client memory and, in the example, in a component field. For a public client application that is normal and unavoidable, since the OAuth code exchange with PKCE happens in the browser. For a setup where the token must never reach the browser, that is a design disagreement rather than a missing feature.

The alternative worth naming is the platform's own authentication route, and the difference in approach is worth being precise about. A framework provided identity service, with its own UI, its own session handling and its own token storage, gives you a consistent sign-in experience across providers without a per-provider configuration, at the cost of an extra network hop to somebody else's service and one more vendor in the authentication path. The library in this repository is the opposite trade: everything runs in your application, you configure each provider yourself, you own the flow, and you accept the maintenance of the provider matrix as Angular moves. For a product that needs its own branded sign-in screen and its own backend session model, that trade is usually right. For a product that just needs a working login and would rather not think about OAuth, the platform service is the shorter path.

Maintenance, licence and the versioning question

The repository is not archived and the last push was on 2026-10-21, so work is landing on the master branch. The recent tags are 2.5.0 in July 2025, 2.5.1 in September 2025 and 2.6.0 in March 2026, which is a cadence of roughly one release per Angular major, with a patch release when something broke at runtime.

That pattern is a reasonable way to maintain a library whose compatibility is defined by its host framework, and it is also a warning about what you get when you install. Because the default branch is master and the release line lags it, installing from the registry gives you a tagged version tied to a specific Angular major, while tracking master gives you the current source. The README does not discuss this, so the choice is yours to make deliberately.

The licence is the other open question. The project metadata records it as unknown, and the visible repository listing includes a LICENSE file, but the terms are not stated in the documentation available here. Anyone planning to use this in a commercial product should read that file, and anyone who cannot accept unclear terms should not ship the dependency until the position is confirmed with the maintainer. That is a licensing question for your own review rather than advice from us.

The public surface is also worth noting for anyone evaluating it. The README directs questions to Discussions rather than the issue tracker, which means support happens in a forum format and the maintainer is reachable without a formal issue. For a library this small, that is probably a feature.

Editorial conclusion

angularx-social-login fits an Angular application that needs two or three social providers behind a single service and wants the sign-in button and the token handling in one library rather than three separate SDK integrations. It is the wrong choice if your application is on an Angular major that the compatibility matrix does not cover, and the wrong choice if you need a provider the library does not ship, since extending means writing a provider yourself. Before you adopt it, check the matrix row for your Angular version, read the provider docs directory, and confirm that the library version you install matches the Angular major you are on.

Frequently asked questions

Official sources

1. abacritt/angularx-social-login on GitHub
2. Issues
3. README
4. Releases