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

71–80 of 116 posts

Re: Nobody Cares About OAuth or OpenID Connect

#71

Post by fixermark »

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…

Okta's position in this article is missing the bootstrapping problem.

Yes, you don't want people rolling their own crypto libraries. But if nothing has been rolled yet for your environment by anyone? You need a standardized open protocol that you have at least a chance of rolling correct crypto against.

Closing that protocol up in a nice shiny (but exclusively-owned-and-maintained) box does you no good if the box can't be bent to fit your use case.

Re: Nobody Cares About OAuth or OpenID Connect

#72

Post by scopendo »

SomeHacker44 wrote: post #49

I recently built an app that outsourced the entirety of the account creation, email validation, MFA and authorization to AWS Cognito and AWS ELB. All I have to do is verify a signed JWT passed in by a header by the ALB (and configure all that stuff and automate it into CloudFormation). Never building this infrastructure again. What a huge time saver. My company used Okta. We ended up cancelling it as it did not seem…

Is that architecture helpful for a saas app that needs to support users from corporate customers using single sign-on via an OIDC or SAML provider like Azure AD or ADFS?

I looked into using Okta or Auth0 for this sort of setup, but both were prohibitively expensive for a saas app.

Re: Nobody Cares About OAuth or OpenID Connect

#74

Post by dexwiz »

MrStonedOne wrote: post #73

This article kinda glossed over what the fuck openID Connection is actually for. Like in a big way that I have no idea what the fuck OpenID is, what authorization and authentication are in this context, and why oauth doesn't handle both.

Authorization = Can I do this?

Authentication = Am I this person?

Technically, OAuth only cares about Authorization. It provides an opaque token to the client that authorizes future requests. It doesn't tell the client anything about who the token is for.

Turns out most clients need to know who is logged in (such as loading basic profile information, email address, avatar, etc). In practice this is usually done through some sort of /user endpoint that accepts an OAuth token. This /user endpoint implementation is service specific.

OpenID Connect tries to fill that space by providing a standardized way to perform authentication and identity information.

Re: Nobody Cares About OAuth or OpenID Connect

#75

Post by simonw »

dcbadacd wrote: post #68
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…

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

Thanks, that looks pretty good: https://flask-dance.readthedocs.io/en/latest/providers.html#...

Re: Nobody Cares About OAuth or OpenID Connect

#76

Post by Dowwie »

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…

I appreciate your blog posts. They're consistently interesting and useful. If you can do what you love and align that with your work, more power to you.

Re: Nobody Cares About OAuth or OpenID Connect

#77

Post by zxcvbn4038 »

AdeptusAquinas wrote: post #37
rossdavidh wrote: post #28

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

Its baked into ASPNET Core, and its still a pain in the ass. 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…

That is another good point - generally you want to force a user to reauthenticate whenever they enter an elevated security context (account management, personal information, etc). With the OAUTH flows there doesn’t appear to be s way to do this. If I tried to send them through the login process again, they would just end up back at my callback address because their token was still valid.

Re: Nobody Cares About OAuth or OpenID Connect

#78

Post by javier2 »

wvh wrote: post #47

I implemented a minimal OpenID Connect server internally a few years back when it was difficult to find something for our specific use case in Go. I think that while the general idea is good, the spec is a mess: it's too flexible in all the wrong ways, so every large player implements it slightly differently, leaving you with no clear path to go yourself; and actually making the protocol (... concept?) less secure th…

> I think that while the general idea is good, the spec is a mess: it's too flexible in all the wrong ways, so every large player implements it slightly differently, leaving you with no clear path to go yourself

This was my experience doing _anything_ at all with OAuth. Now I am seeing the same with OpenID Connect, though not as severe. The spec was narrowed a bit, but it is still way too broad.

Re: Nobody Cares About OAuth or OpenID Connect

#79

Post by taf2 »

abelhabel wrote: post #57
alexk wrote: post #45

Earlier quoted context omitted.

My favorite identity provider of all time is https://auth0.com I was very impressed by their rules concept [1] that allowed me to create quite non-trivial authentication scheme in one day from scratch [2] They also pay attention to development workflows by having great logs and debugging tool chain as a part of their service, very cool! [1] https://auth0.com/docs/rules [2] https://gravitational.com/blog/aws-github-ss…

Auth0 do the same thing though. They make library abstractions such as "passwordless" and make it a separate authentication flow altogether, where as in reality it is just a matter of generating temporary passwords. There is no need to not be able to just enable and disable temporary passwords for any user. Also, try implementing generation of API-key like tokens for users that can be expired, revoked, authorized etc…

Sounds like there is room in this market for competition

Re: Nobody Cares About OAuth or OpenID Connect

#80

Post by whatusername »

arkh wrote: post #46
colemickens wrote: post #39

Here's my problem with OIDC and I don't know where to bring this up to find out if my hopes are widely off or I've missed something big and it already exists... 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 dra…

And a problem for the Resource Server: no common way to check the validity of a token. You may be lucky and get a JWT but even then there's no specified URL to get the keys to check it. Usually you get an opaque token and hope the client gives you a way to know where it comes from so you can do some specific server to server call. So you can't implement an independant RS which does not care about clients and how they…

That's what the Introspection endpoint should be for.
Post reply on HN