To access your IP camera’s image or video stream with embedded username:password in the URL from Basic UI, Classic UI or mobile apps, the image or video is funnelled through the proxy servlet so it can be viewed outside of your local network (like via the myopenhab service).
The proxy servlet does not actually negotiate WWW authentication (Basic or Digest), but instead assumes Basic authentication and adds an HTTP header for Basic authentication before even submitting the GET request. When that is the correct choice, the far end device does not respond with an HTTP 401 response code, but instead accepts the authentication and returns the data. When the far end device insists on Digest authentication, you hit a problem. I have a TP-Link NC220 camera that requests Digest authentication through normal use, but when it receives the Basic authentication header as delivered by the proxy servlet, it accepts it anyway and works. I imagine that many other cameras won’t work this way.
The preferable approach would be to negotiate the kind of authentication that the far end device wants, but it’s pretty tricky to act as both a proxy and something that fully negotiates WWW Authentication transparently to the requester. I was making an effort at that over the last days, but no joy yet.