Add OBO middleware [Feature request]

[lassebass]

trafficstars

Describe the feature you'd like It would be nice to have the framework allow more than one API scope. The case where this is needed, is if you have multiple business applications that need access to the same API. (For example like how both Teams and Outlook has access to your calendar). Features like this is supported in .NET frameworks by making a list of valid isuers and audiences, instead of enforcing just one (see this StackOverflow example for how the .NET AddJwtBearer middleware works)

The "correct way" of dealing with these cases is to add middleware implementing the OBO ("On-Behalf-Of") flow. Usually this is handled by the client, but for third party applications and/or plugins, we cannot initiate OBO client-side.

Additional context If I supply an access token with an audience that I've added to the my application's knownClientApplications list, the token validation should pass.

[h3rmanj]

I'm not sure I understand this question.

The audience of the access token is the application's clientId, not the consumers clientId. You shouldn't have to add an application to it's own knownClientApplications list. The consumers clientId is not validated in this package (and isn't in .NET by default either), so who can create access tokens to your application is dependent of what the issuer allows.

Application that isn't multi-tenant but still has separate app registrations in different tenants something that could be implemented though, but I'm not sure that's what you're asking.

[lassebass]

We have multiple App Registrations set up for authentication over many different applications in our Azure portfolio. The feature I'm looking for, is the option to allow fastapi_azure_auth to accept tokens issued to any one of these app registrations, not just one specific one.

That way, as long as you are logged into any one of our app registrations, you can access the Web API.

With the current setup, fastapi_azure_auth only allows one app_client_id in a SingleTenantAzureAuthorizationCodeBearer. A consequence of this is that the API will only accept tokens that are logged into that single app registration.

I.e. expand this

azure_scheme = SingleTenantAzureAuthorizationCodeBearer(
    app_client_id="00001111-2222-3333-4444-555566667777",
    tenant_id="88889999-aaaa-bbbb-cccc-ddddeeeeffff",
    scopes={
        "api://00001111-2222-3333-4444-5555666667777/.default"
    }

to something like

azure_scheme = SingleTenantAzureAuthorizationCodeBearer(
    app_client_ids=[
        "00001111-2222-3333-4444-555566667777",
        "00001111-2222-3333-4444-555566667778",
        ...
    ],
    tenant_id="88889999-aaaa-bbbb-cccc-ddddeeeeffff",
    scopes={
        "api://00001111-2222-3333-4444-5555666667777/.default",
        "api://00001111-2222-3333-4444-5555666667778/.default",
        ...
    }

which will allow API access to tokens with aud 00001111-2222-3333-4444-555566667777 or 00001111-2222-3333-4444-555566667778

[h3rmanj]

I'm still unsure as to why you would want to accept access tokens issued to another application. If the consumers have been granted the scopes to the API in Azure, they should have no problems requesting tokens to the API without any additional configuration in the API.

[JonasKs]

Sorry, I’ve been away so didn’t have time to look into this.

I’m also struggling to understand the use case here.

The feature I'm looking for, is the option to allow fastapi_azure_auth to accept tokens issued to any one of these app registrations, not just one specific one.

Can you give me some specific examples of a setup here? Or Microsoft documentation?
Seems to me that your application should just fetch multiple tokens.

[fossmark]

The reason why this could be a nice feature is that if you want to integrate with a third party software which you do not develop and have control over .

I agree that it would be more correct to use the On-Behalf-Of flow and fetch a new token which has the expected audience - but as a practical and pragmatic solution it would be nice to have a feature that allows use to specify multiple audiences.

In the possible to specify multiple audience in for example Dotnet Core using the TokenValidationParameters class so I do not think this is a very specific and limited use case.

https://docs.microsoft.com/en-us/dotnet/api/microsoft.identitymodel.tokens.tokenvalidationparameters.validaudiences?view=azure-dotnet#microsoft-identitymodel-tokens-tokenvalidationparameters-validaudiences

This discussion on Stackoverflow may also give some useful information:

https://stackoverflow.com/questions/46990509/how-to-set-multiple-audiences-in-asp-net-core-2-0-addjwtbearer-middleware

[JonasKs]

Who will be the issuer of these tokens? Your tenant or a generic Microsoft tenant (making it multi-tenant)? As far as I can see, the only parameter that we need to support a list for is the audience.

Since we don't actually manually pass in audience, I think this could be an audience: list[str] | None = None parameter. This way we don't have to change any documentation or have any breaking changes, but one could manually pass in audience if one wants to.
In other words, this should be audience or client_id if token_version == 2 else f'api://{client_id}'... Unfortunately, I checked python-jose, and it does not support a list of audiences. In other words, we'd have to do audience verification manually, or (preferabily) try to implement this in python-jose.

[JonasKs]

https://github.com/mpdavis/python-jose/issues/302

[JonasKs]

Closing. PRs welcome, but I do not intend to implement this without python-jose request getting approved.