Secure user access

How can you build and verify an authentication flow without confusing the sign-in interface with data protection?

  • Lovable
  • Claude Code
  • Codex

1250 € per session, excl. VAT

In short

In a half-day session of 3 hours you build an authentication prototype on a prepared training application. With Lovable, Claude Code or Codex, depending on the authorised environment, you formulate instructions, review changes and test registration, sign-in, sign-out and protected access, without aiming for production deployment.

Why this training?

Displaying a sign-in form does not protect an application. Controls must also prevent unauthorised reads on the server side, manage session termination and avoid error messages that unnecessarily reveal the existence of an account. Code proposed by AI requires human review: dependencies, configuration, secrets and access rules still need to be checked. The training links each change to an observable test rather than simply to a successful visual demonstration. Running case study: The fictional organisation ‘Avelune Cartographie’ is preparing a space where each member views their own map requests. On a training application, two fictional accounts must be able to sign in without accessing each other's requests; a visitor who is not signed in must not be able to view any requests. Transfer to the workplace: Reuse the test matrix on an authorised internal application, then submit discrepancies and session configuration for technical review before any deployment decision.

Objectives of this training

  • Define registration, sign-in and sign-out flows.
  • Formulate code generation instructions with security constraints.
  • Configure an existing authentication solution in a training environment.
  • Verify access restrictions between two fictional accounts.
  • Document the prototype's defects, corrections and limitations.

Who is it for and what are the prerequisites?

Roles and tasks concerned

  • Application designers using vibe coding who want to add a personal area.
  • Beginner developers able to read code and launch a test application.

Prior skills

  • Have already generated and then modified code with an AI assistant.
  • Know how to launch the supplied project and distinguish between browser, server and storage.
  • Understand the concepts of a request, a user account and an environment variable.

What you will work on

  1. Flows and access boundaries

    Objective: Define precisely what authentication must protect. Authentication versus authorisation; identity, session and data ownership; choosing a proven mechanism rather than custom-built cryptography.

  2. Assisted construction of flows

    Objective: Obtain a first working and reviewed version. Generating and modifying code through instructions; managing secrets outside prompts; integrating the prepared mechanism according to its official documentation.

  3. Sessions and server-side controls

    Objective: Prevent access that bypasses the interface. Server-side validation, session expiry and invalidation; cookie configuration where relevant; restrained error messages and no passwords in logs.

  4. Acceptance testing and prototype limitations

    Objective: Measure quality using reproducible evidence. Positive and negative tests; comparison of expected and observed results; distinction between functional success and full security validation.

What you take away

  • Matrix of flows and access rights.
  • Prototype runnable in the test environment.
  • Log of instructions and reviewed changes.
  • Test report with documented defects and limitations.

Method and assessment

  • Short explanations followed by immediate practice on the running case study.
  • Individual work followed by work in pairs, with peer review of outputs.
  • Guided group discussion: what works, what needs correcting and what remains a human decision.
  • Preparation: Check access to Lovable, Claude Code or Codex, only if the tool is authorised by the organisation; consult its official documentation for technical arrangements. Install the supplied training project and prepare two fictional identities; do not include any secrets or personal data in the instructions.

Observable criteria: Valid registration and sign-in succeed; incorrect credentials are rejected without unnecessary disclosure. ; A visitor cannot read protected data, including through a direct request. ; Each account can only view its own requests. ; After sign-out or simulated expiry, a new protected request is rejected. ; No server secrets appear in the client code, repository or instruction log..

Frequently asked questions

Do you need to use all three tools?

No. One authorised environment is sufficient; the precise capabilities depend on the project and the official documentation.

Can you use real accounts?

No. The exercises use fictional identities and fictional or anonymised data.

Is the prototype ready for production?

No. An additional review must cover, among other things, account recovery, attempt limiting, hosting configuration and data protection requirements.

Do we develop password storage?

No. We rely on a proven mechanism prepared for the exercise, without plaintext storage or a custom-built algorithm.

Last updated: