1

On the project that i'm currently working, we authenticate the clients by username and password. In this system each user has a key which is calculated from his password.

However, we want to provide an API access for the users where they will be authenticated with an oath 2.0 token. So the problem that I'm facing is that we need the password for calculating the key and we want to avoid the user to hard code his password. So what we have thought about was that when the user requests for the token and the server encrypts and signs the user key and sends it back to the user together with the token. At each API request the user has to send both! Considering that all communications are done over HTTPS, there is alway a chance that there would be a client-side attack where the attacker can capture both the encrypted key and the token and replay them using the same API calls!

The solution that came up to me is as follows:

The encrypted key should contain an expiration date (this date should also be included in the signature)! The problem that remains here is that how we are going to update the encrypted key if we assume that user doens't connect for a long period. On the other hand for non-repudiation and replay attack prevention, we ask for client-side signature (using HMAC or RSA) over the token and the encrypted password!

So my question here is that whether asking the user to sign the token and the encrypted password is too much and unneccessary.

Thanks

Improve this question

1 Answer 1

Reset to default
1

If your back end requires the plain text password, why not cache the password on a secure API proxy server?

  client --- oauth---> [Data Center] ---> HTTP/S ---> App that caches passwords ---> backend

There are many ways to do OAuth 2.0, and I would suggest using the normal token that already includes an expiration, scope, and signature fields.

Just use the verified user ID that comes from the OAuth token to dictate to your proxy on the back end what calls to make.

In my mind, this architecture centralises security, reduces complexity, and allows for better testability.

Improve this answer
1
  • You would have to write the proxy yourself. Yes the PW would be cached forever. If you don't want the password to be accessed by admins, then the backend should be updated to not require the original username and password, or else you're setting yourself up for security risks and probable failure Commented Sep 18, 2013 at 12:18

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.