Horizon as OAuth Provider

[BLamy]

After #176 there will be a way for Horizon to run in isolation and have it's own set of usernames/password (possibly even 2-factor authentication).
Given this, I would like to be able to allow other applications to delegate authentication to my horizon application.

The use case would be as follows:

1. I pick Horizon for an enterprise based application. Call it (App A).
2. App A uses username/password for authentication.
3. A few months down the line I want to create another application (App B)
4. I Would like App B to delegates authentication to App A using O Auth.

A major Pro of this approach over sharing a JWT public key is that App A doesn't need to know about App B.
When implementing JWTs you need to be able to be able to define a scope about what apps/models are supported. If you expect App A to create a scoped token for App B you are either putting logic into App A that shouldn't be there or you are handing out a blank check to App B and App C and any app to come after that.

[deontologician]

This is a good idea, I think we should implement this as a plugin

[sjmcdowall]

This is just my 2-cents : but from a system's architect point of view -- I like the idea of an easy Oauth service based on the horizon security model .. but I for certain would NOT like it to be "hard bundled" in as part of the overall web application.

Being a good micro service advocate, I want to be able to scale / "proxy HA" my Oauth service totally independent on any specific instance of a web app. Loaded in its own Docker (or whatever) container ready to deploy @ multiple hosts if needed to scale via (pick your orchestration engine).

@BLamy -- do you really want the availability of your App B to be dependent on App A always running?

So -- what I am thinking is make this some sort of "hz" build or whatever option that will either run or build an Oauth service that a Horizon app can natively (easily) use but with the option of it just doing that and nothing else as a standalone service -- so it's very lightweight and compartmentalized. Separation of concerns and all that. :)

[arizonatribe]

Yeah, some form of this idea would be great. I can't accurately guess the exact reason for only 3rd Party OAuth, but if it's because those providers are following the OAuth 2 specs (whereas a simple username/password store is insufficient for security), the solution suggested here of implementing the OAuth 2 pattern yourselves would solve the problem.

For now, I've forked Horizon, built my own OAuth provider and dropped it in as one of the "3rd party" options Horizon will accept. But I'd like to not have to be stuck between the options of: 3rd Party OAuth, Anonymous, or forking Horizon with my own company's OAuth provider (but still using Horizon for role/permissions).

Horizon could be a really outstanding application if the Authentication options could cover a wider range of users (and still be true to the OAuth 2 security patterns). It's a tough sell and almost a non-starter (will get you laughed out the door) to suggest using a product that would require your company's users switch to something like Twitter for authentication.

[BLamy]

@sjmcdowall I feel I could make the argument that if you only have 2 applications a full microservices architecture is a little bit overdesign. The scenario I described above would allow developers to slowly scale from one application into an architecture which is suitable for a couple of applications.

Then yes, If your architecture gets more complicated then that you should dedicate a horizon node to just user services as you describe.

I don't exactly see the value in explicitly designing a system to not allow what I described. If that's how the user wants to grow their application let them. By the time someone is shipping their 4th or 5th horizon application they will probably be aware of the architectural trade-offs they are making.

[sjmcdowall]

@BLamy -- I never implied there shouldn't be an option (maybe even the default option!) to imbed an Oauth provider as part of the application -- but that there should be an option to make it a separate micro service if desired. So one can start with the embedded option which maybe perfect for many projects -- then later opt to "split it out" if it makes sense to do so.