The future of axum-login now that tower-sessions is here

[maxcountryman]

Hi folks,

tower-sessions 0.1.0 has been released. It aims to be a replacement for axum-sessions.

Why release a new crate?

We've been working on axum-sessions for a while now but over the last year or so development has been stalled due in large part to its primary dependency, async-session also not having been updated. At the same time, we've encountered some fundamental design flaws related to my attempt to work around the implementation of async-session.

All that to say it seems folks in the tower and axum ecosystem need a solution that's more tailored to our specific needs.

That's exactly that tower-sessions is: it brings the implementation of the session itself directly into the crate (in other words, we no longer rely on async-session) and follows well-established design patterns of other crates, like tower-cookies (which incidentally it uses directly). This means we've addressed the major issues related to deadlocking with this new design.

What about axum-login?

Because axum-login has relied on axum-sessions from the outset, development on it too has stalled. With tower-sessions, we can migrate to this crate, and part ways with axum-sessions. The biggest drawback to this decisions is that we lose support for async-session session stores. That said, tower-sessions also brings with it its own stores, covering Redis, SQLite, Postgres, and MySQL out-of-the-box.

Alternatively, we could consider splitting off from this crate and perhaps creating a tower-login. Overall, I think this makes less sense as the authentication pattern is more closely tied to axum and may not make as much sense as an independent tower crate.

I would love your feedback before we make a final decision.

[maxcountryman]

/cc @czocher

[GrantSparks]

I'm having a lot of trouble with deadlocking axum-sessions/axum-login so attempting to refactor my codebase to use tower-sessions/tower-login is an attractive option, but looking at the branch its a bit more than a drop-in replacement. Any tips for how to approach it given the differences in the libraries?

[maxcountryman]

Sorry you're running into those issues--this is a big part of why we rewrote axum-sessions. The branch is still a work-in-progress, so I would not advise using it beyond testing for now. Please expect it to continue to change while we work on it. For example, I'm in the midst of reworking the separations of concerns presently and I know @czocher has some ideas we'd like to try as well.

[czocher]

Perfect choice, congrats @maxcountryman!

[maxcountryman]

Here's a sketch I've put together using tower-sessions.

Notably this is implemented entirely as an extractor. To enable an extractor-only approach, we need to provide auth state which contains the specific user store. This is slightly awkward, but a missing state is a compile-time error and so the compiler will ensure you can't miss this property.

I've intentionally left out things like roles, in part because I'm not sure that belongs in this library but also because it complicates the implementation and our current solution seems overly opinionated in ways that restrict application authors.

Another issue with this approach is it doesn't do anything to address how you might tie this into an identity provider.

Ultimately to address the last two points, it would be nice to find a way to leave these things up to application authors. I'm not sure this sketch provides the required flexibility to make that a reality however.

[maxcountryman]

/cc @dsaghliani

[maxcountryman]

I've started a branch where I'm exploring this more. These are fairly significant changes, so I do appreciate any and all feedback.

[extrawurst]

i am all in favor of this migration to use tower-sessions forward. the nightmare of the transitive dependencies of axum-login forced me to fork async-redis-session and ship with my code already. i cannot wait for this to be cleaned up. of course sunsetting axum-login and starting fresh with tower-login based on the new tower-sessions will also be fine with me like it also happened with axum-sessions.

[maxcountryman]

I'm sorry you ran into that.

I've started a branch that's a ground up rewrite of axum-login using tower-sessions.

Notably in its current state it will not ship user store implementations or an authenticating user trait.

Instead the workflow will be crate users implement only their user store (the only trait needed) and attach a login service to their application.

Things like requiring authentication and checking for role bounds will be provided via two generic middleware: require authn and require authz.

This moves closer to the spirit of flask-login by creating flexible interfaces with minimal opinions for managing authenticated sessions.

[czocher]

Ah so we're moving towards the idea proposed in #78 as well? Very good idea!

