Make framework integration easier

Is your feature request related to a problem? Please describe.

I’m currently building framework integration for Zope (and will build Pyramid next). What’s frustrating me is that the integration layer with these frameworks only very loosely specifies what is required of these frameworks to actually interoperate with Authlib.

Describe the solution you’d like

I’ve started the Zope layer from a refactoring of the flask layer, to get started, and in the process pulled out an FramworkIntegration object, that only has the job to describe what authlib needs from the framework. That way it is much simpler to know what has to be implemented to make things work, without having to understand so much about how authlib works. Have a look at it here. https://github.com/zms-publishing/zope.openid-connect/tree/master/zope/openid_connect/authlib_integration

Of course it is still very rough, but the Idea here is to have a delegate object, that subclasses the Framework-Integration Interface, that has methods to access session and cache values and documents what kind of requirements these sessions / caches have to be viable (i.e. these values can not be user visible, but these can…). Also how to get at form or query arguments from a request, etc.

There will maybe be different interfaces to support sync and async operation, and probably some optional methods to support stuff like Flasks partially configured state (app factory pattern). See the repo for some rough sketches.

Describe alternatives you’ve considered

I’ve tried to adapt the code from the flask example directly and found it very hard as I had to understand quite a bit about authlib to make that happen. Maybe now I do, but having a simple delegate object that just encapsulates how the specific framework accomplishes things was in the end much more viable.

Additional context

I’d like to add, that having such a delegate pattern, should also make unit testing much simpler, as it is quite easy to fake such an interface without having to bring up / in the actual frameworks.

What I’m currently having is a simple delegate object, but this could also become a factory and holder of the Authlib objects, allowing it to make callbacks - not sure what is the best way here yet.

Also, this is very much still a work in progress, but I wanted to a) get feedback and b) see how you react, and if maybe that is something that can be extracted into a project in the authlib organisation.

[lepture]

@dwt I got it. Our current _client is designed to be used by Django, Flask and Starlette, and it works well. But to make it better for other frameworks, we need to improve the interface to make no assumptions. And also, we can rename _client into base_client, so that other frameworks can inherit from it without fear.

We can make it happen in v0.14.

[lepture]

It is available in v0.14