Go2Auth Security Model

Go2Auth is designed as a minimal passwordless authentication service. The architecture intentionally avoids unnecessary dependencies and keeps the authentication workflow limited to the components required to authenticate a user and establish a session.

1. Security Overview

Go2Auth does not require an SDK, JWT library, or third-party authentication provider. Applications communicate with Go2Auth through standard HTTPS requests and signed webhooks.

The service is designed around a simple principle: keep authentication operations and stored data to the minimum required for the service to function.

Minimal Integration Authentication is initiated through a standard HTTPS link without installing an authentication SDK.

↓

Minimal Data Storage Email addresses are not stored as plaintext in the database.

↓

Server-Side Verification Authentication events are delivered to the application through signed webhook requests.

↓

Session-Based Authentication Authenticated users are handled through a secure, domain-specific HTTP-only session cookie.

2. Authentication

Go2Auth uses passwordless email authentication based on magic links. Users do not create or transmit passwords through the authentication workflow.

Authentication requests are subject to rate limiting to reduce automated abuse, excessive authentication requests, and unwanted email activity.

Magic links are intended for one-time authentication and are used only as part of the authentication process. Once authentication has been established, the application can rely on the resulting session rather than repeatedly requesting a new magic link.

3. Data Handling

Go2Auth is designed to minimize the amount of personal data retained by the authentication service.

Email addresses are not stored as plaintext in the database. Authentication identifiers are processed using one-way cryptographic salted hashing.

The plaintext email address is used during the initial authentication operation and is transmitted to the configured application through the authentication webhook so that the application can identify the user.

After authentication, Go2Auth operates as an authentication transport and session layer rather than requiring permanent plaintext email storage for subsequent sessions.

4. Sessions

Following successful authentication, Go2Auth establishes a domain-specific HTTP-only session cookie.

The cookie is handled by the browser and is not exposed to client-side JavaScript. This reduces the risk of session credentials being directly accessed by scripts running in the page.

Subsequent authentication requests can use the established session instead of requiring the user to enter their email address and request a new magic link each time.

5. Webhook Security

Authentication and logout events are delivered to the configured application through HTTPS POST requests.

Each webhook request includes an X-Signature header generated using HMAC-SHA256 and the application's private webhook secret.

The receiving application should calculate the expected signature from the original request body and compare it with the supplied signature before processing the webhook payload.

The webhook secret is private application configuration and should be stored securely, such as in an environment variable. It should never be exposed in client-side code or committed to source control.

This mechanism allows the receiving application to verify that a webhook payload was generated using the application's configured secret before processing the authentication event.

For the complete webhook payload structure and integration details, see the Go2Auth Developer Documentation.

6. Infrastructure

Go2Auth authentication traffic is handled through HTTPS. Communication between applications and Go2Auth is therefore encrypted in transit.

The service is intentionally designed with a small integration surface: no client SDK, no JWT dependency, and no external authentication provider are required to establish the authentication flow.

The security model is based on minimizing the number of components involved in authentication and limiting the data retained by the service.

7. Security Disclosure

If you believe you have identified a security vulnerability affecting Go2Auth, please report it responsibly through the contact information provided in the Go2Auth Legal Notice.

Please do not publicly disclose an unpatched vulnerability before allowing reasonable time for investigation and remediation.

This document describes the current Go2Auth security model and may be updated when relevant security mechanisms or infrastructure change.