In most cases you don't need to worry about the token validation details. All this is taken care for you by WIF.
But if you really want to know, the best source of information is Vittorio's book: http://www.amazon.com/Programming-Windows%C2%AE-Identity-Foundation-Dev/dp/0735627185
There are some details here: http://msdn.microsoft.com/en-us/library/ff359114.aspx
Another good way of learning is by looking at the extensions built to handle non-SAML tokens (e.g SWT). Download the samples here and look for the REST services.
The ADFS 2 sounds like a perfect choice for you. It is a free subsystem implementing the WS-Federation SSO protocol. The protocol itself is a standard from the WS-* family which means that you can easily find toolkits to support authentication in any client technology (.NET, PHP, Java).
Technically, ADFS 2 is a web application running on IIS 7.5/Windows Server 2008 and uses Active Directory as a backend.
There are good books on the WS-Federation protocol programming:
Claims Based Identity and Access Control (free ebook)
Programming Windows Identity Foundation
I would argue you shouldn't care :-), but we are curious, aren't we? And there's value in knowing how things actually work.
The validation happens on the app with no contact with the STS (e.g. ADFS), that's because in general, the token is digitally signed (and optionally encrypted) and WIF has all the information and means to check the integrity of it.
A great source of WIF internals can be found in Vittorio's book:
There's a lot of information on how all the modules interact and work.
Well, it could be that one of passive single sign-on protocols could be your choice. You can choose between the WS-Federation, SAML protocol or Shibboleth but the first one, WS-Federation is easily supported on .NET with the Windows Indentity Foundation subsystem.
The way WS-Federation works is that it you externalize the authentication/authorization to a separate web application (so called Security Token Service). Each of federated client applications (so called Relying Parties) rely on the information provided by the service.
The basic control flows is like this:
WIF gives you tools to build both STSes and RPs easily and integration of legacy application is also simple - you can either make an effort to handle the protocol at the legacy application level or provide a "brige", a .NET application using WIF which relies on STS and passes the auth information to the legacy application.
What is also great is that with WIF you still stick with old, good notions like Forms Authentication and Membership Providers - it could be a preferred choice of STS implementation.
The WS-Federation protocol itself not only provides the single sign-on but also lets you easily handle single sign off (which is not supported by some other protocols like openid).
Read more on the topic in this book:
If you want Windows Live or Google logins, you need to look at integrating WIF with Azure ACS.
Refer Access Control Service Samples and Documentation.
Also see the how-to's etc. in the TechNet Wiki Windows Identity Foundation (WIF) and Azure AppFabric Access Control Service (ACS) Content Map and Windows Identity Foundation (WIF) Content Map.