Lock displays twice when using Hosted Login Page w/OIDC enabled. (ExpressJS)

I am trying to use Lock with an ExpressJS Web Application. Initially I was not using OIDC compliance, but now I am trying to. After trying to work the problem for many hours; Googling, experimentation and reading threads in this forum, I just seem to be chasing my tail. My general requirements are to be able to access an API after login, and also obtain a refresh token.

I thought I had everything working OK until I started testing with users other than my test account. At that point I starting seeing the problem described here (Help with OIDC Complicance on Hosted Log In page - Auth0 Community). I followed the advice to start using the “/authorize” end-point which wound up looking something like this:

https://hsl-sop.auth0.com/authorize?client_id=4cKmQU8j6ltruCjcStEwePID4N2p18Si&scope=openid profile user_metadata offline_access&audience=https://restapi.sop.heavensentlegal.com&response_type=code

Using this method I now have two problem.

  1. Lock displays as expected, and I can login (with test account), however, after a successful login Lock displays again and from what I can tell my redirect end-point is not called. I login the second time and this time it calls my redirect end-point. But, this leads to problem 2.
  2. No refresh token is returned.

@jeff4 do you mind posting your update as an answer (and also feel free to accept it). It’s just that as an answer it clearly points to the solution in case anyone else stumbles upon the same issue. I can also move that content to an answer, but I can’t do it while keeping it associated with your user I prefer to save that as a last resort.

After continuing to work the problem I managed to identify the root causes my two problems and workable solutions to them. Here they are…

For problem number one, it turns out the problem was with the Auth0 Passport Middleware. It apparently does not support responseMode = "form_post", the middleware code only checks for the existence req.query and that there is no error value on the query string. This caused the second Lock to appear, and for some reason the second Lock called the redirectUri as a GET method instead of the POST.

The second part of my problem was to get the refresh token. The solution was to make sure offline_access was appended to the scope property in the customized hosted login page. Even though I had specified offline_access when configuring the call to webAuth.authorize the value was not passed through to the config object in the hosted login page.