Is it a good practice to store access token in browser localStorage in angular-oauth2-oidc? If not,-CodePudding

I need to store the generated access token at client side, so I have used the library's default setting and added in my Angular code like:

this.oauthService.setStorage(localStorage);

after the statement:

this.oauthService.configure(this.authConfig);

in AuthConfigService file.

But I read on Stackoverflow, it's not recommended to store access token on localStorage. So, what's the alternative? Apart from the requirement to store the access_token in Angular i.e., @ frontend, I also need to fetch the logged in user details retrieved in access_token. So, to read the user data, I tried getIdentityClaims() as follows:

 this.claims = this.oauthService.getIdentityClaims();
    this.user = this.claims['preferred_username'];

But these statements somehow blocking the execution of api calls, and displaying an error like this in the browser console:

ERROR TypeError: Cannot read properties of null (reading 'length')
    at http.js:112
    at Array.forEach (<anonymous>)
    at HttpHeaders.lazyInit (http.js:106)
    at HttpHeaders.push../node_modules/@angular/common/fesm5/http.js.HttpHeaders.init (http.js:211)
    at HttpHeaders.push../node_modules/@angular/common/fesm5/http.js.HttpHeaders.copyFrom (http.js:222)
    at HttpHeaders.push../node_modules/@angular/common/fesm5/http.js.HttpHeaders.init (http.js:208)
    at HttpHeaders.push../node_modules/@angular/common/fesm5/http.js.HttpHeaders.forEach (http.js:280)
    at Observable._subscribe (http.js:1596)
    at Observable.push../node_modules/rxjs/_esm5/internal/Observable.js.Observable._trySubscribe (Observable.js:43)
    at Observable.push../node_modules/rxjs/_esm5/internal/Observable.js.Observable.subscribe (Observable.js:29)

If I comment out that user & claims assignment code, this error is not arising. Any suggestions or solutions to resolve the above mentioned two requirements?

CodePudding user response：

Storage of an access token within local storage depends on the visibility of your application. Is it a public facing web application or an internal organization web application?

If a public facing web application, then the access token should as a minimum have a short expiry duration. This is to minimize the possibility of an active session being accessible to other users that share the same machine.

Alternatively, you can use sessionStorage (see

https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage

)

which keeps the value stored until the browser window or browser tab is closed. This is slightly better then using localStorage (see

https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage

)

Aside from using browser local or session storage, you can implement your own backend session management service or use a third party session storage provider such as Auth0 or Okta to handle the storage for you. Then you won't have to worry about session hijacking of a browser's stored tokens. This is recommended for high use, high visibility public facing web applications.

Reading user details can be done when you obtain the access token from your identity server when the user is authenticated. Then you will not have to execute additional requests to obtain other user details.