I dont get it, why do all those authentication providers want you to use a separate webpage to handle the login, why cant i just have the form and "login with ID provider" buttons on my page.

Why is the user forced to take another step in the flow...
this is UX 101, comon!

You usually can if you set up an API to handle the calls and the identity provider allows it.

If you use an ootb sign in experience from the provider, the .well-known configuration will point to the auth provider's domain so they can apply the specific grants for your app and approve the given scopes.

If you're using OIDC flows and borrowing data from well known locations, the identity will be shared according to the scopes available to the client as tokens. If you remove the third party hop and perform the user consent check in the browser alone from your domain, you will need to have something in your service with client credential permissions on the authority authorization server that can invoke the request on behalf of the user

Tl;Dr bc auth protocols

@SortOfTested yeah but the 3rd party still has to make that request to the provider with the client id etc, and i cant even hardcode that into a button

Could be both UX and technical security reasons.

For security reasons the username and password inputs should not be placed on a page with a bunch of scripts that might be able to grab the info.

For UX reasons a login page might be useful if you want to switch accounts before logging in.

(But I might have misunderstood. Pehaps you’re saying there’s an extra step before that)

Like I said, to avoid it, YOU have to have YOUR service (read: API) use client credential (high trust credentials) to impersonate (send requests on behalf of a user) to the authority (3rd party API).

At that point, your users won't interface with external entities directly. It requires work on your part to make that happen securely. Sans that, auth providers have no way of knowing if requests from your domain are legitimate, or mitm.

Tl;Dr User security > user experience.

I think you are misunderstanding my issue.

currently the flow is like this:

User presses log in on phone app > app opens webpage where user can enter credentials or choose to login with an identity provider > webpage redirects user back to app with a response.

What I wish would happen:

user presses on login with "x provider" > user still gets taken to webpage, but with a direct link to the provider so the webpage automaticly redirects to the provider (instead of having to press the button with the link to the provider on the webpage) > redirect with response.