> ## Documentation Index
> Fetch the complete documentation index at: https://docs.readdy.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Readdy Backend Authentication
> Configure email verification, password recovery, custom SMTP, email templates, and Google Sign-In for websites powered by Readdy Backend
Manage your website's authentication directly in Readdy without connecting a separate authentication service.
With Authentication, you can:
* **Add secure account flows**: create sign-up, sign-in, email verification, and password recovery experiences
* **Send branded emails**: connect your own SMTP provider and customize authentication email templates
* **Offer Google Sign-In**: connect a Google OAuth web client to your published website
* **Prepare changes safely**: save configuration as a Draft before activating it for your live website
**Prerequisites:** Connect [Readdy Backend](/features/backend) to your project before configuring Authentication. Readdy Backend and [Supabase](/integrations/supabase) cannot be connected to the same project at the same time.
Activating a new authentication configuration changes how your live website handles sign-up and sign-in. Generate and publish compatible authentication pages before activating the Draft.
## How Authentication Configuration Works
Authentication settings have two states:
| State | What It Means |
| ------ | -------------------------------------------------------------------------------------------------------------- |
| Draft | Your saved changes are available for generation and review but do not change the live authentication behavior. |
| Active | The configuration currently used by your published website. |
Use this order whenever you add or change an authentication method:
1. Save the complete configuration as a Draft.
2. Ask Readdy to generate or update the compatible authentication pages.
3. Review the generated account flows.
4. Publish the compatible website version.
5. Confirm that the compatible version is published.
6. Activate the Draft.
This sequence prevents a new authentication requirement from going live before your website has the pages needed to support it.
## Before You Start
Make sure you have:
* A project connected to **Readdy Backend**
* The published URL for your website
* An account with an email provider and a verified sending domain if you want to send verification or recovery emails
* A [Google Cloud](https://console.cloud.google.com/apis/credentials) project you can manage if you want to offer Google Sign-In
You do not need to prepare callback paths or Google OAuth credentials in advance. The steps below show you how to configure the return URLs and create a Google OAuth client.
Never paste an SMTP password, API key, or Google Client Secret into Chat or your website's frontend code.
## Configure Email Authentication
Open your project, expand **Backend** in the sidebar, and select **Authentication**.
Open **URL Configuration** and enter your published website URL, such as `https://www.example.com`.
Add every allowed authentication return URL on a separate line. A typical generated website includes routes such as:
```text theme={null}
https://www.example.com/auth/callback
https://www.example.com/auth/reset-password
```
Use HTTPS and make sure each URL belongs to your published domain. Click **"Save Draft"**.
Open **SMTP** and enter the host, port, username, password, Sender Email, and Sender Name from your provider.
You typically need the following information from your email provider:
| Field | What to Enter |
| ------------- | ------------------------------------------- |
| SMTP Host | The outgoing mail server from your provider |
| SMTP Port | The secure port required by your provider |
| SMTP Username | The username provided for SMTP access |
| SMTP Password | Your SMTP password or sending API key |
| Sender Email | An address on a verified sending domain |
| Sender Name | The name recipients see in their inbox |
If the page includes sending limits, choose values that are supported by your provider and appropriate for your website. Click **"Save Draft"** when the configuration is complete.
Use the following values after verifying your sending domain in [Resend](https://resend.com). See the [Resend SMTP guide](https://resend.com/docs/send-with-smtp) for provider-specific setup details.
| Field | Value |
| ------------- | ------------------------------------------------------------------ |
| SMTP Host | `smtp.resend.com` |
| SMTP Port | `465` |
| SMTP Username | `resend` |
| SMTP Password | A Resend API key with sending access |
| Sender Email | An address on your verified domain, such as `no-reply@example.com` |
Create a dedicated sending key and restrict it to the required domain when your provider supports that option.
Open **Email Templates** and review the subject, HTML content, and plain-text content for each authentication email.
Keep the instructions short and make the verification code or recovery action easy to find. If you restore a default template, Readdy replaces the current Draft only; the Active template remains unchanged until you activate the new configuration.
Open **Email**, enable email verification, and save the setting as a Draft.
When email verification is active, new users must complete the verification flow before they can finish signing in.
Return to the Editor and ask Readdy to add the account flows your website needs. For example:
```text theme={null}
Add email and password authentication using Readdy Backend. Include sign-up with email verification, sign-in, forgot password, password reset, and authentication callback pages.
```
Make sure the generated website includes routes for registration, verification, sign-in, password recovery, password reset, and authentication callbacks.
Review the generated pages and publish the latest compatible version of your website.
Check that the published domain matches the website URL and allowed return URLs saved in Authentication.
Return to **Authentication** and confirm that you published a compatible authentication flow. Click **"Activate Email Configuration"**, then confirm the activation.
The Draft becomes Active and your published website starts using the new email authentication behavior.
## Configure Google Sign-In
Google Sign-In requires an active website URL and a Google OAuth client created for a web application. You configure the OAuth client in [Google Cloud Console](https://console.cloud.google.com/apis/credentials); see Google's [OAuth 2.0 guide for web applications](https://developers.google.com/identity/protocols/oauth2/web-server#creatingcred) for more details.
In **Authentication**, open **Google**. Copy the **Authorized JavaScript Origin** and the fixed **Auth Callback URL** shown by Readdy.
The origin is based on your saved website URL. The callback URL is generated by Readdy and cannot be changed.
Open [Google Cloud Console](https://console.cloud.google.com), select your project, and configure the OAuth consent screen under **Google Auth Platform** or **APIs & Services**.
Add your app name, support email, audience, contact information, and authorized domain. For a normal sign-in flow, the `openid`, `email`, and `profile` scopes are usually sufficient.
Create an OAuth Client ID and choose **Web application** as the application type.
Add the value copied from Readdy to **Authorized JavaScript origins**, then add the Readdy callback URL to **Authorized redirect URIs**. Save the client and copy its Client ID and Client Secret.
The origin and callback URL must match the Readdy values exactly, including `https://`, the domain, path, and any trailing slash.
Return to **Authentication** → **Google**. Paste the Client ID and Client Secret, then click **"Save Draft"**.
Readdy stores the secret securely. After it is saved, the full secret is not displayed again.
Ask Readdy to add a **Continue with Google** action to your sign-up and sign-in pages. Review the callback behavior and publish the compatible website version.
Return to **Authentication** → **Google**, confirm that the compatible website version is published, and enable Google Sign-In.
Keep advanced options at their defaults unless your OAuth implementation specifically requires them. For example, only skip the nonce check when your identity provider cannot send the expected nonce, and only allow accounts without an email address when your product supports them.
## Tips and Best Practices
Use separate SMTP and Google OAuth credentials for development and production. This makes credentials easier to rotate and prevents a development change from affecting your live website.
Keep the website URL, allowed return URLs, Google JavaScript origin, and Google redirect URI synchronized whenever your published domain changes.
Include a clear way to return to sign-in or request a new code when a verification or recovery link has expired.
## Troubleshooting
**Symptom:** Authentication settings show your new values, but the published website still uses the previous behavior.
**Cause:** The changes are saved as a Draft and have not been activated.
**How to fix:**
1. Generate and publish pages that support the Draft configuration.
2. Return to **Authentication**.
3. Confirm that the compatible version is published.
4. Activate the Draft.
**Symptom:** The email verification control is unavailable or activation cannot continue.
**Cause:** The required website URL or SMTP configuration is incomplete.
**How to fix:**
1. Save a valid published website URL and allowed return URLs.
2. Complete the SMTP configuration with a verified sender.
3. Save the complete configuration as a Draft.
4. Publish compatible authentication pages, then activate the Draft.
**Symptom:** Users do not receive verification or password recovery emails.
**Cause:** The SMTP credentials, secure port, sender domain, or provider limits may be incorrect.
**How to fix:**
1. Confirm the SMTP host, port, username, and password with your provider.
2. Verify the Sender Email domain with your provider.
3. Check the provider's delivery logs and sending limits.
4. Ask the recipient to check spam or junk folders.
**Symptom:** Google displays an `Error 400: redirect_uri_mismatch` message.
**Cause:** The redirect URI in Google Cloud does not exactly match the fixed callback URL shown by Readdy.
**How to fix:** Copy the callback URL from **Authentication** → **Google** again and replace the Authorized redirect URI in your Google OAuth client.
**Symptom:** The Google switch is disabled or users cannot start Google Sign-In.
**Cause:** The URL configuration is not Active, the OAuth credentials are incomplete, or the compatible website version has not been published.
**How to fix:**
1. Activate the website URL configuration.
2. Confirm the Client ID, Client Secret, origin, and callback URL.
3. Publish the website version that includes Google Sign-In.
4. Return to the Google settings and enable the provider.
**Symptom:** Users finish authentication but land on an unexpected page or domain.
**Cause:** The published domain, Site URL, or allowed return URLs do not match.
**How to fix:** Update the Site URL and allowed return URLs to match the live domain, save the changes as a Draft, publish any required page updates, and activate the Draft.
## FAQ
This guide applies to projects using Readdy Backend. If your project uses Supabase, configure authentication in Supabase instead. A project cannot use Readdy Backend and Supabase at the same time.
Yes. Your new values are saved as a Draft first, so the Active configuration continues working until you publish compatible pages and activate the new Draft.
No. Restoring a default template updates the Draft only. The live email changes after you activate that Draft.
Authentication settings and website pages work together. Publishing first ensures your live website has the routes and UI required by the new Active configuration.
## Need Help?
If this guide doesn't resolve your issue, [submit a support ticket](https://readdy.ai/feedback). We're here to help!