Live data from Hacker News

Nobody Cares About OAuth or OpenID Connect

developer.okta.com

61–70 of 116 posts

Re: Nobody Cares About OAuth or OpenID Connect

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

I'm surprised no one has mentioned FusionAuth ( https://fusionauth.io ). It's free, has a Python library, and the features that most apps need. There are a couple of people using Python with FusionAuth right now. The community for FusionAuth is growing quickly and it has an open issue tracker ( https://github.com/FusionAuth/fusionauth-issues ), good docs ( https://fusionauth.io/docs/v1/tech/ ), and many open source p…

Running FusionAuth in Docker or Kubernetes is a huge benefit to those running on premise.

Re: Nobody Cares About OAuth or OpenID Connect

#62
The author of this article cannot be trusted. He regularly writes articles that compare non-best practices of JWT to best practices of other technologies to make JWT look bad. Because of him, I would not trust Okta at all. Take any article by Okta with a grain of salt.

Re: Nobody Cares About OAuth or OpenID Connect

#65
post #42

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.

Okta is not a replacement for either of those things, and I didn't see the plug in the article for their services that you mention.

It's at the end: "This is one of the reasons why [...] we spend tons of time and effort trying to build [...] client libraries [...] to hide those complexities and make securing your web applications simpler."

It may be the lightest of plugs, but it means that the writer is biased. Being biased doesn't mean you're wrong, but it throws the entire argument into doubt. I feel like I wasted my time.

Also, any security professional who just mentions in passing that OAuth was for authorization loses a little of my trust. It's true that Auth is short for Authorization. But an important nuance is that it isn't authorization for the user but for the application, authorization by the user for this new app to get some information from one of the user's old apps (like Google). For a programmer like me, this clears up why OAuth stands for authorization but always seemed more like authentication. From my understanding, OAuth doesn't handle any authorization of the user within your app. You have to handle that some other way.

Re: Nobody Cares About OAuth or OpenID Connect

#66

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.

Whose bread I eat his song I sing.

I have a ton of respect for Todd but yes, this writer is just doing their job which is to promote okta

Re: Nobody Cares About OAuth or OpenID Connect

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

FWIW, if all you're doing is authenticating a web application, you really can just do it off of the OIDC spec. It's a small subset of the protocol and can be easily understood. I did it recently, writing a multi-tenant application where each tenant can have its own OIDC providers, and it took me about three hours to do and to do correctly (verified against Auth0 and Okta, at least).

Barring that, Okta at least is a conformant OIDC implementation and you can use standard libraries for it.

Re: Nobody Cares About OAuth or OpenID Connect

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

I'm using Flask-Dance, it works rather nicely.

Re: Nobody Cares About OAuth or OpenID Connect

#69

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

Django doesn't work nicely with OAuth, but Flask has Flask-Dance which works rather well.

Re: Nobody Cares About OAuth or OpenID Connect

#70

The author of this article cannot be trusted. He regularly writes articles that compare non-best practices of JWT to best practices of other technologies to make JWT look bad. Because of him, I would not trust Okta at all. Take any article by Okta with a grain of salt.

What practices would that be? Both good and bad is interesting to me.

I recently decided against using jwt bearer tokens due to the concerns expressed in both rfcs and owasp of being to risky when compared to session cookies.

But really I’m wondering if the risk of screwing up csrf protection isn’t more of a concern than token leaks.

Post reply on HN