ToMotion AI logo
Menu
Back to gallery

Public AI explainer video

Authentication vs Authorization: How Apps Manage Logins, Passwords and User Access

Here is the important flip: logging in is only the first check. Imagine an employee notices that the Manage Users button is missing. They try to reach...

Prompt

Source idea used to generate this video.

Create a 4-minute animated educational video titled “Authentication vs Authorization: How Apps Manage Logins, Passwords and User Access”, as Lesson 7 of 20 in the series From Idea to App: Understanding AI-Assisted Development, by Talmond Consulting Services. Target audience: Complete beginners who want to understand and develop applications using AI, without needing programming experience. Learning objective: Help learners understand how applications identify users, protect accounts, control access to information and securely manage different user roles. Begin by connecting to Lesson 6, where we learned how applications store information in databases. Introduce a new question: If an application stores important information, how does it know who is allowed to see or change it? Use the analogy of entering a corporate office. A security guard checks your identity at the entrance, but having permission to enter the building does not mean you can access every room or confidential file. Cover the following concepts in a logical learning sequence: 1. Why Applications Need User Authentication: Explain how applications identify users before allowing them to access private information. Use a simple login screen with an email address and password. 2. Authentication vs Authorization: Clearly explain the difference. Authentication answers “Who are you?” while authorization answers “What are you allowed to do?” Use the office security analogy to demonstrate both. 3. Understanding User Roles and Permissions: Introduce administrator, employee and client roles. Explain how an administrator may manage users, employees may update assigned projects, and clients may only view or approve their own work. Clarify that roles group permissions, while permissions define allowed actions. 4. What Happens When You Log In? Use an animated sequence showing a user entering credentials, the authentication service verifying them, the application establishing a login session and displaying the appropriate dashboard. Explain sessions in simple language as a temporary way for the application to remember that a user has successfully logged in. 5. Password Security: Explain why applications should never store readable passwords. Introduce secure password hashing using a simple analogy of a one-way transformation. Briefly explain password resets, temporary passwords and why sensitive credentials must remain protected. 6. Protecting Information Beyond the Login Screen: Explain that hiding a button is not enough to secure an application. Access permissions must also be checked by the backend or database. Use the example of an employee attempting to access an administrator-only feature. 7. Real-World Example — Talmond Application: Show an illustrative Talmond project portal. An administrator adds an employee and assigns a project. The employee updates that project’s progress. A client reviews and approves a deliverable belonging to their organization. Another client’s documents remain locked. An employee’s attempt to manage users is denied. A beginner types instructions into an AI development assistant. Animate a simple permissions table, followed by successful checks: correct dashboard, blocked administrator access and blocked access to another client’s project. Return to the office guard and locked room, then transform them into a login screen and permission checkpoint. End with the lesson title, series name and Talmond Consulting Services.

Narration

Narration used to create this video.

Video narration

Here is the important flip: logging in is only the first check. Imagine an employee notices that the Manage Users button is missing. They try to reach that administrator-only action another way. Hiding the button did not secure anything. The protected part of the app must check their permission again and deny the request. The same rule applies before protected information is returned from the database. In an illustrative Talmond project portal, an administrator adds an employee and assigns that employee to a project. The employee updates its progress. A client reviews and approves a deliverable for their own organization. Now a different client tries to open those documents. Locked. The employee tries to manage users. Denied. Each person gets the right dashboard, but every important action still checks the pass they carry. If you are building with AI, you can tell an AI development assistant: "Administrators manage users, employees update assigned projects, and clients only access their organization's work." That helps you express the rules. It does not replace the checks that enforce them. Return to the office entrance. The guard confirms who you are. Then each locked room checks whether your badge opens that door. A login proves who you are. Permissions decide which rooms you can enter, and every locked room must check your pass.