WELCOME TO CLOUD MATTER

Search
  • Roman Guoussev-Donskoi

Experience with OAuth 2.0 On-Behalf-Of flow

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 :)







1,228 views0 comments

Recent Posts

See All

Databricks is an amazing platform for data engineering, data science and machine learning. One of the critical requirements of secure data processing is data audit - the ability to identity what data

SAS access to storage account is very convenient and easy and while Microsoft recommends that you use Azure AD credentials when possible as security best practice still SAS sometimes hard to avoid. Le

 

Subscribe

 

CONTACT

Your details were sent successfully!

Computers