5 ms·

Does anyone know if there is any significant upside to using IAM services such as okta or auth0 when anyone can readily deploy a IAM service such as keycloak?

oaiey 7y ago
Because they know what they do. Operating keycloak or whatever software correct and securely is something you need experts and someone dedicated. It is not a side job to run a auth service.
- fgribreau 7y ago
  (Indeed, that's why we are launching https://www.cloud-iam.com https://www.cloud-iam.com a Keycloak as a Service)
  - lifty 7y ago
    FYI, your TLS certificate is invalid.
    - kissgyorgy 7y ago
      A great way to win users trust instantly! :D
    - scient 7y ago
      Not a good look questioning people who know what they are doing by promoting a service apparently built by someone who does NOT know what they are doing.
- techdragon 7y ago
  This is the exact reasoning I used to justify using Auth0 at my current job, and it’s the same logic I use to justify the maintenance time I put into my own Django library and using Auth0 for all my personal projects from now on. They know what they are doing better than I do and their current pricing suits my needs fine.
  - minton 7y ago
    > their current pricing suits my needs fine $2 per user of your API? How can any company afford that?
    - techdragon 7y ago
      If you're put off by the $2 per user per month pricing for "Internal Users", then I'd like to point out their docs about Internal vs External users... https://auth0.com/docs/policies/billing#in-our-pricing-what-is-the-difference-between-internal-and-external-users-are-they-different-technically- https://auth0.com/docs/policies/billing#in-our-pricing-what-... The key line being: "There are no technical differences between these types of users, they simply refer to whether someone is external to your company, or an internal employee." Also... This pricing distinction is only noted on their Developer Pro plan. So for building things that are intended to be used by external users or external paying customers... where you can make the business case for spending at least $0.023 per User per Month (Developer Plan) or $0.28 per User per Month (Developer Pro Plan) then its fine. If you start to build internal applications and your internal business processes start to rely on your staff logging in using Auth0, then $2 per internal employee per month that uses those tools doesn't seem expensive at all.
    - deleted 7y ago
      [deleted]
  - chinathrow 7y ago
    I'm in the market for the same type of service. The pricing of Auth0 would never work out (our accounts are free and no one is paying us per account directly) for us.
kache_ 7y ago
They are focusing all of their efforts on specifically IAM services, enabling them to provide features to you that you otherwise wouldn't have the capacity to provide. Not familiar with the other companies, but auth0 has some pretty nifty bells and whistles. I'm sure the others do as well
rendaw 7y ago
Okta at least can act as an SSO provider for Google accounts. I'm not sure how that's done, it seems a bit like black magic. As far as I'm aware Google Apps only allow you to log in with Google accounts otherwise.
- hirsin 7y ago
  Google supports SAML federation: https://support.google.com/a/answer/60224?hl=en https://support.google.com/a/answer/60224?hl=en
  - rendaw 7y ago
    Whoah, awesome! I guess I was always searching with the wrong terms :/, I did search for "federation" though FWIW. Maybe that's what I should have gone with instead of OpenID with Oidle.
    - hirsin 7y ago
      Yup, although calling it black magic isn't far off from the truth. It's why I stick with oauth and let my coworker handle SAML. (They do SAML both directions, which is how we added it to AAD and Windows). It's a bit of a rough implementation though, so we can't do everything we'd like.
galaxyLogic 7y ago
That is a very good question as are the answers given. I think the important take-away from all this is that OAuth and OpenId and what have you are very complicated. That would seem to be the reason many companies can make a living out of providing them to you. Now could it all be made easier and simpler to understand somehow? Don't know but that would be great.
- dwaite 7y ago
  There are different sorts of hard bits IMHO. OAuth and OpenID Connect can be _conceptually_ hard; you are abstracting authentication and authorization into a protocol and therefore inheriting someone else's model. When that model is presented in the form of a spattering of specifications, understanding and mapping to that model can be really laborious . You also may be doing this as part of a new architecture on your side (e.g. moving from traditional server-side rendered web applications to PWA/SPA apps using APIs). Strong Authentication and Account Lifecycle Management actually are just a whole lot of logic. Authentication is also something which is continually evolving to stay ahead of attackers. They are hard from the perspective of amount of work required, the distraction from your actual product mission, and the consequence of getting them wrong.
  - galaxyLogic 7y ago
    Another thing that makes it hard I think is that these are all by necessity multi-agent protocols/algorithms. How should we unambiguously describe and specify them? Well verbal verbiage is not very formal. Maybe something like: https://en.wikipedia.org/wiki/Specification_and_Description_Language https://en.wikipedia.org/wiki/Specification_and_Description_... What makes this all rather critical is that these are security procedures and, and complexity is the foe of security.

oaiey 7y ago

Because they know what they do. Operating keycloak or whatever software correct and securely is something you need experts and someone dedicated. It is not a side job to run a auth service.

fgribreau 7y ago
(Indeed, that's why we are launching https://www.cloud-iam.com https://www.cloud-iam.com a Keycloak as a Service)
- lifty 7y ago
  FYI, your TLS certificate is invalid.
  - kissgyorgy 7y ago
    A great way to win users trust instantly! :D
  - scient 7y ago
    Not a good look questioning people who know what they are doing by promoting a service apparently built by someone who does NOT know what they are doing.
techdragon 7y ago
This is the exact reasoning I used to justify using Auth0 at my current job, and it’s the same logic I use to justify the maintenance time I put into my own Django library and using Auth0 for all my personal projects from now on. They know what they are doing better than I do and their current pricing suits my needs fine.
- minton 7y ago
  > their current pricing suits my needs fine $2 per user of your API? How can any company afford that?
  - techdragon 7y ago
    If you're put off by the $2 per user per month pricing for "Internal Users", then I'd like to point out their docs about Internal vs External users... https://auth0.com/docs/policies/billing#in-our-pricing-what-is-the-difference-between-internal-and-external-users-are-they-different-technically- https://auth0.com/docs/policies/billing#in-our-pricing-what-... The key line being: "There are no technical differences between these types of users, they simply refer to whether someone is external to your company, or an internal employee." Also... This pricing distinction is only noted on their Developer Pro plan. So for building things that are intended to be used by external users or external paying customers... where you can make the business case for spending at least $0.023 per User per Month (Developer Plan) or $0.28 per User per Month (Developer Pro Plan) then its fine. If you start to build internal applications and your internal business processes start to rely on your staff logging in using Auth0, then $2 per internal employee per month that uses those tools doesn't seem expensive at all.
  - deleted 7y ago
    [deleted]
- chinathrow 7y ago
  I'm in the market for the same type of service. The pricing of Auth0 would never work out (our accounts are free and no one is paying us per account directly) for us.

kache_ 7y ago

They are focusing all of their efforts on specifically IAM services, enabling them to provide features to you that you otherwise wouldn't have the capacity to provide. Not familiar with the other companies, but auth0 has some pretty nifty bells and whistles. I'm sure the others do as well

rendaw 7y ago

Okta at least can act as an SSO provider for Google accounts. I'm not sure how that's done, it seems a bit like black magic. As far as I'm aware Google Apps only allow you to log in with Google accounts otherwise.

hirsin 7y ago
Google supports SAML federation: https://support.google.com/a/answer/60224?hl=en https://support.google.com/a/answer/60224?hl=en
- rendaw 7y ago
  Whoah, awesome! I guess I was always searching with the wrong terms :/, I did search for "federation" though FWIW. Maybe that's what I should have gone with instead of OpenID with Oidle.
  - hirsin 7y ago
    Yup, although calling it black magic isn't far off from the truth. It's why I stick with oauth and let my coworker handle SAML. (They do SAML both directions, which is how we added it to AAD and Windows). It's a bit of a rough implementation though, so we can't do everything we'd like.

galaxyLogic 7y ago

That is a very good question as are the answers given. I think the important take-away from all this is that OAuth and OpenId and what have you are very complicated. That would seem to be the reason many companies can make a living out of providing them to you. Now could it all be made easier and simpler to understand somehow? Don't know but that would be great.

dwaite 7y ago
There are different sorts of hard bits IMHO. OAuth and OpenID Connect can be _conceptually_ hard; you are abstracting authentication and authorization into a protocol and therefore inheriting someone else's model. When that model is presented in the form of a spattering of specifications, understanding and mapping to that model can be really laborious . You also may be doing this as part of a new architecture on your side (e.g. moving from traditional server-side rendered web applications to PWA/SPA apps using APIs). Strong Authentication and Account Lifecycle Management actually are just a whole lot of logic. Authentication is also something which is continually evolving to stay ahead of attackers. They are hard from the perspective of amount of work required, the distraction from your actual product mission, and the consequence of getting them wrong.
- galaxyLogic 7y ago
  Another thing that makes it hard I think is that these are all by necessity multi-agent protocols/algorithms. How should we unambiguously describe and specify them? Well verbal verbiage is not very formal. Maybe something like: https://en.wikipedia.org/wiki/Specification_and_Description_Language https://en.wikipedia.org/wiki/Specification_and_Description_... What makes this all rather critical is that these are security procedures and, and complexity is the foe of security.