The picture above shows the AD client recently added to the ASP.NET “component” in dotnetopenauth open source project. One sees, by default, that this provider is set up to protect the graph API endpoint (the “resource”).
We see that the endpoint supports the websso-friendly authorization code grant type:
We see that the token endpoint has a few quirks:
and we see that the provider client retains the tenant ID and the user OID in instance variables.
One notes how the cert handling fails to conform to PKIX…and one notes the imposition of SHA256.
We see now handling of the refresh token (assuming there is one). We also see no evidence of “id tokens” either.
Now, what we do NOT see is how the provider and SID variables would be handled on the redirect from the authorization endpoint (since proper use of the OAUTH2 state mechanism is not in evidence). Evidently, the service principals redirect is not configured to go back to the ASP.NET template’s ExternalLogin page but to the AbsoluteUri of the page hosting the requestAuthorization handler (normally login.aspx). This will be interesting to track, to see how it was done PROPERLY. Login must maintain state somehow (and presumably it will be via viewstate).
We also see the article at http://www.cloudidentity.com/blog/2013/04/29/fun-with-windows-azure-ad-calling-rest-services-from-a-windows-phone-8-app/ that also consumes the (Azure AD OAUTH2) endpoints directly, too. The latter looks like the next thing to emulate, if only because I can now so trivially swap out the native use of Azure AD endpoints and substitute my own (which happen to delegate to Azure ACS’s OAUTH2 endpoint “support”).