In the last post, we noted how one configures the api manager in azure to communicate with the AAD authorization server for the purpose of enabling developers to logon to the api developer site using their federated credentials. Of course, behind the scenes one is simply configuring the site to talk to AAD using oauth2 – as augmented for multi-tenant access by Microsoft.
In this post, we configure another aspect of api management: oauth2 authorization servers for the purpose of supporting authenticated API requests. That is, the api client and authorization server will communicate to get access tokens that are then attached to the request. The additional authorization headers in the request is processed by the server as an access token, as normal.
we guess at the right parameters and then move on to configure the AAD application so that we obtain the missing clientid/secretkey values.
moving to AAD application configuration…
we enabled all app and delegation permissions (not knowing any better)
Now we arm the api endpoints to demand the access token and interact with an authorization server, such as that configured above. Using the API screen, in the management console:
To test the setup, we follow the instructions and user the developer portal, to invoke a client of the my echo API:
selecting authentication code induces display of the websso experience at the authorization server (which is good!)
once we fix a bug or two, we can continue this to completion.
note the audience fields (doesn’t feel right!)
note how the wtrealm field (provided by azure’s initiator) becomes confused in the IDP: