Just curious if anyone has any knowledge of someone having created an oAuth provider library/endpoint in CF or if at this point its better/easier to use a 3rd party provider (like auth0.com or others) if you need to provide an oAuth compliant endpoint for auth purposes? To be clear, in this model the need is that outside entities are making oAuth calls to request a token, not that the CF app is being a consumer and making a call to get a token to use for subsequent calls.

After the global IT outage, the use of third-party authentication systems should really be examined. Plus, auth0 was hacked last fall. :/

sounds like he's currently examining third party systems...?

I think the sentiment is that 3rd party systems can be "problematic" maybe?

what's involved in hosting your own oauth server?

I like keycloak, and since docker it's pretty easy to stand up, but it is an 800lb gorilla (with support for google and other socials tho)

The challenge is we are a small team and so I need to be careful not to try and implement something that's going to require a lot of support/management/maintenance as currently the need to be an oAuth provider is a pretty limited use case for us.

lol, I've got a cfopenid project from about 12 years ago that has a server and a client, so I bet someone might have something you can use from within a CFML app.

Setting up your own OAuth provider means having an identity server, a login server, and an application server with a predefined set of handshakes between them, if you're following OAuth to the letter. It's a lot of work to build it yourself (we did, and even building on a set of Apache libraries for most of the token/request/response stuff it was quite a bit of work), and then you're maintaining three services rather than just one and you need to consider fallover and deployment etc. If we'd known all that, going in, we'd have probably used a 3rd party service for it instead, despite then having users locked out of your systems if the 3rd party service is down/goes away. Mitigate that by looking at a couple of services and be prepared to switch services "quickly" if needed.

Appreciate the feedback and context, with the size of our team it is likely the case that trying to stand one up ourselves is beyond the scope of what we want to tackle in the context of this particular effort. We had already discussed that if we went the 3rd party route that likely we need to pick one, but try to implement it in a way that makes it relatively easy to swap to a different one if/should/when that need arises. The Keycloak system that @denny referenced does look like a pretty nice system to use, but it likely just adds more time to our project timeline that makes it harder to try and fit in and again becomes another system/platform we have to now manage and maintain for a limited use case at this time.

I guess I'd turn this around and ask: why are you considering implementing OAuth? What are your business drivers here?

We have to build a new integration to an Oracle application (Oracle Recruiting Cloud) and it has bidirectional communication and from their end they stipulate/expect to use oAuth to autenticate back against us when they need to communicate back to our applications. We are just in the initial phases of discovery so I have asked if their request to use oAuth is a requirement or not. I get they want us to use oAuth then connecting to their system, but it does seem a little of a stretch to expect the same in the reverse as they do integrate this platform with partners/businesses of all sizes, which I'm sure the smaller/medium ones are like us and don't have an in-house oAuth server/provider in place.

Interesting. Well, good luck. Sounds like auth0.com will likely be your simplest path but I don't know what costs look like there...

Yeah, that's where I'll likely start, despite the fact that Okta had the blunder they did not too long ago. They have a free tier to start at to at least allow some initial testing/discovery to see if they are the right fit or not. Even then, their next tier up isn't too terrible on the B2B side should we have to go to a paid model.

FWIW, we ended up replacing most of the Apache code with our own implementation based on that OSS library (since it had stopped being maintained and, ironically, had unresolved CVEs against it 😞 which we had to figure out solutions for in our replacement code).

Ugh, yeah. Definitely makes going with a 3rd party provider (despite their potential security issues they have) a more viable/better option simply to avoid all those headaches.

Yeah Keycloak is an identity provider, so think something like LDAP, but it has decent docs and is pretty popular so if you do go in-house, it's probably a good choice.

The biggest thing is if there isn't an absolute need for running your own, don't. Auth systems are crazy complex and you need to be really up on the tech in order to keep it secure and maintained. It's not one of those "deploy it and forget it" things, since it's usually the higher value target for attackers.

Nothing is deploy and forget, per se, tho everything is getting moreso every day. 😃 To some extent it's the old "security by obscurity" paradox. On the one hand, the systems getting attacked the most are going to be the most secure (theoretically), so you get all that "for free" by just hitting an "update" button as it were, whereas maybe your homespun system isn't secure but it's not easily detectable as being a target.