Export feature is necessary
I won't write any more articles unless this platform provides an export feature.
Our knowledge should be controllable by ourselves.
Why you shouldn't use that IdP SDK on most of your Web SPA
-
Because they tend to store refresh tokens in local storage or session storage.
In modern frontend world, we really rely on npm libraries. You cannot trust yourselves that you are not doing any self-XSS provided that there are tons of dependant libraries in your node_modules directory. -
Because they use 3rd party cookies, which is blocked by default or at least deprecating even in privacy unaware browsers.
Examples
Bad Example: AWS Cognito + Amplify SDK
They store in localStorage by default. They do provide a way to override, but not so clear from the interface.
Not so good Example: Firebase
They store in 3rd party cookie by default as per their documentation. There's no necessity to allow google to track the users, and also 3rd party cookies are going to be blocked even on Chrome.
They do provide an interface to select, but not clear on how they implement each choice.
It can be considered OK if you select Auth.Persistence.NONE.
Good Example: Auth0
They do know what they are doing. They provide webworker isolated in-memory persisitent by default, and prefer that only when the app has really no backend server in their doc.
What should I do then?
If your requirements allow users to be logged out just by refreshing the page, go for in-memory persistence. Auth0 SDK provides this out of the box.
If not, you must receive the tokens in your backend servers, and provide Id/Access tokens or some equivalent to the SPA. If you are switching from the not good flows explained in the example, probably the OAuth PKCE-enhanced auth flow would be your choice.
Discussion