Research
Security News
Malicious npm Package Targets Solana Developers and Hijacks Funds
A malicious npm package targets Solana developers, rerouting funds in 2% of transactions to a hardcoded address.
github.com/bitly/oauth2_proxy
(This project was renamed from Google Auth Proxy - May 2015)
A reverse proxy that provides authentication using Providers (Google, Github, and others) to validate accounts by email, domain or group.
v2.0.1
) or build with $ go get github.com/bitly/oauth2_proxy
which will put the binary in $GOROOT/bin
You will need to register an OAuth application with a Provider (Google, Github or another provider), and configure it with Redirect URI(s) for the domain you intend to run oauth2_proxy
on.
Valid providers are :
The provider can be selected using the provider
configuration value.
For Google, the registration steps are:
https://internal.yourcompany.com
https://internal.yourcompany.com/oauth2/callback
oauth2_proxy
will only callback on the path /oauth2/callback
It's recommended to refresh sessions on a short interval (1h) with cookie-refresh
setting which validates that the account is still authorized.
Authorization callback URL
enter the correct url ie https://internal.yourcompany.com/oauth2/callback
The GitHub auth provider supports two additional parameters to restrict authentication to Organization or Team level access. Restricting by org and team is normally accompanied with --email-domain=*
-github-org="": restrict logins to members of this organisation
-github-team="": restrict logins to members of this team
For LinkedIn, the registration steps are:
https://internal.yourcompany.com/oauth2/callback
The MyUSA authentication service (GitHub)
To authorize by email domain use --email-domain=yourcompany.com
. To authorize individual email addresses use --authenticated-emails-file=/path/to/file
with one email per line. To authorize all email addresse use --email-domain=*
.
oauth2_proxy
can be configured via config file, command line options or environment variables.
An example oauth2_proxy.cfg config file is in the contrib directory. It can be used by specifying -config=/etc/oauth2_proxy.cfg
Usage of oauth2_proxy:
-authenticated-emails-file="": authenticate against emails via file (one per line)
-client-id="": the OAuth Client ID: ie: "123456.apps.googleusercontent.com"
-client-secret="": the OAuth Client Secret
-config="": path to config file
-cookie-domain="": an optional cookie domain to force cookies to (ie: .yourcompany.com)*
-cookie-expire=168h0m0s: expire timeframe for cookie
-cookie-httponly=true: set HttpOnly cookie flag
-cookie-key="_oauth2_proxy": the name of the cookie that the oauth_proxy creates
-cookie-refresh=0: refresh the cookie after this duration; 0 to disable
-cookie-secret="": the seed string for secure cookies
-cookie-secure=true: set secure (HTTPS) cookie flag
-custom-templates-dir="": path to custom html templates
-display-htpasswd-form=true: display username / password login form if an htpasswd file is provided
-email-domain=: authenticate emails with the specified domain (may be given multiple times). Use * to authenticate any email
-github-org="": restrict logins to members of this organisation
-github-team="": restrict logins to members of this team
-htpasswd-file="": additionally authenticate against a htpasswd file. Entries must be created with "htpasswd -s" for SHA encryption
-http-address="127.0.0.1:4180": [http://]<addr>:<port> or unix://<path> to listen on for HTTP clients
-https-address=":443": <addr>:<port> to listen on for HTTPS clients
-login-url="": Authentication endpoint
-pass-access-token=false: pass OAuth access_token to upstream via X-Forwarded-Access-Token header
-pass-basic-auth=true: pass HTTP Basic Auth, X-Forwarded-User and X-Forwarded-Email information to upstream
-pass-host-header=true: pass the request Host Header to upstream
-profile-url="": Profile access endpoint
-provider="google": OAuth provider
-proxy-prefix="/oauth2": the url root path that this proxy should be nested under (e.g. /<oauth2>/sign_in)
-redeem-url="": Token redemption endpoint
-redirect-url="": the OAuth Redirect URL. ie: "https://internalapp.yourcompany.com/oauth2/callback"
-request-logging=true: Log requests to stdout
-scope="": Oauth scope specification
-skip-auth-regex=: bypass authentication for requests path's that match (may be given multiple times)
-tls-cert="": path to certificate file
-tls-key="": path to private key file
-upstream=: the http url(s) of the upstream endpoint. If multiple, routing is based on path
-validate-url="": Access token validation endpoint
-version=false: print version string
See below for provider specific options
The environment variables OAUTH2_PROXY_CLIENT_ID
, OAUTH2_PROXY_CLIENT_SECRET
, OAUTH2_PROXY_COOKIE_SECRET
, OAUTH2_PROXY_COOKIE_DOMAIN
and OAUTH2_PROXY_COOKIE_EXPIRE
can be used in place of the corresponding command-line arguments.
There are two recommended configurations.
--tls-cert=/path/to/cert.pem
and --tls-key=/path/to/cert.key
.The command line to run oauth2_proxy
in this configuration would look like this:
./oauth2_proxy \
--email-domain="yourcompany.com" \
--upstream=http://127.0.0.1:8080/ \
--tls-cert=/path/to/cert.pem \
--tls-key=/path/to/cert.key \
--cookie-secret=... \
--cookie-secure=true \
--provider=... \
--client-id=... \
--client-secret=...
Because oauth2_proxy
listens on 127.0.0.1:4180
by default, to listen on all interfaces (needed when using an
external load balancer like Amazon ELB or Google Platform Load Balancing) use --http-address="0.0.0.0:4180"
or
--http-address="http://:4180"
.
Nginx will listen on port 443
and handle SSL connections while proxying to oauth2_proxy
on port 4180
.
oauth2_proxy
will then authenticate requests for an upstream application. The external endpoint for this example
would be https://internal.yourcompany.com/
.
An example Nginx config follows. Note the use of Strict-Transport-Security
header to pin requests to SSL
via HSTS:
server {
listen 443 default ssl;
server_name internal.yourcompany.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/cert.key;
add_header Strict-Transport-Security max-age=2592000;
location / {
proxy_pass http://127.0.0.1:4180;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_connect_timeout 1;
proxy_send_timeout 30;
proxy_read_timeout 30;
}
}
The command line to run oauth2_proxy
in this configuration would look like this:
./oauth2_proxy \
--email-domain="yourcompany.com" \
--upstream=http://127.0.0.1:8080/ \
--cookie-secret=... \
--cookie-secure=true \
--provider=... \
--client-id=... \
--client-secret=...
OAuth2 Proxy responds directly to the following endpoints. All other endpoints will be proxied upstream when authenticated. The /oauth2
prefix can be changed with the --proxy-prefix
config variable.
OAuth2 Proxy logs requests to stdout in a format similar to Apache Combined Log.
<REMOTE_ADDRESS> - <user@domain.com> [19/Mar/2015:17:20:19 -0400] <HOST_HEADER> GET <UPSTREAM_HOST> "/path/" HTTP/1.1 "<USER_AGENT>" <RESPONSE_CODE> <RESPONSE_BYTES> <REQUEST_DURATION>
Follow the examples in the providers
package to define a new
Provider
instance. Add a new case
to
providers.New()
to allow oauth2_proxy
to use the
new Provider
.
FAQs
Unknown package
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
A malicious npm package targets Solana developers, rerouting funds in 2% of transactions to a hardcoded address.
Security News
Research
Socket researchers have discovered malicious npm packages targeting crypto developers, stealing credentials and wallet data using spyware delivered through typosquats of popular cryptographic libraries.
Security News
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.