[Feature request ] OBO for service principals for 3p (was Getting error code 7000114 Application '{appIdentifier}' is not allowed to make application on-behalf-of calls)

[pwlodek]

Which Version of MSAL are you using ? MSAL 4.21

Platform netcore

What authentication flow has the issue?

• Desktop / Mobile
  • [ ] Interactive
  • [ ] Integrated Windows Auth
  • [ ] Username Password
  • [ ] Device code flow (browserless)
  • [x] Client Credential Flow
• Web App
  • [ ] Authorization code
  • [ ] OBO
• Web API
  • [x] OBO

Description:

I have a daemon app that authenticates to Azure AD to call web api. This is achieved with Client Credential flow. Daemon app gets a JWT to call the Web API. The web api needs to call another Azure Service - Data Lake. I want to use OBO Flow inside Web API, and it fails.

Really trying to use this: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow But the initial call to the middle tier is not done by the user, it is done by the Daemon app using Client credentials flow.

Expected behavior JWT Token is returned.

Actual behavior Error is returned:

{ "error": "unauthorized_client", "error_description": "AADSTS7000114: Application '{appid}' is not allowed to make application on-behalf-of calls.\r\nTrace ID: edd4d517-bfc9-4363-bfc2-84539c296d00\r\nCorrelation ID: 07321853-3ad1-4a0f-aac4-1755fe184cd7\r\nTimestamp: 2020-10-22 10:03:57Z", "error_codes": [ 7000114 ], "timestamp": "2020-10-22 10:03:57Z", "trace_id": "edd4d517-bfc9-4363-bfc2-84539c296d00", "correlation_id": "07321853-3ad1-4a0f-aac4-1755fe184cd7", "error_uri": "https://login.microsoftonline.com/error?code=7000114" }

What kind of configuration is required on Azure AD to make this scenario work?

[bgavrilMS]

As far as I know, MSAL does not support OBO for app-to-app tokens, only client-to-app tokens. I am not sure if AAD even allows this.

Why can't you just get a token directly for Data Lake?

CC @jmprieur who's been looking at this scenario.

[jmprieur]

No AAD doesn't support it for 3P apps.

[pwlodek]

@bgavrilMS client-to-app token meaning the users is requesting access not a daemon? Tbh, what difference does it make? Both a user and app (Azure AD app registration) are registered in AD, so why it would work for a "human" user but not the app? Both are valid identities.

The daemon app that wants to talk to the Web API has certain permissions in the data lake (using ACL). The daemon app has clientId and client secret, but the Web API doesnt have these credentials right? I dont want to expose these credentials to the Web API. The main reason is that I have 8 daemon apps connecting to the lake, each with different permissions. That is why I wanted the daemon identity to flow into web api.

Would there be any valid explanation why this would work for "human" users but not "background apps"?

[pwlodek]

And correct this is not really MSAL bug, when I do OAuth2 HTTP Post to Azure AD it also doesnt work. Im just looking for some assistance here. The documentation doesnt mention for what type of client auth flow OBO works.

[jmprieur]

cc: @hspin and @yordan-msft for the scenario.

[ErikMogensen]

I created a feature request for this, https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/41768716-support-the-on-behalf-of-flow-for-tokens-gotten-th.

[jmprieur]

@hpsin FYI

[hpsin]

Thanks @jmprieur . This is something we're reasoning over. The hard part here is that it means something slightly different to everyone, so I really appreciate laying out the expectations in your request @ErikMogensen .

What I'm seeing is that SP A calls SP B, then SP B OBOs the token to call SP C.

The token in the second leg would look like:

oid: A
sub: A
appid: B // This is the app making the call
roles: Roles of A on C
scp: Delegated permissions of B on C // Namely, this is what (of the roles A has) B is allowed to do on behalf of A
original_appid: A

Is that about what you'd expect, and would it satisfy your requirements?

In this scenario, with DataLake as C, DataLake would have to update to understand what the scopes mean, since role-only checks would grant B too much permission. At the same time, B is not intended to call C directly - it would not have any roles, possibly, is that right @pwlodek?

[bgavrilMS]

Since this is a request for the service, let's continue to track it there:

~https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/41768716-support-the-on-behalf-of-flow-for-tokens-gotten-th.~ (dead link)

[kierenj]

I'm interested in this feature, but the forum link is broken. Has it moved? Thanks.

[bgavrilMS]

OBO for service principals is currently only available to a few Microsoft internal services. This is a service limitation. There are a lot of security contraints that go into OBO for Service principals, and so this is not a trivial feature to add.

As an alternative, you can try to use client_credentials.

[kierenj]

No problem - thanks for the update/info. I found that giving the app registration for my client app, access to the enterprise application for my target app - made the roles appear in the access token, which solves my use case.

Sent from my iPhone

On 25 Jul 2022, at 14:04, Bogdan Gavril @.***> wrote:

 OBO for service principals is currently only available to a few Microsoft internal services. This is a service limitation. There are a lot of security contraints that go into OBO for Service principals, and so this is not a trivial feature to add.

As an alternative, you can try to use client_credentials.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[bgavrilMS]

This has been fixed in recent versions of MSAL, e.g. 4.49.1; This feature is not available to 3rd parties because setting up this flow requires special configuration which is done manually by ESTS engineers.

[emil-eklund]

Is this something that you are tracking somewhere, or will it never be available to developers? It sounds like you see the need as you've implemented it internally.

We'd really like to see this feature available as it is very important to our micro-service architecture. Without it, we would be forced to duplicate a lot of integrity checks in our system.

Here is a fictional example:

A daemon detects a fault and reports it to a ticketing system. The ticketing system calls a project management API on behalf of the daemon to ensure the project the fault occurred in is active before creating the ticket.

The workaround is simple; let the daemon check by itself. But this would duplicate the validation logic. Additionally, it would require a separate endpoint to be created. CreateTicketWithoutValidation which makes my engineering eyes bleed. 😟

[bgavrilMS]

It's a valid scenario.

OBO for Service Principal is on the roadmap, but not on the horizon. Provisioning it all is pretty complex and token validation / authZ for this flow is hard to get right.

Please open a feature request, this one has too much history.

[waelmas]

The feature request link here seems invalid, yet this issue is closed even if multiple people have a usecase for such feature..

[bgavrilMS]

Agreed, let's keep this issue open for tracking.

[sjkp]

Please make this available, even though a lot of Microsoft APIs might not work with SP OBO flows initially, there's imo not really any reason to have this artificial blocker in place for those of us that want to use it for APIs we operate ourselves.

Another very valid use case is to access MS Graph as delegated "application client". There are some permisisons in MS graph where this would be really beneficial.