The Python Podcast.__init__

Share on social media:

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With 200 gigabit private networking, scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new API, you've got everything you need to scale up.   And for your tasks that need fast computation, such as training machine learning models, they just launched dedicated CPU instances.   And they also have a new object storage service to make storing data for your apps even easier.  

Go to python podcast.com/linode,   that's l I n o d e, today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show.   And you listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis.   For even more opportunities to meet, listen, and learn from your peers, you don't want to miss out on this year's conference season.   We have partnered with organizations such as O'Reilly Media, Corinium Global Intelligence,   ODSC,   and Data Council.  

Upcoming events include the software architecture conference, the Strata Data Conference, and PyCon US.   Go to python podcast dotcom/conferences   to learn more about these and other events, and take advantage of our partner discounts to save money when you register today.  

[00:01:41] Unknown:

Your host as usual is Tobias Macy. And today, I'm interviewing Matthias Agire about Python Social Auth and the complexities of third party authentication. So, Matthias, can you start by introducing yourself?  

[00:01:51] Unknown:

Yeah. Sure. So, hi, everybody. My name is Matthias Aguilar. I'm a software developer from a small country in South America, Congo, Uruguay. I'm the author and maintainer of Python Sociedad. And do you remember how you first got introduced to Python? Yeah. What? It's been a long time since that.   So I got my hands on Python back in the day when Django   o point 96   was a thing. It was quite popular version, but then so with a friend, we are looking for something to move away from PHP.   So we split our research, 1 focusing on Ruby on Rails, another focusing on Django, which were the popular solutions   at that point. I I was in charge of the Ruby on Rails research, but in the end, Shango won the contest. I'm quite happy about that. And on your profile,  

[00:02:33] Unknown:

where when I was looking around doing some research for the show, I noticed that the list of languages that you primarily work in includes Ruby in addition to Python and JavaScript. And so I'm wondering how much of your focus is still spent on that language, and what you have found to be some of the benefits of working in both Python and Ruby or, just your overall experience of that language? Yes. So I work on Ruby for several years on my previous workplace. Ruby was the main language we used. That was for 8 years, around 8 years of Ruby development. And sometimes I got the chance to use some Python. As of today, I'm working on a new place. It's fully Python for everything. Over over the years, I I had the chance to to work on Python on personal project mostly. Python's layout is 1 of the results of that. And so in terms of Python social auth, can you just start by by giving a bit of a description about what the project is and some of the motivation for starting it and the origin story of how it came to be? Yeah. So PyTorch allows this a small library, not quite small by now, but it aims to simplify the developer life when  

[00:03:38] Unknown:

they want to integrate social based authentication authorization on their projects. So everybody's familiar with the login using x socialize, buttons around the the web. Python's allows us to hide the complexity behind that functionality   by giving enough room to define a good solution that better fits your project. Like many projects, it got started due to frustration with the solutions that were available at that time. It was smaller, like, call while working on a personal project.   The solutions that were popular back then,   they have complicated   setups or not enough   room to   add   my requirements.  

So I found as my own project, Shango Sociedad back then, which fully focused on Django.  

[00:04:25] Unknown:

And then it becomes a really popular solution, and a couple of years later, it morphed into Python itself. And at this point, it seems to have become somewhat of the de facto standard for being able to handle these third party login integrations. So I'm wondering what you think are some of the contributing factors to the popularity that it has gained, and maybe give a bit of a description of some of the overall landscape of available options, particularly now since as you said at the beginning, when you first started the project, there weren't really a lot to choose from. So, yeah, I say that the main contributor factor to make it so popular was the simplicity while integrating on Django. The idea of overall the project was that with really small set of settings or small changes in your code base. You will have a fully working authentication process using a social  

[00:05:13] Unknown:

website as as you source some information for the user details and user profile.   Then the the second key factor on the operator, I would say, is the,   a particular feature on the library, which is called pipeline.   And this feature allows you   to extend the notification process as much as you want with any requirements that, are needed for your project. But then this functionality didn't exist on on the solutions. As I   recall,   the popular library at that, that time, you were required to define   templates,   put ons, add forms,   and that didn't seems like   the proper solution for our authentication flow where usually you just click a button, go to the provider authentication provider to put your credentials in there, and then your copap   sent back to the your site, then you have a your account already up and running. That was main focus on Python's head out, and I did quite well, but it does that today too. And then in terms of some of the use cases of when somebody might want to enable integration with these third party identity providers,  

[00:06:22] Unknown:

what are some of the motivations there, and what are some of the trade offs or drawbacks of delegating authentication and identity to those third parties versus controlling it entirely in your application?  

[00:06:33] Unknown:

Almost every web application requires user to be registering   in order to properly work is a common pattern. Everybody wants users on their side using the application.   And it's a very common problem, but it demands quite a lot of work to solve.   You need to define forms or validations.   You make confirmation.   You have   profile, pictures,   upload details, etcetera etcetera. So it's a very complex product and demands a lot of work. And then there's the security   bit of all these, which is password, handling password, ensuring that they're properly fashioned in your database. You use a salt, a good algorithm, then there's potential of leaking this power out this password out,   especially when there are so many bad practices used by user, like use the same password for every site. There's   a risk,   a security risk on all these. Social authentication   solve most   all of these problems. There's no forms. You just put a link on your site. Profile details are already   populated from the authentication provider.  

Email address are usually already validated by these authentication providers, especially if there's no password on your end. You don't need to have a password  

[00:07:46] Unknown:

store on your database at all. So there are many factors that get reduced simply by adding a link or a button on your side. And for a number of projects, they'll actually have both options where you can create an account using an email or a username and password, but then also have the option of using different social providers, whether that's Google or Facebook or Twitter or GitHub or what have you. And I'm wondering what you have found to be some of the other best practice   or common trends among people using Python social auth as to whether they prefer to have that option of maintaining identity on their platform or if they tend to prefer just relying on the   authentication mechanisms.  



[00:08:30] Unknown:

Probably, I don't see a gain   on your on our side. We by maintaining authentication   on our project,   I really dislike password. I even I prefer authentication mechanics where I I put my email address and a temporary password or link is emailed to my account. There's no need to password at all. So password has proved to be a really security problem   since the beginning,   and avoiding that as much as possible   is is is a must for me. And   for   reasons   why they provide   both options,   they fail to I fail to understand them. I tend to assume that's mostly for recovery,  

[00:09:13] Unknown:

but there are other recovery methods today that you don't need a password on the side to to access application. Yeah. The magic link method that you're referring to as far as not having a password at all, but just taking an email account and then sending an email with a a 1 time use authentication token, I think, is definitely gaining a lot of popularity because of the weaknesses that we've seen in passwords and passphrases that you mentioned. Mentioned. So does Python social auth also support that type of mechanism, or is that something where you would just rely on a different library and then include that in the  

[00:09:44] Unknown:

authentication pipeline that Python and social auth provides. Yes. Python and social auth also provides user   name and password authentication.   It's not commonly used, but it's there. Then you have the 1 time authentication flow using an email address. That's also support. And can you talk a bit more about how Python social auth itself is actually implemented and some of the current architecture of the library and how it's evolved since the first stages of when you began working on it in the form of django social auth? Yeah. So, yeah, in the beginning, it was django social auth. Its unique proposal was to solve social dedication problem for just the Django projects. So in the beginning, it was really highly complete with the framework.   Even but even some basic blocks of what's today and set up already exist by the so   a key part of the implementation was ensuring   the back ends back ends are the the the parts that we handle the communication with the authentication provider.  

So   a key part of the implementation was defining this bucket with the goal of hiding as much as possible the complexity of the authentication provider while offering   clear and simple interface,   interface to the   the users of this provider, which is the rest of the code of Python Software. Then the smallest usually, like, at any chunk of brochure, you have models where we store   the user ID or the dedication provider and the reference to the user in the database. And and then there was the pipelines feature. This was really early introduced in the code base.   Looking at the features, really simple. That is a list of functions that get called on the given order. The output of the previous function is passed to the next 1   until the the last 1 is executed, and the goal of the pipeline is having to have a user, a valid user on your database that it's okay to authenticate.  

