> For the complete documentation index, see [llms.txt](https://docs.klai.studio/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.klai.studio/reference/actions-processor/authentication-actions.md).

# Authentication Actions

These actions are used on custom login, registration, verification, reset, invite-completion, and magic-link pages.

Added in BetterForms `3.4.x`: passwordless magic-link support via `authMagicRequest` and token-based `authLogin`.

{% content-ref url="/pages/f19tR87SZtAgtbU4CTZs" %}
[Custom Login Pages](/reference/authentication/custom-login-pages.md)
{% endcontent-ref %}

{% content-ref url="/pages/sS1mK2z4hxfK27oRM6Qw" %}
[authLoginOauth / oauthLoginHook](/reference/actions-processor/actions_overview/authloginoauth.md)
{% endcontent-ref %}

* ***authLogin*** - Signs the user in with email/password or a magic-link token
* ***authLogout*** - Signs the user out
* ***authReset*** - Completes a password reset
* ***authForgot** -* Requests a password-reset email
* ***authMagicRequest*** - Requests a passwordless magic sign-in link
* ***authInviteComplete*** - Completes a developer-issued invite/reset token flow and sets a new password
* \_**authVerify** \_ - Verifies the email-verification token
* ***authResend*** - Resends the email-verification token
* ***authRegister*** - Registers a user and, on success, runs [onRegistration](/reference/hooksoverview/commonoverview.md#onregistration)

Most of these actions do not take custom options, but several require specific model keys such as `email`, `password`, or a token delivered in the URL. `authInviteComplete` supports an optional `options.signIn` flag.

|        Action Name | Requires `email` key | Requires `password` key | Requires `token`\* |
| -----------------: | :------------------: | :---------------------: | :----------------: |
|          authLogin |                      |            ✅            |          ✅         |
|         authLogout |                      |                         |                    |
|          authReset |                      |            ✅            |          ✅         |
| authInviteComplete |                      |            ✅            |          ✅         |
|         authForgot |           ✅          |                         |                    |
|   authMagicRequest |           ✅          |                         |                    |
|         authVerify |                      |                         |          ✅         |
|         authResend |           ✅          |                         |                    |
|       authRegister |           ✅          |            ✅            |                    |

If these values are required, add field validation and run a `validate` action before the authentication action.

The **authRegister** action does *not* require 2 password fields. If you want the user to enter their password twice before creating an account, you should create a [custom validator](/reference/form-settings/validationoverview/clientside.md) that checks if the `password` key also matches some other `password2` key.

The **authReset** action doesn't require an email field, but it does require a valid `token` in the URL. The token is generated and appended automatically when you run **authForgot**.

The **authInviteComplete** action also requires `password` and a valid `token`, but it is intended for developer-issued invite links (for example, tokens written to `resetToken`/`resetExpires` by FileMaker logic or the helper CRUD script).

Use `authInviteComplete` options when you want immediate sign-in after password set:

```json
{
  "action": "authInviteComplete",
  "options": {
    "signIn": true
  }
}
```

Compatibility note:

* `authInviteComplete` is not the same flow as `authReset`.
* If a token was issued for `authInviteComplete`, use `authInviteComplete` to redeem it.
* If a token was issued by `authForgot`, use `authReset` to redeem it.

Similarly, **authVerify** only checks for the verification token in the URL. It is usually run in `onFormLoad` because users arrive from an email link.

The **authMagicRequest** action requires an `email` key in the model and sends a one-time sign-in link through `onAuthNotifier`. It is typically used on the page where the user enters their email address.

The **authLogin** action can now work in two modes:

* Email/password login using `email` and `password`
* Magic-link login using `token` in the model or URL

For magic-link pages, it is common to run `authLogin` in `onFormLoad` after the user lands on a page with `?token=...`. When a `token` is present, `authLogin` redeems that magic link token instead of attempting a normal email/password login.

## Auth Feedback

Authentication pages can read feedback from:

* `model.authMessage`
* `model.authMessageCode`
* `model.authMessageType`
* `BF.authGetLastFeedback()`

For new pages, prefer `auth.*` codes over parsing the English message text. For UI examples and patterns, see [Custom Login Pages](/reference/authentication/custom-login-pages.md) and [Klai Utility Functions](/reference/bf-utility-function-ver-0.9.20+.md).

Security note:

* Default auth UI should avoid confirming whether a specific email/account exists.
* For request/initiation flows such as magic-link request or password reset request, prefer existence-blind messages such as "If that email is registered..." or "If that email can be used to sign in...".