Yes, you'll also need a Traditional Web App, just for sending the e-mail, unfortunately. However, in general, these sane rules apply for password resets:

• Allow the user to click "I forgot my password". Ask them for their e-mail address, then have them press a confirmation button. Even if the user clicked the button, still allow login with their current username/password to prevent malicious resetting.
• Never send a new password. Instead, send an e-mail containing a link with a unique, non-guessable ID (so no sequence numbers in there! use e.g. a GUID) as parameter. Create and store this GUID in the database when the user clicks the button, then send the e-mail.
• Check whether the e-mail address specified is valid, i.e. it's of a valid, active user. If not, still pretend to send the e-mail (show something like "if you specified a valid e-mail address, you will receive an e-mail with instructions" or the like). Otherwise an attacker can play guess-the-e-mail-address.
• The Screen that is linked from the e-mail should have the GUID as parameter. When it's called, check whether the GUID is in the database. If not, do not proceed.
• Have an expiration time on the GUID, i.e. after a set time (e.g. two hours) it's no longer valid, and the user must request a reset again. You could provide a link to the "forgot my password" Screen for extra service.
• If the GUID is valid, and not expired, ask the user for a new password, and ask confirmation of the password (so the user must enter it twice).
• Check for minimal length of the password. Do not check for upper/lower case, numbers, punctiation marks etc. It's better to set a larger minimum length than to make a mix of upper/lower etc. mandatory. Bonus points for a fancy "weak" / "fairly strong" / "strong" indicator.