# How to add Google and Discord login to an AI website

Canonical: https://uvilno.com/guides/how-to-add-google-and-discord-login-to-ai-websites
Updated: 2026-10-27

Plan hosted app sign-in, private records, account states, and export-origin setup. Keep OAuth on trusted pages and generated code inside its preview boundary.

Written by the Uvilno team. Examples illustrate workflows; confirm service availability before launch.

## Separate your builder account from your app's visitors

Draw a simple account map in your project notes: the owner edits the app, the visitor owns personal records, and a connected provider grants a specific permission. Include the intended sign-out behavior for each. This makes it easier to detect a misleading label, such as a visitor profile appearing to manage the owner's builder subscription, before that confusion becomes part of the generated interface.

Signing in to Uvilno lets you own and edit a project. Signing in to a generated application lets a visitor use that application's supported private features. Connecting a provider for repository or payment access is another permission relationship. These journeys can involve familiar provider names while serving different purposes. Define which identity you are adding before asking the builder for a login button; otherwise a polished account screen can imply access that the service does not actually provide.

Start with the visitor's reason to sign in. A private reading journal needs personal records; a public architecture portfolio probably does not. Avoid requiring an account for content that should be openly readable. List the actions that become available after authentication and what should remain public. That boundary guides the page structure, error handling, and authorization checks, and it keeps login from becoming an unnecessary obstacle in the visitor's journey.

## Understand the hosted authentication boundary

Uvilno's supported managed app authentication is a hosted service, not a new customer-owned identity database provisioned inside the static export. The generated frontend uses the trusted service for sign-in and authorized requests. Provider credentials do not belong in the page, the prompt, or the exported archive. A browser-only website cannot keep a secret simply by hiding its text from the interface; downloaded scripts remain inspectable by visitors.

Generated code also remains isolated from the main application origin. A trusted top-level consent or provider popup handles the sensitive authorization journey, then the application receives a scoped result through the supported runtime. This is why you should not solve a login problem by granting generated content broad same-origin privileges. Isolation and hosted consent are parts of the architecture. The goal is a working visitor journey that respects those boundaries, not an embedded imitation of a provider's login screen.

- [MDN: iframe sandbox behavior](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe)

## Enable the supported service and describe the account screens

Select the managed app-login connection in the composer's app connections for the next explicit build. If you request private records, the product can require that login dependency as well. Selection prepares the next submission; it does not replace the current saved version or silently create a finished account system. Describe the needed screens and states in the brief, then send the request. Check the resulting application rather than assuming that a selected chip proves the full flow is ready.

Request a dedicated login view, the available provider options, a profile, and sign-out where they serve the app. Include email/password registration and recovery only when supported by the selected service. The interface should show provider availability honestly. A Google or Discord button must start a real supported authorization path; an unavailable provider should not appear as a decorative action. Distinguish editable profile fields from account identity information that comes from the trusted service.

Example brief:

Keep the introduction public. Require app sign-in before opening My Books. Offer the providers actually supported by the hosted service, including Google and Discord when configured. After sign-in, show the visitor's own books and a profile. Preserve an unsent note if authentication expires and explain how to retry.

## Keep OAuth consent on the provider's trusted journey

OAuth lets an application request a limited authorization from a provider through a defined flow. Google documents server-side authorization, redirect handling, and protecting credentials. Discord documents its own scopes and authorization process. The exact provider setup belongs to the trusted integration. A generated site should not ask visitors to type their Google or Discord password into a custom form that imitates those providers, and it should not receive a provider client secret.

During testing, inspect the real consent page: the intended provider, application identity, and requested permissions should make sense for the task. Basic sign-in should not be described as permission to send Discord messages or read unrelated Google data. Cancellation must return to a usable signed-out state. If the popup is blocked, show an understandable recovery action. Closing the popup is not proof of consent; the application should wait for the trusted service's result.

