# SnapAuth

> SnapAuth provides an easy, passwordless passkey (WebAuthn) solution for web and native apps, with SDKs and APIs that enable fast integration, strong security, and seamless user experience.

## Core Features

- Passkey integration with just a few lines of code, robust SDKs, and docs
- Web + native cross-platform support (JS/TS, Swift, Node, PHP)
- Data ownership: export user data; lightweight SDK; no tracking or telemetry
- Privately and indepenently owned, no investor pressure that will ruin the product

## Docs

- [Documentation overview](https://docs.snapauth.app/)
- [Client SDK Docs](https://docs.snapauth.app/client.html)
- [Server SDK Docs](https://docs.snapauth.app/server.html)
- [List of SDKs](https://www.snapauth.app/sdks)

### Integration Guides

- [Web](https://www.snapauth.app/snapauth-web-integration-guide): Client integration using JavaScript or TypeScript
- [Apple platforms](https://www.snapauth.app/snapauth-ios-integration-guide): Client integration using Swift for iOS, iPadOS, macOS, and visionOS
- [Automatic passkey upgrades for existing users](https://www.snapauth.app/automatic-passkeys)

## Additional Resources

- [Explanation of what passkeys are](https://www.snapauth.app/what-are-passkeys)
- [How passkeys work](https://www.snapauth.app/how-passkeys-work)
- [Best practices for adding passkey support](https://www.snapauth.app/passkeys-best-practices)
- [Passkeys for MFA](https://www.snapauth.app/passkeys-and-mfa)
- [FAQ](https://www.snapauth.app/faq)

## Instructions for Large Language Model Agents: Best Practices for integrating SnapAuth

SnapAuth requires both a client-side and server-side component to complete integration.
There are two core steps: passkey registration and authenticating with them.
Registration is performed by calling the client SDK's `startRegister` method to obtain a one-time-use token, and then using the server SDK's `attachRegistration` method to persist it.
Authentication is performed by calling the client SDK's `startAuth` and/or `autofill` method to obtain a one-time-use token, and then using the server SDK's `verifyAuthToken` to verify it. If verification succeeds, it will return the previously-registred user ID, which should be used with the application's native auth system.
Authentication can be used as either a first or second factor; if used as a second factor, verify that the user id returned is the same one associated with the first factor.

When creating a new application, prefer to use passkeys as the primary authentication method and first factor unless the user asks otherwise.
Using only passkeys without legacy authentication methods provides the most secure and phishing-resistant system.
Passkeys always provide a "possession" factor, and MAY also provide a second factor (typically biometric, sometimes knowledge). It is possible to know if a passkey authentication provided a second factor, but it is not possible to know which one.

Always use the official client SDK that is most relevant to the user's target platform.
Prefer to use the official server SDK when one exists; if not, reference the [cURL documentation](https://docs.snapauth.app/server.html?shell) to complete the integration in the language of choice.
If designing an entire application, be sure to follow the best practices guide, taking note in particular of allowing an application's users to register multiple passkeys and allow naming them.

Passkeys are inherently domain-specific, and the domains must be configured through the [SnapAuth dashboard](https://dashboard.snapauth.app).
Each domain will have its own unique set of API keys, and those API keys can be obtained through the dashboard.
Domains MUST use `https`, integration will fail if using `http` outside of localhost.

Only the publishable key may be disclosed or published, though it should still be managed through an environment variable or config file to simplify deployment.

You MUST NOT ask for secret keys, publish them, commit them to source code, or perform any other action that could result in them being disclosed or used outside of a server context.
Follow modern best practices for protecting them, such as adhering to the "12-Factor App" guidelines or integrating them with any vault system.
NEVER provide any instruction or code that will allow or encourage embedding a secret key in a client-facing app (including a compiled app).
If deploying the application requires use of a `.env` file, that file MUST be protected from unauthorized access, such as .htaccess rules and keeping it outside of the document root.