Blocks
5 blocks for an authentication page
An authentication page does not have to look good: it has to let the user in on the first attempt. Five categories, the states blocks forget and the real catalogue counts.
Key points
- Pick the login block by the states it shows: error, waiting, disabled.
- Thirty-four login blocks, but few cover forgotten password and email verification.
- An error that shifts the layout costs more than an inelegant label.
An authentication page has to let the user in on the first attempt, not prove the team can center a form. The catalogue indexes 34 login blocks, 19 signup, 32 form, 4 banner and 45 footer, read on 2026-11-01 from the category pages.
The method is the same for every number on this page: a count of records published per category, not an estimate. If a block does not appear in the table, it does not exist in the catalogue, and that is already useful news before Figma opens.
What the page has to do
The sign-in page is the one place where a user who has already paid can be locked out. It has to accept a password manager without breaking, say why an attempt failed without revealing whether the email exists, and stay readable when an error message appears. The rest, from the big logo to the background photo, is optional and often harmful.
- Autofill that fills email and password without manual DOM access.
- An error that does not move the submit button.
- A visible link to password reset and email verification.
- A clear exit for a wrong provider, such as “I use another email”.
The order of the blocks
| Section | Role on the page | Blocks available |
|---|---|---|
| login | let existing accounts in | 34 |
| signup | collect a minimal registration | 19 |
| form | handle reset and verification | 32 |
| banner | explain an alternative sign-in | 4 |
| footer | give support and legal notes | 45 |
Login first, signup after, not the other way round. Whoever lands here almost always has an account and is hunting for the password field: a registration form on top pushes the useful field below the fold. Form and banner sit under the login as reset support, and the footer closes with privacy and terms.
The blocks to start from
The tables show the block, the registry, the file count and the declared category. The file count hints at the states: a 9-file login usually separates field, button and messages, a 3-file one keeps everything in a single component and needs work to add the error. Read the category with care: a “topbar” block lands in the login table only because the registry classifies it that way.
Login blocks
| Block | Registry | File | Category |
|---|---|---|---|
| Topbar 03 - Login Action Topbar | Shadcn Space | 9 | topbar |
| Login 07 | Shadcn UI Blocks | 5 | login |
Signup blocks
Form blocks
| Block | Registry | File | Category |
|---|---|---|---|
| Organization Form - 1 | shadcn-ui-clerk-components | 3 | organization |
| Profile Form - 1 | shadcn-ui-clerk-components | 3 | profile |
Banner blocks
What breaks in production
Nearly every fault on this page is about state, not style. The password field has no declared type and the manager does not fill it. The error message appears under the form and pushes the button off a 360 px phone. The OTP code has six boxes that reject paste.
- Missing autocomplete: email, current-password and new-password.
- Waiting button without aria-busy: the screen reader announces nothing.
- A generic “invalid credentials” even when the email is wrong.
- A post-login redirect that drops the return parameter.
curl "https://ui.eneawork.it/api/blocks/category/login?limit=10"The response lists ten login blocks with source and files: use it to see how many keep a separate file for the error message. If your candidate has a single file, adding the error state means rewriting the component, not only the copy.
A limit to declare
None of the 34 login blocks ships session logic: they are forms, not sign-in systems. Email verification, token rotation and lockout after five attempts stay to be written or wired to the provider. Anyone looking for a “secure” block is looking for something the catalogue does not sell.
In the catalogue: login form, components and blocks with preview. The guides: accessibility checklist, measured contrast and Radix, Base UI and React Aria.
Frequently asked questions
Why does the login page have 34 blocks and signup only 19?
Because registries publish more sign-in screens than registration ones: login is the screen every product must have, while registration often runs through an invite or an external flow. The gap sits in the catalogue, not in demand.
Should the message differ for an unknown email and a wrong password?
No. An identical message avoids turning the form into an address checker. You lose a little clarity and gain the fact that nobody can test whether an email is registered by trying common passwords.
Can a generic form block replace a login block?
Only when it accepts fields with the right type and autocomplete. A generic form starts from neutral labels and a submit without a waiting state: adapting it costs more than taking a 9-file login that already ships messages and field spacing.
How do I handle the OTP code on mobile?
A single field with numeric inputmode and one-time-code autocomplete beats six separate boxes. Boxes block paste, split the screen reader announcement and need JavaScript to move focus on every digit.
Is the banner under the login mandatory?
No, and with 4 banner blocks in the catalogue it is also the thinnest category on the page. Use it for one operational notice, such as planned maintenance; with nothing to say, remove the block instead of filling it with a promotion.