No, this scheme you propose is not secure, because you are potentially exposing your cross-domain authorisation token in server logs and
referer strings on any third-party web servers you'll be linking contents from (or possibly injected by XSS to inspect for request values), if you're passing it along as a URI parameter.
As for cookies, it depends whether you'll be using this authorisation token on multiple domains or a single domain:
- Multiple domains: Since you'll be needing your cookies to be read cross-domain (not limited to a certain
POST method, so you're at least not needlessly exposing this token to any of your third-party content providers (form data on
POST is a part of the request body and not header, meaning its values are not simply inspectable through web servers).
path value, and if possible, use
httponly cookies also (if you framework doesn't support working directly with this value, you could simply attach
;httponly to the end of your authorisation cookie value). Using
These are the considerations you will have to take care of, regardless if you meant in your question you're after multiple-domain authorisation, or a single-domain one:
- Tokens should not only be random, but also unique. Random here means they can't be predicted by knowing any of the previous tokens, and unique means you not only have to expire them as fast as you can, but completely remove from your token pool, and check on token creation you're not repeating and with it invalidating any previously generated tokens that are still valid. Though the unpredictability should theoretically take care of the latter uniqueness requirements, it's still best to make sure and check against your pool before writing a new token to your database.
- You will probably want to lock your token validity to a unique client, as soon as possible. While that unique client might be a rather moot point and easy to spoof, it still provides for added validation when a single token will be used to authorise a single user across multiple domains (or on single domain, when the user resubmits the login request for some reason). I suggest signing any client data you can get your hands on with a HMAC and then storing it in your database along with the token. On any further authentication request, you then also check against this client signature HMAC to further validate the token used.
- Perhaps most importantly, make sure all of this token exchange is secured by using encrypted transport layer, namely HTTPS (SSL or TLS), and eliminate MiTM type attacks on your authorisation process.