Those   basic block of the application   made it possible then to evolve it to Python slash allow   where the   Django   related bits were moved to a new concept as colon strategy. These strategies are   the gluing between the framework particularities   and Python's SQL core.   That's what I load the Python's got support, Django,   Flask,   Pyramid,   etcetera.   You can add more integrations if you want. And, yeah, those are the basic blocks today too as well. Did you have the authentication back ends hiding the complexity   of the providers,   models for storage of the details, the application flow details,   pipelines to   extend   your particular functionality.  

And the strategy is to hide the framework complexities.  

[00:12:31] Unknown:

And what have you found to be some of the most   complex or challenging aspects of designing and building this library, particularly given the number of different identity providers   and the variances  

[00:12:44] Unknown:

in the authentication protocols that they support? So for sure, the difference in the protocol were problematic,   a problem to solve by the framework. But in the end, I found that defining a really simple interface   or interface of the what application   needed from this provider that pays off very well,   as the call evolves because   this simple interface   allows me to hide the complexity   of the   provider,   while still fulfilling their requirements for the library.   For instance,   there's a metal called get user details. I don't care the rest of the call doesn't care about the particular implementation that this method,   has for the different providers. It only cares about the output result is, and it's the having the user details available to build a user in some nice store on the database. So ensuring that defining these interfaces,   clearly define these interfaces for the rest of the call was key   to hide all the complexity behind the protocols or the different location providers. Then without difference on the protocols, like OpenID   works a bit different than OAuth.  

They communicate different. It's extremely involved. Chase on API. Usually, Chase on APIs on all providers. There are this key difference between them,   but it was not as much as was I was expecting when adding them. It's some other of defining the proper methods that need to be involved on the different providers. The data is already available there to to build the rest. It was the   complicated. In overall, the authentication flow is quite similar. You click a button on your side, you get redirected to the provider,   put your credentials, and then you are sent back to your side to continue the dedication process, which usually is hidden  

[00:14:32] Unknown:

behind in the back end. And I know that in different implementations   or different workflows, there can be cases where you have to suspend the authentication   flow and then resume it either from the links into your email or from a different computer. And so I'm wondering how you approach that challenge of being able to ensure that the current state of the authentication for a given user is maintained across sessions or across browsers or machines? Yeah. That that functionality  

[00:15:00] Unknown:

is provided by the partial pipelines called partial pipeline. So it's something glue with the pipeline feature.   It allows you   to stop the authentication process at any given point. That way, you can do something else that sent an email   or render a form where you'll need extra details from the user,   etcetera. I see. It was a very welcome feature. In the beginning, it wasn't perfect. It was session based. So if you stop a pipeline right in the middle for some reason, you needed that confirmation   from an email, for example.   Somebody else   sit on the computer and try to log in also on your side. They will resume the authentication flow from the previous user. So it wasn't perfect   in the beginning. Then it involved into storing   the pipeline state   on the database,   and a token   was generated. You can use that token to send it in in an email or,   store the link   somehow, which are the link to the user   1 way or another. And that unique token would identify your authentication process. And the session was not involved anymore. So you could continue you guys could start your authentication process on your work computer, then go to your home and continue the process on on your home computer. In terms of the different protocols  

[00:16:18] Unknown:

and implementations of those protocols for different authentication providers, they'll all have a different set of attributes that they're able to support or that they'll provide. And so I'm wondering how you approach that challenge in terms of determining what the minimum set of common parameters are and how to take advantage of the additional attributes and merge that all into a cohesive user profile on the end of the site that's implementing Python social auth? Yeah. So,  

[00:16:44] Unknown:

