Authentication Session

[justmangoou]

I believe that most people use this for handling authentication session (aka login session) which it's not really implemented here, should this become a feature. If yes,

• Add this feature as lib feature
• Allow user to create session with provided id
• Allow session to be generated manually

[justmangoou]

@maxcountryman what do you think of this?

[maxcountryman]

Thanks for mentioning this.

I'm wondering if axum-login should migrate to use this crate. (I started a discussion over there about this too.)

Alternatively we could implement a tower-login but I'm not sure if that should live separately from axum.

I suspect it's probably best to have this life as its own crate that consumes this crate tho.

[justmangoou]

Well, it's actually easier to build something from scratch than fix the existing one. But it's up to you to decide.

However, not every user chooses to use a password-based login for their application. They can use oauth or openid which is easier for them to interact with 3rd services such as Github. Also, many of them tend to handle sessions manually.

So that made me think adding such a "general authentication session" feature could handle both cases perfectly.

P/s: I didn't see the reply box

[maxcountryman]

However, not every user chooses to use a password-based login for their application. They can use oauth or openid which is easier for them to interact with 3rd services such as Github.

This is a good point.

Do you have a design in mind?

[justmangoou]

For tower-sessions, there's no need to change anything except for those points I've mentioned.

For axum-sessions or tower-sessions (if plan to), just need to replace the password-input flow with oauth's or openid's flow.

I looked into Ory, Casbin. It provides many features that I personally don't need and it costs performance. So I think just keep it as simple as possible.

[justmangoou]

For further development,
maxcountryman/axum-login#52 and some other discussions about implementing non-supported database drivers or ORMs/ODMs
maxcountryman/axum-login#59 - this explained why authentication session needs to be given manually or any method that allows to renew session dynamically.

In spite of using tower as the based of this library, some axum's feature may be considerable to be put in this library such as CookieJar. I'm not certain that this makes any different compares to tower, so I will leave this question.

For the design, something like

let session_manager = AuthSessionManagerLayer::new(session_store).with_secure(true);

#[derive(Debug, Clone)]
pub struct AuthSessionManagerLayer<Store: SessionStore> {
    inner: SessionManagerLayer<Store>,
}

This should be applied to login crate

Edited design:

• Allow construct SessionManager publicly.
• Add SessionManager to State (idk if tower has this) and retrieve it from middleware.
• Add option to allow SessionManager issues session automatically or not.

I might miss some features, but in 99% way to handle this, it will cause breaking change.

[justmangoou]

This should be implemented by authentication libraries instead.

[maxcountryman]

That makes sense to me.

[justmangoou]

However, I think SessionManager is still needed to be extracted.

Is it possible to extract SessionManager from http method like Session? It'd better than the latest PR, no breaking changes, no need to pass SessionManager parameter.

[maxcountryman]

I've put together a functional proof-of-concept over here.