Passwordless Login without Magic Link/OTP

Hey Guys,
I am using an Oauth provider (Xero) as an authentication method. Basically a user clicks a signup/login with Xero button on my app, they authorise their account on Xero, then are redirected back to me with a code and I get an access token. The whole signup process works well, however for the user password, since there is no input from the user, I generate a random code. This all works fine, however when it comes to logging in, I can’t seem to find a way to put their password (the generated code) back into the password field.
Was wondering if you guys had any idea how to try and solve this?
Thanks, Really appreciate it.

It’s a little complex, but achievable.

When the user users passwordless, you’d ideally want an input that is invisible that is still used for a password.

const input = document.createElement('input');
input.type = 'password';
input.style.visibility = 'hidden'
input.id = 'password-inject';

document.body.append(input);

You would then have some sort of trigger when you receive that code, then inject the value into the input:

const input = document.getElementById('password-inject');
input.value = '<value here>'

Then how do you get that inputs value?
Use that toolbox plugin and use then bubble_fn thing (not sure what it’s really called) to create a trigger and send that value to it.

const input = document.getElementById('password-inject');
input.value = '<value here>'
+ bubble_fn_something('<value>')

This would send data to that trigger and in your workflow you can do something based off that trigger.

Then signin/sign up per usual with that password value sent to the bubble_fn.

Disclaimer: I have not tried this, and it’s all coming from my head right now so in terms of it work, you’ll have to make it work for your use-case.

So are you saying to use the code as the password basically?
If so, each time they authorise the code is different (so the code received when they signup is different to the code received in all subsequent authorisations). Not sure if you are familiar with Oauth 2.0 flow but that is what’s happening here. The code us purely to exchange for an access token to access the users data.