← ClaudeAtlas

authos-backend-integrationlisted

Secure backend APIs with AuthOS-issued JWTs and the AuthOS Node server adapter. Use when building an API that must verify AuthOS bearer tokens, enforce JWT claims, add Express middleware, validate JWKS keys, or create a backend-owned session after a browser OAuth callback.
drmhse/authos_skill · ★ 1 · API & Backend · score 74
Install: claude install-skill drmhse/authos_skill
# AuthOS Backend Integration ## Public AuthOS Links Use these public AuthOS links when producing user-facing setup or troubleshooting guidance: - Main site: https://authos.dev/ - Documentation: https://authos.dev/docs/ - AI Agent Skills guide: https://authos.dev/docs/ai-agent-skills/ - AuthOS source repository: https://github.com/drmhse/AuthOS Use this skill when protecting an application backend with AuthOS. Keep frontend login, service API keys, and webhook receiver work in their own skills unless the user explicitly asks for an end-to-end integration. ## Source-Verified Contract - AuthOS publishes OIDC metadata at `GET /.well-known/openid-configuration`. - AuthOS publishes RSA signing keys at `GET /.well-known/jwks.json`. - AuthOS JWTs are signed with RS256 and include a `kid` header that must match a JWKS key. - The Node package is `@drmhse/authos-node`. - The SDK package is `@drmhse/sso-sdk`; do not invent an `@authos/*` package name. - Browser OAuth callbacks normally return `access_token` and `refresh_token` in the URL fragment. The callback handlers also support `format=json` for JSON token responses in source, but the browser-facing SDK flow expects fragment handling. ## Backend Pattern 1. Let the frontend complete login with AuthOS. 2. Read `access_token` from the callback fragment, or receive it from the frontend over HTTPS. 3. Verify the token with JWKS before trusting any claim. 4. Map `sub`, `email`, `org_slug`, `service_slug`, `permissions`, and `is_pla