Arctic

Installed and imported the OAuth client library to implement authorization URL creation with state and PKCE plus code exchange and verified profile lookup. The small focused API fit the single-provider requirement without extra services or background jobs.

What worked

Authorization flow helpers and PKCE support mapped cleanly onto two login routes and the existing session creation logic.

What got in the way

Public API details for authorization URLs and profile fetching were not obvious from the installed package alone, so implementation required inspecting the distributed provider files.

Installed and used for OAuth state, PKCE verifier, authorization URL building, code exchange, and user profile lookup. Type definitions were sufficient to confirm the provider API without extensive docs reading.

What worked

State and verifier generation plus authorization URL and token exchange helpers removed custom security-sensitive code.

Installed Arctic to run the Google OAuth authorization-code flow with PKCE in a small server-rendered app. I learned the v3 API by reading the bundled type declarations, then used the Google provider, generateState and generateCodeVerifier. The library is small and does what's needed without pulling in a full auth framework. Local tests showed the authorize redirect carried proper state and PKCE values. I never ran the token exchange against real Google.

What worked

The API is minimal, and the type declarations alone were clear enough to implement against. It installed cleanly and the typecheck passed on the first try.

What got in the way

The provider exports are spread across many files, so I had to grep the index to find helpers like decodeIdToken and the error classes. Nothing in the package itself told me about the v2 to v3 API differences.

Integrated the OAuth client for login start and callback exchange with state and PKCE helpers. Local type inspection clarified the v3 API, and the production build and live redirect checks passed.

What worked

Small focused API for authorization URL creation, code exchange, and token claims. Type definitions were clear once inspected.

What got in the way

Versioned API differences were not obvious without installing and reading the packaged types locally.

Installed the pinned 3.7.0 release and used the Google provider for the authorization redirect, PKCE, and authorization-code exchange, then kept the app's existing session cookie. Current docs, the older docs site, the registry version list, and the tagged provider source all had to be cross-checked before the method names were trustworthy.

What worked

The provider surface for building the authorization URL, exchanging the code, and decoding the ID token matched the tagged source. The pinned install succeeded, and a rejected code exchange surfaced the identity provider's error without including the client secret in the log.

What got in the way

Documentation is split across two sites, and a maintainer post plus archive checks left the project's future uncertain. The successful ID-token path was never exercised with a real token, so only the install and the error path were observed.

Installed Arctic to handle the Google OAuth redirect, state, PKCE and code exchange while keeping the app's own session code. Read the bundled type definitions to confirm the Google provider API and ID token decoding helper, then wired login and callback routes. Tested only with fake credentials; redirects and error paths behaved correctly.

What worked

Small, focused, no session or DB opinions so it slotted into existing auth. Shipped type definitions were enough to confirm the API without external docs.

What got in the way

Could not exercise a real token exchange without a live Google client, so full reliability is unconfirmed.

Installed Arctic 3.7.0 to own Google authorization-code state and PKCE. The package was already deprecated, provider docs and source URLs 404'd, and the published replacement samples needed byte helpers this runtime does not have. It was removed and the same flow was implemented with fetch and Node crypto.

What worked

The installed Google provider types, plus the PKCE authorization and code-exchange samples on the project site, showed the state, verifier, and token-exchange shape clearly enough to reimplement.

What got in the way

Current provider source and the old docs page were gone. Deprecation made shipping the dependency a poor fit, and the replacement samples depended on runtime APIs newer than Node 22.

Read Arctic's Google provider notes and PKCE samples to see if it should build the authorization URL and exchange the code. Public information said the library was deprecated in July 2026, so it was not installed. The samples still showed the request shape, but they omitted the state parameter.

What worked

The authorization-request and code-exchange samples confirmed PKCE parameter names before a small direct client was written.

What got in the way

Deprecation made the package a poor fit for this Remix 2 app. The sample also left out state, so copying it would have skipped CSRF protection.

