Adding OAuth2 authentication backend

[mikeokner]

Uses the golang/oauth2 library to authenticate users using the Resource Owner Password OAuth2 flow. Policies can be assigned 100% locally within Vault or assigned based on entitlements read from an OpenID Connect userinfo endpoint that supplies group assignments in some particular field.

This endpoint is similar to the existing Okta backend in terms of configuration and usage. This new oauth2 backend has been tested specifically with Ping, but should work with any OAuth2-compliant provider that plays nice with the golang library.

[mikeokner]

Basic usage of this backend would look like:

# Enable oauth2 backend
$ vault auth-enable oauth2
# Configure it with the provider details
$ vault write auth/oauth2/config \
       provider_url='https://ping.example.com/as/token.oauth2' \
       client_id='VaultTest' \
       client_secret='1234567890qwertyuiop' \
       scope='openid profile' \
       userinfo_url='https://ping.example.com/idp/userinfo.openid' \
       userinfo_group_key='vault_entitlements'
# Map a group name to a policy in Vault
$ vault write auth/oauth2/groups/some-entitlement policies=some-policy
# Assign a user locally to a group
$ vault write auth/oauth2/users/someuser groups=team_two

[panga]

@mikeokner This PR allow users to authenticate with OAuth2 Bearer tokens?

[mikeokner]

@panga no, this one currently only implements the resource-owner password flow. It probably won't get merged in its current state as it sounds like there's a plugin-based auth backend in the works, and they'd rather see something like this end up as a plugin, not mainlined. (See end of #2525 discussion)

[jefferai]

@panga In fact, the proliferation of backends that have come up in the last couple of months around this are exactly why we want to take the approach we took with the combined database backend. The vast majority of the logic can be shared, so we want to share that and have plugins handle the things that are different.

[jefferai]

@mikeokner Thanks for bringing this back up my radar due to closing it :-)

We do intend to have a generic OIDC backend at some point, maybe 0.9 if possible, but given the lack of standards around group/role claims it's likely to be a skeleton for many services. However, in 0.8 we came out with backend plugins, so you now don't need us to merge this in if it's working for you -- just make a couple of small tweaks and it can be built standalone!

[mikeokner]

@jefferai yep, that's the plan! It's been working without a hitch in production for a couple months now so I'm just going to migrate this to a plugin.