- [Google OAuth for web-server applications](https://developers.google.com/identity/protocols/oauth2/web-server)
- [Discord OAuth2 documentation](https://docs.discord.com/developers/topics/oauth2)

## Make private records private on the server

Authentication answers who a visitor is. Authorization determines which records that visitor can read or change. Hiding a page or disabling a button in the browser does not enforce record ownership. For a personal journal, the trusted service must bind requests to the app, project, and signed-in visitor. A second account should not be able to retrieve the first account's records by changing a visible identifier or reopening a URL.

Describe the ownership model explicitly. Uvilno's typed managed collections support declared fields, references, private visitor-owned records and deliberately public reading where configured; they do not imply arbitrary server provisioning or an enterprise permission hierarchy. If you need shared workspaces, team roles or organization-wide administration, treat those as separate requirements and confirm the actual authorization model before building the interface. The Guest/Member/Admin preview selector changes presentation only. A login screen or an admin-looking drawer alone does not establish that the rest of an application's data model is safe or complete.

Test identity and access separately

| Check | Expected behavior | Why it matters |
| --- | --- | --- |
| Signed-out visitor | Private data is unavailable | A hidden menu alone is insufficient. |
| Account A saves a book | A can read it after reload | The request used real persistence. |
| Account B opens the app | B cannot read A's book | Record ownership is enforced. |
| Sign out | Private view closes or clears safely | Old UI must not imply an active session. |

## Design the states around sign-in, not just the happy path

Account features introduce waiting and failure into otherwise simple pages. Show a loading state while the service resolves the session so private content does not flash before authorization is known. Give an empty account a useful next step. Keep validation messages near the relevant field and preserve safe input after a recoverable failure. A disabled submit button needs an understandable reason; a permanent spinner gives the visitor no way forward.

Test session expiration, provider cancellation, password recovery where supported, and sign-out followed by the browser's Back action. Do not leave an old account name or private record on screen in a way that suggests access continues. For asynchronous data, wait for the real result before rendering success. If the service is unavailable, explain that the action failed and provide a retry; do not substitute fictional private records or a fake successful save.

- The signed-out view explains why login is needed.
- Session loading has an explicit bounded state.
- Provider cancellation preserves a usable page.
- Private records render only after authorized retrieval.
- Sign-out and expiration clear or protect private UI.

## Register and test the deployed origin after export

A working preview does not automatically authorize a different production domain. Uvilno's managed app service accepts its supported isolated preview context or an owner-registered deployed origin. Register the external app origin through the available managed sign-in configuration before testing the exported frontend. Use the exact intended scheme and hostname. A temporary host URL, a www hostname, and a root domain can represent different origins even when they display similar pages.

Run the whole journey from the actual deployed address: open a public page, start sign-in, complete provider consent, create a private record, reload, edit it, and sign out. Repeat with a second test account. Keep in mind that the hosted authentication and records remain dependencies after source export. If your goal is to operate a separate identity system, plan an intentional migration with appropriate development rather than assuming the downloaded frontend contains the service and visitor database.

## Troubleshoot the first boundary that fails

If no provider window opens, confirm the button starts from a real user action and check popup permission. If consent returns an error, check the supported connection, provider configuration, and intended origin. If sign-in succeeds but records fail, investigate authorization and service availability rather than rebuilding the login layout. If only the exported site fails, check deployed-origin registration before changing generated code. Keep the preview sandbox intact throughout the investigation.

Report safe reproduction details: which view was open, which provider was selected, whether you were in preview or on a deployed host, and the visible error. Never include raw session credentials, authorization codes, or private visitor data in a prompt or public issue. Once corrected, repeat the two-account access test and the sign-out test. Authentication is complete only when the surrounding private data journey works predictably and the interface explains failures honestly.

## Common questions

### Does app login create a separate backend in my export?

No. Supported managed authentication and personal records remain Uvilno-hosted services. The export contains the frontend and its supported runtime integration, not a separately provisioned identity database.

### Why does sign-in use a popup?

Generated code runs in an isolated preview. A trusted top-level consent or provider window can handle authorization without granting generated content broad privileges on the application origin.

### Why does login fail only after deployment?

Check that the external app origin is registered through the supported managed sign-in configuration. Preview authorization does not automatically authorize another hostname.