8000 Credentials are not stripped on a redirect · Issue #500 · golang/oauth2 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Credentials are not stripped on a redirect #500

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.

Sign up for GitHub

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

Jump to bottom
Open
wirtsi opened this issue Jun 7, 2021 · 4 comments
Open

Credentials are not stripped on a redirect #500

wirtsi opened this issue Jun 7, 2021 · 4 comments

Comments

@wirtsi
Copy link
wirtsi commented Jun 7, 2021

Hey

we have raised 8000 an issue at redpanda-data/connect#792 where the following happens

  • We speak to an oAuth protected endpoint with a valid token
  • Endpoint is happy with the token and redirects me to an endpoint that is secured with a X-Amz-Security-Token URL param (the oauth endpoint adds those)
  • The redirected-to endpoint barfs because the initial Authorization header is still present (Message is something like "Only one auth mechanism allowed")
  • The preservation of the auth headers is something that happens in the oauth2 library, doing a redirect with http.Client removes them

Now the behavior of preserving Auth headers on redirects is a somewhat grey area of the specs. I'd like to point out though that keeping auth headers is not standard golang behavior ... golang/go@6e87082 introduced a changed where Auth headers and cookies are only preserved on redirect if the target host is a subdomain.

The devs at benthos rightly said that this is something that should be fixed in the oauth library. What do you guys think? Is this a bug?
@imax9000
Copy link

Hit this too just now. It's seems like a bug, at the very least because it's inconsistent with http.Client behaviour. Even though redirects are controlled by the service owner, people rarely think about leaking Authorization token when redirecting the user to another domain, so this can also be a security issue in some cases.

@Pival81
Copy link
Pival81 commented Jun 29, 2024

Are there any updates on this? Currently I have to use an oauth2 client to make the first request but stop it from following the redirect, and instead make a second request to the redirected url with a normal http client.

@imax9000
Copy link

Are there any updates on this? Currently I have to use an oauth2 client to make the first request but stop it from following the redirect, and instead make a second request to the redirected url with a normal http client.

I've resorted to a slightly more ergonomic workaround: replacing the transport with my own implementation https://github.com/uabluerail/bsky-tools/blob/main/xrpcauth/transport.go

@seankhliao
Copy link
Member

This may be difficult to fix: the Transport adds t 5C62 he auth tokens, and the interface it implements is RoundTrip(*Request) (*Response, error).
It has no knowledge of which resource servers the tokens are for, or whether a request is a redirected one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@wirtsi @imax9000 @seankhliao @Pival81
0