Today let me add a proper logout, and before we move forward to more features, let's clean up and apply some of the lessons we learned before.
Follow along on StackBlitz
Logout, in the right places
Looking back at our Http interceptor, a 401 might happen more than once, signaling a bad refresh token. When that happens we can either toast the user about a dramatic failure, and give them the chance to login again, or we can force a redirect to the login page ourselves. May the force be with us.
The solution is to reroute in the Logout
function in AuthState
. We'll make it optional because the Logout
function is called when a user fails to login, and when the AuthState
returns an invalid access token on a page that does not necessarily need authentication.
// services/auth.state // reroute optionally Logout(reroute: boolean = false) { // remove leftover this.RemoveState(); // and clean localstroage localStorage.removeItem('user'); if (reroute) { this.router.navigateByUrl('/public/login'); } }
In the AuthState
constructor, do not reroute. If we do, we needlessly reroute users in safe routes. When it fails after a refresh token, that is a good place to redirect. With a but.
// http return this.authService.RefreshToken() .pipe( switchMap((result: boolean) => { if (result) { //... } }), catchError(error => { // exeption or simply bad refresh token, logout an reroute this.authState.Logout(true); return throwError(() => error); }), // ... );
Another location we want to logout and reroute is when the user clicks the Logout button intentionally.
// app.component Logout() { // logout and reroute this.authState.Logout(true); }
What if we are on a safe route already?
There is a scenario where the API call needs user authentication but the page it displays itself, has a public version of it. For example, if you route to a public Twitter account while you have your own login, you can see the like button and use it. If for some reason the refresh token is no longer valid, then clicking on the like button, should somehow warn users of the lack of authentication, and it should ask the user if they want to login again. In situations like that, having a global redirect in the Http interceptor is not ideal. The solution is contextual. Some API calls need to redirect, and some need to toast only. Here is an example of a like button click.
// example this.tweetService.CreateLike(params).pipe( catchError(error => HandleSpecificError(error)) ); // somewhere in our common functions, or toast service HandleSpecificError(error: any): Observable<any> { // if error is of http response 401, show a toast with a button to relogin if (error instanceof HttpErrorResponse && error.status === 401) { ShowToastWithLogin(); return of(null); } else { // handle differently or rethrow return throwError(() => error); } }
I would choose which way to go according to the type of project I am developing. There is no silver bullet. (You may use HttpContext token for that.)
We wrote about toast messages in Angular previously.
Clean up
Before we move on I would like to clean up the AuthState
to allow extra properties. We are going to still use this service to manipulate the localStorage
of the browser. You might be tempted to create a new service for that, but I see no great value because we only need private members for the authenticated user information. Accessing the localStorag
directly is not ideal, but let's keep going.
// authState update, add all necessary functions to deal with localStorage private _SaveUser(user: IAuthInfo) { localStorage.setItem( ConfigService.Config.Auth.userAccessKey, JSON.stringify(user) ); } private _RemoveUser() { localStorage.removeItem(ConfigService.Config.Auth.userAccessKey); } private _GetUser(): IAuthInfo | null { const _localuser: IAuthInfo = JSON.parse( localStorage.getItem(ConfigService.Config.Auth.userAccessKey) ); if (_localuser && _localuser.accessToken) { return <IAuthInfo>_localuser; } return null; }
Then we are going to tidy up the other methods to use these. We need a way to SaveSession
, and UpdateSession
. We also are going to write the logic for CheckAuth
. Let's first go back to the IAuthInfo
and talk about the expiresAt
property,
Expires At
When the information comes back from the authorization server, it usually has a lifetime, rather than an exact date. This is easier to manage given different time zones on server and client. In the client, however, we need to determine the exact time it expires at. A pretty close one, and good enough for our use.
So the expected return model is:
// return from server upon login { accessToken: 'access_token', refreshToken: "refres_token", payload: { name: 'maybe name', id: 'id', email: 'username' }, // expires in is an absolute lifetime in seconds expiresIn: 3600 }
In our model, it's time to properly map to our internal model
// in auth.model we need to properly map the expires at export const NewAuthInfo = (data: any): IAuthInfo => { return { payload: { email: data.payload.email, name: data.payload.name, id: data.payload.id, }, accessToken: data.accessToken, refreshToken: data.refreshToken, // map expiresIn value to exact time stamp expiresAt: Date.now() + data.expiresIn * 1000, }; };
And now in our Login
in AuthService
we properly map
// services/auth.service Login(username: string, password: string): Observable<any> { return this.http.post(this._loginUrl, { username, password }).pipe( map((response) => { // use our mapper const retUser: IAuthInfo = NewAuthInfo((<any>response).data); // ... }) ); }
Now checking the authentication whenever we need, is a simple extra layer of precaution. We already send API calls with null tokens, and let the server handle it. So it is no harm to remove the token from localStorage
whenever the browser thinks it's invalid.
// services/auth.state write the CheckAuth CheckAuth(user: IAuthInfo) { // if no user, or no accessToken, something terrible must have happened if (!user || !user.accessToken) { return false; } // if now is larger than expiresAt, it expired if (Date.now() > user.expiresAt) { return false; } return true; }
Saving and updating session
The client-side simple solution is already in place, I call it session even though it is not really a session. This understanding will help us later figure out what to do when we implement SSR.
// services/auth.state service // add two methods: SaveSession and UpdateSession // new saveSessions method SaveSession(user: IAuthInfo): IAuthInfo | null { if (user.accessToken) { this._SaveUser(user); this.SetState(user); return user; } else { // remove token from user this._RemoveUser(); this.RemoveState(); return null; } } UpdateSession(user: IAuthInfo) { const _localuser: IAuthInfo = this._GetUser(); if (_localuser) { // only set accesstoken and refreshtoken _localuser.accessToken = user.accessToken; _localuser.refreshToken = user.refreshToken; this._SaveUser(_localuser); // this is a new function to clone and update current value // we will move these into their own state class later this.UpdateState(user); } else { // remove token from user this._RemoveUser(); this.RemoveState(); } }
Notice how the UpdateSession
is a tad bit different. After a RefreshToken
request, we do not need much information from the server, and some servers do not return the payload with it. So it is a good practice to read only the new tokens. To use those two methods:
// services/auth.service // login method Login(username: string, password: string): Observable<any> { return this.http.post(this._loginUrl, { username, password }).pipe( map((response) => { // ... return after savi return this.authState.SaveSession(retUser); }) ); } RefreshToken(): Observable<boolean> { return ( this.http // FIX: get refresh token, not token .post(this._refreshUrl, { token: this.authState.GetRefreshToken() }) .pipe( map((response) => { if (!response) { throw new Error('Oh oh'); } // map first, then update session const retUser: IAuthInfo = NewAuthInfo((<any>response).data); this.authState.UpdateSession(retUser); return true; }) ) ); }
We can also make use of our new private methods in the constructor of AuthState
and Logout
// services/auth.state constructor(private router: Router) { // use our new _GetUser const _localuser: IAuthInfo = this._GetUser(); if (this.CheckAuth(_localuser)) { this.SetState(_localuser); } else { this.Logout(false); } } // ... Logout(reroute: boolean = false) { // use our new _RemoveUser this._RemoveUser(); //... }
Now we're ready for a redirect URL. Let this all sink in first, we'll do that next episode. 😴
RELATED POSTS
Catching and displaying UI errors with toast messages in Angular