I think in that case you will need different auth middleware depending on the routes the user tries to access, e.g when the user goes to /admin... the user will be redirected to zitadel login, when the user tries to access any other page, they will be redirected to supabase
this depends on your use case. you can build your own login ui with our session api, either as a separat ui or build it directly into your application. also you need to decide if you still need the oidc standard or not. you can find some guidence on how to build the different flows of for your own ui here: https://zitadel.com/docs/guides/integrate/login-ui
In the following guides you will learn how to create your own login UI with our APIs. The different scenarios like username/password, external identity provider, etc. will be shown.
so first about the flow above, if you do have the loginname and the password field on one screen, you can also send both directly in the post create session, in that case you do not need the second patch with the password. if you have both on different screens then it might make sense to do it in to steps
if you do have your administrators (humans), which are able to administrat ressources, for example create users, i recommend creating users and let them authenticate with a human interaction flow, e.g login ui.
but you can think of your own login ui as an application, which needs to authenticate itself against zitadel. otherwise, everyone could just create sessions and get tokens.
thats why you need a service account/machine user, there are also different possibilities on how to authenticate them, but as this is a machine its not possible to show a login ui, so one possiblity is PAT, this is the easiest way to quickly test if everything works. if you do want to know more about the different methods of authenticating a service account you can read about the benefits and drawbacks of each method here: https://zitadel.com/docs/guides/integrate/service-users/authenticate-service-users#authentication-methods