It sounds like you’re conflating IDPs with other technology.

Istio is a service mesh that can be used to bolt on a proxy that requires authz/authn, but Istio itself is not managing the users or groups. It communicates with whatever IDP was chosen.

I recommend first deciding on which protocol you wish to use for authn/authz.

Some choices are:

- OIDC

- SAML

- OAuth

Most of the protocols have different configuration strategies depending on the application (i.e mobile vs cli tool vs webapp).

The protocols will enable you to create an RBAC system, but the actual implementation of RBAC is done application side not within the IDP.

One of the biggest factors in choosing a solution will be cost. SaaS IDPs become incredibly expensive at social media level of scale (10k+ users).

Personally I recommend starting out in a SaaS IDP and migrating your users to a self hosted service later if needed. As long as you leverage a well supported protocol the migration shouldn’t be _too_ difficult.

The problem is that everyone has their own implementation of it following loose, at best, standards. Some like Auth0 are fully hosted by them, but ORY’s is self hosted, configurable software. Then you also have Amazon’s IAM which is its own proprietary software. Many of the things you listed performs different tasks at different levels of auth flows.

I would first start by fully understanding the difference between authentication and authorization. The way we describe theses terms with the word “auth” does this distinction a disservice.

The OAuth 2.0 and OpenID standards are the best places to start. They are where standardization begins and (unfortunately) ends. OAuth is a Authorization protocol, not an Authentication protocol however people do mix in the authentication into the flows.

Basic intro to OAuth2: https://auth0.com/intro-to-iam/what-is-oauth-2

In depth explanation: https://www.digitalocean.com/community/tutorials/an-introduc...

>OAuth is a Authorization protocol, not an Authentication protocol however people do mix in the authentication into the flows.

This is what I don't get. Using OAuth2 for authentication is so complex, whereas Ory has a simple authentication system based o cookies: https://www.ory.sh/docs/security-model

With OAuth2 it seems to me to be the same just with extra steps keeping track of tokens and expiration. Why use OAuth2 for authentication, it was never designed for that.

My understanding is that this is usually done by companies that need to implement delegated authorization which is the bread and butter of OAuth 2.0. By starting and implementing their authentication flows with OAuth2, you can support both delegated authorization and native authentication where your own apps are simply OAuth clients with some special casing. That isn’t absolutely necessary since you could build authentication separately from OAuth but then you would still need those OAuth2 flows for delegated authz eventually if you do.

If Ory would have a UI for self hosted instances… that would be insane! User Management etc without a user interface is weird, not sure why it’s missing in the self hosted version.

Just also curious, how difficult/complex would be passkey/password/access recovery with what apppears to be so many layers of auth?

No more complicated than usual, as there's separation of concerns. You'd have your IdP, which provides authentication and account management. The IdP then integrates with an application or service using some authentication protocol (OIDC, SAML, LDAP, etc), so downstream only relies on the protocol.

It could get messy if you had some identity-aware proxy in front of your IdP.

Frameworks and companies are so potentially unrelated I'm not sure how to respond to your question. I think it's like any other tech: you have to evaluate it and see if it works for you.