Oauth-proxy

A web application may need organization-wide login without implementing an identity-provider integration itself. An OAuth proxy sits in front of the application, sends visitors through an external sign-in service and forwards accepted requests. This historical chart used the Bitly oauth2_proxy lineage, which later moved through other maintainers. Identify the actual proxy binary before applying current configuration advice, and distinguish proving who a visitor is from deciding which application actions that visitor may perform.

Current guidance

The recovered oauth-proxy entry points to bitly/oauth2_proxy and a very old nginx-ingress compatibility note. Bitly explicitly archived that implementation and endorsed the Pusher fork. The current OAuth2 Proxy changelog records the subsequent move from Pusher to the independent oauth2-proxy organization, establishing the continuation rather than merely a similar name.

Use current proxy and gateway documentation when rebuilding the integration. The historical recommendation to downgrade nginx-ingress is not a valid modern compatibility plan. Decide whether the proxy fronts the application directly or provides an external authentication decision, then check callback paths, forwarded headers and how unauthenticated requests are redirected.

Test login, expired sessions, insufficient group membership and maliciously supplied identity headers against an isolated endpoint. Register exact callback URLs with the identity provider and protect cookie and client secrets. A successful login alone does not prove application authorization. Preserve the chart path for historical readers while treating package replacement and provider configuration as an explicit migration, not a transparent image upgrade.