I'm researching our options for securing access to a single-page web app and a mobile app. The apps communicate with a REST API which, based on the authenticated user's identity, will return potentially sensitive information. The apps can be considered Clients in OAuth 2.0 terms.
Looking at Auth0 and Firebase there are differences in their token exchange which appear to render Firebase's approach less secure than Auth0. Given the popularity of Firebase, that seems incongruous hence the post here.
Firebase
Firebase appears to operate as the Authorization Server, authenticating the Resource Owner (user in our case), and returning to the Client, an id_token and access_token.
Reviewing their Google Sign-In example, in the case that you have a custom backend, Firebase's docs recommend passing the id_token to your backend for validation and to establish a session. They offer little warning about using local storage for credentials, though do give the option of not doing so.
Handling either the access_token or id_token in the browser of a Single-Page App seems inherently less secure, as it places either token vulnerable to XSS attacks.
Auth0
By comparison, Auth0 recommend handling authentication in a Single-Page App scenario using the Authorization Code flow with PKCE, and doing so in a manner which proxies requests via your own backend. This seems inherently more secure because of the code_verifier/code_challenge steps in place, and the absence of either id_token or access_token being stored or accessed in the single-page app itself.
Questions
- Is Firebase inherently less secure on account of this, or am I missing something?
- Is this simply a case of using what's most appropriate for your needs?
