Although you can customize the Lock instance used in your hosted login page there are certain configuration that needs to the one used by default, in particular, the settings related to the internal options available when using Lock from within the hosted page.
For example, my customized hosted login page sets other Lock display options, but leaves the following options as they are in the default template:
auth: {
redirectUrl: config.callbackURL,
responseType: (config.internalOptions || {}).response_type ||
config.callbackOnLocationHash ? 'token' : 'code',
params: config.internalOptions
},
If the Lock instance is not initialized properly then it has no notion that it’s working from the hosted login page and the error in question may be triggered.
In conclusion, the auth options should be the ones used in the default template; in general, you should not be changing those to hardcoded values. All the options that you hardcoded in your hosted login page, more specifically, responseType, audience and scope can be provided (and should be) by the client application so you should go back to using the internal options and adjust the client application if you want to provide specific values.