I'm going to assume here it's a SharePoint hosted app, so authentication is all centered around SharePoint. Provider hosted app may have additional authentication requirements and you would need to refer to vendors documentation on use.
SharePoint hosted app - is a sub-site of the site where it is deployed. By default this will inherit the permissions set on the site (though developer can deploy artifacts and break that inheritance internally). Now - when you access the app you will get the prompt for authentication because your browser will detect it is in a separate domain (at least it should be). This is by design to isolate the app from SharePoint so it can't access anything that it was not granted rights to access.
So for most browsers there is a method to automatically forward your credentials on trusted sites. For IE - you usually add the sites to the "Intranet Zone" which already has security configured for this. You need to add not only SharePoint URL, but your App domain in there as well. That should limit log on prompts for your internal users.
Now - if the credentials are rejected, you will see multiple authentication prompts. With SharePoint this means we are not even getting into site permissions yet (or you would see the "this site is not shared with you message"). Now it can get a bit tricky, as there could be multiple reasons this is happening.
First make sure your "admin" account has actually got access to the site hosting your app (if it's not the account you are logged in as).
Next take a look at what the app does - is it accessing something that you don't have access too? You can sometimes get this from the logs on the server hosting SharePoint. Another method is to load up Fiddler on your machine and generate the same result. Fiddler will show you what you are requesting access too and getting denied.
I'm assuming here Apps are also configured correctly, but just in case check these as well:
Check the fiddler traffic to be sure your app access URL is what you expect (validate DNS is configured correctly) and not pointing you somewhere you didn't expect.
Make sure the site you direct your App DNS entry too does not have a host header assigned in IIS. If it does - extend your web app so you have a new IIS site with no host header and send your app redirect there.
Although you didn't state it - if there are any network devices like application firewalls, proxies, etc these could also be the source of your pain.
Even less likely due to the repeatable nature is your server losing contact with a domain controller, either from it being too busy or network packet loss. That could also result in popups since the web server would fail to validate a user.