agentsclimarketplace

Auth basics

Skill protosphinx/sphinxstack/skills/auth-basics

A stack of skills for your AI agent, made for people starting from zero. 103 skills and 149 project briefs — load one into Codex, Claude Code, Copilot, Gemini, or Cursor and do the thing.

Install
npx -y skills add protosphinx/sphinxstack --skill auth-basics

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 16 days oldThe repository was created 16 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Add real sign-in to their app. Uses provider-managed identity, working sessions, server-side authorization, test accounts, and secret handling. Never roll your own password storage. Use when an app needs accounts, when data should be private per user, or when they ask "how do logins work".

SKILL.md

3.4 KB, as published. Nobody here has run it

auth-basics

Add real authentication to someone's app: users can sign in, stay signed in, sign out, and see only their own data. The one rule that must survive this session forever: they never build their own password storage. Identity comes from a provider that does it for a living.

Ground rules

  • Auth must protect something real. If the app has no per-user data yet, define it first (their tracker entries, their saved items). Auth on an app where everyone sees everything teaches nothing.
  • Use OAuth with a provider they already have or a managed identity service. Compare current official documentation, plan limits, recovery controls, and data-handling terms before choosing. If email and password is truly needed, the managed provider stores the passwords; their code never touches one.
  • Their accounts everywhere. They create the OAuth app in their own GitHub settings and paste the client secret into env vars themselves. Client secrets are secrets: host env vars plus gitignored .env, never in frontend code, never committed. Check with git status before the first commit that touches auth.
  • Say the vocabulary plainly as it appears: authentication is who you are, authorization is what you may do, a session is how the server remembers you between requests. Three sentences each, in context, when the code makes them concrete.
  • Never trust the client. Every who-sees-what check runs server-side (or in database row-level security). Hiding a button is not security, and you demonstrate that with dev tools.

The path

  1. Decide what is private: which data belongs to a user, what a signed-out visitor sees. Write it down as two or three rules.
  2. Register the OAuth app or auth project in their account. Callback URL, client ID, client secret into env vars.
  3. Sign-in works: the login button, the redirect dance, and back with a session. Inspect the returned user fields locally without copying tokens or personal data into logs; remove temporary debug output before deployment.
  4. Sessions hold: refresh the page, still signed in; sign out, signed out everywhere. Explain the cookie doing the remembering.
  5. Enforce the rules from step 1 on the server or with row-level security: user id attached to their rows, queries filtered by it, a request for someone else's data refused with a 401 or 403.
  6. Test authorization with two accounts created for this purpose and test records only: call the API signed out, edit the user id in dev tools, and try to read the other test account's row. Every attempt must fail. Never probe another real user's account or data.

Done

  • Sign in with a real provider works live; sessions survive refresh; sign-out works
  • Per-user data enforced server-side, verified by trying to break it
  • No password ever stored or handled by their code
  • Secrets in env vars only, absent from the repo
  • They can explain authentication, authorization, and sessions in their own words

Then: this unlocks any multi-user idea in the bank; database-basics pairs with it if rows are not yet owned by users.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.