OAuth has been presented as a solution to the security issue of giving service username and password for third party integrations and it solved a lot of problems. It replaces the need to explain to people why we need their username and password, it is easier for them to integrate, and they usually have sensible permissions so we do not need to ask for something we do not need.
But creating these integrations can still bring problems. These can range from technical, team based and business related problems. From figuring out why the refresh flow no longer works after months to explaining to coworkers, why their solutions based on abstract understanding of the OAuth would not work to the dealing with people verifying your OAuth app.
Our teams developed and maintained dozens of OAuth integrations. This talk is going to go through multiple real-world examples, when OAuth can still cause friction for the developer working on it.
This talk does not assume any programming level or any Python knowledge. I will try to make it friendly to the OAuth beginners, but you will probably take more from the talk, if you had already tried to use OAuth before.
I am a software engineer at LeanIX. There I am being a part of the team that oversees more than hundreds direct integrations with different SaaS vendors.
I come from a cognitive science and economics background, so I am more likely to be interested in how to use Python to find out the answer to the social science questions, then going into the nitty picky details about kubernetes or CPython.