Should I avoid this token-based authentication scheme (that's not OAuth)?

Question

I've dealt with OAuth before but I'm not too sure about the API I'm working with now. My question is basically, is this woefully insecure?

As I understand it, oAuth does the following (roughly):

1. Service X gives me a key and a secret

2. I ask the user to grant me access to service X

3. I send my key and secret to Service X to check. Service X gives me a request token, which I send over with the user.

4. User confirms they want to let me in, and the service sends them back to me with a token I can keep in my database, and use to make service API calls on their behalf

5. At some point the token expires, but the service knows who I am, so I can just ask them for a new one

However, the API I'm dealing with works like this (all over https, obv):

1. They give me an API key.

2. The user gives me their username and password

3. I transmit them to the service along with my API key, then discard them

4. They service sends me back a token I can use to make API calls on their behalf (using the token and my API key), which I store in my database.

5. At some point, the token expires and I need to get a new one so the user must re-authenticate.

Am I right in thinking that the main weaknesses of this scheme compared to OAuth are as follows?

• there is no guarantee that the request comes from my server, so if anyone broke into my db, they could make API calls at will for all my users, using my API key, which they could get from analysing the POST I have to send when authenticating a given user
• I have to go on reauthenticating the user with a password etc because it's basically just dangerous to have such data floating around
• I'm obliged to provide an HTTPS connection for the user to type in their service password in the first place

It's not life-or-death stuff - it's not people's bank accounts etc - but it would be nice to be reasonably confident there won't be an Exxon Valdez dataspill.

Thank you for any help or advice.

Answer 1

This initially jumps out at me: "The user gives me their username and password"

With their username and password you can do a lot of damage. With OAuth it is easier to have granular control of access.

Answer 2

My main concern there would be having to handle the user's username and password at all. I'm not sure I see how the tokens really differ. OAuth gives the additional ability for your information to be registered to the service so you can re-authenticate in the future, but ultimately, if your DB is compromised, then there is probably a decent chance your API keys are as well. In that case, the token would still be useful to an attacker until expiration, but they wouldn't have the ability to get a new one under the second system.

Functionally, depending on how the key storage works, there might be a slight advantage to OAuth, but really, the main meaningful difference is just having to forward credentials yourself.