Your current solution would work, however, you could keep the information on your server by tracking a session. When a user sends their login credentials, you could store them in a database (possibly encrypted) and then issue them a unique session id (should be difficult to predict the session id, eg. crypto rand + hash).
Once the user has obtained the session key, they would send that id along with every request to your server. When you verify that this session key is valid, you get the username/password out of the database, and make the request on behalf of the user. After some amount of time, you'd invalidate this session key and delete it and the login information from your database. This would help guard against replay style attacks.
If you include the actual login information and don't have some kind of age off, an attacker could obtain the URL used to access the system, and possibly make requests on behalf of the user. Of course, this depends on how you set up the URL etc.
Typically though, this sort of situation is handled by storing the credentials locally in some sort of secure (e.g. encrypted) storage, and issuing some kind of temporal session identifier.
While there may be some benefit in using short running processes, it is likely more cost than benefit. If an attacker is to the point at which they can read memory in your processes, the fact that the time in memory is short lived won't help much. Furthermore, you are still probably storing the encrypted credentials somewhere on your server (e.g. http access logs), along with the encryption key (which I'm guessing is in a database). If the attacker has access to both, the credentials will be compromised. Depending on which language you're using to write application, there may be some way to zeroize memory once you're finished with the sensitive information.
If you use timestamps in the URL, you're going to need to make sure that the timestamp can't be tampered with (HMAC, AES-GCM etc). Keeping credential data, encrypted or not, also represents a problem controlling information. If you suspect your encryption key has been compromised, you can easily delete the credntials from your server. If the credentials are in URLs potentially scattered all over the internet in browser caches etc, you won't be able to mitigate the leakage.
If you store the credentials in the database, along with whatever material you use to derive the key, you'll have much more control over the data. Assuming you have your database application secured, it is arguably more secure. I would suggest using different keys for each set of credentials, and using some kind of KDF (http://en.wikipedia.org/wiki/Key_derivation_function) to derive the key, instead of storing the key in plaintext in the database. You could also include some portion of the key derivation material in the session id you issue to the user.
Of course, if someone has complete access to your server, including the database and/or the VA space of your CGI processes, the credentials will be comprimised, but that is true with nearly any solution.
If I were writing this application, I would use session ids to tie a user's requests to a set of credentials. I would use a database table containing fields for the id, creation time, last seen time, username, password, and key derivation seed (this part depends on how you derive keys). The session id I would issue to the user would be a large, hard to guess value (stored in the id field), combined with a portion of the material needed to generate the key (this material wouldn't be stored on the server, so both a valid session id and the material stored on the server are needed to decrypt the credentials).
For instance, a session id may look like this:
d7be62755db80ccefb7d802fde153145b6e9_bdb8f9bf599293fd65a020dba1ecd
The first part would be the id portion, and the second half part of the data needed to derive the key.
When a request is made, the id portion of the session id would be verified, and the decryption key generated using the key material portion supplied by the user (via the session id) and the portion stored in the database. Once the key is generated, you'd decrypt and use the credneitals.
This way, if an attacker gains access to the database, they don't have everything they need to decrypt all of the credentials. They'd need a session id for every set of credentials they wish to decrypt.
In order to age off sessions you could have a cron job, or some other mechanism, deleting expired sessions from the database.
