[POC/Draft] Add FastAPI SecurityBase-based authentication switch to Saleor's offline JWT (JWK) verification

[pkucmus]

Why the change

Schema documentation

FastAPI being tied to OAS should have apps built with it describing the API appropriately. The previous usage of simple deps was not leveraging the securityScheme definition, now it does.
Ref: https://swagger.io/docs/specification/authentication/api-keys/#multiple

Precise authentication

More importantly, the proposed change reflects the truth more accurately. A Saleor app on every call does multiple authentication checks, at the very least it authenticates a Saleor instance (SaleorDomainSecurity) then it validates the requestor either with SaleorUserAuthSecurity for Dashboard users or with SaleorWebhookSecurity when validating the source of a webhook event. The two latter ones are always dependent on domain authentication hence the dependency - this means we have endpoints secured with:

• Saleor Domain Validation
• Saleor Domain Validation AND Saleor User Authentication
• Saleor Domain Validation AND Saleor Webhook Signature Verification
  (the AND is important here)

The auto_error logic is important as it allows to wrap the security methods with an additional layer in case there will be an endpoint with a OR security like

(Saleor Domain Validation **AND** Saleor Webhook Signature Verification) 
OR 
(Saleor Domain Validation **AND** Shared Secret Authentication)

in that case one might want to create something like the following:

saleor_auth = SaleorUserAuthSecurity(auto_error=False)
shared_secret_auth = SharedSecretAuth(auto_error=False)

async def my_authentication(
    saleor_principal: SaleorPrincipal = Security(saleor_auth),
    principal: Principal = Security(shared_secret_auth),
):
    if saleor_principal:
        return saleor_principal
    elif principal:
        return principal
    raise HTTPException(
        status_code=HTTP_401_UNAUTHORIZED,
        detail=f"Provided domain {saleor} is invalid.",
    )

Caveat: FastAPI does not have the ability to fully support what is described here - fastapi/fastapi#2835 - a user will need to rely on the verbosity of the errors when there is AND authentication despite the schema describing it being an OR

To do:

• fix docs
• fix unit tests
• unify the Principal (SaleorPrincipal) I don't want to have special logic in handlers that would need to recognize the type of the principal - one representation should be enough

[piotrgrundas]

If this is a sample app for the wider audience I would add a comment here on why this IP is here and how to handle it for mac users.

[piotrgrundas]

Why u need to unpack it?

[pkucmus]

in being a Python keyword, can't be used as an argument, that's how they defined the args there

[piotrgrundas]

But correct me if I'm wrong - it does not matter if u use it as an fn keyword argument, right? Ur not shadowing anything

[piotrgrundas]

Ditto.

[piotrgrundas]

Can we be consistent across errors?

Suggested change

	detail=f"Missing {SALEOR_TOKEN_HEADER.upper()} header.",
	detail=f"Missing token {SALEOR_TOKEN_HEADER.upper()} header.",

Maybe create a custom exception class that would be consistent with generating error messages?

[pkucmus]

We could do that to allow some control over the error payload of a service which would be good but might the detrimental - now if an app does not care about a custom payload you do not need to do anything. If it does want to hide this default and use a different error schema it would be a matter of making an error handler for HTTPException.
If we went for a custom exception here we would force the user to create a custom error handler every time.

[koradon]

It looks ok for me but the CI is not passing and there are no tests really for the new things. I would like to see unit tests for the new Security classes.
Also, I can't see any test that uses saleor_user_auth_security.

If we are already here I would rename samples to examples. It is more descriptive.

[pkucmus]

@koradon I'll do all that once we approve and agree that this PoC is the way to go