What are best practices for activation/registration/password-reset links in emails with nonce

This question is very similar to Implementing secure, unique “single-use” activation URLs in ASP.NET (C#).

My answer there is close to your scheme, with a few issues pointed out - such as short period of validity, handling double signups, etc.
Your use of a cryptographic nonce is also important, that many tend to skip over - e.g. "lets just use a GUID"...

One new point that you do raise, and this is important here, is wrt the idempotency of GET.
Whilst I agree with your general intent, its clear that idempotency is in direct contradiction to one-time links, which is a necessity in some situations such as this.

I would have liked to posit that this doesn't really violate the idempotentness of the GET, but unfortunately it does... On the other hand, the RFC says GET SHOULD be idempotent, its not a MUST. So I would say forgo it in this case, and stick to the one-time auto-invalidated links.

If you really want to aim for strict RFC compliance, and not get into non-idempotent(?) GETs, you can have the GET page auto-submit the POST - kind of a loophole around that bit of the RFC, but legit, and you dont require the user to double-optin, and you're not bugging him...

You dont really have to worry about preloading (are you talkng about CSRF, or browser-optimizers?)... CSRF is useless because of the nonce, and optimizers usually wont process javascript (used to auto-submit) on the preloaded page.

About password reset:

The practice of doing this by sending an email to the user's registered email address is, while very common in practice, not good security. Doing this fully outsources your application security to the user's email provider. It does not matter how long passwords you require and whatever clever password hashing you use. I will be able to get into your site by reading the email sent out to the user, given that I have access to the email account or am able to read the unencrypted email anywhere on its way to the user (think: evil sysadmins).

This might or might not be important depending on the security requirements of the site in question, but I, as a user of the site, would at least want to be able to disable such a password reset function since I consider it unsafe.

I found this white paper that discusses the topic.

The short version of how to do it in a secure way:

1. Require hard facts about the account

   1. username.
   2. email address.
   3. 10 digit account number or other information like social security number.

2. Require that the user answers at least three predefined questions (predefined by you, don't let the user create his own questions) that can not be trivial. Like "What's your favorite vacation spot", not "What's your favorite color".

3. Optionally: Send a confirmation code to a predefined email address or cell number (SMS) that the user has to input.

4. Allow the user to input a new password.

I generally agree with you with some modification suggested below.

1. User registers at your site providing an email.
2. Verification email is sent to the users account with two links: a) One link with the GUID to verify the registration b) One link with the GUID to reject the verification
3. When they visit the verification url from their email they are automatically verified and the verification guid is marked as such in your system.
4. When they visit the rejection url from their email they are automatically removed from the queue of possible verifications but more importantly you can tell the user that you are sorry for the email registration and give them further options such as removing their email from your system. This will stop any custom service type complaints about someone entering my email in your system...blah blah blah.

Yes, you should assume that when they click the verification link that they are verified. Making them click a second button in a page is a bit much and only needed for double opt in style registration where you plan to spam the person that registered. Standard registration/verification schemes don't usually require this.