Enhancement: OIDC Security Backend

[Goldziher]

As we discussed in #794 - we would like to have an OIDC integration as an optional component in starlite.contrib.oidc. This will have to rely on pyoidc, which while problematic is the only fully fledged OIDC implementation in python and also has a usable license.

Our implementation should support all the flows supported by pyoidc with an easy to use abstraction layer. For reference: https://darutk.medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660

[Goldziher]

So, after looking into pyoidc I am dubious we should actually integrate this inside Starlite. This library is too messy and is going to be hard to maintain - this should be done in an external library, outside of our github org, probably by someone else who is willing to maintain this.

Open to people who want to pick this up - this issue though is going to be closed here.

fyi @infohash if you want to publish you own lib.

[v3ss0n]

any OIDC supportin coming in 2.0 ? the starlite-oidc is also abandoned right?

[infohash]

While there is no planned date for OIDC extension of starlite 2.0, I have prepared a requirement to create an OIDC extension which will wrap idpy-oidc which is the latest OpenID foundation certified OIDC lib in Python with latest OIDC features and addons.

The problem I am facing is even though idpy-oidc is the latest revision of OIDC implementation for Python, its design pattern still does not look modern and it is not async so a wrapper around it for starlite cannot be maintained by starlite-api. I have 2 options:

1. Either I port idpy-oidc lib to an async version and then write a starlite extension on top of it.
2. Or Just use the lib as is and write a wrapper around it.

Both have its own problems and complexity with maintainability of code (and security if I port idpy-oidc to an async version).

The reason I no longer want to use pyoidc lib as base is because it's not async, it has legacy design pattern and it does not have all the features of OIDC like the most popular one is OIDC-PKCE (idpy-oidc has this one though). Another problem is (or it may become a security problem in future) pyoidc lib depends on pyjwkest which is no longer being maintained as much as jwcrypto which is a good replacement candidate for pyjwkest and is used by idpy-oidc.

You can also try using idpy-oidc natively. I would like to hear if someone else is (or has already started) working on OIDC support for starlite.

[v3ss0n]

thats sounds bad , how other async frameworks doing with this? did they write their own connector? Gonna look around.

[v3ss0n]

I stumble upon this : https://github.com/revensky/psion what do you think?

[v3ss0n]

also this one , looks maintained : https://github.com/kroketio/quart-keycloak could this be adapted?

[infohash]

psion only has OIDC Authorization Code Flow without its addons like PKCE, PAR, etc and quart-keycloak only supports Keycloak as an adapter and not as a generic client. See the complete list of features that idpy-oidc supports which will soon also support OIDC CIBA. I appreciate that Roland Hedberg has taken care of everything including the crypto but being async and having a sustainable modern design pattern are kind of a cool thing to have specially for the modern async frameworks where type hinting is strictly enforced.

I think FastAPI does have a custom third party OIDC extension and there is also a well maintained and fully compliant authlib for Python but with BSD license for open source projects and a commercial license for industrial projects. The problem with writing a security lib like this is if it is not certified or at least not fully compliant with the OIDC spec, its adoption rate in the industrial projects will be very slow and if you are not a security expert, maintaining its security will be hard so I stick to writing wrappers.

[v3ss0n]

psion only has OIDC Authorization Code Flow without its addons like PKCE, PAR, etc and quart-keycloak only supports Keycloak as an adapter and not as a generic client. See the complete list of features that idpy-oidc supports which will soon also support OIDC CIBA. I appreciate that Roland Hedberg has taken care of everything including the crypto but being async and having a sustainable modern design pattern are kind of a cool thing to have specially for the modern async frameworks where type hinting is strictly enforced.

Thank you very much for well researched reply

authlib for Python but with BSD license for open source projects and a commercial license for industrial projects

Dual license, sucks.

[v3ss0n]

Have you checked oauthlib ?

[infohash]

oauthlib is a legacy version of authlib.

[v3ss0n]

how about https://github.com/frankie567/httpx-oauth ?

[v3ss0n]

@infohash https://github.com/lepture/authlib/issues/475 the author saids that allows to use BSD License on Closed Source Projects (can choose any) . His license only seems to apply to the cases where the developer uses a closed source OAuth Provider (like Auth0) .

[mcclade]

For corporates any license condition that requires a conversation is going to block usage.

“Why is starlite being blocked by the package manager?”

“Oh, one of its dependencies is on a dual license. You need to speak to Steve in Legal to explain what you’re using it for and get agreement that your use case matches this guy’s vague statement on a GitHub issue”

“Yeah… I’ll just use something else.”

[infohash]

@v3ss0n httpx-oauth has partial implementation of OIDC. As for authlib, what @mcclade said. It will deter industrial projects to use such an extension that wraps a dual licensed code.

[v3ss0n]

Its seems that BlackSheep's OIDC looks like the best fit for starlite as @Goldziher suggested . I am free a few weeks , and we are going to rebuild our project management platform - which would need OIDC . We are going to opensource our work on OIDC too. Any direction would be greatly appreciated.