I'm trying to understand the oauth2 flows, specifically the authorization code flow. I have a javascript app docker container, backend service container, and an identification service container.
If I understand the flow correctly, the javascript app should redirect the user directly to the identification service for login? Why can't the login page be contained within the javascript app with an api call to the identification service?
The original idea is that the identity provider (your "identification service") will maintain users with their data (like password if applicable), and the application that uses it (sometimes called RP, relying party in Oauth terms) should not have access to that user data.
Think of Facebook login to an app. In that case, Facebook is your identity provider, but a user would not want to enter their Facebook password into your app, and your app doesn't need to know, you just want a signed list of claims who the user is.
Of course there are cases when the identity provider and the apps that use it are developed by the same entity, or are entirely part of the same application. Even in this case, it is more secure to only have user data in one place, and separate that risk from all the other applications that use the identity. This way even if an application is compromised, user data like credentials are still not available for an attacker. However, in recent years it has become fairly common to not use it this way, and if the IdP and RP are from the same entity, use some other flow so no redirect is needed. This is especially common in single-page Javascript frontends, and for many cases it's ok, but you should be aware of the risks (primarily that user credentials will then flow through your other apps too, and a compromise in any ofthem may directly access user passwords for example).
(Also maybe you just didn't include all of your services in the question, but if there is only one application using an identity provider specifically providing login for this one app, you probably don't need this whole complexity of OIDC and a separate IdP at all.)