step 1, use visual studio 2013 and make a web project. Its wizard now gives a wizard able to construct web.config files (and supporting classes) suited to talking to “organizational” IDPs – including those that cooperate with others to offer a “multi-organization” cloud identity concept. This is that which aims to control the signup process to applications on devices controlled by parties OTHER than the IDP. The local administrator authorizes certain IDPs to expose their API (and grant delegated access to those APIs to the API-consuming devices).
In our case, the websso process concluded with
This is after, the following websso handshake(s) steps (since a IDP for the authentication statement has already issued a web session to visual studio)
Retrieve IP-STS metadata, given verified domain identity. This is not from our STS (but from the intermediate IP-STS that proxies to our STS).
we see an oauth handshake, next:
so logically having discovered the oauth endpoint from the federationmetadata, visual studio appears to talk to it. First, a uri with oauth2 querystring is issued, which returns a URN in a redirect. Presumably, this is captured by the visual studio process and recognized, such that it then issues the followup URI with querystring (showing knowledge of the authorization code). Of course, we are seeing the classical authorization step followed by token issuing step.
The token response is interesting, showing an id_token:
Next see the process use the directory API (a graph API, recall):
atom feed of “user” class object
citing access token, ey…
when we look at the id token we see:
While I don’t quite understand the last char (encoding bug??), we do see an unsigned assertion being presented BEFORE one goes and calls the graph API and walks its entity tree