Sometimes there is no login page so you need the authentication scheme to contain all the actions. For example, with SSO or NTLM-type page sentry authentication. Also, processes on the login page that do run after the login process run the risk that (a) the redirect that takes place from within the login process might conflict timing-wise with code executed in the processes that follow the login process on the page, and (b) the session ID might change during the execution of the login process, so actions that take place in processes on the login page after the login process might not be effective if they act on session state using the original session ID.

About "b", are you saying that code that executes in the Post Authentication Process still has access to the original session ID?

Also, if the session ID were to change during the login process and a page process followed that login process, wouldn't that page process be working with the new session ID/state? How would they use the original session ID?

The Post Authentication Process will run using the new session ID if it has changed or the old session ID if it has not.

Your point about processes after the login process using the new/old session ID/state is correct. They too would use whatever the current session ID is. What can happen though is that the login process redirects to the after-login page and that HTTP request gets acted on immediately, i.e., the request goes to the HTTP server/modplsql and a new page request is started in a new database session at once. This page request will use whatever session state exists at the moment. In the meantime, the process or processes after the login process on the login page in the original request get executed. If these alter session state, that state may or may not be available at the instant it is accessed by the new after-login page request.

So it's safest to keep things sequential/synchronous by using the Post Authentication Process.

This is a bizarre coincidence but just today an alert forum member described a problem that indicated that the processes on the main Application Express login page were not performing their supposed functions. Looking at the source of an after submit process on the login page, one that runs after the login process, we see:

...ought to match SHORT_NAME with the page item where you type in the workspace name on the login page. But it doesn't. Why not? Because by the time the previous process finished it had assigned a new session ID and had redirected the user's browser to the Application Express home page. When the above process accessed the value of F4550_P1_COMPANY, it did so using the session state of the new session, which was empty.