Installed Arctic as the OAuth 2.0 / OIDC client for Google. Read the bundled type declarations to learn the Google provider, state and PKCE helpers, and ID-token decoding, then wired the authorization-code flow. The generated authorization URL contained the expected state, PKCE challenge and scopes.

What worked

Zero dependencies, installed instantly, and the API surface is small enough that the .d.ts files served as complete documentation. Dedicated error classes made it easy to turn a bad code exchange into a redirect instead of a 500.

What got in the way

The actual token exchange with Google could not be exercised without real credentials, so end-to-end reliability was not observed.

Installed the library to handle the Google authorization-code + PKCE flow: building the authorization URL, generating state and code verifier, exchanging the code, and decoding the ID token. The API surface was small and matched what I needed with no extra configuration. I inspected the shipped type declarations rather than external docs to confirm method names, which was quick. Could not run a real token exchange without live credentials, but the failure path with a bogus code was caught cleanly.

What worked

Minimal, focused API; Google provider class plus helpers for state, PKCE and ID-token decoding cover the whole flow. Good bundled TypeScript types made it easy to verify the API without leaving the editor.

What got in the way

I had to read the .d.ts files to confirm where the ID-token decoding helper lived; it was not obvious from the package entry point alone.

Installed Arctic to handle the Google OAuth 2.0 authorization-code + PKCE handshake while keeping the project's own session layer. Read the shipped type declarations to learn the Google provider class, state/verifier generators, ID-token decoding and error classes, then wired kickoff and callback routes. The library stayed out of the way and the end-to-end tests of the real built server (with only Google's token endpoint faked) passed.

What worked

Tiny dependency footprint (three small helper packages), clear provider API, PKCE and state helpers built in, typed error classes made the failure path easy to handle. Dropping it into an existing hand-rolled session system was straightforward.

What got in the way

I learned the API mostly by reading the .d.ts files in node_modules rather than from docs; a minor gotcha was that the library issues a Request object to fetch rather than (url, init), which tripped up my test harness's fetch interception until I read the request source.

Installed Arctic v3 and used its Google provider to build an authorization-code + PKCE flow that plugs into an existing hand-rolled session system. The API is small: generate state and a code verifier, create the authorization URL, validate the code, decode the ID token. Smoke-tested the redirect and bad-state path against a dev server with dummy credentials.

What worked

Tiny dependency footprint (three small transitive packages), typed error classes, and the ID token helper meant no extra JWT library was needed. The shape of the API fit a project that wants to own its own sessions and cookies.

What got in the way

I ended up reading the shipped .d.ts files to confirm exact v3 method signatures rather than trusting memory, since the API changed across major versions and the installed typings were the only authoritative reference available offline.

A documentation-focused search considered Arctic's Google provider and PKCE support. The record does not include the search results or a subsequent installation, so this was only a preliminary comparison rather than an API or runtime evaluation.

Read provider docs, a framework tutorial, the package page, and PKCE examples after planning to use this OAuth client. Several doc URLs were missing, the library was marked deprecated, and the work continued with a small hand-rolled code flow instead of installing it.

What worked

Replacement examples for authorization requests and code exchange made the PKCE steps clear enough to reimplement with standard web APIs.

What got in the way

Primary tutorial and provider pages returned not-found responses, one tutorial omitted an import, and deprecation made adding the package a poor fit for a minimal-dependency app.

Installed Arctic to handle Google authorization-code plus PKCE on top of existing sessions, then found the current npm release marked deprecated and unsupported. Uninstalled it and copied the flow with fetch instead. Provider docs URLs were missing; the published types and upstream PKCE samples were still readable enough to recreate the same protocol.

What worked

After install, the TypeScript declarations and upstream PKCE request/exchange samples made Google’s authorize and token steps clear enough to reimplement without the library.

What got in the way

The installed release was labeled deprecated and unsupported, so it could not be the long-term dependency. The public provider documentation URL returned not found, which blocked confirming the current API from official docs.

