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.