Project: Mobile Auth and Notification Architecture

Build the mental model

This project fuses the two identity- and messaging-focused lessons from this course: mobile authentication architecture and push notification architecture. Individually, each lesson explained one loop: how a user proves who they are and keeps a session alive, and how a backend reaches a specific installed app instance without polling. Building a real app requires connecting those two loops, because a push notification is worthless if the backend cannot say which user's device to send it to, and that link only exists once authentication and device registration talk to each other.

• Mobile authentication architecture — login, session tokens, secure storage, and every subsequent authenticated call
• Push notification architecture — device-token registration and how a backend reaches one specific installed app

The fictional app for this project is a learning platform with user accounts and lesson-reminder notifications, deliberately close to the real site this course lives on. A learner logs in with an email and password, or through an OAuth provider such as Google as an alternative path with no separate password to manage.

Both paths funnel into the same session token from mobile authentication architecture. That token goes into secure storage on the device, never plain preferences, and every subsequent API call, including the push-notification lesson's device-token registration call, carries it as proof of identity.

The design detail that ties the whole project together is the backend's data model: it does not store device tokens on their own, it stores a device token linked to a user id, populated only after that same authenticated call succeeds.

When an event worth notifying about happens, a new lesson unlocking in this scenario, the backend looks up that user's stored device token and sends the push through Apple's or Google's notification service, never contacting the device directly.

MOBILE AUTH + PUSH NOTIFICATION ARCHITECTURE
--------------------------------------------
[Login: password]  or  [Login: OAuth (Google)]
              |
              v
     [Backend issues session token]
              |
              v
   [Token stored in secure storage on device]
              |
              v
  [Authenticated API calls]  +  [Device token registration]
              |
              v
   [Backend: user record now linked to device token]
              |
              v
        [Event: new lesson unlocked]
              |
              v
     [Push service: Apple APNs / Google FCM]
              |
              v
           [Learner's device]

Connect it to a real scenario

• A push notification is only as good as the link between a verified user id and a device token — the backend must never store one without the other.
• OAuth login and password login both end at the same session token; the rest of the architecture doesn't care which path the learner took.
• Device-token registration is itself an authenticated API call and must be rejected exactly like any other call would be for a missing or invalid token.

Try the working example

function simulateAuthAndNotificationFlow(user, event) {
  const steps = [];

  if (!user.isAuthenticated) {
    steps.push("Auth check: FAILED - no valid session token");
    steps.push("Aborting before device-token lookup");
    return { user: user.name, event, steps, notificationSent: false };
  }
  steps.push("Auth check: PASSED - session token valid");

  if (!user.deviceToken) {
    steps.push("Device token lookup: NONE REGISTERED");
    steps.push("Aborting before push dispatch");
    return { user: user.name, event, steps, notificationSent: false };
  }
  steps.push(`Device token lookup: FOUND (${user.deviceToken})`);

  steps.push(`Event received: "${event}"`);
  steps.push(`Push dispatch: sending to ${user.platform} push service`);
  steps.push(`Notification delivered to device ${user.deviceToken}`);

  return { user: user.name, event, steps, notificationSent: true };
}

const scenarios = [
  {
    user: {
      name: "Aye (authenticated, registered device)",
      isAuthenticated: true,
      deviceToken: "device-abc123",
      platform: "Android (FCM)"
    },
    event: "New lesson unlocked: How Mobile Apps Work"
  },
  {
    user: {
      name: "Unknown visitor (no session)",
      isAuthenticated: false,
      deviceToken: null,
      platform: null
    },
    event: "New lesson unlocked: How Mobile Apps Work"
  }
];

scenarios.forEach(({ user, event }) => {
  const result = simulateAuthAndNotificationFlow(user, event);
  console.log(`${result.user}`);
  result.steps.forEach((s) => console.log(`  - ${s}`));
  console.log(`  Notification sent: ${result.notificationSent}\n`);
});

Running the two scenarios prints: the authenticated user with a registered device passes the auth check, finds device token "device-abc123", and logs a successful push dispatch and delivery, ending with notificationSent: true. The unauthenticated visitor fails the auth check immediately, logs an abort message, and ends with notificationSent: false — the device-token lookup never runs.

Firebase Cloud Messaging — Architectural Overview — How Mobile Apps Work