Home/ Questions/Q 6173071
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T23:30:15+00:00

Ok so I am creating an API for manipulating users and data in a

  • 0

Ok so I am creating an API for manipulating users and data in a web application using XML. If they POST XML they can create users, etc. I am using a 2-legged OAuth solution to secure and verify the API requests. However this question is not about that aspect of security, but the aspect I will describe is for allowing the user to login from an API request without having to type their username and password, here is what I have:

Step 1, partner uses XML API to create a user, if successful the system returns a path containing the new ID, “/user/99” for example.

Step 2, partner makes a request to user/login/99, this will create a new “Login Token” in my database, here are the relevant properties:

UserID      int     FK
AccountID   int     FK
Token       string
Expiration  date
Used        bit

UserID and AccountID are related to the respective Users and Accounts table…

the Token is the first 20 characters of a randomly generated GUID with the dashes removed and all characters set ToUpper().

The Expiration is 30 seconds from DateTime.Now.

Used = false

Step 3, the partner will have knowledge of the URL of the system (which is on a different domain from the API), and they can now make a POST to it like this:

http://otherdomain.webapp.com/core/login/%5Binsert guid here]

Now, the ‘otherdomain’ part is going to be unique per account, so at this point we verify:

Look up the LoginToken based on the provided guid, if it goes with the account that matches the subdomain, is NOT expired (within 30 seconds), AND ‘Used’ is set to false still, log the user in, set Used = true, direct them to the homepage or to another URL if one was provided via querystring.

So basically you NEED a complete registered App and secret key and all the jazz for OAuth simply to REQUEST the GUID which allows you to login but only works ONE time and within a 30 second window… and they need to have knowledge of the login URL in the first place, IS THIS GOOD ENOUGH?

In the end if someone can somehow know the GUID and the URL all within 30 seconds they could hi-jack the login, but what are the chances of that?

Alternatively, what could I add to make it more secure?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    (Disclaimer: I am not a security expert.)

    The immediate problem that I notice is this:

    http://otherdomain.webapp.com/core/login/[insert guid here]

    Based on your setup, the GUID token has to be given to the user when it’s requested. That’s effectively the password for the request. If you send it over HTTP, anybody who can snoop the connection has the token and it wouldn’t be hard to hijack the session. This absolutely must use SSL for the entire process.

    Beyond that, the problem is that you’re sending the token to the user before they can use it, which isn’t great. But with SSL it may very well be good enough for your purposes. I’ve used a similar method when dealing with a protocol that can’t handle normal authentication, the user connects over the secured channel first and says “I want to do a transfer on the other one”, and the server sends back a token they can use for that request. It works well enough on a low-security system. If you’re protecting critical data, I’d strongly recommend you invest the money to bring in an expert to look at it before going to production.

    • 0