Skip to content

Support Generic OAuth2 Providers #180

Open

Description

@alee792

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

Activity

  1. cainlevy commented on Aug 6, 2021

    @cainlevy
    Member

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

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

  2. alee792 commented on Aug 8, 2021

    @alee792
    Author

    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

  3. c-nv-s commented on Apr 14, 2023

    @c-nv-s

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

  4. cainlevy commented on Apr 14, 2023

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions