Depending on the context, you are relying on the security manager and associated security policy to do the right thing. Generally unless you are doing your own classloader magic, you shouldn't need to do anything special. If you have control of the security policy, (for example in a java application rather than applet) you can grant permissions to call your jars only to certain other code. If you rely on codebase to distinguish code, a https URL is better. It is also no harm to limit access to the jars on the webserver if you know where/who the accesses should be coming from, but is probably more trouble than it is worth.
However, you should always bear in mind that the caller of your API may not be your code, and may be malicious. So in your threat modelling, you should think about what a malicious user may be able to do if they somehow had access to the functionality given by the API your code exposes. The security manager is supposed to check up the call stack to prevent this kind of thing. But if for example your signed jar has a method LaunchMissiles() ...you might want to ask the user if they are sure anyway. And you might want to authenticate the user too.
Nor should you necessarily rely on the user to click the right button on any security warning, especially if it refers to certificates and URLS etc - most users fall into one of two categories: those who click OK on any warning because they don't understand it, and those who click Cancel on any warning because they don't understand it.