Authenticated Users isn't a true group—it's a special security principal that specifies any session that's been authenticated using some account, such as a local SAM account, domain account, or account from any trusted domain. So Authenticated Users does include the accounts you mention.
Microsoft created the Authenticated Users group in response to fears that Anonymous logons could gain access to objects for which Everyone (another special security principal) has access. I don't recommend using the Authenticated Users group for controlling permissions because it includes local accounts, which are a bad practice to use because you can't centrally manage them at the domain level, and they use NT LAN Manager (NTLM) authentication rather than the stronger Kerberos. Also, the membership of Authenticated Users changes dynamically when you create a trust to another domain. When you want to give all users in a domain access to a resource, I recommend that you use the Domain Users group, which limits membership to the domain. If you need to give all users in a forest access to a resource, create a universal scope group called Forest Users and add each domain's Domain Users group as a member.
Conclusion
When it comes to permissions, one critical question we need to be able to answer is: which humans have access to a particular resource?
Most of the time when you’re inspecting permissions on a given resource in Windows you’re not dealing with humans (this is actually a best practice); rather, you’re dealing with groups, some of which are built-in implicit identities with ambiguous names. As a result, we often have to do quite a bit of digging to get what we need.