So never forget, for my critical tone, I'm in admiration for microsoft having actually built out what is essentially the secure X.500 directory concept. Directory as in "application platform" - that is. THAT WAS the original idea (30 years ahead of its time). its greate that the signed JWT plays much the same role as a signed directory read token, to be sent to a network of agents (over inter-agent secure chaining).
I think my mental model is getting straighter concerning JWTs, protocols, interoperability, and profiling. All several variants.
There is ADAL 2, that talks openid connect version of oauth. This gets id tokens, and access tokens for APIs hosted by IDPs and third parties alike. In particular, one gets the directory port itself. This drives sharepoint apps hosted in a webapp process, and allows directory-based features such as people pickers via directory-enabled HTML controls. It also enables the webapp to consume sharepoint APIs.
There is owin-based visual studio 2013 era middleware, for webapps clients and webapp-hosted webAPIs, and the like of sharepoint apps, as above. The various middlewares can talk to AD, ACS, and use ADAL2 above to talk to openid connect services of Azure AD.
There is ADAL 1, for XAML apps, that should be thought of as talking to ACS's oauth endpoints, only. While a websso dialog occurs with several IDPs configured in ACS, only an access token is granted. There is no id token.
Then there are web authentication broker in windows 8 land, that talks directly to the oauth endpoints of Google et al. It doesnt seem to talk to ACS or AAD.
There there is the ADAL 1/2 alternative in windows 8.1 app land, that does talk to ACS and AAD (but not to Google et al).
There are hints that AAD and ACS may merge, undoing the previous constraint as Google and Microsoft (and others) use the openid connect discovery mechanisms to let MicrosoftOnline and AAD integrate with more than ws-fedp IDPs in certified domains.
Then, there is the visual studio 2012 era webapps and todays webmatrix samples, that use dotnetopenauth - to talk directly to Google, Yahoo, Twitter oauth2/oauth1 endpoints. (Only via this route did I ever manage to program a plugin that could also talk to the oauth2 endpoints of Ping Identity oauth server!)
The old concept of a visual studio 2012 era "oauth2 provider" class seems to now have become an visual studio 2013 era OWIN middleware provider. it tunes up the protocols for the vendor perculiarties (like ADFS and is oauth2 weirdisms)
Then there is the visual studio 2010 era notion of WIF, using ASP.NET modules as middleware. These have recently been owin-ised. Thus you can talk to an JWT-issuing IDP over ws-fedp to get an X (but note that X is not an id token obtained from using openid-connect middleware).
One such ws-fedp IDP is ACS, acting as an FP, and fronting google and ADFS using protocol relaying or gatewaying to the likes of Facebook. The X obtained by this route may contain access tokens in claims (but these seems like a disreputable practice, now out of date)
Then there is WCF 4.5, which should be thought of as a ws-security platform (ignoring webhttpbinding). One injects the likes of X into the client proxy, wrapping it as a binary security token. This pops out the other server in the JWTSecurityTOken handler, which you have to subclass, to set the validation parameters in the validate token method. (Or can one use per securitytoken handler config?)
Then there is servicebus, for which you have to use ACS to get tokens, so that the ws* soap flows are Managed. Whether the SWT tokens will become JWTs is not clear.
The point of service bus and ws-* soapy interfaces is to act as "legacy" back-backend for webAPIs hosted in azure mobile service "backends" - that offer pure REST models of webAPI-dom. The service bus MAY REMOTELY enforce ws2007httpfederation bindings at its message acceptance endpoint. Its to be determined if it would validate a JWT (and how).
Then, there is multi-tenant plumbing, which seems to come down in webapp land to a validation concept (where the webapp is a set of resources requiring authentication, rather than webapp UI talking to WebAPIs). One sees samples with a WIF pipeline installed issuernameregistry that stores keys/names in a db, as multi-tenant signup occurs, leveraging the modern consent flow of openid connect.
Then, there MAY be an owin version of the above concept for validating tokens AND managing multi-tenant trust stores, discarding the XML approach to config (that seems to going out of vogue and heading for ASN.1s fate). Rather than think of XML as script way of making artifacts, now one just scripts ...them.
Underneath, it all still hinges on X.509 certs, and windows trust stores - which dont seem to have joined the modern world yet. In some cases, ws* in particular, you can hit OCSP servers to address revocation and compromise of keying material.
In the JWT world, unlike SAML/ws*, a few bytes on the wire are saved by NOT attaching the keying material. This may be being address by openid connect discovery (but things are not clear). The latter seems to hinge on DNSSEC for authority keying (and kerberos like revocation/comrpomise handling), supporting a profile of https tuned up for using the web itself as a giant cert store for endpoint keying material.
Its a COMPLICATED STORY.
And it doesnt look finished. So Im a little wary!