A very long time ago (like a few months), we learned about OAUTH as a protocol to talk to authentication IDPs. We wrote dotnetopenauth plugins to talk to wordpress (as an IDP) and then PingFederate (as a proxying IDP to websso partners). Since then, we have emulated PingFederate’s optional Authorization Server feature, using a Azure ACS namespace as the backend service. Today, we updated our OAUTH2 provider for ASP.NET – enabling a standard dotnetopenauth-aware web site built from the Visual Studio wizard to consume the various assertions, user credentials, and the “directory graph access points”. Of course, this all really just means we obtained an access token having logged onto Google, which gave us access to the token verification API, which duly unpacked the JWT issued by ACS .. .delivering “attributes” to the SP site – which then implemented an account linking experience.
So as to do NOTHING but add the plugin to the assertion-consuming web project built by the wizard, we altered our AS to be maximally flexible when interworking. (It is thus somewhat insecure, relatively, on the topic of redirect URIs, state management, and the like.)
Of course, we should now change the name of our plugin – to be “PingFederate-emulation (via Azure ACS)”.
So we are now using OAUTH for authentication, which is not what its for. But its what everyone does with OAUTH. So… so do we.