What cookie(s) should a client request include to authenticate it?

[dsaghliani]

Sorry about the newbie question. It's my first time writing auth.

When a user is logged in on the server, it should respond with the data necessary for authentication, right? Data that should be stored on the client as a cookie so that it's attached with every subsequent request.

Since axum-login uses tower_http's RequireAuthorizationLayer, I assume it checks the Authorization header, as it says in the docs. But what value should I assign that?

Looking at axum-login's source code, I see that it attempts to fetch the Option<User> extension in the request, where User: AuthUser<Role>.

impl<User, ReqBody, ResBody, Role> AuthorizeRequest<ReqBody> for Login<User, ResBody, Role>
where
    Role: PartialOrd + PartialEq + Clone + Send + Sync + 'static,
    User: AuthUser<Role>,
    ResBody: HttpBody + Default,
{
    type ResponseBody = ResBody;

    fn authorize(
        &mut self,
        request: &mut Request<ReqBody>,
    ) -> Result<(), Response<Self::ResponseBody>> {
        let user = request
            .extensions()
            .get::<Option<User>>()
            .expect("Auth extension missing. Is the auth layer installed?");

        match user {
            Some(user) if self.role_bounds.contains(user.get_role()) => {
                let user = user.clone();
                request.extensions_mut().insert(user);

                Ok(())
            }

            _ => {
                let unauthorized_response = Response::builder()
                    .status(http::StatusCode::UNAUTHORIZED)
                    .body(Default::default())
                    .unwrap();

                Err(unauthorized_response)
            }
        }
    }
}

Is that what I'm supposed to include in the Authorization header? Does that mean I'm expected to pass around a struct with fields id, role, and password_hash with every request? Is that safe?

[maxcountryman]

axum-login uses axum-sessions which in turn sets its own cookie (by default this is axum.sid but can be configured to be called whatever you like).

While the docs for RequireAuthorizationLayer do mention the Authorization header in our implementation that part is not relevant: we instead use the middleware directly to obtain a User if one is present. This works because axum-sessions manages the cookie for us and axum-login provides the user context via that.

So the only thing that needs to be passed back to the server is that cookie, axum.sid. This also means the cookie is sensitive and should never be shared. For that reason the cookie uses a number of default settings that help ensure it cannot be easily stolen.

[dsaghliani]

I'll do that. In the meantime, if you're willing to take a look, I've removed maud and replaced it with plain HTML.

[dsaghliani]

I figured out the problem: I was using a dummy MemoryStore and had not populated it with users. It appears I misunderstood how axum-login works. I thought, when I called AuthContext::login(), which sets self.current_user = Some(user.clone()), that current_user would be persisted between handlers, but I guess it's just for use in the same handler (that called login())? And the middleware queries the database and refetches User: AuthUser with every request?

[maxcountryman]

Glad you figured it out.

The second part of what you said is true: the user needs to be queryable and if it's not in the store then you won't be able to access it.

This supports consistency when a user is changed or deleted. Otherwise your application might be accessing a stale copy which could be dangerous.

You can see how this behavior is implemented by checking out the login middleware itself which attaches the User to the request.

[dsaghliani]

That explains it. While we're on the topic of auth, do you suggest using Postgres or Redis as the session store, provided auth data is the only thing stored in sessions? Since the auth service has to read from the database anyway, could it be somehow be optimized to grab the session data along the way to avoid 2 reads? Or is that a silly question?

[maxcountryman]

Great question. I'm using Postgres to minimize the complexity of my infra. Redis is the more traditional answer but I'm not convinced it's actually better for most applications.

As far as the query optimization question, that would be nice but I don't think there's any practical way to do that. Even if we assume the session and the user are in the same store, we don't have a way of making axum-session aware of axum-login or vice versa. (We could probably find some way of doing this but I suspect it would be awkward--as it stands each is its own module and the way I can think of to enable that would be to make e.g. axum-login also responsible for querying the session.)