Auth, Security & Secrets

Core concepts

1. Sign-in methods: Email and password, magic links, phone codes and social login (Apple, Google). Apple requires Sign in with Apple when you offer other third-party social logins in many cases; read the review guidelines. — App Store Review Guidelines
2. Sessions and tokens: After sign-in you get an access token and a refresh token. Store them in SecureStore (or the auth library's secure adapter) and refresh automatically. — Expo SecureStore
3. Authorization: Authentication proves identity; authorization decides access. Enforce it on the server or in database rules (RLS, Firestore rules), never only in the UI. — Supabase RLS
4. Secrets management: Public keys in EXPO_PUBLIC_ variables, private keys in server environments or EAS secrets. Anything in the bundle is public. — Expo env vars
5. Mobile security basics: Use HTTPS only, validate all input on the server, avoid logging tokens, and be careful with deep links that can trigger actions. — React Native security
6. OWASP Mobile Top 10: A checklist of the most common mobile risks, including insecure storage, weak auth and insecure communication. Use it to prompt agent security reviews. — OWASP Mobile
7. Privacy and compliance: Declare data collection in the stores' privacy forms, publish a privacy policy, and offer account deletion, which the stores require for apps with accounts. — App Store Review Guidelines

Concept videos

YouTube channels and searches for these topics. On a large screen they open in the reading panel next to the roadmap.

• Auth in React Native — YouTube search: Expo auth Supabase Clerk Firebase tutorial
• Supabase auth — Supabase channel
• Mobile security — YouTube search: React Native app security best practices

Explanation

UI checks are not security

Hiding a button does not stop an attacker calling your API. Every sensitive action must be checked where the data lives.

Typical agent mistakes

Hard-coding an API key to 'make it work', adding a debug log of the token, disabling certificate checks, trusting route params, and leaving test accounts or open rules in place.

Pick an auth provider by effort

Supabase Auth and Firebase Auth integrate with their databases. Clerk offers polished prebuilt UI. A custom auth system is rarely worth building.

What Is It?

Auth establishes a user's identity and session; security is the set of rules and habits that protect their data and your keys.

Why Should I Care?

Security failures expose user data and can get an app pulled from the stores, and they are cheaper to prevent than to fix after launch.

Real World Analogy

Auth is the ID check at the door; authorization is the wristband colour deciding which rooms you may enter; secrets are the master keys kept in the manager's office.

Visual Mental Model

Sign in -> tokens (SecureStore) -> API/DB checks identity + rules -> data
Secrets live on the server

Beginner Explanation

Use your backend's built-in auth, store the session securely, turn on access rules for every table, and run a security review prompt before each release.

Smallest Possible Example

import { supabase } from '@/lib/supabase';

export async function signIn(email: string, password: string) {
  const { data, error } = await supabase.auth.signInWithPassword({ email, password });
  if (error) throw error;
  return data.session;
}

Common Mistakes

❌ Putting a service or admin key in the app.

Anyone can unpack the bundle and read it.

❌ Checking permissions only in the UI.

Attackers call the API directly.

❌ Logging tokens during debugging and forgetting to remove it.

Logs can end up in crash reports and shared screenshots.

Real Project Example

Most apps ship with a managed auth provider and database-level access rules, and add a server function only for secrets and third-party calls.

Build This Mini Project

Add sign-up, sign-in and sign-out to your app, secure the session, add an account deletion button, and write RLS or security rules proving user A cannot read user B's data.

Interview Question

Why is it unsafe to ship an API secret in a mobile app, and what do you do instead?

The bundle can be decompiled so any embedded secret is public. Keep secrets on a server or edge function and have the app call that backend with a user token.

Key Takeaways

• Authorize where the data lives.
• Only public keys in the app.
• Store tokens in SecureStore.
• Add account deletion and a privacy policy.

Stack for this step

Prompts for Cursor, Claude Code & Codex

Paste these into Cursor, Claude Code, Codex, or any coding agent. Replace the bracketed parts with your app details, and keep the agent in plan mode first so you review the approach before it edits files.

Security review

Act as a mobile security reviewer using the OWASP Mobile Top 10. Review the diff for: hard-coded secrets, tokens in logs or plain storage, missing server-side authorization, unvalidated deep links and route params, and insecure network calls. List findings with severity, file and fix.

Auth flow

Implement email sign-up, sign-in and sign-out with [Supabase/Firebase/Clerk] in the Expo app: session persisted securely, auth state in a provider, redirect logic in the root layout, and an account deletion action. No secrets in code.

Prove isolation

Write tests or SQL checks proving a user cannot read, update or delete another user's rows. List each policy and the case that tests it.

Claude Code skill for this step

Save this as .claude/skills/security-review/SKILL.md in your project so Claude Code loads it automatically when the task matches. The same text works as a Cursor rule or an AGENTS.md section.

---
name: security-review
description: Use before merging any change that touches auth, storage, networking or user data.
---
1. Search the diff for keys, tokens and URLs with credentials.
2. Confirm authorization is enforced in the backend or database rules.
3. Confirm tokens use secure storage and are never logged.
4. List risks and required fixes before approving.

Rules, databases & blogs to use

• Firebase, Supabase and Clerk authentication: pick an auth provider
• Security rules category: security-focused Cursor rules
• Whole fight for AI sandbox: limit what agents can run
• AI agent auditing and compliance: audit mindset for AI-built software
• Making AI applications without AI slop: quality and safety guardrails

Resources

• Supabase Auth
• Firebase Auth
• React Native security
• OWASP Mobile Top 10
• Expo SecureStore

The 60-second story

A hotel checks your ID at the desk (authentication), gives you a keycard that opens only your room and the gym (authorization), and keeps the master keys in a safe in the manager's office (secrets).

Apps are the same. Sign-in is the front desk, the keycard is the token you keep in the secure store, and the room rules are database policies that check the card every time. An AI agent that wants to 'make it work' may tape the master key to the front door. Your job is to check that every door still locks.

Mental model: front desk, keycard, locked rooms, master keys off-site.