{"id":5801,"date":"2019-08-04T03:03:11","date_gmt":"2019-08-04T03:03:11","guid":{"rendered":"https:\/\/blogs.aaddevsup.xyz\/?p=5801"},"modified":"2020-08-07T18:29:13","modified_gmt":"2020-08-07T18:29:13","slug":"understanding-azure-ads-on-behalf-of-flow-aka-obo-flow","status":"publish","type":"post","link":"https:\/\/blogs.aaddevsup.xyz\/2019\/08\/understanding-azure-ads-on-behalf-of-flow-aka-obo-flow\/","title":{"rendered":"Understanding Azure AD\u2019s On-Behalf-Of flow (aka OBO flow)"},"content":{"rendered":"

Background<\/h1>\n

Microsoft Azure Active Directory supports an OAuth2 protocol extension<\/a> called On-Behalf-Of flow (OBO flow). This is documented at both the Microsoft Identity Platform V1<\/a> and V2<\/a> endpoint. The OBO flow is used in the following scenario. Both Web API 1 and Web API 2 are protected by Azure AD.<\/p>\n

\"\"<\/p>\n

    \n
  1. A client application (could be a SPA app, a front-end Web Application, or a native application) signs a user into Azure AD and request a delegated access token for Web API 1<\/li>\n
  2. Client application then calls Web API 1 with the issued access token<\/li>\n
  3. Web API 1 in turn needs to call a downstream Web API 2 so it uses its access token (in step 2 above) to request an access token for Web API 2. What happens in this step is that Web API 1 uses the OBO flow to exchange its access token for another resource’s access token. The exchanged token is still issued on behalf of the original sign in user and it has delegated permission.<\/li>\n
  4. Web API 1 uses the new access token to call Web API 2<\/li>\n<\/ol>\n

    Let’s look at the parameters used in an OBO flow at the V1 endpoint below. I want to call out a few highlighted<\/span> parameters as their significance will become more obvious a little bit later.<\/p>\n

    assertion:<\/strong>
    \n<\/span>this is the access token issued in step 2 above<\/p>\n

    client_id:<\/strong>
    \n<\/span>application id of Web API 1<\/p>\n

    Resource:<\/strong>
    \n<\/span>this is Application ID URI or Application ID of Web API 2<\/p>\n

    \"\"<\/p>\n

    Let’s look at an OBO end to end traffic in Fiddler<\/a>:<\/p>\n

    Frame 1 \u2013 14 below shows the user navigates to the web site and is redirected to Azure AD to log in. Frame 15 is the request to the token endpoint to get an access token for Web API 1<\/p>\n

    Hover over image to enlarge<\/em><\/span><\/p>\n

    \"\"<\/div>\n

    In this example Web API 2 is Microsoft Graph. In frame 19 below Web API 1 uses an OBO flow to request a token for Microsoft Graph. It uses the access token received in frame 15 as the assertion parameter.<\/p>\n

    Hover over image to enlarge<\/span><\/em><\/p>\n

    \"\"<\/div>\n

    It is extremely important to use the correct parameter in the OBO flow. Note that the OBO parameters client_id <\/strong><\/span>and the assertion<\/strong><\/span> (access token) are for the calling application (Web API 1) in this token exchange request.<\/p>\n

    Common pitfall customers run into when using the OBO flow<\/h1>\n

    I have seen a few AADSTS error returned for this flow when either the client_id <\/strong><\/span>or the assertion<\/strong><\/span> parameters used are not for the calling application (Web API 1). Below are a few examples:<\/p>\n

    HTTP 400 error: AADSTS500131: Assertion audience does not match the Client app presenting the assertion. The audience in the assertion was ‘00000002-0000-0000-c000-000000000000’ and the expected audience is \u2026<\/strong><\/span><\/p>\n

    Root cause: The access token used in the assertion is for a different application \/ resource instead of for the calling app Web API 1. The GUID in this error is an Azure AD Graph resource.
    \n<\/em><\/span><\/p>\n

    HTTP 400 error: AADSTS50013: Assertion failed signature validation. [Reason – The provided signature value did not match the expected signature value., Thumbprint of key used by client:\u2026<\/strong><\/span><\/p>\n

    Root cause: The access token used in the assertion is for Microsoft Graph resource (https:\/\/graph.microsoft.com<\/a>)
    \n<\/em><\/span><\/p>\n

    HTTP 400 error: AADSTS50013: Assertion failed signature validation. [Reason – The key was not found., Thumbprint of key used by client: ‘B25930C…..<\/span><\/strong>
    \nRoot cause: Web API 1 is a SAML Application (check the Enterprise Application blade to see if Single sign-on is enabled and there is a SAML signing Certificate attached)<\/span>.<\/em><\/span><\/p>\n

    HTTP 500 error: AADSTS50000: There was an error issuing a token.<\/strong><\/span><\/p>\n

    Root cause: the client id used is either not valid or does not exist in the tenant.
    \n<\/em><\/span><\/p>\n

    How can I diagnose this issue?<\/h1>\n