Unified Security Extension For Starlite

[infohash]

There are multitude of options to choose from when it comes to authentication and authorization. We need an extension that features following security protocols:

1. Oauth2
2. OIDC (We don't have to segregate OAuth2 and OIDC as OIDC works on top of Oauth2 so if the base lib implements OIDC, it will natively support Oauth2.)
3. Static API keys
4. Traditional username and password auth

With a unified design, we can also merge starlite-jwt into it.

Let's discuss more feature requirements for other security protocols that you have in mind along with the structure.

[provinzkraut]

Okay so here goes my current thoughts:

At first, we should aim low. That is, provide an MVP of what's commonly needed for simple web application security.

We should also segregate concerns here, that is, make a clear distinction between submodules and their provided functionality.
Modules for JWT, session-based authentication and OIDC should work independently of a potential authentication / authorization module, while the latter could make use of the former.

There is a lot of common functionality, so it makes sense to provide generic components for this. Let's call those our backends for now.
These "backends" should provide functionalities to:

1. Initialize a new session
2. Authenticate a request
3. Authorize a request
4. Retrieve user identity from a session
5. Terminate an existing session
6. (If applicable) Remotely terminate a session

I propose a general layout something like this:

└── starlite_security
    ├── jwt
    ├── login
    ├── oidc
    └── session_auth

With each of these having a very narrow scope:

• login:
  • Provide users
  • Guards for authentication / authorization
  • Generic handlers to manage user sessions (login / logout)
• jwt:
  • Provide identity via JWT
  • Generic JWT functionality (validate / inject arbitrary JWTs into handlers)
• oidc
  • Provide identity via OIDC
  • Generic ODIC integration
• session_auth: Provide identity via sessions

If we feel fancy at some point, we could broaden the scope to include a users module, which allows for basic user management, akin to what flask-security does.

This is just a very rough outline of things, we'd have to settle for more concrete goals / non-goals regarding features we want to support before we're going to implement it.

@infohash I think everything you said about the potential OIDC integration could be made to fit within the framework I described, WDYT?

[provinzkraut]

Session auth doesn't use JWT. It's cookie based (either session data stored directly in a cookie or the cookie just stores the session ID).

I'm not that familiar with OIDC, but I imagine it could built upon the functionality in jwt for the JWT stuff.

[cofin]

I failed to mention in my previous post that I like the directory structure as well.

[LonelyVikingMichael]

Session auth doesn't use JWT. It's cookie based (either session data stored directly in a cookie or the cookie just stores the session ID).

I'm not that familiar with OIDC, but I imagine it could built upon the functionality in jwt for the JWT stuff.

It is not unheard of to use a JWT as a cookie's value

[LonelyVikingMichael]

On login, we need to load user data from somewhere.
Do we leave it to the consumer to define and register a get_user callback?

[provinzkraut]

It is not unheard of to use a JWT as a cookie's value

Sure, but we don't use that for anything right now, and it doesn't really concern the security module where the identity comes from. The providers will be given request data to authenticate, so if someone wants to load their JWT from a cookie there's nothing holding them back.

On login, we need to load user data from somewhere. Do we leave it to the consumer to define and register a get_user callback?

For the time being, yes. The plan is to first craft a basic framework, that's adaptable to specific needs, and once that's settled we can follow up with specific implementations, for example provide functionality to load users using our ORM integrations. This would fall into the same category as user management.

[Goldziher]

Should we go for a separate package or starlite.contrib.security? I tend for the contrib approach now, since the open telemetry stuff is in contrib.

[v3ss0n]

Most of the things you mention are user management. This is out of scope for now and is definitely not lightweight at all. Check my comment about the suggested structure about the module to see what would be a base implementation.

then , better do jwt , oidc in contrib , user management as seperate project / lib , oauth providers contributed inside authlib would make sense?
Oauth Providers are useful for itnernal services sharing the same user across several services.

Contrib -> jwt , oidc
Separate Module -> users module (like fastapi-users ) https://github.com/fastapi-users/fastapi-users
authlib => starlite-oauth/2 providers.

[provinzkraut]

Please see the original structure I proposed. It includes all of these and where they should go.
Yes, jwt and oidc go into contrib, user management might be a future goal.

[v3ss0n]

Please see the original structure I proposed. It includes all of these and where they should go. Yes, jwt and oidc go into contrib, user management might be a future goal.

yes i saw when i am posting last comment , sorry i ddin't see it earlier as it was collapsed.

[Goldziher]

All good, your participation is appreciated 👍.
If you'd like to contribute a login flow and the others it could be cool. Or just a lib on your end you publish too!

As for OIDC - it's pretty complex because the specification actually offers multiple mechanisms for authentication. Basically you're familiar with 0Auth, and OIDC also supports 0Auth. You can read the spec, which is pretty arcane, or simply play with it.

The problem in python is that the only certified packages for OIDC, name pyoidc and the libs built on top of it, are not ASGI and are pretty hard to work with. Also there are no docs. So Authlib is our best bet. It's not perfect but it's definitely better.

[v3ss0n]

Yes i am interested , i will look around this week as we need to integrated in our current project too.

[provinzkraut]

Integration with / of authlib might also be something considering.

[v3ss0n]

how authlib works? never used it before. haven't seen a framework using it too

[v3ss0n]

This is exactly what i am looking for .
For Lightweight use cases (Non Oauth/OIDC) , we could start with

User creation and management

• register
• user/password CRUD
• password reset
• password generate

Security

• jwt
• login
• firstime login and password reset flow.
• user roles

OTP

• Registration Emailing
• Password Reset
• preauth login and set password

[Goldziher]

Ok, first iteration of this has been merged!

i'd like to suggest we discuss the next iteration. I suggest the following:

1. OIDC support via authlib
2. A permissions system that offers ready to use guards and is easy to use (DRF, looking at you)

Possibly also adding a contrib with a few static pages - logic screen, password reset etc. using passlib or some other solution. I dont think this is a very good approach these days, but users will want this. This is probably though a really great 3rd party package.

[LonelyVikingMichael]

Where does the (currently WIP) starlite-oidc package fit into this?

[Goldziher]

Im considering to ditch OIDC support as part of starlite. Pyoidc is too messy, and authlib has a license we cant sustain.

[Goldziher]

see this ticket i decided to close: #878.

If you want to publish starlite-oidc with infohash (wallrod) together, outside of the starlite org, youre welcome to do this.

[LonelyVikingMichael]

That's understandable, thanks.