Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody Cares About OAuth or OpenID Connect

developer.okta.com

Post reply on HN
Print view View original

21–30 of 116 posts

Re: Nobody Cares About OAuth or OpenID Connect

#21

Post by rdegges »

aclimatt wrote: post #15

The article provides a very light history and technically shallow description of OAuth and OIDC so it can advertise Okta. Essentially, "these two protocols are complicated, and you probably don't care, so you should buy Okta." Except this is Hacker News, where caring is fundamental. I'll pass on the Okta advertisement.

I'm legitimately not trying to advertise for Okta here at all.

This topic is near and dear to my heart because I've been working in this industry for many years now, and it is frustrating that there is a huge focus on building more OAuth/OIDC tools and encouraging developers to get directly involved in working with things like JWTs directly.

There are so many ways to mess things up at foundational levels today, I just really want to see better tooling created in the open source communities (and in paid products) to abstract things like OAuth/OIDC so that developers don't need to constantly be fiddling around with these lower level protocols where the risk for messing up is extremely high.

Re: Nobody Cares About OAuth or OpenID Connect

#22

Post by wil421 »

qwerty456127 wrote: post #13

> 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…

Just think about companies like Mint who scrape your banking and financial information using your creds. Not sure if Mint has changed this or not (or if the banks opened an API) but at one point it was the case.

In the enterprise space these solutions help a lot. Especially with the rise of enterprise cloud software solutions like Salesforce, Workday, and ServiceNow.

Re: Nobody Cares About OAuth or OpenID Connect

#23

Post by rdegges »

wil421 wrote: post #22
qwerty456127 wrote: post #13

> 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…

Just think about companies like Mint who scrape your banking and financial information using your creds. Not sure if Mint has changed this or not (or if the banks opened an API) but at one point it was the case. In the enterprise space these solutions help a lot. Especially with the rise of enterprise cloud software solutions like Salesforce, Workday, and ServiceNow.

They still do that for 99% of the banks, since most banks don't support OAuth/OIDC yet :(

Chase recently switched over to OIDC which was pretty neat, but for most banks, it is an absolute nightmare.

Re: Nobody Cares About OAuth or OpenID Connect

#24

Post by mraible23 »

tofflos wrote: post #17

I agree that the learning curve is too steep with OAuth and OpenID and that supporting multiple scenarios could be part of the problem. 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 soluti…

I agree that Keycloak + Docker Compose is a great combination for development and testing. We use this setup in JHipster (https://www.jhipster.tech) when you choose OIDC for authentication. It auto imports users, roles, and OIDC apps so everything works right away.

Re: Nobody Cares About OAuth or OpenID Connect

#25

Post by merlincorey »

rdegges wrote: post #14
merlincorey wrote: post #10

Earlier quoted context omitted.

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…

That is awesome! I'm going to forward this comment to our DevEx team and see if that's something we could do. Sounds great to me =D

Excellent -- I sent you an email to the address in your profile from my work email in case anything comes of it.

Re: Nobody Cares About OAuth or OpenID Connect

#26

Post by simonw »

rdegges wrote: post #4
simonw wrote: post #2

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 :(

I don't particularly need a Python SDK. What I need is extremely clear documentation on how to roll my own authentication code against Okta - the equivalent of https://developer.github.com/apps/building-oauth-apps/author...

Re: Nobody Cares About OAuth or OpenID Connect

#27

Post by qwerty456127 »

rdegges wrote: post #16
qwerty456127 wrote: post #13

> 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…

That's one of the nicer things about these flows: you can have scoped data that is allowed, and nothing more. 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.

> That's one of the nicer things about these flows: you can have scoped data that is allowed, and nothing more.

IIRC the user is rarely given a choice, same as when you install an Android app from the Google Play store - they just tell you the app demands to access this and that an give you an Ok/Cancel choice instead of options to allow or disallow access to every particular element in the app's demands list and still install it regardless to what does the app author want (I don't mind if some features won't work then). IMHO this is seriously wrong.

Re: Nobody Cares About OAuth or OpenID Connect

#28

Post by rossdavidh »

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 "baked in". Many other features which are less common, are, or else have middleware that makes it pretty much just "add this line to your config file".

I have had to mess with Oauth two or three times in ten years, so needless to say I am hapless at it. If I did it less often, or more often, it would be fine, but it's not. Does anyone know why this isn't rolled into frameworks like Django, as a boolean that you set to TRUE?

Re: Nobody Cares About OAuth or OpenID Connect

#29

Post by brlewis »

woranl wrote: post #9
rdegges wrote: post #7

Earlier quoted context omitted.

I agree! I really liked OAuth 1.0, especially from a security POV. But, the working group has moved on, and OAuth 2 is the standard now :x

Not everyone is using OAuth 2. Mastercard makes a security decision to stay with OAuth 1.0a. https://news.ycombinator.com/item?id=17482178

Also twitter whenever the app is supposed to act on behalf of a user. (OAuth 2 is simpler, and is available for accessing public data not on behalf of a user.)

https://developer.twitter.com/en/docs/basics/authentication/...

Re: Nobody Cares About OAuth or OpenID Connect

#30

Post by jessaustin »

rdegges wrote: post #21
aclimatt wrote: post #15

The article provides a very light history and technically shallow description of OAuth and OIDC so it can advertise Okta. Essentially, "these two protocols are complicated, and you probably don't care, so you should buy Okta." Except this is Hacker News, where caring is fundamental. I'll pass on the Okta advertisement.

I'm legitimately not trying to advertise for Okta here at all. This topic is near and dear to my heart because I've been working in this industry for many years now, and it is frustrating that there is a huge focus on building more OAuth/OIDC tools and encouraging developers to get directly involved in working with things like JWTs directly. There are so many ways to mess things up at foundational levels today, I jus…

Advertisements with their hearts in the right place are still advertisements. If your tool were open source (it may be? not clear from TFA...) no one would complain. Since it's commercial and TFA takes such an anti-hacker stance, the complaint above is not surprising. It's not difficult to imagine that TFA might be very effective in speaking to some of your customers. With the customers who hang out here, a different essay with a different emphasis (e.g. "this is how everyone gets OAuth wrong and here's how we do it right") might be more effective.
Post reply on HN