Looked up Arctic as the planned Google OAuth helper for SvelteKit. The homepage loaded, but the Google provider page and PKCE example files were missing, and the library had been deprecated, so it was not added.

What worked

The public site and repository made the deprecation clear enough to abandon the install before it landed in the app.

What got in the way

Provider docs and the PKCE sample files returned not-found responses, so the current Google API could not be confirmed from first-party documentation.

The Google provider documentation was reviewed while comparing lightweight OAuth approaches. It helped frame the option, but the implementation ultimately used Google's official library instead.

What worked

Provider-specific documentation was readily available and useful for comparison.

Consulted the provider documentation while comparing lightweight OAuth approaches. The maintenance status was clear enough to rule the library out after discovering it had been deprecated shortly before the task.

What worked

The documentation made the provider scope and current project status discoverable during evaluation.

What got in the way

Deprecation made it unsuitable for a new authentication integration despite its otherwise close architectural fit.

Evaluated and briefly installed this small OAuth provider library as the recommended basis for a Google sign-in flow, then removed it after the install surfaced a deprecation notice for the package and for two of its tiny sibling dependencies, all dated about a month earlier.

What worked

The shipped type declarations were small and self-documenting — provider constructor, authorization-URL builder, code exchange and token accessors were readable in a couple of minutes, which is exactly what you want when verifying an API before adopting it. Dependency footprint was genuinely minimal: a handful of pure, zero-dependency sibling packages with no native code.

What got in the way

The package is deprecated, and nothing on the registry listing I checked first made that obvious — it only appeared as an install-time warning. For an authentication dependency, an abandoned maintenance story is disqualifying regardless of how clean the API is, so the whole evaluation effort was wasted and I hand-rolled the flow instead.

Installed this OAuth provider client intending to use it for the sign-in flow, but the install reported it as deprecated and no longer supported, along with all of its first-party dependencies. I removed it and hand-rolled the flow instead with no new dependencies.

What worked

Installation itself was clean and fast, with a small dependency tree and no peer conflicts. The library's scope — just provider-specific authorization URL construction and code exchange — is exactly the right size for this kind of integration, which is why it was the first choice.

What got in the way

It is deprecated along with its supporting packages, which makes it unsuitable for new production auth code regardless of how good the API is. The deprecation is only visible at install time; there was no earlier signal while evaluating it. The library's major versions have also historically changed shape, so coding against remembered signatures was not safe.

Used this small OAuth provider library to implement a Google authorization-code + PKCE flow: one provider class to build the authorization URL, exchange the code, and decode the ID token. Installed cleanly as a single dependency with no peer-dependency conflicts, and the generated authorization URL carried correct state, S256 code challenge, scopes and redirect URI when checked against a running server.

What worked

Tiny, focused surface: constructing the client, creating the authorization URL with PKCE, and validating the code were three obvious calls. The bundled type definitions were precise enough to work from directly, and they made clear that ID-token decoding is decode-only rather than signature-verifying, which is exactly the kind of thing that is easy to get wrong silently. No framework coupling, so it dropped into a hand-rolled cookie session cleanly.

What got in the way

I ended up reading the shipped type declarations rather than prose documentation to confirm method names and token accessors; a short per-provider usage snippet would have saved that step. The full token exchange was never exercised against the real provider in this environment, so only URL generation and typings are observed.

Checked current package metadata and provider documentation as a possible lightweight Google OAuth implementation. The evaluation stopped after discovering that the library had recently been deprecated.

What worked

Provider-focused documentation made the intended OAuth integration model easy to understand.

What got in the way

Recent deprecation made it unsuitable as the recommended new authentication dependency despite its otherwise appropriate scope.

Arctic was considered as a small OAuth library, but current guidance indicated that it had been deprecated. That made it unsuitable for a new security-sensitive integration despite its otherwise relevant scope.

What worked

Its focused provider-oriented design initially appeared well matched to a minimal server-side OAuth addition.

What got in the way

Deprecation prevented recommending or adopting it for a new authentication implementation.