= Sign-up, login and invitations
:nav-title: Sign-up Management
:description: Registration, email verification, password reset, login with Google and team invitations, done by the service. You set the app name, the URLs and the emails.
:keywords: user registration, sign-up flow, email verification, password reset, Google login, OAuth, team invitations, authentication for web app
:group: Your users
:order: 50

Registration, email verification, password reset, login with Google and team invitations are the part of every app that is the same every time. The **Sign-up, OAuth & Invitations** plugin does them for your service: your app shows the forms, the service does the rest, and the xref:kit.adoc[Kit] already wires the two together.

image::/assets/docs-images/signup.png[The Sign-up page: the plugin enabled, and the registration settings with the app name and the frontend URLs]

== Turn it on

Open **Sign-up Mgmt** and click **Enable**. The page becomes the configuration form. **Save** applies every change at once; it takes up to a minute to reach every node of the service.

== Tell it about your app

[cols="1,3"]
|===
| Field | What it is for

| **App Name**
| Shown in email subjects and on the login page.

| **Frontend URL**
| Where your app lives, such as `https://app.example.com`. Links in the emails are built from it.

| **Frontend App URL**
| Where a user lands after a link signs them in: after verifying their email, resetting a password, accepting an invitation or coming back from Google. Usually the app's home for signed-in users, such as `https://app.example.com/dashboard`. Without it, users land on the wrong page.
|===

== Choose the features

Each flow has a switch. Off, its endpoints answer `403`.

[cols="1,3"]
|===
| Feature | What the app calls

| **Registration and verification**
| `POST /auth/register`, then the link in the email hits `GET /auth/verify` and `PATCH /auth/activate`.

| **Password reset**
| `POST /auth/forgot-password`, then `PATCH /auth/reset-password` from the link in the email.

| **Team invitations**
| `POST /auth/invite`, `GET /auth/teams`, `POST /auth/switch-team`.

| **Login with Google**
| `GET /auth/oauth/authorize/google`, and the callback the service handles.
|===

The Kit calls these for you: `register()`, `login()`, `forgotPassword()`, `inviteMember()` and the rest. The full flows, with sequence diagrams, are in the link:{restheart-docs}/accounts/auth-flows[accounts documentation].

== Login with Google [[oauth]]

. In https://console.cloud.google.com/[Google Cloud Console], open **APIs & Services** and configure the **OAuth consent screen**.
. Under **Credentials**, create an **OAuth 2.0 Client ID** of type **Web application**.
. Add this redirect URI, with your service's address: `https://f3a9c1.eu-central-1-free-1.restheart.com/auth/oauth/callback/google`.
. Copy the client ID and secret into the **OAuth** section of the Sign-up page, switch **Google OAuth** on, and save.

The secret is stored encrypted. Details and security notes are in link:{restheart-docs}/accounts/google-oauth[OAuth social login].

== The emails [[email-templates]]

Three emails go out on your behalf: **verification** after registration, **password reset**, and **invitation**. Each has a built-in template; paste your own HTML to replace it, **Fill default** to start from ours, **Preview** to see it rendered. The `{{app-name}}`, `{{first-name}}`, `{{verification-url}}`, `{{reset-url}}`, `{{invite-url}}`, `{{inviter-name}}`, `{{team-name}}` and `{{year}}` placeholders are filled when the mail is sent. How many you can send, and how to send from your own address, is on the xref:emails.adoc[Email] page. The template format, with translations, is in link:{restheart-docs}/accounts/email-templates[email templates].

== What users cannot do to themselves [[users-self-service-write-restriction]]

With the plugin on, a user cannot change their own `roles`, teams or verification status through the `/users` API, whatever their permission says. Registration, verification and invitations write those fields through their own endpoints. This is what stops a user who may edit their profile from promoting themselves to `admin`. Exemptions are described in link:{restheart-docs}/accounts/security#users-self-service-write-restriction[accounts security].

== Related pages

* xref:kit.adoc[The Cloud Kit]: the client side of every flow here.
* xref:managing-users.adoc[Users]: the accounts these flows create.
* xref:guards.adoc[Guards]: for instance, block a user who has not accepted the current terms.
* xref:emails.adoc[Email]: quotas and your own sender address.