Live data from Hacker News

Nobody Cares About OAuth or OpenID Connect

developer.okta.com

41–50 of 116 posts

Re: Nobody Cares About OAuth or OpenID Connect

#41
If you need to implement your own OIDC/OAuth I highly recommend Identity Server 4[1]. I've used it in production and it was fairly painless to get up going. It's .NET based & battle-tested. It has lots of samples on GitHub to show you how to get going for the various flows (which they even walk you through in their docs) and has a quickstart UI so you've got something you can brand quickly to give users a contiguous login experience. However, if you can manage not to host your own (don't want to mess with it), I recommend either Auth0[2] or the one of the AWS/Azure solutions mentioned elsewhere.

[1]https://github.com/IdentityServer/IdentityServer4 [2]https://auth0.com/

Re: Nobody Cares About OAuth or OpenID Connect

#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.

Re: Nobody Cares About OAuth or OpenID Connect

#43
post #4
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 :(

Interesting, someone I worked with at a previous job left there to go to Okta. He did our Django/python Auth stuff. His Linkedin says he's still at Okta.

Re: Nobody Cares About OAuth or OpenID Connect

#44
post #22

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

When I read about that, I lost my mind. People who give their banking creds to someone who isn't their bank are insane.

Re: Nobody Cares About OAuth or OpenID Connect

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

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-sso/

Re: Nobody Cares About OAuth or OpenID Connect

#46

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 authenticate their users.

Re: Nobody Cares About OAuth or OpenID Connect

#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 than it could be.

I kept thinking that for our use case, a simpler aead token or perhaps something like Maracoons (if there would be more battle-tested libraries for it...) would suffice. In the end I implemented a partial solution with one flow and one JWT signing algorithm so the other services could rely on existing client libraries for their respective programming languages.

Of course none of it ended up being used, as SAML (there's another can of worms...) support became a requirement and some large framework was brought in for that corporate software feel-good factor...

I agree with the sentiment that it would be nice if there would be new development in this area, even (or especially) if none of the big players are involved, but non-trivial crypto protocols and frameworks seem to need a lot of momentum to break out of their local ecosystems. It's not easy to design something that fits different use cases yet doesn't break at the joints.

Re: Nobody Cares About OAuth or OpenID Connect

#48
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 also ran into issues with using the Okta OAuth/OIDC integration with Teleport and ended up using SAML [0]. Perhaps more painful, especially if you are more familiar OAuth/OIDC but it worked. This was when Okta OAuth/OIDC was still in beta so perhaps it has improved since then.

[0] https://developer.okta.com/authentication-guide/saml-login/ ; https://gravitational.com/teleport/docs/ssh_okta/

Re: Nobody Cares About OAuth or OpenID Connect

#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 to offer any value whatsoever and was crazy expensive for our 300-odd users.

Re: Nobody Cares About OAuth or OpenID Connect

#50
post #12

Earlier quoted context omitted.

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…

This is an implementation issue, not a spec issue. Pages can delegate to another identity provider (primarily used for vanity URLs, for example I could say that https://nullable.se/ should map to my Google OpenID, for example), and the identity provider can claim a different URL than you asked for (for example, Steam always uses https://steamcommunity.com/openid as the provider, but will claim a different URL for eac…

> That they didn't says more about Google than OpenID.

HN did the same thing. In fact pretty much every OpenID site implemented this weird expectation. Part of helping a standard get adopted is making sure it's implemented correctly.

Post reply on HN