11–20 of 116 posts
Original OpenID implementation was so simple and the scope of it was so small, i wonder where we got all this complexity
https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45...
Original OpenID implementation was so simple and the scope of it was so small, i wonder where we got all this complexity
OpenID Connect just standardised the existing practice of being authorised to use an identity provider as a type of authentication.
Edit: actually something something o8:
https://www.google.com/accounts/o8/id
Again, this was required for USERS, not developers.
This is someone asking how to log in: https://webapps.stackexchange.com/questions/18899/how-do-i-f...
I understand there are cases and people when this is needed but as for me I bloody never want anybody to access my "user data in another service" and that's why I strongly prefer plain old email sign-up: in many cases if you sign-up with your google account the service will also request your contacts list, your personal details and everything and I never want to share these.
Nevertheless the single sign-in feature OAuth/OpenID provide seems very convenient (unless implemented improperly when the service would take your OpenID and still ask you to set a password, a login name and/or e-mail address) so I still use it for some services.
Earlier quoted context omitted.
We don't have any official Okta Python library support at the moment :( We don't have any full-time Pythonistas on staff right now, so deprecated our old stuff. We're hoping to hire and expand that role out to build proper SDKs + support in the future. Right now, the best option is to use generic OIDC/OAuth compliant libraries (since Okta is a generic OAuth/OIDC provider). Sorry :(
The company I work for recently became an Okta Partner... and I'm a Software Engineer that primarily works in Python. I am expecting this quarter to start building out a platform that will use Okta for authentication and authorization. Do you think Okta would be willing to pay for some engineering hours if we were to take on the mantle of producing a modern Python SDK? If so, I'll be happy to start running that up th…
Except this is Hacker News, where caring is fundamental. I'll pass on the Okta advertisement.
> Back in pre-2007, there was no way for developers to build apps that needed to securely access user data in another service. I understand there are cases and people when this is needed but as for me I bloody never want anybody to access my "user data in another service" and that's why I strongly prefer plain old email sign-up: in many cases if you sign-up with your google account the service will also request your…
The ideal use case here is for banks, and services that store a lot of sensitive data. If you want to pull your data from your bank into a service like Mint, you would ideally like for Mint to only get read access to your transactions, nothing else: no ability to send $$$, etc.
One specific problem I've faced is that it's very complicated to configure a development environment for unit and integration testing. I think there is huge demand for something that works well for Docker Compose and unit testing frameworks while still being a production grade solution.
I haven't evaluated everything out there but so far the best solution I've found is Keycloak. Unfortunately it takes 20 seconds to start on my computer and up until very recently I had to go through the configuration procedure each time you launched tests. I was fortunate enough to get a PR (https://github.com/jboss-dockerfiles/keycloak/pull/152) accepted which allowed me to load a working configuration file directly into the unaltered Docker container with some users and roles for testing purposes.
So if you have something that starts quickly, is easy to combine with Docker Compose and with unit testing frameworks, and could be used in a production scenario... Let me know. ;-)
Oh, and it also needs to be on-premise.
A lot of people just don’t have the background to do good security work, and when you try to explain why a short lived credential is good, or why we can’t have a plain text password embedded in the git repo, their eyes glaze over and you lose them. So it’s much easier to just dictate it will be a tls connection and you’ll use OAUTH, and then they go download a library and everything is good.
Where I ran into problems is with using OAUTH for federated user logins. I did a proof of concept with Facebook, then after a couple hours they decided I was a robot and that was that - account closed, no recourse. Luckily that happened before I had a large user base using it - I don’t know what you do if Facebook decides your a robot and suddenly 50,000 people can’t authenticate to your site, guess you learn something. A week later most of the other sites decided I was a robot and terminated my accounts. Google is the only site that didn’t. (Which is good because I have a decade of e-mail and photos I’d hate to lose)
tl;dr nobody cares how the sausage is made. they just want the sausage. they are hungry.
I'm trying to build a simple Python app that authenticates against corporate Okta right now. It's incredibly, painfully difficult. If you search for "Python Okta" you get this: https://developer.okta.com/code/python/ > At this time we do not support official API client libraries (SDKs) for Python. You may fork our legacy Python SDK or join the conversation on this thread and let us know how you’d like to use Okta fro…