sso-auth: add all providers from oauth2_proxy

[eforbus]

This project looks promising and it would be a sure winner if you add support for all the providers currently supported by bitlys oauth2_proxy project https://github.com/bitly/oauth2_proxy. Especially because that project is really being maintained

[sporkmonger]

I'm beginning to work on an Azure AD provider.

[sporkmonger]

Things diverged somewhat between this project and https://github.com/bitly/oauth2_proxy and in particular I think verification logic needs to be refactored. (e.g. Azure AD doesn't have a verification endpoint, it expects implementors to actually do full OIDC, which neither project really does.)

[dekimsey]

@sporkmonger Which version of Azure's oidc are you working on? v1 or v2? I created a provider* for oauth2_proxy that does mostly azure's v2 oidc. I haven't looked into porting it to buzzfeed/sso, but I'd like to. I dunno if that's helpful to your work. v2 supports roles, which our applications need, the original implementation in oauth2_proxy was only v1.

Getting oauth2_proxy running with merging several different outstanding pull requests was messy. I'd very much like to switch to a tool being better maintained!

*: Implementation was a bit clunky, since oauth2_proxy didn't use discovery url's or oauth2's v2 libraries which seem to have better support for OpenID Connect flows. Also, groups were pulled from graph and not from the uudi's provided in the jwt.

[sporkmonger]

I need v2, I was starting w/ v1 as a basis. Sounds like what you've got would probably be quite helpful, thanks!

[sporkmonger]

Also I need the groups to be in the JWT for token-pass-through on #45 as well.

[kevinoconnor7]

I think #6 needs to be resolved first as well since config validation is currently responsible for creating the Google auth provider. A refactor to decouple this will be necessary to be able to cleanly add more auth providers.

(For reference I start looking into implementing a generic oidc provider last week).

[shrayolacrayon]

Hi @kevinoconnor7, thank you for looking into adding more providers, we appreciate your contributions! For some context, we have prioritized #6 as well as creating a dummy provider for integration tests, so that it will be simpler to add new providers to sso-auth and validate changes.

[sporkmonger]

Definitely agree that refactor should happen first. Since it's blocking the work I'm trying to do, I'll probably pick at least some of that up unless someone else has already started on it.

[luisdavim]

hi, any updates on this?

[emilaasa]

@sporkmonger Are you working on this now?
We need some of this functionality at work pretty soon and I am starting a rough implementation off of the case statement in options#newProvider. Would be happy to help in any way to make it good enough for upstream merge.

[sporkmonger]

Yes, I'm working on this actively. I have a partially working Azure AD provider in progress, but ran into some hiccups along the way that I'm still working through. I have a working flow for initial auth, but once the token expires for the first time it drops 500s ("missing refresh token") and 401s ("not authorized after refreshing the session"). Still debugging that. Presumably need to disabuse it of the notion that it's always going to have a refresh token. Azure AD only sends an ID token.

[sporkmonger]

I should add that the Azure AD provider I'm working on is derived from a generic OIDC provider, and both will get packaged together in the same PR.

[sporkmonger]

@emilaasa Which provider are you looking for?