AI Briefing
KO

Building Aviation Frontend Authentication: Integrating Token Ingestion Paths for Web and App WebViews and httpOnly Cookie Handling Strategy

·2026.09.10 09:51

Key point

We built an authentication architecture that unifies disparate token ingestion paths from web and app webviews into httpOnly cookies, resolving timing issues.

1 / 3

Details

The aviation frontend authentication system focused on integrating two disparate token ingestion paths—web (Cookie) and app webview (Bridge)—into a single processing path. The previous screen-specific individual handling caused security risks and rendering timing inconsistencies, but the final strategy achieved abstraction by setting tokens acquired in the app as httpOnly cookies, identical to the web.

Token Ingestion Paths and Dual Request Logic Tokens are ingested via three paths: web cookies, app session reading (Bridge), and direct app requests. To resolve timing issues where tokens were missing immediately after login due to delays in updating the app storage, we introduced a secondary verification logic that directly requests via requestToken() if app session reading fails. This is a reliable method to confirm state on the web side without modifying the app.

SSR Support and Library Dependency Separation Adopting the cookie approach allows login state to be reflected from the initial HTML generation during server-side rendering (SSR). The authentication hook (useAuthCore) is designed not to depend on Next.js server actions, minimizing library dependencies by injecting member lookup and token management functions as arguments. Additionally, branching environments using isAppByNative and isAppByWeb improved debugging and the accuracy of authentication logic.

React External State Synchronization and Zombie Token Handling Since bridge functions operate outside the React tree, login state is synchronized via properties of invisible DOM elements (data-logged-in) and the global function window.syncAppSession. Expired 'zombie tokens' cannot be deleted via cookies during SSR, so the server only reports failure, and deletion occurs via clearToken() after reaching the client. However, in the app environment, cookies are not deleted immediately to prevent blocking the re-fetch path.

Architectural Principles We followed the principle of specifying where differences exist rather than eliminating them. Screen code references only isLoggedIn and myInfo via the useAuth() hook, encapsulating complex token source determination logic within the hook. This resulted in thinner screen code and improved maintainability, but introduced a trade-off where related logic is concentrated in one place.

This summary was generated automatically by AI. Check the original for the author's claims and context. Copyright belongs to the original author.

Our guide explains how the AI works. Report summary errors, attribution issues, or removal requests via Contact.