vwpolo3

That looks like a mistake in the doc:

- https://oauth.net/articles/authentication/

- https://tools.ietf.org/html/rfc6749 - The OAuth 2.0 Authorization Framework

It explains why OAuth2 is hard to use and does not solve login, registration, sessions, profile management, mfa, and proposes another solution. It’s all open source! :)

The first vulnerability is in the title, OAuth is an Authorization framework (Open Authorization) and is explicitly NOT for authentication. It’s also a delegation protocol (I give you something to do on my behalf).

If you want a list of things that can go wrong, look here: https://tools.ietf.org/id/draft-ietf-oauth-security-topics-1...

Generally you probably do not need OAuth2: https://www.ory.sh/hydra/docs/concepts/before-oauth2/

But if you do don’t roll your own but use proven open source like https://github.com/ory/hydra

Don't forget Ory:

https://github.com/ory

There are already true open source alternatives on the horizon such as https://github.com/ory

It is about time for a new generation of identity systems in my opinion. This acquisition shows the risk of centralized, vendor locked-in services.

Don't implement your own, there's tons of open source that can do that, for example https://github.com/ory/hydra

Without upgrade, this might be exploited through package managers able to fetch from Git URLs (so NPM, Go Modules, and others).

Ory | Open Source Software Engineer (Go, React) | FULLTIME | ONSITE in Munich Germany

We build stuff for an emerging cloud infrastructure. It's security, zero trust, hardcore bullet proof engineering. It's Golang, K8S, React, Hashicorp etc. - no more buzzwords! We are looking for people with a broad set of technical skills who are ready to take on some of technology's challenges and work with others to create modern world class solutions. We like React, Go and Kubernetes (among other things) and love learning how to push the boundaries with those technologies! Drop us a short introductory email to jobs@ory.sh. We believe that great engineering deserves to be paid accordingly.

https://github.com/ory https://github.com/ory/jobs https://www.ory.sh

The problem is that online news sources are (almost) all the same - low budget, second tier silos of mostly trainee journalists. They have an emphasis on clicks and outrage and constant updates to keep you engaged and are a secondary (or tertiary) driver of revenue. The only exception I know of are The New York Times and maybe The Intercept.

My tip is to read a (or more) actual (read: printed) newspapers:

- they are printed daily or weekly (e.g. The Economist), keeping you out of the "Breaking News" loop every 60 minutes; - they have more weight within the news organization because they are the primary driver of revenue; - are therefore written by actual professional journalists in a proper journalistic process.

I recommend just picking up any news paper and comparing that to the online presence of that news paper, you will notice the tremendous difference.

In my opinion, a lot of the "media mistrust" comes from the constant barrage of so-called "news" articles with the primary goal of being shared on social media and bubbling up in Google News. Just check how many news articles are 1:1 copies of AP or any other news conglomerate.

Username + Password with a cookie store is much better understood and harder to get wrong than implementing a full OIDC suite (server + client). If you're talking federated login, that's what OIDC is for. If you're talking "login", your opinion is misguided.

Sorry, but following a standard for federation is not a substitute for building a log in system, which is what most people want when building "a web app".

Yes, not only on a roadmap but in high priority and under active development (not in the public eye yet)

The blog posts and discussion was long ago (the video is 6 years old). Since then, that particular author acknowledged that (iirc) OpenID Connect solves many of the things he criticized. I have to look up the source, it’s been a while.

However, OIDC and OAuth2 are complex protocols which is also why we encourage most greenfield and small projects to avoid it unless explicitly required.

It’s also important to note that that particular person voiced criticism, but most of the biggest names in tech (GCP, AWS, ...) heavily rely on those protocols (+ extensions). His proposed alternative protocol Oz never got to real world adoption (to my knowledge) and has recently been archived. The prediction that we would see major OAuth2 security wholes within 3 years (so 2015j never came true. It doesn’t mean that he was wrong, but that there are opinions that contradict him, and that those opinions and voices have established themselves in the industry.

Yes, implementing both OAuth2 as well as OIDC according to spec is a significant development effort and countless teams and companies fail at pushing through, shipping incomplete or insecure implementations. If you’re greenfield, OAuth2/OIDC is with 99% certainty not the right fit for you anyways.

While not explicitly mentioned, PKCE is supported! And yes, that draft was an important guide during implementation.

It leaves the implementation of the login (enter /password, ...) and consent (may application X have access to your pictures?) flows up to the developers using HTTP Redirection flows. You can therefore integrate it much easier in existing applications.

Also, you have complete control over the ui and user experience and must not learn a template language (Keycloak) or fork (Dex) the project to customize it.

Compared to Keycloak, Hydra is much more lightweight (no JVM/JBoss). However, you need to implement the user database yourself and/or write your own connector for it.

Agreed, also while they can not be censored by the administrator of the website, they can still be censored (or moderated) by the Plugin Owner, right?

The open source ory ecosystem ( http://github.com/ory/ ) might have what you're looking for, but it's definitely for advanced usecases. I know a lot of people that worked with Auth0/Okta/AWS Cognito but got so frustrated by downtimes, bugs, and complexity that they moved away. But it is an option for rapid prototyping although I'd keep a "replace it" somewhere in my milestone planning. Another possibility is Keycloak which is very enterprise / java fullstack and quite complex to understand.

Most advice in the comments is pretty bad though. Stuff like "API Clients need bearer tokens" is completely backwards and pushed by marketing people from companies (Auth0, Okta, ...) that misuse open protocols (OAuth2, OIDC) as a way to legitimize the closed source saas approach they took. Along the lines "if it looks complex it looks secure because most people have no idea". It's actually very easy to use cookies (httpOnly, secure) with API clients and you're saving yourself so much complexity with refreshing tokens and all that stuff.

Yet another possibility for super rapid prototyping is: https://github.com/bitly/oauth2_proxy

edit:// I forgot KeyCloak, but it's also for advanced enterprise use cases (SAML, OIDC, Realms, ...) and (from what I've heard) with a steep learning curve and heavy.