-
Notifications
You must be signed in to change notification settings - Fork 79
Description
Describe the feature you'd like
Exposing 'auto_error' from OAuth2AuthorizationCodeBearer and implementing auto_error in 'AzureAuthorizationCodeBearerBase.call'.
This will allow having other SecurityBases along side this package.
Additional context
This allows having both AzureAD authentication(Bearer) and X-Api-Key authorization for the backend API.
If a system is broken up into 2 separate systems (UI and API), the UI would connect to the API via Bearer, where other applications would connect to the API via X-Api-Key.
The current problem is that fastapi-azure-auth throws exceptions if the Bearer token isn't available in the request. 'auto_error' standard allows the developer to decide if it should throw the Exception or handle it with another check/Depends on the API Endpoint.
azure_scheme = SingleTenantAzureAuthorizationCodeBearer( app_client_id=settings.APP_CLIENT_ID, tenant_id=settings.TENANT_ID, scopes={ f'api://{settings.APP_CLIENT_ID}/user_impersonation': 'user_impersonation', }, auto_error=False )
identity_auth = IdentityToken(auto_error=False)
`def check(os_auth: Optional[IdentityUser] = Depends(identity_auth),
azure_auth: Optional[SingleTenantAzureAuthorizationCodeBearer] = Depends(azure_scheme)) -> bool:
if os_auth is not None:
return os_auth
if azure_auth is not None:
return azure_auth
raise HTTPException(status_code=401, detail="No Authorization method provided")
@app.get("/both", dependencies=[Depends(check)])
async def both():
return {
"status": "OK"
}`
This both handles both authentication methods, along with properly updating swagger to allow one or both authentication methods. 'check' would allow others to define which order they deem fit.
(PR incoming)
-Brian Metzler