Skip to content
This repository has been archived by the owner on Jan 24, 2019. It is now read-only.

Adaptation to other OAuth2 services: Pull requests or forks? #65

Closed
mbland opened this issue Mar 16, 2015 · 6 comments
Closed

Adaptation to other OAuth2 services: Pull requests or forks? #65

mbland opened this issue Mar 16, 2015 · 6 comments

Comments

@mbland
Copy link
Contributor

mbland commented Mar 16, 2015

I've managed to successfully fork this repo and adapt it to a new OAuth2 provider. I know others have done the same. However, given how little work it was, I'm wondering if you'd be open to generalizing the server to support multiple providers out-of-the-box, defaulting to Google but allowing for other providers.

I'm happy to take this on, and add tests as I go, as you can see from the latter link. (I'm about to file a PR for a bug I found in Options.Validate as part of this process.) That said, I understand if you'd rather keep this instance "pure" and let forks for other providers proliferate as they will.

Apologies if you've address this before; didn't see this come up in any earlier issue. Also, thanks for writing this; we've been using it successfully for months now on our Google-managed domain.

@jehiah
Copy link
Member

jehiah commented Mar 17, 2015

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

@jehiah
Copy link
Member

jehiah commented Mar 17, 2015

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

@mbland
Copy link
Contributor Author

mbland commented Mar 19, 2015

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.

@mbland mbland closed this as completed Mar 19, 2015
@mbland
Copy link
Contributor Author

mbland commented Mar 27, 2015

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.

@jehiah
Copy link
Member

jehiah commented Mar 28, 2015

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.

@mbland
Copy link
Contributor Author

mbland commented Mar 30, 2015

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

mbland pushed a commit to cloud-gov/oauth2_proxy that referenced this issue Mar 30, 2015
This is the first step towards genericizing the google_auth_proxy to support
OAuth2 providers other than Google as discussed in bitly#65. The `api` package will
enable multiple providers to use the same `api.Request()` implementation.
balshor pushed a commit to balshor/linkedin_auth_proxy that referenced this issue Apr 18, 2015
This is the first step towards genericizing the google_auth_proxy to support
OAuth2 providers other than Google as discussed in bitly#65. The `api` package will
enable multiple providers to use the same `api.Request()` implementation.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

2 participants