To play devil's advocate, people discourage "security by obscurity" but not "security with obscurity". That is to say, secrets or "obscurity" as part of a layer in your overall security model isn't what gets contested, it's solely relying on obscure information staying obscure that gets contested.

e.g. configuring an sshd accepting password auth and unlimited retries to listen on a non-22 port is "security by obscurity". configuring an sshd to disallow root logins, disallow password authentication, only accept connections from a subset of "trustworthy" IP addresses, and listen on a non-22 port, is "security with obscurity"

The idea behind "security thorough obscurity" is that even if the adversary knows everything about your setup *except the secret keys*, you should be secure. Security through obscurity is any method of protection other than the secret key, like for example: * serving ssh on a random high port * using a custom secret encryption algorithm * hosting an unauthenticated service on a secret subdomain in hope nobody will find out * or with a long directory name

Some security thorough obscurity is OK (for example high ports or port knocking help buy time when protecting from a zeroday on the service). It's just that relying only on the security thorough obscurity is bad.

In this case, I wouldn't call URLs with embedded key security through obscurity, just a poor key management.