Python's here, I'll try to solve the bare minimum   of the problem. So   it focus on really small set of attributes,   in order to work, like email or   username or first and last name. With those   really small   attributes, it's able to to to build a user and store that in the database.   These are   these are very basic it's really based on on Django   user model that that it was based on from Django social. It was narrated   from there.   Still, you are able to   define   what actually attributes you want to pull from the different authentication providers. Some some of them can be   pulled automatically by the library because their   API is being used by the 4   is able to provide these attributes.  

Sometimes   on most of the cases, you need to actually   extend   the pipeline,   in order to retrieve the extra attributes you want to store on your project. Like, you want to download at the profile picture from Google,   then   you need to add   a metal to that pipeline   to do that particular   API request.   And   that's   where Python c allow   is out of the   of what it offers. You you can extend, you can pull anything you want, but you need to add the implementation   yourself.  

[00:18:18] Unknown:

And so it's probably worth digging a bit more into the   user's   perspective of implementing   Python social auth and the overall work flow there, and maybe dig into the pipeline mechanism that you have for being able to handle these different stages of   authentication and how you manage the attributes and permissions from the identity providers that you're getting?  

[00:18:40] Unknown:

Yeah. So from developer perspective, usually, like, all you need to do is go to the authentication provider   administration   panel or page. There's usually 1 for dedicated for developers where you can create an application.   Once you create that application   with certain   values like our redirect   URL, you will get an application ID, application secret, or an application ID for open ID. There's very minimal settings   that then you go to your project, add these   particular keys in your settings to be available for the back end that we've handed to the authentication.   Then you can include a URL or a button on a template.  

Once the user clicks on this button, the authentication flow kicks in and you end with a user,   a created user or an existing user already logging on your site. So it tries to be really simple. There's the complexity of going to the panel to create this application and certain requirements from from these providers.   But then on the Python side, it's   set of settings, a URL, a link, that's all. But   if you want to   extend the the functionality,   like the previous example, download on the profile picture,   the work is a little more involved. You need to figure out which are the   permissions,   name, or scope name you need to use to be able to access this this profile feature from Google, for example,   add that scope to a setting.  

With the scope there, you will get granted access to the API that provides the picture, and then you can call this   API to download the the file and store in your in your public storage or where it needs to be. So they're they're really simple,   solution.   It usually   is enough for everybody or for most of the projects. You want more involved solution, you can do that. There's room for for that, and that's what's the goal of the project too. And another concept that's often conflated with authentication  

[00:20:44] Unknown:

is that of authorization,   and I'm wondering   how you handle that aspect   of the overall process of identification   permissioning   in Python social auth, or if that's something that you leave entirely to to the developers as a separate concern from what you're trying to tackle in this library.  

[00:21:02] Unknown:

Yeah. Python sellout actually doesn't care about that at all.   I understand there's an abuse of authentication   protocols that go out,   and they are even if they are only to authorize access to API, they can also be used to create a user on your side,   authenticate the user in your side. So   the there's   a a fine line there that you you could usually cross   out out OAuth is used for authentication as well. In the end, it's up to the developer to   decide who want to use OAuth   for authentication   or just authorization to access APIs   on behalf of the user.  

My experience is that OAuth is the most common protocol  

[00:21:47] Unknown:

around the web. They use it's usually used for authentication as well as authorization. Yeah. And in terms of the scope of the application that is granting these identities to the users, authorization also takes on a different scope of what they're allowed to do within the application, which is not something that you necessarily   want to rely on   3rd party identity providers and their scopes of determining and something that you would have to build as a primary concern for your own application. And I know that there are a number of other libraries available for Django and other frameworks for handling that concern, which is definitely a separate and, differently complex beast to tackle. And then   in terms of the   protocols that you support, as you said, a number of these identity providers are using   now OAuth 2, but also some of them are using OAuth 1. And then there are things like OpenID and SAML, and they all have different variations of how they handle the overall flow. And I'm wondering what you have found to be some of the most   interesting or unexpected or challenging lessons that you've learned in the process   of building support for all these different authentication protocols into this library?  



