When a user logs in to an e-learning platform through an OpenID Provider with the authorization code flow, which messages pass through the browser, which go directly between the servers, and who ever sees the password?

Through the browser: the redirect to the OP, the authentication request, the login form and credentials, and the redirect back with the code. Directly between servers: the code exchange with client ID and secret, the returned tokens, the UserInfo call, and the OP's lookup in the user storage. Only the OP (and the browser) sees the password.

* Front channel through the browser, back channel between RP and OP, and the password never reaching the application. *

The full sequence:

1. The person asks for the e-learning page; the browser requests the URL from the RP.
2. The RP has no session and redirects the browser to the OP.
3. The browser sends the authentication request to the OP's authorization endpoint.
4. to 7. The OP returns a login form, the person enters ID and password, and the browser posts them to the OP.
5. and 9. The OP looks up the user ID in its user storage, receives the stored password hash and compares it with the hash of what was entered.
6. and 11. The OP redirects the browser back to the app with the authorization code, which the browser delivers to the RP.
7. The RP sends the code, its redirect URI, client ID and client secret directly to the token endpoint.
8. The OP returns the access, refresh and ID tokens; optionally the RP fetches user claims from UserInfo with the access token.
9. and 15. The RP creates its session and the browser shows the e-learning page.

The application never sees the password, and the user storage only ever talks to the OP. The client secret and tokens never pass through the browser.

Go deeper:

• OpenID Connect Core 1.0: Authorization Code Flow — the same exchange with every message spelled out.
• RFC 6749, Section 2.3: Client Authentication — how the client ID and secret are sent at the token endpoint (HTTP Basic or body parameters).