First of all let me tell you that you can communicate from Flex over HTPP or HTTPS. It depends on your need.
Second, when it comes to user authentication you can use basically the same workflow you use in HTML/PHP apps. For example suppose you authenticate the user from the client (could be an HTML form or could be a form from the Flex application itself). Back on the server, you validate the credentials and if correct you set some flags in session. All the calls you make from the Flex client to PHP scripts (using REST services, web services, remoting or XML-RPC) will append the session id to the request, and as a result the PHP will be executed with the same session information. And based on the session information you can check if the user has the rights to do what the operation is trying to do.
When it comes to code execution loaded after the application was initialized (for example your Flex application loads some widgets from other servers), Flash Player offer sandboxes as a way to ensure that foreign code (and potentially dangerous from the point of view of the security) is not accessing the variables from the main Flex application. This is done by default. For example if you have a Flex application that loads a weather widget from another domain, you don’t want the weather widget code to find what is the user name or his bank account is (suppose that the info is part of the Flex app).
If you trust the code you loaded (although this is a security risk) you can “import” instead of loading, and the widget code from the above example could execute in the same application domain as the Flex application code.
If you keep the loaded code in a separate domain (you don’t “import” the code), you can communicate from one domain to another using Local Connection. You can read more about these here. HP created a free application called SWFScan that scans Flash applications for a number of vulnerabilities. This is a good way to ensure that you don’t make mistakes.