What Is OIDC?

Building an entire directory app is hard though. And you want it to be highly resilient, right?

What do you recommend?

1000x this - each and every CAIM has their own "interpretation" of what the various constructs actually mean in the various RFCs and it leads to a lot of hodge-podge integrations that organizations outgrow. Things like Okta and Auth0 might seem shiny and easy on the face of it, and they are for very small startups, but quickly devolve into dogshit as you scale.

Lots of companies require sso for saas.

> the business risks are too great

Building authentication in-house is non-trivial to say the least. It is a dynamic service that fundamentally needs a database and is fundamentally accessible both to the wider public Internet (networking-wise) and to unauthenticated users (which attackers always start out as), which makes it incredibly difficult to secure. DoS, keeping everything patched on a moment's notice, rate limiting clients, emailing resets, ensuring your emails continue to be deliverable, suspending accounts hit by credential stuffing, having support processes for unsuspending accounts that are not themselves susceptible to social engineering... the sheer complexity of security engineering required to do this correctly and at scale is not even remotely trivial. Not to mention very strict performance/latency requirements because auth is overhead on everything, which gets to be difficult once services start to scale globally, and runs into direct internal contradictions when revocations compete against internal caching.

I appreciate the business risk of depending on a third-party for part of the foundation of your value offering, but the truth is, if you're not running your own datacenter and hosting your own databases (and therefore your databases are located in some vendor's offering, be it co-lo or cloud), you're dependent on a vendor for part of the foundation of your value offering. In and of itself, that's a pretty normal, expected, and acceptable business risk to take.

Not all businesses are the same, and I'm sure there are some where you need to run auth in-house (like if you're selling on-prem software), but I'm mindful that most companies simply cannot run auth securely. And when their security fails, their users' data leaks, and in a modern era, that too is a real business risk.

I cannot recommend https://ory.sh enough. Completely open-source and self-hostable auth. Great team too.

I couldn't disagree more strongly; you will screw this up if you roll your own. The only secure option is to push as much as possible outside of your infrastructure. The concerns that it won't be "auditable" or that you "give away the keys to your kingdom" are nonsense and implementation-specific. If it's important, then don't build your integration with those flaws. You will still have substantial control, so you can decide how "auditable" the auth actually is and what to do with users authed from one platform or another.

If you can avoid managing authn, you will be substantially better off. I don't think you can so easily do this for authz; however, it depends on what you're building.

This advice is wrong on some many levels. Building your own OIDC/OAuth/SAML infrastructure is incredibly expensive, error prone and dangerous; and not mention you need people to code it, run it securely, audit it, test it.

Even running something like a self-hosted Keycloak instance/cluster is not easy either and comes with its own set of problems.

I agree, with the implicit "build it in-house with OIDC certified 3rd party dependencies ". The foundation already goes a long way towards providing conformance suites and several certificates. I don't understand how we came into this status quo of "I'm just gonna outsource users data, XP and all to this company I have little transparency over, and its gonna be fine because I don't waste time maintaining infrastructure for auth which is my core business, much better to maintain the several sync points, settings pages they won't possibly do, and waste man hours inquiring about why this user password changed when they are telling us it didn't, and I can't tell them to ask Auth0?"

Friends don’t let friends build auth. Use open source, standards compliant solutions if you don’t trust a company. Just don’t reinvent the wheel.

> Don't outsource either your authentication or authorization. Run it in-house.

This is hard to do, though. I hope people here will drop a lot of self-hostable combinations that work for them!

Personally, for a small/medium scale project, I went with:

Keycloak: https://www.keycloak.org/

It supports various backing RDBMSes (like PostgreSQL, MariaDB/MySQL and others), allows both users that you persist in your own DB, as well as various external sources, like social login across various platforms, is an absolute pain to configure and sometimes acts in stupid ways behind a reverse proxy, but has most of the features that you might ever want, which sadly comes coupled with some complexity and an enterprise feeling.

I quite like that it offers the login/registration views that you need with redirects, as well as user management, storing roles/permissions and other custom attributes. It's on par with what you'd expect and should serve you nicely.

mod_auth_openidc: https://github.com/OpenIDC/mod_auth_openidc

This one's a certified OpenID Connect Relying Party implementation for... Apache2/httpd.

Some might worry about the performance and there are other options out there (like a module for OpenResty, which is built on top of Nginx), but when coupled with mod_md Apache makes for a great reverse proxy/ingress for my needs.

The benefit here is that I don't need 10 different implementations for each service/back end language that's used, I can outsource the heavy lifting to mod_auth_openidc (protected paths, needed roles/permissions, redirect URLs, token renewal and other things) and just read a few trusted headers behind the reverse proxy if further checks are needed, which is easy in all technologies.

That said, the configuration there is also hard and annoying to do, as is working with OpenID Connect in general, even though you can kind of understand why that complexity is inherent. Here's a link with some certified implementations, by the way: https://openid.net/developers/certified-openid-connect-imple...

Please don't write your security code from scratch and lean in the direction of just gluing various tested options together.

Our current production deploys for our B2B/SaaS banking product run "in-house" authentication.

We were essentially laughed out of the room when we showed our biggest prospect how we managed users in our legacy product. I felt really smug about my fancy hand-coded user management tooling until about 50% into the presentation when I could see an equivalently-smug look + mild sideways head shaking coming from the customer CTO. Running in-house authentication is literally a joke to many of these orgs in 2023. Most developers probably won't ever experience this. I think it is a shame, because this one experience forced us to embrace a new kind of light that much of HN probably won't ever see. Our roadmap was accelerated by this rejection.

