The reason the runtime api method is more complicated is because Mendix handles the session with the XASSESSIONID cookie and when you create the new session server side you have to somehow get the new cookie value to the users client. Browser policies prevent cookies being set by a server unless they are in a response.
I would take a look at the autologin module. The idea behind that module is a user is going from anonymous to a named user without having to enter their credentials twice. In the microflow when you create the autologin token you can do a check with the verify password java action in community commons or their is a java action in the autologin module that does this too. if that returns true then you can proceed with having the user login.
Here is a working example with all the different options for signing in. I was able to use the autologin module to do the login in a microflow.
Did you create seperate landing pages for anonymous and regular users? My assumption is that you did not and hence the security errors. Try setting up two different landing pages with different entities on them and make sure that the anonymous user has access to all the entities on that landing page.
I found a way to break the flow of user roles inheritance using the ‘executeMicroflowAsUser’ Java action from the “Community Commons” module on the store (or you can roll your own Java action). Essentially, the “StartLogin” custom microflow I created runs under all roles, but after successful login, ends with “executeMicroflowAsUser( $currentUser/Name, false )”. That prevents the anonymous role being inherited into my “OnLoginSuccessful” MF.