As per Microsoft documentation Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow: "The OAuth 2.0 On-Behalf-Of flow (OBO) serves the use case where an application invokes a service/web API, which in turn needs to call another service/web API. The idea is to propagate the delegated user identity and permissions through the request chain."
The diagram below outlines this scenario and details available in Microsoft documentation.
This flow can be useful in some scenarios yet relying on propagating user identity in enterprise environment can make things complex (with many layers of distributed applications calling each other to fulfil the task and not all of them may be capable propagate user identity).
The constrains as documented can also add complexity "The OBO flow only works for user principals at this time. A service principal cannot request an app-only token, send it to an API, and have that API exchange that for another token that represents that original service principal. "
One of the APIs we have been integrating with required use of this capability which by itself worked perfectly (from reading the flow documentation to tested end-to-end demo took about an hour). Postman and Azure App Service authentication saved much time and no coding was needed for initial testing :)
Integrating with actual API took somewhat more effort as at this moment there does not seem to be an easy way ensure all token validations performed by the back-end API are precisely and completely documented. At least not to the extent of my knowledge - maybe one day will learn :).
Below are the steps we took (hopefully will help someone following the same path)
First we have setup 2 app services in Azure and made sure AppB is configured Azure Active Directory Authentication
In Azure Active Directory we have exposed an API with access_as_user scope on the application registration AppB. The actual API we needed to access was setup the same way
And granted app registration of AppA access to AppB API
We also created an API with user_impersonation scope in app registration AppA for acquiring AppA token
Then we used Postman Azure AD v2.0 Protocols collection (Authorization Code Flow) to test
It is easy to prepare authorize request in Postman
Then submit authorize request using your browser with Developer Tools tracking network communications. This will return us the code we will use to acquire token
Then use the code to get the token for AppA user_impersonation scope as per usual Authorization Code Flow
Then with App A clientID and secret we use AppA token to get the AppB token. (We pass the previous AppA token as "assertion" below
Now we call AppB URL with the new token and get the required data
Initially our calls were returning 403 Forbidden. After some investigation it has occurred that backend API was relying on Application roles granted to users like below:
This information would be reflected like below in AppB access token:
Once this and other validations were accommodated everything worked as expected.
The questions remains what to do with applications that need to call API and can not pass user identity. But this is for another day :)
