Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm looking for a way to create a URL that allows a user to login to our application without providing a username and password.

We have created an API which is protected using OAuth 2.0. I want to take advantage of this and create the possibility to GET a URL when you provide a OAuth Token (Token is bound to a user) which automatically logs the user in. I think this URL should be valid for 1 time use and only for a certain timespan.

I could generate a GUID or some sort of random string and save this in the database and remove it after for example 10 seconds. Then when someone requests the login URL with a GUID I check if the GUID is in the database and set the authentication cookie for the user. I could possibly take this one step further by checking if the user ever logged in himself on this machine by setting some cookie and validate the presence of the cookie once the URL is used.

I wonder if this is secure and if there are any other common solutions?

share|improve this question
    
You're asking for solutions, but I don't feel I fully understand the situation. I think whether there are any other common solutions depends on exactly what problem you're trying to solve. Is this for cross-site sign-on? If so, it has some similarities with the classic solution (forward the browser to a central login domain, which generates a single-use token to pass back as a query parameter to the satellite domain). –  cloudfeet Jun 13 '13 at 13:31

1 Answer 1

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 path), meaning they could be read by any of your third-party content providers (any linked contents, including but not limited to external domain JavaScript, CSS, image, video,... files) as well. A better way to do it would be with the use of HTTP 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).
  • Single domain: You could use cookies for this, but make sure they're locked to a single domain in their 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 httponly will make sure these cookies can't be read by JavaScript on all supporting browsers (most do support this), thus eliminating the threat of XSS injections to steal your authorisation tokens and hijack user sessions.

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.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.