4 ms·

Keycloak is a great open source identity server that supports openid connect. Works out of the box but also allows for full customization as well. Whatever you

Keycloak is a great open source identity server that supports openid connect. Works out of the box but also allows for full customization as well. Whatever you do, don't write your own oauth server.

mooreds 6y ago
> Whatever you do, don't write your own oauth server. I wish I could upvote this 10 times. There are open source solutions. There are closed source solutions. There are SaaS solutions. Pick a solution that meets your needs. Build the differentiating features of your app, not an OAuth server.
- 1cvmask 6y ago
  Any recommendations or favorites, and any to avoid?
  - mooreds 6y ago
    Hiya, I'm employed by a company which provides an OAuth implementation which I think is worth evaluating; you can look at other comments on this post or in my profile for more details. Happy to chat more over email, which is also in my profile, if that'd be helpful. Since I don't know your use cases or needs, I would like to take a step back and think about what a developer might think about when evaluating this type of decision. Here are some things I'd consider: * what does your organization currently use? If your org has experience with an identity solution, I'd evaluate that very seriously. It might not fit all your needs, especially if it is focused on IAM (identity and access management) as opposed to CIAM (customer identity and access management) but since your org uses it and presumably knows how to operate it, start there. * cost of a solution. What does it cost to run the solution every month? What costs to set up the solution? Don't forget to estimate the time of staff to operate--even if I handed you a great solution for free, it would take an engineer's time to get it up and running, and that costs money. * features and functionality. These could be what you might think of as features (does it support passwordless, what languages have client libraries, what standards like SAML, WS-Fed, OIDC, LDAP are supported) as well as non functional requirements like tenancy, performance and data center locality (sometimes governments have requirements about where user data can live). I've built a number of software applications and I can tell you that I wish I'd started out with a separate identity provider more often. It makes it easier to create a single sign on experience, add more applications, and enable new functionality. Add that to the fact that identity is a necessary but not sufficient requirement that doesn't often differentiate or add much value to your application. If you're building a todo app, people expect to be able to login but will rarely rave about how smooth the login experience is :) . If you find a solution that works, you can often drop it in and accelerate delivery of the real value of your application, while giving you flexibility for the future. Finally, here's a video from RailsConf about the dangers of rolling your own user identity management: https://railsconf.com/2020/video/seyed-m-nasehi-why-you-should-avoid-identity-sync-like-wildfire https://railsconf.com/2020/video/seyed-m-nasehi-why-you-shou... . I don't know the speaker, but certainly some of the issues his hedgehogs (no, really) encountered seemed familiar.
skrtskrt 6y ago
Hydra looks like another popular open source solution, but it leaves you to implement the user login and challenge. I have been writing a hobby OpenID server as a way to learn Go and to understand auth. Reading the OpenID connect spec is SO much more educational & clearer than the OAuth RFC on its own.

Keycloak is a great open source identity server that supports openid connect. Works out of the box but also allows for full customization as well. Whatever you do, don't write your own oauth server.

mooreds 6y ago

> Whatever you do, don't write your own oauth server. I wish I could upvote this 10 times. There are open source solutions. There are closed source solutions. There are SaaS solutions. Pick a solution that meets your needs. Build the differentiating features of your app, not an OAuth server.

1cvmask 6y ago
Any recommendations or favorites, and any to avoid?
- mooreds 6y ago
  Hiya, I'm employed by a company which provides an OAuth implementation which I think is worth evaluating; you can look at other comments on this post or in my profile for more details. Happy to chat more over email, which is also in my profile, if that'd be helpful. Since I don't know your use cases or needs, I would like to take a step back and think about what a developer might think about when evaluating this type of decision. Here are some things I'd consider: * what does your organization currently use? If your org has experience with an identity solution, I'd evaluate that very seriously. It might not fit all your needs, especially if it is focused on IAM (identity and access management) as opposed to CIAM (customer identity and access management) but since your org uses it and presumably knows how to operate it, start there. * cost of a solution. What does it cost to run the solution every month? What costs to set up the solution? Don't forget to estimate the time of staff to operate--even if I handed you a great solution for free, it would take an engineer's time to get it up and running, and that costs money. * features and functionality. These could be what you might think of as features (does it support passwordless, what languages have client libraries, what standards like SAML, WS-Fed, OIDC, LDAP are supported) as well as non functional requirements like tenancy, performance and data center locality (sometimes governments have requirements about where user data can live). I've built a number of software applications and I can tell you that I wish I'd started out with a separate identity provider more often. It makes it easier to create a single sign on experience, add more applications, and enable new functionality. Add that to the fact that identity is a necessary but not sufficient requirement that doesn't often differentiate or add much value to your application. If you're building a todo app, people expect to be able to login but will rarely rave about how smooth the login experience is :) . If you find a solution that works, you can often drop it in and accelerate delivery of the real value of your application, while giving you flexibility for the future. Finally, here's a video from RailsConf about the dangers of rolling your own user identity management: https://railsconf.com/2020/video/seyed-m-nasehi-why-you-should-avoid-identity-sync-like-wildfire https://railsconf.com/2020/video/seyed-m-nasehi-why-you-shou... . I don't know the speaker, but certainly some of the issues his hedgehogs (no, really) encountered seemed familiar.

skrtskrt 6y ago

Hydra looks like another popular open source solution, but it leaves you to implement the user login and challenge. I have been writing a hobby OpenID server as a way to learn Go and to understand auth. Reading the OpenID connect spec is SO much more educational & clearer than the OAuth RFC on its own.