An additional idea I had is maybe we should think about a middleware-based approach, where additional checks, such as required roles, user lockout (as proposed in #102) etc. shall be handled by adding middleware to the authentication/authorization process to perform any additional checks.

What do you think about that @maxcountryman?

[maxcountryman]

Something like that: as it stands, we wouldn't ship any UserStore implementations: this is because the UserStore will also ask for associated types in the form of User, UserId, and Error. So, generic implementations might not be possible or desirable. The work of integrating axum-login then becomes implementing your UserStore (which I hope to be a fairly low lift, but it will vary depending on the specific store).

[maxcountryman]

An additional idea I had is maybe we should think about a middleware-based approach, where additional checks, such as required roles, user lockout (as proposed in #102) etc. shall be handled by adding middleware to the authentication/authorization process to perform any additional checks.

I think I'm following. What do you think about the implementations of require_authn and require_authz? The idea there is that someone implementing UserStore can control the exact behavior of those middleware. For example, perhaps you check role bounds in the implementation of is_authz.

[czocher]

I just had a deeper look into it and in my opinion we're mixing up two separate responsibilities here. There are three elements of a proper authorization workflow:

1. Find the correct user - this should be the main responsibility of the UserStore - find a given User by their identifying feature, it being a username, an email, id or whatever.
2. Verify the provided secret information to grant authentication - this can be a password, a TOTP. This should not be the responsibility of the UserStore, but something else entirely.
3. Authorize a user for a given resource - this is not a part of the authentication flow, since this takes two input parameters: the given user with all their claims (verified information taken from the database) and a resource (usually an endpoint).

There's also a separate responsibility of error handling with distinct operations that can potentially fail:

1. When the UserStore fails to either retrieve the user or even connect to the underlying store.
2. When the authentication process fails due to an incorrect secret.
3. When a user lacks proper authorization for a given resource.

I strongly believe some kind of middleware approach would potentially benefit us here, since our main responsibility should be authentication and we should leave some way to provide authorization for the user to implement, being it a role-based approach, permissions or something else entirely.

[czocher]

I still have that in mind, just travelling at the moment and can't concentrate on open source work.

[maxcountryman]

I've not captured everything you've mentioned, but I have reworked experimental sketch again. This time I've brought back the user trait and introduced the concept of a "backend", also a trait, which encapsulates identification, authentication, and authorization a la the Django auth middleware.

For example, that could look like this:

pub type UserId<Backend> = <<Backend as AuthBackend>::User as AuthUser>::Id;

pub trait AuthUser: Clone + Send + Sync {
    type Id: Clone + Send + Sync + Serialize + for<'de> Deserialize<'de>;

    fn id(&self) -> Self::Id;

    fn session_auth_hash(&self) -> Vec<u8>;
}

#[async_trait]
pub trait AuthBackend: Clone + Send + Sync {
    type User: AuthUser;
    type Credentials: Clone + Send + Sync;
    type Permission: Hash + Eq + Clone + Send + Sync;
    type Error: std::error::Error + Send + Sync;

    async fn authenticate<B: Send>(
        &self,
        req: Request<B>,
        creds: Self::Credentials,
    ) -> Result<Option<Self::User>, Self::Error>;

    async fn get_user(&self, user_id: &UserId<Self>) -> Result<Option<Self::User>, Self::Error>;

    async fn get_user_permissions(
        &self,
        user: &Self::User,
    ) -> Result<HashSet<Self::Permission>, Self::Error> {
        Ok(HashSet::new())
    }

    async fn get_group_permissions(
        &self,
        user: &Self::User,
    ) -> Result<HashSet<Self::Permission>, Self::Error> {
        Ok(HashSet::new())
    }

    async fn get_all_permissions(
        &self,
        user: &Self::User,
    ) -> Result<HashSet<Self::Permission>, Self::Error> {
        let mut all_perms = HashSet::new();
        all_perms.extend(self.get_user_permissions(user).await?);
        all_perms.extend(self.get_group_permissions(user).await?);
        Ok(all_perms)
    }

    async fn has_perm(
        &self,
        user: &Self::User,
        perm: Self::Permission,
    ) -> Result<bool, Self::Error> {
        Ok(self.get_all_permissions(user).await?.contains(&perm))
    }
}

The attendant middleware are also included on the tower-sessions branch as well as a very messy example.

One thing I'm not particularly pleased about is the need to define the Permission associated type even if you don't use it.

[czocher]

What I had in mind (which I'm currently trying to implement) is something like this:

Create a trait (named AuthFlow or something) with a default implementation which would take three parameters:

• UserStore - a trait which would get a UserId and return a User (or an Error: IntoResponse) from a database connection.
• Authenticator - a function which would get User, verify it's password and either forward it downstream or return an Error: IntoResponse.
• Authorizator - a function (or maybe a list of functions) which would get a User (and probably some additional parameters, maybe even a database connection) and return the user or an Error: IntoResponse.

The default implementation of AuthFlow would have a single method doing the following:

fn execute(userId: UserId) -> Result<User, Error> {
    return authorizator(authenticator(userStore.load(userId)?)?);
}

This is of course just an idea, not sure how Rust will like it yet :D. I'm currently analyzing what is possible ;).

[czocher]

@maxcountryman I analized your recent version and in my opinion this is far better than what I would create. The problem you mentioned with defining Permissions even if they're unnecessary may be solved by creating two versions of the trait - one without the permission check, one with - since it would be an additive change it can also be hidden behind a feature flag.

I'm super impressed with what you created, thanks!

[maxcountryman]

@czocher great idea--splitting the traits makes sense to me!

Here's a slightly less chaotic example of that approach:

use std::net::SocketAddr;

use askama::Template;
use async_trait::async_trait;
use axum::{
    error_handling::HandleErrorLayer,
    extract::Query,
    response::{IntoResponse, Redirect},
    routing::{get, post},
    BoxError, Form, Router,
};
use axum_login::{login_required, AuthBackend, AuthManagerLayer, AuthUser, UserId};
use http::StatusCode;
use serde::{Deserialize, Serialize};
use sqlx::{FromRow, SqlitePool};
use time::Duration;
use tower::ServiceBuilder;
use tower_sessions::{Expiry, MemoryStore, SessionManagerLayer};

#[derive(Debug, Clone)]
pub struct Backend {
    pool: SqlitePool,
}

impl Backend {
    pub fn new(pool: SqlitePool) -> Self {
        Self { pool }
    }
}

#[derive(Debug, Deserialize)]
struct NextUri {
    next: Option<String>,
}

#[derive(Debug, Clone, Deserialize)]
pub struct Credentials {
    username: String,
    password: String,
    next: Option<String>,
}

#[async_trait]
impl AuthBackend for Backend {
    type User = User;
    type Credentials = Credentials;
    type Error = sqlx::Error;

    async fn authenticate(
        &self,
        creds: Self::Credentials,
    ) -> Result<Option<Self::User>, Self::Error> {
        // **NEVER** store plaintext passwords!
        //
        // Instead a real application should store a password hash.
        //
        // For example, `argon2` is an excellent password hashing function.
        let user = sqlx::query_as("select * from users where username = ? and password = ?")
            .bind(creds.username)
            .bind(creds.password)
            .fetch_optional(&self.pool)
            .await?;

        Ok(user)
    }

    async fn get_user(&self, user_id: &UserId<Self>) -> Result<Option<Self::User>, Self::Error> {
        let user = sqlx::query_as("select * from users where id = ?")
            .bind(user_id)
            .fetch_optional(&self.pool)
            .await?;

        Ok(user)
    }
}

#[derive(Debug, Clone, Serialize, Deserialize, FromRow)]
pub struct User {
    id: i64,
    username: String,
    password: String,
}

impl AuthUser for User {
    type Id = i64;

    fn id(&self) -> Self::Id {
        self.id
    }

    fn session_auth_hash(&self) -> Vec<u8> {
        self.password.as_bytes().to_vec()
    }
}

type AuthSession = axum_login::AuthSession<Backend>;

#[derive(Template)]
#[template(path = "login.html")]
struct LoginTemplate {
    message: Option<String>,
    next: Option<String>,
}

#[derive(Template)]
#[template(path = "protected.html")]
struct ProtectedTemplate<'a> {
    username: &'a str,
}

async fn get_login_handler(Query(NextUri { next }): Query<NextUri>) -> LoginTemplate {
    LoginTemplate {
        message: None,
        next,
    }
}

async fn post_login_handler(
    mut auth_session: AuthSession,
    Form(creds): Form<Credentials>,
) -> impl IntoResponse {
    let user = match auth_session.authenticate(creds.clone()).await {
        Ok(Some(user)) => user,
        Ok(None) => {
            return LoginTemplate {
                message: Some("Invalid credentials.".to_string()),
                next: creds.next,
            }
            .into_response()
        }
        Err(_) => return StatusCode::INTERNAL_SERVER_ERROR.into_response(),
    };

    if auth_session.login(&user).await.is_err() {
        return StatusCode::INTERNAL_SERVER_ERROR.into_response();
    }

    if let Some(ref next) = creds.next {
        Redirect::to(next).into_response()
    } else {
        Redirect::to("/").into_response()
    }
}

async fn logout_handler(mut auth_session: AuthSession) -> impl IntoResponse {
    match auth_session.logout() {
        Ok(_) => Redirect::to("/login").into_response(),
        Err(_) => StatusCode::INTERNAL_SERVER_ERROR.into_response(),
    }
}

async fn protected_handler(auth_session: AuthSession) -> impl IntoResponse {
    match auth_session.user {
        Some(user) => ProtectedTemplate {
            username: &user.username,
        }
        .into_response(),

        None => StatusCode::INTERNAL_SERVER_ERROR.into_response(),
    }
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Session layer.
    let session_store = MemoryStore::default();
    let session_layer = SessionManagerLayer::new(session_store)
        .with_secure(false)
        .with_expiry(Expiry::OnInactivity(Duration::days(1)));

    // Login service.
    let pool = SqlitePool::connect("sqlite:examples/example.db").await?;
    let backend = Backend::new(pool.clone());
    let auth_service = ServiceBuilder::new()
        .layer(HandleErrorLayer::new(|_: BoxError| async {
            StatusCode::BAD_REQUEST
        }))
        .layer(AuthManagerLayer::new(backend, session_layer));

    let app = Router::new()
        .route("/", get(protected_handler))
        .route_layer(login_required!(Backend, login_url = "/login"))
        .route("/login", post(post_login_handler))
        .route("/login", get(get_login_handler))
        .route("/logout", get(logout_handler))
        .layer(auth_service);

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await?;

    Ok(())
}

[ericaltendorf]

My input was requested in a discussion over on Reddit, but being new both to Rust and FE dev in general, I'm not qualified to opine on the architecture. I'm just building a proof of concept with a Rust backend exposing data via API, a Next.js FE which talks to the API, and a DB behind Rust, and had assumed there was a standard library for auth & session management. I don't have complex authorization requirements, need to make sure users are authenticated, then will use their id to load the data from the DB. I would like the ability in the future to integrate with Oauth2, FWIW.

[maxcountryman]

Hi again folks, I've made considerable progress on the tower-sessions branch and now would be an excellent time for feedback about that particular approach you all might have. My plan is to move forward with this API and continue to iterate on it as we find opportunities for improvement. Again, any feedback you all might have is very much appreciated.

[maxcountryman]

v0.7.0 is now released. The plan is to continue to iterate on this, so please do let us know what feedback you have as you use it.

[ericaltendorf]

Thanks! Trying it out now. I have one question (general, not specific to the rewrite). My Rust server will manage sessions and expose JSON APIs. End-user page rendering, routing, and redirects will happen in a Next.js frontend. I'm not sure if it makes sense to use login_required! to protect the api routes on the Rust server, since I think each API call will need to check the session for the user info and return errors if its missing anyway? Sorry if this is drifting off-topic; only bringing it up in case it's a use case to consider in the design.

[maxcountryman]

I'm not sure if it makes sense to use login_required! to protect the api routes on the Rust server, since I think each API call will need to check the session for the user info and return errors if its missing anyway?

We've provided login_required! and the other macros as a convenience, but I fully expect some applications won't use them either because they'll write their own middleware or like you mention inspect the session directly at the route level and respond accordingly.

It's important to point out that applications that don't use the macros and the middleware they produce are still responsible for controlling resource access.