If you're using HTTPS/SSL and you trust your endpoints, this is fairly secure for your purposes, because the get parameter will be encrypted as part of the query string, so traffic capture is not a problem.
The "secret" hashes will most likely end up in the web server logs of the web server which servers your web application, but if you control these logs, then for your level of desired security that's probably a non-issue.
You'll obviously also have to trust all the services which store these URLs (browser bookmarks, cloud services etc, but you seeem to be fine with that). I'd think the greatest risk was here (e.g. one of your users logs in using a public computer, and the next user of that public computer looks at the browser history, clicks the link and has access to your protected data).
If you're using unencrypted HTTP, your secret hashes will also end up in proxy server logs and basically anyone who can eavesdrop on your connection will have tons of chances to capture the secrets.
However, I'd only do direct GET param authentication if I really didn't care much about the secrecy and integrity of the data the secret hashes are supposed to protect (basically if I wanted to keep the hordes of stupid vandals at bay, but didn't think any determined person might be interested enough in my data to try to access it, and didn't have a problem if it turned out I was wrong).
A very simple way to considerably improve the security of your authentication scheme would be to have the secret tokens expire, or even better yet, to treat them as one-time-passwords. Give each user a list of tokens, to be used one after the other. This doesn't require much code on the server side and solves the problem of one of your users accidentally leaving/publishing his secret token somewhere.