Realizing that we might have lost a multi-million dollar customer over an ego trip was a bit of a wakeup call. I have some skin in this game. I don't know about the rest of HN. At a certain point, it's about making money and being able to sleep at night. Running in-house anything typically works against that (i.e. spending finite innovation tokens). Like it or not, if you are dealing with a big crusty organization, outsourcing authentication might become mandatory at a certain point.

Further, if something goes wrong and one of our customers gets breached, I don't want the investigation to wind up at a line of code in my codebase. That means I have to get involved in legal proceedings. I am completely out of the game of touching end-user passwords or MFA tokens now. We get claims from an IdP and that's that. We don't even write SAML/OIDC integration code because our tech partner has done that for us by way of a happy DDL election on our FaaS runner config. The authenticated user's claims are injected into our HTTP trigger function arg list, and since we do stupid-simple PHP-style SSR web apps, the rest is fairly obvious. We still have a "Users" table, but all that password hashing/salting/iterations crap is replaced by a simple UPN string field (i.e. the user's email address).

Above all this, use case matters most. If you are unregulated and dealing B2C with 100m customers, you'd have to be the maddest hatter to ever live to consider paying someone else for authentication duty like we decided to do. If you are working B2B with US banks and other regulated orgs, the exact opposite appears to be true.

> Don't outsource either your authentication or authorization

This is why a solution like FusionAuth (my employer) or Keycloak is a good option. You can self-host the authentication server.

If you do that, you outsource the development of the auth solution, but keep the data and the operation of it firmly in your control, lowering the business risks.

As other comments mention, there's a lot that goes into building and maintaining auth, and it's rarely a differentiator for your application.

Running your own system also, frankly, lowers the target value of your system. Okta and other centralized auth solutions are of greater value than the users of only one system. Of course, they can also hire specialized security experts on a scale you might not be able to, so you have to balance those risks too.

Yup - OIDC can be boiled down to:

1. The OG OAuth2 spec never said anything about identifying principals 2. OIDC mandated an id_token to avoid the hit of POSTing the access token to an introspection endpoint 3. The shape of the id_token is a JWT

This doc is junk, btw - it's suggesting the client use the id_token for the purposes of authentication? I wouldn't trust that token beyond some basics, unless you have very strong controls over the authorization server and IdP to ensure things like email verification are propagated correctly.

> why you'd even want OIDC for most apps

If you can get away from OIDC, don't touch it. It's only usefull if you don't control the source of users, need to have some seemless login across many apps or if your app is integrated with many other apps for which you need something that work everywhere and that is a standard. OIDC and SAML are the lingua franca when you need that kind of capabilities and those scenario are just the one I've faced, there's a lot more to it

> I don't see why it is preferable over basic forms auth with a cookie.

Cookie is how you typically persist session on a browser, this is the step that usually goes after you've authenticated / been authorised, the scope of OIDC is purely in the authentication/authorisation and doesn't even specify how you should persist the session. Also the scope of OIDC goes beyond the browser

> OIDC-by-default seems like overengineering but I appreciate I'm probably missing a critical reason.

By all means, if your use case doesn't need it, don't touch OIDC/SAML it would be like using kubernetes to host your mum wordpress. OIDC and SAML are complicated because SSO is made to fit the need of companies with all sort of use cases that goes beyond simple use case like the one you seem to describe.

I wholeheartedly agree with your last sentence that is seems overengineered, but one has to assume that there are use cases that warrant such a complex auth scheme. I cannot speak to that as I have never implemented systems of massive scale.

However one thing that puts me off is that it slowly becomes the default way of implementing authentication and authorisation at work where our internal (web) services are (at best) used by 10s of people on a given day. Besides the "old" way of auth integrated much better into our existing system landscape while the "new" way requires (in our case) a Keycloak server.

Again, all that would be fine if the use cased warranted the complexity, but in my employer's case it does not.

So much this. I work on an educational product, and we support something like 5 or 6 different school OIDC providers and have to maintain a separate implementation for each one. They all use the same base class, but there’s just a stupid amount of variation in how they actually work.

It’s missing a step or two. Once you’ve selected your identifying provider, the user is redirected to it, identify itself and select there the claims he’s willing to share (most of the time only what’s needed for authorization). The identifying provider generate the proper token and claims, return them with the user to the third party site. Who can then authorize or not the identified user and return the user.

This exchange of data and redirection is the core of the oauth.

The app server requesting access has to be configured with the identity provider. Part of that is a redirect URL, which the identity provider redirects the client to once the authentication is ok. The URL is to an endpoint of the app server.

When the id provider redirects, it includes the authorization code as an URL parameter or similar, so the app server can pick it up and call the id provider to exchange the authorization code for an access token.

At least that's how I remeber it off the top of my head.

Thanks for the feedback. I created the diagram and would love to improve it.

I skipped a bit (as other folks have mentioned) and the 'authenticate the user' and 'obtain the user consent' steps both involve requests to the browser. I'll update the diagram to make it clearer.

It is "relying"[0].

I think because the relying party is "relying" on the OpenID provider to authenticate the user, but I wasn't able to find the authoritative origin of the term.

0: https://openid.net/specs/openid-connect-core-1_0.html#Termin...

As long as the app only depends on the standard, you have some flexibility.

For example, you can outsource authentication to a third party OIDC server on SaaS deployment and run a self hosted OIDC server like Ory Hydra for onprem deployments.

My read of this is 'don't write your own auth library'. If you want to rely on someone else to host it, or host it yourself, that's up to you and entirely fine. Different pros and cons of each approach; neither is perfect.