OAuth2 HttpClient customizable header

[Patrick Kaeding]

Would it be possible to allow the [header that is used](https://github.com/golang/oauth2/blob/2e8d9340160224d36fd555eaf8837240a7e239a7/token.go#L80) by the golang.org/x/oauth2 client to be overridden?

I imagine the code change would be simple, but would it be accepted?

My use case is that I have an application that proxies some requests to another service. Those proxied requests have an authorization header, which is sent by their client, and identifies who that caller is. My inner service is the one that I am using the oauth2 library to authenticate with:

client --API token in authorization header--> outer service --OAuth2 token--> inner service

The API token alone is not enough to grant access to the inner service's resource; only the outer service is authorized to access it. I'm sure I could change the way we handle the proxied request, but it seems like it would be useful to make the header customizable.

Thanks

[Sean Liao]

doesn't sound like a common use case, might be easier to use a transport that moves the header?

- sean

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/be9baa89-98fa-44d7-9389-6e68d8548779n%40googlegroups.com.

[Patrick Kaeding]

Thanks Sean!

I just realized I cited the wrong package in my earlier message. I meant to refer to the  golang.org/x/oauth2/clientcredentials client. I'm not sure if that matters for the discussion, but I apologize for any confusion.

Is it safe to use a custom transport with this client? https://pkg.go.dev/golang.org/x/oau...@v0.0.0-20220411215720-9780585627b5/clientcredentials#Config.Client warns specifically against modifying the returned Client or Transport.

[Sean Liao]

Now that I think about it, it won't work 

because oauth2 will Set the Authorization header,

overwriting whatever you might have originally set there.

Maybe it's easier to follow standard oauth and move the original user authentication into some other header?

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ef3ad422-3094-4a0a-814a-32555fc4b8e4n%40googlegroups.com.

[Robert Engels]

If it is implemented correctly oauth2 is a standard that uses a Bearer token. Not sure if the other auth-scheme are usable - then it wouldn’t be oauth. Sounds like you either need an additional routing header or a different auth-scheme 

On May 18, 2022, at 3:09 PM, 'Sean Liao' via golang-nuts <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGabyPpBW__%2BeYU4cyJ0kx3q10YZp6ahCSJPgvkDQs%3DpCixk_g%40mail.gmail.com.