It looks like it’s strictly for OAuth 2.0 flows. No SAML, no ldap, no Kerberos, so it’s just a basic key exchange for those who can’t be bothered. Auth is hard and consumes too much sprint cycles, as is, so anything is welcome in this space. I personally will stick to keycloak.
The people who require SAML, LDAP and Kerberos are often catering towards a specific userbase (ie. internal business customers).
The needs for Auth & Auth are different for public-facing apps/services. It's not entirely unsurprising many newer Auth solutions don't even attempt to implement SAML et al.
With all of the recent steep price hikes in the Auth SaaS space, it seems it's becoming increasingly important to actually own your user account data. By own, I mean have access to the database and be capable of migrating it somewhere else (even at a large inconvenience) if necessary.
KeyCloak seems awesome for this - but I am liking the "explosion" of new Auth providers that seem to be popping up everywhere these days.
reactordev|1 year ago
Alupis|1 year ago
The needs for Auth & Auth are different for public-facing apps/services. It's not entirely unsurprising many newer Auth solutions don't even attempt to implement SAML et al.
With all of the recent steep price hikes in the Auth SaaS space, it seems it's becoming increasingly important to actually own your user account data. By own, I mean have access to the database and be capable of migrating it somewhere else (even at a large inconvenience) if necessary.
KeyCloak seems awesome for this - but I am liking the "explosion" of new Auth providers that seem to be popping up everywhere these days.
thdxr|1 year ago
but the flow between your apps and openauth will always be oauth