31–40 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
OpenID (not connect) had a weird OpenID URL users had to care about. Mine was something something google something u8. Nobody cared. Sites like HN removed OpenID logins. OpenID died. 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…
Combine these, and Google would have been perfectly capable of making everyone just type google.com. That they didnt' says more about Google than OpenID.
Besides, people were perfectly capable of showing the same pickers back then as you are forced to use with the current OIDC/OAuth2 abomination.
> 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…
You're forgetting that local applications fall into this category too: email, calendaring, storage, messaging, remote access, music/movie streaming, VPN, Twitter, code repositories, container registries, cloud cli tools, chat, chatbots, database access, directory access.
Wouldn't it be nice if you never had to click "Save my password" or use a service account ever again?
You just included some javascript in your frontend, maybe a 5-line function in the backend, and people could authenticate to your web app.
No need to store a password and correctly crypt the hash, provide a password change function, provide a password reset function (what a PITA to get correct).
Why hasn't anybody created something comparable yet?
The redeeming feature about OAUTH, like pretty much anything security related, is that if you don’t give people a standard to follow then you are probably going to end up with something that is insecure and poorly implemented. 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…
This is exactly why I am paranoid about depending entirely on social sign up/in. So if the API provides it, I believe it's a good idea to capture the email address associated with the social account and either generate a hard password for later reset if necessary or request the user set one up. The latter obviously reduces a little convenience of the social sign up, but does hint to the user that they can sign-in otherwise and gives them control.
Authentication is just too important to completely outsource without recourse.
So, I know I'm naive and all, but it seems odd to me that this isn't baked into normal web frameworks. It is entirely ordinary for a website to want to allow a user to login using Google/FB/Yahoo/whatever other id's, so that they don't have to make a new id (and remember a new password) just for your website. Probably half of the websites made with frameworks want this. Oddly, if I want to do it, I rarely find this "…
Even though the middleware handles JWT validation, cookie storage, redirects etc (which are a big part of it) there are still a tonne of little details to OAuth that clients need to know enough to specify:
- what grant flow are you using (code, hybrid, implicit, resource owner etc.. all are valid for different and overlapping scenarios, based on how secure you want to be and how much hassle you want your users to experience)
- client id and secret management, and registering this with your server
- refresh tokens: i.e. how do I prevent my user needing to log in every 15 minutes without making my jwt last an insecure amount of time.
etc. etc. etc. I've built OAuth/OIDC into dozens of apps, and have deployed my own identity providers (not rolled my own, thank the gods, just used a framework for the server side) and its still the bane of my development existence.
There's nothing specified anywhere that allows an application to interrogate an RP about the available scopes. I just don't see how fine-grained resource access can be done with OIDC without requiring the user to grant much coarser access first. I found a draft spec once but it was abandoned and the author didn't reply to an email I sent...
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…
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 :(
My team did use Okta React briefly for an internal project but we couldn't get it to play nicely with Cypress (e2e testing) so we ended up removing it sadly.
I'm pretty sure we had just implemented it incorrectly though since we were still getting to grips with React at the time (as a team that previously had little to no combined UI experience) :)