OpenId Connect - autologin - double boot time

We have a site that only works for authenticated users. That is, when an unautenticated user arrives, she should immediatly be redirected to the STS (IdentityServcer).

Current flow for an unauthenticated user:

  • User navigates to app
  • App downloads, then boots (takes a few seconds)
  • App detects that user is not logged in
  • App redirects to STS
  • User login, and redirect back to app
  • App boots again (a few more seconds)

Question is: How could we detact that the user is not logged in before the app boots, and thus prevent the first boot time?

We’re using the aurelia-open-id-connect to help us manage the oidc flow.


You could verify the session in the backend :slight_smile:

Another way would be to verify this before aurelia starts or only start aurelia if the user is verified.

Suggestion 1, verify session in backend? Not sure I understand. There’s just a plain static web server.

Suggestion 2, Yes, verify before aurelia start is what I was thinking of. But then I need to get a script to execute before aurelia loads, and that script should also decode the token (simple jwt maybe, or send it to the api for verification) and check if present and still valid. That script also must have the configuration of the authority.

Is it possible to do this with webpack? Or should we have a seprat file just for verifying the token?


I have a class User, to keep record of the user. Then on main.js, I do the following

aurelia.start().then(a => { a.setRoot(user.isAuthenticated ? 'app' : 'login'); }

My isAuthenticated, checks my Session class if all requirements match to be considered logged. If yes, I boot the app otherwise I boot the login.

The once user logins in. I reset and deactivate the router, and setRoot to app.

Probably there are other ways of doing it, using Router Pipeline.

The advantage of setting login as a different app, is that while the user is logged out, the app don’t know anything about the authenticated routes, so it is more secure.


I am preparing a comprehensive document explaining the various authentication and authorization methods for Aurelia developers (see While this document was planned to be complete by now, I had to take a long leave of absence due to other more urgent tasks - and am plannng to return back to this aurelia-identity early next month.

I understand that you may not be willing to wait, so I am writing this to offer some quick discussion on your issue - if it is still active