At least one problem is that Oauth2 isn't a protocol; it's a framework for making protocols. Things like endpoints, scopes, security practices, etc aren't prescribed, so every implementation is different. And unfortunately none of the big players are really incentivized to standardize anything.

OIDC is basically a protocol, and is what you're describing. It's _the_ attempt to standardize on a common set of scopes, discovery mechanisms, etc for making it easier to build apps that use OAuth2.

And the platforms that do support OIDC properly just require a login portal URL to integrate support for it.

Want to add Microsoft logins with an oidc library? One url.

Want to add Twitter / Facebook signin? Go get an OAuth library and write several hundred LOCs to detail the scopes and crap you want form them because they are non-standard.

Forgive me if I'm mistaken, but isn't OIDC for authentication/profile information? Does it include standards for things like accessing contact lists, reading/writing files, sending email, etc?

OIDC is for authentication and profile information. The standard claims refer to each field of profile information [1].

It doesn't include any domain-specific operations like your examples.

[1] https://openid.net/specs/openid-connect-core-1_0.html#Standa...

A bit late: you're correct, but it does provide a standard API for looking up additional metadata, even if it's non-standard. That's using custom claims and/or the user info endpoint (which can include custom claims). You can use custom scopes to limit what is available as well.

I've recently tried out Keycloak(https://www.keycloak.org/) and have been impressed with it. Saved at least a few weeks on a personal project. It does have a learning curve though.

This, so much.

I've been tasked with implementing oauth/openid at work and in about one month in spare time i was able to read rfc 6749, install keycloak, configure it, create a client, create a very basic app (~80 lines of python and flask) and log in via oauth/openid with user information and groups pulled via LDAP.

Keycloak is really a game changer.

This presentation is very interesting: https://www.youtube.com/watch?v=FyVHNJNriUQ

I've been usjng keycloak as an UMA authorization server, and while it's better than nothing it has a few bugs that make it not exactly compliant with the spec. Additionally the UI is incredibly confusing and the documentation isn't that helpful in some cases. Anything you want to do you have to spend too much time searching the UI and some things are not even available: Want to assign ownership of a resource to a user? Need to run a curl request. Though I haven't tried other implementations, so maybe this one's the best

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.

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.

> 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.

Any recommendations or favorites, and any to avoid?

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-shou... . I don't know the speaker, but certainly some of the issues his hedgehogs (no, really) encountered seemed familiar.

(Full disclosure, FusionAuth is my employer.)

If you want a drop in OAuth/OIDC server that runs anywhere, I'd recommend looking at FusionAuth. You can set it up in 5 minutes and it runs everywhere: https://fusionauth.io/docs/v1/tech/5-minute-setup-guide

Worth noting: it is free as in beer--if you need an open source solution, it's not a fit.

Edit: typo

A drop-in component so your product can do what exactly?

To be an OIDC Relying Party [1]?

To be an OIDC Provider [1]?

To be an OAuth2 client [2]? Keep in mind, being an OAuth2 client is probably not useful by itself -- you'll have to program your app to deal with the resource server's specific APIs to accomplish anything, and request the appropriate scopes for the situation, based on what you're doing.

[1] https://openid.net/specs/openid-connect-core-1_0.html#Termin... [2] https://tools.ietf.org/html/rfc6749#section-1.1

Company i work in spent 2 years to implement OAuth. For that time application was rewritten 3-4 times. 3 developers worked on that in different times. And guess what? It still doesn't work and serves tiny portion of traffic with tons of issues.