Florenz A.P. Hollebrandse

### Implementation options 1. Do nothing. App developers can pass in headers manually as and when required. Or alternatively they could subclass ~~`ClientSession`~~ or `ClientRequest` (`ClientSession` is marked as "final"...

My personal preference would be towards option 3. It’s simple, clean and would feel very familiar for people coming from “requests” lib.

@Dreamsorcerer and maintainers, I welcome feedback on this.

I created draft PR #6954 just to test out how the existing `BasicAuth` functionality could be generalized.

Just picking up some feedback from @webknjaz here: https://github.com/aio-libs/aiohttp/pull/6954#discussion_r978097919 (thanks!) Personally, I don't feel adding an auth handler base class adds that much if the contract really is that it...

For illustration, the expected usage is something like this: ```python async def my_auth(request: ClientRequest) -> None: token = await token_from_cache() if not token: token = await generate_token() request.headers["Authorization"] = f"Bearer...

@Dreamsorcerer thanks! Let me separate this out into a few distinct decision points below

### Auth-specific vs generic middleware/hook This is really options 2-4 vs option 5 in https://github.com/aio-libs/aiohttp/issues/6915#issuecomment-1249168494. I don't have a strong preference for either approach. Some advantages for doing something auth-specific:...

### Client session property vs request property I agree that in many case, one would set an auth handler on the session. However, the auth handler is in reality a...

### Background token refresh vs on-send function call In a typical token expiring case, one could rotate the auth header using a background task. But I think it would involve...