[00:22:56] Unknown:

So I was lucky enough to be able to build Python's allowed,   on the shoulders of other bigger projects like OpenID,   Python ID, or,   there's also some   library that will integrate with the will provide you the access to the protocol   on a simple way. So   it wasn't that difficult to   integrate the different protocols   all as since Python to see a lot actually cares about the bare minimum solution to the problem, it actually requests little very little from this library. Usually,   URL that the user is going to be sent to grant permissions,   input the credential, current permission, etcetera.  

And then there's   a secondary   API that gets called most of the time, it gets called to get some extra details.   OpenID has the difference. The these user details are already provided in the response   back to to your site. But   this complexity is all hidden   on these libraries   I use or this little small complexity that I need to implement on Python to fill out in order to to access the needed attributes.   So in the end, the authentication flow is similar   on the different protocols. You send the user to a site, the site gets sends the user back to you.   You exchange a few,   attributes from API,  

[00:24:26] Unknown:

and that's all. Yeah. And that's all the Python SQL actually cares about. And as somebody who has been working in the space of federated identity for so long, I'm curious what your thoughts are on the current state of affairs   in terms of the available protocols, and if you think that there are any missing elements or if there's space for a new protocol to be defined that will improve upon the existing set that we have or any shortcomings in the protocols that you deal with on a day to day basis.  

[00:24:55] Unknown:

I I still have strong opinions about different protocols. I know they're there to solve different problems.   I really would like to see a unified   protocol that removes the cuts within OpenID and OAuths, for example, which are the most common protocols around the web, up to date. Having a single solution that provides both, like, all of this used today is actually abused today to do authentication or something similar   that merged OpenID,   OAuth could be a a nice solution to see around. So   from a from a developer perspective today,   they they actually have the the option to avoid the hassle of integrating social media authentication on their side or the many sides or the different protocols. Even Atlassian that tried to solve the the differences, there are   simpler solutions today,   services that will provide you social authentication or user authentication   as a service if reduce actually the work you need to do. So in the end, for developers, which are is the word I I care with this library is is becoming even simpler to add  

[00:26:00] Unknown:

this feature to your site. And in terms of your   experience of using Python social auth or your conversations with people who have been using it for their own purposes, what are some of the most interesting or unexpected or innovative ways that you've seen it used? So I I don't usually get feedback  

[00:26:17] Unknown:

or, you know, how do ways   the delivery is being used? I usually log   on a blog post here or there or something pop ups on on my Twitter feed.   But there was a party where a project that probably   gains the   wins the contest,   of being innovative. And he was a user   using Python to sell out to authenticate   or   and once authenticated,   he the garage door of the house open or close. I don't remember the details now, but I don't remember if you you log in and you have the control of the garage door on on this website or, ultimately, by logging in, you your garage door will open or close depending on the state. It was a really fun read. I I can't I can't find the blog post anymore.  

[00:27:05] Unknown:

Yeah. Yeah. It's definitely an interesting way to abuse the pipeline where you can run arbitrary functions just as a result of different stages completing. So Yeah. Indeed.   And then in terms of your experience of building and growing the community around it, I'm wondering   how that has evolved and   just some of the overall benefits   and learning ex experiences that you've had as a result of it gaining popularity,   and then splitting into its own GitHub organization  

[00:27:33] Unknown:

and onboarding new committers and maintainers to the project? Yes. So certainly, there are no more maintainers on the project.   I tried to add a few a couple years ago,   and the experience upgrade didn't work out. I I it's not that, they were bad materials or anything.   The   but the the in the end, the the the amount of work, that the the person did it. Okay. They they abandoned   the the effort so that, I discarded that option   since then,   sadly because I I really would like to delay a a lot of the work that is needed for the library. I'm at a point of my life where dedicating time to Python scale out is   will be something I'm trying I I'm struggling with. New maintainers will be really welcome to to to the project to provide   the efforts and the different development,   that's is needed,   at the moment. I have a big list of different items I want to work on there. The area that I need to find the time to take into it. And right now, I'm in quarantine on a low maintenance mode where I go in, review the different pull request, request some change of a merchant, a few here and there, and then,   release a new version of the library with the last   request merchant.  



