[1]https://github.com/IdentityServer/IdentityServer4 [2]https://auth0.com/
Nobody Cares About OAuth or OpenID Connect
41–50 of 116 posts
Re: Nobody Cares About OAuth or OpenID Connect
#42The 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.
Re: Nobody Cares About OAuth or OpenID Connect
#43I'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 :(
Re: Nobody Cares About OAuth or OpenID Connect
#44> 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
#45I'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 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
#46Here'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…
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
#47I 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
#48I'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…
[0] https://developer.okta.com/authentication-guide/saml-login/ ; https://gravitational.com/teleport/docs/ssh_okta/
Re: Nobody Cares About OAuth or OpenID Connect
#49Never 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
#50Earlier 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…
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.