 <p>My 2 cents:</p> <ul> <li>We a have a Flex application and our login screen is part of the Flex application. We don't use SSL but you may define a secure channel if you need it (but you don't);</li> <li>We created our own instance of the adapter class on the server (that extends the one that comes with BlazeDS). The idea is that this class would check if the session for which that request belongs to has an authenticated user or not. In the Flex methods/ classes (on the Java side), we used annotations to inform the adapter class about requirements that must be satisfied in order for that method to be called - we call these annotations "FlexService" (for the class) and "FlexMethod" (for a method); <ul> <li>The main reason behind this is to avoid a method from being called if the user has not been authenticated before, and we want more granular control than just "block everybody". We have licensing requirements and this library is also responsible for checking if the user has a license and if that license still valid for each request.</li> </ul></li> <li>Remember to hash your password before saving it to the database, and compare the hash only. You could hash it one time in the Flex client (so the open password is never sent to the server), and hash the hashed value again before saving it to the database (so that if someone obtain your database hashed passwords, he still cannot hack into your system because he won't have the original hashed value that was sent from the Flex client).</li> </ul> <p>I am pretty sure I will get some downvotes if BlazeDS implements all of the above, but I didn't like what I found that was native to it, and I thought that using annotations was a good solution, especially because we were using annotations anyway to mark the methods that were BlazeDS methods (so IntelliJ would stop bothering us about methods that are not called anywhere).</p>