[00:28:49] Unknown:

And in terms of the primary focus,   it definitely seems like,   particularly given its origin of being integrated with Django, that it's primarily used in web contexts.   But is it viable to use in other types of environments where it's primarily just for authenticating between back ends or   maybe in terms of some sort of industrial automation or Internet of things context? Or is it primarily just focused on a web environment and,   anything that people might choose to use it for outside of that context? They're sort of treading their own path. So up to date,  

[00:29:24] Unknown:

it remains a web   only solution.   There's still my plans improving that area with the introduction of strategies on on Python to see that   open the door to implement   new ways of integrating the library on on new places.   I I really would like a solution that's fully   console   integration that you can they usually   token   number is is based on the console or stuff like that or or or a UI. It doesn't need to be a web 1.   That's 1 of the strategy I would like to work at some point. But, yeah, the door is open to to integrate it with more environments,  

[00:30:03] Unknown:

not just web. And what other plans do you have for the future of the project, either in terms of the technical aspects or community aspects or just your overall,   ambitions of where you might take it or additional projects that you might build within its ecosystem?  

[00:30:19] Unknown:

So for community,   I I don't have any particular plans.   It has its own flow as it is right now. I can put requests from time to time, and that's that's good enough in in my opinion. Technical aspect, yeah, I have a quite a list like Python 2,   for the mobile,   Python 2 support mobile,   async on a way to support, integration   with newer microframeworks,   like FastAPI   or sonic,   implement a pure   WCGI,   GI,   or HSGI,   strategies that they actually don't depend on any framework, non web   integrations   and improvements here and there. It's it's good. I can mean to integration this. You need some law.   I know better than I right now. I know I can do a better call there. And, of course, documentation. The documentation   needs a lot of work in improve examples,   improve documentation on how to implement   new strategies, new back ends, new integration,  

[00:31:20] Unknown:

etcetera. There's a lot to do. And are there any other aspects   of the work that you're doing with Python social auth and the library or any of the associated topics with identification and authorization and authentication that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:31:36] Unknown:

No, Roger. You know, I I actually like Python Celaus. It is trying to solve the bare minimum to the program.  

[00:31:43] Unknown:

I I would I really like to to keep it that way. Okay. Well, for anybody who wants to follow along with the work that you're doing or get in touch or offer contributions, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the picks. And this week, I'm going to choose the Joker movie, which came out recently. I think they did a very good job of portraying the character and giving a believable and meaningful origin story and,   a lot of really good acting throughout. So for anybody who is at all interested in that, overall story space of the Batman, Mythos, and the DC characters, it's definitely worth a look. Not your typical Superman story, definitely much more character driven, but worth a watch. And so with that, I'll pass it to you, Matthias. Do you have any this week? Yeah. I have a a technical 1 that I  

[00:32:30] Unknown:

I'm really enjoying using,   this new microframework,   Sonic, which focus on async and await,   support on Python 3. I I really have some fun. It's close to Flask on API,   It has its   own small things that make very comfortable to work on. No technical peaks.   I'm really looking forward to the to watch the new Star Trek Picard series.   I'm really looking   forward to that. I'm really fond of this of the of the saga,  

[00:33:01] Unknown:

and this 1 is fully promising. Alright. Well, thank you very much for taking the time today to join me and discuss your experiences of building the Python social auth framework. It's a tool that I've used pretty extensively in the projects that we do at work, and it's made our lives a lot simpler. So thank you for all of your efforts on that front, and I hope you enjoy the rest of your day. Thank you very much. Thank you for for having me over.  

[00:33:24] Unknown:

Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at dataengineeringpodcast.com   for the latest on modern data management.   And visit the site at pythonpodcast.com   to subscribe   to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email host at podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.