What does a practical implementation of authentication for an internal company app look like?
20:40 24 May 2026

I'm working on architecting an internal app for my company that will have a separate frontend and backend and will use our IdP (Okta) for login. My initial idea is to have frontend have users log in through IdP with OIDC + PKCE where the IdP issues authorization code and passes the code back to the frontend. Frontend then fetches the access token JWT with the code and stores the token in either memory, sessionStorage, or localStorage. When the frontend uses the token to authenticate to the backend, the backend validates the JWT and grants access if valid.

My question is, for a simple and small-medium scope application, how reasonable is this approach? I understand handling all auth on the backend and validating the user with some form of session state would be more secure since the access token is never visible to JS, but how much does that matter if the browser would need to be compromised for arbitrary JS to be run anyways? If I treat every instance of the frontend as inherently untrusted, it still needs to see some sort of access at some point, whether it's an encrypted HttpOnly cookie, access token in memory, or a refresh token in sessionStorage, it's all visible to a compromised browser. At what point am I building redundant security, or security for a scenario that would only happen in a targeted nation-state attack? Do any of these change by enforcing on-prem/vpn-only access to the frontend/IdP/backend?

authentication security openid-connect