Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Generic OAuth2 Providers #180

Open
alee792 opened this issue Aug 6, 2021 · 4 comments
Open

Support Generic OAuth2 Providers #180

alee792 opened this issue Aug 6, 2021 · 4 comments

Comments

@alee792
Copy link

alee792 commented Aug 6, 2021

Keratin supports generic OAuth2 providers here: https://github.com/keratin/authn-server/blob/master/lib/oauth/provider.go

However, there is no means to read configurations from the environment, or otherwise inject them. The credentials, scopes and endpoints required for an *oauth2.Config could be represented by:

CUSTOM_OAUTH_NAME (Used for HTTP path.)
CUSTOM_OAUTH_CREDENTIALS
CUSTOM_OAUTH_AUTH_URL
CUSTOM_OAUTH_TOKEN_URL
CUSTOM_OAUTH_SCOPES

Or, the env vars could be written to be easily pattern matchable to allow for multiple custom providers.

I see there are outstanding requests for Twitter and other providers. A generic provider would sidestep the need to PR for every requested provider. I believe the oauth2 library took the same tack and basically stopped accepting changes for what amounted to config as code: https://github.com/golang/oauth2#policy-for-new-packages

@cainlevy
Copy link
Member

cainlevy commented Aug 6, 2021

Sounds nice! I would really appreciate not needing custom code for each provider.

My only question is how to handle the UserInfoFetcher. Any thoughts?

@alee792
Copy link
Author

alee792 commented Aug 8, 2021

That does appear to be the crux...

Both OAuth2 Introspection and OIDC UserInfo can return an email.

For Introspection, the email could show up as either sub, username or some custom claim. The ID could also be either of those two fields.

For UserInfo, the email will likely be email, but there are several fields for which an ID could be returned.

The custom provider could be constrained to the OAuth2 and OIDC spec, with the expectation that a GET with a bearer token to a specified endpoint returns a JSON response with status 200. Reading the JWT could be done, but then we would have to manage keys for signature verification.

Whether it's OAuth2 or OIDC may be immaterial. The config could also specify which fields to map to ID and email.

So we could add:

CUSTOM_OAUTH_INTROSPECTION_URL
CUSTOM_OIDC_USERINFO_URL
(Or just a single field like CUSTOM_USERINFO_URL, then document that both OAuth2 Introspection and OIDC UserInfo work.)
CUSTOM_OAUTH_USER_ID_FIELD
CUSTOM_OAUTH_EMAIL_FIELD

@c-nv-s
Copy link

c-nv-s commented Apr 14, 2023

Was trying to investigate how to integrate with oidc and I see this ticket didn't really progress?

@cainlevy
Copy link
Member

@c-nv-s That's correct. I'd be happy to review a pull request however!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants