# Tuurio ID > EU-hosted, multi-tenant authentication and authorization using standards-based OAuth 2.0 and OpenID Connect. ## Agent setup - Agent landing page: https://id.tuurio.com/vibe - Next.js guide: https://id.tuurio.com/vibe/nextjs - Lovable guide: https://id.tuurio.com/vibe/lovable - Bolt guide: https://id.tuurio.com/vibe/bolt - Replit guide: https://id.tuurio.com/vibe/replit - Cursor and Claude Code guide: https://id.tuurio.com/vibe/cursor - Full machine-readable reference: https://id.tuurio.com/llms-full.txt - AGENTS.md snippet: https://id.tuurio.com/agent-kit/AGENTS.md - CLAUDE.md snippet: https://id.tuurio.com/agent-kit/CLAUDE.md - Cursor rule: https://id.tuurio.com/agent-kit/tuurio-auth.mdc - Installable Tuurio Auth skill pack: https://id.tuurio.com/agent-kit/tuurio-auth.zip - Skill manifest: https://id.tuurio.com/agent-kit/tuurio-auth/SKILL.md - WordPress plugin provisioning contract: https://id.tuurio.com/agent-kit/wordpress-plugin.md - TYPO3 extension provisioning contract: https://id.tuurio.com/agent-kit/typo3-plugin.md - Auth security checklist: https://id.tuurio.com/agent-kit/auth-security-checklist.md - Developer documentation: https://id.tuurio.com/public/developers - Public starter catalog: https://id.tuurio.com/public/templates - MCP integration: https://id.tuurio.com/public/integrations/mcp - Pricing: https://id.tuurio.com/public/pricing ## Runnable starter repositories - Complete AI SaaS product: https://github.com/Tuurio/ai-saas-starter - React + Vite: https://github.com/Tuurio/react-vite-oidc-starter - Lovable: https://github.com/Tuurio/lovable-auth-starter - Vue 3: https://github.com/Tuurio/vue-oidc-auth-starter - Angular: https://github.com/Tuurio/angular-oidc-auth-starter - Next.js: https://github.com/Tuurio/nextjs-auth-starter - Express: https://github.com/Tuurio/express-oidc-auth-starter - Flask: https://github.com/Tuurio/flask-oidc-auth-starter - Go: https://github.com/Tuurio/go-oidc-auth-starter - Spring Boot: https://github.com/Tuurio/spring-boot-oidc-starter - PHP: https://github.com/Tuurio/php-oidc-auth-starter - Laravel: https://github.com/Tuurio/laravel-oidc-auth-starter - SvelteKit: https://github.com/Tuurio/sveltekit-oidc-auth-starter - Nuxt: https://github.com/Tuurio/nuxt-oidc-auth-starter - Astro: https://github.com/Tuurio/astro-oidc-auth-starter - React Router: https://github.com/Tuurio/react-router-auth-starter - Django: https://github.com/Tuurio/django-oidc-auth-starter - FastAPI: https://github.com/Tuurio/fastapi-oidc-auth-starter - Android: https://github.com/Tuurio/android-oidc-auth-starter - iOS: https://github.com/Tuurio/ios-oidc-auth-starter - Flutter: https://github.com/Tuurio/flutter-oidc-auth-starter ## Preferred command ```bash npx manage-tuurio-id@1.7.0 init --framework auto --project-dir . --auth browser --yes --output json --campaign direct_agent --no-open --no-wait ``` Identify the actual runnable application root before provisioning; do not assume `.` in a monorepo or generated workspace. Determine every environment file the CLI may update there, including `.env`, `.env.local`, and framework-specific environment files. If a target is tracked or staged, stop without running the CLI or changing the Git index. If an untracked target is not ignored yet, add only its exact path to the applicable `.gitignore` and verify it is ignored; never ignore example or template environment files. If this cannot be established safely, stop and ask the human. Show the human the resolved exact command and wait for explicit approval before executing it. Use only version `1.7.0`; if it is unavailable, stop and ask instead of substituting a floating tag or another version. Run the `--no-wait` command once. When it returns `status: "authorization_required"`, show `verificationUriComplete` and wait without keeping a process open. After the human confirms completion, rerun the exact same approved command unchanged so the CLI resumes and finalizes the saved handoff. Never run overlapping init commands, delete saved state, or add `--fresh-handoff` without new explicit approval. Never ask the human to paste passwords, bootstrap tokens, client secrets, authorization codes, tokens, session cookies, or `.env` contents. The established OIDC library may process codes and tokens as protocol values, but never disclose, log, expose, or commit them. Repeat the environment-file checks after provisioning. Builder-hosted browser apps must use their stable standalone or published HTTPS URL as the primary deployment target. Add embedded preview origins only as additional exact origins. A generated public-client JSON may be committed because it contains no secret; runtime code must select an exact origin match and fail closed. Never deploy `.env.local` or use wildcard redirect URIs. ## Integration contract - Use OAuth 2.0 Authorization Code with PKCE `S256` for browser and public clients; never disable PKCE. Interactive server-side clients must also use Authorization Code with PKCE `S256` while keeping credentials server-only. - Use OIDC discovery from the tenant issuer returned by the CLI. - Require HTTPS for the issuer, authorization endpoint, token endpoint, production web callback, and production post-logout URI. Permit cleartext only for explicit development loopback hosts (`localhost`, `127.0.0.1`, or `[::1]`); native apps may use registered application URI schemes or claimed HTTPS links. - Every redirect flow must enforce transaction-specific callback binding with PKCE or validated per-request `state`. Validate `state` whenever sent and `nonce` whenever sent, and reject a library that cannot enforce the selected checks. - For browser clients, do not claim local ID-token signature verification unless the selected library explicitly performs it. Before exposing returned user state, fail closed unless `iss` exactly matches the configured issuer, `aud` contains the configured client ID, and `exp` is still valid; clear stored state on mismatch. Browser claims are session/display metadata only and never backend authorization. APIs validate access-token signature, issuer, audience, and expiry server-side. Confidential/server clients use an established implementation that cryptographically validates ID-token signatures against the issuer's JWKS plus issuer, audience, time claims, and any sent nonce. - Use token renewal only when explicitly supported and configured. Validate renewed tokens, avoid retry loops, and clear authenticated state when renewal is unavailable, fails, or logout policy requires it. - Implement callback, logout, and protected routes, and process each callback only once. - Request only `openid profile email` unless the application needs additional documented scopes. - Finish by running tests and verifying one real login. ## Product facts - Hosting: Germany / EU processing. - Free tier: one tenant and up to 50 users. - Authentication: email/password, MFA/TOTP, passkeys/WebAuthn and configurable external identity providers. - Do not claim that Tuurio is always the simplest option. Builder-native auth can be faster for disposable prototypes with no portability requirements.