The Implication

Using OAuth2/OIDC implicit flow in a front-end framework website is degenerate. Fite me irl.

You have made the mistake of inheriting a 5-page website built on this year's most fashionable front end framework. It's secured with a questionable OIDC library several hundred npm dependencies using implicit flow.

My opinions are summaries and simplifications of items outlined in the OAuth 2.0 Security Best Practice draft. Implicit flow has categorical problems. Primarily, the access token is delivered directly to the client by hash fragment. Presenting the token in such a way exposes the site and token to a litany of vulnerabilities.

Client-side authorization code flow is a passable alternative with a few caveats. You must use PKCE, as the client cannot secure a secret. And you cannot request refresh tokens because you cannot store them securely. So ultimately you are restricted in your options and have the unfortunate kludge of OAuth2/OIDC libraries bloating your application.

Same-domain is a potential solution, albeit the least feasible. Host the application at the same domain as the API. Use a cookie as an authentication method for both the application and API, and optionally have the API also support bearer tokens. This is not always applicable, as the domain cannot always be shared between multiple applications.

However you can use a same-domain strategy by way of an API reverse proxy:

• Shift authentication to the server. Use authorization code flow with PKCE and issue a cookie.
• Host an API reverse proxy within the application's domain. It converts cookie authentication to bearer token API requests.
• Utilize an iframe that keeps your session and access tokens current by way of http-equiv="refresh".

The front-end now needs to not care about OAuth2/OIDC at all. Refresh tokens can also be securely stored server-side. The application is largely protected against many vulnerabilities by standard conventions of cookie domain and content security policies.