This article should help you in choosing the right security for your browser based Javascript or Typescript applications.
You should aim to secure the application as best as possible. The following diagram should help you in making your decision. Also for any of these flows, you should always use HTTPS.
Appendix
SPA: Single page application
OIDC: Open ID Connect
STS: Secure Token Service
PKCE: Proof Key for Code Exchange
Securing the Javascript/Typescript application using Cookies
This is the most secure way of implementing the browser based application, if done properly. This requires that the app has a trusted backend which can keep a secret. The trusted backend could for example, login using OIDC Code flow and store this data in a cookie. The Javacript application can only use the API in the same domain, and so use same site, secure, http only cookies with each request. Anti-Forgery can also be used on the API as an added protection. If using APIs from different domains, the trusted backend should make these requests, and make the data available in it’s APIs.
The application is a standalone and does not use an STS
Then you require a trusted backend which implements the auth logic.
What’s the problem with OIDC Code Flow, or Implicit Flow for an SPA application?
The main problem here is that the browser based application manages the tokens in the browser. Between the HTTP requests, the tokens needs to be persisted somewhere like the local storage.
See the links underneath for the details like what, how, why.
Links
An alternative way to secure SPAs (with ASP.NET Core, OpenID Connect, OAuth 2.0 and ProxyKit)
The State of the Implicit Flow in OAuth2
https://openid.net/developers/specs/
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12