Adaptation to other OAuth2 services: Pull requests or forks? about oauth2_proxy HOT 6 CLOSED

@mbland good questions. Let me dig into your current set of changes to understand what would be involved.

I'm not opposed to some generalization for other oauth provider endpoints and requested scopes, but i suspect it will become tricky as oauth providers don't have a consistent way to echo back identity after authentication which GAP needs.

I'm also keen to eventually support #28 which likely ties some functionality closer to Google's apis.

from oauth2_proxy.

also cc: @balshor w/r/t 5f8bd41

from oauth2_proxy.

OK, I'll keep hacking on 18F/oauth2_proxy to see if I can come up with some seams that make sense, and we can consider later whether they're worth pushing back up here. Feel free to subscribe to our repo, jump in on PRs, etc.

from oauth2_proxy.

FYI, I've merged the latest changes from here into the generalize branch of our oauth2_proxy fork, and we're running this version now. Seems to work well.

If you're curious, I created a providers package to present a unified providers.Provider interface between the Google and MyUSA providers, and an api package to share the common api.Request() (formerly apiRequest()) between them.

I still need to add proper tests, but in the off chance you'd be interested in having any of this pushed upstream, let me know and I can prioritize that.

from oauth2_proxy.

wow. Amazingly that refactoring came out very clean. Totally would accept as a PR.

And naming is hard, but renaming this project to a more generic "oauth2_proxy" is not a bad idea either.

from oauth2_proxy.

Cool! I'll start sending PRs your way to build this up bit-by-bit.

from oauth2_proxy.