I'm trying to figure out how modern internal API management should work like and started https://www.appear.sh/.
After spending so much of my career dealing with APIs and building tooling for that I feel there's huge gap between what is needed and possible vs how the space generally works. There's a plethora of great tools that do one job really well, but when you want to use them the integration will kill you. When you want to get your existing system in them it takes forever. When you want to connect those tools that takes even longer.
The reality I'm seeing around myself and hearing from people we talk to is that most companies have many services in various stages of decay. Some brand new and healthy, some very old, written by people who left, acquired from different companies or in languages that were abandoned. And all of that software is still generating a lot of value for the company and to be able to leverage that value APIs are essential. But they are incredibly hard and slow to use, and the existing tools don't make it easier.
After working in video streaming company for several years and writing web player (on top of vjs & shaka) used by millions of users every month I both agree and disagree with the article at the same time.
Streaming video is too hard, 100% agree with that, but <video/> element is the reason nor the biggest problem. Biggest pain in my opinion is DRM. That is huge pain in the ass which is poorly standardised (getting better but still) and is constantly broken. Second is transcoding, which is hard because it is hugely complicated problem. Even after the years I don’t feel I understand more than 10% of what is going on. Luckily there are companies like Bitmovin and Mux that can help with those 2. Distribution of the video is easier with modern CDNs, it’s just insanely expensive.
Where we could do better though is to better integrate low level libraries like VideoJS and Shaka to web frameworks like React or Vue. Everything that is out there feels like hobby project someone just played with. Full respect and big thanks to the authors for putting it out though. You did way better than me in supporting open-source.
The html video tag is the smallest bit of the problem, adaptive streaming is much more complex and there isn’t just one file per resolution.
CultureAmp | Software engineer, Backend, Frontend, SRE | Lead, senior, mid | Full-time | REMOTE or Melbourne, AU
CultureAmp is a rapidly growing company empowering our customers to build Culture First workplaces. Our market-leading, category-defining Engagement product has been the engine of our success. In 2019 we added an award winning performance management solution to our portfolio. These two products together enable us to deliver highly differentiated, powerful and industry-leading capabilities to our customers including Slack, Airbnb, Etsy and thousands of others.
We are looking for several engineers to join the mission. From SRE, backend to frontend. From lead to junior. If you desire to drive technical change and excited by writing the code that powers a product you believe in, then we'd love to speak with you. There are many parts you can play and many ways how to accelerate our mission to positively affect the lives of a hundred million people at work.
Our stack includes AWS, Ruby, TypeScript, Go, Kafka, MongoDB and many other cool tech.
I have very similar experience in very different field.
About 8 years ago, we've built a SAAS for purchasing material for companies using auctions. The idea was that if it will be super easy for companies to do reverse auctions and use them to buy material they will save a lot of money (proven concept in those who actually used it).
But what we learned after some time was it didn't matter. Because people in the companies responsible for buying material didn't really care for how much they buy it. They care that they call their favourite supplier have a nice chat and then order whatever they need. And those suppliers throw some "gifts/rewards" to the package here and there. And without appraisal of those people the business owner never said yes.
The thing was that those people who effectively decided if they will use it or not didn't benefited from it at all.
We haven't lost so much money on that, but the lesson learned was huge.
The battle between OAuth 1.0a, 2.0, and OIDC is really long and drawn out and doesn't seem to have a clear winner which I think is hurting everyone (though of course some companies are winning because they can support everything and offer that as value).
I sure do wish people would just standardize on OIDC...
It’s unfortunate. Big companies are pushing for OAuth 2.0 and trying to blindsided people as if it is an upgrade to OAuth 1.0a. It is not. OAuth 1.0a provides authenticity, integrity, and non-repudiation. Something that OAuth 2.0 does not provide.
large providers will drag their feet kicking and screaming because the prominent 'login with facebook / google' link are both selling point of their platform and monitoring opportunities for third party users.
But not the extensions the GP cites as meaning OIDC solves the same problem. And even if they did, I don't think it allows to isolate your identity from the identity provider you currently use, which seems to be a key aspect of IndieAuth: You can delegate the role of Identity Provider to a third party, but can change that third party, similar to how you could in "original" OpenID.
Of course you can isolate the identity from the identify provider. It's fully supported by OIDC. It's a main use case for every website that wants to manage its user accounts.
Right, seems I misunderstood it last time I looked at that spec or was misremembering, re-reading it one could of course point to an external service. Is there an actual implementation of that in the wild, that I e.g. could use with my e-mail address at my domain? Even support for discovery at all seemed basically non-existent.
It's already available if you use any of the major email provider.
If you want to provide it from your own domain, it's perfectly doable, but it takes a lot of work to setup. This won't be usable from other sites though because they won't trust yoursite.com
Discovery is non existent because it makes zero sense in practice.
Ok, so you confirm that while the standards theoretically exist, OpenID Connect doesn't provide those features from OpenID in practice (where they did make sense for some reason?)
You don't need trust to the domain if you just want "an identity" to recognize a user, which is the use case for many services: basically as soon as you allow e-mail + password sign-up, that's the only thing you get. OpenID did the same.
Delegation is helpful exactly because it is somewhat difficult to implement OAuth nicely. OpenID did the same.
Which I guess answers the original question of "why not OpenID Connect" with "because nobody in that ecosystem cares about those features, even if someone at some point wrote down how they can work".
I don't understand your complaint. I suspect you have a fundamental misunderstanding of identity management in practice, irrelevant of whether it's implemented with OpenID, OpenID Connect or SAML.
If you want people to register with anything, then just let them register with an arbitrary username and password. You don't even need an email or a domain.
I want what OpenID provided me: I give a site a URL to a page I control, and it goes there to figure out what service of my choosing to use to sign me in. I want this to be open, so I don't have to check with each site what whitelist of providers they accept.
I thus do not need to remember/manage a username/password pair per site, and am not tied to a specific service that might die, which was a big problem with the OpenID infrastructure dying bit by bit: those wo didn't use URLs they controlled to delegate lost their ability log in when the provider they used went away.
Most of the implementations were incomplete/broken, everyone wanted to provide OpenID while nobody wanted to consume it, and the few parties that did consume it got left holding the bag when the OPs ripped out support and left users without a way to prove their identity to recover their accounts.
You want at least a weak unilateral arrangement, such as Google or Microsoft or Facebook saying they have no plans to rip the feature out from under you any time soon.
Also, OpenID adoption was never going to happen with users being identified by URLs. No party was going to step up and explain to users why they should go through the effort of learning all this tech to use it vs. using the passwords they were already familiar with.
Because otherwise anyone could make an authentication provider that's authenticating as you@gmail.com and assume your identity.
Remember that the goal is to delegate authentication, user profile and/or user creation. It's implicitly trusting everything coming from the third party. For instance when supporting google login, it's expected that google only validate user accounts that really exist and are hosted by google.
Authentication cannot be bound to any email or format.
For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers.
For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers.
It's not a subset, it's a superset (or built upon Oauth 2.0 if that's the more accurate way to put it) -- I just read through the OpenID Core spec[0] today since I felt like I didn't know enough about it.
Does anything actually implement discovery? I looked at various OpenID Connect implementations a while back and nobody seemed to support it. It's a pretty big user-education problem if you can't just say "you can use OpenID Connect", but have to explain "you can use OpenID Connect, provided your provider supports Extensions X and Y, and they probably don't clearly document that they do, so please just try logging in here and see if it works".
Quite a few things implement discovery. Most IDPs advertise metadata, and many RP libraries consume it by default. IDPs even motivate them to consume it by rotating signing keys pretty often.
Not many things support dynamic client registration, which means the list of IDPs a site can use are pretty static.
When people talk about just "OpenID", they usually mean the original one, not Connect. The old OpenID did not have the ability to authenticate requests to the domain you signed in with.
OpenID Connect adds lots of bloat, it's very large and complicated. IndieAuth is actually easy to understand and implement.
Depends on your point of view. IndieAuth has a bunch of modifications to OAuth2 behaviors that may not be compatible with existing deployments, and requires software to implement things like full HTML parsing libraries to read out link tags. There were many incomplete OpenID 1/2 implementations, and compatibility greatly suffered as a result.
As someone who maintained an OpenID 1/2 OP for a few years, I would much rather implement OpenID Connect Basic Profile than IndieAuth.
IndieAuth, like OpenID 1/2, also assumes the user has a known profile page or even knows what a URL is, which are both statistically unlikely.
reply