Capacitor Auth Manager — a project by Ahsan Mahmood
Framework-agnostic TypeScript authentication library unifying 15 OAuth, passwordless, credential, and biometric sign-in flows behind one provider-less API.
Fifteen ways to sign in, and a product needs about three of them.
Which three is the part nobody knows at the start. A founder wants Google because everybody already has one, then the first enterprise conversation asks for Microsoft, then support asks for a magic link because a user cannot remember which button they pressed the last time.
Each of those is a week.
Not a week of difficult work. A week of reading one provider's console, finding where it disagrees with the last one, and writing the fourth version of the same token-refresh code you have already written in other codebases.
Capacitor Auth Manager exists because I had written it more than once.
It is one singleton, one provider-configuration model and one auth-state contract, and it behaves the same way in React, Vue, Angular or plain JavaScript. There is no context provider to wrap your tree in. You import it and read it, the way a Zustand store works.
That is why it can be adopted a screen at a time.
The provider list runs to fifteen. Google, Microsoft, Facebook, GitHub, Slack and LinkedIn cover the OAuth side, Firebase covers the projects already standing on it, and then there are the three that are not OAuth at all: password, one-time codes with magic links, and biometric sign-in.
Security is where a library like this either earns its place or quietly loses it.
Manual OAuth flows run real S256 PKCE rather than the plain variant that is easier to implement and protects nothing. An ID token is checked for its nonce and its expiry rather than decoded and believed. Secure storage is an interface, so where a token actually sits is your decision instead of mine. The browser biometric fallback encrypts with AES-GCM.
Then there is the part the documentation says out loud.
A client library cannot be your security boundary. It can run a ceremony correctly and hand you a result; whether that result deserves trust is a question for your server, and no amount of code on this side of the line answers it. That admission costs adoption. It is worth it, because the alternative is a developer who believes the wrong thing about their own login.
What it cost was the boring half: a 79-test suite, clean ESM, CommonJS and browser builds, and zero lint warnings held as a condition rather than a target.
The standing cost is different, and it never goes away.
Fifteen providers is fifteen surfaces somebody else controls. A provider renames a scope, retires an endpoint or tightens a redirect rule, and that failure arrives in my inbox rather than in a compiler, usually from somebody whose users cannot sign in this morning.
The honest version of the maintenance answer is a method rather than a promise. A fix publishes as a new version in the same pass that produced it. That is how every package here is handled, and it is all one maintainer can truthfully offer.
The optional native plugin covers Android. There is no iOS release behind any of this, because there is no Apple Developer account here.
It is on npm as capacitor-auth-manager under MIT, with the source at github.com/aoneahsan/capacitor-auth-manager.
Read the section on client-side limits first. It is the part most authentication libraries leave you to discover on your own, usually at the moment when discovering it has already become expensive to act on.
What it does, and what that costs to build
- 15 sign-in providers behind one provider-less API
- Framework-agnostic (React/Vue/Angular/vanilla JS)
- S256 PKCE + OIDC nonce/exp validation
- AES-GCM biometric web fallback
- Pluggable secure storage interface
- Optional native Capacitor plugin (iOS/Android)
- Tree-shakeable ESM/CJS/browser bundles
Built with
- TypeScript
- CapacitorJS
- Rollup
- React 19
- Vue
- Angular
Worth knowing
- npm
- package
- authentication
- oauth
- capacitor
- biometric
Who built Capacitor Auth Manager, and who maintains it?
Ahsan Mahmood, working alone, and he is the person who answers an issue on it. That is the honest maintenance picture: one maintainer, no company behind the package, and a fix that publishes as a new npm version in the same pass that produced the fix. It is on npm as capacitor-auth-manager under MIT, with the source at github.com/aoneahsan/capacitor-auth-manager. What is not on offer is a support commitment, because a promise about future availability is not one that a single maintainer can make honestly.
Which sign-in methods does it cover?
Fifteen providers behind one API: the OAuth set including Google, Microsoft, Facebook, GitHub, Slack and LinkedIn, then Firebase, then the three that are not OAuth at all, which are password, one-time codes with magic links, and biometric sign-in. The count is not the interesting part. Adding a fourth sign-in method to a live product becomes a configuration change instead of another week spent reading a provider console, and that week is the real cost this removes.
Does Capacitor Auth Manager work on iPhone?
The OAuth flows are HTTP redirects, so they run in any browser, an iPhone browser included, because none of that is platform code. The optional native plugin covers Android. There is no iOS release behind this work, because there is no Apple Developer account here and nothing I build has shipped to the App Store. So the accurate reading is web everywhere, native on Android, and no claim of any kind about what happens inside an Apple review queue.
Do I have to wrap my application in a provider component?
No. There is no context provider and no higher-order component to add; the library is a singleton you import and read, in the way a Zustand store works. That is what makes it adoptable one screen at a time rather than as a rewrite, and it is why the same package behaves identically in React, Vue, Angular and plain JavaScript. It builds to ESM, CommonJS and a browser bundle, and it is tree-shakeable, so a project using three providers does not carry the other twelve.
What does this library deliberately not do?
It does not make your client the security boundary, and the documentation says that out loud rather than implying otherwise. A client library can run an authentication ceremony correctly and hand you a result; deciding whether that result may be trusted belongs to your server, and no code on the browser side of the line changes it. It also does not host anything, hold state on your behalf, or replace the provider consoles where scopes and redirect URIs live. Those stay in your accounts, which is the version of this where you are not locked in.
https://aoneahsan.com/projects/com.aoneahsan.capacitorauthmanager