The MIcrosoft work on the “ADAL” library is more than perhaps it seems at first glance (a generalized API to several oauth flows, for clients, servers, deamons, etc etc).
First, recognize that it has within support for name-based discovery of authorities – when an API that fails to process a token responds with an error message – identifying a domain name of an authority s willing to accept tokens from.
Second, since anyone can send any domain name to which the client nominally now sends oauth messages, the client needs to “validated” the adress – to ensure it meets the “form requirements”. In general this means having login…microsoft… in the domain name (or the US government or Chinese cloud equivalens) ensuring that only officially-named (and SSL certified) azure cloud endpoints are valid. Of course, one can also register ones own forms (so CNAMES work, too).
Next, we should recognize that client certs are not dead – in the sense that such as windows 8.1 phone come with VPNs (both ipsec and sslvpn) that can present client certificates using EAP-TLS handshakes. This is all part of the world in which certain apps are bound to the VPN, and its client-cert authenticated tunnel. THUS THE TUNNEL can act as the oauth authenticator..
Finally, a family of apps – sharing a VPN tunnel – can share a token and cookie-for-the-IDP caches (on such as the windows phone) when using the windows store SID-ID as athe logical name of the client.