Implements the core functionality to allow 3rd party identities access to Google APIs. Specifically, this PR implements the base account credential type and supports file-sourced credentials such as Kubernetes workloads. Later updates will add support for URL-sourced credentials such as Microsoft Azure and support for AWS credentials.

Perhaps add a BrokenAuthHeader to EndPoint?

The server bug behind this seems pretty common (it's also in Shopify, with domain names [shop].myshopify.com), and it seems unfortunate to need to update this library every time someone finds one. I'd bet 90% of the forks are to add another broken provider.

Let me know if you might accept a change like this and I'll work on it.

Added authhandler.go, which implements a TokenSource to support "three-legged OAuth 2.0" via a custom AuthorizationHandler.

Added example_test.go with a sample command line implementation for AuthorizationHandler.

This patch adds support for 3-legged-OAuth flow using an OAuth Client ID file downloaded from Google Cloud Console.

New credential type supported: "impersonated_service_account".

Extend the "credentialsFile" struct to take into account the credential source for the impersonation.

Reuse of ImpersonateTokenSource struct, from `google/internal/externalaccount/Impersonate.go' file. The struct has a package-scope visibility now.

Fixes: #515

@proppy gave some feedback about caching. Cache interface doesn't have flexibility to support multiple users. Rather than providing another Cache interface with token identification such as

type Cache interface {
    Read(id interface{}) (*Token, error)
    Write(id interface{}, token *Token) error
}

we should wrap the authorizedTransport with a cacher transport.

t := FileCacheTransport{config.NewAuthorizedTransport()}

FileCacheTransport's RoundTripper could handle token caching.

In some cases it is desirable to generate a JWT signed by a service account with custom claims. For instance, when exchanging a service account signed token for a Google ID token.

Fixes golang/oauth2#266

This would help add extra claim for certain 2-leg JWT exchange.

For example, Google service account key can be used to generate an OIDC token, but Google TokenURL requires "target_audience" claims set.

See this example usage: https://gist.github.com/wlhee/64bc518190053e2122ca1909c2977c67#file-exmaple-go-L29

Workforce pools (external account credentials for non-Google users) are organization-level resources which means that issued workforce pool tokens will not have any client project ID on token exchange as currently designed.

"To use a Google API, the client must identify the application to the server. If the API requires authentication, the client must also identify the principal running the application."

The application here is the client project. The token will identify the user principal but not the application. This will result in APIs rejecting requests authenticated with these tokens.

Note that passing a x-goog-user-project override header on API request is still not sufficient. The token is still expected to have a client project.

As a result, we have extended the spec to support an additional workforce_pool_user_project for these credentials (workforce pools) which will be passed when exchanging an external token for a Google Access token. After the exchange, the issued access token will use the supplied project as the client project. The underlying principal must still have serviceusage.services.use IAM permission to use the project for billing/quota.

This field is not needed for flows with basic client authentication (e.g. client ID is supplied). The client ID is sufficient to determine the client project and any additionally supplied workforce_pool_user_project value will be ignored.

Note that this feature is not usable yet publicly.

Hi,

Is there a way I can use golang oauth2 to extend short lived facebook access tokens? With the new version of Go 1.5 I cannot use the "internal" package.

What I used to do with the 1.4 version of go is:

import (
      "golang.org/x/oauth2"
      "golang.org/x/oauth2/internal"
)

itk, err := internal.RetrieveToken(
        oauth2.NoContext,
        cfg.ClientID,
        cfg.ClientSecret,
        cfg.Endpoint.TokenURL,
        url.Values{
            "grant_type":        {"fb_exchange_token"},
            "fb_exchange_token": {tkn.AccessToken},
        },
    )

Is there a "supported" or "suggested" way to do this with Go 1.5 that doesn't allow the usage of the "internal" package?

Thanks, Alex

Add an Audience field to jwt.Config which, if set, is used instead of TokenURL as the 'aud' claim in the generated JWT. This allows the jwt package to work with authorization servers that require the 'aud' claim and token endpoint URL to be different values.

Fixes #369.

AWS released a new instance metadata service (IMDSv2). IMDSv2 brought a requirement that a session token header is now required on every call to metadata endpoint. Modify the AWS credential retrieval flow to fetch the session token and send it along with the calls to metadata endpoints

x/oauth2 has some churn due to security issues and changes in dependencies.

However the dependencies of x/oauth2 are not so set in stone:

• Heavy cloud.google.com/go is required only for fetching GCE metadata. However the package for fetching metadata is pretty self-contained and can be pulled in.
• Heavy google.golang.org/appengine is required only for Gen1 AppEngine. I haven't investigated how much code is actually used. After removal of these two dependencies, the rest is trivial:
• x/net is used in one place to save 5 lines of code.
• google/go-cmp is used in one test to save 11 lines of code.

I currently maintain a dependency-less version of x/oauth2 at https://github.com/ridge/auth2. Here are the patches: https://github.com/golang/oauth2/compare/master...ridge:oauth2:master

The only feature loss is AppEngine Gen1 environment: for expediency I cut it out instead of figuring out if it can be retained.

Found vulnerable in: golang/golang.org/x/[email protected]

OSS Index ID: [CVE-2022-41717] CWE-789: Uncontrolled Memory Allocation

Please upgrade golang/golang.org/x/[email protected] to v0.4.0

This adds a function for the multi-tenant authentication platform provided by Vault Vision. It is similar to the AWSCognito function and includes a basic unit test.

Parse error parameters described in OAuth RFC https://datatracker.ietf.org/doc/html/rfc6749#section-5.2

Handle unorthodox servers responding 200 in error case.

Fixes #441 Updates #173

Tested with GitHub

Fixes #418

Draft until #610 merged. Important that error handling is consistent for both flows

Co-authored-by: cmP [email protected]