That is not an error. It is a security warning. When you login into your account in the next step, you are asked to grant access to the application and it will create an app-password. You should only do that if you did indead initiate that… Since everybody can create this request and share the link with you. It will ask you for authorization and the atacker could become login credentials.
Here is what you see on your terminal for a user called “john”:
Now if user “john” opens the url provided under “login” in his browser and logs in and grants access, an eventual atacker - since everybody can create this request who knows the url of the cloud - could have sent the link to user “john” and he would eventually not expect any harm without this warning. The potential atacker would become this respond if access is granted by user “john”:
root@nextcloud-host:~# curl -X POST https://cloud.example.com/login/v2/poll -d "token=<the 128-digit-token obtained in first step>" | jq
{
"server": "https://cloud.example.com",
"loginName": "john",
"appPassword": "<72-digit-password>"
}
And with tese credentials one can login to the account “john”
You will have to explain your use case a little more in detail. I do not understand what you are looking for. Are you creating an app?
The underlying mechanism here is intended to enable apps that are not suitable to do 2FA, for example, to log in through automatic app password generation. This is how it works e.g. with the desktop client.
Edit:
However (just to put your mind at ease), an attempt to log in to a web frontend with these credentials will fail.
as long you don’t share user credentials unencrypted between multiple systems (which is very very bad habit) there is no way to accomplish this goal. You might be looking for SSO technologies like SAML or OpenID Connect which allow using multiple systems after single login process.