# Flutter Login: Authentication Screens for Flutter Apps > Flutter Login provides a configurable login, signup, confirmation, and password recovery widget for Flutter applications. It handles interface state and callbacks, while the host app remains responsible for authentication, validation, navigation, and security decisions. **NearHuscarl/flutter_login** — Provides login screen with login/signup functionalities to help speed up development - Repository: https://github.com/NearHuscarl/flutter_login - Stars: 1,590 · Forks: 807 - Language: Dart - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/nearhuscarl-flutter-login ## Why Flutter Login Exists in a Flutter Application Flutter Login addresses the presentation layer of account access. It supplies a widget for login and signup, plus related states for confirming a signup, recovering a password, confirming recovery, and requesting another confirmation code. The intended audience is Flutter developers who would otherwise rebuild several authentication forms and coordinate their labels, keyboard behavior, validation, and mode transitions for each application. The package does not present itself as an authentication service. Its callbacks hand the submitted data back to the application, and properties such as `userValidator` and `passwordValidator` control validation within the form. This division is important: Flutter Login can construct the screen and collect values, but it cannot by itself establish a trusted session, verify credentials against a server, or decide whether an account is allowed to sign in. Those operations must be implemented by the application that owns the widget. This makes the package most relevant to consumer-facing Flutter apps that need several authentication modes behind one interface. It is less suitable when the required design is fixed by an identity provider and cannot accept a custom Flutter widget, or when the project has no plan for processing the data returned through its callbacks. ## Flutter Login Modes and Callback Data Flow The central interface is the `FlutterLogin` widget. Its behavior is assembled from callbacks and mode-specific properties. In login mode, submission invokes `onLogin`. Signup submission invokes `onSignup` and supplies a `SignupData` object containing the name and password. When `additionalSignUpFields` is configured, the callback also receives those entered values in a `Map`. Signup confirmation is conditional rather than unconditional. The README states that `onConfirmSignup` enables confirmation by the user, while `confirmSignupRequired` can decide at runtime whether confirmation is required. A related `onResendCode` callback is required only when signup confirmation is provided. This structure allows an application to collect a confirmation code without forcing every signup flow through that state. Password recovery follows the same callback-driven pattern. `onRecoverPassword` handles the initial recovery submission. If recovery requires a confirmation code and a new password, `onConfirmRecover` handles that operation. `onSubmitAnimationCompleted` provides a separate point for route transition logic after the submit animation finishes. The animation is part of the visible package experience, but authentication state transitions remain application code. ## Installing Flutter Login Through pub.dev Flutter Login is distributed through pub.dev, and the README directs users to the package's installation tab rather than giving repository-specific installation commands. The first implementation step is therefore to open the linked `pub.dev/packages/flutter_login` installation instructions, add the package through the normal Flutter dependency workflow available in that project, and review the package documentation for the current Flutter and Dart requirements. After installation, a real first use begins by placing `FlutterLogin` in the application screen that should own authentication. Connect `onLogin` to the application's login operation and decide how its submitted data leads to a loading state, error display, or route transition. Then provide or intentionally omit the signup, confirmation, and recovery callbacks according to the account flow the product requires. The repository includes an `example/` directory and a `demo/` directory, so those are the available places to inspect for concrete composition. No installation command or configuration file is reproduced here because the README does not contain exact commands, dependency versions, or environment settings. ## Validation, Labels, and Custom Signup Fields Validation is configurable at the field level. The user field defaults to email validation when `userType` is not specified, and applications can replace that behavior with `userValidator`. The password field has a separate `passwordValidator`. Both validators use Flutter's `FormFieldValidator` contract: they return an error string to display on failure or `null` when validation succeeds. This gives the host application control over account-name rules and password policy without requiring the widget to know the backend's constraints. Validation timing is also configurable. With `validateUserImmediately` set to `true`, the email field is validated after losing focus. The default value is `false`, which defers validation until form submission. That difference can affect user experience, particularly on mobile keyboards where focus may move frequently. Text is collected through `LoginMessages`, which centralizes labels, hints, button text, and other authentication descriptions. Signup can go beyond name and password through `additionalSignUpFields`, whose submitted key-value pairs are added to `SignupData`. The README does not define a bounded limit on field count or describe the exact widget used for every additional field, so applications requiring unusual inputs, conditional fields, or complex cross-field rules should confirm those requirements before committing to this interface. ## Branding Flutter Login with Themes and Logos The widget supports application branding through `title`, `logo`, and `LoginTheme`. An empty or null `title` removes the large text above the login card. The `logo` property accepts either an `ImageProvider` or a string asset path. When no explicit `LoginTheme` is supplied, the documentation says the widget uses its default appearance together with the color scheme from the nearest `Theme` widget. That default relationship provides a starting point for Material-oriented applications, but it does not mean every element is automatically identical to a native Material component. The package describes its own `LoginTheme`, and the repository includes theme-related demo assets such as `demo/theme.png` and `demo/theme-data.png`. Developers can inspect those concrete examples rather than infer all supported visual controls from the callback reference. Customization still has a boundary. The README does not document rebuilding the card, replacing individual fields with arbitrary widgets, or changing the complete transition sequence. A design that requires an entirely different composition should not assume those capabilities. In that case, Flutter Login may be useful for a conventional account screen but unsuitable as the base for a highly specialized authentication experience. ## Flutter Login's Limits and Operational Responsibilities The main limitation is that Flutter Login owns interface behavior rather than the full authentication lifecycle. Its callbacks do not document automatic server requests, session creation, token storage, account locking, password reset email delivery, or protection against replayed confirmation codes. Those responsibilities remain outside the package unless the host application adds them. Callback presence also changes the interface. Providing `onConfirmSignup` exposes user confirmation, and it makes `onResendCode` required for that flow. Omitting `onConfirmSignup` means signup confirmation will not be performed by the user. Likewise, confirmation-based recovery depends on `onConfirmRecover`; without it, the documented behavior does not use a confirmation code to recover the password. An application that enables an incomplete callback set may expose only part of the flow it assumes it has implemented. Animation completion should not be treated as proof that authentication succeeded. `onSubmitAnimationCompleted` is documented as the place for route transition logic, but the README does not define a built-in success or failure result object. The application should perform its authentication operation and decide when navigation is appropriate. The package is therefore the wrong choice if it is being evaluated as a replacement for a backend identity system. ## Maintenance, Releases, and MIT Licensing The repository is not archived, and its last push was on 2026-08-10. That is recent enough to avoid describing the project as abandoned, although recency alone does not establish API compatibility or long-term support. The listed release history includes `v7.0.0` on 2026-05-18, `v6.0.0` on 2025-09-17, and `v5.1.0` on 2025-06-23, which shows that major versions have continued to appear. Version changes can require migration work, but `CHANGELOG.md` is not quoted in the README, so it does not support claims about specific breaking changes, minimum Flutter versions, or migration procedures for `v7.0.0`. Before upgrading an existing integration, developers should inspect that changelog and the current pub.dev documentation, then search the application for uses of renamed or changed properties. The repository declares the MIT license. That permits use, modification, distribution, and private use under the license's conditions, while redistributed copies must retain the required notices. This is a practical licensing baseline for commercial Flutter applications, but organizations should check dependency licenses and their own compliance requirements separately. ## Conclusion Flutter developers should consider Flutter Login when they need a Material-oriented authentication interface that covers several account flows and can accept application-owned callbacks. Projects requiring an established identity provider, backend session handling, token storage, or an exact prebuilt design may need another approach. Before adoption, verify the package's current pub.dev installation instructions, then check callback behavior, field validation, confirmation requirements, and visual customization against the target application. ## FAQ ### Does Flutter Login handle login and signup requests for an application? It exposes `onLogin` and `onSignup` callbacks for submitted form data. The README does not state that the package performs backend requests or manages authenticated sessions. ### Can Flutter Login collect custom fields during signup? Yes. The `onSignup` callback receives a `SignupData` object, and entries from `additionalSignUpFields` are available in a `Map`. ### Does Flutter Login support password recovery and confirmation codes? It documents recovery through `onRecoverPassword`, confirmation through `onConfirmRecover`, and signup resending through `onResendCode` when signup confirmation is enabled. ### How can email and password validation be changed in Flutter Login? Use `userValidator` and `passwordValidator`, each of which accepts a `FormFieldValidator`. Email validation is the documented default for the user field. ## Sources - [Issues](https://github.com/NearHuscarl/flutter_login/issues) - [License: MIT](https://github.com/NearHuscarl/flutter_login/blob/master/LICENSE) - [NearHuscarl/flutter_login on GitHub](https://github.com/NearHuscarl/flutter_login) - [README](https://github.com/NearHuscarl/flutter_login/blob/master/README.md) - [Releases](https://github.com/NearHuscarl/flutter_login/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nearhuscarl-flutter-login