git.iko.soy/typeable/oauth2-proxy

on master help sign in

from

swap

to20d4e9c175 ahead, 0 behind

compare

.devcontainer/Dockerfile+1−1

@@ -1,4 +1,4 @@

1−FROM mcr.microsoft.com/vscode/devcontainers/go:1-1.23

1+FROM mcr.microsoft.com/vscode/devcontainers/go:1-1.26

22

33SHELL ["/bin/bash", "-o", "pipefail", "-c"]

44

.github/ISSUE_TEMPLATE/config.yml+2−2

@@ -1,6 +1,6 @@

11blank_issues_enabled: false

22contact_links:

3− - name: OAuth2-Proxy Slack

4− url: https://gophers.slack.com/messages/CM2RSS25N

3+ - name: OAuth2 Proxy Slack

4+ url: https://cloud-native.slack.com/archives/C098Y5URZ2N

55 about: Feel free to ask any questions here.

66

.github/PULL_REQUEST_TEMPLATE.md+3−2

@@ -20,7 +20,8 @@

2020<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->

2121<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

2222

23−- [ ] My change requires a change to the documentation or CHANGELOG.

24−- [ ] I have updated the documentation/CHANGELOG accordingly.

23+- [ ] I have added an entry for my changes to the [CHANGELOG.md](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/CHANGELOG.md).

24+- [ ] I have [signed off](https://github.com/apps/dco) all my commits.

2525- [ ] I have created a feature (non-master) branch for my PR.

26+- [ ] I have used [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#examples) for the PR title.

2627- [ ] I have written tests for my code changes.

.github/renovate.json5+9

@@ -46,6 +46,15 @@

4646 depNameTemplate: "alpine",

4747 datasourceTemplate: "docker",

4848 },

49+ {

50+ customType: "regex",

51+ fileMatch: [

52+ "^Makefile",

53+ ],

54+ matchStrings: [

55+ "# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)\\s+?GOLANGCILINT_VERSION \\?= (?<currentValue>.*)\\s",

56+ ],

57+ },

4958 {

5059 customType: "regex",

5160 fileMatch: ["(^|/)\\.github/workflows/[^/]+\\.ya?ml$"],

.github/workflows/ci.yml+57−20

@@ -7,29 +7,33 @@ on:

77 pull_request:

88 branches:

99 - '**'

10+ workflow_dispatch:

11+

12+permissions:

13+ contents: read

14+ id-token: write

15+ security-events: write

16+

1017jobs:

1118 build:

1219 runs-on: ubuntu-latest

13− env:

14− COVER: true

1520 steps:

1621 - name: Check out code

17− uses: actions/checkout@v5

18−

19− - name: Set up Go

20− uses: actions/setup-go@v5

22+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

2123 with:

22− go-version-file: go.mod

23− id: go

24+ fetch-depth: 0

2425

25− - name: Get dependencies

26− env:

27− # renovate: datasource=github-tags depName=golangci/golangci-lint

28− GOLANGCI_LINT_VERSION: v2.4.0

26+ - name: Get Go version

2927 run: |

30− curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin ${GOLANGCI_LINT_VERSION}

31− curl -L https://codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64 > ./cc-test-reporter

32− chmod +x ./cc-test-reporter

28+ version=$(grep "^go " go.mod | cut -d' ' -f2 | cut -d. -f1,2)

29+ echo "version=${version}" >> "$GITHUB_OUTPUT"

30+ id: go-version

31+

32+ - name: Set up Go

33+ uses: actions/setup-go@b7ad1dad31e06c5925ef5d2fc7ad053ef454303e # v7.0.0

34+ with:

35+ go-version: ${{ steps.go-version.outputs.version }}

36+ check-latest: true

3337

3438 - name: Verify Code Generation

3539 run: |

@@ -52,22 +56,55 @@ jobs:

5256

5357 - name: Test

5458 env:

55− CC_TEST_REPORTER_ID: ${{ secrets.CC_TEST_REPORTER_ID }}

59+ COVER: true

60+ run: |

61+ make test

62+

63+ - name: Generate Coverage Report

64+ if: github.event_name == 'push'

5665 run: |

57− ./.github/workflows/test.sh

66+ go install github.com/jandelgado/gcov2lcov@25681830fb515e3d4c117e136b4f049e21efb4d0

67+ gcov2lcov -infile=c.out -outfile=lcov.info

68+

69+ - name: Upload Coverage Report

70+ if: github.event_name == 'push'

71+ uses: qltysh/qlty-action/coverage@08a0a862c159eae9b9003081da6663d96efef637 # v2.3.0

72+ with:

73+ oidc: true

74+ files: lcov.info

75+

76+ - name: Run Trivy vulnerability scanner

77+ if: (!startsWith(github.head_ref, 'release'))

78+ uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0

79+ with:

80+ scan-type: 'rootfs'

81+ scan-ref: './oauth2-proxy'

82+ severity: 'CRITICAL,HIGH'

83+ hide-progress: true

84+ format: 'sarif'

85+ output: 'trivy-results.sarif'

86+ exit-code: '0'

87+

88+ - name: Upload Trivy scan results

89+ if: (!startsWith(github.head_ref, 'release'))

90+ uses: github/codeql-action/upload-sarif@ff2f1c621b7f889edc0d3c761ac2e6a3f8cdb0dd # v4.37.7

91+ with:

92+ sarif_file: 'trivy-results.sarif'

5893

5994 docker:

6095 runs-on: ubuntu-latest

6196 steps:

6297 - name: Check out code

63− uses: actions/checkout@v5

98+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

99+ with:

100+ fetch-depth: 0

64101

65102 - name: Set up QEMU

66− uses: docker/setup-qemu-action@v3

103+ uses: docker/setup-qemu-action@96fe6ef7f33517b61c61be40b68a1882f3264fb8 # v4.2.0

67104

68105 - name: Set up Docker Buildx

69106 id: buildx

70− uses: docker/setup-buildx-action@v3

107+ uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0

71108

72109 - name: Docker Build

73110 if: (!startsWith(github.head_ref, 'release'))

.github/workflows/codeql.yml+4−4

@@ -32,18 +32,18 @@ jobs:

3232

3333 steps:

3434 - name: Checkout repository

35− uses: actions/checkout@v5

35+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

3636

3737 # Initializes the CodeQL tools for scanning.

3838 - name: Initialize CodeQL

39− uses: github/codeql-action/init@v3

39+ uses: github/codeql-action/init@ff2f1c621b7f889edc0d3c761ac2e6a3f8cdb0dd # v4.37.7

4040 with:

4141 languages: go

4242

4343 # Autobuild attempts to build any compiled languages (C/C++, C#, or Java).

4444 # If this step fails, then you should remove it and run the build manually (see below)

4545 - name: Autobuild

46− uses: github/codeql-action/autobuild@v3

46+ uses: github/codeql-action/autobuild@ff2f1c621b7f889edc0d3c761ac2e6a3f8cdb0dd # v4.37.7

4747

4848 # ℹ️ Command-line programs to run using the OS shell.

4949 # 📚 https://git.io/JvXDl

@@ -57,4 +57,4 @@ jobs:

5757 # make release

5858

5959 - name: Perform CodeQL Analysis

60− uses: github/codeql-action/analyze@v3

60+ uses: github/codeql-action/analyze@ff2f1c621b7f889edc0d3c761ac2e6a3f8cdb0dd # v4.37.7

.github/workflows/create-release.yml+2−2

@@ -17,7 +17,7 @@ jobs:

1717 runs-on: ubuntu-latest

1818 steps:

1919 - name: Check out code

20− uses: actions/checkout@v5

20+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

2121 with:

2222 ref: master

2323 fetch-depth: 0

@@ -54,7 +54,7 @@ jobs:

5454 git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"

5555

5656 - name: Setup node

57− uses: actions/setup-node@v4

57+ uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0

5858 with:

5959 node-version-file: docs/package.json

6060

.github/workflows/docs.yml+9−9

@@ -14,16 +14,16 @@ jobs:

1414 if: github.event_name == 'pull_request'

1515 runs-on: ubuntu-latest

1616 steps:

17− - uses: actions/checkout@v5

17+ - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

1818

1919 - name: Setup Pages

2020 id: pages

21− uses: actions/configure-pages@v5

21+ uses: actions/configure-pages@45bfe0192ca1faeb007ade9deae92b16b8254a0d # v6.0.0

2222

23− - uses: actions/setup-node@v4

23+ - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0

2424 with:

2525 # renovate: datasource=node-version depName=node

26− node-version: 22

26+ node-version: 24

2727

2828 - name: Test Build

2929 working-directory: ./docs

@@ -35,12 +35,12 @@ jobs:

3535 if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'

3636 runs-on: ubuntu-latest

3737 steps:

38− - uses: actions/checkout@v5

38+ - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

3939

40− - uses: actions/setup-node@v4

40+ - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0

4141 with:

4242 # renovate: datasource=node-version depName=node

43− node-version: 22

43+ node-version: 24

4444

4545 - name: Build docusaurus

4646 working-directory: ./docs

@@ -49,7 +49,7 @@ jobs:

4949 npm run build

5050

5151 - name: Upload artifact

52− uses: actions/upload-pages-artifact@v3

52+ uses: actions/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9 # v5.0.0

5353 with:

5454 path: ./docs/build

5555

@@ -65,4 +65,4 @@ jobs:

6565 steps:

6666 - name: Deploy to GitHub Pages

6767 id: deployment

68− uses: actions/deploy-pages@v4

68+ uses: actions/deploy-pages@cd2ce8fcbc39b97be8ca5fce6e763baed58fa128 # v5.0.0

.github/workflows/labeler.yml+1−1

@@ -9,7 +9,7 @@ jobs:

99 pull-requests: write

1010 runs-on: ubuntu-latest

1111 steps:

12− - uses: actions/labeler@v5

12+ - uses: actions/labeler@bf12e9b00b37c5c0ca2b87b79b2daf7891dbda13 # v7.0.0

1313 with:

1414 sync-labels: true

1515 dot: true

.github/workflows/nightly.yml+4−4

@@ -12,21 +12,21 @@ jobs:

1212 if: github.repository == 'oauth2-proxy/oauth2-proxy'

1313 steps:

1414 - name: Check out code

15− uses: actions/checkout@v5

15+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

1616 with:

1717 ref: master

1818 fetch-depth: 0

1919 fetch-tags: true

2020

2121 - name: Set up QEMU

22− uses: docker/setup-qemu-action@v3

22+ uses: docker/setup-qemu-action@96fe6ef7f33517b61c61be40b68a1882f3264fb8 # v4.2.0

2323

2424 - name: Set up Docker Buildx

2525 id: buildx

26− uses: docker/setup-buildx-action@v3

26+ uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0

2727

2828 - name: Login to quay.io

29− uses: docker/login-action@v3

29+ uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0

3030 with:

3131 registry: quay.io/oauth2-proxy

3232 username: ${{ secrets.REGISTRY_USERNAME_NIGHTLY }}

.github/workflows/publish-release.yml+22−22

@@ -14,49 +14,49 @@ permissions:

1414

1515jobs:

1616 publish:

17− if: github.event.pull_request.merged && startsWith(github.event.pull_request.head.ref, 'release/')

17+ if: github.event.pull_request.merged && startsWith(github.event.pull_request.head.ref, 'release/') && github.event.pull_request.head.repo.full_name == github.repository

1818 runs-on: ubuntu-latest

1919 outputs:

2020 tag: ${{ steps.tag.outputs.version }}

2121 steps:

2222 - name: Check out code

23− uses: actions/checkout@v5

23+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

2424 with:

2525 ref: ${{ github.event.pull_request.merge_commit_sha }}

2626 fetch-depth: 0

2727 fetch-tags: true

2828

2929 - name: Tag release

30+ env:

31+ BRANCH: ${{ github.event.pull_request.head.ref }}

3032 run: |

3133 # Set up github-actions[bot] user

3234 git config --local user.name "github-actions[bot]"

3335 git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"

3436

3537 # Get the version from the branch name

36− branch="${{ github.event.pull_request.head.ref }}"

37− version="${branch#release/}"

38+ version="${BRANCH#release/}"

3839 echo ${version}

3940

4041 # Tag and create release

4142 git tag -a "${version}" -m "Release ${version}"

4243 echo "version=${version}" >> $GITHUB_OUTPUT

4344 id: tag

44−

45− - name: Set up go

46− uses: actions/setup-go@v5

47− with:

48− go-version-file: go.mod

4945

50− - name: Get dependencies

51− env:

52− # renovate: datasource=github-tags depName=golangci/golangci-lint

53− GOLANGCI_LINT_VERSION: v2.4.0

46+ - name: Get Go version

5447 run: |

55− curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin ${GOLANGCI_LINT_VERSION}

56− curl -L https://codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64 > ./cc-test-reporter

57− chmod +x ./cc-test-reporter

48+ version=$(grep "^go " go.mod | cut -d' ' -f2 | cut -d. -f1,2)

49+ echo "version=${version}" >> "$GITHUB_OUTPUT"

50+ id: go-version

5851

59− # Install go dependencies

52+ - name: Set up Go

53+ uses: actions/setup-go@b7ad1dad31e06c5925ef5d2fc7ad053ef454303e # v7.0.0

54+ with:

55+ go-version: ${{ steps.go-version.outputs.version }}

56+ check-latest: true

57+

58+ - name: Get go dependencies

59+ run: |

6060 go mod download

6161

6262 - name: Build Artifacts

@@ -64,7 +64,7 @@ jobs:

6464

6565 # Upload artifacts in case of workflow failure

6666 - name: Upload Artifacts

67− uses: actions/upload-artifact@v4

67+ uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1

6868 with:

6969 name: oauth2-proxy-artifacts

7070 path: |

@@ -100,21 +100,21 @@ jobs:

100100 runs-on: ubuntu-latest

101101 steps:

102102 - name: Check out code

103− uses: actions/checkout@v5

103+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

104104 with:

105105 ref: ${{ needs.publish.outputs.tag }}

106106 fetch-depth: 0

107107 fetch-tags: true

108108

109109 - name: Set up QEMU

110− uses: docker/setup-qemu-action@v3

110+ uses: docker/setup-qemu-action@96fe6ef7f33517b61c61be40b68a1882f3264fb8 # v4.2.0

111111

112112 - name: Set up Docker Buildx

113113 id: buildx

114− uses: docker/setup-buildx-action@v3

114+ uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0

115115

116116 - name: Login to quay.io

117− uses: docker/login-action@v3

117+ uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0

118118 with:

119119 registry: quay.io/oauth2-proxy

120120 username: ${{ secrets.REGISTRY_USERNAME }}

.github/workflows/stale.yml+1−1

@@ -10,7 +10,7 @@ jobs:

1010 runs-on: ubuntu-latest

1111

1212 steps:

13− - uses: actions/stale@v9

13+ - uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0

1414 with:

1515 repo-token: ${{ secrets.GITHUB_TOKEN }}

1616 days-before-stale: 180

.github/workflows/test.shdeleted−26

@@ -1,26 +0,0 @@

1−#!/bin/bash

2−# manually exiting from script, because after-build needs to run always

3−set +e

4−

5−if [ -z $CC_TEST_REPORTER_ID ]; then

6− echo "1. CC_TEST_REPORTER_ID is unset, skipping"

7−else

8− echo "1. Running before-build"

9− ./cc-test-reporter before-build

10−fi

11−

12−echo "2. Running test"

13−make test

14−TEST_STATUS=$?

15−

16−if [ -z $CC_TEST_REPORTER_ID ]; then

17− echo "3. CC_TEST_REPORTER_ID is unset, skipping"

18−else

19− echo "3. Running after-build"

20− ./cc-test-reporter after-build --exit-code $TEST_STATUS --prefix $(go list -m)

21−fi

22−

23−if [ "$TEST_STATUS" -ne 0 ]; then

24− echo "Test failed, status code: $TEST_STATUS"

25− exit $TEST_STATUS

26−fi

.golangci.yml+9−1

@@ -37,7 +37,7 @@ linters:

3737 - linters:

3838 - revive

3939 path: _test\.go

40− text: 'dot-imports:'

40+ text: "dot-imports:"

4141 # # If we have tests in shared test folders, these can be less strictly linted

4242 - linters:

4343 - bodyclose

@@ -53,6 +53,14 @@ linters:

5353 - revive

5454 path: util/.*\.go$

5555 text: "var-naming: avoid meaningless package names"

56+ # pkg/version conflicts with go/version (added in Go 1.22)

57+ - linters:

58+ - revive

59+ path: pkg/version/.*\.go$

60+ text: "var-naming: avoid package names that conflict with"

61+ - linters:

62+ - prealloc

63+ path: _test\.go

5664 paths:

5765 - third_party$

5866 - builtin$

ADOPTERS.mddeleted−28

@@ -1,28 +0,0 @@

1−# Adopters

2−

3−This list showcases organizations that leverage OAuth2-Proxy within their

4−infrastructure. If your organization uses OAuth2-Proxy and isn't yet listed, we

5−encourage you to add it!

6−

7−This list aims to be a comprehensive and trusted resource for the OAuth2-Proxy

8−community, demonstrating successful adoption across all kinds of industries.

9−

10−Contributing to this list is a simple way to impact the project's growth,

11−maturity, and momentum. Thank you to all adopters and contributors of the

12−OAuth2-Proxy project!

13−

14−## Updating this list

15−

16−To add your organization to this list, you can just [open a PR](https://github.com/oauth2-proxy/oauth2-proxy/pulls)

17−to directly update this list.

18−

19−Add your organization name, your github username and if you desire a short

20−description on how you utilize oauth2-proxy.

21−

22−## OAuth2-Proxy Adopters

23−

24−This list is sorted in the order that organizations were added to it.

25−

26−| Organization | Contact | Description of Use |

27−| ------------ | ------- | ------------------ |

28−| | | |

CHANGELOG.md+356−1

@@ -2,8 +2,361 @@

22

33## Release Highlights

44

5+## Important Notes

6+

7+## Breaking Changes

8+

9+## Changes since v7.15.4

10+

11+# V7.15.4

12+

13+## Release Highlights

14+

15+- 🔵 Golang version upgrade to v1.26.7

16+ - Upgrade of all dependencies to their latest versions

17+- 🕵️‍♀️ Vulnerabilities have been addressed

18+ - [CVE-2026-33818](https://nvd.nist.gov/vuln/detail/CVE-2026-33818)

19+ - [CVE-2026-39821](https://nvd.nist.gov/vuln/detail/CVE-2026-39821)

20+ - [CVE-2026-39822](https://nvd.nist.gov/vuln/detail/CVE-2026-39822)

21+ - [CVE-2026-42505](https://nvd.nist.gov/vuln/detail/CVE-2026-42505)

22+ - [CVE-2026-46600](https://nvd.nist.gov/vuln/detail/CVE-2026-46600)

23+ - [CVE-2026-56852](https://nvd.nist.gov/vuln/detail/CVE-2026-56852)

24+ - [CVE-2026-56853](https://nvd.nist.gov/vuln/detail/CVE-2026-56853)

25+ - [CVE-2026-56858](https://nvd.nist.gov/vuln/detail/CVE-2026-56858)

26+ - [CVE-2026-56859](https://nvd.nist.gov/vuln/detail/CVE-2026-56859)

27+ - [CVE-2026-56860](https://nvd.nist.gov/vuln/detail/CVE-2026-56860)

28+ - [CVE-2026-56862](https://nvd.nist.gov/vuln/detail/CVE-2026-56862)

29+

30+## Important Notes

31+

32+## Breaking Changes

33+

34+## Changes since v7.15.3

35+

36+- [#3493](https://github.com/oauth2-proxy/oauth2-proxy/pull/3493) chore(deps): update gomod @tuunit

37+

38+# V7.15.3

39+

40+## Release Highlights

41+

42+- 🔵 Golang version upgrade to v1.26.4

43+ - Upgrade of all dependencies to their latest versions

44+- 🕵️‍♀️ Vulnerabilities have ben addressed

45+ - [CVE-2026-33811](https://nvd.nist.gov/vuln/detail/)

46+ - [CVE-2026-33814](https://nvd.nist.gov/vuln/detail/)

47+ - [CVE-2026-39820](https://nvd.nist.gov/vuln/detail/)

48+ - [CVE-2026-39836](https://nvd.nist.gov/vuln/detail/)

49+ - [CVE-2026-42499](https://nvd.nist.gov/vuln/detail/)

50+ - [CVE-2026-42504](https://nvd.nist.gov/vuln/detail/)

51+ - [CVE-2026-39823](https://nvd.nist.gov/vuln/detail/)

52+ - [CVE-2026-39826](https://nvd.nist.gov/vuln/detail/)

53+ - [CVE-2026-39825](https://nvd.nist.gov/vuln/detail/)

54+ - [CVE-2026-27145](https://nvd.nist.gov/vuln/detail/)

55+ - [CVE-2026-42507](https://nvd.nist.gov/vuln/detail/)

56+

57+## Important Notes

58+

59+## Breaking Changes

60+

61+## Changes since v7.15.2

62+

63+- [#3477](https://github.com/oauth2-proxy/oauth2-proxy/pull/3477) chore(dep): bump go to 1.26 and migrate of reverse proxy handling

64+

65+# V7.15.2

66+

67+## Release Highlights

68+

69+- 🔵 Golang version upgrade to v1.25.9

70+ - Upgrade of all dependencies to their latest versions

71+ - [CVE-2026-34986](https://nvd.nist.gov/vuln/detail/CVE-2026-34986)

72+ - [CVE-2026-32281](https://nvd.nist.gov/vuln/detail/CVE-2026-32281)

73+ - [CVE-2026-32289](https://nvd.nist.gov/vuln/detail/CVE-2026-32289)

74+ - [CVE-2026-32288](https://nvd.nist.gov/vuln/detail/CVE-2026-32288)

75+ - [CVE-2026-32280](https://nvd.nist.gov/vuln/detail/CVE-2026-32280)

76+ - [CVE-2026-32282](https://nvd.nist.gov/vuln/detail/CVE-2026-32282)

77+ - [CVE-2026-32283](https://nvd.nist.gov/vuln/detail/CVE-2026-32283)

78+- 🕵️‍♀️ Vulnerabilities have been addressed

79+

80+## Important Notes

81+

82+We have had security audits performed on OAuth2 Proxy in the past couple of weeks and as a result we have fixed

83+several CRITICAL vulnerabilities.

84+

85+The security vulnerabilities include multiple authentication bypasses and a potential session fixation attack.

86+For more details and to identify if you are effects, we urge all users of OAuth2 Proxy to read the security

87+disclosures.

88+

89+- (Critical) [GHSA-5hvv-m4w4-gf6v](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-5hvv-m4w4-gf6v) fix: health check user-agent authentication bypass

90+- (Critical) [GHSA-7x63-xv5r-3p2x](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-7x63-xv5r-3p2x) fix: authentication bypass via X-Forwarded-Uri header spoofing

91+- (High) [GHSA-pxq7-h93f-9jrg](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-pxq7-h93f-9jrg) fix: fragment evaluation as part of the allowed routes

92+- (Moderate) [GHSA-c5c4-8r6x-56w3](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-c5c4-8r6x-56w3) fix: email validation bypass via malformed multi-@ email claims

93+

94+Furthermore, for improving the security of OAuth2 Proxy we introduced a new flag `--trusted-proxy-ip` that allows users

95+to explicitly specify trusted reverse proxy IPs for the `X-Forwarded-*` headers. This is an important step to prevent

96+potential header spoofing attacks and to ensure that OAuth2 Proxy only trusts headers from known and trusted sources.

97+We highly recommend users to review their deployment architecture and consider using this flag to enhance the security

98+of their OAuth2 Proxy instances. Check the docs for more details: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#proxy-options

99+

100+Furthermore, we want to thank everyone who contributed to the audits and reported potential issues to make open source

101+software like OAuth2 Proxy more secure for everyone.

102+

103+## Breaking Changes

104+

105+## Changes since v7.15.1

106+

107+- [#3411](https://github.com/oauth2-proxy/oauth2-proxy/pull/3411) chore(deps): update gomod dependencies (@tuunit)

108+- [#3333](https://github.com/oauth2-proxy/oauth2-proxy/pull/3333) fix: invalidate session on fatal OAuth2 refresh errors (@frhack)

109+- [GHSA-f24x-5g9q-753f](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-f24x-5g9q-753f) fix: clear session cookie at beginning of signinpage handler (@fnoehWM / @bella-WI / @tuunit)

110+- [GHSA-5hvv-m4w4-gf6v](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-5hvv-m4w4-gf6v) fix: health check user-agent authentication bypass (@tuunit)

111+- [GHSA-7x63-xv5r-3p2x](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-7x63-xv5r-3p2x) fix: authentication bypass via X-Forwarded-Uri header spoofing (@tuunit)

112+- [GHSA-pxq7-h93f-9jrg](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-pxq7-h93f-9jrg) fix: fragment evaluation as part of the allowed routes (@tuunit)

113+- [GHSA-c5c4-8r6x-56w3](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-c5c4-8r6x-56w3) fix: email validation bypass via malformed multi-@ email claims (@tuunit)

114+

115+# V7.15.1

116+

117+## Release Highlights

118+

119+- 🐛 Squashed some bugs

120+- 🕵️‍♀️ Vulnerabilities have been addressed

121+ - [CVE-2026-33186](https://nvd.nist.gov/vuln/detail/CVE-2026-33186)

122+ OAuth2 Proxy was not impacted by this vulnerability as it isn't in the path of execution

123+

124+## Important Notes

125+

126+## Breaking Changes

127+

128+## Changes since v7.15.0

129+

130+- [#3382](https://github.com/oauth2-proxy/oauth2-proxy/pull/3382) chore(deps): update gomod and golangci/golangci-lint to v2.11.4 (@tuunit)

131+- [#3374](https://github.com/oauth2-proxy/oauth2-proxy/pull/3374) fix: handle Unix socket RemoteAddr in IP resolution (@H1net)

132+- [#3381](https://github.com/oauth2-proxy/oauth2-proxy/pull/3381) fix: do not log error for backend logout 204 (@artificiosus)

133+- [#3327](https://github.com/oauth2-proxy/oauth2-proxy/pull/3327) fix: improve logging when session refresh token is missing (@yosri-brh)

134+- [#2767](https://github.com/oauth2-proxy/oauth2-proxy/pull/2767) fix: propagate errors during route building (@sybereal)

135+

136+# V7.15.0

137+

138+## Release Highlights

139+

140+- 🔒 OIDC JWT signing algorithms can now be configured

141+- 🍪 CSRF cookie improvements (SameSite option, proper expiration validation)

142+- 🧪 Configuration validation flag: --config-test

143+- 🔌 Unix socket file mode support

144+- 👤 Session state can now be extend with arbitrary claims from ID Token and upstream IDP user profiles endpoint

145+ - This opens the door for multiple features like:

146+ - Additional arbitrary header values for any claims your IDP provides

147+ - Extended OAuth2 Proxy UserInfo endpoint with all additional claims

148+ - Read the docs [here](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#how-to-utilize-arbitrary-claims-provided-by-your-identity-provider)

149+

150+## Important Notes

151+

152+CSRF cookie validation now correctly uses `CSRFExpire` instead of `Expire`. If you relied on the previous behavior, review your session timeout configuration.

153+Check the [documentation(https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#cookie-options) for `cookie-csrf-expire`.

154+

155+## Breaking Changes

156+

157+## Changes since v7.14.3

158+

159+- [#3352](https://github.com/oauth2-proxy/oauth2-proxy/pull/3352) fix: backend logout URL call on sign out (#3172)(@vsejpal)

160+- [#3332](https://github.com/oauth2-proxy/oauth2-proxy/pull/3332) ci: distribute windows binary with .exe extension (@igitur)

161+- [#2685](https://github.com/oauth2-proxy/oauth2-proxy/pull/2685) feat: allow arbitrary claims from the IDToken and IdentityProvider UserInfo endpoint to be added to the session state (@vegetablest)

162+- [#3278](https://github.com/oauth2-proxy/oauth2-proxy/pull/3278) feat: possibility to inject id_token in redirect url during sign out (@albanf)

163+- [#2851](https://github.com/oauth2-proxy/oauth2-proxy/pull/2851) feat: add support for specifying allowed OIDC JWT signing algorithms (#2753) (@andoks / @tuunit)

164+- [#3369](https://github.com/oauth2-proxy/oauth2-proxy/pull/3369) fix: use CSRFExpire instead of Expire for CSRF cookie validation (@Br1an67)

165+- [#3365](https://github.com/oauth2-proxy/oauth2-proxy/pull/3365) fix: filter empty strings from allowed groups (@Br1an67)

166+- [#3338](https://github.com/oauth2-proxy/oauth2-proxy/pull/3338) feat: add --config-test flag for validating configuration (@MayorFaj)

167+- [#3347](https://github.com/oauth2-proxy/oauth2-proxy/pull/3347) feat: add same site option for csrf cookies (@jvnoije)

168+- [#3376](https://github.com/oauth2-proxy/oauth2-proxy/pull/3376) feat: allow setting unix socket file mode when declaring listener (@Tristan971 / @tuunit)

169+

170+# V7.14.3

171+

172+## Release Highlights

173+

174+- 🔵 Go1.25.7 and upgrade of dependencies to latest versions

175+ - Fixes [CVE-2025-68121](https://nvd.nist.gov/vuln/detail/cve-2025-68121)

176+- 🐛 Bug fixes

177+ - Allow Redis URL parameters to configure username, password and max idle connection timeout if the matching configuration is empty.

178+

179+## Important Notes

180+

181+We improved our supply chain security by added additional checks to prevent potential command injection in the publish release workflow and to ensure that it can only be triggered from branches originating in the local repository. This potential issue was reported by automated systems as well as a couple of security researchers, and we want to thank everyone for their diligence in looking out for the security of the project. Especially Aastha Aggarwal for her detailed report and follow-up. @Aastha2602

182+

183+

184+## Breaking Changes

185+

186+## Changes since v7.14.2

187+

188+- [#3183](https://github.com/oauth2-proxy/oauth2-proxy/pull/3183) fix: allow URL parameters to configure username, password and max idle connection timeout if the matching configuration is empty.

189+

190+# V7.14.2

191+

192+## Release Highlights

193+

194+- Revert AuthOnly endpoint change from v7.14.1 that caused issues when using `skip-provider-button` enabled

195+

196+## Important Notes

197+

198+- This release reverts the change made in v7.14.1 that caused issues when using the `skip-provider-button` enabled. Now, when a session does not exist, the AuthOnly endpoint will send a 401 status code as expected instead of a 302 redirect. And instead we extended the documentation to clarify the behavior when using `nginx` with `auth_request` and `skip-provider-button` and how to properly configure redirects for browser and API routes.

199+

200+## Breaking Changes

201+

202+## Changes since v7.14.1

203+

204+- [#3314](https://github.com/oauth2-proxy/oauth2-proxy/pull/3314) revert: fix: skip provider button auth only redirect (#3309) (@StefanMarkmann / @tuunit)

205+- [#3315](https://github.com/oauth2-proxy/oauth2-proxy/pull/3315) docs: clarify browser vs API routes for nginx auth_request redirects (@StefanMarkmann)

206+

207+# V7.14.1

208+

209+## Release Highlights

210+

211+- 🔵 Go1.25.6 and upgrade of dependencies to latest versions

212+- 🐛 Bug fixes

213+ - AuthOnly now starts the auth flow and send status code 302 if no session exists and skip-provider-button is true

214+ - Fixed static upstream validation issue due to incorrect defaults

215+

216+## Important Notes

217+

218+## Breaking Changes

219+

220+## Changes since v7.14.0

221+

222+- [#3309](https://github.com/oauth2-proxy/oauth2-proxy/pull/3309) fix: Return 302 redirect from AuthOnly endpoint when skip-provider-button is true (@StefanMarkmann)

223+- [#3302](https://github.com/oauth2-proxy/oauth2-proxy/pull/3302) fix: static upstreams failing validation due to `passHostHeader` and `proxyWebSockets` defaults being set incorrectly (@sourava01 / @tuunit)

224+- [#3312](https://github.com/oauth2-proxy/oauth2-proxy/pull/3312) chore(deps): upgrade to go1.25.6 and latest dependencies (@tuunit)

225+

226+# V7.14.0

227+

228+## Release Highlights

229+

230+- 🕵️‍♀️ Vulnerabilities have been addressed

231+ - [CVE-2025-61729](https://access.redhat.com/security/cve/cve-2025-61729)

232+ - [CVE-2025-61727](https://access.redhat.com/security/cve/cve-2025-61727)

233+ - [CVE-2025-47914](https://access.redhat.com/security/cve/cve-2025-47914)

234+ - [CVE-2025-58181](https://access.redhat.com/security/cve/cve-2025-58181)

235+- 🗂️ AMajor Alpha Config YAML parsing revamped for better extensibility and preparing v8

236+- 🐛 Squashed some bugs

237+

238+## Important Notes

239+

240+This release introduces a breaking change for Alpha Config users and moves us significantly

241+closer to removing legacy configuration parameters, making the codebase of OAuth2 Proxy more

242+future proof and extensible.

243+

244+From v7.14.0 onward, header injection sources must be explicitly nested. If you

245+previously relied on squashed fields, update to the new structure before upgrading:

246+

247+```yaml

248+# before v7.14.0

249+injectRequestHeaders:

250+- name: X-Forwarded-User

251+ values:

252+ - claim: user

253+- name: X-Custom-Secret-header

254+ values:

255+ - value: my-super-secret

256+

257+# v7.14.0 and later

258+injectRequestHeaders:

259+- name: X-Forwarded-User

260+ values:

261+ - claimSource:

262+ claim: user

263+- name: X-Custom-Secret-header

264+ values:

265+ - secretSource:

266+ value: my-super-secret

267+```

268+

269+Furthermore, Alpha Config now fully supports configuring the `Server` struct using YAML.

270+

271+```yaml

272+// Server represents the configuration for the Proxy HTTP(S) configuration.

273+type Server struct {

274+ // BindAddress is the address on which to serve traffic.

275+ BindAddress string `yaml:"bindAddress,omitempty"`

276+

277+ // SecureBindAddress is the address on which to serve secure traffic.

278+ SecureBindAddress string `yaml:"secureBindAddress,omitempty"`

279+

280+ // TLS contains the information for loading the certificate and key for the

281+ // secure traffic and further configuration for the TLS server.

282+ TLS *TLS `yaml:"tls,omitempty"`

283+}

284+

285+// TLS contains the information for loading a TLS certificate and key

286+// as well as an optional minimal TLS version that is acceptable.

287+type TLS struct {

288+ // Key is the TLS key data to use.

289+ Key *SecretSource `yaml:"key,omitempty"`

290+ // Cert is the TLS certificate data to use.

291+ Cert *SecretSource `yaml:"cert,omitempty"`

292+ // MinVersion is the minimal TLS version that is acceptable.

293+ MinVersion string `yaml:"minVersion,omitempty"`

294+ // CipherSuites is a list of TLS cipher suites that are allowed.

295+ CipherSuites []string `yaml:"cipherSuites,omitempty"`

296+}

297+```

298+

299+More about how to use Alpha Config can be found in the [documentation](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#server).

300+

301+We are committed to Semantic Versioning and usually avoid breaking changes without a major version release.

302+Advancing Alpha Config toward its Beta stage required this exception, and even for the Alpha Config we try

303+to keep breaking changes in v7 to a minium. Thank you for understanding the need for this step to prepare

304+the project for future maintainability and future improvements like structured logging.

305+

306+## Breaking Changes

307+

308+- Alpha Config: header injection no longer supports squashed claim/secret sources; they must now be set explicitly (see example above).

309+

310+## Changes since v7.13.0

311+

312+- [#2628](https://github.com/oauth2-proxy/oauth2-proxy/pull/2628) feat(structured config): revamp of yaml parsing using mapstructure decoder and custom decoders (@tuunit)

313+- [#3197](https://github.com/oauth2-proxy/oauth2-proxy/pull/3197) fix: NewRemoteKeySet is not using DefaultHTTPClient (@rsrdesarrollo / @tuunit)

314+- [#3292](https://github.com/oauth2-proxy/oauth2-proxy/pull/3292) chore(deps): upgrade gomod and bump to golang v1.25.5 (@tuunit)

315+- [#3304](https://github.com/oauth2-proxy/oauth2-proxy/pull/3304) fix: added conditional so default is not always set and env vars are honored fixes 3303 (@pixeldrew)

316+- [#3264](https://github.com/oauth2-proxy/oauth2-proxy/pull/3264) fix: more aggressively truncate logged access_token (@MartinNowak / @tuunit)

317+- [#3267](https://github.com/oauth2-proxy/oauth2-proxy/pull/3267) fix: Session refresh handling in OIDC provider (@gysel)

318+- [#3290](https://github.com/oauth2-proxy/oauth2-proxy/pull/3290) fix: WebSocket proxy to respect PassHostHeader setting (@UnsignedLong)

319+

320+# V7.13.0

321+

322+## Release Highlights

323+

324+- 🕵️‍♀️ Vulnerabilities have been addressd

325+ - [CVE-2025-47912](https://nvd.nist.gov/vuln/detail/CVE-2025-47912)

326+ - [CVE-2025-58183](https://nvd.nist.gov/vuln/detail/CVE-2025-58183)

327+ - [CVE-2025-58186](https://nvd.nist.gov/vuln/detail/CVE-2025-58186)

328+ - [CVE-2025-64484](https://nvd.nist.gov/vuln/detail/CVE-2025-64484)

329+- 🐛 Squashed some bugs

330+

331+## Important Notes

332+

333+By default all specified headers will now be normalized, meaning that both capitalization and the use of underscores (_) versus dashes (-) will be ignored when matching headers to be stripped. For example, both `X-Forwarded-For` and `X_Forwarded-for` will now be treated as equivalent and stripped away.

334+

335+Please read our security advisory for CVE-2025-64484: [GHSA-vjrc-mh2v-45x6](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-vjrc-mh2v-45x6)

336+

337+Furthermore, we now use the access_token for validating refreshed sessions in OIDC providers instead of the id_token. This is to align with the [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens) which states that id_tokens are not guaranteed to be issued when using refresh tokens. In future releases we might remove the id_token validation for sessions completely.

338+

339+## Breaking Changes

340+

341+## Changes since v7.12.0

342+

343+- [#3228](https://github.com/oauth2-proxy/oauth2-proxy/pull/3228) fix: use GetSecret() in ticket.go makeCookie to respect cookie-secret-file (@stagswtf)

344+- [#3244](https://github.com/oauth2-proxy/oauth2-proxy/pull/3244) chore(deps): upgrade to latest go1.25.3 (@tuunit)

345+- [#3238](https://github.com/oauth2-proxy/oauth2-proxy/pull/3238) chore: Replace pkg/clock with narrowly targeted stub clocks (@dsymonds)

346+- [#3237](https://github.com/oauth2-proxy/oauth2-proxy/pull/3237) - feat: add option to use organization id for preferred username in Google Provider (@pixeldrew)

347+- [GHSA-vjrc-mh2v-45x6](https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-vjrc-mh2v-45x6) fix: request header smuggling by stripping all normalized header variants (@tuunit)

348+- [#1933](https://github.com/oauth2-proxy/oauth2-proxy/pull/1933) fix: validation of refreshed sessions using the access_token in the OIDC provider (@gysel / @tuunit)

349+- [#2841](https://github.com/oauth2-proxy/oauth2-proxy/pull/2841) feat: add allowed_* constraint option to proxy endpoint query string (@jacobalberty)

350+

351+# V7.12.0

352+

353+## Release Highlights

354+

5355- 🕵️‍♀️ Vulnerabilities have been addressed

6356 - [CVE-2025-47907](https://pkg.go.dev/vuln/GO-2025-3849)

357+- 🦸 Support for Cidaas IDP

358+- 🐛 Squashed some bugs

359+

7360

8361## Important Notes

9362

@@ -13,6 +366,8 @@

13366

14367- [#2273](https://github.com/oauth2-proxy/oauth2-proxy/pull/2273) feat: add Cidaas provider (@Bibob7, @Teko012)

15368- [#3166](https://github.com/oauth2-proxy/oauth2-proxy/pull/3166) chore(dep): upgrade to latest golang 1.24.6 (@tuunit)

369+- [#3156](https://github.com/oauth2-proxy/oauth2-proxy/pull/3156) feat: allow disable-keep-alives configuration for upstream (@jet-go)

370+- [#3150](https://github.com/oauth2-proxy/oauth2-proxy/pull/3150) fix: Gitea team membership (@MagicRB, @tuunit)

16371

17372# V7.11.0

18373

@@ -104,7 +459,7 @@ For detailed information, migration guidance, and security implications, see the

104459- 🕵️‍♀️ Vulnerabilities have been addressed

105460 - [CVE-2025-22871](https://github.com/advisories/GHSA-g9pc-8g42-g6vq)

106461- 🐛 Squashed some bugs

107−

462+

108463## Important Notes

109464

110465## Breaking Changes

CODE_OF_CONDUCT.md+81−103

@@ -1,134 +1,112 @@

1−# Contributor Covenant Code of Conduct

1+## CNCF Community Code of Conduct v1.3

2+

3+Other languages available:

4+- [Arabic/العربية](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/ar.md)

5+- [Bengali/বাংলা](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/bn.md)

6+- [Bulgarian/Български](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/bg.md)

7+- [Chinese/中文](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/zh.md)

8+- [Czech/Česky](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/cs.md)

9+- [Farsi/فارسی](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/fa.md)

10+- [French/Français](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/fr.md)

11+- [German/Deutsch](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/de.md)

12+- [Hebrew/עברית](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/he.md)

13+- [Hindi/हिन्दी](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/hi.md)

14+- [Hungarian/Magyar](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/hu.md)

15+- [Indonesian/Bahasa Indonesia](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/id.md)

16+- [Italian/Italiano](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/it.md)

17+- [Japanese/日本語](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/ja.md)

18+- [Korean/한국어](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/ko.md)

19+- [Polish/Polski](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/pl.md)

20+- [Portuguese/Português](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/pt.md)

21+- [Russian/Русский](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/ru.md)

22+- [Spanish/Español](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/es.md)

23+- [Turkish/Türkçe](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/tr.md)

24+- [Ukrainian/Українська](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/uk.md)

25+- [Vietnamese/Tiếng Việt](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/vi.md)

26+

27+### Community Code of Conduct

28+

29+As contributors, maintainers, and participants in the CNCF community, and in the interest of fostering

30+an open and welcoming community, we pledge to respect all people who participate or contribute

31+through reporting issues, posting feature requests, updating documentation,

32+submitting pull requests or patches, attending conferences or events, or engaging in other community or project activities.

33+

34+We are committed to making participation in the CNCF community a harassment-free experience for everyone, regardless of age, body size, caste, disability, ethnicity, level of experience, family status, gender, gender identity and expression, marital status, military or veteran status, nationality, personal appearance, race, religion, sexual orientation, socioeconomic status, tribe, or any other dimension of diversity.

235

3−## Our Pledge

36+## Scope

37+

38+This code of conduct applies:

39+* within project and community spaces,

40+* in other spaces when an individual CNCF community participant's words or actions are directed at or are about a CNCF project, the CNCF community, or another CNCF community participant in the context of a CNCF activity.

441

5−We as members, contributors, and leaders pledge to make participation in our

6−community a harassment-free experience for everyone, regardless of age, body

7−size, visible or invisible disability, ethnicity, sex characteristics, gender

8−identity and expression, level of experience, education, socio-economic status,

9−nationality, personal appearance, race, caste, color, religion, or sexual

10−identity and orientation.

42+### CNCF Events

1143

12−We pledge to act and interact in ways that contribute to an open, welcoming,

13−diverse, inclusive, and healthy community.

44+CNCF events that are produced by the Linux Foundation with professional events staff are governed by the Linux Foundation [Events Code of Conduct](https://events.linuxfoundation.org/code-of-conduct/) available on the event page. This is designed to be used in conjunction with the CNCF Code of Conduct.

1445

1546## Our Standards

1647

17−Examples of behavior that contributes to a positive environment for our

18−community include:

48+The CNCF Community is open, inclusive and respectful. Every member of our community has the right to have their identity respected.

49+

50+Examples of behavior that contributes to a positive environment include but are not limited to:

1951

2052* Demonstrating empathy and kindness toward other people

2153* Being respectful of differing opinions, viewpoints, and experiences

2254* Giving and gracefully accepting constructive feedback

2355* Accepting responsibility and apologizing to those affected by our mistakes,

2456 and learning from the experience

25−* Focusing on what is best not just for us as individuals, but for the overall

26− community

57+* Focusing on what is best not just for us as individuals, but for the

58+ overall community

59+* Using welcoming and inclusive language

2760

28−Examples of unacceptable behavior include:

2961

30−* The use of sexualized language or imagery, and sexual attention or advances of

31− any kind

62+Examples of unacceptable behavior include but are not limited to:

63+

64+* The use of sexualized language or imagery

3265* Trolling, insulting or derogatory comments, and personal or political attacks

33−* Public or private harassment

34−* Publishing others' private information, such as a physical or email address,

35− without their explicit permission

66+* Public or private harassment in any form

67+* Publishing others' private information, such as a physical or email

68+ address, without their explicit permission

69+* Violence, threatening violence, or encouraging others to engage in violent behavior

70+* Stalking or following someone without their consent

71+* Unwelcome physical contact

72+* Unwelcome sexual or romantic attention or advances

73+* Using CNCF projects or community spaces for political campaigning or promotion of political causes

74+ that are unrelated to the advancement of cloud native technology. To clarify, this policy does not restrict individuals' personal attire, including attire that expresses personal beliefs or aspects of identity.

3675* Other conduct which could reasonably be considered inappropriate in a

3776 professional setting

3877

39−## Enforcement Responsibilities

40−

41−Community leaders are responsible for clarifying and enforcing our standards of

42−acceptable behavior and will take appropriate and fair corrective action in

43−response to any behavior that they deem inappropriate, threatening, offensive,

44−or harmful.

45−

46−Community leaders have the right and responsibility to remove, edit, or reject

47−comments, commits, code, wiki edits, issues, and other contributions that are

48−not aligned to this Code of Conduct, and will communicate reasons for moderation

49−decisions when appropriate.

50−

51−## Scope

52−

53−This Code of Conduct applies within all community spaces, and also applies when

54−an individual is officially representing the community in public spaces.

55−Examples of representing our community include using an official email address,

56−posting via an official social media account, or acting as an appointed

57−representative at an online or offline event.

58−

59−## Enforcement

78+The following behaviors are also prohibited:

79+* Providing knowingly false or misleading information in connection with a Code of Conduct investigation or otherwise intentionally tampering with an investigation.

80+* Retaliating against a person because they reported an incident or provided information about an incident as a witness.

6081

61−Instances of abusive, harassing, or otherwise unacceptable behavior may be

62−reported to the community leaders responsible for enforcement at

63−https://gophers.slack.com/messages/CM2RSS25N or directly contacting one of the

64−maintainers from the MAINTAINERS file.

65−All complaints will be reviewed and investigated promptly and fairly.

82+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct.

83+By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect

84+of managing a CNCF project.

85+Project maintainers who do not follow or enforce the Code of Conduct may be temporarily or permanently removed from the project team.

6686

67−All community leaders are obligated to respect the privacy and security of the

68−reporter of any incident.

87+## Reporting

6988

70−## Enforcement Guidelines

89+For incidents occurring in the Kubernetes community, contact the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via <conduct@kubernetes.io>. You can expect a response within three business days.

7190

72−Community leaders will follow these Community Impact Guidelines in determining

73−the consequences for any action they deem in violation of this Code of Conduct:

91+For other projects, or for incidents that are project-agnostic or impact multiple CNCF projects, please contact the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) via <conduct@cncf.io>. Alternatively, you can contact any of the individual members of the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) to submit your report. For more detailed instructions on how to submit a report, including how to submit a report anonymously, please see our [Incident Resolution Procedures](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-incident-resolution-procedures.md). You can expect a response within three business days.

7492

75−### 1. Correction

93+For incidents occurring at CNCF event that is produced by the Linux Foundation, please contact <eventconduct@cncf.io>.

7694

77−**Community Impact**: Use of inappropriate language or other behavior deemed

78−unprofessional or unwelcome in the community.

95+## Frequently asked questions

96+For more information about this Code of Conduct, please see the [CNCF Code of Conduct Frequently Asked Questions](https://www.cncf.io/conduct/faq/).

7997

80−**Consequence**: A private, written warning from community leaders, providing

81−clarity around the nature of the violation and an explanation of why the

82−behavior was inappropriate. A public apology may be requested.

83−

84−### 2. Warning

85−

86−**Community Impact**: A violation through a single incident or series of

87−actions.

88−

89−**Consequence**: A warning with consequences for continued behavior. No

90−interaction with the people involved, including unsolicited interaction with

91−those enforcing the Code of Conduct, for a specified period of time. This

92−includes avoiding interactions in community spaces as well as external channels

93−like social media. Violating these terms may lead to a temporary or permanent

94−ban.

95−

96−### 3. Temporary Ban

97−

98−**Community Impact**: A serious violation of community standards, including

99−sustained inappropriate behavior.

100−

101−**Consequence**: A temporary ban from any sort of interaction or public

102−communication with the community for a specified period of time. No public or

103−private interaction with the people involved, including unsolicited interaction

104−with those enforcing the Code of Conduct, is allowed during this period.

105−Violating these terms may lead to a permanent ban.

106−

107−### 4. Permanent Ban

108−

109−**Community Impact**: Demonstrating a pattern of violation of community

110−standards, including sustained inappropriate behavior, harassment of an

111−individual, or aggression toward or disparagement of classes of individuals.

112−

113−**Consequence**: A permanent ban from any sort of public interaction within the

114−community.

98+## Enforcement

11599

116−## Attribution

100+Upon review and investigation of a reported incident, the CoC response team that has jurisdiction will determine what action is appropriate based on this Code of Conduct and its related documentation.

117101

118−This Code of Conduct is adapted from the [Contributor Covenant][homepage],

119−version 2.1, available at

120−[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].

102+For information about which Code of Conduct incidents are handled by project leadership, which incidents are handled by the CNCF Code of Conduct Committee, and which incidents are handled by the Linux Foundation (including its events team), see our [Jurisdiction Policy](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-committee-jurisdiction-policy.md).

121103

122−Community Impact Guidelines were inspired by

123−[Mozilla's code of conduct enforcement ladder][Mozilla CoC].

104+## Amendments

124105

125−For answers to common questions about this code of conduct, see the FAQ at

126−[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at

127−[https://www.contributor-covenant.org/translations][translations].

106+Consistent with the CNCF Charter, any substantive changes to this Code of Conduct must be approved by the Technical Oversight Committee.

128107

129−[homepage]: https://www.contributor-covenant.org

130−[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html

131−[Mozilla CoC]: https://github.com/mozilla/diversity

132−[FAQ]: https://www.contributor-covenant.org/faq

133−[translations]: https://www.contributor-covenant.org/translations

108+## Acknowledgements

134109

110+This Code of Conduct is adapted from the Contributor Covenant

111+(http://contributor-covenant.org), version 2.0 available at

112+http://contributor-covenant.org/version/2/0/code_of_conduct/

DCO.mdnew file+34

@@ -0,0 +1,34 @@

1+Developer Certificate of Origin

2+Version 1.1

3+

4+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

5+

6+Everyone is permitted to copy and distribute verbatim copies of this

7+license document, but changing it is not allowed.

8+

9+

10+Developer's Certificate of Origin 1.1

11+

12+By making a contribution to this project, I certify that:

13+

14+(a) The contribution was created in whole or in part by me and I

15+ have the right to submit it under the open source license

16+ indicated in the file; or

17+

18+(b) The contribution is based upon previous work that, to the best

19+ of my knowledge, is covered under an appropriate open source

20+ license and I have the right under that license to submit that

21+ work with modifications, whether created in whole or in part

22+ by me, under the same open source license (unless I am

23+ permitted to submit under a different license), as indicated

24+ in the file; or

25+

26+(c) The contribution was provided directly to me by some other

27+ person who certified (a), (b) or (c) and I have not modified

28+ it.

29+

30+(d) I understand and agree that this project and the contribution

31+ are public and that a record of the contribution (including all

32+ personal information I submit with it, including my sign-off) is

33+ maintained indefinitely and may be redistributed consistent with

34+ this project or the open source license(s) involved.

MAINTAINERS+2−5

@@ -1,5 +1,2 @@

1−Joel Speed <joel@oauth2-proxy.dev> (@JoelSpeed)

2−Nick Meves <nick@oauth2-proxy.dev> (@NickMeves)

3−Braunson <braunson@oauth2-proxy.dev> (@braunsonm)

4−Jan Larwig <jan@oauth2-proxy.dev> (@tuunit)

5−Koen van Zuijlen <koen@oauth2-proxy.dev> (@kvanzuijlen)

1+

2+Moved to https://github.com/oauth2-proxy/oauth2-proxy/blob/master/MAINTAINERS.md

MAINTAINERS.mdnew file+33

@@ -0,0 +1,33 @@

1+# Maintainers

2+

3+The table below lists all current maintainers for the oauth2-proxy as defined

4+by our [project governance](GOVERNANCE.md).

5+

6+| Name | GitHub Handle | Domains of reponsibility | Email Alias | Affiliation |

7+| ---------------- | ------------------------------------------------------ | ------------------------ | -------------------------- | ----------- |

8+| Joel Speed | [@JoelSpeed](https://github.com/joelspeed) | Governance, Core | joel@oauth2-proxy.dev | Red Hat |

9+| Jan Larwig | [@tuunit](https://github.com/tuunit) | Governance, Core | jan@oauth2-proxy.dev | STACKIT |

10+| JJ Łakis | [@jjlakis](https://github.com/jjlakis) | Provider | jj@oauth2-proxy.dev | - |

11+| Koen van Zuijlen | [@kvanzuijlen](https://github.com/kvanzuijlen) | CI | koen@oauth2-proxy.dev | - |

12+| Pierluigi Lenoci | [@pierluigilenoci](https://github.com/pierluigilenoci) | Helm | pierluigi@oauth2-proxy.dev | SAP |

13+

14+## Emeritus Maintainers

15+

16+We would like to highlight that this project does have prior maintainers and

17+core contributors that, if they so wished, could (and should) be granted the

18+status of emeritus maintainers.

19+

20+| Name | GitHub Handle |

21+| ------------- | ------------------------------------------------------ |

22+| Nick Meves | [@NickMeves](https://github.com/NickMeves) |

23+| Braunson | [@braunsonm](https://github.com/braunsonm) |

24+| Henry Jenkins | [@steakunderscore](https://github.com/steakunderscore) |

25+

26+

27+## Security Response Team and GitHub Organization Owners

28+

29+The following maintainers are members of the security response team and owners

30+of the GitHub organization.

31+

32+- Joel Speed

33+- Jan Larwig

Makefile+21−21

@@ -25,7 +25,8 @@ help: ## Display this help

2525

2626

2727GO ?= go

28−GOLANGCILINT ?= golangci-lint

28+# renovate: datasource=github-tags depName=golangci/golangci-lint

29+GOLANGCILINT_VERSION ?= v2.11.4

2930

3031BINARY := oauth2-proxy

3132VERSION ?= $(shell git describe --always --dirty --tags 2>/dev/null || echo "undefined")

@@ -36,13 +37,12 @@ REPOSITORY ?= oauth2-proxy

3637DATE := $(shell date +"%Y%m%d")

3738.NOTPARALLEL:

3839

39−GO_MAJOR_VERSION = $(shell $(GO) version | cut -c 14- | cut -d' ' -f1 | cut -d'.' -f1)

40−GO_MINOR_VERSION = $(shell $(GO) version | cut -c 14- | cut -d' ' -f1 | cut -d'.' -f2)

40+# The go version in go.mod used for the Docker build toolchain, without the patch

41+GO_MOD_VERSION_MINOR := $(shell $(GO) list -f '{{printf "%.4s" .Module.GoVersion}}' )

4142

42−GO_MOD_VERSION = $(shell sed -En 's/^go ([[:digit:]]\.[[:digit:]]+)\.[[:digit:]]+/\1/p' go.mod)

43−MINIMUM_SUPPORTED_GO_MAJOR_VERSION = $(shell echo ${GO_MOD_VERSION} | cut -d' ' -f1 | cut -d'.' -f1)

44−MINIMUM_SUPPORTED_GO_MINOR_VERSION = $(shell echo ${GO_MOD_VERSION} | cut -d' ' -f1 | cut -d'.' -f2)

45−GO_VERSION_VALIDATION_ERR_MSG = Golang version is not supported, please update to at least $(MINIMUM_SUPPORTED_GO_MAJOR_VERSION).$(MINIMUM_SUPPORTED_GO_MINOR_VERSION)

43+# From go1.21 go will transparently download the toolchain declared in go.mod. https://go.dev/doc/toolchain

44+# We don't need to keep this message updated: the important info is in go.mod.

45+GO_VERSION_VALIDATION_ERR_MSG = Golang version is not supported, please update to at least go1.21

4646

4747ifeq ($(COVER),true)

4848TESTCOVER ?= -coverprofile c.out

@@ -56,7 +56,7 @@ build: validate-go-version clean $(BINARY) ## Build and create oauth2-proxy bina

5656$(BINARY):

5757 CGO_ENABLED=0 $(GO) build -a -installsuffix cgo -ldflags="-X github.com/oauth2-proxy/oauth2-proxy/v7/pkg/version.VERSION=${VERSION}" -o $@ github.com/oauth2-proxy/oauth2-proxy/v7

5858

59−DOCKER_BUILDX_COMMON_ARGS ?= --build-arg BUILD_IMAGE=docker.io/library/golang:${GO_MOD_VERSION}-bookworm --build-arg VERSION=${VERSION}

59+DOCKER_BUILDX_COMMON_ARGS ?= --build-arg BUILD_IMAGE=docker.io/library/golang:$(GO_MOD_VERSION_MINOR)-bookworm --build-arg VERSION=$(VERSION)

6060

6161DOCKER_BUILD_PLATFORM ?= linux/amd64,linux/arm64,linux/ppc64le,linux/arm/v7,linux/s390x

6262DOCKER_BUILD_RUNTIME_IMAGE ?= gcr.io/distroless/static:nonroot

@@ -67,7 +67,7 @@ DOCKER_BUILDX_PUSH := $(DOCKER_BUILDX) --push

6767DOCKER_BUILDX_PUSH_X_PLATFORM := $(DOCKER_BUILDX_PUSH) --platform ${DOCKER_BUILD_PLATFORM}

6868

6969DOCKER_BUILD_PLATFORM_ALPINE ?= linux/amd64,linux/arm64,linux/ppc64le,linux/arm/v6,linux/arm/v7,linux/s390x

70−DOCKER_BUILD_RUNTIME_IMAGE_ALPINE ?= alpine:3.22.1

70+DOCKER_BUILD_RUNTIME_IMAGE_ALPINE ?= alpine:3.24.1

7171DOCKER_BUILDX_ARGS_ALPINE ?= --build-arg RUNTIME_IMAGE=${DOCKER_BUILD_RUNTIME_IMAGE_ALPINE} ${DOCKER_BUILDX_COMMON_ARGS}

7272DOCKER_BUILDX_X_PLATFORM_ALPINE := docker buildx build ${DOCKER_BUILDX_ARGS_ALPINE} --platform ${DOCKER_BUILD_PLATFORM_ALPINE}

7373DOCKER_BUILDX_PUSH_X_PLATFORM_ALPINE := $(DOCKER_BUILDX_X_PLATFORM_ALPINE) --push

@@ -75,6 +75,10 @@ DOCKER_BUILDX_PUSH_X_PLATFORM_ALPINE := $(DOCKER_BUILDX_X_PLATFORM_ALPINE) --pus

7575.PHONY: build-docker

7676build-docker: build-distroless build-alpine ## Build multi architecture docker images in both flavours (distroless / alpine)

7777

78+.PHONY: build-docker-local

79+build-docker-local: ## Build distroless docker image and locally load into docker images

80+ $(DOCKER_BUILDX) --load -t $(REGISTRY)/$(REPOSITORY):${VERSION}-local .

81+

7882.PHONY: build-distroless

7983build-distroless: ## Build multi architecture distroless based docker image

8084 $(DOCKER_BUILDX_X_PLATFORM) -t $(REGISTRY)/$(REPOSITORY):latest -t $(REGISTRY)/$(REPOSITORY):${VERSION} .

@@ -140,11 +144,11 @@ verify-generate: generate ## Verify command to check if alpha config docs are in

140144##@ Miscellaneous

141145

142146.PHONY: test

143−test: lint ## Run all Go tests

147+test: ## Run all Go tests

144148 GO111MODULE=on $(GO) test $(TESTCOVER) -v -race ./...

145149

146150.PHONY: release

147−release: validate-go-version lint test ## Create a full release for all architectures (binaries and checksums)

151+release: validate-go-version ## Create a full release for all architectures (binaries and checksums)

148152 BINARY=${BINARY} VERSION=${VERSION} ./dist.sh

149153

150154.PHONY: clean

@@ -154,19 +158,15 @@ clean: ## Cleanup release and build files

154158

155159.PHONY: lint

156160lint: validate-go-version ## Lint all files using golangci-lint

157− GO111MODULE=on $(GOLANGCILINT) run

161+ GO111MODULE=on $(GO) run github.com/golangci/golangci-lint/v2/cmd/golangci-lint@$(GOLANGCILINT_VERSION) run --timeout 10m

162+

163+.PHONY: lint-fix

164+lint-fix: validate-go-version ## Lint all files and apply fixes using golangci-lint

165+ GO111MODULE=on $(GO) run github.com/golangci/golangci-lint/v2/cmd/golangci-lint@$(GOLANGCILINT_VERSION) run --timeout 10m --fix

158166

159167.PHONY: validate-go-version

160168validate-go-version: ## Validate Go environment requirements

161− @if [ $(GO_MAJOR_VERSION) -gt $(MINIMUM_SUPPORTED_GO_MAJOR_VERSION) ]; then \

162− exit 0 ;\

163− elif [ $(GO_MAJOR_VERSION) -lt $(MINIMUM_SUPPORTED_GO_MAJOR_VERSION) ]; then \

164− echo '$(GO_VERSION_VALIDATION_ERR_MSG)';\

165− exit 1; \

166− elif [ $(GO_MINOR_VERSION) -lt $(MINIMUM_SUPPORTED_GO_MINOR_VERSION) ] ; then \

167− echo '$(GO_VERSION_VALIDATION_ERR_MSG)';\

168− exit 1; \

169− fi

169+ @$(GO) list . >/dev/null || { echo '$(GO_VERSION_VALIDATION_ERR_MSG)'; exit 1; }

170170

171171# local-env can be used to interact with the local development environment

172172# eg:

README.md+38−19

@@ -1,26 +1,29 @@

11[](https://github.com/oauth2-proxy/oauth2-proxy/actions/workflows/ci.yml)

2−[](https://goreportcard.com/report/github.com/oauth2-proxy/oauth2-proxy)

3−[](https://godoc.org/github.com/oauth2-proxy/oauth2-proxy)

2+[](https://goreportcard.com/report/github.com/oauth2-proxy/oauth2-proxy/v7)

3+[](https://godoc.org/github.com/oauth2-proxy/oauth2-proxy/v7)

44[](./LICENSE)

5−[](https://codeclimate.com/github/oauth2-proxy/oauth2-proxy/maintainability)

6−[](https://codeclimate.com/github/oauth2-proxy/oauth2-proxy/test_coverage)

5+[](https://qlty.sh/gh/oauth2-proxy/projects/oauth2-proxy)

6+[](https://qlty.sh/gh/oauth2-proxy/projects/oauth2-proxy)

7+[](https://scorecard.dev/viewer/?uri=github.com/oauth2-proxy/oauth2-proxy)

8+[](https://www.bestpractices.dev/projects/11223)

9+[](https://app.fossa.com/projects/git%2Bgithub.com%2Foauth2-proxy%2Foauth2-proxy?ref=badge_shield)

710

811

912

10−OAuth2-Proxy is a flexible, open-source tool that can act as either a standalone reverse proxy or a middleware component integrated into existing reverse proxy or load balancer setups. It provides a simple and secure way to protect your web applications with OAuth2 / OIDC authentication. As a reverse proxy, it intercepts requests to your application and redirects users to an OAuth2 provider for authentication. As a middleware, it can be seamlessly integrated into your existing infrastructure to handle authentication for multiple applications.

13+OAuth2 Proxy is a flexible, open-source tool that can act as either a standalone reverse proxy or a middleware component integrated into existing reverse proxy or load balancer setups. It provides a simple and secure way to protect your web applications with OAuth2 / OIDC authentication. As a reverse proxy, it intercepts requests to your application and redirects users to an OAuth2 provider for authentication. As a middleware, it can be seamlessly integrated into your existing infrastructure to handle authentication for multiple applications.

1114

12−OAuth2-Proxy supports a lot of OAuth2 as well as OIDC providers. Either through a generic OIDC client or a specific implementation for Google, Microsoft Entra ID, GitHub, login.gov and others. Through specialised provider implementations oauth2-proxy can extract more details about the user like preferred usernames and groups. Those details can then be forwarded as HTTP headers to your upstream applications.

15+OAuth2 Proxy supports a lot of OAuth2 as well as OIDC providers. Either through a generic OIDC client or a specific implementation for Google, Microsoft Entra ID, GitHub, login.gov and others. Through specialised provider implementations OAuth2 Proxy can extract more details about the user like preferred usernames and groups. Those details can then be forwarded as HTTP headers to your upstream applications.

1316

1417

1518

1619## Get Started

1720

18−OAuth2-Proxy's [Installation Docs](https://oauth2-proxy.github.io/oauth2-proxy/installation) cover how to install and configure your setup. Additionally you can take a further look at the [example setup files](https://github.com/oauth2-proxy/oauth2-proxy/tree/master/contrib/local-environment).

21+OAuth2 Proxy's [Installation Docs](https://oauth2-proxy.github.io/oauth2-proxy/installation) cover how to install and configure your setup. Additionally you can take a further look at the [example setup files](https://github.com/oauth2-proxy/oauth2-proxy/tree/master/contrib/local-environment).

1922

2023## Releases

2124

2225### Binaries

23−We publish oauth2-proxy as compiled binaries on GitHub for all major architectures as well as more exotic ones like `ppc64le` as well as `s390x`.

26+We publish OAuth2 Proxy as compiled binaries on GitHub for all major architectures as well as more exotic ones like `ppc64le` as well as `s390x`.

2427

2528Check out the [latest release](https://github.com/oauth2-proxy/oauth2-proxy/releases/latest).

2629

@@ -34,24 +37,26 @@ Since 2023-11-18 we build nightly images directly from the `master` branch and p

3437These images are considered unstable and therefore should **NOT** be used for production purposes unless you know what you're doing.

3538

3639## Sponsors

40+Would you like to sponsor the project then please contact us at [sponsors@oauth2-proxy.dev](mailto:sponsors@oauth2-proxy.dev)

3741

38−

39−Microsoft Azure credits for open source projects

42+

4043

41−Would you like to sponsor the project then please contact us at [sponsors@oauth2-proxy.dev](mailto:sponsors@oauth2-proxy.dev)

44+SAP Open Source Program

45+

46+## Former Sponsors

47+

48+

49+Microsoft Azure credits for open source projects

4250

4351## Getting Involved

44−[](https://gophers.slack.com/archives/CM2RSS25N)

52+[](https://cloud-native.slack.com/archives/C098Y5URZ2N)

4553

46−Join the #oauth2-proxy [Slack channel](https://gophers.slack.com/archives/CM2RSS25N) to chat with other users of oauth2-proxy or reach out to the maintainers directly. Use the [public invite link](https://invite.slack.golangbridge.org/) to get an invite for the Gopher Slack space.

54+Join the #oauth2-proxy [Slack channel](https://cloud-native.slack.com/archives/C098Y5URZ2N) to chat with other users of OAuth2 Proxy or reach out to the maintainers directly. Use the [public invite link](https://slack.cncf.io/) to get an invite for the CNCF space.

4755

48−OAuth2-Proxy is a community-driven project. We rely on the contribut️ions of our users to continually improve it. While review times can vary, we appreciate your patience and understanding. As a volunteer-driven project, we strive to keep this project stable and might take longer to merge changes.

56+OAuth2 Proxy is a community-driven project. We rely on the contribut️ions of our users to continually improve it. While review times can vary, we appreciate your patience and understanding. As a volunteer-driven project, we strive to keep this project stable and might take longer to merge changes.

4957

5058If you want to contribute to the project. Please see our [Contributing](https://oauth2-proxy.github.io/oauth2-proxy/community/contribution) guide.

5159

52−Who uses OAuth2-Proxy? Have a look at our new [ADOPTERS](ADOPTERS.md) file and

53−feel free to open a PR to add your organisation.

54−

5560Thanks to all the people who already contributed ❤

5661

5762<a href="https://github.com/oauth2-proxy/oauth2-proxy/graphs/contributors">

@@ -65,7 +70,7 @@ Made with [contrib.rocks](https://contrib.rocks).

6570

6671If you believe you have found a vulnerability within OAuth2 Proxy or any of its dependencies, please do **NOT** open an issue or PR on GitHub, please do **NOT** post any details publicly.

6772

68−Security disclosures **MUST** be done in private. If you have found an issue that you would like to bring to the attention of the maintainers, please compose an email and send it to the list of people listed in our [MAINTAINERS](MAINTAINERS) file.

73+Security disclosures **MUST** be done in private. If you have found an issue that you would like to bring to the attention of the maintainers, please compose an email and send it to the list of people listed in our [MAINTAINERS.md](MAINTAINERS.md) file.

6974

7075For more details read our full [Security Docs](https://oauth2-proxy.github.io/oauth2-proxy/community/security#security-disclosures)

7176

@@ -81,6 +86,20 @@ See [open redirect vulnerability](https://github.com/oauth2-proxy/oauth2-proxy/s

8186

8287**2020-03-29:** This project was formerly hosted as `pusher/oauth2_proxy` but has been renamed to `oauth2-proxy/oauth2-proxy`. Going forward, all images shall be available at `quay.io/oauth2-proxy/oauth2-proxy` and binaries will be named `oauth2-proxy`.

8388

89+## Code of Conduct

90+Participation in the OAuth2 Proxy project is governed by the [CNCF Code of Conduct](CODE_OF_CONDUCT.md).

91+

8492## License

8593

86−OAuth2-Proxy is distributed under [The MIT License](LICENSE).

94+OAuth2 Proxy is distributed under [The MIT License](LICENSE).

95+

96+

97+[](https://app.fossa.com/projects/git%2Bgithub.com%2Foauth2-proxy%2Foauth2-proxy?ref=badge_large)

98+

99+## Trademarks

100+

101+OAuth2 Proxy is a [Cloud Native Computing Foundation](https://cncf.io) Sandbox project.

102+

103+

104+

105+The Linux Foundation® (TLF) has registered trademarks and uses trademarks. For a list of TLF trademarks, see [Trademark Usage](https://www.linuxfoundation.org/legal/trademark-usage).

contrib/local-environment/Makefile+2−2

@@ -49,8 +49,8 @@ kubernetes-down:

4949

5050.PHONY: traefik-up

5151traefik-up:

52− docker compose -f docker-compose.yaml -f docker-compose-traefik.yaml up -d

52+ docker compose -f docker-compose-traefik.yaml up -d

5353

5454.PHONY: traefik-%

5555traefik-%:

56− docker compose -f docker-compose.yaml -f docker-compose-traefik.yaml $*

56+ docker compose -f docker-compose-traefik.yaml $*

contrib/local-environment/dex-traefik.yamlnew file+25

@@ -0,0 +1,25 @@

1+# This configuration is intended to be used with the Traefik local environment.

2+# Dex uses in-memory storage because this environment is disposable.

3+issuer: http://dex.localtest.me/dex

4+storage:

5+ type: memory

6+web:

7+ http: 0.0.0.0:5556

8+oauth2:

9+ skipApprovalScreen: true

10+expiry:

11+ signingKeys: "4h"

12+ idTokens: "1h"

13+staticClients:

14+ - id: oauth2-proxy

15+ redirectURIs:

16+ - "http://oauth2-proxy.localtest.me/oauth2/callback"

17+ name: "OAuth2 Proxy"

18+ secret: b2F1dGgyLXByb3h5LWNsaWVudC1zZWNyZXQK

19+enablePasswordDB: true

20+staticPasswords:

21+ - email: "admin@example.com"

22+ # bcrypt hash of the string "password"

23+ hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"

24+ username: "admin"

25+ userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"

contrib/local-environment/dex.yaml+13−17

@@ -3,11 +3,7 @@

33# This should configure Dex to run on port 5556 and provides a static login

44issuer: http://dex.localtest.me:5556/dex

55storage:

6− type: etcd

7− config:

8− endpoints:

9− - http://etcd:2379

10− namespace: dex/

6+ type: memory

117web:

128 http: 0.0.0.0:5556

139oauth2:

@@ -16,17 +12,17 @@ expiry:

1612 signingKeys: "4h"

1713 idTokens: "1h"

1814staticClients:

19−- id: oauth2-proxy

20− redirectURIs:

21− # These redirect URIs point to the `--redirect-url` for OAuth2 proxy.

22− - 'http://oauth2-proxy.localtest.me:4180/oauth2/callback' # For basic proxy example.

23− - 'http://oauth2-proxy.oauth2-proxy.localhost/oauth2/callback' # For nginx and traefik example.

24− name: 'OAuth2 Proxy'

25− secret: b2F1dGgyLXByb3h5LWNsaWVudC1zZWNyZXQK

15+ - id: oauth2-proxy

16+ redirectURIs:

17+ # These redirect URIs point to the `--redirect-url` for OAuth2 proxy.

18+ - "http://oauth2-proxy.localtest.me:4180/oauth2/callback" # For basic proxy example.

19+ - "http://oauth2-proxy.localtest.me:8080/oauth2/callback" # For nginx example.

20+ name: "OAuth2 Proxy"

21+ secret: b2F1dGgyLXByb3h5LWNsaWVudC1zZWNyZXQK

2622enablePasswordDB: true

2723staticPasswords:

28−- email: "admin@example.com"

29− # bcrypt hash of the string "password"

30− hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"

31− username: "admin"

32− userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"

24+ - email: "admin@example.com"

25+ # bcrypt hash of the string "password"

26+ hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"

27+ username: "admin"

28+ userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"

contrib/local-environment/docker-compose-alpha-config.yaml+37−3

@@ -1,7 +1,7 @@

11# This docker-compose file can be used to bring up an example instance of oauth2-proxy

22# for manual testing and exploration of features.

33# Alongside OAuth2-Proxy, this file also starts Dex to act as the identity provider,

4−# etcd for storage for Dex and HTTPBin as an example upstream.

4+# HTTPBin as an example upstream.

55# This file also uses alpha configuration when configuring OAuth2 Proxy.

66#

77# This file is an extension of the main compose file and must be used with it

@@ -10,11 +10,45 @@

1010# make alpha-config-<command> (eg make nginx-up, make nginx-down)

1111#

1212# Access http://localhost:4180 to initiate a login cycle

13−version: '3.0'

13+version: "3.0"

1414services:

1515 oauth2-proxy:

16− image: quay.io/oauth2-proxy/oauth2-proxy:v7.11.0

16+ container_name: oauth2-proxy

17+ image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.4

1718 command: --config /oauth2-proxy.cfg --alpha-config /oauth2-proxy-alpha-config.yaml

19+ hostname: oauth2-proxy

1820 volumes:

1921 - "./oauth2-proxy-alpha-config.cfg:/oauth2-proxy.cfg"

2022 - "./oauth2-proxy-alpha-config.yaml:/oauth2-proxy-alpha-config.yaml"

23+ restart: unless-stopped

24+ ports:

25+ - 4180:4180/tcp

26+ networks:

27+ dex: {}

28+ httpbin: {}

29+ depends_on:

30+ - dex

31+ - httpbin

32+ dex:

33+ container_name: dex

34+ image: ghcr.io/dexidp/dex:v2.45.1

35+ command: dex serve /dex.yaml

36+ hostname: dex

37+ volumes:

38+ - "./dex.yaml:/dex.yaml"

39+ restart: unless-stopped

40+ ports:

41+ - 5556:5556/tcp

42+ networks:

43+ dex:

44+ aliases:

45+ - dex.localtest.me

46+ httpbin:

47+ container_name: httpbin

48+ image: kennethreitz/httpbin

49+ ports: []

50+ networks:

51+ httpbin: {}

52+networks:

53+ dex: {}

54+ httpbin: {}

contrib/local-environment/docker-compose-gitea.yaml+2−2

@@ -14,7 +14,7 @@ version: '3.0'

1414services:

1515 oauth2-proxy:

1616 container_name: oauth2-proxy

17− image: quay.io/oauth2-proxy/oauth2-proxy:v7.11.0

17+ image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.4

1818 command: --config /oauth2-proxy.cfg

1919 hostname: oauth2-proxy

2020 volumes:

@@ -39,7 +39,7 @@ services:

3939 httpbin: {}

4040

4141 gitea:

42− image: gitea/gitea:1.24.5

42+ image: gitea/gitea:1.27.2

4343 container_name: gitea

4444 environment:

4545 - USER_UID=1000

contrib/local-environment/docker-compose-keycloak.yaml+6−6

@@ -10,11 +10,11 @@

1010#

1111# Access http://oauth2-proxy.localtest.me:4180 to initiate a login cycle using user=admin@example.com, password=password

1212# Access http://keycloak.localtest.me:9080 with the same credentials to check out the settings

13−version: '3.0'

13+version: "3.0"

1414services:

1515 oauth2-proxy:

1616 container_name: oauth2-proxy

17− image: quay.io/oauth2-proxy/oauth2-proxy:v7.11.0

17+ image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.4

1818 command: --config /oauth2-proxy.cfg

1919 hostname: oauth2-proxy

2020 volumes:

@@ -40,12 +40,12 @@ services:

4040

4141 keycloak:

4242 container_name: keycloak

43− image: keycloak/keycloak:25.0

43+ image: keycloak/keycloak:26.7

4444 hostname: keycloak

4545 command:

46− - 'start-dev'

47− - '--http-port=9080'

48− - '--import-realm'

46+ - "start-dev"

47+ - "--http-port=9080"

48+ - "--import-realm"

4949 volumes:

5050 - ./keycloak:/opt/keycloak/data/import

5151 environment:

contrib/local-environment/docker-compose-nginx.yaml+9−33

@@ -1,38 +1,28 @@

11# This docker-compose file can be used to bring up an example instance of oauth2-proxy

22# for manual testing and exploration of features.

33# Alongside OAuth2-Proxy, this file also starts Dex to act as the identity provider,

4−# etcd for storage for Dex, nginx as a reverse proxy and other http services for upstreams

4+# nginx as a reverse proxy and other HTTP services for upstreams.

55#

66# This file is an extension of the main compose file and must be used with it

77# docker-compose -f docker-compose.yaml -f docker-compose-nginx.yaml <command>

88# Alternatively:

99# make nginx-<command> (eg make nginx-up, make nginx-down)

1010#

11−# Access one of the following URLs to initiate a login flow:

12−# - http://oauth2-proxy.localhost

13−# - http://httpbin.oauth2-proxy.localhost

14−#

15−# The OAuth2 Proxy itself is hosted at http://oauth2-proxy.oauth2-proxy.localhost

16−#

17−# Note, the above URLs should work with Chrome, but you may need to add hosts

18−# entries for other browsers

19−# 127.0.0.1 oauth2-proxy.localhost

20−# 127.0.0.1 httpbin.oauth2-proxy.localhost

21−# 127.0.0.1 oauth2-proxy.oauth2-proxy.localhost

22−version: '3.0'

11+# Access http://oauth2-proxy.localtest.me:8080 to initiate a login flow.

12+version: "3.0"

2313services:

2414 oauth2-proxy:

25− image: quay.io/oauth2-proxy/oauth2-proxy:v7.11.0

15+ image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.4

2616 ports: []

2717 hostname: oauth2-proxy

2818 container_name: oauth2-proxy

2919 command: --config /oauth2-proxy.cfg

20+ restart: unless-stopped

3021 volumes:

3122 - "./oauth2-proxy-nginx.cfg:/oauth2-proxy.cfg"

3223 networks:

3324 oauth2-proxy: {}

3425 dex: {}

35− etcd: {}

3626 httpbin: {}

3727 depends_on:

3828 - dex

@@ -41,52 +31,38 @@ services:

4131 depends_on:

4232 - oauth2-proxy

4333 container_name: nginx

44− image: nginx:1.29

34+ image: nginx:1.31

4535 restart: unless-stopped

4636 ports:

47− - 80:80/tcp

37+ - 8080:8080/tcp

4838 hostname: nginx

4939 volumes:

5040 - "./nginx.conf:/etc/nginx/conf.d/default.conf"

5141 networks:

5242 oauth2-proxy: {}

5343 dex: {}

54− etcd: {}

5544 httpbin: {}

5645 dex:

5746 container_name: dex

58− image: ghcr.io/dexidp/dex:v2.43.1

47+ image: ghcr.io/dexidp/dex:v2.45.1

5948 command: dex serve /dex.yaml

6049 hostname: dex

6150 volumes:

6251 - "./dex.yaml:/dex.yaml"

6352 restart: unless-stopped

6453 ports:

65− - 5556:4181/tcp

54+ - 5556:5556/tcp

6655 networks:

6756 dex:

6857 aliases:

6958 - dex.localtest.me

70− etcd: {}

71− depends_on:

72− - etcd

7359 httpbin:

7460 container_name: httpbin

7561 image: kennethreitz/httpbin

7662 ports: []

7763 networks:

7864 httpbin: {}

79− etcd:

80− container_name: etcd

81− image: gcr.io/etcd-development/etcd:v3.6.4

82− entrypoint: /usr/local/bin/etcd

83− command:

84− - --listen-client-urls=http://0.0.0.0:2379

85− - --advertise-client-urls=http://etcd:2379

86− networks:

87− etcd: {}

8865networks:

8966 dex: {}

90− etcd: {}

9167 httpbin: {}

9268 oauth2-proxy: {}

contrib/local-environment/docker-compose-traefik.yaml+42−18

@@ -1,7 +1,7 @@

11# This docker-compose file can be used to bring up an example instance of oauth2-proxy

22# for manual testing and exploration of features.

3−# Alongside OAuth2-Proxy, this file also starts Dex to act as the identity provider,

4−# HTTPBin as an example upstream.

3+# Alongside OAuth2-Proxy, this file also starts Dex to act as the identity provider

4+# and HTTPBin as an example upstream.

55#

66# This can either be created using docker-compose

77# docker-compose -f docker-compose-traefik.yaml <command>

@@ -9,32 +9,51 @@

99# make traefik-<command> (eg. make traefik-up, make traefik-down)

1010#

1111# Access one of the following URLs to initiate a login flow:

12−# - http://oauth2-proxy.localhost

13−# - http://httpbin.oauth2-proxy.localhost

12+# - http://oauth2-proxy.localtest.me

13+# - http://httpbin.localtest.me

14+# - http://dex.localtest.me/dex

1415#

15−# The OAuth2 Proxy itself is hosted at http://oauth2-proxy.oauth2-proxy.localhost

16−#

17−# Note, the above URLs should work with Chrome, but you may need to add hosts

18−# entries for other browsers

19−# 127.0.0.1 oauth2-proxy.localhost

20−# 127.0.0.1 httpbin.oauth2-proxy.localhost

21−# 127.0.0.1 oauth2-proxy.oauth2-proxy.localhost

22−version: '3.0'

16+# The OAuth2 Proxy itself is hosted at http://oauth2-proxy.localtest.me

2317services:

2418

2519 oauth2-proxy:

26− image: quay.io/oauth2-proxy/oauth2-proxy:v7.11.0

20+ container_name: oauth2-proxy

21+ image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.4

22+ command: --config /oauth2-proxy.cfg

2723 ports: []

2824 hostname: oauth2-proxy

2925 volumes:

3026 - "./oauth2-proxy-traefik.cfg:/oauth2-proxy.cfg"

27+ restart: unless-stopped

28+ networks:

29+ oauth2-proxy: {}

30+ dex: {}

31+ depends_on:

32+ - dex

33+ - httpbin

34+

35+ dex:

36+ container_name: dex

37+ image: ghcr.io/dexidp/dex:v2.45.1

38+ command: dex serve /dex.yaml

39+ hostname: dex

40+ volumes:

41+ - "./dex-traefik.yaml:/dex.yaml"

42+ restart: unless-stopped

3143 networks:

32− oauth2-proxy:

44+ dex: {}

45+

46+ httpbin:

47+ container_name: httpbin

48+ image: kennethreitz/httpbin

49+ ports: []

50+ networks:

51+ httpbin: {}

3352

3453 # Reverse proxy

3554 gateway:

3655 container_name: traefik

37− image: traefik:v2.11.28

56+ image: traefik:v3.7.10

3857 volumes:

3958 - "./traefik:/etc/traefik"

4059 ports:

@@ -43,8 +62,13 @@ services:

4362 depends_on:

4463 - oauth2-proxy

4564 networks:

46− oauth2-proxy:

47− httpbin:

65+ oauth2-proxy: {}

66+ httpbin: {}

67+ dex:

68+ aliases:

69+ - dex.localtest.me

4870

4971networks:

50− oauth2-proxy:

72+ dex: {}

73+ httpbin: {}

74+ oauth2-proxy: {}

contrib/local-environment/docker-compose.yaml+4−17

@@ -1,7 +1,7 @@

11# This docker-compose file can be used to bring up an example instance of oauth2-proxy

22# for manual testing and exploration of features.

33# Alongside OAuth2-Proxy, this file also starts Dex to act as the identity provider,

4−# etcd for storage for Dex and HTTPBin as an example upstream.

4+# HTTPBin as an example upstream.

55#

66# This can either be created using docker-compose

77# docker-compose -f docker-compose.yaml <command>

@@ -9,11 +9,11 @@

99# make <command> (eg. make up, make down)

1010#

1111# Access http://oauth2-proxy.localtest.me:4180 to initiate a login cycle

12−version: '3.0'

12+version: "3.0"

1313services:

1414 oauth2-proxy:

1515 container_name: oauth2-proxy

16− image: quay.io/oauth2-proxy/oauth2-proxy:v7.11.0

16+ image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.4

1717 command: --config /oauth2-proxy.cfg

1818 hostname: oauth2-proxy

1919 volumes:

@@ -29,7 +29,7 @@ services:

2929 - httpbin

3030 dex:

3131 container_name: dex

32− image: ghcr.io/dexidp/dex:v2.43.1

32+ image: ghcr.io/dexidp/dex:v2.45.1

3333 command: dex serve /dex.yaml

3434 hostname: dex

3535 volumes:

@@ -41,25 +41,12 @@ services:

4141 dex:

4242 aliases:

4343 - dex.localtest.me

44− etcd: {}

45− depends_on:

46− - etcd

4744 httpbin:

4845 container_name: httpbin

4946 image: kennethreitz/httpbin

5047 ports: []

5148 networks:

5249 httpbin: {}

53− etcd:

54− container_name: etcd

55− image: gcr.io/etcd-development/etcd:v3.6.4

56− entrypoint: /usr/local/bin/etcd

57− command:

58− - --listen-client-urls=http://0.0.0.0:2379

59− - --advertise-client-urls=http://etcd:2379

60− networks:

61− etcd: {}

6250networks:

6351 dex: {}

64− etcd: {}

6552 httpbin: {}

contrib/local-environment/kubernetes/Chart.lock+4−4

@@ -1,15 +1,15 @@

11dependencies:

22- name: dex

33 repository: https://charts.dexidp.io

4− version: 0.23.0

4+ version: 0.24.1

55- name: oauth2-proxy

66 repository: https://oauth2-proxy.github.io/manifests

7− version: 7.14.1

7+ version: 7.18.0

88- name: httpbin

99 repository: https://conservis.github.io/helm-charts

1010 version: 1.1.0

1111- name: hello-world

1212 repository: https://conservis.github.io/helm-charts

1313 version: 1.1.0

14−digest: sha256:9b18e072db6863053c2967d023929ab4b9c03b6bd84f6529d90fe7a9ec5e315f

15−generated: "2025-07-20T08:56:43.559585022Z"

14+digest: sha256:3fff8bf99cebcd20a73c984423d5f1c2dfa1e5a394f82a5dc60d9aaffe5361b7

15+generated: "2026-08-18T07:33:03.791274914Z"

contrib/local-environment/kubernetes/Chart.yaml+2−2

@@ -3,10 +3,10 @@ description: K8S example based on https://kind.sigs.k8s.io

33name: kubernetes

44dependencies:

55 - name: dex

6− version: 0.23.0

6+ version: 0.24.1

77 repository: https://charts.dexidp.io

88 - name: oauth2-proxy

9− version: &chartVersion 7.14.1

9+ version: &chartVersion 7.18.0

1010 repository: https://oauth2-proxy.github.io/manifests

1111 # https://github.com/postmanlabs/httpbin/issues/549 is still in progress, for now using a non-official chart

1212 - name: httpbin

contrib/local-environment/nginx.conf+31−73

@@ -1,86 +1,44 @@

1−# Reverse proxy to oauth2-proxy

2−server {

3− listen 80;

4− server_name oauth2-proxy.oauth2-proxy.localhost;

5−

6− location / {

7− proxy_set_header Host $host;

8− proxy_set_header X-Real-IP $remote_addr;

9−

10− proxy_pass http://oauth2-proxy:4180/;

11− }

12−}

13−

141# Reverse proxy to httpbin

152server {

16− listen 80;

17− server_name httpbin.oauth2-proxy.localhost;

18−

19− auth_request /internal-auth/oauth2/auth;

20−

21− # If the auth_request denies the request (401), redirect to the sign_in page

22− # and include the final rd URL back to the user's original request.

23− error_page 401 =403 http://oauth2-proxy.oauth2-proxy.localhost/oauth2/sign_in?rd=$scheme://$host$request_uri;

24−

25− # Alternatively send the request to `start` to skip the provider button

26− # error_page 401 = http://oauth2-proxy.oauth2-proxy.localhost/oauth2/start?rd=$scheme://$host$request_uri;

27−

28− location / {

29− proxy_pass http://httpbin/;

3+ listen 8080;

4+ server_name oauth2-proxy.localtest.me;

5+

6+ location /oauth2/ {

7+ proxy_pass http://oauth2-proxy:4180;

8+ proxy_set_header Host $host;

9+ proxy_set_header X-Real-IP $remote_addr;

10+ proxy_set_header X-Forwarded-Uri $request_uri;

11+ proxy_set_header X-Auth-Request-Redirect $request_uri;

3012 }

3113

32− # auth_request must be a URI so this allows an internal path to then proxy to

33− # the real auth_request path.

34− # The trailing /'s are required so that nginx strips the prefix before proxying.

35− location /internal-auth/ {

36− internal; # Ensure external users can't access this path

37−

38− # Make sure the OAuth2 Proxy knows where the original request came from.

39− proxy_set_header Host $host;

40− proxy_set_header X-Real-IP $remote_addr;

41− proxy_set_header X-Forwarded-Uri $request_uri;

42−

43− proxy_pass http://oauth2-proxy:4180/;

14+ location = /oauth2/auth {

15+ proxy_pass http://oauth2-proxy:4180;

16+ proxy_set_header Host $host;

17+ proxy_set_header X-Real-IP $remote_addr;

18+ proxy_set_header X-Forwarded-Uri $request_uri;

19+ # nginx auth_request includes headers but not body

20+ proxy_set_header Content-Length "";

21+ proxy_pass_request_body off;

4422 }

45−}

46−

47−# Statically serve the nginx welcome

48−server {

49− listen 80;

50− server_name oauth2-proxy.localhost;

5123

5224 location / {

53− auth_request /internal-auth/oauth2/auth;

54−

55− # If the auth_request denies the request (401), redirect to the sign_in page

56− # and include the final rd URL back to the user's original request.

57− error_page 401 =403 http://oauth2-proxy.oauth2-proxy.localhost/oauth2/sign_in?rd=$scheme://$host$request_uri;

25+ auth_request /oauth2/auth;

26+ error_page 401 = @oauth2_signin;

5827

59− # Alternatively send the request to `start` to skip the provider button

60− # error_page 401 = http://oauth2-proxy.oauth2-proxy.localhost/oauth2/start?rd=$scheme://$host$request_uri;

28+ # pass information via X-User and X-Email headers to backend,

29+ # requires running with --set-xauthrequest flag

30+ auth_request_set $user $upstream_http_x_auth_request_user;

31+ auth_request_set $email $upstream_http_x_auth_request_email;

32+ proxy_set_header X-User $user;

33+ proxy_set_header X-Email $email;

6134

62−

63− root /usr/share/nginx/html;

64− index index.html index.htm;

65− }

66−

67− # redirect server error pages to the static page /50x.html

68− error_page 500 502 503 504 /50x.html;

69− location = /50x.html {

70− root /usr/share/nginx/html;

35+ proxy_pass http://httpbin/;

36+ # or "root /path/to/site;" or "fastcgi_pass ..." etc

7137 }

7238

73− # auth_request must be a URI so this allows an internal path to then proxy to

74− # the real auth_request path.

75− # The trailing /'s are required so that nginx strips the prefix before proxying.

76− location /internal-auth/ {

77− internal; # Ensure external users can't access this path

78−

79− # Make sure the OAuth2 Proxy knows where the original request came from.

80− proxy_set_header Host $host;

81− proxy_set_header X-Real-IP $remote_addr;

82− proxy_set_header X-Forwarded-Uri $request_uri;

83−

84− proxy_pass http://oauth2-proxy:4180/;

39+ # Named location for handling OAuth2 sign-in redirects

40+ # This ensures the browser receives a proper 302 redirect that it will follow

41+ location @oauth2_signin {

42+ return 302 /oauth2/sign_in?rd=$scheme://$http_host$request_uri;

8543 }

8644}

contrib/local-environment/oauth2-proxy-alpha-config.cfg+1−2

@@ -1,5 +1,4 @@

1−http_address="0.0.0.0:4180"

21cookie_secret="OQINaROshtE9TcZkNAm-5Zs2Pv3xaWytBmc5W7sPX7w="

32email_domains="example.com"

43cookie_secure="false"

5−redirect_url="http://localhost:4180/oauth2/callback"

4+redirect_url="http://oauth2-proxy.localtest.me:4180/oauth2/callback"

contrib/local-environment/oauth2-proxy-alpha-config.yaml+21−21

@@ -1,23 +1,23 @@

1−upstreams:

2− - id: httpbin

3− path: /

4− uri: http://httpbin

1+server:

2+ bindAddress: "0.0.0.0:4180"

3+upstreamConfig:

4+ upstreams:

5+ - id: httpbin

6+ path: /

7+ uri: http://httpbin

58injectRequestHeaders:

6−- name: X-Forwarded-Groups

7− values:

8− - claim: groups

9−- name: X-Forwarded-User

10− values:

11− - claim: user

12−- name: X-Forwarded-Email

13− values:

14− - claim: email

15−- name: X-Forwarded-Preferred-Username

16− values:

17− - claim: preferred_username

9+ - name: X-Forwarded-User

10+ values:

11+ - claimSource:

12+ claim: user

13+ - name: X-Forwarded-Email

14+ values:

15+ - claimSource:

16+ claim: email

1817providers:

19−- provider: oidc

20− clientSecret: b2F1dGgyLXByb3h5LWNsaWVudC1zZWNyZXQK

21− clientID: oauth2-proxy

22− oidcConfig:

23− issuerURL: http://dex.localhost:5556/dex

18+ - id: oidc

19+ provider: oidc

20+ clientSecret: b2F1dGgyLXByb3h5LWNsaWVudC1zZWNyZXQK

21+ clientID: oauth2-proxy

22+ oidcConfig:

23+ issuerURL: http://dex.localtest.me:5556/dex

contrib/local-environment/oauth2-proxy-nginx.cfg+11−6

@@ -1,14 +1,19 @@

11http_address="0.0.0.0:4180"

22cookie_secret="OQINaROshtE9TcZkNAm-5Zs2Pv3xaWytBmc5W7sPX7w="

3−provider="oidc"

43email_domains="example.com"

5−oidc_issuer_url="http://dex.localtest.me:5556/dex"

4+cookie_secure="false"

5+upstreams="static://200"

6+cookie_domains=[".localtest.me"] # Required so cookie can be read on all subdomains.

7+whitelist_domains=[".localtest.me"] # Required to allow redirection back to original requested target.

8+

9+# dex provider

610client_secret="b2F1dGgyLXByb3h5LWNsaWVudC1zZWNyZXQK"

711client_id="oauth2-proxy"

8−cookie_secure="false"

12+redirect_url="http://oauth2-proxy.localtest.me:8080/oauth2/callback"

13+

14+oidc_issuer_url="http://dex.localtest.me:5556/dex"

15+provider="oidc"

16+provider_display_name="Dex"

917

10−redirect_url="http://oauth2-proxy.oauth2-proxy.localhost/oauth2/callback"

11−cookie_domains=".oauth2-proxy.localhost" # Required so cookie can be read on all subdomains.

12−whitelist_domains=".oauth2-proxy.localhost" # Required to allow redirection back to original requested target.

1318# Enables the use of `X-Forwarded-*` headers to determine request correctly

1419reverse_proxy="true"

contrib/local-environment/oauth2-proxy-traefik.cfg+4−4

@@ -2,14 +2,14 @@ http_address="0.0.0.0:4180"

22cookie_secret="OQINaROshtE9TcZkNAm-5Zs2Pv3xaWytBmc5W7sPX7w="

33provider="oidc"

44email_domains=["example.com"]

5−oidc_issuer_url="http://dex.localhost:5556/dex"

5+oidc_issuer_url="http://dex.localtest.me/dex"

66client_secret="b2F1dGgyLXByb3h5LWNsaWVudC1zZWNyZXQK"

77client_id="oauth2-proxy"

88cookie_secure="false"

99

10−redirect_url="http://oauth2-proxy.oauth2-proxy.localhost/oauth2/callback"

11−cookie_domains=".oauth2-proxy.localhost" # Required so cookie can be read on all subdomains.

12−whitelist_domains=".oauth2-proxy.localhost" # Required to allow redirection back to original requested target.

10+redirect_url="http://oauth2-proxy.localtest.me/oauth2/callback"

11+cookie_domains=".localtest.me" # Required so cookie can be read on all subdomains.

12+whitelist_domains=".localtest.me" # Required to allow redirection back to original requested target.

1313

1414# Mandatory option when using oauth2-proxy with traefik

1515reverse_proxy="true"

contrib/local-environment/traefik/dynamic.yaml+11−4

@@ -1,22 +1,25 @@

11http:

22 routers:

33 oauth2-proxy-route:

4− rule: "Host(`oauth2-proxy.oauth2-proxy.localhost`)"

4+ rule: "Host(`oauth2-proxy.localtest.me`)"

55 middlewares:

66 - auth-headers

77 service: oauth-backend

8+ dex-route:

9+ rule: "Host(`dex.localtest.me`)"

10+ service: dex-service

811 httpbin-route:

9− rule: "Host(`httpbin.oauth2-proxy.localhost`)"

12+ rule: "Host(`httpbin.localtest.me`)"

1013 service: httpbin-service

1114 middlewares:

1215 - oauth-auth-redirect # redirects all unauthenticated to oauth2 signin

1316 httpbin-route-2:

14− rule: "Host(`httpbin.oauth2-proxy.localhost`) && PathPrefix(`/no-auto-redirect`)"

17+ rule: "Host(`httpbin.localtest.me`) && PathPrefix(`/no-auto-redirect`)"

1518 service: httpbin-service

1619 middlewares:

1720 - oauth-auth-wo-redirect # unauthenticated session will return a 401

1821 services-oauth2-route:

19− rule: "Host(`httpbin.oauth2-proxy.localhost`) && PathPrefix(`/oauth2/`)"

22+ rule: "Host(`httpbin.localtest.me`) && PathPrefix(`/oauth2/`)"

2023 middlewares:

2124 - auth-headers

2225 service: oauth-backend

@@ -30,6 +33,10 @@ http:

3033 loadBalancer:

3134 servers:

3235 - url: http://oauth2-proxy:4180

36+ dex-service:

37+ loadBalancer:

38+ servers:

39+ - url: http://dex:5556

3340

3441 middlewares:

3542 auth-headers:

contrib/local-environment/traefik/traefik.yaml+2

@@ -5,3 +5,5 @@ log:

55providers:

66 file:

77 filename: /etc/traefik/dynamic.yaml

8+ # Routes are static for this example; disabling watch avoids host inotify limits.

9+ watch: false

dist.sh+10−3

@@ -30,16 +30,23 @@ for ARCH in "${ARCHS[@]}"; do

3030 GO_OS=$(echo $ARCH | awk -F- '{print $1}')

3131 GO_ARCH=$(echo $ARCH | awk -F- '{print $2}')

3232

33+ # Determine binary name based on OS

34+ if [[ "${GO_OS}" == "windows" ]]; then

35+ BINARY_NAME="${BINARY}.exe"

36+ else

37+ BINARY_NAME="${BINARY}"

38+ fi

39+

3340 # Create architecture specific binaries

3441 if [[ ${GO_ARCH} == armv* ]]; then

3542 GO_ARM=$(echo $GO_ARCH | awk -Fv '{print $2}')

3643 GO111MODULE=on GOOS=${GO_OS} GOARCH=arm GOARM=${GO_ARM} CGO_ENABLED=0 go build \

3744 -ldflags="-X github.com/oauth2-proxy/oauth2-proxy/v7/pkg/version.VERSION=${VERSION}" \

38− -o release/${BINARY}-${VERSION}.${ARCH}/${BINARY} .

45+ -o release/${BINARY}-${VERSION}.${ARCH}/${BINARY_NAME} .

3946 else

4047 GO111MODULE=on GOOS=${GO_OS} GOARCH=${GO_ARCH} CGO_ENABLED=0 go build \

4148 -ldflags="-X github.com/oauth2-proxy/oauth2-proxy/v7/pkg/version.VERSION=${VERSION}" \

42− -o release/${BINARY}-${VERSION}.${ARCH}/${BINARY} .

49+ -o release/${BINARY}-${VERSION}.${ARCH}/${BINARY_NAME} .

4350 fi

4451

4552 cd release

@@ -51,7 +58,7 @@ for ARCH in "${ARCHS[@]}"; do

5158 sha256sum ${BINARY}-${VERSION}.${ARCH}.tar.gz > ${BINARY}-${VERSION}.${ARCH}.tar.gz-sha256sum.txt

5259

5360 # Create sha256sum for architecture specific binary

54− sha256sum ${BINARY}-${VERSION}.${ARCH}/${BINARY} > ${BINARY}-${VERSION}.${ARCH}-sha256sum.txt

61+ sha256sum ${BINARY}-${VERSION}.${ARCH}/${BINARY_NAME} > ${BINARY}-${VERSION}.${ARCH}-sha256sum.txt

5562

5663 cd ..

5764done

docs/README.md+1−1

@@ -19,7 +19,7 @@ This command starts a local development server and open up a browser window. Mos

1919## Build

2020

2121```console

22−npm build

22+npm run build

2323```

2424

2525This command generates static content into the `build` directory and can be served using any static contents hosting service.

docs/docs/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/docs/community/contribution.md+6−4

@@ -15,7 +15,9 @@ We suggest using [Visual Studio Code](https://code.visualstudio.com/docs/languag

1515

1616# Go version

1717

18−This project is currently still using go 1.22. You can follow the installation guide for go [here.](https://go.dev/doc/install) And you can find go version 1.22 in the archived section [here.](https://go.dev/dl/)

18+See the `go.mod` file in the root of this repository for the version of Go used by this project.

19+You can follow [the installation guide for Go](https://go.dev/doc/install),

20+and you can find this specific Go version on [the Go downloads page](https://go.dev/dl/).

1921

2022# Preparing your fork

2123Clone your fork, create a feature branch and update the depedencies to get started.

@@ -37,7 +39,7 @@ For starting oauth2-proxy locally open the debugging tab and create the `launch.

3739 "version": "0.2.0",

3840 "configurations": [

3941 {

40− "name": "Launch OAuth2-Proxy with Dex",

42+ "name": "Launch OAuth2 Proxy with Dex",

4143 "type": "go",

4244 "request": "launch",

4345 "mode": "auto",

@@ -50,7 +52,7 @@ For starting oauth2-proxy locally open the debugging tab and create the `launch.

5052 ]

5153 },

5254 {

53− "name": "Launch OAuth2-Proxy with Keycloak",

55+ "name": "Launch OAuth2 Proxy with Keycloak",

5456 "type": "go",

5557 "request": "launch",

5658 "mode": "auto",

@@ -83,7 +85,7 @@ The username and password for all setups is usually `admin@example.com` and `pas

8385

8486The docker compose setups expose the services with a dynamic reverse DNS resolver: localtest.me

8587

86−- OAuth2-Proxy: http://oauth2-proxy.localtest.me:4180

88+- OAuth2 Proxy: http://oauth2-proxy.localtest.me:4180

8789- Upstream: http://httpbin.localtest.me:8080

8890- Dex: http://dex.localtest.me:5556

8991

docs/docs/community/security.md+1−1

@@ -21,7 +21,7 @@ any details publicly.

2121Security disclosures MUST be done in private.

2222If you have found an issue that you would like to bring to the attention of the

2323maintenance team for OAuth2 Proxy, please compose an email and send it to the

24−list of maintainers in our [MAINTAINERS](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/MAINTAINERS) file.

24+list of maintainers in our [MAINTAINERS.md](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/MAINTAINERS.md) file.

2525

2626Please include as much detail as possible.

2727Ideally, your disclosure should include:

docs/docs/configuration/alpha_config.md+175−26

@@ -24,17 +24,56 @@ When using alpha configuration, your config file will look something like below:

2424upstreams:

2525 - id: ...

2626 ...: ...

27−injectRequestHeaders:

28− - name: ...

27+providers:

28+ - id: ...

2929 ...: ...

30+cookie:

31+ secret: ...

32+ ...: ...

33+injectRequestHeaders:

34+ - secretSource:

35+ ...: ...

3036injectResponseHeaders:

31− - name: ...

32− ...: ...

37+ - claimSource:

38+ ...: ...

3339```

3440

3541Please browse the [reference](#configuration-reference) below for the structure

3642of the new configuration format.

3743

44+# Migration Guide

45+

46+This section details breaking changes and migration steps for moving to the new

47+alpha configuration format.

48+

49+## Migrating header injections in v7.14.0

50+

51+From v7.14.0 onward, header injection sources must be explicitly nested. If you

52+previously relied on squashed fields, update to the new structure before

53+upgrading:

54+

55+```yaml

56+# before v7.14.0

57+injectRequestHeaders:

58+- name: X-Forwarded-User

59+ values:

60+ - claim: user

61+- name: X-Custom-Secret-header

62+ values:

63+ - value: my-super-secret

64+

65+# v7.14.0 and later

66+injectRequestHeaders:

67+- name: X-Forwarded-User

68+ values:

69+ - claimSource:

70+ claim: user

71+- name: X-Custom-Secret-header

72+ values:

73+ - secretSource:

74+ value: my-super-secret

75+```

76+

3877## Using Alpha Configuration

3978

4079To use the new **alpha** configuration, generate a YAML file based on the format

@@ -67,9 +106,20 @@ the new config.

67106oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

68107```

69108

70−## Using ENV variables in the alpha configuration

109+### Validating Alpha Configuration

71110

72−The alpha package supports the use of environment variables in place of yaml keys, allowing sensitive values to be pulled from somewhere other than the yaml file.

111+Use `--config-test` to validate your alpha configuration without starting the proxy:

112+

113+```bash

114+oauth2-proxy --config core.cfg --alpha-config alpha.yaml --config-test

115+```

116+

117+This is useful for CI/CD pipelines to catch configuration errors before deployment.

118+See the [Configuration Validation](./overview.md#configuration-validation) section for more details.

119+

120+### How to use environment variables

121+

122+The alpha package supports the use of environment variables in place of yaml values, allowing sensitive data to be pulled from somewhere other than the yaml file.

73123When using environment variables, your yaml will look like this:

74124

75125```yaml

@@ -81,6 +131,109 @@ When using environment variables, your yaml will look like this:

81131Where CLIENT_SECRET is an environment variable.

82132More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

83133

134+### How to inject custom headers

135+

136+Configure `injectRequestHeaders` and `injectResponseHeaders` in alpha config YAML.

137+

138+```yaml

139+injectRequestHeaders:

140+ - name: "X-User-Email"

141+ values:

142+ - claimSource:

143+ claim: "email" # extract the email claim contents from the id token

144+ - name: "X-Static-Secret"

145+ values:

146+ # secrets need to be encoded with base64 when directly in the yaml config but will be send decoded

147+ - secretSource:

148+ value: "c3VwZXItc2VjcmV0"

149+ - name: "X-Static-File-Secret"

150+ - secretSource:

151+ fromFile: "/path/to/my/secret"

152+ - name: "X-Static-Env-Secret"

153+ - secretSource:

154+ value: "${MY_SECRET_ENV}" # content still needs to be base64 encoded

155+injectResponseHeaders:

156+ # Following will result in a header "Authorization: Basic <user:password> (encoded)"

157+ - name: "Authorization"

158+ values:

159+ - claimSource:

160+ claim: user

161+ prefix: "Basic "

162+ basicAuthPassword:

163+ value: c3VwZXItc2VjcmV0LXBhc3N3b3Jk # base64 encoded password

164+```

165+

166+**Value sources:**

167+* `claimSource` - `claim` (session claims either from id token or from profile URL)

168+* `secretSource` - `value` (base64), `fromFile` (file path)

169+

170+#### Claim value serialization

171+

172+`claimSource` converts the selected claim into one or more string header values. Scalars

173+produce one value, while arrays produce one value per element. Values that cannot be

174+converted directly to strings, such as objects, are JSON-encoded individually.

175+

176+Each non-empty value is added separately under the configured header name. An array of

177+objects therefore produces multiple header values containing one JSON object each, not a

178+single JSON array. HTTP libraries and intermediaries may expose repeated values as a

179+comma-joined string, so consumers should retrieve and parse each header value separately.

180+

181+**Request option:** `preserveRequestValue: true` retains existing header values

182+

183+**Incompatibility:** Remove legacy flags `pass-user-headers`, `set-xauthrequest`

184+

185+### How to utilize arbitrary claims provided by your Identity Provider

186+

187+With the additionalClaims attribute you can specify which claims you want to extract

188+from the ID Token or userinfo (ProfileURL) endpoint.

189+

190+Configure these on the relevant provider entry:

191+

192+```yaml

193+providers:

194+ - id: my-oidc-provider

195+ provider: oidc

196+ clientID: ${OAUTH_CLIENT_ID}

197+ clientSecret: ${OAUTH_CLIENT_SECRET}

198+ oidcConfig:

199+ issuerURL: https://issuer.example.com

200+ profileURL: https://issuer.example.com/oauth2/userinfo

201+ additionalClaims:

202+ - department

203+ - employee_id

204+ - organization.name

205+```

206+

207+OAuth2 Proxy resolves each configured claim using the following order:

208+

209+1. The raw ID token is checked first.

210+2. If the claim is not present there and `profileURL` is configured, the userinfo endpoint is queried.

211+3. If `skipClaimsFromProfileURL: true` is set, only the ID token is used.

212+

213+Claims that are not found are ignored rather than causing authentication to fail.

214+

215+You can use dot-separated paths for nested JSON objects, for example `organization.name`.

216+Array indexes are not supported.

217+

218+Once loaded, these claims are stored in the session as `additionalClaims`. They can then be

219+used anywhere session claims are accepted, including header injection:

220+

221+```yaml

222+injectRequestHeaders:

223+ - name: X-Department

224+ values:

225+ - claimSource:

226+ claim: department

227+ - name: X-Organization

228+ values:

229+ - claimSource:

230+ claim: organization.name

231+```

232+

233+This is useful when your IdP exposes application-specific attributes such as department,

234+tenant, employee ID, entitlement, or other custom claims that are not part of the default

235+OAuth2 Proxy session fields.

236+

84237## Removed options

85238

86239The following flags/options and their respective environment variables are no

@@ -204,16 +357,6 @@ ClaimSource allows loading a header value from a claim within the session

204357| `prefix` | _string_ | Prefix is an optional prefix that will be prepended to the value of the<br/>claim if it is non-empty. |

205358| `basicAuthPassword` | _[SecretSource](#secretsource)_ | BasicAuthPassword converts this claim into a basic auth header.<br/>Note the value of claim will become the basic auth username and the<br/>basicAuthPassword will be used as the password value. |

206359

207−### Duration

208−#### (`string` alias)

209−

210−(**Appears on:** [Upstream](#upstream))

211−

212−Duration is as string representation of a period of time.

213−A duration string is a is a possibly signed sequence of decimal numbers,

214−each with optional fraction and a unit suffix, such as "300ms", "-1.5h" or "2h45m".

215−Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".

216−

217360### GitHubOptions

218361

219362(**Appears on:** [Provider](#provider))

@@ -252,6 +395,8 @@ Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".

252395| `serviceAccountJson` | _string_ | ServiceAccountJSON is the path to the service account json credentials |

253396| `useApplicationDefaultCredentials` | _bool_ | UseApplicationDefaultCredentials is a boolean whether to use Application Default Credentials instead of a ServiceAccountJSON |

254397| `targetPrincipal` | _string_ | TargetPrincipal is the Google Service Account used for Application Default Credentials |

398+| `useOrganizationID` | _bool_ | UseOrganizationId indicates whether to use the organization ID as the UserName claim |

399+| `adminAPIUserScope` | _string_ | admin scope needed for fetching user organization information from admin api, can be one of cloud, user or defaults to readonly |

255400

256401### Header

257402

@@ -264,6 +409,7 @@ response header.

264409| ----- | ---- | ----------- |

265410| `name` | _string_ | Name is the header name to be used for this set of values.<br/>Names should be unique within a list of Headers. |

266411| `preserveRequestValue` | _bool_ | PreserveRequestValue determines whether any values for this header<br/>should be preserved for the request to the upstream server.<br/>This option only applies to injected request headers.<br/>Defaults to false (headers that match this header will be stripped). |

412+| `InsecureSkipHeaderNormalization` | _bool_ | InsecureSkipHeaderNormalization disables normalizing the header name<br/>According to RFC 7230 Section 3.2 there aren't any rules about<br/>capitalization of header names, but the standard practice is to use<br/>Title-Case (e.g. X-Forwarded-For). By default, header names will be<br/>normalized to Title-Case and any incoming headers that match will be<br/>treated as the same header. Additionally underscores (_) in header names<br/>will be converted to dashes (-) when normalizing.<br/>Defaults to false (header names will be normalized). |

267413| `values` | _[[]HeaderValue](#headervalue)_ | Values contains the desired values for this header |

268414

269415### HeaderValue

@@ -416,6 +562,7 @@ character.

416562| `userIDClaim` | _string_ | UserIDClaim indicates which claim contains the user ID<br/>default set to 'email' |

417563| `audienceClaims` | _[]string_ | AudienceClaim allows to define any claim that is verified against the client id<br/>By default `aud` claim is used for verification. |

418564| `extraAudiences` | _[]string_ | ExtraAudiences is a list of additional audiences that are allowed<br/>to pass verification in addition to the client id. |

565+| `enabledSigningAlgs` | _[]string_ | EnabledSigningAlgs is a list of allowed JWT signing algorithms.<br/>When discovery is enabled, the effective set is the intersection<br/>between this list and the provider's discovered supported algorithms.<br/>By default `RS256` is used if nothing has been discovered or specified. |

419566

420567### Provider

421568

@@ -454,6 +601,7 @@ Provider holds all configuration for a single provider

454601| `scope` | _string_ | Scope is the OAuth scope specification |

455602| `allowedGroups` | _[]string_ | AllowedGroups is a list of restrict logins to members of this group |

456603| `code_challenge_method` | _string_ | The code challenge method |

604+| `additionalClaims` | _[]string_ | Additional claims to be obtained from the upstream IDP, either from the id_token or from the userinfo endpoint if configured. |

457605| `backendLogoutURL` | _string_ | URL to call to perform backend logout, `{id_token}` would be replaced by the actual `id_token` if available in the session |

458606

459607### ProviderType

@@ -499,9 +647,9 @@ Server represents the configuration for an HTTP(S) server

499647

500648| Field | Type | Description |

501649| ----- | ---- | ----------- |

502−| `BindAddress` | _string_ | BindAddress is the address on which to serve traffic.<br/>Leave blank or set to "-" to disable. |

503−| `SecureBindAddress` | _string_ | SecureBindAddress is the address on which to serve secure traffic.<br/>Leave blank or set to "-" to disable. |

504−| `TLS` | _[TLS](#tls)_ | TLS contains the information for loading the certificate and key for the<br/>secure traffic and further configuration for the TLS server. |

650+| `bindAddress` | _string_ | BindAddress is the address on which to serve traffic.<br/>Different types of bind addresses are supported:<br/>* `[http://]<addr>:<port>`<br/>* `fd:<int>` (case insensitive)<br/>* `unix://<path>`<br/>Unix sockets are created with default system umask mode, which can be overridden, e.g.: `unix://my-socket,mode=0777`<br/>Square brackets are required for ipv6 address, e.g. `http://[::1]:4180`<br/>Leave blank or set to "-" to disable. |

651+| `secureBindAddress` | _string_ | SecureBindAddress is the address on which to serve secure traffic.<br/>Secure bind addresses need to respond with valid SSL and use the following format:<br/>* `[https://]<addr>:<port>`<br/>Square brackets are required for ipv6 address, e.g. `https://[::1]:4180`<br/>Leave blank or set to "-" to disable. |

652+| `tls` | _[TLS](#tls)_ | TLS contains the information for loading the certificate and key for the<br/>secure traffic and further configuration for the TLS server. |

505653

506654### TLS

507655

@@ -512,10 +660,10 @@ as well as an optional minimal TLS version that is acceptable.

512660

513661| Field | Type | Description |

514662| ----- | ---- | ----------- |

515−| `Key` | _[SecretSource](#secretsource)_ | Key is the TLS key data to use.<br/>Typically this will come from a file. |

516−| `Cert` | _[SecretSource](#secretsource)_ | Cert is the TLS certificate data to use.<br/>Typically this will come from a file. |

517−| `MinVersion` | _string_ | MinVersion is the minimal TLS version that is acceptable.<br/>E.g. Set to "TLS1.3" to select TLS version 1.3 |

518−| `CipherSuites` | _[]string_ | CipherSuites is a list of TLS cipher suites that are allowed.<br/>E.g.:<br/>- TLS_RSA_WITH_RC4_128_SHA<br/>- TLS_RSA_WITH_AES_256_GCM_SHA384<br/>If not specified, the default Go safe cipher list is used.<br/>List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). |

663+| `key` | _[SecretSource](#secretsource)_ | Key is the TLS key data to use.<br/>Typically this will come from a file. |

664+| `cert` | _[SecretSource](#secretsource)_ | Cert is the TLS certificate data to use.<br/>Typically this will come from a file. |

665+| `minVersion` | _string_ | MinVersion is the minimal TLS version that is acceptable.<br/>E.g. Set to "TLS1.3" to select TLS version 1.3 |

666+| `cipherSuites` | _[]string_ | CipherSuites is a list of TLS cipher suites that are allowed.<br/>E.g.:<br/>- TLS_RSA_WITH_RC4_128_SHA<br/>- TLS_RSA_WITH_AES_256_GCM_SHA384<br/>If not specified, the default Go safe cipher list is used.<br/>List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). |

519667

520668### URLParameterRule

521669

@@ -541,16 +689,17 @@ Requests will be proxied to this upstream if the path matches the request path.

541689| Field | Type | Description |

542690| ----- | ---- | ----------- |

543691| `id` | _string_ | ID should be a unique identifier for the upstream.<br/>This value is required for all upstreams. |

544−| `path` | _string_ | Path is used to map requests to the upstream server.<br/>The closest match will take precedence and all Paths must be unique.<br/>Path can also take a pattern when used with RewriteTarget.<br/>Path segments can be captured and matched using regular experessions.<br/>Eg:<br/>- `^/foo$`: Match only the explicit path `/foo`<br/>- `^/bar/$`: Match any path prefixed with `/bar/`<br/>- `^/baz/(.*)$`: Match any path prefixed with `/baz` and capture the remaining path for use with RewriteTarget |

692+| `path` | _string_ | Path is used to map requests to the upstream server.<br/>The closest match will take precedence and all Paths must be unique.<br/>Without RewriteTarget, Path follows gorilla/mux route syntax.<br/>Eg:<br/>- `/foo`: Match only the explicit path `/foo`<br/>- `/bar/`: Match any path prefixed with `/bar/`<br/>- `/baz/{path:.*}`: Match any path prefixed with `/baz/`<br/>When RewriteTarget is set, Path is treated as a regular expression.<br/>Eg: `^/baz/(.*)$` matches any path prefixed with `/baz` and captures the<br/>remaining path for use with RewriteTarget. |

545693| `rewriteTarget` | _string_ | RewriteTarget allows users to rewrite the request path before it is sent to<br/>the upstream server (for an HTTP/HTTPS upstream) or mapped to the filesystem<br/>(for a `file:` upstream).<br/>Use the Path to capture segments for reuse within the rewrite target.<br/>Eg: With a Path of `^/baz/(.*)`, a RewriteTarget of `/foo/$1` would rewrite<br/>the request `/baz/abc/123` to `/foo/abc/123` before proxying to the<br/>upstream server. Or if the upstream were `file:///app`, a request for<br/>`/baz/info.html` would return the contents of the file `/app/foo/info.html`. |

546694| `uri` | _string_ | The URI of the upstream server. This may be an HTTP(S) server of a File<br/>based URL. It may include a path, in which case all requests will be served<br/>under that path.<br/>Eg:<br/>- http://localhost:8080<br/>- https://service.localhost<br/>- https://service.localhost/path<br/>- file://host/path<br/>If the URI's path is "/base" and the incoming request was for "/dir",<br/>the upstream request will be for "/base/dir". |

547695| `insecureSkipTLSVerify` | _bool_ | InsecureSkipTLSVerify will skip TLS verification of upstream HTTPS hosts.<br/>This option is insecure and will allow potential Man-In-The-Middle attacks<br/>between OAuth2 Proxy and the upstream server.<br/>Defaults to false. |

548696| `static` | _bool_ | Static will make all requests to this upstream have a static response.<br/>The response will have a body of "Authenticated" and a response code<br/>matching StaticCode.<br/>If StaticCode is not set, the response will return a 200 response. |

549697| `staticCode` | _int_ | StaticCode determines the response code for the Static response.<br/>This option can only be used with Static enabled. |

550−| `flushInterval` | _[Duration](#duration)_ | FlushInterval is the period between flushing the response buffer when<br/>streaming response from the upstream.<br/>Defaults to 1 second. |

698+| `flushInterval` | _duration_ | FlushInterval is the period between flushing the response buffer when<br/>streaming response from the upstream.<br/>Defaults to 1 second. |

551699| `passHostHeader` | _bool_ | PassHostHeader determines whether the request host header should be proxied<br/>to the upstream server.<br/>Defaults to true. |

552700| `proxyWebSockets` | _bool_ | ProxyWebSockets enables proxying of websockets to upstream servers<br/>Defaults to true. |

553−| `timeout` | _[Duration](#duration)_ | Timeout is the maximum duration the server will wait for a response from the upstream server.<br/>Defaults to 30 seconds. |

701+| `timeout` | _duration_ | Timeout is the maximum duration the server will wait for a response from the upstream server.<br/>Defaults to 30 seconds. |

702+| `disableKeepAlives` | _bool_ | DisableKeepAlives disables HTTP keep-alive connections to the upstream server.<br/>Defaults to false. |

554703

555704### UpstreamConfig

556705

docs/docs/configuration/alpha_config.md.tmpl+159−6

@@ -24,17 +24,56 @@ When using alpha configuration, your config file will look something like below:

2424upstreams:

2525 - id: ...

2626 ...: ...

27−injectRequestHeaders:

28− - name: ...

27+providers:

28+ - id: ...

2929 ...: ...

30+cookie:

31+ secret: ...

32+ ...: ...

33+injectRequestHeaders:

34+ - secretSource:

35+ ...: ...

3036injectResponseHeaders:

31− - name: ...

32− ...: ...

37+ - claimSource:

38+ ...: ...

3339```

3440

3541Please browse the [reference](#configuration-reference) below for the structure

3642of the new configuration format.

3743

44+# Migration Guide

45+

46+This section details breaking changes and migration steps for moving to the new

47+alpha configuration format.

48+

49+## Migrating header injections in v7.14.0

50+

51+From v7.14.0 onward, header injection sources must be explicitly nested. If you

52+previously relied on squashed fields, update to the new structure before

53+upgrading:

54+

55+```yaml

56+# before v7.14.0

57+injectRequestHeaders:

58+- name: X-Forwarded-User

59+ values:

60+ - claim: user

61+- name: X-Custom-Secret-header

62+ values:

63+ - value: my-super-secret

64+

65+# v7.14.0 and later

66+injectRequestHeaders:

67+- name: X-Forwarded-User

68+ values:

69+ - claimSource:

70+ claim: user

71+- name: X-Custom-Secret-header

72+ values:

73+ - secretSource:

74+ value: my-super-secret

75+```

76+

3877## Using Alpha Configuration

3978

4079To use the new **alpha** configuration, generate a YAML file based on the format

@@ -67,9 +106,20 @@ the new config.

67106oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

68107```

69108

70−## Using ENV variables in the alpha configuration

109+### Validating Alpha Configuration

110+

111+Use `--config-test` to validate your alpha configuration without starting the proxy:

112+

113+```bash

114+oauth2-proxy --config core.cfg --alpha-config alpha.yaml --config-test

115+```

116+

117+This is useful for CI/CD pipelines to catch configuration errors before deployment.

118+See the [Configuration Validation](./overview.md#configuration-validation) section for more details.

71119

72−The alpha package supports the use of environment variables in place of yaml keys, allowing sensitive values to be pulled from somewhere other than the yaml file.

120+### How to use environment variables

121+

122+The alpha package supports the use of environment variables in place of yaml values, allowing sensitive data to be pulled from somewhere other than the yaml file.

73123When using environment variables, your yaml will look like this:

74124

75125```yaml

@@ -81,6 +131,109 @@ When using environment variables, your yaml will look like this:

81131Where CLIENT_SECRET is an environment variable.

82132More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

83133

134+### How to inject custom headers

135+

136+Configure `injectRequestHeaders` and `injectResponseHeaders` in alpha config YAML.

137+

138+```yaml

139+injectRequestHeaders:

140+ - name: "X-User-Email"

141+ values:

142+ - claimSource:

143+ claim: "email" # extract the email claim contents from the id token

144+ - name: "X-Static-Secret"

145+ values:

146+ # secrets need to be encoded with base64 when directly in the yaml config but will be send decoded

147+ - secretSource:

148+ value: "c3VwZXItc2VjcmV0"

149+ - name: "X-Static-File-Secret"

150+ - secretSource:

151+ fromFile: "/path/to/my/secret"

152+ - name: "X-Static-Env-Secret"

153+ - secretSource:

154+ value: "${MY_SECRET_ENV}" # content still needs to be base64 encoded

155+injectResponseHeaders:

156+ # Following will result in a header "Authorization: Basic <user:password> (encoded)"

157+ - name: "Authorization"

158+ values:

159+ - claimSource:

160+ claim: user

161+ prefix: "Basic "

162+ basicAuthPassword:

163+ value: c3VwZXItc2VjcmV0LXBhc3N3b3Jk # base64 encoded password

164+```

165+

166+**Value sources:**

167+* `claimSource` - `claim` (session claims either from id token or from profile URL)

168+* `secretSource` - `value` (base64), `fromFile` (file path)

169+

170+#### Claim value serialization

171+

172+`claimSource` converts the selected claim into one or more string header values. Scalars

173+produce one value, while arrays produce one value per element. Values that cannot be

174+converted directly to strings, such as objects, are JSON-encoded individually.

175+

176+Each non-empty value is added separately under the configured header name. An array of

177+objects therefore produces multiple header values containing one JSON object each, not a

178+single JSON array. HTTP libraries and intermediaries may expose repeated values as a

179+comma-joined string, so consumers should retrieve and parse each header value separately.

180+

181+**Request option:** `preserveRequestValue: true` retains existing header values

182+

183+**Incompatibility:** Remove legacy flags `pass-user-headers`, `set-xauthrequest`

184+

185+### How to utilize arbitrary claims provided by your Identity Provider

186+

187+With the additionalClaims attribute you can specify which claims you want to extract

188+from the ID Token or userinfo (ProfileURL) endpoint.

189+

190+Configure these on the relevant provider entry:

191+

192+```yaml

193+providers:

194+ - id: my-oidc-provider

195+ provider: oidc

196+ clientID: ${OAUTH_CLIENT_ID}

197+ clientSecret: ${OAUTH_CLIENT_SECRET}

198+ oidcConfig:

199+ issuerURL: https://issuer.example.com

200+ profileURL: https://issuer.example.com/oauth2/userinfo

201+ additionalClaims:

202+ - department

203+ - employee_id

204+ - organization.name

205+```

206+

207+OAuth2 Proxy resolves each configured claim using the following order:

208+

209+1. The raw ID token is checked first.

210+2. If the claim is not present there and `profileURL` is configured, the userinfo endpoint is queried.

211+3. If `skipClaimsFromProfileURL: true` is set, only the ID token is used.

212+

213+Claims that are not found are ignored rather than causing authentication to fail.

214+

215+You can use dot-separated paths for nested JSON objects, for example `organization.name`.

216+Array indexes are not supported.

217+

218+Once loaded, these claims are stored in the session as `additionalClaims`. They can then be

219+used anywhere session claims are accepted, including header injection:

220+

221+```yaml

222+injectRequestHeaders:

223+ - name: X-Department

224+ values:

225+ - claimSource:

226+ claim: department

227+ - name: X-Organization

228+ values:

229+ - claimSource:

230+ claim: organization.name

231+```

232+

233+This is useful when your IdP exposes application-specific attributes such as department,

234+tenant, employee ID, entitlement, or other custom claims that are not part of the default

235+OAuth2 Proxy session fields.

236+

84237## Removed options

85238

86239The following flags/options and their respective environment variables are no

docs/docs/configuration/integrations/caddy.mdnew file+63

@@ -0,0 +1,63 @@

1+---

2+id: caddy

3+title: Caddy

4+---

5+

6+Integrate OAuth2 Proxy with Caddy v2 using the `forward_auth` directive.

7+

8+**Key features:**

9+- Simple forward_auth setup

10+- Automatic header handling

11+- Custom error handling and redirects

12+

13+## Configuring for use with the Caddy (v2) `forward_auth` directive

14+

15+The [Caddy `forward_auth` directive](https://caddyserver.com/docs/caddyfile/directives/forward_auth) allows Caddy to authenticate requests via the `oauth2-proxy`'s `/auth`.

16+

17+This example is for a simple reverse proxy setup where the `/oauth2/` path is kept under the same domain and failed auth requests (401 status returned) will be caught and redirected to the `sign_in` endpoint.

18+

19+**Following options need to be set on `oauth2-proxy`:**

20+- `--reverse-proxy=true`: Enables the use of `X-Forwarded-*` headers to determine redirects correctly

21+

22+```nginx title="Caddyfile"

23+example.com {

24+ # Requests to /oauth2/* are proxied to oauth2-proxy without authentication.

25+ # You can't use `reverse_proxy /oauth2/* oauth2-proxy.internal:4180` here because the reverse_proxy directive has lower precedence than the handle directive.

26+ handle /oauth2/* {

27+ reverse_proxy oauth2-proxy.internal:4180 {

28+ # oauth2-proxy requires the X-Real-IP and X-Forwarded-{Proto,Host,Uri} headers.

29+ # The reverse_proxy directive automatically sets X-Forwarded-{For,Proto,Host} headers.

30+ header_up X-Real-IP {remote_host}

31+ header_up X-Forwarded-Uri {uri}

32+ }

33+ }

34+

35+ # Requests to other paths are first processed by oauth2-proxy for authentication.

36+ handle {

37+ forward_auth oauth2-proxy.internal:4180 {

38+ uri /oauth2/auth

39+

40+ # oauth2-proxy requires the X-Real-IP and X-Forwarded-{Proto,Host,Uri} headers.

41+ # The forward_auth directive automatically sets the X-Forwarded-{For,Proto,Host,Method,Uri} headers.

42+ header_up X-Real-IP {remote_host}

43+

44+ # If needed, you can copy headers from the oauth2-proxy response to the request sent to the upstream.

45+ # Make sure to configure the --set-xauthrequest flag to enable this feature.

46+ #copy_headers X-Auth-Request-User X-Auth-Request-Email

47+

48+ # If oauth2-proxy returns a 401 status, redirect the client to the sign-in page.

49+ @error status 401

50+ handle_response @error {

51+ redir * /oauth2/sign_in?rd={scheme}://{host}{uri}

52+ }

53+ }

54+

55+ # If oauth2-proxy returns a 2xx status, the request is then proxied to the upstream.

56+ reverse_proxy upstream.internal:3000

57+ }

58+}

59+```

60+

61+:::note

62+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

63+:::

docs/docs/configuration/integrations/headlamp.mdnew file+105

@@ -0,0 +1,105 @@

1+---

2+id: headlamp

3+title: Headlamp

4+---

5+

6+Modern, actively maintained Kubernetes web UI with OAuth2 Proxy integration examples.

7+

8+**Key features:**

9+- Active development and maintenance

10+- Modern, intuitive interface

11+- Multi-cluster support

12+- Plugin system

13+- Works with all OAuth2 providers

14+

15+## Configuring for use with Headlamp

16+

17+[Headlamp](https://headlamp.dev/) is a modern, user-friendly Kubernetes web UI that can be integrated with OAuth2 Proxy for authentication. This is a recommended alternative to the deprecated Kubernetes Dashboard.

18+

19+### Architecture

20+

21+```

22+User → Ingress → OAuth2 Proxy → Authentication Provider (e.g., Azure Entra ID)

23+ ↓

24+ Headlamp

25+```

26+

27+### Prerequisites

28+

29+- Kubernetes cluster (e.g., AKS, EKS, GKE, or self-hosted)

30+- Headlamp installed in the cluster

31+- OAuth2 provider configured (Azure Entra ID, Google, GitHub, etc.)

32+- Ingress controller (Nginx, Traefik, etc.)

33+

34+### Configuration Overview

35+

36+When integrating Headlamp with OAuth2 Proxy, the OAuth2 Proxy acts as a reverse proxy in front of Headlamp:

37+

38+1. User requests access to Headlamp

39+2. Ingress forwards to OAuth2 Proxy

40+3. OAuth2 Proxy authenticates the user via the OAuth2 provider

41+4. After successful authentication, OAuth2 Proxy proxies requests to Headlamp

42+5. Headlamp receives the authenticated user information via headers

43+

44+### OAuth2 Proxy Configuration

45+

46+Configure OAuth2 Proxy to proxy to the Headlamp service:

47+

48+```yaml

49+upstreamConfig:

50+ upstreams:

51+ - id: headlamp

52+ path: /

53+ uri: http://headlamp-service.headlamp-namespace.svc.cluster.local:4466

54+```

55+

56+Enable the necessary headers:

57+

58+```yaml

59+extraArgs:

60+ reverse-proxy: true

61+ pass-authorization-header: true

62+ set-xauthrequest: true

63+ email-domain: "*" # Or restrict to your organization

64+```

65+

66+### Example with Azure Entra ID on AKS

67+

68+For detailed instructions on deploying Headlamp with OAuth2 Proxy on Azure Kubernetes Service using Azure Entra ID, see the official Headlamp documentation:

69+

70+https://headlamp.dev/docs/latest/installation/in-cluster/aks-cluster-oauth/

71+

72+Key steps include:

73+

74+1. **Set up AKS with OIDC**: Enable Microsoft Entra ID authentication with Kubernetes RBAC

75+2. **Create Azure App Registration**: Configure redirect URI and create client secret

76+3. **Deploy Headlamp**: Install Headlamp via Helm in your cluster

77+4. **Deploy OAuth2 Proxy**: Configure OAuth2 Proxy with Entra ID provider settings and upstream pointing to Headlamp

78+5. **Configure Ingress**: Set up Ingress to route traffic through OAuth2 Proxy to Headlamp

79+6. **Set RBAC Policies**: Apply Kubernetes RBAC bindings based on users or groups

80+

81+### Integration with Other Providers

82+

83+The same integration pattern works with other OAuth2 providers supported by OAuth2 Proxy:

84+

85+- **Google**: Use the Google provider configuration

86+- **GitHub**: Use the GitHub provider configuration

87+- **GitLab**: Use the GitLab provider configuration

88+- **Keycloak**: Use the Keycloak OIDC provider configuration

89+- **Any OIDC Provider**: Use the generic OIDC provider configuration

90+

91+For provider-specific configuration examples, see the [OAuth Provider Configuration](../providers/index.md) documentation.

92+

93+### Benefits Over Kubernetes Dashboard

94+

95+Headlamp offers several advantages:

96+

97+- **Active Development**: Headlamp is actively maintained and developed

98+- **Modern UI**: Clean, intuitive interface with better UX

99+- **Plugin System**: Extensible with custom plugins

100+- **Multi-cluster Support**: Built-in support for managing multiple clusters

101+- **Desktop App**: Available as both web UI and desktop application

102+

103+:::note

104+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

105+:::

docs/docs/configuration/integrations/index.mdnew file+41

@@ -0,0 +1,41 @@

1+---

2+id: index

3+title: Integrations

4+---

5+

6+This section provides configuration examples for integrating OAuth2 Proxy with various reverse proxies, ingress controllers, and Kubernetes web UIs.

7+

8+## Reverse Proxies and Ingress Controllers

9+

10+OAuth2 Proxy can be integrated with popular reverse proxies and ingress controllers to add authentication to your applications:

11+

12+- [Nginx](nginx.md)

13+- [Traefik](traefik.md)

14+- [caddy](caddy.md)

15+

16+## Kubernetes Web UIs

17+

18+OAuth2 Proxy can also be used to add authentication to Kubernetes web user interfaces:

19+

20+- [Headlamp](headlamp.md) ✨ *Recommended*

21+- [Kubernetes Dashboard](kubernetes-dashboard.md) ⚠️ *Deprecated*

22+

23+:::tip

24+When integrating with Kubernetes web UIs, make sure to:

25+1. Configure the Ingress to pass the Authorization header with the bearer token

26+2. Increase buffer sizes for large OIDC tokens (especially with Azure Entra ID)

27+3. Set up appropriate Kubernetes RBAC permissions for your users or groups

28+:::

29+

30+## General Requirements

31+

32+Most integrations require the following OAuth2 Proxy configuration:

33+

34+- `--reverse-proxy=true`: Required to correctly handle `X-Forwarded-*` headers

35+- **Session storage**: For production deployments with large tokens due to a lot of claims like AD groups, use `--session-store-type=redis`

36+

37+For provider-specific configuration, see the [OAuth Provider Configuration](../providers/index.md) documentation.

38+

39+:::note

40+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

41+:::

docs/docs/configuration/integrations/kubernetes-dashboard.mdnew file+289

@@ -0,0 +1,289 @@

1+---

2+id: kubernetes-dashboard

3+title: Kubernetes Dashboard

4+---

5+

6+:::warning Deprecated Project

7+Kubernetes Dashboard has been deprecated and discontinued as of January 2025. See the [official announcement](https://github.com/kubernetes/dashboard/commit/0ba796dce6916bb6ca5da5ca0b3ab22cecfd1e18) for more information.

8+

9+You may want to consider alternative solutions such as [Headlamp](./headlamp.md).

10+:::

11+

12+## Kubernetes Dashboard on AKS with Azure Entra ID

13+

14+Integration guide for the deprecated Kubernetes Dashboard, including comprehensive Azure Entra ID configuration on AKS with detailed troubleshooting and RBAC setup.

15+

16+### Architecture

17+

18+```

19+User → Nginx Ingress → OAuth2 Proxy → Entra ID

20+ ↓

21+ Kubernetes Dashboard

22+```

23+

24+The integration flow:

25+1. Unauthenticated requests to Dashboard are intercepted by Nginx Ingress

26+2. Nginx redirects to OAuth2 Proxy for authentication

27+3. OAuth2 Proxy redirects to Entra ID login

28+4. After successful authentication, OAuth2 Proxy receives ID token from Entra ID

29+5. OAuth2 Proxy sets Authorization header with the bearer token

30+6. Nginx forwards the request with token to Kubernetes Dashboard

31+7. Dashboard validates the token and grants access based on AKS RBAC configuration

32+

33+### Prerequisites

34+

35+- AKS cluster with Entra ID integration enabled

36+- Kubernetes Dashboard installed (version 7.x or later)

37+- NGINX Ingress Controller installed

38+- Entra ID App Registration configured with:

39+ - Redirect URI: `https://your-oauth2-domain.com/oauth2/callback`

40+ - API Permissions: `openid`, `email`, `profile`

41+ - Groups claim enabled (if using group-based RBAC)

42+- Users or groups assigned appropriate Kubernetes RBAC permissions

43+

44+### Alpha Configuration Example

45+

46+Using [Alpha Configuration](../alpha_config.md) with the OAuth2 Proxy Helm chart:

47+

48+```yaml

49+alphaConfig:

50+ enabled: true

51+ configData:

52+ providers:

53+ - id: azure-entra

54+ provider: entra-id

55+ clientID: YOUR_CLIENT_ID

56+ clientSecret: YOUR_CLIENT_SECRET

57+ oidcConfig:

58+ issuerURL: https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0

59+ audienceClaims:

60+ - aud

61+ emailClaim: email

62+ groupsClaim: groups

63+ userIDClaim: oid

64+ scope: openid email profile

65+

66+ upstreamConfig:

67+ upstreams:

68+ - id: static

69+ path: /

70+ static: true

71+ staticCode: 200

72+

73+ # Response headers passed to Dashboard via Nginx

74+ injectResponseHeaders:

75+ - name: Authorization

76+ values:

77+ - claim: id_token

78+ prefix: "Bearer "

79+ - name: X-Auth-Request-User

80+ values:

81+ - claim: email

82+ - name: X-Auth-Request-Email

83+ values:

84+ - claim: email

85+ - name: X-Auth-Request-Groups

86+ values:

87+ - claim: groups

88+

89+ server:

90+ BindAddress: "0.0.0.0:4180"

91+

92+extraArgs:

93+ cookie-domain: ".your-domain.com"

94+ whitelist-domain: ".your-domain.com"

95+ email-domain: "*" # Or restrict to your organization

96+ skip-provider-button: true

97+ reverse-proxy: true

98+ pass-authorization-header: true

99+ set-xauthrequest: true

100+

101+sessionStorage:

102+ type: redis

103+

104+redis:

105+ enabled: true

106+ auth:

107+ enabled: true

108+

109+ingress:

110+ enabled: true

111+ className: nginx

112+ hosts:

113+ - OAuth2 Proxy.your-domain.com

114+ path: /oauth2

115+ pathType: Prefix

116+```

117+

118+### Kubernetes Dashboard Ingress

119+

120+**Critical**: The Ingress must include `Authorization` in the `auth-response-headers` annotation:

121+

122+```yaml

123+apiVersion: networking.k8s.io/v1

124+kind: Ingress

125+metadata:

126+ name: kubernetes-dashboard

127+ namespace: kubernetes-dashboard

128+ annotations:

129+ nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

130+ nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

131+

132+ # OAuth2 Proxy authentication

133+ nginx.ingress.kubernetes.io/auth-url: "https://OAuth2 Proxy.your-domain.com/oauth2/auth"

134+ nginx.ingress.kubernetes.io/auth-signin: "https://OAuth2 Proxy.your-domain.com/oauth2/start?rd=$scheme://$best_http_host$request_uri"

135+

136+ # Include Authorization header with bearer token

137+ nginx.ingress.kubernetes.io/auth-response-headers: "Authorization, X-Auth-Request-User, X-Auth-Request-Email"

138+

139+ # Buffer sizes for large tokens (Entra tokens can exceed 4KB)

140+ nginx.ingress.kubernetes.io/proxy-buffer-size: "256k"

141+ nginx.ingress.kubernetes.io/proxy-buffers-number: "4"

142+ nginx.ingress.kubernetes.io/proxy-busy-buffers-size: "256k"

143+spec:

144+ ingressClassName: nginx

145+ tls:

146+ - hosts:

147+ - dashboard.your-domain.com

148+ secretName: dashboard-tls

149+ rules:

150+ - host: dashboard.your-domain.com

151+ http:

152+ paths:

153+ - path: /

154+ pathType: Prefix

155+ backend:

156+ service:

157+ name: kubernetes-dashboard-kong-proxy

158+ port:

159+ number: 443

160+```

161+

162+### RBAC Configuration

163+

164+Assign Kubernetes permissions to Entra ID users or groups.

165+

166+**User-based:**

167+```yaml

168+apiVersion: rbac.authorization.k8s.io/v1

169+kind: ClusterRoleBinding

170+metadata:

171+ name: dashboard-user-admin

172+roleRef:

173+ apiGroup: rbac.authorization.k8s.io

174+ kind: ClusterRole

175+ name: cluster-admin

176+subjects:

177+ - kind: User

178+ name: "user@your-domain.com" # Email from Entra ID token

179+ apiGroup: rbac.authorization.k8s.io

180+```

181+

182+**Group-based (recommended):**

183+```yaml

184+apiVersion: rbac.authorization.k8s.io/v1

185+kind: ClusterRoleBinding

186+metadata:

187+ name: dashboard-admins-group

188+roleRef:

189+ apiGroup: rbac.authorization.k8s.io

190+ kind: ClusterRole

191+ name: cluster-admin

192+subjects:

193+ - kind: Group

194+ name: "YOUR_ENTRA_GROUP_OBJECT_ID" # Entra ID Group Object ID

195+ apiGroup: rbac.authorization.k8s.io

196+```

197+

198+For production, create custom roles with limited permissions instead of using `cluster-admin`.

199+

200+### Troubleshooting

201+

202+**Dashboard still asks for token after authentication**

203+

204+Verify that:

205+1. `injectResponseHeaders` in alphaConfig includes Authorization header with id_token claim

206+2. Dashboard Ingress includes `Authorization` in `auth-response-headers` annotation

207+3. Buffer sizes are sufficient for large tokens (set to 256k as shown above)

208+4. Check OAuth2 Proxy logs for successful token generation: `kubectl logs -n OAuth2 Proxy <pod-name>`

209+

210+**"Unauthorized" or "Invalid token" errors**

211+

212+Common causes:

213+1. User/group not configured in Kubernetes RBAC

214+ - Check: `kubectl get clusterrolebindings | grep <user-email>`

215+2. Token validation failed

216+ - Verify AKS Entra ID integration is enabled

217+ - Check Dashboard logs: `kubectl logs -n kubernetes-dashboard <pod-name>`

218+3. Incorrect OAuth2 Proxy configuration

219+ - Ensure `reverse-proxy: true` is set

220+ - Verify issuer URL matches your tenant

221+

222+**Groups not included in token**

223+

224+To include groups in the token:

225+1. In Entra ID App Registration, go to **Token configuration**

226+2. Add **groups claim** and select security groups

227+3. Or edit the manifest and add: `"groupMembershipClaims": "SecurityGroup"`

228+4. For 200+ groups, ensure scope includes `User.Read` for group overage handling

229+5. Verify groups appear in token: check OAuth2 Proxy logs

230+

231+**Session expires too quickly**

232+

233+Configure cookie expiration:

234+```yaml

235+extraArgs:

236+ cookie-expire: "24h"

237+ cookie-refresh: "1h"

238+```

239+

240+### Using Workload Identity (Passwordless)

241+

242+For production environments, use Workload Identity instead of client secrets:

243+

244+```yaml

245+config:

246+ clientID: "YOUR_CLIENT_ID"

247+ secretKeys: # Exclude client-secret

248+ - client-id

249+ - cookie-secret

250+ cookieSecret: "YOUR_COOKIE_SECRET"

251+

252+serviceAccount:

253+ annotations:

254+ azure.workload.identity/client-id: YOUR_CLIENT_ID

255+ azure.workload.identity/tenant-id: YOUR_TENANT_ID

256+

257+podLabels:

258+ azure.workload.identity/use: "true"

259+

260+alphaConfig:

261+ enabled: true

262+ configData:

263+ providers:

264+ - id: azure-entra

265+ provider: entra-id

266+ clientID: YOUR_CLIENT_ID

267+ oidcConfig:

268+ issuerURL: https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0

269+ # ... other config

270+ entraIdConfig:

271+ federatedTokenAuth: true

272+```

273+

274+This requires:

275+- AKS with OIDC issuer and Workload Identity enabled

276+- Federated identity credential configured in Entra ID App Registration

277+- Service account annotated with `azure.workload.identity/client-id`

278+

279+For detailed Workload Identity setup instructions, see the [Workload Identity section](../providers/ms_entra_id.md#workload-identity) in the Microsoft Entra ID provider documentation.

280+

281+## Integration with Other Providers

282+

283+While this guide focuses on Azure Entra ID, Kubernetes Dashboard can be integrated with other OAuth2 providers supported by OAuth2 Proxy. The key requirements remain the same:

284+

285+1. **Authorization Header**: Pass the bearer token via the `Authorization` header

286+2. **RBAC Configuration**: Configure Kubernetes RBAC for your authentication provider's users/groups

287+3. **Buffer Sizes**: Ensure adequate buffer sizes for tokens (especially important for OIDC providers)

288+

289+For provider-specific configuration examples, see the [OAuth Provider Configuration](../providers/index.md) documentation.

docs/docs/configuration/integrations/nginx.mdnew file+190

@@ -0,0 +1,190 @@

1+---

2+id: nginx

3+title: Nginx

4+---

5+

6+Configure OAuth2 Proxy with Nginx using the `auth_request` directive. Includes examples for both standalone Nginx configurations and Kubernetes ingress-nginx with annotations.

7+

8+**Key features:**

9+- Support for `auth_request` directive

10+- Kubernetes Ingress annotations

11+- Multi-part cookie handling for large tokens

12+- Session refresh support

13+

14+## Configuring for use with the Nginx `auth_request` directive

15+

16+**This option requires `--reverse-proxy` option to be set.**

17+

18+The [Nginx `auth_request` directive](http://nginx.org/en/docs/http/ngx_http_auth_request_module.html) allows Nginx to authenticate requests via the oauth2-proxy's `/auth` endpoint, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the request through. For example:

19+

20+```nginx

21+server {

22+ listen 443 ssl;

23+ server_name ...;

24+ include ssl/ssl.conf;

25+

26+ location /oauth2/ {

27+ proxy_pass http://127.0.0.1:4180;

28+ proxy_set_header Host $host;

29+ proxy_set_header X-Real-IP $remote_addr;

30+ proxy_set_header X-Auth-Request-Redirect $request_uri;

31+ # or, if you are handling multiple domains:

32+ # proxy_set_header X-Auth-Request-Redirect $scheme://$host$request_uri;

33+ }

34+ location = /oauth2/auth {

35+ proxy_pass http://127.0.0.1:4180;

36+ proxy_set_header Host $host;

37+ proxy_set_header X-Real-IP $remote_addr;

38+ proxy_set_header X-Forwarded-Uri $request_uri;

39+ # nginx auth_request includes headers but not body

40+ proxy_set_header Content-Length "";

41+ proxy_pass_request_body off;

42+ }

43+

44+ location / {

45+ auth_request /oauth2/auth;

46+ error_page 401 = @oauth2_signin;

47+

48+ # pass information via X-User and X-Email headers to backend,

49+ # requires running with --set-xauthrequest flag

50+ auth_request_set $user $upstream_http_x_auth_request_user;

51+ auth_request_set $email $upstream_http_x_auth_request_email;

52+ proxy_set_header X-User $user;

53+ proxy_set_header X-Email $email;

54+

55+ # if you enabled --pass-access-token, this will pass the token to the backend

56+ auth_request_set $token $upstream_http_x_auth_request_access_token;

57+ proxy_set_header X-Access-Token $token;

58+

59+ # if you enabled --cookie-refresh, this is needed for it to work with auth_request

60+ auth_request_set $auth_cookie $upstream_http_set_cookie;

61+ add_header Set-Cookie $auth_cookie;

62+

63+ # Large OIDC tokens can make the session cookie exceed the 4KB limit,

64+ # causing OAuth2 Proxy to split the cookie into multiple parts.

65+ # Nginx normally only copies the first `Set-Cookie` header from the auth_request to the response,

66+ # so extract the second part when using the default cookie name, `_oauth2_proxy`.

67+ auth_request_set $auth_cookie_upstream_1 $upstream_cookie__oauth2_proxy_1;

68+

69+ # Extract the Cookie attributes from the first Set-Cookie header and append them

70+ # to the second part ($upstream_cookie_* variables only contain the raw cookie content)

71+ if ($auth_cookie ~* "(; .*)") {

72+ set $auth_cookie_0 $auth_cookie;

73+ set $auth_cookie_1 "_oauth2_proxy_1=$auth_cookie_upstream_1$1";

74+ }

75+

76+ # Send both Set-Cookie headers now if there was a second part

77+ if ($auth_cookie_upstream_1) {

78+ add_header Set-Cookie $auth_cookie_0;

79+ add_header Set-Cookie $auth_cookie_1;

80+ }

81+

82+ proxy_pass http://backend/;

83+ # or "root /path/to/site;" or "fastcgi_pass ..." etc

84+ }

85+

86+ # Named location for handling OAuth2 sign-in redirects

87+ # This ensures the browser receives a proper 302 redirect that it will follow

88+ location @oauth2_signin {

89+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

90+ }

91+}

92+```

93+

94+### Multi-part session cookies

95+

96+The example above is ready to use with the default `--cookie-name=_oauth2_proxy` setting and handles a session split into two cookies. If you configure a custom cookie name, update both references to the second cookie part:

97+

98+| Cookie configuration | Nginx upstream cookie variable | `Set-Cookie` name |

99+| --- | --- | --- |

100+| Default (`_oauth2_proxy`) | `$upstream_cookie__oauth2_proxy_1` | `_oauth2_proxy_1=` |

101+| `--cookie-name=my_cookie` | `$upstream_cookie_my_cookie_1` | `my_cookie_1=` |

102+

103+For example, with `--cookie-name=my_cookie`, change the relevant lines to:

104+

105+```nginx

106+auth_request_set $auth_cookie_upstream_1 $upstream_cookie_my_cookie_1;

107+set $auth_cookie_1 "my_cookie_1=$auth_cookie_upstream_1$1";

108+```

109+

110+If a session is split into more than two cookies, repeat the extraction for each additional numeric suffix. For consistently large sessions, prefer `--session-store-type=redis` so only a small session ticket is stored in the browser cookie.

111+

112+### Understanding the `error_page` redirect pattern

113+

114+The `auth_request` directive expects the authentication endpoint (`/oauth2/auth`) to return:

115+- **2xx**: Request is authenticated, allow access

116+- **401 or 403**: Request is not authenticated, deny access

117+

118+When a 401 is returned, nginx triggers the `error_page` directive. The recommended pattern uses a **named location** (`@oauth2_signin`) that returns a proper **302 redirect**:

119+

120+```nginx

121+error_page 401 = @oauth2_signin;

122+

123+location @oauth2_signin {

124+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

125+}

126+```

127+

128+:::warning Avoid `error_page 401 =403` with sign_in

129+Some older configurations use `error_page 401 =403 /oauth2/sign_in`. While this works for displaying the sign-in page, it returns a **403 status code** with a `Location` header. Browsers do not automatically follow redirects on 403 responses, which can cause issues when using `--skip-provider-button=true` (users see a "Found." link instead of being automatically redirected).

130+

131+The named location pattern above ensures the browser receives a standard **302 redirect** that works correctly with all oauth2-proxy configurations.

132+:::

133+

134+### Browser vs API Routes

135+

136+:::important When to use redirects

137+Redirecting authentication failures (302 to `/oauth2/sign_in`) should **only be used for browser-facing routes**. API or machine clients should receive a plain 401/403 response without redirect.

138+:::

139+

140+#### Browser-facing routes (HTML, UI)

141+

142+For interactive browser routes where users should be redirected to sign in:

143+

144+```nginx

145+location / {

146+ auth_request /oauth2/auth;

147+ error_page 401 = @oauth2_signin;

148+ proxy_pass http://backend/;

149+}

150+

151+location @oauth2_signin {

152+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

153+}

154+```

155+

156+#### API / Machine routes (no redirect)

157+

158+For API endpoints where clients expect a 401/403 status code (not a redirect):

159+

160+```nginx

161+location /api/ {

162+ auth_request /oauth2/auth;

163+ error_page 401 =401; # Pass through the 401 status

164+ proxy_pass http://backend/;

165+}

166+```

167+

168+This ensures:

169+- ✅ Browsers get a redirect and smooth login flow

170+- ✅ API clients fail fast with appropriate HTTP status codes

171+- ✅ `/oauth2/auth` remains a pure boolean oracle (2xx/401)

172+

173+When you use ingress-nginx in Kubernetes, you can configure the same behavior with the following annotations on your Ingress resource:

174+

175+```yaml

176+nginx.ingress.kubernetes.io/auth-url: "https://<oauth2-proxy-fqdn>/oauth2/auth"

177+nginx.ingress.kubernetes.io/auth-signin: "https://<oauth2-proxy-fqdn>/oauth2/start?rd=$escaped_request_uri"

178+```

179+

180+This minimal configuration works for standard authentication flows. Lua/cookie handling is only needed for advanced scenarios (e.g., multi-part cookies, custom session logic). See the official ingress-nginx example: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/.

181+

182+It is recommended to use `--session-store-type=redis` when expecting large sessions/OIDC tokens (_e.g._ with MS Azure).

183+

184+:::tip Kubernetes Dashboard with Azure Entra ID

185+For a complete example of integrating oauth2-proxy with Kubernetes Dashboard on AKS using Azure Entra ID, including RBAC configuration and troubleshooting, see the [Kubernetes Dashboard on AKS](../providers/ms_entra_id.md#kubernetes-dashboard-on-aks) section in the Microsoft Entra ID provider documentation.

186+:::

187+

188+:::note

189+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

190+:::

docs/docs/configuration/integrations/traefik.mdnew file+192

@@ -0,0 +1,192 @@

1+---

2+id: traefik

3+title: Traefik

4+---

5+

6+Set up OAuth2 Proxy with Traefik v2 using the `ForwardAuth` middleware. Includes examples for both error-based redirects and static upstream configurations.

7+

8+**Key features:**

9+- ForwardAuth middleware integration

10+- Error middleware for 401 redirects

11+- Static upstream configuration (202 responses)

12+- Dynamic file configuration examples

13+

14+

15+## Configuring for use with the Traefik (v2) `ForwardAuth` middleware

16+

17+**This option requires `--reverse-proxy` option to be set.**

18+

19+### ForwardAuth with 401 errors middleware

20+

21+The [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) allows Traefik to authenticate requests via the oauth2-proxy's `/oauth2/auth` endpoint on every request, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the whole request through. For example, on Dynamic File (YAML) Configuration:

22+

23+```yaml

24+http:

25+ routers:

26+ a-service:

27+ rule: "Host(`a-service.example.com`)"

28+ service: a-service-backend

29+ middlewares:

30+ - oauth-errors

31+ - oauth-auth

32+ tls:

33+ certResolver: default

34+ domains:

35+ - main: "example.com"

36+ sans:

37+ - "*.example.com"

38+ oauth:

39+ rule: "Host(`a-service.example.com`, `oauth.example.com`) && PathPrefix(`/oauth2/`)"

40+ middlewares:

41+ - auth-headers

42+ service: oauth-backend

43+ tls:

44+ certResolver: default

45+ domains:

46+ - main: "example.com"

47+ sans:

48+ - "*.example.com"

49+

50+ services:

51+ a-service-backend:

52+ loadBalancer:

53+ servers:

54+ - url: http://172.16.0.2:7555

55+ oauth-backend:

56+ loadBalancer:

57+ servers:

58+ - url: http://172.16.0.1:4180

59+

60+ middlewares:

61+ auth-headers:

62+ headers:

63+ sslRedirect: true

64+ stsSeconds: 315360000

65+ browserXssFilter: true

66+ contentTypeNosniff: true

67+ forceSTSHeader: true

68+ sslHost: example.com

69+ stsIncludeSubdomains: true

70+ stsPreload: true

71+ frameDeny: true

72+ oauth-auth:

73+ forwardAuth:

74+ address: https://oauth.example.com/oauth2/auth

75+ trustForwardHeader: true

76+ oauth-errors:

77+ errors:

78+ status:

79+ - "401-403"

80+ service: oauth-backend

81+ query: "/oauth2/sign_in?rd={url}"

82+ statusRewrites:

83+ "401": 302

84+```

85+

86+:::caution Troubleshooting: Browser shows "Found." instead of redirecting

87+When using the Errors middleware without `statusRewrites`, the redirect response from oauth2-proxy can be served within the original 401/403 status context. This causes some browsers to display a "Found." link instead of automatically following the redirect to the identity provider.

88+

89+Adding `statusRewrites` to rewrite `401 -> 302` ensures the browser treats the response as a proper redirect and follows it automatically.

90+:::

91+

92+### ForwardAuth with static upstreams configuration

93+

94+Redirect to sign_in functionality provided without the use of `errors` middleware with [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) pointing to oauth2-proxy service's `/` endpoint

95+

96+**Following options need to be set on `oauth2-proxy`:**

97+- `--upstream=static://202`: Configures a static response for authenticated sessions

98+- `--reverse-proxy=true`: Enables the use of `X-Forwarded-*` headers to determine redirects correctly

99+

100+```yaml

101+http:

102+ routers:

103+ a-service-route-1:

104+ rule: "Host(`a-service.example.com`, `b-service.example.com`) && PathPrefix(`/`)"

105+ service: a-service-backend

106+ middlewares:

107+ - oauth-auth-redirect # redirects all unauthenticated to oauth2 signin

108+ tls:

109+ certResolver: default

110+ domains:

111+ - main: "example.com"

112+ sans:

113+ - "*.example.com"

114+ a-service-route-2:

115+ rule: "Host(`a-service.example.com`) && PathPrefix(`/no-auto-redirect`)"

116+ service: a-service-backend

117+ middlewares:

118+ - oauth-auth-wo-redirect # unauthenticated session will return a 401

119+ tls:

120+ certResolver: default

121+ domains:

122+ - main: "example.com"

123+ sans:

124+ - "*.example.com"

125+ services-oauth2-route:

126+ rule: "Host(`a-service.example.com`, `b-service.example.com`) && PathPrefix(`/oauth2/`)"

127+ middlewares:

128+ - auth-headers

129+ service: oauth-backend

130+ tls:

131+ certResolver: default

132+ domains:

133+ - main: "example.com"

134+ sans:

135+ - "*.example.com"

136+ oauth2-proxy-route:

137+ rule: "Host(`oauth.example.com`) && PathPrefix(`/`)"

138+ middlewares:

139+ - auth-headers

140+ service: oauth-backend

141+ tls:

142+ certResolver: default

143+ domains:

144+ - main: "example.com"

145+ sans:

146+ - "*.example.com"

147+

148+ services:

149+ a-service-backend:

150+ loadBalancer:

151+ servers:

152+ - url: http://172.16.0.2:7555

153+ b-service-backend:

154+ loadBalancer:

155+ servers:

156+ - url: http://172.16.0.3:7555

157+ oauth-backend:

158+ loadBalancer:

159+ servers:

160+ - url: http://172.16.0.1:4180

161+

162+ middlewares:

163+ auth-headers:

164+ headers:

165+ sslRedirect: true

166+ stsSeconds: 315360000

167+ browserXssFilter: true

168+ contentTypeNosniff: true

169+ forceSTSHeader: true

170+ sslHost: example.com

171+ stsIncludeSubdomains: true

172+ stsPreload: true

173+ frameDeny: true

174+ oauth-auth-redirect:

175+ forwardAuth:

176+ address: https://oauth.example.com/

177+ trustForwardHeader: true

178+ authResponseHeaders:

179+ - X-Auth-Request-Access-Token

180+ - Authorization

181+ oauth-auth-wo-redirect:

182+ forwardAuth:

183+ address: https://oauth.example.com/oauth2/auth

184+ trustForwardHeader: true

185+ authResponseHeaders:

186+ - X-Auth-Request-Access-Token

187+ - Authorization

188+```

189+

190+:::note

191+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

192+:::

docs/docs/configuration/overview.md+59−13

@@ -66,11 +66,11 @@ An example [oauth2-proxy.cfg](https://github.com/oauth2-proxy/oauth2-proxy/blob/

6666

6767### Command Line Options

6868

69−| Flag | Description |

70−| ----------- | -------------------- |

71−| `--config` | path to config file |

72−| `--version` | print version string |

73−

69+| Flag | Description |

70+| ---------------- | ------------------------------------------------------- |

71+| `--config` | path to config file |

72+| `--config-test` | test configuration and exit (for CI/CD validation) |

73+| `--version` | print version string |

7474

7575### General Provider Options

7676

@@ -83,7 +83,7 @@ Provider specific options can be found on their respective subpages.

8383| flag: `--approval-prompt`<br/>toml: `approval_prompt` | string | OAuth approval_prompt | `"force"` |

8484| flag: `--backend-logout-url`<br/>toml: `backend_logout_url` | string | URL to perform backend logout, if you use `{id_token}` in the url it will be replaced by the actual `id_token` of the user session | |

8585| flag: `--client-id`<br/>toml: `client_id` | string | the OAuth Client ID, e.g. `"123456.apps.googleusercontent.com"` | |

86−| flag: `--client-secret-file`<br/>toml: `client_secret_file` | string | the file with OAuth Client Secret | |

86+| flag: `--client-secret-file`<br/>toml: `client_secret_file` | string | the file with OAuth Client Secret. The file must contain the secret only, with no trailing newline | |

8787| flag: `--client-secret`<br/>toml: `client_secret` | string | the OAuth Client Secret | |

8888| flag: `--code-challenge-method`<br/>toml: `code_challenge_method` | string | use PKCE code challenges with the specified method. Either 'plain' or 'S256' (recommended) | |

8989| flag: `--insecure-oidc-allow-unverified-email`<br/>toml: `insecure_oidc_allow_unverified_email` | bool | don't fail if an email address in an id_token is not verified | false |

@@ -99,10 +99,11 @@ Provider specific options can be found on their respective subpages.

9999| flag: `--oidc-groups-claim`<br/>toml: `oidc_groups_claim` | string | which OIDC claim contains the user groups | `"groups"` |

100100| flag: `--oidc-issuer-url`<br/>toml: `oidc_issuer_url` | string | the OpenID Connect issuer URL, e.g. `"https://accounts.google.com"` | |

101101| flag: `--oidc-jwks-url`<br/>toml: `oidc_jwks_url` | string | OIDC JWKS URI for token verification; required if OIDC discovery is disabled and public key files are not provided | |

102−| flag: `--oidc-public-key-file`<br/>toml: `oidc_public_key_files` | string | Path to public key file in PEM format to use for verifying JWT tokens (may be given multiple times). Required if OIDC discovery is disabled na JWKS URL isn't provided | string \| list |

102+| flag: `--oidc-public-key-file`<br/>toml: `oidc_public_key_files` | string | Path to public key file in PEM format to use for verifying JWT tokens (may be given multiple times). Required if OIDC discovery is disabled na JWKS URL isn't provided | |

103+| flag: `--oidc-enabled-signing-alg`<br/>toml: `oidc_enabled_signing_algs` | string \| list | List of allowed JWT signing algorithms. When oidc discovery is enabled, the effective set is the intersection between this list and the provider's discovered supported algorithms. | |

103104| flag: `--profile-url`<br/>toml: `profile_url` | string | Profile access endpoint | |

104105| flag: `--prompt`<br/>toml: `prompt` | string | [OIDC prompt](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest); if present, `approval-prompt` is ignored | `""` |

105−| flag: `--provider-ca-file`<br/>toml: `provider_ca_files` | string \| list | Paths to CA certificates that should be used when connecting to the provider. If not specified, the default Go trust sources are used instead. |

106+| flag: `--provider-ca-file`<br/>toml: `provider_ca_files` | string \| list | Paths to CA certificates that should be used when connecting to the provider. If not specified, the default Go trust sources are used instead. | |

106107| flag: `--provider-display-name`<br/>toml: `provider_display_name` | string | Override the provider's name with the given string; used for the sign-in page | (depends on provider) |

107108| flag: `--provider`<br/>toml: `provider` | string | OAuth provider | google |

108109| flag: `--pubjwk-url`<br/>toml: `pubjwk_url` | string | JWK pubkey access endpoint: required by login.gov | |

@@ -120,6 +121,7 @@ Provider specific options can be found on their respective subpages.

120121| flag: `--cookie-csrf-expire`<br/>toml: `cookie_csrf_expire` | duration | expire timeframe for CSRF cookie | 15m |

121122| flag: `--cookie-csrf-per-request`<br/>toml:`cookie_csrf_per_request` | bool | Enable having different CSRF cookies per request, making it possible to have parallel requests. | false |

122123| flag: `--cookie-csrf-per-request-limit`<br/>toml: `cookie_csrf_per_request_limit` | int | Sets a limit on the number of CSRF requests cookies that oauth2-proxy will create. The oldest cookie will be removed. Useful if users end up with 431 Request headers too large status codes. Only effective if --cookie-csrf-per-request is true | "infinite" |

124+| flag: `--cookie-csrf-samesite`<br/>toml: `cookie_csrf_samesite` | string | set SameSite CSRF cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`). When using the default setting, the CSRF cookie samesite value is taken from the session cookie configuration. | `""` |

123125| flag: `--cookie-domain`<br/>toml: `cookie_domains` | string \| list | Optional cookie domains to force cookies to (e.g. `.yourcompany.com`). The longest domain matching the request's host will be used (or the shortest cookie domain if there is no match). | |

124126| flag: `--cookie-expire`<br/>toml: `cookie_expire` | duration | expire timeframe for cookie. If set to 0, cookie becomes a session-cookie which will expire when the browser is closed. | 168h0m0s |

125127| flag: `--cookie-httponly`<br/>toml: `cookie_httponly` | bool | set HttpOnly cookie flag | true |

@@ -128,7 +130,7 @@ Provider specific options can be found on their respective subpages.

128130| flag: `--cookie-refresh`<br/>toml: `cookie_refresh` | duration | refresh the cookie after this duration; `0` to disable; not supported by all providers&nbsp;[^1] | |

129131| flag: `--cookie-samesite`<br/>toml: `cookie_samesite` | string | set SameSite cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`). | `""` |

130132| flag: `--cookie-secret`<br/>toml: `cookie_secret` | string | the seed string for secure cookies (optionally base64 encoded) | |

131−| flag: `--cookie-secret-file`<br/>toml: `cookie_secret_file` | string | For defining a separate cookie secret file to read the encryption key from | |

133+| flag: `--cookie-secret-file`<br/>toml: `cookie_secret_file` | string | File containing the cookie secret (must be raw binary, exactly 16, 24, or 32 bytes). Use dd if=/dev/urandom bs=32 count=1 > cookie.secret to generate | |

132134| flag: `--cookie-secure`<br/>toml: `cookie_secure` | bool | set [secure (HTTPS only) cookie flag](https://owasp.org/www-community/controls/SecureFlag) | true |

133135

134136[^1]: The following providers support `--cookie-refresh`: ADFS, Azure, GitLab, Google, Keycloak and all other Identity Providers which support the full [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens)

@@ -174,7 +176,7 @@ Provider specific options can be found on their respective subpages.

174176| Flag / Config Field | Type | Description | Default |

175177| ----------------------------------------------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------- | ------- |

176178| flag: `--banner`<br/>toml: `banner` | string | custom (html) banner string. Use `"-"` to disable default banner. | |

177−| flag: `--custom-sign-in-logo`<br/>toml: `custom_sign_in_logo` | string | path or a URL to an custom image for the sign_in page logo. Use `"-"` to disable default logo. |

179+| flag: `--custom-sign-in-logo`<br/>toml: `custom_sign_in_logo` | string | path or a URL to an custom image for the sign_in page logo. Use `"-"` to disable default logo. | |

178180| flag: `--custom-templates-dir`<br/>toml: `custom_templates_dir` | string | path to custom html templates | |

179181| flag: `--display-htpasswd-form`<br/>toml: `display_htpasswd_form` | bool | display username / password login form if an htpasswd file is provided | true |

180182| flag: `--footer`<br/>toml: `footer` | string | custom (html) footer string. Use `"-"` to disable default footer. (Can be used to obfuscate the version) | |

@@ -191,6 +193,10 @@ Provider specific options can be found on their respective subpages.

191193

192194### Proxy Options

193195

196+:::warning

197+When `--reverse-proxy` is enabled, configure `--trusted-proxy-ip` to the IPs or CIDR ranges of the reverse proxies that are allowed to send `X-Forwarded-*` headers. If you leave it unset, OAuth2 Proxy currently trusts all source IPs for backwards compatibility, which means a client that can reach OAuth2 Proxy directly may be able to spoof forwarded headers.

198+:::

199+

194200| Flag / Config Field | Type | Description | Default |

195201| ----------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |

196202| flag: `--allow-query-semicolons`<br/>toml: `allow_query_semicolons` | bool | allow the use of semicolons in query args ([required for some legacy applications](https://github.com/golang/go/issues/25192)) | `false` |

@@ -209,10 +215,11 @@ Provider specific options can be found on their respective subpages.

209215| flag: `--redirect-url`<br/>toml: `redirect_url` | string | the OAuth Redirect URL, e.g. `"https://internalapp.yourcompany.com/oauth2/callback"` | |

210216| flag: `--relative-redirect-url`<br/>toml: `relative_redirect_url` | bool | allow relative OAuth Redirect URL.` | false |

211217| flag: `--reverse-proxy`<br/>toml: `reverse_proxy` | bool | are we running behind a reverse proxy, controls whether headers like X-Real-IP are accepted and allows X-Forwarded-\{Proto,Host,Uri\} headers to be used on redirect selection | false |

218+| flag: `--trusted-proxy-ip`<br/>toml: `trusted_proxy_ips` | string \| list | list of IPs or CIDR ranges allowed to supply `X-Forwarded-*` headers when `--reverse-proxy` is enabled. If not set, OAuth2 Proxy preserves backwards compatibility by trusting all source IPs (`0.0.0.0/0`, `::/0`) and logs a warning at startup. Configure this to your reverse proxy addresses to prevent forwarded header spoofing. | `"0.0.0.0/0", "::/0"` |

212219| flag: `--signature-key`<br/>toml: `signature_key` | string | GAP-Signature request signature key (algorithm:secretkey) | |

213220| flag: `--skip-auth-preflight`<br/>toml: `skip_auth_preflight` | bool | will skip authentication for OPTIONS requests | false |

214−| flag: `--skip-auth-regex`<br/>toml: `skip_auth_regex` | string \| list | (DEPRECATED for `--skip-auth-route`) bypass authentication for requests paths that match (may be given multiple times) | |

215−| flag: `--skip-auth-route`<br/>toml: `skip_auth_routes` | string \| list | bypass authentication for requests that match the method & path. Format: method=path_regex OR method!=path_regex. For all methods: path_regex OR !=path_regex | |

221+| flag: `--skip-auth-regex`<br/>toml: `skip_auth_regex` | string \| list | (DEPRECATED for `--skip-auth-route`) bypass authentication for requests paths that match (may be given multiple times). Path matching is performed against the normalized path only; fragment identifiers (`#`) and their URL-encoded form (`%23`) are stripped before evaluation. | |

222+| flag: `--skip-auth-route`<br/>toml: `skip_auth_routes` | string \| list | bypass authentication for requests that match the method & path. Format: method=path_regex OR method!=path_regex. For all methods: path_regex OR !=path_regex. Path matching is performed against the normalized path only; fragment identifiers (`#`) and their URL-encoded form (`%23`) are stripped before evaluation. | |

216223| flag: `--skip-jwt-bearer-tokens`<br/>toml: `skip_jwt_bearer_tokens` | bool | will skip requests that have verified JWT bearer tokens (the token must have [`aud`](https://en.wikipedia.org/wiki/JSON_Web_Token#Standard_fields) that matches this client id or one of the extras from `extra-jwt-issuers`) | false |

217224| flag: `--skip-provider-button`<br/>toml: `skip_provider_button` | bool | will skip sign-in-page to directly reach the next step: oauth/start | false |

218225| flag: `--ssl-insecure-skip-verify`<br/>toml: `ssl_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS providers | false |

@@ -225,7 +232,7 @@ Provider specific options can be found on their respective subpages.

225232

226233| Flag / Config Field | Type | Description | Default |

227234| ------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |

228−| flag: `--http-address`<br/>toml: `http_address` | string | `[http://]<addr>:<port>` or `unix://<path>` or `fd:<int>` (case insensitive) to listen on for HTTP clients. Square brackets are required for ipv6 address, e.g. `http://[::1]:4180` | `"127.0.0.1:4180"` |

235+| flag: `--http-address`<br/>toml: `http_address` | string | `[http://]<addr>:<port>` or `unix://<path>` or `fd:<int>` (case insensitive) to listen on for HTTP clients. Unix sockets are created with default system umask mode, which can be overridden, e.g. `unix://my-socket,mode=0777`. Square brackets are required for ipv6 address, e.g. `http://[::1]:4180` | `"127.0.0.1:4180"` |

229236| flag: `--https-address`<br/>toml: `https_address` | string | `[https://]<addr>:<port>` to listen on for HTTPS clients. Square brackets are required for ipv6 address, e.g. `https://[::1]:443` | `":443"` |

230237| flag: `--metrics-address`<br/>toml: `metrics_address` | string | the address prometheus metrics will be scraped from | `""` |

231238| flag: `--metrics-secure-address`<br/>toml: `metrics_secure_address` | string | the address prometheus metrics will be scraped from if using HTTPS | `""` |

@@ -244,6 +251,7 @@ Provider specific options can be found on their respective subpages.

244251| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

245252| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

246253| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

254+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. | |

247255| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

248256| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

249257| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

@@ -261,9 +269,47 @@ Provider specific options can be found on their respective subpages.

261269| flag: `--pass-host-header`<br/>toml: `pass_host_header` | bool | pass the request Host Header to upstream | true |

262270| flag: `--proxy-websockets`<br/>toml: `proxy_websockets` | bool | enables WebSocket proxying | true |

263271| flag: `--ssl-upstream-insecure-skip-verify`<br/>toml: `ssl_upstream_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS upstreams | false |

272+| flag: `--disable-keep-alives`<br/>toml: `disable_keep_alives` | bool | disable HTTP keep-alive connections to the upstream server | false |

264273| flag: `--upstream-timeout`<br/>toml: `upstream_timeout` | duration | maximum amount of time the server will wait for a response from the upstream | 30s |

265274| flag: `--upstream`<br/>toml: `upstreams` | string \| list | the http url(s) of the upstream endpoint, file:// paths for static files or `static://<status_code>` for static response. Routing is based on the path | |

266275

276+## Configuration Validation

277+

278+The `--config-test` flag validates your configuration file without starting the proxy server. This is useful for:

279+- **CI/CD pipelines**: Pre-deployment validation

280+- **Configuration management**: Testing before applying changes

281+- **Debugging**: Verifying syntax and required fields

282+

283+### Usage

284+

285+```bash

286+# Test legacy config

287+oauth2-proxy --config /etc/oauth2-proxy.cfg --config-test

288+

289+# Test alpha config

290+oauth2-proxy --config /etc/core.cfg --alpha-config /etc/alpha.yaml --config-test

291+

292+# CI/CD pre-deployment check

293+# Returns with exit code 1 if any validation errors occur

294+oauth2-proxy --config new-config.cfg --config-test

295+```

296+

297+### Exit Codes

298+

299+- **0**: Configuration is valid ✅

300+- **1**: Configuration is invalid (errors printed to stderr) ❌

301+

302+### Validation Coverage

303+

304+The `--config-test` flag performs the **same comprehensive validation** as normal startup, including:

305+- Required fields (client ID, client secret, cookie secret, etc.)

306+- Syntax validation (TOML/YAML parsing)

307+- Provider configuration

308+- Upstream server definitions

309+- Session store connectivity (e.g., Redis network checks if configured)

310+

311+**Note**: Cannot be combined with `--convert-config-to-alpha`.

312+

267313## Upstreams Configuration

268314

269315`oauth2-proxy` supports having multiple upstreams, and has the option to pass requests on to HTTP(S) servers, unix socket or serve static files from the file system.

docs/docs/configuration/providers/atlassian.mdnew file+26

@@ -0,0 +1,26 @@

1+---

2+id: atlassian

3+title: Atlassian Cloud

4+---

5+

6+1. Create an OAuth 2.0 integration in the [Atlassian developer console](https://developer.atlassian.com/console/myapps/).

7+2. Under **Permissions**, add the User identity API with the `read:me` scope.

8+3. Under **Authorization**, set the callback URL to `https://<proxy_host>/oauth2/callback`.

9+4. Copy the client ID and secret from **Settings**.

10+5. Run the proxy with:

11+

12+```shell

13+ --provider=atlassian

14+ --client-id=<client ID>

15+ --client-secret=<secret>

16+ --redirect-url=https://<proxy_host>/oauth2/callback

17+ --cookie-secret=<cookie secret>

18+```

19+

20+A new app works only for the account that created it. Enable sharing under **Distribution** to let other users sign in.

21+Atlassian then admits only accounts with access to the Atlassian site the app is installed on; others are refused at

22+the consent screen.

23+

24+The proxy reads the user's email from `https://api.atlassian.com/me`. Restricting access further is supported by

25+[email](index.md#email-authentication). With `--cookie-refresh` set, the proxy re-validates the token against `/me` on

26+that interval.

docs/docs/configuration/providers/cisco_duo.mdnew file+44

@@ -0,0 +1,44 @@

1+---

2+id: cisco_duo

3+title: Cisco Duo

4+---

5+

6+Cisco Duo SSO can be configured with OAuth2 Proxy using the OIDC provider.

7+

8+1. Create a new **Generic OIDC Relying Party - Single Sign-On** application in the Duo Admin Portal

9+2. Configure OAuth2 Proxy with the following options:

10+

11+```

12+provider = "oidc"

13+provider_display_name = "Duo SSO"

14+scope = "openid email profile"

15+pass_access_token = true

16+code_challenge_method = "S256"

17+```

18+

19+3. Configure Provider endpoints. Copy the following values from the corresponding fields in the Duo Admin Portal:

20+

21+```

22+# Copy from "Client ID" field

23+client_id = "XXXXXXXX"

24+

25+# Copy from "Client Secret" field

26+client_secret = "XXXXXXXX"

27+

28+# Copy from "Issuer" field

29+oidc_issuer_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx"

30+

31+# Copy from "JWKS URL" field

32+oidc_jwks_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/jwks"

33+

34+# Copy from "Token Introspection URL" field

35+validate_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/token_introspection"

36+

37+# Copy from "UserInfo" field

38+profile_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/userinfo"

39+

40+# Copy from "Token URL" field

41+redeem_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/token"

42+```

43+

44+4. Complete Configuration by filling in any remaining required fields and save your configuration.

docs/docs/configuration/providers/dtt_sso.mdnew file+45

@@ -0,0 +1,45 @@

1+---

2+id: dtt_sso

3+title: DTT SSO

4+---

5+

6+Signs users in with the DTT SSO (auth-server) using the authorization code flow and its HS256 id_token.

7+

8+1. Register a client in the auth-server config, one per protected service, with the proxy's callback as its

9+ only redirect URI:

10+

11+ ```yaml

12+ clients:

13+ redash-gate:

14+ secret: <random secret>

15+ redirect_uri: https://redash.example.com/oauth2/callback

16+ display_name: Redash

17+ ```

18+

19+2. Run the proxy with:

20+

21+ ```shell

22+ --provider=dtt-sso

23+ --client-id=redash-gate

24+ --client-secret-file=/run/secrets/client_secret

25+ --redirect-url=https://redash.example.com/oauth2/callback

26+ --cookie-secret-file=/run/secrets/cookie_secret

27+ --cookie-name=_dtt_sso_redash

28+ --cookie-refresh=5m

29+ ```

30+

31+ Give each instance its own `--cookie-name`: another oauth2-proxy setting its cookie on a parent domain

32+ (the Atlassian proxy uses `_oauth2_proxy` on `.thebestagent.pro`) would otherwise shadow this one.

33+

34+The endpoints default to `https://auth.thebestagent.pro`. For another SSO host set `--login-url`, `--redeem-url`

35+and `--validate-url` to its `/oauth/authorize`, `/oauth/token` and `/oauth/check_token`; the id_token issuer must

36+equal the login URL's origin (the SSO's `site_host`).

37+

38+The scope must stay `openid`, the only scope the SSO accepts.

39+

40+The session carries the SSO `email`, the user UUID as the user, and the SSO `role` as the only group, so

41+`--allowed-group=dtt_admin` restricts access by role. `--authenticated-emails-file` and `--email-domain` restrict

42+by email as usual.

43+

44+With `--cookie-refresh` set, the proxy refreshes the tokens on that interval and re-reads the email and role; a user

45+deleted or signed out in the SSO loses access at the next refresh.

docs/docs/configuration/providers/gitea.md+2−2

@@ -1,10 +1,10 @@

11---

22id: gitea

3−title: Gitea

3+title: Gitea / Forgejo

44---

55

66:::note

7−This is not actually its own provider. For more details and options please refer to the [GitHub Provider Options](github.md)

7+This is not actually a fully serparate provider. For more details and options please refer to the [GitHub Provider Options](github.md)

88:::

99

10101. Create a new application: `https://< your gitea host >/user/settings/applications`

docs/docs/configuration/providers/gitlab.md+1−1

@@ -8,7 +8,7 @@ title: GitLab

88| Flag | Toml Field | Type | Description | Default |

99| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

1010| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11−| `--gitlab-projects` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

1212

1313## Usage

1414

docs/docs/configuration/providers/google.md+16−7

@@ -5,13 +5,15 @@ title: Google (default)

55

66## Config Options

77

8−| Flag | Toml Field | Type | Description | Default |

9−| ---------------------------------------------- | -------------------------------------------- | ------ | ------------------------------------------------------------------------------------------------ | -------------------------------------------------- |

10−| `--google-admin-email` | `google_admin_email` | string | the google admin to impersonate for api calls | |

11−| `--google-group` | `google_groups` | string | restrict logins to members of this google group (may be given multiple times). If not specified and service account or default credentials are configured, all user groups will be allowed. | |

12−| `--google-service-account-json` | `google_service_account_json` | string | the path to the service account json credentials | |

13−| `--google-use-application-default-credentials` | `google_use_application_default_credentials` | bool | use application default credentials instead of service account json (i.e. GKE Workload Identity) | |

14−| `--google-target-principal` | `google_target_principal` | bool | the target principal to impersonate when using ADC | defaults to the service account configured for ADC |

8+| Flag | Toml Field | Type | Description | Default |

9+|-------------------------------------------------|----------------------------------------------| ------ |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------|

10+| `--google-admin-email` | `google_admin_email` | string | the google admin to impersonate for api calls | |

11+| `--google-group` | `google_groups` | string | restrict logins to members of this google group (may be given multiple times). If not specified and service account or default credentials are configured, all user groups will be allowed. | |

12+| `--google-service-account-json` | `google_service_account_json` | string | the path to the service account json credentials | |

13+| `--google-use-application-default-credentials` | `google_use_application_default_credentials` | bool | use application default credentials instead of service account json (i.e. GKE Workload Identity) | |

14+| `--google-target-principal` | `google_target_principal` | bool | the target principal to impersonate when using ADC | defaults to the service account configured for ADC |

15+| `--google-use-organization-id` | `google_use_organization_id` | bool | use organization id as preferred username | false |

16+| `--google-admin-api-user-scope` | `google_admin_api_user_scope` | string | the OAuth scope to use when querying the Google Admin SDK for organization id, can be 'readonly', 'user' or 'cloud'<br/> | `readonly` |

1517

1618## Usage

1719

@@ -73,3 +75,10 @@ can be leveraged through a feature called Workload Identity. Follow Google's [gu

7375to set up Workload Identity.

7476

7577When deployed outside of GCP, [Workload Identity Federation](https://cloud.google.com/docs/authentication/provide-credentials-adc#wlif) might be an option.

78+

79+##### Using Organization ID as Preferred Username (optional)

80+By default, the google provider uses the google id as username. If you would like to use an organization id instead, you can set the `google-use-organization-id` flag to true.

81+This requires that the service account used to query the Google Admin SDK has one of the following scopes granted in step 5 above:

82+- `https://www.googleapis.com/auth/admin.directory.user.readonly`,

83+- `https://www.googleapis.com/auth/admin.directory.user`

84+- `https://www.googleapis.com/auth/cloud-platform`

docs/docs/configuration/providers/index.md+4

@@ -9,9 +9,12 @@ with Redirect URI(s) for the domain you intend to run `oauth2-proxy` on.

99Valid providers are :

1010

1111- [ADFS](adfs.md)

12+- [Atlassian Cloud](atlassian.md)

1213- [Bitbucket](bitbucket.md)

1314- [Cidaas](cidaas.md)

15+- [CiscoDuo](cisco_duo.md)

1416- [DigitalOcean](digitalocean.md)

17+- [DTT SSO](dtt_sso.md)

1518- [Facebook](facebook.md)

1619- [Gitea](gitea.md)

1720- [GitHub](github.md)

@@ -25,6 +28,7 @@ Valid providers are :

2528- [Microsoft Entra ID](ms_entra_id.md)

2629- [Nextcloud](nextcloud.md)

2730- [OpenID Connect](openid_connect.md)

31+- [SourceHut](sourcehut.md)

2832

2933The provider can be selected using the `provider` configuration value, or set in the [`providers` array using AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers). However, [**the feature to implement multiple providers is not complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

3034

docs/docs/configuration/providers/ms_entra_id.md+5−1

@@ -112,7 +112,7 @@ insecure_oidc_skip_issuer_verification=true

112112```

113113`insecure_oidc_skip_issuer_verification` setting is required to disable following checks:

114114* Startup check for matching issuer URL returned from [discovery document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) with `oidc_issuer_url` setting. Required, as document's `issuer` field doesn't equal to `https://login.microsoftonline.com/common/v2.0`. See [OIDC Discovery 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation).

115−* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by diffrerent tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

115+* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by different tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

116116

117117To provide additional security, Entra ID provider performs check on the ID token's `issuer` claim to match the `https://login.microsoftonline.com/{tenant-id}/v2.0` template.

118118

@@ -195,3 +195,7 @@ scope="openid profile email User.Read"

195195entra_id_allowed_tenants=["9188040d-6c67-4c5b-b112-36a304b66dad","<my-tenant-id>"] # Allow only <my-tenant-id> and Personal MS Accounts tenant

196196email_domains="*"

197197```

198+

199+## Kubernetes Dashboard Integration

200+

201+For a complete guide on integrating oauth2-proxy with Kubernetes Dashboard on AKS using Azure Entra ID authentication, including detailed configuration examples, RBAC setup, troubleshooting, and Workload Identity setup, see the [Kubernetes Dashboard integration guide](../integrations/kubernetes-dashboard.md).

docs/docs/configuration/providers/sourcehut.md+1−1

@@ -21,5 +21,5 @@ to the appropriate URLs:

2121

2222The default configuration allows everyone with an account to authenticate.

2323Restricting access is currently only supported by

24−[email](#email-authentication).

24+[email](index.md#email-authentication).

2525

docs/docs/configuration/sessions.md+2−2

@@ -64,9 +64,9 @@ the refresh flow to get a new Access-Token. If it is longer, it might be that th

6464expired.

6565

6666The "cookie-refresh" value controls when OAuth2 Proxy tries to refresh an Access-Token. If it is set to "0", the

67−Access-Token will never be refreshed, even if it is already expired and a valid Refresh-Token is available. If set, OAuth2-Proxy will

67+Access-Token will never be refreshed, even if it is already expired and a valid Refresh-Token is available. If set, OAuth2 Proxy will

6868refresh the Access-Token after this many seconds whether it is still valid or not. According to the official OAuth2.0 specification

69−Access-Tokens are not required to follow a specific format. Therefore OAuth2-Proxy cannot check for any expiry date without an

69+Access-Tokens are not required to follow a specific format. Therefore OAuth2 Proxy cannot check for any expiry date without an

7070introspection endpoint. If an Access-Token expires and you have not set a corresponding "cookie-refresh" value, you will likely

7171encounter expiry issues.

7272

docs/docs/configuration/systemd_socket.md+8

@@ -40,4 +40,12 @@ the listener it created onto the process, starting with file descriptor 3.

4040 --client-secret=...

4141```

4242

43+## Trusted IPs

44+

45+When listening on a Unix socket, Go sets `http.Request.RemoteAddr` to `"@"` instead of the usual `"host:port"` format. This means there is no client IP available from the connection itself.

46+

47+As a result, `--trusted-ip` entries cannot match against the direct connection address for Unix socket listeners. Requests arriving over a Unix socket will never be considered "trusted" based on their `RemoteAddr`. IP-based trust decisions will still work if a trusted reverse proxy sets `X-Forwarded-For` or `X-Real-IP` headers and `--reverse-proxy=true` is configured.

48+

49+## TLS

50+

4351Currently TLS is not supported (but it's doable).

docs/docs/features/endpoints.md+27−1

@@ -5,6 +5,7 @@ title: Endpoints

55

66OAuth2 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.

77

8+- / - the proxy endpoint provides authentication and returns the appropriate 40x error if not authenticated or authorized then passes the request upstream.

89- /robots.txt - returns a 200 OK response that disallows all User-agents from all paths; see [robotstxt.org](http://www.robotstxt.org/) for more info

910- /ping - returns a 200 OK response, which is intended for use with health checks

1011- /ready - returns a 200 OK response if all the underlying connections (e.g., Redis store) are connected

@@ -14,7 +15,7 @@ OAuth2 Proxy responds directly to the following endpoints. All other endpoints w

1415- /oauth2/start - a URL that will redirect to start the OAuth cycle

1516- /oauth2/callback - the URL used at the end of the OAuth cycle. The oauth app will be configured with this as the callback url.

1617- /oauth2/userinfo - the URL is used to return user's email from the session in JSON format.

17−- /oauth2/auth - only returns a 202 Accepted response or a 401 Unauthorized response; for use with the [Nginx `auth_request` directive](../configuration/integration#configuring-for-use-with-the-nginx-auth_request-directive)

18+- /oauth2/auth - only returns a 202 Accepted response or a 401 Unauthorized response; for use with the [Nginx `auth_request` directive](../configuration/integrations/nginx)

1819- /oauth2/static/\* - stylesheets and other dependencies used in the sign_in and error pages

1920

2021### Sign out

@@ -37,6 +38,20 @@ X-Auth-Request-Redirect: https://my-oidc-provider/sign_out_page

3738

3839BEWARE that the domain you want to redirect to (`my-oidc-provider.example.com` in the example) must be added to the [`--whitelist-domain`](../configuration/overview) configuration option otherwise the redirect will be ignored. Make sure to include the actual domain and port (if needed) and not the URL (e.g "localhost:8081" instead of "http://localhost:8081").

3940

41+ID Token can be injected in the redirect url by using `{id_token}` placeholder. For example to redirect to `https://my-oidc-provider.example.com/sign_out_page?id_token_hint={id_token}&post_logout_redirect_uri=https://my-app.example.com`;

42+

43+```

44+/oauth2/sign_out?rd=https%3A%2F%2Fmy-oidc-provider.example.com%2Fsign_out_page%3Fid_token_hint%3D%7Bid_token%7D%26post_logout_redirect_uri%3Dhttps%3A%2F%2Fmy-app.example.com

45+```

46+

47+or alternatively in the header:

48+

49+```

50+GET /oauth2/sign_out HTTP/1.1

51+X-Auth-Request-Redirect: https://my-oidc-provider.example.com/sign_out_page?id_token_hint={id_token}&post_logout_redirect_uri=https://my-app.example.com

52+...

53+```

54+

4055### Auth

4156

4257This endpoint returns 202 Accepted response or a 401 Unauthorized response.

@@ -45,3 +60,14 @@ It can be configured using the following query parameters:

4560- `allowed_groups`: comma separated list of allowed groups

4661- `allowed_email_domains`: comma separated list of allowed email domains

4762- `allowed_emails`: comma separated list of allowed emails

63+

64+### Proxy (/)

65+

66+This endpoint returns the upstream response if authenticated.

67+If unauthenticated it returns a 401 Unauthorized. If the authenticatd user

68+is not in one of the allowed groups, or emails then it returns a 403 forbidden

69+

70+It can be configured using the following query parameters:

71+- `allowed_groups`: comma separated list of allowed groups

72+- `allowed_email_domains`: comma separated list of allowed email domains

73+- `allowed_emails`: comma separated list of allowed emails

docs/docs/installation.md+1−1

@@ -5,7 +5,7 @@ title: Installation

55

661. Choose how to deploy:

77

8− a. Using a [Prebuilt Binary](https://github.com/oauth2-proxy/oauth2-proxy/releases) (current release is `v7.11.0`)

8+ a. Using a [Prebuilt Binary](https://github.com/oauth2-proxy/oauth2-proxy/releases) (current release is `v7.15.4`)

99

1010 b. Using Go to install the latest release

1111 ```bash

docs/docs/welcome.md+10

@@ -21,3 +21,13 @@ A list of changes can be seen in the [CHANGELOG](https://github.com/oauth2-proxy

2121## Architecture

2222

2323

24+

25+

26+## Cloud Native Computing Foundation

27+

28+OAuth2 Proxy is a [Cloud Native Computing Foundation](https://cncf.io) Sandbox project.

29+

30+

31+

32+The Linux Foundation® (TLF) has registered trademarks and uses trademarks. For a list of TLF trademarks, see [Trademark Usage](https://www.linuxfoundation.org/legal/trademark-usage).

33+

docs/docusaurus.config.js+2−2

@@ -105,7 +105,7 @@ const config = {

105105 dropdownActiveClassDisabled: true,

106106 },

107107 {

108− href: 'https://gophers.slack.com/messages/CM2RSS25N',

108+ href: 'https://cloud-native.slack.com/archives/C098Y5URZ2N',

109109 label: 'Slack',

110110 position: 'right',

111111 },

@@ -118,7 +118,7 @@ const config = {

118118 },

119119 footer: {

120120 style: 'dark',

121− copyright: `Copyright © ${new Date().getFullYear()} OAuth2 Proxy.`,

121+ copyright: `Copyright © ${new Date().getFullYear()} OAuth2 Proxy a Series of LF Projects, LLC.<br>For website terms of use, trademark policy and other project policies please see lfprojects.org/policies/`,

122122 },

123123 prism: {

124124 theme: prismThemes.github,

docs/package.json+4−1

@@ -17,7 +17,7 @@

1717 "@docusaurus/core": "^3.3.2",

1818 "@docusaurus/preset-classic": "^3.3.2",

1919 "@docusaurus/theme-mermaid": "^3.3.2",

20− "@easyops-cn/docusaurus-search-local": "^0.52.0",

20+ "@easyops-cn/docusaurus-search-local": "^0.55.0",

2121 "@mdx-js/react": "^3.0.0",

2222 "clsx": "^2.0.0",

2323 "prism-react-renderer": "^2.3.0",

@@ -42,5 +42,8 @@

4242 },

4343 "engines": {

4444 "node": ">=18.0"

45+ },

46+ "overrides" : {

47+ "webpackbar" : "^7.0.0"

4548 }

4649}

docs/sidebars.js+20−1

@@ -22,7 +22,21 @@ const sidebars = {

2222 collapsed: false,

2323 items: [

2424 'configuration/overview',

25− 'configuration/integration',

25+ {

26+ type: 'category',

27+ label: 'Integration Guides',

28+ link: {

29+ type: 'doc',

30+ id: 'configuration/integrations/index',

31+ },

32+ items: [

33+ "configuration/integrations/nginx",

34+ "configuration/integrations/traefik",

35+ "configuration/integrations/caddy",

36+ "configuration/integrations/headlamp",

37+ "configuration/integrations/kubernetes-dashboard"

38+ ],

39+ },

2640 {

2741 type: 'category',

2842 label: 'OAuth Provider Configuration',

@@ -32,9 +46,13 @@ const sidebars = {

3246 },

3347 items: [

3448 "configuration/providers/adfs",

49+ "configuration/providers/atlassian",

3550 "configuration/providers/azure",

3651 "configuration/providers/bitbucket",

52+ "configuration/providers/cidaas",

53+ "configuration/providers/cisco_duo",

3754 "configuration/providers/digitalocean",

55+ "configuration/providers/dtt_sso",

3856 "configuration/providers/facebook",

3957 "configuration/providers/gitea",

4058 "configuration/providers/github",

@@ -47,6 +65,7 @@ const sidebars = {

4765 "configuration/providers/ms_entra_id",

4866 "configuration/providers/nextcloud",

4967 "configuration/providers/openid_connect",

68+ "configuration/providers/sourcehut"

5069 ],

5170 },

5271 'configuration/session_storage',

docs/versioned_docs/version-7.0.x/behaviour.md+1−1

@@ -3,7 +3,7 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

6+1. Any request passing through the proxy (and not matched by `--skip-auth-route`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

772. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

883. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

994. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

docs/versioned_docs/version-7.1.x/behaviour.md+1−1

@@ -3,7 +3,7 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

6+1. Any request passing through the proxy (and not matched by `--skip-auth-route`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

772. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

883. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

994. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

docs/versioned_docs/version-7.10.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.10.x/configuration/integration.md+83−15

@@ -33,9 +33,15 @@ server {

3333 proxy_pass_request_body off;

3434 }

3535

36+ # Named location for handling OAuth2 sign-in redirects

37+ # This ensures the browser receives a proper 302 redirect that it will follow

38+ location @oauth2_signin {

39+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

40+ }

41+

3642 location / {

3743 auth_request /oauth2/auth;

38− error_page 401 =403 /oauth2/sign_in;

44+ error_page 401 = @oauth2_signin;

3945

4046 # pass information via X-User and X-Email headers to backend,

4147 # requires running with --set-xauthrequest flag

@@ -77,23 +83,77 @@ server {

7783}

7884```

7985

80−When you use ingress-nginx in Kubernetes, you MUST use `kubernetes/ingress-nginx` (which includes the Lua module) and the following configuration snippet for your `Ingress`.

81−Variables set with `auth_request_set` are not `set`-able in plain nginx config when the location is processed via `proxy_pass` and then may only be processed by Lua.

82−Note that `nginxinc/kubernetes-ingress` does not include the Lua module.

86+### Understanding the `error_page` redirect pattern

87+

88+The `auth_request` directive expects the authentication endpoint (`/oauth2/auth`) to return:

89+- **2xx**: Request is authenticated, allow access

90+- **401 or 403**: Request is not authenticated, deny access

91+

92+When a 401 is returned, nginx triggers the `error_page` directive. The recommended pattern uses a **named location** (`@oauth2_signin`) that returns a proper **302 redirect**:

93+

94+

95+```nginx

96+error_page 401 = @oauth2_signin;

97+

98+location @oauth2_signin {

99+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

100+}

101+```

102+

103+:::warning Avoid `error_page 401 =403` with sign_in

104+Some older configurations use `error_page 401 =403 /oauth2/sign_in`. While this works for displaying the sign-in page, it returns a **403 status code** with a `Location` header. Browsers do not automatically follow redirects on 403 responses, which can cause issues when using `--skip-provider-button=true` (users see a "Found." link instead of being automatically redirected).

105+

106+The named location pattern above ensures the browser receives a standard **302 redirect** that works correctly with all oauth2-proxy configurations.

107+:::

108+

109+### Browser vs API Routes

110+

111+:::important When to use redirects

112+Redirecting authentication failures (302 to `/oauth2/sign_in`) should **only be used for browser-facing routes**. API or machine clients should receive a plain 401/403 response without redirect.

113+:::

114+

115+#### Browser-facing routes (HTML, UI)

116+

117+For interactive browser routes where users should be redirected to sign in:

118+

119+```nginx

120+location / {

121+ auth_request /oauth2/auth;

122+ error_page 401 = @oauth2_signin;

123+ proxy_pass http://backend/;

124+}

125+

126+location @oauth2_signin {

127+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

128+}

129+```

130+

131+#### API / Machine routes (no redirect)

132+

133+For API endpoints where clients expect a 401/403 status code (not a redirect):

134+

135+```nginx

136+location /api/ {

137+ auth_request /oauth2/auth;

138+ error_page 401 =401; # Pass through the 401 status

139+ proxy_pass http://backend/;

140+}

141+```

142+

143+This ensures:

144+- ✅ Browsers get a redirect and smooth login flow

145+- ✅ API clients fail fast with appropriate HTTP status codes

146+- ✅ `/oauth2/auth` remains a pure boolean oracle (2xx/401)

147+

148+When you use ingress-nginx in Kubernetes, you can configure the same behavior with the following annotations on your Ingress resource:

83149

84150```yaml

85−nginx.ingress.kubernetes.io/auth-response-headers: Authorization

86−nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2/start?rd=$escaped_request_uri

87−nginx.ingress.kubernetes.io/auth-url: https://$host/oauth2/auth

88−nginx.ingress.kubernetes.io/configuration-snippet: |

89− auth_request_set $name_upstream_1 $upstream_cookie_name_1;

90−

91− access_by_lua_block {

92− if ngx.var.name_upstream_1 ~= "" then

93− ngx.header["Set-Cookie"] = "name_1=" .. ngx.var.name_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")

94− end

95− }

151+nginx.ingress.kubernetes.io/auth-url: "https://<oauth2-proxy-fqdn>/oauth2/auth"

152+nginx.ingress.kubernetes.io/auth-signin: "https://<oauth2-proxy-fqdn>/oauth2/start?rd=$escaped_request_uri"

96153```

154+

155+This minimal configuration works for standard authentication flows. Lua/cookie handling is only needed for advanced scenarios (e.g., multi-part cookies, custom session logic). See the official ingress-nginx example: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/.

156+

97157It is recommended to use `--session-store-type=redis` when expecting large sessions/OIDC tokens (_e.g._ with MS Azure).

98158

99159You have to substitute *name* with the actual cookie name you configured via --cookie-name parameter. If you don't set a custom cookie name the variable should be "$upstream_cookie__oauth2_proxy_1" instead of "$upstream_cookie_name_1" and the new cookie-name should be "_oauth2_proxy_1=" instead of "name_1=".

@@ -165,8 +225,16 @@ http:

165225 - "401-403"

166226 service: oauth-backend

167227 query: "/oauth2/sign_in?rd={url}"

228+ statusRewrites:

229+ "401": 302

168230```

169231

232+:::info Troubleshooting: Browser shows "Found." instead of redirecting

233+When using the Errors middleware without `statusRewrites`, the redirect response from oauth2-proxy can be served within the original 401/403 status context. This causes some browsers to display a "Found." link instead of automatically following the redirect to the identity provider.

234+

235+Adding `statusRewrites` to rewrite `401 -> 302` ensures the browser treats the response as a proper redirect and follows it automatically.

236+:::

237+

170238### ForwardAuth with static upstreams configuration

171239

172240Redirect to sign_in functionality provided without the use of `errors` middleware with [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) pointing to oauth2-proxy service's `/` endpoint

docs/versioned_docs/version-7.10.x/configuration/overview.md+1

@@ -241,6 +241,7 @@ Provider specific options can be found on their respective subpages.

241241| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

242242| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

243243| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

244+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. |

244245| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

245246| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

246247| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

docs/versioned_docs/version-7.10.x/configuration/providers/gitlab.md+1−1

@@ -8,7 +8,7 @@ title: GitLab

88| Flag | Toml Field | Type | Description | Default |

99| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

1010| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11−| `--gitlab-projects` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

1212

1313## Usage

1414

docs/versioned_docs/version-7.10.x/configuration/providers/ms_entra_id.md+1−1

@@ -112,7 +112,7 @@ insecure_oidc_skip_issuer_verification=true

112112```

113113`insecure_oidc_skip_issuer_verification` setting is required to disable following checks:

114114* Startup check for matching issuer URL returned from [discovery document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) with `oidc_issuer_url` setting. Required, as document's `issuer` field doesn't equal to `https://login.microsoftonline.com/common/v2.0`. See [OIDC Discovery 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation).

115−* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by diffrerent tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

115+* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by different tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

116116

117117To provide additional security, Entra ID provider performs check on the ID token's `issuer` claim to match the `https://login.microsoftonline.com/{tenant-id}/v2.0` template.

118118

docs/versioned_docs/version-7.11.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.11.x/configuration/integration.md+83−15

@@ -33,9 +33,15 @@ server {

3333 proxy_pass_request_body off;

3434 }

3535

36+ # Named location for handling OAuth2 sign-in redirects

37+ # This ensures the browser receives a proper 302 redirect that it will follow

38+ location @oauth2_signin {

39+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

40+ }

41+

3642 location / {

3743 auth_request /oauth2/auth;

38− error_page 401 =403 /oauth2/sign_in;

44+ error_page 401 = @oauth2_signin;

3945

4046 # pass information via X-User and X-Email headers to backend,

4147 # requires running with --set-xauthrequest flag

@@ -77,23 +83,77 @@ server {

7783}

7884```

7985

80−When you use ingress-nginx in Kubernetes, you MUST use `kubernetes/ingress-nginx` (which includes the Lua module) and the following configuration snippet for your `Ingress`.

81−Variables set with `auth_request_set` are not `set`-able in plain nginx config when the location is processed via `proxy_pass` and then may only be processed by Lua.

82−Note that `nginxinc/kubernetes-ingress` does not include the Lua module.

86+### Understanding the `error_page` redirect pattern

87+

88+The `auth_request` directive expects the authentication endpoint (`/oauth2/auth`) to return:

89+- **2xx**: Request is authenticated, allow access

90+- **401 or 403**: Request is not authenticated, deny access

91+

92+When a 401 is returned, nginx triggers the `error_page` directive. The recommended pattern uses a **named location** (`@oauth2_signin`) that returns a proper **302 redirect**:

93+

94+

95+```nginx

96+error_page 401 = @oauth2_signin;

97+

98+location @oauth2_signin {

99+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

100+}

101+```

102+

103+:::warning Avoid `error_page 401 =403` with sign_in

104+Some older configurations use `error_page 401 =403 /oauth2/sign_in`. While this works for displaying the sign-in page, it returns a **403 status code** with a `Location` header. Browsers do not automatically follow redirects on 403 responses, which can cause issues when using `--skip-provider-button=true` (users see a "Found." link instead of being automatically redirected).

105+

106+The named location pattern above ensures the browser receives a standard **302 redirect** that works correctly with all oauth2-proxy configurations.

107+:::

108+

109+### Browser vs API Routes

110+

111+:::important When to use redirects

112+Redirecting authentication failures (302 to `/oauth2/sign_in`) should **only be used for browser-facing routes**. API or machine clients should receive a plain 401/403 response without redirect.

113+:::

114+

115+#### Browser-facing routes (HTML, UI)

116+

117+For interactive browser routes where users should be redirected to sign in:

118+

119+```nginx

120+location / {

121+ auth_request /oauth2/auth;

122+ error_page 401 = @oauth2_signin;

123+ proxy_pass http://backend/;

124+}

125+

126+location @oauth2_signin {

127+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

128+}

129+```

130+

131+#### API / Machine routes (no redirect)

132+

133+For API endpoints where clients expect a 401/403 status code (not a redirect):

134+

135+```nginx

136+location /api/ {

137+ auth_request /oauth2/auth;

138+ error_page 401 =401; # Pass through the 401 status

139+ proxy_pass http://backend/;

140+}

141+```

142+

143+This ensures:

144+- ✅ Browsers get a redirect and smooth login flow

145+- ✅ API clients fail fast with appropriate HTTP status codes

146+- ✅ `/oauth2/auth` remains a pure boolean oracle (2xx/401)

147+

148+When you use ingress-nginx in Kubernetes, you can configure the same behavior with the following annotations on your Ingress resource:

83149

84150```yaml

85−nginx.ingress.kubernetes.io/auth-response-headers: Authorization

86−nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2/start?rd=$escaped_request_uri

87−nginx.ingress.kubernetes.io/auth-url: https://$host/oauth2/auth

88−nginx.ingress.kubernetes.io/configuration-snippet: |

89− auth_request_set $name_upstream_1 $upstream_cookie_name_1;

90−

91− access_by_lua_block {

92− if ngx.var.name_upstream_1 ~= "" then

93− ngx.header["Set-Cookie"] = "name_1=" .. ngx.var.name_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")

94− end

95− }

151+nginx.ingress.kubernetes.io/auth-url: "https://<oauth2-proxy-fqdn>/oauth2/auth"

152+nginx.ingress.kubernetes.io/auth-signin: "https://<oauth2-proxy-fqdn>/oauth2/start?rd=$escaped_request_uri"

96153```

154+

155+This minimal configuration works for standard authentication flows. Lua/cookie handling is only needed for advanced scenarios (e.g., multi-part cookies, custom session logic). See the official ingress-nginx example: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/.

156+

97157It is recommended to use `--session-store-type=redis` when expecting large sessions/OIDC tokens (_e.g._ with MS Azure).

98158

99159You have to substitute *name* with the actual cookie name you configured via --cookie-name parameter. If you don't set a custom cookie name the variable should be "$upstream_cookie__oauth2_proxy_1" instead of "$upstream_cookie_name_1" and the new cookie-name should be "_oauth2_proxy_1=" instead of "name_1=".

@@ -165,8 +225,16 @@ http:

165225 - "401-403"

166226 service: oauth-backend

167227 query: "/oauth2/sign_in?rd={url}"

228+ statusRewrites:

229+ "401": 302

168230```

169231

232+:::info Troubleshooting: Browser shows "Found." instead of redirecting

233+When using the Errors middleware without `statusRewrites`, the redirect response from oauth2-proxy can be served within the original 401/403 status context. This causes some browsers to display a "Found." link instead of automatically following the redirect to the identity provider.

234+

235+Adding `statusRewrites` to rewrite `401 -> 302` ensures the browser treats the response as a proper redirect and follows it automatically.

236+:::

237+

170238### ForwardAuth with static upstreams configuration

171239

172240Redirect to sign_in functionality provided without the use of `errors` middleware with [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) pointing to oauth2-proxy service's `/` endpoint

docs/versioned_docs/version-7.11.x/configuration/overview.md+1

@@ -244,6 +244,7 @@ Provider specific options can be found on their respective subpages.

244244| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

245245| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

246246| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

247+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. |

247248| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

248249| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

249250| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

docs/versioned_docs/version-7.11.x/configuration/providers/gitlab.md+1−1

@@ -8,7 +8,7 @@ title: GitLab

88| Flag | Toml Field | Type | Description | Default |

99| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

1010| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11−| `--gitlab-projects` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

1212

1313## Usage

1414

docs/versioned_docs/version-7.11.x/configuration/providers/index.md+1

@@ -24,6 +24,7 @@ Valid providers are :

2424- [Microsoft Entra ID](ms_entra_id.md)

2525- [Nextcloud](nextcloud.md)

2626- [OpenID Connect](openid_connect.md)

27+- [SourceHut](sourcehut.md)

2728

2829The provider can be selected using the `provider` configuration value, or set in the [`providers` array using AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers). However, [**the feature to implement multiple providers is not complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

2930

docs/versioned_docs/version-7.11.x/configuration/providers/ms_entra_id.md+1−1

@@ -112,7 +112,7 @@ insecure_oidc_skip_issuer_verification=true

112112```

113113`insecure_oidc_skip_issuer_verification` setting is required to disable following checks:

114114* Startup check for matching issuer URL returned from [discovery document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) with `oidc_issuer_url` setting. Required, as document's `issuer` field doesn't equal to `https://login.microsoftonline.com/common/v2.0`. See [OIDC Discovery 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation).

115−* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by diffrerent tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

115+* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by different tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

116116

117117To provide additional security, Entra ID provider performs check on the ID token's `issuer` claim to match the `https://login.microsoftonline.com/{tenant-id}/v2.0` template.

118118

docs/versioned_docs/version-7.11.x/configuration/providers/sourcehut.md+1−1

@@ -21,5 +21,5 @@ to the appropriate URLs:

2121

2222The default configuration allows everyone with an account to authenticate.

2323Restricting access is currently only supported by

24−[email](#email-authentication).

24+[email](index.md#email-authentication).

2525

docs/versioned_docs/version-7.12.x/behaviour.mdnew file+26

@@ -0,0 +1,26 @@

1+---

2+id: behaviour

3+title: Behaviour

4+---

5+

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

10+

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.12.x/community/contribution.mdnew file+89

@@ -0,0 +1,89 @@

1+---

2+id: contribution

3+title: Contribution Guide

4+---

5+

6+We track bugs and issues using Github.

7+

8+If you find a bug, please open an Issue. When opening an Issue or Pull Request please follow the preconfigured template and take special note of the checkboxes.

9+

10+If you want to fix a bug, add a new feature or extend existing functionality, please create a fork, create a feature branch and open a PR back to this repo.

11+Please mention open bug issue number(s) within your PR if applicable.

12+

13+We suggest using [Visual Studio Code](https://code.visualstudio.com/docs/languages/go) with the official [Go for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=golang.go) extension.

14+

15+

16+# Go version

17+

18+This project is currently still using go 1.22. You can follow the installation guide for go [here.](https://go.dev/doc/install) And you can find go version 1.22 in the archived section [here.](https://go.dev/dl/)

19+

20+# Preparing your fork

21+Clone your fork, create a feature branch and update the depedencies to get started.

22+```bash

23+git clone git@github.com:<YOUR_FORK>/oauth2-proxy

24+cd oauth2-proxy

25+git branch feature/<BRANCH_NAME>

26+git push --set-upstream origin feature/<BRANCH_NAME>

27+go mod download

28+```

29+

30+

31+# Testing / Debugging

32+For starting oauth2-proxy locally open the debugging tab and create the `launch.json` and select `Go: Launch Package`.

33+

34+

35+```json

36+{

37+ "version": "0.2.0",

38+ "configurations": [

39+ {

40+ "name": "Launch OAuth2-Proxy with Dex",

41+ "type": "go",

42+ "request": "launch",

43+ "mode": "auto",

44+ "program": "${workspaceFolder}",

45+ "args": [

46+ "--config",

47+ // The following configuration contains settings for a locally deployed

48+ // upstream and dex as an idetity provider

49+ "contrib/local-environment/oauth2-proxy.cfg"

50+ ]

51+ },

52+ {

53+ "name": "Launch OAuth2-Proxy with Keycloak",

54+ "type": "go",

55+ "request": "launch",

56+ "mode": "auto",

57+ "program": "${workspaceFolder}",

58+ "args": [

59+ "--config",

60+ // The following configuration contains settings for a locally deployed

61+ // upstream and keycloak as an idetity provider

62+ "contrib/local-environment/oauth2-proxy-keycloak.cfg"

63+ ]

64+ }

65+ ]

66+}

67+```

68+

69+Before you can start your local version of oauth2-proxy, you will have to use the provided docker compose files to start a local upstream service and identity provider. We suggest using [httpbin](https://hub.docker.com/r/kennethreitz/httpbin) as your upstream for testing as it allows for request and response introspection of all things HTTP.

70+

71+Inside the `contrib/local-environment` directory you can use the `Makefile` for

72+starting different example setups:

73+

74+- Dex as your IdP: `make up` or `make down`

75+- Dex as your IdP using the alpha-config: `make alpha-config-up`

76+- Keycloak as your IdP: `make keycloak-up`

77+- Dex as your IdP & nginx reverse proxy: `make nginx-up`

78+- and many more...

79+

80+Check out the `Makefile` to see what is available.

81+

82+The username and password for all setups is usually `admin@example.com` and `password`.

83+

84+The docker compose setups expose the services with a dynamic reverse DNS resolver: localtest.me

85+

86+- OAuth2-Proxy: http://oauth2-proxy.localtest.me:4180

87+- Upstream: http://httpbin.localtest.me:8080

88+- Dex: http://dex.localtest.me:5556

89+

docs/versioned_docs/version-7.12.x/community/security.mdnew file+49

@@ -0,0 +1,49 @@

1+---

2+id: security

3+title: Security

4+---

5+

6+:::note

7+OAuth2 Proxy is a community project.

8+Maintainers do not work on this project full time, and as such,

9+while we endeavour to respond to disclosures as quickly as possible,

10+this may take longer than in projects with corporate sponsorship.

11+:::

12+

13+## Security Disclosures

14+

15+:::important

16+If you believe you have found a vulnerability within OAuth2 Proxy or any of its

17+dependencies, please do NOT open an issue or PR on GitHub, please do NOT post

18+any details publicly.

19+:::

20+

21+Security disclosures MUST be done in private.

22+If you have found an issue that you would like to bring to the attention of the

23+maintenance team for OAuth2 Proxy, please compose an email and send it to the

24+list of maintainers in our [MAINTAINERS](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/MAINTAINERS) file.

25+

26+Please include as much detail as possible.

27+Ideally, your disclosure should include:

28+- A reproducible case that can be used to demonstrate the exploit

29+- How you discovered this vulnerability

30+- A potential fix for the issue (if you have thought of one)

31+- Versions affected (if not present in master)

32+- Your GitHub ID

33+

34+### How will we respond to disclosures?

35+

36+We use [GitHub Security Advisories](https://docs.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories)

37+to privately discuss fixes for disclosed vulnerabilities.

38+If you include a GitHub ID with your disclosure we will add you as a collaborator

39+for the advisory so that you can join the discussion and validate any fixes

40+we may propose.

41+

42+For minor issues and previously disclosed vulnerabilities (typically for

43+dependencies), we may use regular PRs for fixes and forego the security advisory.

44+

45+Once a fix has been agreed upon, we will merge the fix and create a new release.

46+If we have multiple security issues in flight simultaneously, we may delay

47+merging fixes until all patches are ready.

48+We may also backport the fix to previous releases,

49+but this will be at the discretion of the maintainers.

docs/versioned_docs/version-7.12.x/configuration/alpha_config.mdnew file+565

@@ -0,0 +1,565 @@

1+---

2+id: alpha-config

3+title: Alpha Configuration

4+---

5+

6+:::warning

7+This page contains documentation for alpha features.

8+We reserve the right to make breaking changes to the features detailed within this page with no notice.

9+

10+Options described in this page may be changed, removed, renamed or moved without prior warning.

11+Please beware of this before you use alpha configuration options.

12+:::

13+

14+This page details a set of **alpha** configuration options in a new format.

15+Going forward we are intending to add structured configuration in YAML format to

16+replace the existing TOML based configuration file and flags.

17+

18+Below is a reference for the structure of the configuration, with

19+[AlphaOptions](#alphaoptions) as the root of the configuration.

20+

21+When using alpha configuration, your config file will look something like below:

22+

23+```yaml

24+upstreams:

25+ - id: ...

26+ ...: ...

27+injectRequestHeaders:

28+ - name: ...

29+ ...: ...

30+injectResponseHeaders:

31+ - name: ...

32+ ...: ...

33+```

34+

35+Please browse the [reference](#configuration-reference) below for the structure

36+of the new configuration format.

37+

38+## Using Alpha Configuration

39+

40+To use the new **alpha** configuration, generate a YAML file based on the format

41+described in the [reference](#configuration-reference) below.

42+

43+Provide the path to this file using the `--alpha-config` flag.

44+

45+:::note

46+When using the `--alpha-config` flag, some options are no longer available.

47+See [removed options](#removed-options) below for more information.

48+:::

49+

50+### Converting configuration to the new structure

51+

52+Before adding the new `--alpha-config` option, start OAuth2 Proxy using the

53+`convert-config-to-alpha` flag to convert existing configuration to the new format.

54+

55+```bash

56+oauth2-proxy --convert-config-to-alpha --config ./path/to/existing/config.cfg

57+```

58+

59+This will convert any options supported by the new format to YAML and print the

60+new configuration to `STDOUT`.

61+

62+Copy this to a new file, remove any options from your existing configuration

63+noted in [removed options](#removed-options) and then start OAuth2 Proxy using

64+the new config.

65+

66+```bash

67+oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

68+```

69+

70+## Using ENV variables in the alpha configuration

71+

72+The alpha package supports the use of environment variables in place of yaml keys, allowing sensitive values to be pulled from somewhere other than the yaml file.

73+When using environment variables, your yaml will look like this:

74+

75+```yaml

76+ providers:

77+ - provider: azure

78+ clientSecret: ${CLIENT_SECRET}

79+ ...

80+```

81+Where CLIENT_SECRET is an environment variable.

82+More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

83+

84+## Removed options

85+

86+The following flags/options and their respective environment variables are no

87+longer available when using alpha configuration:

88+

89+<!-- Legacy Upstream FlagSet -->

90+- `flush-interval`/`flush_interval`

91+- `pass-host-header`/`pass_host_header`

92+- `proxy-websockets`/`proxy_websockets`

93+- `ssl-upstream-insecure-skip-verify`/`ssl_upstream_insecure_skip_verify`

94+- `upstream`/`upstreams`

95+

96+<!-- Legacy Headers FlagSet -->

97+- `pass-basic-auth`/`pass_basic_auth`

98+- `pass-access-token`/`pass_access_token`

99+- `pass-user-headers`/`pass_user_headers`

100+- `pass-authorization-header`/`pass_authorization_header`

101+- `set-basic-auth`/`set_basic_auth`

102+- `set-xauthrequest`/`set_xauthrequest`

103+- `set-authorization-header`/`set_authorization_header`

104+- `prefer-email-to-user`/`prefer_email_to_user`

105+- `basic-auth-password`/`basic_auth_password`

106+- `skip-auth-strip-headers`/`skip_auth_strip_headers`

107+

108+<!-- Legacy provider FlagSet -->

109+- `client-id`/`client_id`

110+- `client-secret`/`client_secret`, and `client-secret-file`/`client_secret_file`

111+- `provider`

112+- `provider-display-name`/`provider_display_name`

113+- `provider-ca-file`/`provider_ca_files`

114+- `login-url`/`login_url`

115+- `redeem-url`/`redeem_url`

116+- `profile-url`/`profile_url`

117+- `resource`

118+- `validate-url`/`validate_url`

119+- `scope`

120+- `prompt`

121+- `approval-prompt`/`approval_prompt`

122+- `acr-values`/`acr_values`

123+- `user-id-claim`/`user_id_claim`

124+- `allowed-group`/`allowed_groups`

125+- `allowed-role`/`allowed_roles`

126+- `jwt-key`/`jwt_key`

127+- `jwt-key-file`/`jwt_key_file`

128+- `pubjwk-url`/`pubjwk_url`

129+

130+and all provider-specific options, i.e. any option whose name includes `oidc`,

131+`azure`, `bitbucket`, `github`, `gitlab`, `google` or `keycloak`. Attempting to

132+use any of these options via flags or via config when `--alpha-config` is

133+set will result in an error.

134+

135+:::important

136+You must remove these options before starting OAuth2 Proxy with `--alpha-config`

137+:::

138+

139+## Configuration Reference

140+

141+<!--- THIS FILE IS AUTOGENERATED!!! DO NOT EDIT!!! -->

142+

143+### ADFSOptions

144+

145+(**Appears on:** [Provider](#provider))

146+

147+

148+

149+| Field | Type | Description |

150+| ----- | ---- | ----------- |

151+| `skipScope` | _bool_ | Skip adding the scope parameter in login request<br/>Default value is 'false' |

152+

153+### AlphaOptions

154+

155+AlphaOptions contains alpha structured configuration options.

156+Usage of these options allows users to access alpha features that are not

157+available as part of the primary configuration structure for OAuth2 Proxy.

158+

159+:::warning

160+The options within this structure are considered alpha.

161+They may change between releases without notice.

162+:::

163+

164+| Field | Type | Description |

165+| ----- | ---- | ----------- |

166+| `upstreamConfig` | _[UpstreamConfig](#upstreamconfig)_ | UpstreamConfig is used to configure upstream servers.<br/>Once a user is authenticated, requests to the server will be proxied to<br/>these upstream servers based on the path mappings defined in this list. |

167+| `injectRequestHeaders` | _[[]Header](#header)_ | InjectRequestHeaders is used to configure headers that should be added<br/>to requests to upstream servers.<br/>Headers may source values from either the authenticated user's session<br/>or from a static secret value. |

168+| `injectResponseHeaders` | _[[]Header](#header)_ | InjectResponseHeaders is used to configure headers that should be added<br/>to responses from the proxy.<br/>This is typically used when using the proxy as an external authentication<br/>provider in conjunction with another proxy such as NGINX and its<br/>auth_request module.<br/>Headers may source values from either the authenticated user's session<br/>or from a static secret value. |

169+| `server` | _[Server](#server)_ | Server is used to configure the HTTP(S) server for the proxy application.<br/>You may choose to run both HTTP and HTTPS servers simultaneously.<br/>This can be done by setting the BindAddress and the SecureBindAddress simultaneously.<br/>To use the secure server you must configure a TLS certificate and key. |

170+| `metricsServer` | _[Server](#server)_ | MetricsServer is used to configure the HTTP(S) server for metrics.<br/>You may choose to run both HTTP and HTTPS servers simultaneously.<br/>This can be done by setting the BindAddress and the SecureBindAddress simultaneously.<br/>To use the secure server you must configure a TLS certificate and key. |

171+| `providers` | _[Providers](#providers)_ | Providers is used to configure your provider. **Multiple-providers is not<br/>yet working.** [This feature is tracked in<br/>#925](https://github.com/oauth2-proxy/oauth2-proxy/issues/926) |

172+

173+### AzureOptions

174+

175+(**Appears on:** [Provider](#provider))

176+

177+

178+

179+| Field | Type | Description |

180+| ----- | ---- | ----------- |

181+| `tenant` | _string_ | Tenant directs to a tenant-specific or common (tenant-independent) endpoint<br/>Default value is 'common' |

182+| `graphGroupField` | _string_ | GraphGroupField configures the group field to be used when building the groups list from Microsoft Graph<br/>Default value is 'id' |

183+

184+### BitbucketOptions

185+

186+(**Appears on:** [Provider](#provider))

187+

188+

189+

190+| Field | Type | Description |

191+| ----- | ---- | ----------- |

192+| `team` | _string_ | Team sets restrict logins to members of this team |

193+| `repository` | _string_ | Repository sets restrict logins to user with access to this repository |

194+

195+### ClaimSource

196+

197+(**Appears on:** [HeaderValue](#headervalue))

198+

199+ClaimSource allows loading a header value from a claim within the session

200+

201+| Field | Type | Description |

202+| ----- | ---- | ----------- |

203+| `claim` | _string_ | Claim is the name of the claim in the session that the value should be<br/>loaded from. Available claims: `access_token` `id_token` `created_at`<br/>`expires_on` `refresh_token` `email` `user` `groups` `preferred_username`. |

204+| `prefix` | _string_ | Prefix is an optional prefix that will be prepended to the value of the<br/>claim if it is non-empty. |

205+| `basicAuthPassword` | _[SecretSource](#secretsource)_ | BasicAuthPassword converts this claim into a basic auth header.<br/>Note the value of claim will become the basic auth username and the<br/>basicAuthPassword will be used as the password value. |

206+

207+### Duration

208+#### (`string` alias)

209+

210+(**Appears on:** [Upstream](#upstream))

211+

212+Duration is as string representation of a period of time.

213+A duration string is a is a possibly signed sequence of decimal numbers,

214+each with optional fraction and a unit suffix, such as "300ms", "-1.5h" or "2h45m".

215+Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".

216+

217+### GitHubOptions

218+

219+(**Appears on:** [Provider](#provider))

220+

221+

222+

223+| Field | Type | Description |

224+| ----- | ---- | ----------- |

225+| `org` | _string_ | Org sets restrict logins to members of this organisation |

226+| `team` | _string_ | Team sets restrict logins to members of this team |

227+| `repo` | _string_ | Repo sets restrict logins to collaborators of this repository |

228+| `token` | _string_ | Token is the token to use when verifying repository collaborators<br/>it must have push access to the repository |

229+| `users` | _[]string_ | Users allows users with these usernames to login<br/>even if they do not belong to the specified org and team or collaborators |

230+

231+### GitLabOptions

232+

233+(**Appears on:** [Provider](#provider))

234+

235+

236+

237+| Field | Type | Description |

238+| ----- | ---- | ----------- |

239+| `group` | _[]string_ | Group sets restrict logins to members of this group |

240+| `projects` | _[]string_ | Projects restricts logins to members of these projects |

241+

242+### GoogleOptions

243+

244+(**Appears on:** [Provider](#provider))

245+

246+

247+

248+| Field | Type | Description |

249+| ----- | ---- | ----------- |

250+| `group` | _[]string_ | Groups sets restrict logins to members of this Google group |

251+| `adminEmail` | _string_ | AdminEmail is the Google admin to impersonate for api calls |

252+| `serviceAccountJson` | _string_ | ServiceAccountJSON is the path to the service account json credentials |

253+| `useApplicationDefaultCredentials` | _bool_ | UseApplicationDefaultCredentials is a boolean whether to use Application Default Credentials instead of a ServiceAccountJSON |

254+| `targetPrincipal` | _string_ | TargetPrincipal is the Google Service Account used for Application Default Credentials |

255+

256+### Header

257+

258+(**Appears on:** [AlphaOptions](#alphaoptions))

259+

260+Header represents an individual header that will be added to a request or

261+response header.

262+

263+| Field | Type | Description |

264+| ----- | ---- | ----------- |

265+| `name` | _string_ | Name is the header name to be used for this set of values.<br/>Names should be unique within a list of Headers. |

266+| `preserveRequestValue` | _bool_ | PreserveRequestValue determines whether any values for this header<br/>should be preserved for the request to the upstream server.<br/>This option only applies to injected request headers.<br/>Defaults to false (headers that match this header will be stripped). |

267+| `values` | _[[]HeaderValue](#headervalue)_ | Values contains the desired values for this header |

268+

269+### HeaderValue

270+

271+(**Appears on:** [Header](#header))

272+

273+HeaderValue represents a single header value and the sources that can

274+make up the header value

275+

276+| Field | Type | Description |

277+| ----- | ---- | ----------- |

278+| `value` | _[]byte_ | Value expects a base64 encoded string value. |

279+| `fromEnv` | _string_ | FromEnv expects the name of an environment variable. |

280+| `fromFile` | _string_ | FromFile expects a path to a file containing the secret value. |

281+| `claim` | _string_ | Claim is the name of the claim in the session that the value should be<br/>loaded from. Available claims: `access_token` `id_token` `created_at`<br/>`expires_on` `refresh_token` `email` `user` `groups` `preferred_username`. |

282+| `prefix` | _string_ | Prefix is an optional prefix that will be prepended to the value of the<br/>claim if it is non-empty. |

283+| `basicAuthPassword` | _[SecretSource](#secretsource)_ | BasicAuthPassword converts this claim into a basic auth header.<br/>Note the value of claim will become the basic auth username and the<br/>basicAuthPassword will be used as the password value. |

284+

285+### KeycloakOptions

286+

287+(**Appears on:** [Provider](#provider))

288+

289+

290+

291+| Field | Type | Description |

292+| ----- | ---- | ----------- |

293+| `groups` | _[]string_ | Group enables to restrict login to members of indicated group |

294+| `roles` | _[]string_ | Role enables to restrict login to users with role (only available when using the keycloak-oidc provider) |

295+

296+### LoginGovOptions

297+

298+(**Appears on:** [Provider](#provider))

299+

300+

301+

302+| Field | Type | Description |

303+| ----- | ---- | ----------- |

304+| `jwtKey` | _string_ | JWTKey is a private key in PEM format used to sign JWT, |

305+| `jwtKeyFile` | _string_ | JWTKeyFile is a path to the private key file in PEM format used to sign the JWT |

306+| `pubjwkURL` | _string_ | PubJWKURL is the JWK pubkey access endpoint |

307+

308+### LoginURLParameter

309+

310+(**Appears on:** [Provider](#provider))

311+

312+LoginURLParameter is the configuration for a single query parameter that

313+can be passed through from the `/oauth2/start` endpoint to the IdP login

314+URL. The "default" option specifies the default value or values (if any)

315+that will be passed to the IdP for this parameter, and "allow" is a list

316+of options for ways in which this parameter can be set or overridden via

317+the query string to `/oauth2/start`.

318+If _only_ a default is specified and no "allow" then the parameter is

319+effectively fixed - the default value will always be used and anything

320+passed to the start URL will be ignored. If _only_ "allow" is specified

321+but no default then the parameter will only be passed on to the IdP if

322+the caller provides it, and no value will be sent otherwise.

323+

324+Examples:

325+

326+# A parameter whose value is fixed

327+

328+```

329+name: organization

330+default:

331+- myorg

332+```

333+

334+A parameter that is not passed by default, but may be set to one of a

335+fixed set of values

336+

337+```

338+name: prompt

339+allow:

340+- value: login

341+- value: consent

342+- value: select_account

343+```

344+

345+A parameter that is passed by default but may be overridden by one of

346+a fixed set of values

347+

348+```

349+name: prompt

350+default: ["login"]

351+allow:

352+- value: consent

353+- value: select_account

354+```

355+

356+A parameter that may be overridden, but only by values that match a

357+regular expression. For example to restrict `login_hint` to email

358+addresses in your organization's domain:

359+

360+```

361+name: login_hint

362+allow:

363+- pattern: '^[^@]*@example\.com$'

364+# this allows at most one "@" sign, and requires "example.com" domain.

365+```

366+

367+Note that the YAML rules around exactly which characters are allowed

368+and/or require escaping in different types of string literals are

369+convoluted. For regular expressions the single quoted form is simplest

370+as backslash is not considered to be an escape character. Alternatively

371+use the "chomped block" format `|-`:

372+

373+```

374+ - pattern: |-

375+ ^[^@]*@example\.com$

376+

377+```

378+

379+The hyphen is important, a `|` block would have a trailing newline

380+character.

381+

382+| Field | Type | Description |

383+| ----- | ---- | ----------- |

384+| `name` | _string_ | Name specifies the name of the query parameter. |

385+| `default` | _[]string_ | _(Optional)_ Default specifies a default value or values that will be<br/>passed to the IdP if not overridden. |

386+| `allow` | _[[]URLParameterRule](#urlparameterrule)_ | _(Optional)_ Allow specifies rules about how the default (if any) may be<br/>overridden via the query string to `/oauth2/start`. Only<br/>values that match one or more of the allow rules will be<br/>forwarded to the IdP. |

387+

388+### MicrosoftEntraIDOptions

389+

390+(**Appears on:** [Provider](#provider))

391+

392+

393+

394+| Field | Type | Description |

395+| ----- | ---- | ----------- |

396+| `allowedTenants` | _[]string_ | AllowedTenants is a list of allowed tenants. In case of multi-tenant apps, incoming tokens are<br/>issued by different issuers and OIDC issuer verification needs to be disabled.<br/>When not specified, all tenants are allowed. Redundant for single-tenant apps<br/>(regular ID token validation matches the issuer). |

397+| `federatedTokenAuth` | _bool_ | FederatedTokenAuth enable oAuth2 client authentication with federated token projected<br/>by Entra Workload Identity plugin, instead of client secret. |

398+

399+### OIDCOptions

400+

401+(**Appears on:** [Provider](#provider))

402+

403+

404+

405+| Field | Type | Description |

406+| ----- | ---- | ----------- |

407+| `issuerURL` | _string_ | IssuerURL is the OpenID Connect issuer URL<br/>eg: https://accounts.google.com |

408+| `insecureAllowUnverifiedEmail` | _bool_ | InsecureAllowUnverifiedEmail prevents failures if an email address in an id_token is not verified<br/>default set to 'false' |

409+| `insecureSkipIssuerVerification` | _bool_ | InsecureSkipIssuerVerification skips verification of ID token issuers. When false, ID Token Issuers must match the OIDC discovery URL<br/>default set to 'false' |

410+| `insecureSkipNonce` | _bool_ | InsecureSkipNonce skips verifying the ID Token's nonce claim that must match<br/>the random nonce sent in the initial OAuth flow. Otherwise, the nonce is checked<br/>after the initial OAuth redeem & subsequent token refreshes.<br/>default set to 'true'<br/>Warning: In a future release, this will change to 'false' by default for enhanced security. |

411+| `skipDiscovery` | _bool_ | SkipDiscovery allows to skip OIDC discovery and use manually supplied Endpoints<br/>default set to 'false' |

412+| `jwksURL` | _string_ | JwksURL is the OpenID Connect JWKS URL<br/>eg: https://www.googleapis.com/oauth2/v3/certs |

413+| `publicKeyFiles` | _[]string_ | PublicKeyFiles is a list of paths pointing to public key files in PEM format to use<br/>for verifying JWT tokens |

414+| `emailClaim` | _string_ | EmailClaim indicates which claim contains the user email,<br/>default set to 'email' |

415+| `groupsClaim` | _string_ | GroupsClaim indicates which claim contains the user groups<br/>default set to 'groups' |

416+| `userIDClaim` | _string_ | UserIDClaim indicates which claim contains the user ID<br/>default set to 'email' |

417+| `audienceClaims` | _[]string_ | AudienceClaim allows to define any claim that is verified against the client id<br/>By default `aud` claim is used for verification. |

418+| `extraAudiences` | _[]string_ | ExtraAudiences is a list of additional audiences that are allowed<br/>to pass verification in addition to the client id. |

419+

420+### Provider

421+

422+(**Appears on:** [Providers](#providers))

423+

424+Provider holds all configuration for a single provider

425+

426+| Field | Type | Description |

427+| ----- | ---- | ----------- |

428+| `clientID` | _string_ | ClientID is the OAuth Client ID that is defined in the provider<br/>This value is required for all providers. |

429+| `clientSecret` | _string_ | ClientSecret is the OAuth Client Secret that is defined in the provider<br/>This value is required for all providers. |

430+| `clientSecretFile` | _string_ | ClientSecretFile is the name of the file<br/>containing the OAuth Client Secret, it will be used if ClientSecret is not set. |

431+| `keycloakConfig` | _[KeycloakOptions](#keycloakoptions)_ | KeycloakConfig holds all configurations for Keycloak provider. |

432+| `azureConfig` | _[AzureOptions](#azureoptions)_ | AzureConfig holds all configurations for Azure provider. |

433+| `microsoftEntraIDConfig` | _[MicrosoftEntraIDOptions](#microsoftentraidoptions)_ | MicrosoftEntraIDConfig holds all configurations for Entra ID provider. |

434+| `ADFSConfig` | _[ADFSOptions](#adfsoptions)_ | ADFSConfig holds all configurations for ADFS provider. |

435+| `bitbucketConfig` | _[BitbucketOptions](#bitbucketoptions)_ | BitbucketConfig holds all configurations for Bitbucket provider. |

436+| `githubConfig` | _[GitHubOptions](#githuboptions)_ | GitHubConfig holds all configurations for GitHubC provider. |

437+| `gitlabConfig` | _[GitLabOptions](#gitlaboptions)_ | GitLabConfig holds all configurations for GitLab provider. |

438+| `googleConfig` | _[GoogleOptions](#googleoptions)_ | GoogleConfig holds all configurations for Google provider. |

439+| `oidcConfig` | _[OIDCOptions](#oidcoptions)_ | OIDCConfig holds all configurations for OIDC provider<br/>or providers utilize OIDC configurations. |

440+| `loginGovConfig` | _[LoginGovOptions](#logingovoptions)_ | LoginGovConfig holds all configurations for LoginGov provider. |

441+| `id` | _string_ | ID should be a unique identifier for the provider.<br/>This value is required for all providers. |

442+| `provider` | _[ProviderType](#providertype)_ | Type is the OAuth provider<br/>must be set from the supported providers group,<br/>otherwise 'Google' is set as default |

443+| `name` | _string_ | Name is the providers display name<br/>if set, it will be shown to the users in the login page. |

444+| `caFiles` | _[]string_ | CAFiles is a list of paths to CA certificates that should be used when connecting to the provider.<br/>If not specified, the default Go trust sources are used instead |

445+| `useSystemTrustStore` | _bool_ | UseSystemTrustStore determines if your custom CA files and the system trust store are used<br/>If set to true, your custom CA files and the system trust store are used otherwise only your custom CA files. |

446+| `loginURL` | _string_ | LoginURL is the authentication endpoint |

447+| `loginURLParameters` | _[[]LoginURLParameter](#loginurlparameter)_ | LoginURLParameters defines the parameters that can be passed from the start URL to the IdP login URL |

448+| `authRequestResponseMode` | _string_ | AuthRequestResponseMode defines the response mode to request during authorization request |

449+| `redeemURL` | _string_ | RedeemURL is the token redemption endpoint |

450+| `profileURL` | _string_ | ProfileURL is the profile access endpoint |

451+| `skipClaimsFromProfileURL` | _bool_ | SkipClaimsFromProfileURL allows to skip request to Profile URL for resolving claims not present in id_token<br/>default set to 'false' |

452+| `resource` | _string_ | ProtectedResource is the resource that is protected (Azure AD and ADFS only) |

453+| `validateURL` | _string_ | ValidateURL is the access token validation endpoint |

454+| `scope` | _string_ | Scope is the OAuth scope specification |

455+| `allowedGroups` | _[]string_ | AllowedGroups is a list of restrict logins to members of this group |

456+| `code_challenge_method` | _string_ | The code challenge method |

457+| `backendLogoutURL` | _string_ | URL to call to perform backend logout, `{id_token}` would be replaced by the actual `id_token` if available in the session |

458+

459+### ProviderType

460+#### (`string` alias)

461+

462+(**Appears on:** [Provider](#provider))

463+

464+ProviderType is used to enumerate the different provider type options

465+Valid options are: adfs, azure, bitbucket, digitalocean facebook, github,

466+gitlab, google, keycloak, keycloak-oidc, linkedin, login.gov, nextcloud

467+and oidc.

468+

469+### Providers

470+

471+#### ([[]Provider](#provider) alias)

472+

473+(**Appears on:** [AlphaOptions](#alphaoptions))

474+

475+The provider can be selected using the `provider` configuration value, or

476+set in the [`providers` array using

477+AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers).

478+However, [**the feature to implement multiple providers is not

479+complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

480+

481+### SecretSource

482+

483+(**Appears on:** [ClaimSource](#claimsource), [HeaderValue](#headervalue), [TLS](#tls))

484+

485+SecretSource references an individual secret value.

486+Only one source within the struct should be defined at any time.

487+

488+| Field | Type | Description |

489+| ----- | ---- | ----------- |

490+| `value` | _[]byte_ | Value expects a base64 encoded string value. |

491+| `fromEnv` | _string_ | FromEnv expects the name of an environment variable. |

492+| `fromFile` | _string_ | FromFile expects a path to a file containing the secret value. |

493+

494+### Server

495+

496+(**Appears on:** [AlphaOptions](#alphaoptions))

497+

498+Server represents the configuration for an HTTP(S) server

499+

500+| Field | Type | Description |

501+| ----- | ---- | ----------- |

502+| `BindAddress` | _string_ | BindAddress is the address on which to serve traffic.<br/>Leave blank or set to "-" to disable. |

503+| `SecureBindAddress` | _string_ | SecureBindAddress is the address on which to serve secure traffic.<br/>Leave blank or set to "-" to disable. |

504+| `TLS` | _[TLS](#tls)_ | TLS contains the information for loading the certificate and key for the<br/>secure traffic and further configuration for the TLS server. |

505+

506+### TLS

507+

508+(**Appears on:** [Server](#server))

509+

510+TLS contains the information for loading a TLS certificate and key

511+as well as an optional minimal TLS version that is acceptable.

512+

513+| Field | Type | Description |

514+| ----- | ---- | ----------- |

515+| `Key` | _[SecretSource](#secretsource)_ | Key is the TLS key data to use.<br/>Typically this will come from a file. |

516+| `Cert` | _[SecretSource](#secretsource)_ | Cert is the TLS certificate data to use.<br/>Typically this will come from a file. |

517+| `MinVersion` | _string_ | MinVersion is the minimal TLS version that is acceptable.<br/>E.g. Set to "TLS1.3" to select TLS version 1.3 |

518+| `CipherSuites` | _[]string_ | CipherSuites is a list of TLS cipher suites that are allowed.<br/>E.g.:<br/>- TLS_RSA_WITH_RC4_128_SHA<br/>- TLS_RSA_WITH_AES_256_GCM_SHA384<br/>If not specified, the default Go safe cipher list is used.<br/>List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). |

519+

520+### URLParameterRule

521+

522+(**Appears on:** [LoginURLParameter](#loginurlparameter))

523+

524+URLParameterRule represents a rule by which query parameters

525+passed to the `/oauth2/start` endpoint are checked to determine whether

526+they are valid overrides for the given parameter passed to the IdP's

527+login URL. Either Value or Pattern should be supplied, not both.

528+

529+| Field | Type | Description |

530+| ----- | ---- | ----------- |

531+| `value` | _string_ | A Value rule matches just this specific value |

532+| `pattern` | _string_ | A Pattern rule gives a regular expression that must be matched by<br/>some substring of the value. The expression is _not_ automatically<br/>anchored to the start and end of the value, if you _want_ to restrict<br/>the whole parameter value you must anchor it yourself with `^` and `$`. |

533+

534+### Upstream

535+

536+(**Appears on:** [UpstreamConfig](#upstreamconfig))

537+

538+Upstream represents the configuration for an upstream server.

539+Requests will be proxied to this upstream if the path matches the request path.

540+

541+| Field | Type | Description |

542+| ----- | ---- | ----------- |

543+| `id` | _string_ | ID should be a unique identifier for the upstream.<br/>This value is required for all upstreams. |

544+| `path` | _string_ | Path is used to map requests to the upstream server.<br/>The closest match will take precedence and all Paths must be unique.<br/>Path can also take a pattern when used with RewriteTarget.<br/>Path segments can be captured and matched using regular experessions.<br/>Eg:<br/>- `^/foo$`: Match only the explicit path `/foo`<br/>- `^/bar/$`: Match any path prefixed with `/bar/`<br/>- `^/baz/(.*)$`: Match any path prefixed with `/baz` and capture the remaining path for use with RewriteTarget |

545+| `rewriteTarget` | _string_ | RewriteTarget allows users to rewrite the request path before it is sent to<br/>the upstream server (for an HTTP/HTTPS upstream) or mapped to the filesystem<br/>(for a `file:` upstream).<br/>Use the Path to capture segments for reuse within the rewrite target.<br/>Eg: With a Path of `^/baz/(.*)`, a RewriteTarget of `/foo/$1` would rewrite<br/>the request `/baz/abc/123` to `/foo/abc/123` before proxying to the<br/>upstream server. Or if the upstream were `file:///app`, a request for<br/>`/baz/info.html` would return the contents of the file `/app/foo/info.html`. |

546+| `uri` | _string_ | The URI of the upstream server. This may be an HTTP(S) server of a File<br/>based URL. It may include a path, in which case all requests will be served<br/>under that path.<br/>Eg:<br/>- http://localhost:8080<br/>- https://service.localhost<br/>- https://service.localhost/path<br/>- file://host/path<br/>If the URI's path is "/base" and the incoming request was for "/dir",<br/>the upstream request will be for "/base/dir". |

547+| `insecureSkipTLSVerify` | _bool_ | InsecureSkipTLSVerify will skip TLS verification of upstream HTTPS hosts.<br/>This option is insecure and will allow potential Man-In-The-Middle attacks<br/>between OAuth2 Proxy and the upstream server.<br/>Defaults to false. |

548+| `static` | _bool_ | Static will make all requests to this upstream have a static response.<br/>The response will have a body of "Authenticated" and a response code<br/>matching StaticCode.<br/>If StaticCode is not set, the response will return a 200 response. |

549+| `staticCode` | _int_ | StaticCode determines the response code for the Static response.<br/>This option can only be used with Static enabled. |

550+| `flushInterval` | _[Duration](#duration)_ | FlushInterval is the period between flushing the response buffer when<br/>streaming response from the upstream.<br/>Defaults to 1 second. |

551+| `passHostHeader` | _bool_ | PassHostHeader determines whether the request host header should be proxied<br/>to the upstream server.<br/>Defaults to true. |

552+| `proxyWebSockets` | _bool_ | ProxyWebSockets enables proxying of websockets to upstream servers<br/>Defaults to true. |

553+| `timeout` | _[Duration](#duration)_ | Timeout is the maximum duration the server will wait for a response from the upstream server.<br/>Defaults to 30 seconds. |

554+| `disableKeepAlives` | _bool_ | DisableKeepAlives disables HTTP keep-alive connections to the upstream server.<br/>Defaults to false. |

555+

556+### UpstreamConfig

557+

558+(**Appears on:** [AlphaOptions](#alphaoptions))

559+

560+UpstreamConfig is a collection of definitions for upstream servers.

561+

562+| Field | Type | Description |

563+| ----- | ---- | ----------- |

564+| `proxyRawPath` | _bool_ | ProxyRawPath will pass the raw url path to upstream allowing for urls<br/>like: "/%2F/" which would otherwise be redirected to "/" |

565+| `upstreams` | _[[]Upstream](#upstream)_ | Upstreams represents the configuration for the upstream servers.<br/>Requests will be proxied to this upstream if the path matches the request path. |

docs/versioned_docs/version-7.12.x/configuration/alpha_config.md.tmplnew file+139

@@ -0,0 +1,139 @@

1+---

2+id: alpha-config

3+title: Alpha Configuration

4+---

5+

6+:::warning

7+This page contains documentation for alpha features.

8+We reserve the right to make breaking changes to the features detailed within this page with no notice.

9+

10+Options described in this page may be changed, removed, renamed or moved without prior warning.

11+Please beware of this before you use alpha configuration options.

12+:::

13+

14+This page details a set of **alpha** configuration options in a new format.

15+Going forward we are intending to add structured configuration in YAML format to

16+replace the existing TOML based configuration file and flags.

17+

18+Below is a reference for the structure of the configuration, with

19+[AlphaOptions](#alphaoptions) as the root of the configuration.

20+

21+When using alpha configuration, your config file will look something like below:

22+

23+```yaml

24+upstreams:

25+ - id: ...

26+ ...: ...

27+injectRequestHeaders:

28+ - name: ...

29+ ...: ...

30+injectResponseHeaders:

31+ - name: ...

32+ ...: ...

33+```

34+

35+Please browse the [reference](#configuration-reference) below for the structure

36+of the new configuration format.

37+

38+## Using Alpha Configuration

39+

40+To use the new **alpha** configuration, generate a YAML file based on the format

41+described in the [reference](#configuration-reference) below.

42+

43+Provide the path to this file using the `--alpha-config` flag.

44+

45+:::note

46+When using the `--alpha-config` flag, some options are no longer available.

47+See [removed options](#removed-options) below for more information.

48+:::

49+

50+### Converting configuration to the new structure

51+

52+Before adding the new `--alpha-config` option, start OAuth2 Proxy using the

53+`convert-config-to-alpha` flag to convert existing configuration to the new format.

54+

55+```bash

56+oauth2-proxy --convert-config-to-alpha --config ./path/to/existing/config.cfg

57+```

58+

59+This will convert any options supported by the new format to YAML and print the

60+new configuration to `STDOUT`.

61+

62+Copy this to a new file, remove any options from your existing configuration

63+noted in [removed options](#removed-options) and then start OAuth2 Proxy using

64+the new config.

65+

66+```bash

67+oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

68+```

69+

70+## Using ENV variables in the alpha configuration

71+

72+The alpha package supports the use of environment variables in place of yaml keys, allowing sensitive values to be pulled from somewhere other than the yaml file.

73+When using environment variables, your yaml will look like this:

74+

75+```yaml

76+ providers:

77+ - provider: azure

78+ clientSecret: ${CLIENT_SECRET}

79+ ...

80+```

81+Where CLIENT_SECRET is an environment variable.

82+More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

83+

84+## Removed options

85+

86+The following flags/options and their respective environment variables are no

87+longer available when using alpha configuration:

88+

89+<!-- Legacy Upstream FlagSet -->

90+- `flush-interval`/`flush_interval`

91+- `pass-host-header`/`pass_host_header`

92+- `proxy-websockets`/`proxy_websockets`

93+- `ssl-upstream-insecure-skip-verify`/`ssl_upstream_insecure_skip_verify`

94+- `upstream`/`upstreams`

95+

96+<!-- Legacy Headers FlagSet -->

97+- `pass-basic-auth`/`pass_basic_auth`

98+- `pass-access-token`/`pass_access_token`

99+- `pass-user-headers`/`pass_user_headers`

100+- `pass-authorization-header`/`pass_authorization_header`

101+- `set-basic-auth`/`set_basic_auth`

102+- `set-xauthrequest`/`set_xauthrequest`

103+- `set-authorization-header`/`set_authorization_header`

104+- `prefer-email-to-user`/`prefer_email_to_user`

105+- `basic-auth-password`/`basic_auth_password`

106+- `skip-auth-strip-headers`/`skip_auth_strip_headers`

107+

108+<!-- Legacy provider FlagSet -->

109+- `client-id`/`client_id`

110+- `client-secret`/`client_secret`, and `client-secret-file`/`client_secret_file`

111+- `provider`

112+- `provider-display-name`/`provider_display_name`

113+- `provider-ca-file`/`provider_ca_files`

114+- `login-url`/`login_url`

115+- `redeem-url`/`redeem_url`

116+- `profile-url`/`profile_url`

117+- `resource`

118+- `validate-url`/`validate_url`

119+- `scope`

120+- `prompt`

121+- `approval-prompt`/`approval_prompt`

122+- `acr-values`/`acr_values`

123+- `user-id-claim`/`user_id_claim`

124+- `allowed-group`/`allowed_groups`

125+- `allowed-role`/`allowed_roles`

126+- `jwt-key`/`jwt_key`

127+- `jwt-key-file`/`jwt_key_file`

128+- `pubjwk-url`/`pubjwk_url`

129+

130+and all provider-specific options, i.e. any option whose name includes `oidc`,

131+`azure`, `bitbucket`, `github`, `gitlab`, `google` or `keycloak`. Attempting to

132+use any of these options via flags or via config when `--alpha-config` is

133+set will result in an error.

134+

135+:::important

136+You must remove these options before starting OAuth2 Proxy with `--alpha-config`

137+:::

138+

139+## Configuration Reference

docs/docs/configuration/integration.md → docs/versioned_docs/version-7.12.x/configuration/integration.mdrenamed+83−15

@@ -33,9 +33,15 @@ server {

3333 proxy_pass_request_body off;

3434 }

3535

36+ # Named location for handling OAuth2 sign-in redirects

37+ # This ensures the browser receives a proper 302 redirect that it will follow

38+ location @oauth2_signin {

39+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

40+ }

41+

3642 location / {

3743 auth_request /oauth2/auth;

38− error_page 401 =403 /oauth2/sign_in;

44+ error_page 401 = @oauth2_signin;

3945

4046 # pass information via X-User and X-Email headers to backend,

4147 # requires running with --set-xauthrequest flag

@@ -77,23 +83,77 @@ server {

7783}

7884```

7985

80−When you use ingress-nginx in Kubernetes, you MUST use `kubernetes/ingress-nginx` (which includes the Lua module) and the following configuration snippet for your `Ingress`.

81−Variables set with `auth_request_set` are not `set`-able in plain nginx config when the location is processed via `proxy_pass` and then may only be processed by Lua.

82−Note that `nginxinc/kubernetes-ingress` does not include the Lua module.

86+### Understanding the `error_page` redirect pattern

87+

88+The `auth_request` directive expects the authentication endpoint (`/oauth2/auth`) to return:

89+- **2xx**: Request is authenticated, allow access

90+- **401 or 403**: Request is not authenticated, deny access

91+

92+When a 401 is returned, nginx triggers the `error_page` directive. The recommended pattern uses a **named location** (`@oauth2_signin`) that returns a proper **302 redirect**:

93+

94+

95+```nginx

96+error_page 401 = @oauth2_signin;

97+

98+location @oauth2_signin {

99+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

100+}

101+```

102+

103+:::warning Avoid `error_page 401 =403` with sign_in

104+Some older configurations use `error_page 401 =403 /oauth2/sign_in`. While this works for displaying the sign-in page, it returns a **403 status code** with a `Location` header. Browsers do not automatically follow redirects on 403 responses, which can cause issues when using `--skip-provider-button=true` (users see a "Found." link instead of being automatically redirected).

105+

106+The named location pattern above ensures the browser receives a standard **302 redirect** that works correctly with all oauth2-proxy configurations.

107+:::

108+

109+### Browser vs API Routes

110+

111+:::important When to use redirects

112+Redirecting authentication failures (302 to `/oauth2/sign_in`) should **only be used for browser-facing routes**. API or machine clients should receive a plain 401/403 response without redirect.

113+:::

114+

115+#### Browser-facing routes (HTML, UI)

116+

117+For interactive browser routes where users should be redirected to sign in:

118+

119+```nginx

120+location / {

121+ auth_request /oauth2/auth;

122+ error_page 401 = @oauth2_signin;

123+ proxy_pass http://backend/;

124+}

125+

126+location @oauth2_signin {

127+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

128+}

129+```

130+

131+#### API / Machine routes (no redirect)

132+

133+For API endpoints where clients expect a 401/403 status code (not a redirect):

134+

135+```nginx

136+location /api/ {

137+ auth_request /oauth2/auth;

138+ error_page 401 =401; # Pass through the 401 status

139+ proxy_pass http://backend/;

140+}

141+```

142+

143+This ensures:

144+- ✅ Browsers get a redirect and smooth login flow

145+- ✅ API clients fail fast with appropriate HTTP status codes

146+- ✅ `/oauth2/auth` remains a pure boolean oracle (2xx/401)

147+

148+When you use ingress-nginx in Kubernetes, you can configure the same behavior with the following annotations on your Ingress resource:

83149

84150```yaml

85−nginx.ingress.kubernetes.io/auth-response-headers: Authorization

86−nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2/start?rd=$escaped_request_uri

87−nginx.ingress.kubernetes.io/auth-url: https://$host/oauth2/auth

88−nginx.ingress.kubernetes.io/configuration-snippet: |

89− auth_request_set $name_upstream_1 $upstream_cookie_name_1;

90−

91− access_by_lua_block {

92− if ngx.var.name_upstream_1 ~= "" then

93− ngx.header["Set-Cookie"] = "name_1=" .. ngx.var.name_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")

94− end

95− }

151+nginx.ingress.kubernetes.io/auth-url: "https://<oauth2-proxy-fqdn>/oauth2/auth"

152+nginx.ingress.kubernetes.io/auth-signin: "https://<oauth2-proxy-fqdn>/oauth2/start?rd=$escaped_request_uri"

96153```

154+

155+This minimal configuration works for standard authentication flows. Lua/cookie handling is only needed for advanced scenarios (e.g., multi-part cookies, custom session logic). See the official ingress-nginx example: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/.

156+

97157It is recommended to use `--session-store-type=redis` when expecting large sessions/OIDC tokens (_e.g._ with MS Azure).

98158

99159You have to substitute *name* with the actual cookie name you configured via --cookie-name parameter. If you don't set a custom cookie name the variable should be "$upstream_cookie__oauth2_proxy_1" instead of "$upstream_cookie_name_1" and the new cookie-name should be "_oauth2_proxy_1=" instead of "name_1=".

@@ -165,8 +225,16 @@ http:

165225 - "401-403"

166226 service: oauth-backend

167227 query: "/oauth2/sign_in?rd={url}"

228+ statusRewrites:

229+ "401": 302

168230```

169231

232+:::info Troubleshooting: Browser shows "Found." instead of redirecting

233+When using the Errors middleware without `statusRewrites`, the redirect response from oauth2-proxy can be served within the original 401/403 status context. This causes some browsers to display a "Found." link instead of automatically following the redirect to the identity provider.

234+

235+Adding `statusRewrites` to rewrite `401 -> 302` ensures the browser treats the response as a proper redirect and follows it automatically.

236+:::

237+

170238### ForwardAuth with static upstreams configuration

171239

172240Redirect to sign_in functionality provided without the use of `errors` middleware with [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) pointing to oauth2-proxy service's `/` endpoint

docs/versioned_docs/version-7.12.x/configuration/overview.mdnew file+407

@@ -0,0 +1,407 @@

1+---

2+id: overview

3+title: Overview

4+---

5+

6+`oauth2-proxy` can be configured via [command line options](#command-line-options), [environment variables](#environment-variables) or [config file](#config-file) (in decreasing order of precedence, i.e. command line options will overwrite environment variables and environment variables will overwrite configuration file settings).

7+

8+## Generating a Cookie Secret

9+

10+To generate a strong cookie secret use one of the below commands:

11+

12+import Tabs from '@theme/Tabs';

13+import TabItem from '@theme/TabItem';

14+

15+<Tabs defaultValue="python">

16+ <TabItem value="python" label="Python">

17+

18+```shell

19+python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())'

20+```

21+

22+ </TabItem>

23+ <TabItem value="bash" label="Bash">

24+

25+```shell

26+dd if=/dev/urandom bs=32 count=1 2>/dev/null | base64 | tr -d -- '\n' | tr -- '+/' '-_' ; echo

27+```

28+

29+ </TabItem>

30+ <TabItem value="openssl" label="OpenSSL">

31+

32+```shell

33+openssl rand -base64 32 | tr -- '+/' '-_'

34+```

35+

36+ </TabItem>

37+ <TabItem value="powershell" label="PowerShell">

38+

39+```powershell

40+# Add System.Web assembly to session, just in case

41+Add-Type -AssemblyName System.Web

42+[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes([System.Web.Security.Membership]::GeneratePassword(32,4))).Replace("+","-").Replace("/","_")

43+```

44+

45+ </TabItem>

46+ <TabItem value="terraform" label="Terraform">

47+

48+```hcl

49+# Valid 32 Byte Base64 URL encoding set that will decode to 24 []byte AES-192 secret

50+resource "random_password" "cookie_secret" {

51+ length = 32

52+ override_special = "-_"

53+}

54+```

55+

56+ </TabItem>

57+</Tabs>

58+

59+## Config File

60+

61+Every command line argument can be specified in a config file by replacing hyphens (-) with underscores (\_). If the argument can be specified multiple times, the config option should be plural (trailing s).

62+

63+An example [oauth2-proxy.cfg](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/oauth2-proxy.cfg.example) config file is in the contrib directory. It can be used by specifying `--config=/etc/oauth2-proxy.cfg`

64+

65+## Config Options

66+

67+### Command Line Options

68+

69+| Flag | Description |

70+| ----------- | -------------------- |

71+| `--config` | path to config file |

72+| `--version` | print version string |

73+

74+

75+### General Provider Options

76+

77+Provider specific options can be found on their respective subpages.

78+

79+| Flag / Config Field | Type | Description | Default |

80+| --------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |

81+| flag: `--acr-values`<br/>toml: `acr_values` | string | optional, see [docs](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html#acrValues) | `""` |

82+| flag: `--allowed-group`<br/>toml: `allowed_groups` | string \| list | Restrict login to members of a group or list of groups. Furthermore, if you aren't setting the `scope` and use `allowed_groups` with the generic OIDC provider the scope `groups` gets added implicitly. | |

83+| flag: `--approval-prompt`<br/>toml: `approval_prompt` | string | OAuth approval_prompt | `"force"` |

84+| flag: `--backend-logout-url`<br/>toml: `backend_logout_url` | string | URL to perform backend logout, if you use `{id_token}` in the url it will be replaced by the actual `id_token` of the user session | |

85+| flag: `--client-id`<br/>toml: `client_id` | string | the OAuth Client ID, e.g. `"123456.apps.googleusercontent.com"` | |

86+| flag: `--client-secret-file`<br/>toml: `client_secret_file` | string | the file with OAuth Client Secret. The file must contain the secret only, with no trailing newline | |

87+| flag: `--client-secret`<br/>toml: `client_secret` | string | the OAuth Client Secret | |

88+| flag: `--code-challenge-method`<br/>toml: `code_challenge_method` | string | use PKCE code challenges with the specified method. Either 'plain' or 'S256' (recommended) | |

89+| flag: `--insecure-oidc-allow-unverified-email`<br/>toml: `insecure_oidc_allow_unverified_email` | bool | don't fail if an email address in an id_token is not verified | false |

90+| flag: `--insecure-oidc-skip-issuer-verification`<br/>toml: `insecure_oidc_skip_issuer_verification` | bool | allow the OIDC issuer URL to differ from the expected (currently required for Azure multi-tenant compatibility) | false |

91+| flag: `--insecure-oidc-skip-nonce`<br/>toml: `insecure_oidc_skip_nonce` | bool | skip verifying the OIDC ID Token's nonce claim | true |

92+| flag: `--jwt-key-file`<br/>toml: `jwt_key_file` | string | path to the private key file in PEM format used to sign the JWT so that you can say something like `--jwt-key-file=/etc/ssl/private/jwt_signing_key.pem`: required by login.gov | |

93+| flag: `--jwt-key`<br/>toml: `jwt_key` | string | private key in PEM format used to sign JWT, so that you can say something like `--jwt-key="${OAUTH2_PROXY_JWT_KEY}"`: required by login.gov | |

94+| flag: `--login-url`<br/>toml: `login_url` | string | Authentication endpoint | |

95+| flag: `--auth-request-response-mode`<br/>toml: `auth-request-response-mode` | string | Response mode to ask for during authentication request | |

96+| flag: `--oidc-audience-claim`<br/>toml: `oidc_audience_claims` | string | which OIDC claim contains the audience | `"aud"` |

97+| flag: `--oidc-email-claim`<br/>toml: `oidc_email_claim` | string | which OIDC claim contains the user's email | `"email"` |

98+| flag: `--oidc-extra-audience`<br/>toml: `oidc_extra_audiences` | string \| list | additional audiences which are allowed to pass verification | `"[]"` |

99+| flag: `--oidc-groups-claim`<br/>toml: `oidc_groups_claim` | string | which OIDC claim contains the user groups | `"groups"` |

100+| flag: `--oidc-issuer-url`<br/>toml: `oidc_issuer_url` | string | the OpenID Connect issuer URL, e.g. `"https://accounts.google.com"` | |

101+| flag: `--oidc-jwks-url`<br/>toml: `oidc_jwks_url` | string | OIDC JWKS URI for token verification; required if OIDC discovery is disabled and public key files are not provided | |

102+| flag: `--oidc-public-key-file`<br/>toml: `oidc_public_key_files` | string | Path to public key file in PEM format to use for verifying JWT tokens (may be given multiple times). Required if OIDC discovery is disabled na JWKS URL isn't provided | string \| list |

103+| flag: `--profile-url`<br/>toml: `profile_url` | string | Profile access endpoint | |

104+| flag: `--prompt`<br/>toml: `prompt` | string | [OIDC prompt](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest); if present, `approval-prompt` is ignored | `""` |

105+| flag: `--provider-ca-file`<br/>toml: `provider_ca_files` | string \| list | Paths to CA certificates that should be used when connecting to the provider. If not specified, the default Go trust sources are used instead. |

106+| flag: `--provider-display-name`<br/>toml: `provider_display_name` | string | Override the provider's name with the given string; used for the sign-in page | (depends on provider) |

107+| flag: `--provider`<br/>toml: `provider` | string | OAuth provider | google |

108+| flag: `--pubjwk-url`<br/>toml: `pubjwk_url` | string | JWK pubkey access endpoint: required by login.gov | |

109+| flag: `--redeem-url`<br/>toml: `redeem_url` | string | Token redemption endpoint | |

110+| flag: `--scope`<br/>toml:`scope` | string | OAuth scope specification. Every provider has a default list of scopes which will be used in case no scope is configured. | |

111+| flag: `--skip-claims-from-profile-url`<br/>toml: `skip_claims_from_profile_url` | bool | skip request to Profile URL for resolving claims not present in id_token | false |

112+| flag: `--skip-oidc-discovery`<br/>toml: `skip_oidc_discovery` | bool | bypass OIDC endpoint discovery. `--login-url`, `--redeem-url` and `--oidc-jwks-url` must be configured in this case | false |

113+| flag: `--use-system-trust-store`<br/>toml: `use_system_trust_store` | bool | Determines if `provider-ca-file` files and the system trust store are used. If set to true, your custom CA files and the system trust store are used otherwise only your custom CA files. | false |

114+| flag: `--validate-url`<br/>toml: `validate_url` | string | Access token validation endpoint | |

115+

116+### Cookie Options

117+

118+| Flag / Config Field | Type | Description | Default |

119+| --------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |

120+| flag: `--cookie-csrf-expire`<br/>toml: `cookie_csrf_expire` | duration | expire timeframe for CSRF cookie | 15m |

121+| flag: `--cookie-csrf-per-request`<br/>toml:`cookie_csrf_per_request` | bool | Enable having different CSRF cookies per request, making it possible to have parallel requests. | false |

122+| flag: `--cookie-csrf-per-request-limit`<br/>toml: `cookie_csrf_per_request_limit` | int | Sets a limit on the number of CSRF requests cookies that oauth2-proxy will create. The oldest cookie will be removed. Useful if users end up with 431 Request headers too large status codes. Only effective if --cookie-csrf-per-request is true | "infinite" |

123+| flag: `--cookie-domain`<br/>toml: `cookie_domains` | string \| list | Optional cookie domains to force cookies to (e.g. `.yourcompany.com`). The longest domain matching the request's host will be used (or the shortest cookie domain if there is no match). | |

124+| flag: `--cookie-expire`<br/>toml: `cookie_expire` | duration | expire timeframe for cookie. If set to 0, cookie becomes a session-cookie which will expire when the browser is closed. | 168h0m0s |

125+| flag: `--cookie-httponly`<br/>toml: `cookie_httponly` | bool | set HttpOnly cookie flag | true |

126+| flag: `--cookie-name`<br/>toml: `cookie_name` | string | the name of the cookie that the oauth_proxy creates. Should be changed to use a [cookie prefix](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes) (`__Host-` or `__Secure-`) if `--cookie-secure` is set. | `"_oauth2_proxy"` |

127+| flag: `--cookie-path`<br/>toml: `cookie_path` | string | an optional cookie path to force cookies to (e.g. `/poc/`) | `"/"` |

128+| flag: `--cookie-refresh`<br/>toml: `cookie_refresh` | duration | refresh the cookie after this duration; `0` to disable; not supported by all providers&nbsp;[^1] | |

129+| flag: `--cookie-samesite`<br/>toml: `cookie_samesite` | string | set SameSite cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`). | `""` |

130+| flag: `--cookie-secret`<br/>toml: `cookie_secret` | string | the seed string for secure cookies (optionally base64 encoded) | |

131+| flag: `--cookie-secret-file`<br/>toml: `cookie_secret_file` | string | File containing the cookie secret (must be raw binary, exactly 16, 24, or 32 bytes). Use dd if=/dev/urandom bs=32 count=1 > cookie.secret to generate | |

132+| flag: `--cookie-secure`<br/>toml: `cookie_secure` | bool | set [secure (HTTPS only) cookie flag](https://owasp.org/www-community/controls/SecureFlag) | true |

133+

134+[^1]: The following providers support `--cookie-refresh`: ADFS, Azure, GitLab, Google, Keycloak and all other Identity Providers which support the full [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens)

135+

136+### Header Options

137+

138+| Flag / Config Field | Type | Description | Default |

139+| ------------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

140+| flag: `--basic-auth-password`<br/>toml: `basic_auth_password` | string | the password to set when passing the HTTP Basic Auth header | |

141+| flag: `--set-xauthrequest`<br/>toml: `set_xauthrequest` | bool | set X-Auth-Request-User, X-Auth-Request-Groups, X-Auth-Request-Email and X-Auth-Request-Preferred-Username response headers (useful in Nginx auth_request mode). When used with `--pass-access-token`, X-Auth-Request-Access-Token is added to response headers. | false |

142+| flag: `--set-authorization-header`<br/>toml: `set_authorization_header` | bool | set Authorization Bearer response header (useful in Nginx auth_request mode) | false |

143+| flag: `--set-basic-auth`<br/>toml: `set_basic_auth` | bool | set HTTP Basic Auth information in response (useful in Nginx auth_request mode) | false |

144+| flag: `--skip-auth-strip-headers`<br/>toml: `skip_auth_strip_headers` | bool | strips `X-Forwarded-*` style authentication headers & `Authorization` header if they would be set by oauth2-proxy | true |

145+| flag: `--pass-access-token`<br/>toml: `pass_access_token` | bool | pass OAuth access_token to upstream via X-Forwarded-Access-Token header. When used with `--set-xauthrequest` this adds the X-Auth-Request-Access-Token header to the response | false |

146+| flag: `--pass-authorization-header`<br/>toml: `pass_authorization_header` | bool | pass OIDC IDToken to upstream via Authorization Bearer header | false |

147+| flag: `--pass-basic-auth`<br/>toml: `pass_basic_auth` | bool | pass HTTP Basic Auth, X-Forwarded-User, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream | true |

148+| flag: `--prefer-email-to-user`<br/>toml: `prefer_email_to_user` | bool | Prefer to use the Email address as the Username when passing information to upstream. Will only use Username if Email is unavailable, e.g. htaccess authentication. Used in conjunction with `--pass-basic-auth` and `--pass-user-headers` | false |

149+| flag: `--pass-user-headers`<br/>toml: `pass_user_headers` | bool | pass X-Forwarded-User, X-Forwarded-Groups, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream | true |

150+

151+### Logging Options

152+

153+| Flag / Config Field | Type | Description | Default |

154+| --------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------- | --------------------------------------------------- |

155+| flag: `--auth-logging-format`<br/>toml: `auth_logging_format` | string | Template for authentication log lines | see [Logging Configuration](#logging-configuration) |

156+| flag: `--auth-logging`<br/>toml: `auth_logging` | bool | Log authentication attempts | true |

157+| flag: `--errors-to-info-log`<br/>toml: `errors_to_info_log` | bool | redirects error-level logging to default log channel instead of stderr | false |

158+| flag: `--exclude-logging-path`<br/>toml: `exclude_logging_paths` | string | comma separated list of paths to exclude from logging, e.g. `"/ping,/path2"` | `""` (no paths excluded) |

159+| flag: `--logging-compress`<br/>toml: `logging_compress` | bool | Should rotated log files be compressed using gzip | false |

160+| flag: `--logging-filename`<br/>toml: `logging_filename` | string | File to log requests to, empty for `stdout` | `""` (stdout) |

161+| flag: `--logging-local-time`<br/>toml: `logging_local_time` | bool | Use local time in log files and backup filenames instead of UTC | true (local time) |

162+| flag: `--logging-max-age`<br/>toml: `logging_max_age` | int | Maximum number of days to retain old log files | 7 |

163+| flag: `--logging-max-backups`<br/>toml: `logging_max_backups` | int | Maximum number of old log files to retain; 0 to disable | 0 |

164+| flag: `--logging-max-size`<br/>toml: `logging_max_size` | int | Maximum size in megabytes of the log file before rotation | 100 |

165+| flag: `--request-id-header`<br/>toml: `request_id_header` | string | Request header to use as the request ID in logging | X-Request-Id |

166+| flag: `--request-logging-format`<br/>toml: `request_logging_format` | string | Template for request log lines | see [Logging Configuration](#logging-configuration) |

167+| flag: `--request-logging`<br/>toml: `request_logging` | bool | Log requests | true |

168+| flag: `--silence-ping-logging`<br/>toml: `silence_ping_logging` | bool | disable logging of requests to ping & ready endpoints | false |

169+| flag: `--standard-logging-format`<br/>toml: `standard_logging_format` | string | Template for standard log lines | see [Logging Configuration](#logging-configuration) |

170+| flag: `--standard-logging`<br/>toml: `standard_logging` | bool | Log standard runtime information | true |

171+

172+### Page Template Options

173+

174+| Flag / Config Field | Type | Description | Default |

175+| ----------------------------------------------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------- | ------- |

176+| flag: `--banner`<br/>toml: `banner` | string | custom (html) banner string. Use `"-"` to disable default banner. | |

177+| flag: `--custom-sign-in-logo`<br/>toml: `custom_sign_in_logo` | string | path or a URL to an custom image for the sign_in page logo. Use `"-"` to disable default logo. |

178+| flag: `--custom-templates-dir`<br/>toml: `custom_templates_dir` | string | path to custom html templates | |

179+| flag: `--display-htpasswd-form`<br/>toml: `display_htpasswd_form` | bool | display username / password login form if an htpasswd file is provided | true |

180+| flag: `--footer`<br/>toml: `footer` | string | custom (html) footer string. Use `"-"` to disable default footer. (Can be used to obfuscate the version) | |

181+| flag: `--show-debug-on-error`<br/>toml: `show_debug_on_error` | bool | show detailed error information on error pages (WARNING: this may contain sensitive information - do not use in production) | false |

182+

183+### Probe Options

184+

185+| Flag / Config Field | Type | Description | Default |

186+| ------------------------------------------------------- | ------ | ---------------------------------------------------------- | ----------------------------- |

187+| flag: `--ping-path`<br/>toml: `ping_path` | string | the ping endpoint that can be used for basic health checks | `"/ping"` |

188+| flag: `--ping-user-agent`<br/>toml: `ping_user_agent` | string | a User-Agent that can be used for basic health checks | `""` (don't check user agent) |

189+| flag: `--ready-path`<br/>toml: `ready_path` | string | the ready endpoint that can be used for deep health checks | `"/ready"` |

190+| flag: `--gcp-healthchecks`<br/>toml: `gcp_healthchecks` | bool | Enable GCP/GKE healthcheck endpoints (deprecated) | false |

191+

192+### Proxy Options

193+

194+| Flag / Config Field | Type | Description | Default |

195+| ----------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |

196+| flag: `--allow-query-semicolons`<br/>toml: `allow_query_semicolons` | bool | allow the use of semicolons in query args ([required for some legacy applications](https://github.com/golang/go/issues/25192)) | `false` |

197+| flag: `--api-route`<br/>toml: `api_routes` | string \| list | Requests to these paths must already be authenticated with a cookie, or a JWT if `--skip-jwt-bearer-tokens` is set. No redirect to login will be done. Return 401 if not. Format: path_regex | |

198+| flag: `--authenticated-emails-file`<br/>toml: `authenticated_emails_file` | string | authenticate against emails via file (one per line) | |

199+| flag: `--bearer-token-login-fallback`<br/>toml: `bearer_token_login_fallback` | bool | if `--skip-jwt-bearer-tokens` is set, if a request includes an invalid JWT (expired, malformed, missing required audiences, etc), fall back to normal login redirect as if the token were not sent at all. If false, respond 403 | true |

200+| flag: `--email-domain`<br/>toml: `email_domains` | string \| list | authenticate emails with the specified domain (may be given multiple times). Use `*` to authenticate any email | |

201+| flag: `--encode-state`<br/>toml: `encode_state` | bool | encode the state parameter as UrlEncodedBase64 | false |

202+| flag: `--extra-jwt-issuers`<br/>toml: `extra_jwt_issuers` | string | if `--skip-jwt-bearer-tokens` is set, a list of extra JWT `issuer=audience` (see a token's `iss`, `aud` fields) pairs (where the issuer URL has a `.well-known/openid-configuration` or a `.well-known/jwks.json`) | |

203+| flag: `--force-https`<br/>toml: `force_https` | bool | enforce https redirect | `false` |

204+| flag: `--force-json-errors`<br/>toml: `force_json_errors` | bool | force JSON errors instead of HTTP error pages or redirects | `false` |

205+| flag: `--htpasswd-file`<br/>toml: `htpasswd_file` | string | additionally authenticate against a htpasswd file. Entries must be created with `htpasswd -B` for bcrypt encryption | |

206+| flag: `--htpasswd-user-group`<br/>toml: `htpasswd_user_groups` | string \| list | the groups to be set on sessions for htpasswd users | |

207+| flag: `--proxy-prefix`<br/>toml: `proxy_prefix` | string | the url root path that this proxy should be nested under (e.g. /`<oauth2>/sign_in`) | `"/oauth2"` |

208+| flag: `--real-client-ip-header`<br/>toml: `real_client_ip_header` | string | Header used to determine the real IP of the client, requires `--reverse-proxy` to be set (one of: X-Forwarded-For, X-Real-IP, X-ProxyUser-IP, X-Envoy-External-Address, or CF-Connecting-IP) | X-Real-IP |

209+| flag: `--redirect-url`<br/>toml: `redirect_url` | string | the OAuth Redirect URL, e.g. `"https://internalapp.yourcompany.com/oauth2/callback"` | |

210+| flag: `--relative-redirect-url`<br/>toml: `relative_redirect_url` | bool | allow relative OAuth Redirect URL.` | false |

211+| flag: `--reverse-proxy`<br/>toml: `reverse_proxy` | bool | are we running behind a reverse proxy, controls whether headers like X-Real-IP are accepted and allows X-Forwarded-\{Proto,Host,Uri\} headers to be used on redirect selection | false |

212+| flag: `--signature-key`<br/>toml: `signature_key` | string | GAP-Signature request signature key (algorithm:secretkey) | |

213+| flag: `--skip-auth-preflight`<br/>toml: `skip_auth_preflight` | bool | will skip authentication for OPTIONS requests | false |

214+| flag: `--skip-auth-regex`<br/>toml: `skip_auth_regex` | string \| list | (DEPRECATED for `--skip-auth-route`) bypass authentication for requests paths that match (may be given multiple times) | |

215+| flag: `--skip-auth-route`<br/>toml: `skip_auth_routes` | string \| list | bypass authentication for requests that match the method & path. Format: method=path_regex OR method!=path_regex. For all methods: path_regex OR !=path_regex | |

216+| flag: `--skip-jwt-bearer-tokens`<br/>toml: `skip_jwt_bearer_tokens` | bool | will skip requests that have verified JWT bearer tokens (the token must have [`aud`](https://en.wikipedia.org/wiki/JSON_Web_Token#Standard_fields) that matches this client id or one of the extras from `extra-jwt-issuers`) | false |

217+| flag: `--skip-provider-button`<br/>toml: `skip_provider_button` | bool | will skip sign-in-page to directly reach the next step: oauth/start | false |

218+| flag: `--ssl-insecure-skip-verify`<br/>toml: `ssl_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS providers | false |

219+| flag: `--trusted-ip`<br/>toml: `trusted_ips` | string \| list | list of IPs or CIDR ranges to allow to bypass authentication (may be given multiple times). When combined with `--reverse-proxy` and optionally `--real-client-ip-header` this will evaluate the trust of the IP stored in an HTTP header by a reverse proxy rather than the layer-3/4 remote address. WARNING: trusting IPs has inherent security flaws, especially when obtaining the IP address from an HTTP header (reverse-proxy mode). Use this option only if you understand the risks and how to manage them. | |

220+| flag: `--whitelist-domain`<br/>toml: `whitelist_domains` | string \| list | allowed domains for redirection after authentication. Prefix domain with a `.` or a `*.` to allow subdomains (e.g. `.example.com`, `*.example.com`)&nbsp;[^2] | |

221+

222+[^2]: When using the `whitelist-domain` option, any domain prefixed with a `.` or a `*.` will allow any subdomain of the specified domain as a valid redirect URL. By default, only empty ports are allowed. This translates to allowing the default port of the URL's protocol (80 for HTTP, 443 for HTTPS, etc.) since browsers omit them. To allow only a specific port, add it to the whitelisted domain: `example.com:8080`. To allow any port, use `*`: `example.com:*`.

223+

224+### Server Options

225+

226+| Flag / Config Field | Type | Description | Default |

227+| ------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |

228+| flag: `--http-address`<br/>toml: `http_address` | string | `[http://]<addr>:<port>` or `unix://<path>` or `fd:<int>` (case insensitive) to listen on for HTTP clients. Square brackets are required for ipv6 address, e.g. `http://[::1]:4180` | `"127.0.0.1:4180"` |

229+| flag: `--https-address`<br/>toml: `https_address` | string | `[https://]<addr>:<port>` to listen on for HTTPS clients. Square brackets are required for ipv6 address, e.g. `https://[::1]:443` | `":443"` |

230+| flag: `--metrics-address`<br/>toml: `metrics_address` | string | the address prometheus metrics will be scraped from | `""` |

231+| flag: `--metrics-secure-address`<br/>toml: `metrics_secure_address` | string | the address prometheus metrics will be scraped from if using HTTPS | `""` |

232+| flag: `--metrics-tls-cert-file`<br/>toml: `metrics_tls_cert_file` | string | path to certificate file for secure metrics server | `""` |

233+| flag: `--metrics-tls-key-file`<br/>toml: `metrics_tls_key_file` | string | path to private key file for secure metrics server | `""` |

234+| flag: `--tls-cert-file`<br/>toml: `tls_cert_file` | string | path to certificate file | |

235+| flag: `--tls-key-file`<br/>toml: `tls_key_file` | string | path to private key file | |

236+| flag: `--tls-cipher-suite`<br/>toml: `tls_cipher_suites` | string \| list | Restricts TLS cipher suites used by server to those listed (e.g. TLS_RSA_WITH_RC4_128_SHA) (may be given multiple times). If not specified, the default Go safe cipher list is used. List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). | |

237+| flag: `--tls-min-version`<br/>toml: `tls_min_version` | string | minimum TLS version that is acceptable, either `"TLS1.2"` or `"TLS1.3"` | `"TLS1.2"` |

238+

239+### Session Options

240+

241+| Flag / Config Field | Type | Description | Default |

242+| ----------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

243+| flag: `--session-cookie-minimal`<br/>toml: `session_cookie_minimal` | bool | strip OAuth tokens from cookie session stores if they aren't needed (cookie session store only) | false |

244+| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

245+| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

246+| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

247+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. |

248+| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

249+| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

250+| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

251+| flag: `--redis-sentinel-master-name`<br/>toml: `redis_sentinel_master_name` | string | Redis sentinel master name. Used in conjunction with `--redis-use-sentinel` | |

252+| flag: `--redis-sentinel-connection-urls`<br/>toml: `redis_sentinel_connection_urls` | string \| list | List of Redis sentinel connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-sentinel` | |

253+| flag: `--redis-use-cluster`<br/>toml: `redis_use_cluster` | bool | Connect to redis cluster. Must set `--redis-cluster-connection-urls` to use this feature | false |

254+| flag: `--redis-use-sentinel`<br/>toml: `redis_use_sentinel` | bool | Connect to redis via sentinels. Must set `--redis-sentinel-master-name` and `--redis-sentinel-connection-urls` to use this feature | false |

255+| flag: `--redis-connection-idle-timeout`<br/>toml: `redis_connection_idle_timeout` | int | Redis connection idle timeout seconds. If Redis [timeout](https://redis.io/docs/reference/clients/#client-timeouts) option is set to non-zero, the `--redis-connection-idle-timeout` must be less than Redis timeout option. Example: if either redis.conf includes `timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14` | 0 |

256+

257+### Upstream Options

258+

259+| Flag / Config Field | Type | Description | Default |

260+| ----------------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- |

261+| flag: `--flush-interval`<br/>toml: `flush_interval` | duration | period between flushing response buffers when streaming responses | `"1s"` |

262+| flag: `--pass-host-header`<br/>toml: `pass_host_header` | bool | pass the request Host Header to upstream | true |

263+| flag: `--proxy-websockets`<br/>toml: `proxy_websockets` | bool | enables WebSocket proxying | true |

264+| flag: `--ssl-upstream-insecure-skip-verify`<br/>toml: `ssl_upstream_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS upstreams | false |

265+| flag: `--disable-keep-alives`<br/>toml: `disable_keep_alives` | bool | disable HTTP keep-alive connections to the upstream server | false |

266+| flag: `--upstream-timeout`<br/>toml: `upstream_timeout` | duration | maximum amount of time the server will wait for a response from the upstream | 30s |

267+| flag: `--upstream`<br/>toml: `upstreams` | string \| list | the http url(s) of the upstream endpoint, file:// paths for static files or `static://<status_code>` for static response. Routing is based on the path | |

268+

269+## Upstreams Configuration

270+

271+`oauth2-proxy` supports having multiple upstreams, and has the option to pass requests on to HTTP(S) servers, unix socket or serve static files from the file system.

272+

273+To configure **HTTP and HTTPS upstreams**, provide such a URL in `--upstream=URL`. The scheme+host portion and the path portion are extracted to configure proxying behavior. When processing incoming requests, the path portion becomes a lookup key for selecting the destination server of the proxied request.

274+

275+* Upstream URLs *without a trailing slash,* like in `--upstream=http://service2.internal/foo`, will match an incoming request exactly to `/foo` in `https://this.o2p.example.com/foo`, and forward the request on to service2.internal, but not match a request to `https://this.o2p.example.com/foo/more` nor ...`.com/food`.

276+* Upstream URLs *with a trailing slash,* like in `--upstream=http://service1.internal/foo/`, will match any incoming request to any incoming requests's path *starting with* `/foo/`, like `/foo/` and `/foo/more` and `/foo/lots/more?etc`.

277+

278+If multiple `--upstream` URLs' paths match an incoming request, the one with the longest matching path (the most specific match) takes priority over shorter (less specific) ones.

279+

280+**Unix socket upstreams** are configured as `unix:///path/to/unix.sock`.

281+

282+**Static file paths** are configured as a file:// URL. `file:///var/www/static/` will serve the files from that directory at `http://[oauth2-proxy url]/var/www/static/`, which may not be what you want. You can provide the path to where the files should be available by adding a fragment to the configured URL. The value of the fragment will then be used to specify which path the files are available at, e.g. `file:///var/www/static/#/static/` will make `/var/www/static/` available at `http://[oauth2-proxy url]/static/`.

283+

284+Multiple upstreams can either be configured by supplying a comma separated list to the `--upstream` parameter, supplying the parameter multiple times or providing a list in the [config file](#config-file). When multiple upstreams are used routing to them will be based on the path they are set up with.

285+

286+## Environment variables

287+

288+Every command line argument can be specified as an environment variable by

289+prefixing it with `OAUTH2_PROXY_`, capitalising it, and replacing hyphens (`-`)

290+with underscores (`_`). If the argument can be specified multiple times, the

291+environment variable should be plural (trailing `S`).

292+

293+This is particularly useful for storing secrets outside a configuration file

294+or the command line.

295+

296+For example, the `--cookie-secret` flag becomes `OAUTH2_PROXY_COOKIE_SECRET`.

297+If a flag has the type `string | list` like the `--email-domain` flag it is

298+available as an environment variable in plural form e.g. `OAUTH2_PROXY_EMAIL_DOMAINS`

299+

300+Values for type `string | list` usually have a plural environment variable name

301+and need to be seperated by `,` e.g.

302+`OAUTH2_PROXY_SKIP_AUTH_ROUTES="GET=^/api/status,POST=^/api/saved_objects/_import"`

303+

304+Please check the type for each [config option](#config-options) first.

305+

306+## Logging Configuration

307+

308+By default, OAuth2 Proxy logs all output to stdout. Logging can be configured to output to a rotating log file using the `--logging-filename` command.

309+

310+If logging to a file you can also configure the maximum file size (`--logging-max-size`), age (`--logging-max-age`), max backup logs (`--logging-max-backups`), and if backup logs should be compressed (`--logging-compress`).

311+

312+There are three different types of logging: standard, authentication, and HTTP requests. These can each be enabled or disabled with `--standard-logging`, `--auth-logging`, and `--request-logging`.

313+

314+Each type of logging has its own configurable format and variables. By default, these formats are similar to the Apache Combined Log.

315+

316+Logging of requests to the `/ping` endpoint (or using `--ping-user-agent`) and the `/ready` endpoint can be disabled with `--silence-ping-logging` reducing log volume.

317+

318+## Auth Log Format

319+

320+Authentication logs are logs which are guaranteed to contain a username or email address of a user attempting to authenticate. These logs are output by default in the below format:

321+

322+```

323+<REMOTE_ADDRESS> - <REQUEST ID> - <user@domain.com> [2015/03/19 17:20:19] [<STATUS>] <MESSAGE>

324+```

325+

326+The status block will contain one of the below strings:

327+

328+- `AuthSuccess` If a user has authenticated successfully by any method

329+- `AuthFailure` If the user failed to authenticate explicitly

330+- `AuthError` If there was an unexpected error during authentication

331+

332+If you require a different format than that, you can configure it with the `--auth-logging-format` flag.

333+The default format is configured as follows:

334+

335+```

336+{{.Client}} - {{.RequestID}} - {{.Username}} [{{.Timestamp}}] [{{.Status}}] {{.Message}}

337+```

338+

339+Available variables for auth logging:

340+

341+| Variable | Example | Description |

342+| ------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------- |

343+| Client | 74.125.224.72 | The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true. |

344+| Host | domain.com | The value of the Host header. |

345+| Message | Authenticated via OAuth2 | The details of the auth attempt. |

346+| Protocol | HTTP/1.0 | The request protocol. |

347+| RequestID | 00010203-0405-4607-8809-0a0b0c0d0e0f | The request ID pulled from the `--request-id-header`. Random UUID if empty |

348+| RequestMethod | GET | The request method. |

349+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

350+| UserAgent | - | The full user agent as reported by the requesting client. |

351+| Username | username@email.com | The email or username of the auth request. |

352+| Status | AuthSuccess | The status of the auth request. See above for details. |

353+

354+## Request Log Format

355+

356+HTTP request logs will output by default in the below format:

357+

358+```

359+<REMOTE_ADDRESS> - <REQUEST ID> - <user@domain.com> [2015/03/19 17:20:19] <HOST_HEADER> GET <UPSTREAM_HOST> "/path/" HTTP/1.1 "<USER_AGENT>" <RESPONSE_CODE> <RESPONSE_BYTES> <REQUEST_DURATION>

360+```

361+

362+If you require a different format than that, you can configure it with the `--request-logging-format` flag.

363+The default format is configured as follows:

364+

365+```

366+{{.Client}} - {{.RequestID}} - {{.Username}} [{{.Timestamp}}] {{.Host}} {{.RequestMethod}} {{.Upstream}} {{.RequestURI}} {{.Protocol}} {{.UserAgent}} {{.StatusCode}} {{.ResponseSize}} {{.RequestDuration}}

367+```

368+

369+Available variables for request logging:

370+

371+| Variable | Example | Description |

372+| --------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------- |

373+| Client | 74.125.224.72 | The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true. |

374+| Host | domain.com | The value of the Host header. |

375+| Protocol | HTTP/1.0 | The request protocol. |

376+| RequestDuration | 0.001 | The time in seconds that a request took to process. |

377+| RequestID | 00010203-0405-4607-8809-0a0b0c0d0e0f | The request ID pulled from the `--request-id-header`. Random UUID if empty |

378+| RequestMethod | GET | The request method. |

379+| RequestURI | "/oauth2/auth" | The URI path of the request. |

380+| ResponseSize | 12 | The size in bytes of the response. |

381+| StatusCode | 200 | The HTTP status code of the response. |

382+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

383+| Upstream | - | The upstream data of the HTTP request. |

384+| UserAgent | - | The full user agent as reported by the requesting client. |

385+| Username | username@email.com | The email or username of the auth request. |

386+

387+## Standard Log Format

388+

389+All other logging that is not covered by the above two types of logging will be output in this standard logging format. This includes configuration information at startup and errors that occur outside of a session. The default format is below:

390+

391+```

392+[2015/03/19 17:20:19] [main.go:40] <MESSAGE>

393+```

394+

395+If you require a different format than that, you can configure it with the `--standard-logging-format` flag. The default format is configured as follows:

396+

397+```

398+[{{.Timestamp}}] [{{.File}}] {{.Message}}

399+```

400+

401+Available variables for standard logging:

402+

403+| Variable | Example | Description |

404+| --------- | --------------------------------- | -------------------------------------------------- |

405+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

406+| File | main.go:40 | The file and line number of the logging statement. |

407+| Message | HTTP: listening on 127.0.0.1:4180 | The details of the log statement. |

docs/versioned_docs/version-7.12.x/configuration/providers/adfs.mdnew file+19

@@ -0,0 +1,19 @@

1+---

2+id: adfs

3+title: ADFS

4+---

5+

6+1. Open the ADFS administration console on your Windows Server and add a new Application Group

7+2. Provide a name for the integration, select Server Application from the Standalone applications section and click Next

8+3. Follow the wizard to get the client-id, client-secret and configure the application credentials

9+4. Configure the proxy with

10+

11+```

12+ --provider=adfs

13+ --client-id=<application ID from step 3>

14+ --client-secret=<value from step 3>

15+```

16+

17+Note: When using the ADFS Auth provider with nginx and the cookie session store you may find the cookie is too large and

18+doesn't get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the

19+[redis session storage](../sessions.md#redis-storage) should resolve this.

docs/versioned_docs/version-7.12.x/configuration/providers/bitbucket.mdnew file+25

@@ -0,0 +1,25 @@

1+---

2+id: bitbucket

3+title: BitBucket

4+---

5+

6+1. [Add a new OAuth consumer](https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html)

7+ * In "Callback URL" use `https://<oauth2-proxy>/oauth2/callback`, substituting `<oauth2-proxy>` with the actual

8+ hostname that oauth2-proxy is running on.

9+ * In Permissions section select:

10+ * Account -> Email

11+ * Team membership -> Read

12+ * Repositories -> Read

13+2. Note the Client ID and Client Secret.

14+

15+To use the provider, pass the following options:

16+

17+```

18+ --provider=bitbucket

19+ --client-id=<Client ID>

20+ --client-secret=<Client Secret>

21+```

22+

23+The default configuration allows everyone with Bitbucket account to authenticate. To restrict the access to the team

24+members use additional configuration option: `--bitbucket-team=<Team name>`. To restrict the access to only these users

25+who have access to one selected repository use `--bitbucket-repository=<Repository name>`.

docs/versioned_docs/version-7.12.x/configuration/providers/cidaas.mdnew file+37

@@ -0,0 +1,37 @@

1+---

2+id: cidaas

3+title: Cidaas

4+---

5+

6+[Cidaas](https://www.cidaas.com/) is an Identity as a Service (IDaaS) solution that provides authentication and authorization services.

7+It supports various protocols including OpenID Connect, OAuth 2.0, and SAML.

8+

9+However, Cidaas provides groups and their roles as hierarchical claims, which are not supported by oauth2-proxy yet.

10+The Cidaas provider transforms the hierarchical claims into a flat list of groups, which can be used by oauth2-proxy.

11+

12+Example of groups and roles in Cidaas:

13+

14+```json

15+{

16+ "groups": [

17+ {

18+ "groupId": "group1",

19+ "roles": ["role1", "role2"]

20+ },

21+ {

22+ "groupId": "group2",

23+ "roles": ["role3"]

24+ }

25+ ]

26+}

27+```

28+

29+This will be transformed into a flat list of groups:

30+

31+```json

32+{

33+ "groups": ["group1:role1", "group2:role2", "group2:role3"]

34+}

35+```

36+

37+Apart from that the Cidaas provider inherits all the features of the [OpenID Connect provider](openid_connect.md).

docs/versioned_docs/version-7.12.x/configuration/providers/digitalocean.mdnew file+21

@@ -0,0 +1,21 @@

1+---

2+id: digitalocean

3+title: DigitalOcean

4+---

5+

6+1. [Create a new OAuth application](https://cloud.digitalocean.com/account/api/applications)

7+ * You can fill in the name, homepage, and description however you wish.

8+ * In the "Application callback URL" field, enter: `https://oauth-proxy/oauth2/callback`, substituting `oauth2-proxy`

9+ with the actual hostname that oauth2-proxy is running on. The URL must match oauth2-proxy's configured redirect URL.

10+2. Note the Client ID and Client Secret.

11+

12+To use the provider, pass the following options:

13+

14+```

15+ --provider=digitalocean

16+ --client-id=<Client ID>

17+ --client-secret=<Client Secret>

18+```

19+

20+Alternatively, set the equivalent options in the config file. The redirect URL defaults to

21+`https://<requested host header>/oauth2/callback`. If you need to change it, you can use the `--redirect-url` command-line option.

docs/versioned_docs/version-7.12.x/configuration/providers/facebook.mdnew file+7

@@ -0,0 +1,7 @@

1+---

2+id: facebook

3+title: Facebook

4+---

5+

6+1. Create a new FB App from https://developers.facebook.com/

7+2. Under FB Login, set your Valid OAuth redirect URIs to `https://internal.yourcompany.com/oauth2/callback`

docs/versioned_docs/version-7.12.x/configuration/providers/gitea.mdnew file+24

@@ -0,0 +1,24 @@

1+---

2+id: gitea

3+title: Gitea / Forgejo

4+---

5+

6+:::note

7+This is not actually a fully serparate provider. For more details and options please refer to the [GitHub Provider Options](github.md)

8+:::

9+

10+1. Create a new application: `https://< your gitea host >/user/settings/applications`

11+2. Under `Redirect URI` enter the correct URL i.e. `https://<proxied host>/oauth2/callback`

12+3. Note the Client ID and Client Secret.

13+4. Pass the following options to the proxy:

14+

15+```

16+ --provider="github"

17+ --redirect-url="https://<proxied host>/oauth2/callback"

18+ --provider-display-name="Gitea"

19+ --client-id="< client_id as generated by Gitea >"

20+ --client-secret="< client_secret as generated by Gitea >"

21+ --login-url="https://< your gitea host >/login/oauth/authorize"

22+ --redeem-url="https://< your gitea host >/login/oauth/access_token"

23+ --validate-url="https://< your gitea host >/api/v1/user/emails"

24+```

docs/versioned_docs/version-7.12.x/configuration/providers/github.mdnew file+81

@@ -0,0 +1,81 @@

1+---

2+id: github

3+title: GitHub

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ---------------- | -------------- | -------------- | ------------------------------------------------------------------------------------------------------------- | ------- |

10+| `--github-org` | `github_org` | string | restrict logins to members of this organisation | |

11+| `--github-team` | `github_team` | string | restrict logins to members of any of these teams (slug) or (org:team), comma separated | |

12+| `--github-repo` | `github_repo` | string | restrict logins to collaborators of this repository formatted as `orgname/repo` | |

13+| `--github-token` | `github_token` | string | the token to use when verifying repository collaborators (must have push access to the repository) | |

14+| `--github-user` | `github_users` | string \| list | To allow users to login by username even if they do not belong to the specified org and team or collaborators | |

15+

16+## Usage

17+

18+1. Create a new project: https://github.com/settings/developers

19+2. Under `Authorization callback URL` enter the correct url ie `https://internal.yourcompany.com/oauth2/callback`

20+

21+The GitHub auth provider supports two additional ways to restrict authentication to either organization and optional

22+team level access, or to collaborators of a repository. Restricting by these options is normally accompanied with `--email-domain=*`. Additionally, all the organizations and teams a user belongs to are set as part of the `X-Forwarded-Groups` header. e.g. `org1:team1,org1:team2,org2:team1`

23+

24+NOTE: When `--github-user` is set, the specified users are allowed to log in even if they do not belong to the specified

25+org and team or collaborators.

26+

27+To restrict access to your organization:

28+

29+```shell

30+ # restrict logins to members of this organisation

31+ --github-org="your-org"

32+```

33+

34+To restrict access to specific teams within an organization:

35+

36+```shell

37+ --github-org="your-org"

38+ # restrict logins to members of any of these teams (slug), comma separated

39+ --github-team="team1,team2,team3"

40+```

41+

42+To restrict to teams within different organizations, keep the organization flag empty and use `--github-team` like so:

43+

44+```shell

45+ # keep empty

46+ --github-org=""

47+ # restrict logins to members to any of the following teams (format <org>:<slug>, like octo:team1), comma separated

48+ --github-team="org1:team1,org2:team1,org3:team42,octo:cat"

49+```

50+

51+If you would rather restrict access to collaborators of a repository, those users must either have push access to a

52+public repository or any access to a private repository:

53+

54+```shell

55+ # restrict logins to collaborators of this repository formatted as orgname/repo

56+ --github-repo=""

57+```

58+

59+If you'd like to allow access to users with **read only** access to a **public** repository you will need to provide a

60+[token](https://github.com/settings/tokens) for a user that has write access to the repository. The token must be

61+created with at least the `public_repo` scope:

62+

63+```shell

64+ # the token to use when verifying repository collaborators

65+ --github-token=""

66+```

67+

68+To allow a user to log in with their username even if they do not belong to the specified org and team or collaborators:

69+

70+```shell

71+ # allow logins by username, comma separated

72+ --github-user=""

73+```

74+

75+If you are using GitHub enterprise, make sure you set the following to the appropriate url:

76+

77+```shell

78+ --login-url="http(s)://<enterprise github host>/login/oauth/authorize"

79+ --redeem-url="http(s)://<enterprise github host>/login/oauth/access_token"

80+ --validate-url="http(s)://<enterprise github host>/api/v3"

81+```

docs/versioned_docs/version-7.12.x/configuration/providers/gitlab.mdnew file+49

@@ -0,0 +1,49 @@

1+---

2+id: gitlab

3+title: GitLab

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

10+| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

12+

13+## Usage

14+

15+This auth provider has been tested against Gitlab version 12.X. Due to Gitlab API changes, it may not work for version

16+prior to 12.X (see [994](https://github.com/oauth2-proxy/oauth2-proxy/issues/994)).

17+

18+Whether you are using GitLab.com or self-hosting GitLab, follow

19+[these steps to add an application](https://docs.gitlab.com/integration/oauth_provider/). Make sure to enable at

20+least the `openid`, `profile` and `email` scopes, and set the redirect url to your application url e.g.

21+https://myapp.com/oauth2/callback.

22+

23+If you need projects filtering, add the extra `read_api` scope to your application.

24+

25+The following config should be set to ensure that the oauth will work properly. To get a cookie secret follow

26+[these steps](../overview.md#generating-a-cookie-secret)

27+

28+```

29+ --provider="gitlab"

30+ --redirect-url="https://myapp.com/oauth2/callback" // Should be the same as the redirect url for the application in gitlab

31+ --client-id=GITLAB_CLIENT_ID

32+ --client-secret=GITLAB_CLIENT_SECRET

33+ --cookie-secret=COOKIE_SECRET

34+```

35+

36+Restricting by group membership is possible with the following option:

37+

38+```shell

39+ --gitlab-group="mygroup,myothergroup" # restrict logins to members of any of these groups (slug), separated by a comma

40+```

41+

42+If you are using self-hosted GitLab, make sure you set the following to the appropriate URL:

43+

44+```shell

45+ --oidc-issuer-url="<your gitlab url>"

46+```

47+

48+If your self-hosted GitLab is on a subdirectory (e.g. domain.tld/gitlab), as opposed to its own subdomain

49+(e.g. gitlab.domain.tld), you may need to add a redirect from domain.tld/oauth pointing at e.g. domain.tld/gitlab/oauth.

docs/versioned_docs/version-7.12.x/configuration/providers/google.mdnew file+75

@@ -0,0 +1,75 @@

1+---

2+id: google

3+title: Google (default)

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ---------------------------------------------- | -------------------------------------------- | ------ | ------------------------------------------------------------------------------------------------ | -------------------------------------------------- |

10+| `--google-admin-email` | `google_admin_email` | string | the google admin to impersonate for api calls | |

11+| `--google-group` | `google_groups` | string | restrict logins to members of this google group (may be given multiple times). If not specified and service account or default credentials are configured, all user groups will be allowed. | |

12+| `--google-service-account-json` | `google_service_account_json` | string | the path to the service account json credentials | |

13+| `--google-use-application-default-credentials` | `google_use_application_default_credentials` | bool | use application default credentials instead of service account json (i.e. GKE Workload Identity) | |

14+| `--google-target-principal` | `google_target_principal` | bool | the target principal to impersonate when using ADC | defaults to the service account configured for ADC |

15+

16+## Usage

17+

18+For Google, the registration steps are:

19+

20+1. Create a new project: https://console.developers.google.com/project

21+2. Choose the new project from the top right project dropdown (only if another project is selected)

22+3. In the project Dashboard center pane, choose **"APIs & Services"**

23+4. In the left Nav pane, choose **"Credentials"**

24+5. In the center pane, choose **"OAuth consent screen"** tab. Fill in **"Product name shown to users"** and hit save.

25+6. In the center pane, choose **"Credentials"** tab.

26+ - Open the **"New credentials"** drop down

27+ - Choose **"OAuth client ID"**

28+ - Choose **"Web application"**

29+ - Application name is freeform, choose something appropriate

30+ - Authorized JavaScript origins is your domain ex: `https://internal.yourcompany.com`

31+ - Authorized redirect URIs is the location of oauth2/callback ex: `https://internal.yourcompany.com/oauth2/callback`

32+ - Choose **"Create"**

33+7. Take note of the **Client ID** and **Client Secret**

34+

35+It's recommended to refresh sessions on a short interval (1h) with `cookie-refresh` setting which validates that the

36+account is still authorized.

37+

38+#### Restrict auth to specific Google groups on your domain. (optional)

39+

40+1. Create a [service account](https://developers.google.com/identity/protocols/oauth2/service-account) and configure it

41+ to use [Application Default Credentials / Workload Identity / Workload Identity Federation (recommended)](#using-application-default-credentials-adc--workload-identity--workload-identity-federation-recommended) or,

42+ alternatively download the JSON.

43+2. Make note of the Client ID for a future step.

44+3. Under "APIs & Auth", choose APIs.

45+4. Click on Admin SDK and then Enable API.

46+5. Follow the steps on [Set up domain-wide delegation for a service account](https://developers.google.com/workspace/guides/create-credentials#optional_set_up_domain-wide_delegation_for_a_service_account)

47+ and give the client id from step 2 the following oauth scopes:

48+

49+ ```

50+ https://www.googleapis.com/auth/admin.directory.group.member.readonly

51+ ```

52+

53+6. Follow the steps on https://support.google.com/a/answer/60757 to enable Admin API access.

54+7. Create or choose an existing administrative email address on the Gmail domain to assign to the `google-admin-email`

55+ flag. This email will be impersonated by this client to make calls to the Admin SDK. See the note on the link from

56+ step 5 for the reason why.

57+8. Create or choose an existing email group and set that email to the `google-group` flag. You can pass multiple instances

58+ of this flag with different groups and the user will be checked against all the provided groups.

59+

60+(Only if using a JSON file (see step 1))

61+

62+9. Lock down the permissions on the json file downloaded from step 1 so only oauth2-proxy is able to read the file and

63+ set the path to the file in the `google-service-account-json` flag.

64+10. Restart oauth2-proxy.

65+

66+Note: The user is checked against the group members list on initial authentication and every time the token is

67+refreshed ( about once an hour ).

68+

69+##### Using Application Default Credentials (ADC) / Workload Identity / Workload Identity Federation (recommended)

70+oauth2-proxy can make use of [Application Default Credentials](https://cloud.google.com/docs/authentication/application-default-credentials).

71+When deployed within GCP, this means that it can automatically use the service account attached to the resource. When deployed to GKE, ADC

72+can be leveraged through a feature called Workload Identity. Follow Google's [guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)

73+to set up Workload Identity.

74+

75+When deployed outside of GCP, [Workload Identity Federation](https://cloud.google.com/docs/authentication/provide-credentials-adc#wlif) might be an option.

docs/versioned_docs/version-7.12.x/configuration/providers/index.mdnew file+45

@@ -0,0 +1,45 @@

1+---

2+id: index

3+title: OAuth Provider Configuration

4+---

5+

6+You will need to register an OAuth application with a Provider (Google, GitHub or another provider), and configure it

7+with Redirect URI(s) for the domain you intend to run `oauth2-proxy` on.

8+

9+Valid providers are :

10+

11+- [ADFS](adfs.md)

12+- [Bitbucket](bitbucket.md)

13+- [Cidaas](cidaas.md)

14+- [DigitalOcean](digitalocean.md)

15+- [Facebook](facebook.md)

16+- [Gitea](gitea.md)

17+- [GitHub](github.md)

18+- [GitLab](gitlab.md)

19+- [Google](google.md) _default_

20+- [Keycloak](keycloak.md) (Deprecated)

21+- [Keycloak OIDC](keycloak_oidc.md)

22+- [LinkedIn](linkedin.md)

23+- [login.gov](login_gov.md)

24+- [Microsoft Azure](ms_azure_ad.md) (Deprecated)

25+- [Microsoft Entra ID](ms_entra_id.md)

26+- [Nextcloud](nextcloud.md)

27+- [OpenID Connect](openid_connect.md)

28+- [SourceHut](sourcehut.md)

29+

30+The provider can be selected using the `provider` configuration value, or set in the [`providers` array using AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers). However, [**the feature to implement multiple providers is not complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

31+

32+Please note that not all providers support all claims. The `preferred_username` claim is currently only supported by the

33+OpenID Connect provider.

34+

35+## Email Authentication

36+

37+To authorize a specific email-domain use `--email-domain=yourcompany.com`. To authorize individual email addresses use

38+`--authenticated-emails-file=/path/to/file` with one email per line. To authorize all email addresses use `--email-domain=*`.

39+

40+## Adding a new Provider

41+

42+Follow the examples in the [`providers` package](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/) to define a new

43+`Provider` instance. Add a new `case` to

44+[`providers.New()`](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/providers.go) to allow `oauth2-proxy` to use the

45+new `Provider`.

docs/versioned_docs/version-7.12.x/configuration/providers/keycloak.mdnew file+36

@@ -0,0 +1,36 @@

1+---

2+id: keycloak

3+title: Keycloak (Deprecated)

4+---

5+

6+:::note

7+This is the legacy and deprecated provider for Keycloak, use [Keycloak OIDC Auth Provider](keycloak_oidc.md) if possible.

8+:::

9+

10+1. Create new client in your Keycloak realm with **Access Type** 'confidential' and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'

11+2. Take note of the Secret in the credential tab of the client

12+3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.

13+

14+Make sure you set the following to the appropriate url:

15+

16+```

17+ --provider=keycloak

18+ --client-id=<client you have created>

19+ --client-secret=<your client's secret>

20+ --login-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/auth"

21+ --redeem-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/token"

22+ --profile-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"

23+ --validate-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"

24+ --keycloak-group=<first_allowed_user_group>

25+ --keycloak-group=<second_allowed_user_group>

26+```

27+

28+For group based authorization, the optional `--keycloak-group` (legacy) or `--allowed-group` (global standard)

29+flags can be used to specify which groups to limit access to.

30+

31+If these are unset but a `groups` mapper is set up above in step (3), the provider will still

32+populate the `X-Forwarded-Groups` header to your upstream server with the `groups` data in the

33+Keycloak userinfo endpoint response.

34+

35+The group management in keycloak is using a tree. If you create a group named admin in keycloak

36+you should define the 'keycloak-group' value to /admin.

docs/versioned_docs/version-7.12.x/configuration/providers/keycloak_oidc.mdnew file+151

@@ -0,0 +1,151 @@

1+---

2+id: keycloak_oidc

3+title: Keycloak OIDC

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ---------------- | --------------- | -------------- | ------------------------------------------------------------------------------------------------------------------ | ------- |

10+| `--allowed-role` | `allowed_roles` | string \| list | restrict logins to users with this role (may be given multiple times). Only works with the keycloak-oidc provider. | |

11+

12+## Usage

13+

14+```

15+ --provider=keycloak-oidc

16+ --client-id=<your client's id>

17+ --client-secret=<your client's secret>

18+ --redirect-url=https://internal.yourcompany.com/oauth2/callback

19+ --oidc-issuer-url=https://<keycloak host>/realms/<your realm> // For Keycloak versions <17: --oidc-issuer-url=https://<keycloak host>/auth/realms/<your realm>

20+ --email-domain=<yourcompany.com> // Validate email domain for users, see option documentation

21+ --allowed-role=<realm role name> // Optional, required realm role

22+ --allowed-role=<client id>:<client role name> // Optional, required client role

23+ --allowed-group=</group name> // Optional, requires group client scope

24+ --code-challenge-method=S256 // PKCE

25+```

26+

27+:::note

28+Keycloak has updated its admin console and as of version 19.0.0, the new admin console is enabled by default. The

29+legacy admin console has been announced for removal with the release of version 21.0.0.

30+:::

31+

32+**Keycloak legacy admin console**

33+

34+1. Create new client in your Keycloak realm with **Access Type** 'confidential', **Client protocol** 'openid-connect'

35+ and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'

36+2. Take note of the Secret in the credential tab of the client

37+3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.

38+4. Create a mapper with **Mapper Type** 'Audience' and **Included Client Audience** and **Included Custom Audience** set

39+ to your client name.

40+

41+**Keycloak new admin console (default as of v19.0.0)**

42+

43+The following example shows how to create a simple OIDC client using the new Keycloak admin2 console. However, for best

44+practices, it is recommended to consult the Keycloak documentation.

45+

46+The OIDC client must be configured with an _audience mapper_ to include the client's name in the `aud` claim of the JWT token.

47+The `aud` claim specifies the intended recipient of the token, and OAuth2 Proxy expects a match against the values of

48+either `--client-id` or `--oidc-extra-audience`.

49+

50+_In Keycloak, claims are added to JWT tokens through the use of mappers at either the realm level using "client scopes" or

51+through "dedicated" client mappers._

52+

53+**Creating the client**

54+

55+1. Create a new OIDC client in your Keycloak realm by navigating to:

56+ **Clients** -> **Create client**

57+ * **Client Type** 'OpenID Connect'

58+ * **Client ID** `<your client's id>`, please complete the remaining fields as appropriate and click **Next**.

59+ * **Client authentication** 'On'

60+ * **Authentication flow**

61+ * **Standard flow** 'selected'

62+ * **Direct access grants** 'deselect'

63+ * _Save the configuration._

64+ * **Settings / Access settings**:

65+ * **Valid redirect URIs** `https://internal.yourcompany.com/oauth2/callback`

66+ * _Save the configuration._

67+ * Under the **Credentials** tab you will now be able to locate `<your client's secret>`.

68+2. Configure a dedicated *audience mapper* for your client by navigating to **Clients** -> **\<your client's id\>** -> **Client scopes**.

69+* Access the dedicated mappers pane by clicking **\<your client's id\>-dedicated**, located under *Assigned client scope*.

70+ _(It should have a description of "Dedicated scope and mappers for this client")_

71+ * Click **Configure a new mapper** and select **Audience**

72+ * **Name** 'aud-mapper-\<your client's id\>'

73+ * **Included Client Audience** select `<your client's id>` from the dropdown.

74+ * _OAuth2 proxy can be set up to pass both the access and ID JWT tokens to your upstream services.

75+ If you require additional audience entries, you can use the **Included Custom Audience** field in addition

76+ to the "Included Client Audience" dropdown. Note that the "aud" claim of a JWT token should be limited and

77+ only specify its intended recipients._

78+ * **Add to ID token** 'On'

79+ * **Add to access token** 'On' - [#1916](https://github.com/oauth2-proxy/oauth2-proxy/pull/1916)

80+ * _Save the configuration._

81+* Any subsequent dedicated client mappers can be defined by clicking **Dedicated scopes** -> **Add mapper** ->

82+ **By configuration** -> *Select mapper*

83+

84+You should now be able to create a test user in Keycloak and get access to the OAuth2 Proxy instance, make sure to set

85+an email address matching `<yourcompany.com>` and select _Email verified_.

86+

87+**Authorization**

88+

89+_OAuth2 Proxy will perform authorization by requiring a valid user, this authorization can be extended to take into

90+account a user's membership in Keycloak `groups`, `realm roles`, and `client roles` using the keycloak-oidc provider options

91+`--allowed-role` or `--allowed-group`_

92+

93+**Roles**

94+

95+_A standard Keycloak installation comes with the required mappers for **realm roles** and **client roles** through the

96+pre-defined client scope "roles". This ensures that any roles assigned to a user are included in the `JWT` tokens when

97+using an OIDC client that has the "Full scope allowed" feature activated, the feature is enabled by default._

98+

99+_Creating a realm role_

100+* Navigate to **Realm roles** -> **Create role**

101+ * **Role name**, *`<realm role name>`* -> **save**

102+

103+_Creating a client role_

104+* Navigate to **Clients** -> `<your client's id>` -> **Roles** -> **Create role**

105+ * **Role name**, *`<client role name>`* -> **save**

106+

107+

108+_Assign a role to a user_

109+

110+**Users** -> _Username_ -> **Role mapping** -> **Assign role** -> _filter by roles or clients and select_ -> **Assign**.

111+

112+Keycloak "realm roles" can be authorized using the `--allowed-role=<realm role name>` option, while "client roles" can be

113+evaluated using `--allowed-role=<your client's id>:<client role name>`.

114+

115+You may limit the _realm roles_ included in the JWT tokens for any given client by navigating to:

116+**Clients** -> `<your client's id>` -> **Client scopes** -> _\<your client's id\>-dedicated_ -> **Scope**

117+Disabling **Full scope allowed** activates the **Assign role** option, allowing you to select which roles, if assigned

118+to a user, will be included in the user's JWT tokens. This can be useful when a user has many associated roles, and you

119+want to reduce the size and impact of the JWT token.

120+

121+

122+**Groups**

123+

124+You may also do authorization on group memberships by using the OAuth2 Proxy option `--allowed-group`.

125+We will only do a brief description of creating the required _client scope_ **groups** and refer you to read the Keycloak

126+documentation.

127+

128+To summarize, the steps required to authorize Keycloak group membership with OAuth2 Proxy are as follows:

129+

130+* Create a new Client Scope with the name **groups** in Keycloak.

131+ * Include a mapper of type **Group Membership**.

132+ * Set the "Token Claim Name" to **groups** or customize by matching it to the `--oidc-groups-claim` option of OAuth2 Proxy.

133+ * If the "Full group path" option is selected, you need to include a "/" separator in the group names defined in the

134+ `--allowed-group` option of OAuth2 Proxy. Example: "/groupname" or "/groupname/child_group".

135+

136+After creating the _Client Scope_ named _groups_ you will need to attach it to your client.

137+**Clients** -> `<your client's id>` -> **Client scopes** -> **Add client scope** -> Select **groups** and choose Optional

138+and you should now have a client that maps group memberships into the JWT tokens so that Oauth2 Proxy may evaluate them.

139+

140+Create a group by navigating to **Groups** -> **Create group** and _add_ your test user as a member.

141+

142+The OAuth2 Proxy option `--allowed-group=/groupname` will now allow you to filter on group membership

143+

144+Keycloak also has the option of attaching roles to groups, please refer to the Keycloak documentation for more information.

145+

146+**Tip**

147+

148+To check if roles or groups are added to JWT tokens, you can preview a users token in the Keycloak console by following

149+these steps: **Clients** -> `<your client's id>` -> **Client scopes** -> **Evaluate**.

150+Select a _realm user_ and optional _scope parameters_ such as groups, and generate the JSON representation of an access

151+or id token to examine its contents.

docs/versioned_docs/version-7.12.x/configuration/providers/linkedin.mdnew file+13

@@ -0,0 +1,13 @@

1+---

2+id: linkedin

3+title: LinkedIn

4+---

5+

6+For LinkedIn, the registration steps are:

7+

8+1. Create a new project: https://www.linkedin.com/secure/developer

9+2. In the OAuth User Agreement section:

10+ - In default scope, select r_basicprofile and r_emailaddress.

11+ - In "OAuth 2.0 Redirect URLs", enter `https://internal.yourcompany.com/oauth2/callback`

12+3. Fill in the remaining required fields and Save.

13+4. Take note of the **Consumer Key / API Key** and **Consumer Secret / Secret Key**

docs/versioned_docs/version-7.12.x/configuration/providers/login_gov.mdnew file+79

@@ -0,0 +1,79 @@

1+---

2+id: login_gov

3+title: Login.gov

4+---

5+

6+login.gov is an OIDC provider for the US Government.

7+If you are a US Government agency, you can contact the login.gov team through the contact information

8+that you can find on https://login.gov/developers/ and work with them to understand how to get login.gov

9+accounts for integration/test and production access.

10+

11+A developer guide is available here: https://developers.login.gov/, though this proxy handles everything

12+but the data you need to create to register your application in the login.gov dashboard.

13+

14+As a demo, we will assume that you are running your application that you want to secure locally on

15+http://localhost:3000/, that you will be starting your proxy up on http://localhost:4180/, and that

16+you have an agency integration account for testing.

17+

18+First, register your application in the dashboard. The important bits are:

19+* Identity protocol: make this `Openid connect`

20+* Issuer: do what they say for OpenID Connect. We will refer to this string as `${LOGINGOV_ISSUER}`.

21+* Public key: This is a self-signed certificate in .pem format generated from a 2048-bit RSA private key.

22+ A quick way to do this is

23+ `openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 3650 -nodes -subj '/C=US/ST=Washington/L=DC/O=GSA/OU=18F/CN=localhost'`.

24+ The contents of the `key.pem` shall be referred to as `${OAUTH2_PROXY_JWT_KEY}`.

25+* Return to App URL: Make this be `http://localhost:4180/`

26+* Redirect URIs: Make this be `http://localhost:4180/oauth2/callback`.

27+* Attribute Bundle: Make sure that email is selected.

28+

29+Now start the proxy up with the following options:

30+```

31+./oauth2-proxy -provider login.gov \

32+ -client-id=${LOGINGOV_ISSUER} \

33+ -redirect-url=http://localhost:4180/oauth2/callback \

34+ -oidc-issuer-url=https://idp.int.identitysandbox.gov/ \

35+ -cookie-secure=false \

36+ -email-domain=gsa.gov \

37+ -upstream=http://localhost:3000/ \

38+ -cookie-secret=somerandomstring12341234567890AB \

39+ -cookie-domain=localhost \

40+ -skip-provider-button=true \

41+ -pubjwk-url=https://idp.int.identitysandbox.gov/api/openid_connect/certs \

42+ -profile-url=https://idp.int.identitysandbox.gov/api/openid_connect/userinfo \

43+ -jwt-key="${OAUTH2_PROXY_JWT_KEY}"

44+```

45+You can also set all these options with environment variables, for use in cloud/docker environments.

46+One tricky thing that you may encounter is that some cloud environments will pass in environment

47+variables in a docker env-file, which does not allow multiline variables like a PEM file.

48+If you encounter this, then you can create a `jwt_signing_key.pem` file in the top level

49+directory of the repo which contains the key in PEM format and then do your docker build.

50+The docker build process will copy that file into your image which you can then access by

51+setting the `OAUTH2_PROXY_JWT_KEY_FILE=/etc/ssl/private/jwt_signing_key.pem`

52+environment variable, or by setting `--jwt-key-file=/etc/ssl/private/jwt_signing_key.pem` on the commandline.

53+

54+Once it is running, you should be able to go to `http://localhost:4180/` in your browser,

55+get authenticated by the login.gov integration server, and then get proxied on to your

56+application running on `http://localhost:3000/`. In a real deployment, you would secure

57+your application with a firewall or something so that it was only accessible from the

58+proxy, and you would use real hostnames everywhere.

59+

60+#### Skip OIDC discovery

61+

62+Some providers do not support OIDC discovery via their issuer URL, so oauth2-proxy cannot simply grab the authorization,

63+token and jwks URI endpoints from the provider's metadata.

64+

65+In this case, you can set the `--skip-oidc-discovery` option, and supply those required endpoints manually:

66+

67+```

68+ -provider oidc

69+ -client-id oauth2-proxy

70+ -client-secret proxy

71+ -redirect-url http://127.0.0.1:4180/oauth2/callback

72+ -oidc-issuer-url http://127.0.0.1:5556

73+ -skip-oidc-discovery

74+ -login-url http://127.0.0.1:5556/authorize

75+ -redeem-url http://127.0.0.1:5556/token

76+ -oidc-jwks-url http://127.0.0.1:5556/keys

77+ -cookie-secure=false

78+ -email-domain example.com

79+```

docs/versioned_docs/version-7.12.x/configuration/providers/ms_azure_ad.mdnew file+59

@@ -0,0 +1,59 @@

1+---

2+id: azure

3+title: Azure (Deprecated)

4+---

5+

6+:::note

7+This is the legacy and deprecated provider for Azure, use [Microsoft Entra ID](ms_entra_id.md) if possible.

8+:::

9+

10+## Config Options

11+

12+| Flag | Toml Field | Type | Description | Default |

13+| ---------------- | -------------- | ------ | ---------------------------------------------------------------- | ---------- |

14+| `--azure-tenant` | `azure_tenant` | string | go to a tenant-specific or common (tenant-independent) endpoint. | `"common"` |

15+| `--resource` | `resource` | string | The resource that is protected (Azure AD only) | |

16+

17+## Usage

18+

19+1. Add an application: go to [https://portal.azure.com](https://portal.azure.com), choose **Azure Active Directory**, select

20+ **App registrations** and then click on **New registration**.

21+2. Pick a name, check the supported account type(single-tenant, multi-tenant, etc). In the **Redirect URI** section create a new

22+ **Web** platform entry for each app that you want to protect by the oauth2 proxy(e.g.

23+ https://internal.yourcompanycom/oauth2/callback). Click **Register**.

24+3. Next we need to add group read permissions for the app registration, on the **API Permissions** page of the app, click on

25+ **Add a permission**, select **Microsoft Graph**, then select **Application permissions**, then click on **Group** and select

26+ **Group.Read.All**. Hit **Add permissions** and then on **Grant admin consent** (you might need an admin to do this).

27+ <br/>**IMPORTANT**: Even if this permission is listed with **"Admin consent required=No"** the consent might actually

28+ be required, due to AAD policies you won't be able to see. If you get a **"Need admin approval"** during login,

29+ most likely this is what you're missing!

30+4. Next, if you are planning to use v2.0 Azure Auth endpoint, go to the **Manifest** page and set `"accessTokenAcceptedVersion": 2`

31+ in the App registration manifest file.

32+5. On the **Certificates & secrets** page of the app, add a new client secret and note down the value after hitting **Add**.

33+6. Configure the proxy with:

34+- for V1 Azure Auth endpoint (Azure Active Directory Endpoints - https://login.microsoftonline.com/common/oauth2/authorize)

35+

36+```

37+ --provider=azure

38+ --client-id=<application ID from step 3>

39+ --client-secret=<value from step 5>

40+ --azure-tenant={tenant-id}

41+ --oidc-issuer-url=https://sts.windows.net/{tenant-id}/

42+```

43+

44+- for V2 Azure Auth endpoint (Microsoft Identity Platform Endpoints - https://login.microsoftonline.com/common/oauth2/v2.0/authorize)

45+```

46+ --provider=azure

47+ --client-id=<application ID from step 3>

48+ --client-secret=<value from step 5>

49+ --azure-tenant={tenant-id}

50+ --oidc-issuer-url=https://login.microsoftonline.com/{tenant-id}/v2.0

51+```

52+

53+***Notes***:

54+- When using v2.0 Azure Auth endpoint (`https://login.microsoftonline.com/{tenant-id}/v2.0`) as `--oidc_issuer_url`, in conjunction

55+ with `--resource` flag, be sure to append `/.default` at the end of the resource name. See

56+ https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope for more details.

57+- When using the Azure Auth provider with nginx and the cookie session store you may find the cookie is too large and doesn't

58+ get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the

59+ [redis session storage](../sessions.md#redis-storage) should resolve this.

docs/versioned_docs/version-7.12.x/configuration/providers/ms_entra_id.mdnew file+197

@@ -0,0 +1,197 @@

1+---

2+id: ms_entra_id

3+title: Microsoft Entra ID

4+---

5+

6+Provider for Microsoft Entra ID. Fully compliant with OIDC, with support for group overage and multi-tenant apps.

7+

8+## Config Options

9+

10+The provider is OIDC-compliant, so all the OIDC parameters are honored. Additional provider-specific configuration parameters are:

11+

12+| Flag | Toml Field | Type | Description | Default |

13+| --------------------------- | -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

14+| `--entra-id-allowed-tenant` | `entra_id_allowed_tenants` | string \| list | List of allowed tenants. In case of multi-tenant apps, incoming tokens are issued by different issuers and OIDC issuer verification needs to be disabled. When not specified, all tenants are allowed. Redundant for single-tenant apps (regular ID token validation matches the issuer). | |

15+| `--entra-id-federated-token-auth` | `entra_id_federated_token_auth` | boolean | Enable oAuth2 client authentication with federated token projected by Entra Workload Identity plugin, instead of client secret. | false |

16+

17+## Configure App registration

18+To begin, create an App registration, set a redirect URI, and generate a secret. All account types are supported, including single-tenant, multi-tenant, multi-tenant with Microsoft accounts, and Microsoft accounts only.

19+

20+<details>

21+ <summary>See Azure Portal example</summary>

22+ <div class="videoBlock">

23+ <iframe src="https://www.youtube.com/embed/IUNfxhOzr4E"></iframe>

24+ </div>

25+</details>

26+

27+<details>

28+ <summary>See Terraform example</summary>

29+```

30+ resource "azuread_application" "auth" {

31+ display_name = "oauth2-proxy"

32+ sign_in_audience = "AzureADMyOrg" # Others are also supported

33+

34+ web {

35+ redirect_uris = [

36+ "https://podinfo.lakis.tech/oauth2/callback",

37+ ]

38+ }

39+ // We don't specify any required API permissions - we allow user consent only

40+ }

41+

42+ resource "azuread_service_principal" "sp" {

43+ client_id = azuread_application.auth.client_id

44+ app_role_assignment_required = false

45+ }

46+

47+ resource "azuread_service_principal_password" "pass" {

48+ service_principal_id = azuread_service_principal.sp.id

49+ }

50+

51+```

52+</details>

53+

54+### Configure groups

55+If you want to make use of groups, you can configure *groups claim* to be present in ID Tokens issued by the App registration.

56+<details>

57+ <summary>See Azure Portal example</summary>

58+ <div class="videoBlock">

59+ <div class="videoBlock">

60+ <iframe src="https://www.youtube.com/embed/QZmP5MKEJis"></iframe>

61+ </div>

62+ </div>

63+</details>

64+<details>

65+ <summary>See Terraform example</summary>

66+```

67+ resource "azuread_application" "auth" {

68+ display_name = "oauth2-proxy"

69+ sign_in_audience = "AzureADMyOrg"

70+

71+ group_membership_claims = [

72+ "SecurityGroup"

73+ ]

74+

75+ web {

76+ redirect_uris = [

77+ "https://podinfo.lakis.tech/oauth2/callback",

78+ ]

79+ }

80+ }

81+

82+ resource "azuread_service_principal" "sp" {

83+ client_id = azuread_application.auth.client_id

84+ app_role_assignment_required = false

85+ }

86+

87+ resource "azuread_service_principal_password" "pass" {

88+ service_principal_id = azuread_service_principal.sp.id

89+ }

90+

91+```

92+</details>

93+

94+### Scopes and claims

95+For single-tenant and multi-tenant apps without groups, the only required scope is `openid` (See: [Scopes and permissions](https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc#the-openid-scope)).

96+

97+To make use of groups - for example use `allowed_groups` setting or authorize based on groups inside your service - you need to enable *groups claims* in the App Registration. When enabled, list of groups is present in the issued ID token. No additional scopes are required besides `openid`. This works up to 200 groups.

98+

99+When user has more than 200 group memberships, OAuth2-Proxy attempts to retrieve the complete list from Microsoft Graph API's [`transitiveMemberOf`](https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof). Endpoint requires `User.Read` scope (delegated permission). This permission can be by default consented by user during first login. Set scope to `openid User.Read` to request user consent. Without proper scope, user with 200+ groups will authenticate with 0 groups. See: [group overages](https://learn.microsoft.com/en-us/security/zero-trust/develop/configure-tokens-group-claims-app-roles#group-overages).

100+

101+Alternatively to user consent, both `openid` and `User.Read` permissions can be consented by admistrator. Then, user is not asked for consent on the first login, and group overage works with `openid` scope only. Admin consent can also be required for some tenants. It can be granted with [azuread_service_principal_delegated_permission_grant](https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/service_principal_delegated_permission_grant) terraform resource.

102+

103+For personal microsoft accounts, required scope is `openid profile email`.

104+

105+See: [Overview of permissions and consent in the Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview).

106+

107+### Multi-tenant apps

108+To authenticate apps from multiple tenants (including personal Microsoft accounts), set the common OIDC issuer url and disable verification:

109+```toml

110+oidc_issuer_url=https://login.microsoftonline.com/common/v2.0

111+insecure_oidc_skip_issuer_verification=true

112+```

113+`insecure_oidc_skip_issuer_verification` setting is required to disable following checks:

114+* Startup check for matching issuer URL returned from [discovery document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) with `oidc_issuer_url` setting. Required, as document's `issuer` field doesn't equal to `https://login.microsoftonline.com/common/v2.0`. See [OIDC Discovery 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation).

115+* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by different tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

116+

117+To provide additional security, Entra ID provider performs check on the ID token's `issuer` claim to match the `https://login.microsoftonline.com/{tenant-id}/v2.0` template.

118+

119+### Workload Identity

120+Provider supports authentication with federated token, without need of using client secret. Following conditions have to be met:

121+

122+* Cluster has public OIDC provider URL. For major cloud providers, it can be enabled with a single flag, for example for [Azure Kubernetes Service deployed with Terraform](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/kubernetes_cluster), it's `oidc_issuer_enabled`.

123+* Workload Identity admission webhook is deployed on the cluster. For AKS, it can be enabled with a flag (`workload_identity_enabled` in Terraform resource), for clusters outside of Azure, it can be installed from [helm chart](https://github.com/Azure/azure-workload-identity).

124+* Appropriate federated credential is added to application registration.

125+<details>

126+ <summary>See federated credential terraform example</summary>

127+```

128+ resource "azuread_application_federated_identity_credential" "fedcred" {

129+ application_id = azuread_application.application.id # ID of your application

130+ display_name = "federation-cred"

131+ description = "Workload identity for oauth2-proxy"

132+ audiences = ["api://AzureADTokenExchange"] # Fixed value

133+ issuer = "https://cluster-oidc-issuer-url..."

134+ subject = "system:serviceaccount:oauth2-proxy-namespace-name:oauth2-proxy-sa-name" # set proper NS and SA name

135+ }

136+```

137+</details>

138+

139+* Kubernetes service account associated with oauth2-proxy deployment, is annotated with `azure.workload.identity/client-id: <app-registration-client-id>`

140+* oauth2-proxy pod is labeled with `azure.workload.identity/use: "true"`

141+* oauth2-proxy is configured with `entra_id_federated_token_auth` set to `true`.

142+

143+`client_secret` setting can be omitted when using federated token authentication.

144+

145+See: [Azure Workload Identity documentation](https://azure.github.io/azure-workload-identity/docs/).

146+

147+### Example configurations

148+Single-tenant app without groups (*groups claim* not enabled). Consider using generic OIDC provider:

149+```toml

150+provider="entra-id"

151+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

152+client_id="<client-id>"

153+client_secret="<client-secret>"

154+scope="openid"

155+```

156+

157+Single-tenant app with up to 200 groups (*groups claim* enabled). Consider using generic OIDC provider:

158+```toml

159+provider="entra-id"

160+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

161+client_id="<client-id>"

162+client_secret="<client-secret>"

163+scope="openid"

164+allowed_groups=["ac51800c-2679-4ecb-8130-636380a3b491"]

165+```

166+

167+Single-tenant app with more than 200 groups:

168+```toml

169+provider="entra-id"

170+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

171+client_id="<client-id>"

172+client_secret="<client-secret>"

173+scope="openid User.Read"

174+allowed_groups=["968b4844-d5e7-4e18-a834-59927959369f"]

175+```

176+

177+Single-tenant app with more than 200 groups and workload identity enabled:

178+```toml

179+provider="entra-id"

180+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

181+client_id="<client-id>"

182+scope="openid User.Read"

183+allowed_groups=["968b4844-d5e7-4e18-a834-59927959369f"]

184+entra_id_federated_token_auth=true

185+```

186+

187+Multi-tenant app with Microsoft personal accounts & one Entra tenant allowed, with group overage considered:

188+```toml

189+provider="entra-id"

190+oidc_issuer_url="https://login.microsoftonline.com/common/v2.0"

191+client_id="<client-id>"

192+client_secret="<client-secret>"

193+insecure_oidc_skip_issuer_verification=true

194+scope="openid profile email User.Read"

195+entra_id_allowed_tenants=["9188040d-6c67-4c5b-b112-36a304b66dad","<my-tenant-id>"] # Allow only <my-tenant-id> and Personal MS Accounts tenant

196+email_domains="*"

197+```

docs/versioned_docs/version-7.12.x/configuration/providers/nextcloud.mdnew file+28

@@ -0,0 +1,28 @@

1+---

2+id: nextcloud

3+title: NextCloud

4+---

5+

6+The Nextcloud provider allows you to authenticate against users in your

7+Nextcloud instance.

8+

9+When you are using the Nextcloud provider, you must specify the urls via

10+configuration, environment variable, or command line argument. Depending

11+on whether your Nextcloud instance is using pretty urls your urls may be of the

12+form `/index.php/apps/oauth2/*` or `/apps/oauth2/*`.

13+

14+Refer to the [OAuth2

15+documentation](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/oauth2.html)

16+to set up the client id and client secret. Your "Redirection URI" will be

17+`https://internalapp.yourcompany.com/oauth2/callback`.

18+

19+```

20+ -provider nextcloud

21+ -client-id <from nextcloud admin>

22+ -client-secret <from nextcloud admin>

23+ -login-url="<your nextcloud url>/index.php/apps/oauth2/authorize"

24+ -redeem-url="<your nextcloud url>/index.php/apps/oauth2/api/v1/token"

25+ -validate-url="<your nextcloud url>/ocs/v2.php/cloud/user?format=json"

26+```

27+

28+Note: in *all* cases the validate-url will *not* have the `index.php`.

docs/versioned_docs/version-7.12.x/configuration/providers/openid_connect.mdnew file+146

@@ -0,0 +1,146 @@

1+---

2+id: openid_connect

3+title: OpenID Connect

4+---

5+

6+OpenID Connect is a spec for OAUTH 2.0 + identity that is implemented by many major providers and several open source projects.

7+

8+This provider was originally built against CoreOS Dex, and we will use it as an example.

9+The OpenID Connect Provider (OIDC) can also be used to connect to other Identity Providers such as Okta, an example can be found below.

10+

11+#### Dex

12+

13+To configure the OIDC provider for Dex, perform the following steps:

14+

15+1. Download Dex:

16+

17+ ```

18+ go get github.com/dexidp/dex

19+ ```

20+

21+ See the [getting started guide](https://dexidp.io/docs/getting-started/) for more details.

22+

23+2. Setup oauth2-proxy with the correct provider and using the default ports and callbacks. Add a configuration block to

24+ the `staticClients` section of `examples/config-dev.yaml`:

25+

26+ ```

27+ - id: oauth2-proxy

28+ redirectURIs:

29+ - 'http://127.0.0.1:4180/oauth2/callback'

30+ name: 'oauth2-proxy'

31+ secret: proxy

32+ ```

33+

34+3. Launch Dex: from `$GOPATH/github.com/dexidp/dex`, run:

35+

36+ ```

37+ bin/dex serve examples/config-dev.yaml

38+ ```

39+

40+4. In a second terminal, run the oauth2-proxy with the following args:

41+

42+ ```shell

43+ --provider oidc

44+ --provider-display-name "My OIDC Provider"

45+ --client-id oauth2-proxy

46+ --client-secret proxy

47+ --redirect-url http://127.0.0.1:4180/oauth2/callback

48+ --oidc-issuer-url http://127.0.0.1:5556/dex

49+ --cookie-secure=false

50+ --cookie-secret=secret

51+ --email-domain kilgore.trout

52+ ```

53+

54+ To serve the current working directory as a website under the `/static` endpoint, add:

55+

56+ ```shell

57+ --upstream file://$PWD/#/static/

58+ ```

59+

60+5. Test the setup by visiting http://127.0.0.1:4180 or http://127.0.0.1:4180/static .

61+

62+See also [our local testing environment](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/local-environment) for a self-contained example using Docker and etcd as storage for Dex.

63+

64+#### Okta

65+

66+To configure the OIDC provider for Okta, perform the following steps:

67+

68+1. Log in to Okta using an administrative account. It is suggested you try this in preview first, `example.oktapreview.com`

69+2. (OPTIONAL) If you want to configure authorization scopes and claims to be passed on to multiple applications,

70+ you may wish to configure an authorization server for each application. Otherwise, the provided `default` will work.

71+ * Navigate to **Security** then select **API**

72+ * Click **Add Authorization Server**, if this option is not available you may require an additional license for a custom

73+ authorization server.

74+ * Fill out the **Name** with something to describe the application you are protecting. e.g. 'Example App'.

75+ * For **Audience**, pick the URL of the application you wish to protect: https://example.corp.com

76+ * Fill out a **Description**

77+ * Add any **Access Policies** you wish to configure to limit application access.

78+ * The default settings will work for other options.

79+ [See Okta documentation for more information on Authorization Servers](https://developer.okta.com/docs/guides/customize-authz-server/overview/)

80+3. Navigate to **Applications** then select **Add Application**.

81+ * Select **Web** for the **Platform** setting.

82+ * Select **OpenID Connect** and click **Create**

83+ * Pick an **Application Name** such as `Example App`.

84+ * Set the **Login redirect URI** to `https://example.corp.com`.

85+ * Under **General** set the **Allowed grant types** to `Authorization Code` and `Refresh Token`.

86+ * Leave the rest as default, taking note of the `Client ID` and `Client Secret`.

87+ * Under **Assignments** select the users or groups you wish to access your application.

88+4. Create a configuration file like the following:

89+

90+ ```

91+ provider = "oidc"

92+ redirect_url = "https://example.corp.com/oauth2/callback"

93+ oidc_issuer_url = "https://corp.okta.com/oauth2/abCd1234"

94+ upstreams = [

95+ "https://example.corp.com"

96+ ]

97+ email_domains = [

98+ "corp.com"

99+ ]

100+ client_id = "XXXXX"

101+ client_secret = "YYYYY"

102+ pass_access_token = true

103+ cookie_secret = "ZZZZZ"

104+ skip_provider_button = true

105+ ```

106+

107+The `oidc_issuer_url` is based on URL from your **Authorization Server**'s **Issuer** field in step 2, or simply

108+https://corp.okta.com. The `client_id` and `client_secret` are configured in the application settings.

109+Generate a unique `cookie_secret` to encrypt the cookie.

110+

111+Then you can start the oauth2-proxy with `./oauth2-proxy --config /etc/example.cfg`

112+

113+#### Okta - localhost

114+

115+1. Signup for developer account: https://developer.okta.com/signup/

116+2. Create New `Web` Application: https://$\{your-okta-domain\}/dev/console/apps/new

117+3. Example Application Settings for localhost:

118+ * **Name:** My Web App

119+ * **Base URIs:** http://localhost:4180/

120+ * **Login redirect URIs:** http://localhost:4180/oauth2/callback

121+ * **Logout redirect URIs:** http://localhost:4180/

122+ * **Group assignments:** `Everyone`

123+ * **Grant type allowed:** `Authorization Code` and `Refresh Token`

124+4. Make note of the `Client ID` and `Client secret`, they are needed in a future step

125+5. Make note of the **default** Authorization Server Issuer URI from: https://$\{your-okta-domain\}/admin/oauth2/as

126+6. Example config file `/etc/localhost.cfg`

127+ ```shell

128+ provider = "oidc"

129+ redirect_url = "http://localhost:4180/oauth2/callback"

130+ oidc_issuer_url = "https://$\{your-okta-domain\}/oauth2/default"

131+ upstreams = [

132+ "http://0.0.0.0:8080"

133+ ]

134+ email_domains = [

135+ "*"

136+ ]

137+ client_id = "XXX"

138+ client_secret = "YYY"

139+ pass_access_token = true

140+ cookie_secret = "ZZZ"

141+ cookie_secure = false

142+ skip_provider_button = true

143+ # Note: use the following for testing within a container

144+ # http_address = "0.0.0.0:4180"

145+ ```

146+7. Then you can start the oauth2-proxy with `./oauth2-proxy --config /etc/localhost.cfg`

docs/versioned_docs/version-7.12.x/configuration/providers/sourcehut.mdnew file+25

@@ -0,0 +1,25 @@

1+---

2+id: sourcehut

3+title: SourceHut

4+---

5+

6+1. Create a new OAuth client: https://meta.sr.ht/oauth2

7+2. Under `Redirection URI` enter the correct URL, i.e.

8+ `https://internal.yourcompany.com/oauth2/callback`

9+

10+To use the provider, start with `--provider=sourcehut`.

11+

12+If you are hosting your own SourceHut instance, make sure you set the following

13+to the appropriate URLs:

14+

15+```shell

16+ --login-url="https://<meta.your.instance>/oauth2/authorize"

17+ --redeem-url="https://<meta.your.instance>/oauth2/access-token"

18+ --profile-url="https://<meta.your.instance>/query"

19+ --validate-url="https://<meta.your.instance>/profile"

20+```

21+

22+The default configuration allows everyone with an account to authenticate.

23+Restricting access is currently only supported by

24+[email](index.md#email-authentication).

25+

docs/versioned_docs/version-7.12.x/configuration/sessions.mdnew file+99

@@ -0,0 +1,99 @@

1+---

2+id: session_storage

3+title: Session Storage

4+---

5+

6+Sessions allow a user's authentication to be tracked between multiple HTTP

7+requests to a service.

8+

9+The OAuth2 Proxy uses a Cookie to track user sessions and will store the session

10+data in one of the available session storage backends.

11+

12+At present the available backends are (as passed to `--session-store-type`):

13+- [cookie](#cookie-storage) (default)

14+- [redis](#redis-storage)

15+

16+### Cookie Storage

17+

18+The Cookie storage backend is the default backend implementation and has

19+been used in the OAuth2 Proxy historically.

20+

21+With the Cookie storage backend, all session information is stored in client

22+side cookies and transferred with each and every request.

23+

24+The following should be known when using this implementation:

25+- Since all state is stored client side, this storage backend means that the OAuth2 Proxy is completely stateless

26+- Cookies are signed server side to prevent modification client-side

27+- It is mandatory to set a `cookie-secret` which will ensure data is encrypted within the cookie data.

28+- Since multiple requests can be made concurrently to the OAuth2 Proxy, this session implementation

29+cannot lock sessions and while updating and refreshing sessions, there can be conflicts which force

30+users to re-authenticate

31+

32+

33+### Redis Storage

34+

35+The Redis Storage backend stores encrypted sessions in redis. Instead of sending all the information

36+back the client for storage, as in the [Cookie storage](#cookie-storage), a ticket is sent back

37+to the user as the cookie value instead.

38+

39+A ticket is composed as the following:

40+

41+`{CookieName}-{ticketID}.{secret}`

42+

43+Where:

44+

45+- The `CookieName` is the OAuth2 cookie name (_oauth2_proxy by default)

46+- The `ticketID` is a 128-bit random number, hex-encoded

47+- The `secret` is a 128-bit random number, base64url encoded (no padding). The secret is unique for every session.

48+- The pair of `{CookieName}-{ticketID}` comprises a ticket handle, and thus, the redis key

49+to which the session is stored. The encoded session is encrypted with the secret and stored

50+in redis via the `SETEX` command.

51+

52+Encrypting every session uniquely protects the refresh/access/id tokens stored in the session from

53+disclosure. Additionally, the browser only has to send a short Cookie with every request and not the whole JWT,

54+which can get quite big.

55+

56+Two settings are used to configure the OAuth2 Proxy cookie lifetime:

57+

58+ --cookie-refresh duration refresh the cookie after this duration; 0 to disable

59+ --cookie-expire duration expire timeframe for cookie 168h0m0s

60+

61+The "cookie-expire" value should be equal to the lifetime of the Refresh-Token that is issued by the OAuth2 authorization server.

62+If it expires earlier and is deleted by the browser, OAuth2 Proxy cannot find the stored Refresh-Tokens in Redis and thus cannot start

63+the refresh flow to get a new Access-Token. If it is longer, it might be that the old Refresh-Token will be found in Redis but has already

64+expired.

65+

66+The "cookie-refresh" value controls when OAuth2 Proxy tries to refresh an Access-Token. If it is set to "0", the

67+Access-Token will never be refreshed, even if it is already expired and a valid Refresh-Token is available. If set, OAuth2-Proxy will

68+refresh the Access-Token after this many seconds whether it is still valid or not. According to the official OAuth2.0 specification

69+Access-Tokens are not required to follow a specific format. Therefore OAuth2-Proxy cannot check for any expiry date without an

70+introspection endpoint. If an Access-Token expires and you have not set a corresponding "cookie-refresh" value, you will likely

71+encounter expiry issues.

72+

73+Caveat: It can happen that the Access-Token is valid for e.g. "1m" and a request happens after exactly "59s".

74+It would pass OAuth2 Proxy and be forwarded to the backend but is just expired when the backend tries to validate

75+it. This is especially relevant if the backend uses the JWT to make requests to other backends.

76+For this reason, it's advised to set the cookie-refresh a couple of seconds less than the Access-Token lifespan.

77+

78+Recommended settings:

79+

80+* cookie_refresh := Access-Token lifespan - 1m

81+* cookie_expire := Refresh-Token lifespan (i.e. Keycloak client_session_idle)

82+

83+#### Usage

84+

85+When using the redis store, specify `--session-store-type=redis` as well as the Redis connection URL, via

86+`--redis-connection-url=redis://host[:port][/db-number]`.

87+

88+You may also configure the store for Redis Sentinel. In this case, you will want to use the

89+`--redis-use-sentinel=true` flag, as well as configure the flags `--redis-sentinel-master-name`

90+and `--redis-sentinel-connection-urls` appropriately.

91+

92+Redis Cluster is available to be the backend store as well. To leverage it, you will need to set the

93+`--redis-use-cluster=true` flag, and configure the flags `--redis-cluster-connection-urls` appropriately.

94+

95+Note that flags `--redis-use-sentinel=true` and `--redis-use-cluster=true` are mutually exclusive.

96+

97+Note, if Redis timeout option is set to non-zero, the `--redis-connection-idle-timeout`

98+must be less than [Redis timeout option](https://redis.io/docs/reference/clients/#client-timeouts). For example: if either redis.conf includes

99+`timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14`

docs/versioned_docs/version-7.12.x/configuration/systemd_socket.mdnew file+43

@@ -0,0 +1,43 @@

1+---

2+id: systemd_socket

3+title: Systemd Socket Activation

4+---

5+

6+Pass an existing listener created by systemd.socket to oauth2-proxy.

7+

8+To do this create a socket:

9+

10+oauth2-proxy.socket

11+```

12+[Socket]

13+ListenStream=%t/oauth2.sock

14+SocketGroup=www-data

15+SocketMode=0660

16+```

17+

18+Now it's possible to call this socket from e.g. nginx:

19+```

20+server {

21+ location /oauth2/ {

22+ proxy_pass http://unix:/run/oauth2-proxy/oauth2.sock;

23+}

24+```

25+

26+The oauth2-proxy should have `--http-address=fd:3` as a parameter.

27+Here fd is case insensitive and means file descriptor. The number 3 refers to the first non-stdin/stdout/stderr file descriptor,

28+systemd-socket-activate (which is what systemd.socket uses), listens to what it is told and passes

29+the listener it created onto the process, starting with file descriptor 3.

30+

31+```

32+./oauth2-proxy \

33+ --http-address="fd:3" \

34+ --email-domain="yourcompany.com" \

35+ --upstream=http://127.0.0.1:8080/ \

36+ --cookie-secret=... \

37+ --cookie-secure=true \

38+ --provider=... \

39+ --client-id=... \

40+ --client-secret=...

41+```

42+

43+Currently TLS is not supported (but it's doable).

docs/versioned_docs/version-7.12.x/configuration/tls.mdnew file+85

@@ -0,0 +1,85 @@

1+---

2+id: tls

3+title: TLS Configuration

4+---

5+

6+There are two recommended configurations:

7+- [At OAuth2 Proxy](#terminate-tls-at-oauth2-proxy)

8+- [At Reverse Proxy](#terminate-tls-at-reverse-proxy-eg-nginx)

9+

10+### Terminate TLS at OAuth2 Proxy

11+

12+1. Configure SSL Termination with OAuth2 Proxy by providing a `--tls-cert-file=/path/to/cert.pem` and `--tls-key-file=/path/to/cert.key`.

13+

14+ The command line to run `oauth2-proxy` in this configuration would look like this:

15+

16+ ```bash

17+ ./oauth2-proxy \

18+ --email-domain="yourcompany.com" \

19+ --upstream=http://127.0.0.1:8080/ \

20+ --tls-cert-file=/path/to/cert.pem \

21+ --tls-key-file=/path/to/cert.key \

22+ --cookie-secret=... \

23+ --cookie-secure=true \

24+ --provider=... \

25+ --client-id=... \

26+ --client-secret=...

27+ ```

28+

29+2. With this configuration approach the customization of the TLS settings is limited.

30+

31+ The minimal acceptable TLS version can be set with `--tls-min-version=TLS1.3`.

32+ The defaults set `TLS1.2` as the minimal version.

33+ Regardless of the minimum version configured, `TLS1.3` is currently always used as the maximal version.

34+

35+ TLS server side cipher suites can be specified with `--tls-cipher-suite=TLS_RSA_WITH_RC4_128_SHA`.

36+ If not specified, the defaults from [`crypto/tls`](https://pkg.go.dev/crypto/tls#CipherSuites) of the currently used `go` version for building `oauth2-proxy` will be used.

37+ A complete list of valid TLS cipher suite names can be found in [`crypto/tls`](https://pkg.go.dev/crypto/tls#pkg-constants).

38+

39+### Terminate TLS at Reverse Proxy, e.g. Nginx

40+

41+1. Configure SSL Termination with [Nginx](http://nginx.org/) (example config below), Amazon ELB, Google Cloud Platform Load Balancing, or ...

42+

43+ Because `oauth2-proxy` listens on `127.0.0.1:4180` by default, to listen on all interfaces (needed when using an

44+ external load balancer like Amazon ELB or Google Platform Load Balancing) use `--http-address="0.0.0.0:4180"` or

45+ `--http-address="http://:4180"`.

46+

47+ Nginx will listen on port `443` and handle SSL connections while proxying to `oauth2-proxy` on port `4180`.

48+ `oauth2-proxy` will then authenticate requests for an upstream application. The external endpoint for this example

49+ would be `https://internal.yourcompany.com/`.

50+

51+ An example Nginx config follows. Note the use of `Strict-Transport-Security` header to pin requests to SSL

52+ via [HSTS](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security):

53+

54+ ```

55+ server {

56+ listen 443 default ssl;

57+ server_name internal.yourcompany.com;

58+ ssl_certificate /path/to/cert.pem;

59+ ssl_certificate_key /path/to/cert.key;

60+ add_header Strict-Transport-Security max-age=2592000;

61+

62+ location / {

63+ proxy_pass http://127.0.0.1:4180;

64+ proxy_set_header Host $host;

65+ proxy_set_header X-Real-IP $remote_addr;

66+ proxy_connect_timeout 1;

67+ proxy_send_timeout 30;

68+ proxy_read_timeout 30;

69+ }

70+ }

71+ ```

72+

73+2. The command line to run `oauth2-proxy` in this configuration would look like this:

74+

75+ ```bash

76+ ./oauth2-proxy \

77+ --email-domain="yourcompany.com" \

78+ --upstream=http://127.0.0.1:8080/ \

79+ --cookie-secret=... \

80+ --cookie-secure=true \

81+ --provider=... \

82+ --reverse-proxy=true \

83+ --client-id=... \

84+ --client-secret=...

85+ ```

docs/versioned_docs/version-7.12.x/features/endpoints.mdnew file+47

@@ -0,0 +1,47 @@

1+---

2+id: endpoints

3+title: Endpoints

4+---

5+

6+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.

7+

8+- /robots.txt - returns a 200 OK response that disallows all User-agents from all paths; see [robotstxt.org](http://www.robotstxt.org/) for more info

9+- /ping - returns a 200 OK response, which is intended for use with health checks

10+- /ready - returns a 200 OK response if all the underlying connections (e.g., Redis store) are connected

11+- /metrics - Metrics endpoint for Prometheus to scrape, serve on the address specified by `--metrics-address`, disabled by default

12+- /oauth2/sign_in - the login page, which also doubles as a sign-out page (it clears cookies)

13+- /oauth2/sign_out - this URL is used to clear the session cookie

14+- /oauth2/start - a URL that will redirect to start the OAuth cycle

15+- /oauth2/callback - the URL used at the end of the OAuth cycle. The oauth app will be configured with this as the callback url.

16+- /oauth2/userinfo - the URL is used to return user's email from the session in JSON format.

17+- /oauth2/auth - only returns a 202 Accepted response or a 401 Unauthorized response; for use with the [Nginx `auth_request` directive](../configuration/integration#configuring-for-use-with-the-nginx-auth_request-directive)

18+- /oauth2/static/\* - stylesheets and other dependencies used in the sign_in and error pages

19+

20+### Sign out

21+

22+To sign the user out, redirect them to `/oauth2/sign_out`. This endpoint only removes oauth2-proxy's own cookies, i.e. the user is still logged in with the authentication provider and may automatically re-login when accessing the application again. You will also need to redirect the user to the authentication provider's sign-out page afterward using the `rd` query parameter, i.e. redirect the user to something like (notice the url-encoding!):

23+

24+```

25+/oauth2/sign_out?rd=https%3A%2F%2Fmy-oidc-provider.example.com%2Fsign_out_page

26+```

27+

28+Alternatively, include the redirect URL in the `X-Auth-Request-Redirect` header:

29+

30+```

31+GET /oauth2/sign_out HTTP/1.1

32+X-Auth-Request-Redirect: https://my-oidc-provider/sign_out_page

33+...

34+```

35+

36+(The "sign_out_page" should be the [`end_session_endpoint`](https://openid.net/specs/openid-connect-session-1_0.html#rfc.section.2.1) from [the metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) if your OIDC provider supports Session Management and Discovery.)

37+

38+BEWARE that the domain you want to redirect to (`my-oidc-provider.example.com` in the example) must be added to the [`--whitelist-domain`](../configuration/overview) configuration option otherwise the redirect will be ignored. Make sure to include the actual domain and port (if needed) and not the URL (e.g "localhost:8081" instead of "http://localhost:8081").

39+

40+### Auth

41+

42+This endpoint returns 202 Accepted response or a 401 Unauthorized response.

43+

44+It can be configured using the following query parameters:

45+- `allowed_groups`: comma separated list of allowed groups

46+- `allowed_email_domains`: comma separated list of allowed email domains

47+- `allowed_emails`: comma separated list of allowed emails

docs/versioned_docs/version-7.12.x/installation.mdnew file+32

@@ -0,0 +1,32 @@

1+---

2+id: installation

3+title: Installation

4+---

5+

6+1. Choose how to deploy:

7+

8+ a. Using a [Prebuilt Binary](https://github.com/oauth2-proxy/oauth2-proxy/releases) (current release is `v7.12.0`)

9+

10+ b. Using Go to install the latest release

11+ ```bash

12+ $ go install github.com/oauth2-proxy/oauth2-proxy/v7@latest

13+ ```

14+ This will install the binary into `$GOPATH/bin`. Make sure you include `$GOPATH` in your `$PATH`. Otherwise your system won't find binaries installed via `go install`

15+

16+ c. Using a [Prebuilt Docker Image](https://quay.io/oauth2-proxy/oauth2-proxy) (AMD64, PPC64LE, S390x, ARMv6, ARMv7, and ARM64 available)

17+

18+ d. Using a [Pre-Release Nightly Docker Image](https://quay.io/oauth2-proxy/oauth2-proxy-nightly) (AMD64, PPC64LE, ARMv6, ARMv7, and ARM64 available)

19+

20+ e. Using the official [Kubernetes manifest](https://github.com/oauth2-proxy/manifests) (Helm)

21+

22+ Prebuilt binaries can be validated by extracting the file and verifying it against the `sha256sum.txt` checksum file provided for each release starting with version `v3.0.0`.

23+

24+ ```

25+ $ sha256sum -c sha256sum.txt

26+ oauth2-proxy-x.y.z.linux-amd64: OK

27+ ```

28+

29+2. [Select a Provider and Register an OAuth Application with a Provider](configuration/providers/index.md)

30+3. [Configure OAuth2 Proxy using config file, command line options, or environment variables](configuration/overview.md)

31+4. [Configure SSL or Deploy behind an SSL endpoint](configuration/tls.md) (example provided for Nginx)

32+5. [Configure OAuth2 Proxy using systemd.socket](configuration/systemd_socket.md) (example provided for Nginx/Systemd)

docs/versioned_docs/version-7.12.x/welcome.mdnew file+23

@@ -0,0 +1,23 @@

1+---

2+id: welcome

3+title: Welcome

4+hide_table_of_contents: true

5+slug: /

6+---

7+

8+

9+

10+A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others)

11+to validate accounts by email, domain or group.

12+

13+:::note

14+This repository was forked from [bitly/OAuth2_Proxy](https://github.com/bitly/oauth2_proxy) on 27/11/2018.

15+Versions v3.0.0 and up are from this fork and will have diverged from any changes in the original fork.

16+A list of changes can be seen in the [CHANGELOG](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/CHANGELOG.md).

17+:::

18+

19+

20+

21+## Architecture

22+

23+

docs/versioned_docs/version-7.13.x/behaviour.mdnew file+26

@@ -0,0 +1,26 @@

1+---

2+id: behaviour

3+title: Behaviour

4+---

5+

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

10+

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.13.x/community/contribution.mdnew file+91

@@ -0,0 +1,91 @@

1+---

2+id: contribution

3+title: Contribution Guide

4+---

5+

6+We track bugs and issues using Github.

7+

8+If you find a bug, please open an Issue. When opening an Issue or Pull Request please follow the preconfigured template and take special note of the checkboxes.

9+

10+If you want to fix a bug, add a new feature or extend existing functionality, please create a fork, create a feature branch and open a PR back to this repo.

11+Please mention open bug issue number(s) within your PR if applicable.

12+

13+We suggest using [Visual Studio Code](https://code.visualstudio.com/docs/languages/go) with the official [Go for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=golang.go) extension.

14+

15+

16+# Go version

17+

18+See the `go.mod` file in the root of this repository for the version of Go used by this project.

19+You can follow [the installation guide for Go](https://go.dev/doc/install),

20+and you can find this specific Go version on [the Go downloads page](https://go.dev/dl/).

21+

22+# Preparing your fork

23+Clone your fork, create a feature branch and update the depedencies to get started.

24+```bash

25+git clone git@github.com:<YOUR_FORK>/oauth2-proxy

26+cd oauth2-proxy

27+git branch feature/<BRANCH_NAME>

28+git push --set-upstream origin feature/<BRANCH_NAME>

29+go mod download

30+```

31+

32+

33+# Testing / Debugging

34+For starting oauth2-proxy locally open the debugging tab and create the `launch.json` and select `Go: Launch Package`.

35+

36+

37+```json

38+{

39+ "version": "0.2.0",

40+ "configurations": [

41+ {

42+ "name": "Launch OAuth2-Proxy with Dex",

43+ "type": "go",

44+ "request": "launch",

45+ "mode": "auto",

46+ "program": "${workspaceFolder}",

47+ "args": [

48+ "--config",

49+ // The following configuration contains settings for a locally deployed

50+ // upstream and dex as an idetity provider

51+ "contrib/local-environment/oauth2-proxy.cfg"

52+ ]

53+ },

54+ {

55+ "name": "Launch OAuth2-Proxy with Keycloak",

56+ "type": "go",

57+ "request": "launch",

58+ "mode": "auto",

59+ "program": "${workspaceFolder}",

60+ "args": [

61+ "--config",

62+ // The following configuration contains settings for a locally deployed

63+ // upstream and keycloak as an idetity provider

64+ "contrib/local-environment/oauth2-proxy-keycloak.cfg"

65+ ]

66+ }

67+ ]

68+}

69+```

70+

71+Before you can start your local version of oauth2-proxy, you will have to use the provided docker compose files to start a local upstream service and identity provider. We suggest using [httpbin](https://hub.docker.com/r/kennethreitz/httpbin) as your upstream for testing as it allows for request and response introspection of all things HTTP.

72+

73+Inside the `contrib/local-environment` directory you can use the `Makefile` for

74+starting different example setups:

75+

76+- Dex as your IdP: `make up` or `make down`

77+- Dex as your IdP using the alpha-config: `make alpha-config-up`

78+- Keycloak as your IdP: `make keycloak-up`

79+- Dex as your IdP & nginx reverse proxy: `make nginx-up`

80+- and many more...

81+

82+Check out the `Makefile` to see what is available.

83+

84+The username and password for all setups is usually `admin@example.com` and `password`.

85+

86+The docker compose setups expose the services with a dynamic reverse DNS resolver: localtest.me

87+

88+- OAuth2-Proxy: http://oauth2-proxy.localtest.me:4180

89+- Upstream: http://httpbin.localtest.me:8080

90+- Dex: http://dex.localtest.me:5556

91+

docs/versioned_docs/version-7.13.x/community/security.mdnew file+49

@@ -0,0 +1,49 @@

1+---

2+id: security

3+title: Security

4+---

5+

6+:::note

7+OAuth2 Proxy is a community project.

8+Maintainers do not work on this project full time, and as such,

9+while we endeavour to respond to disclosures as quickly as possible,

10+this may take longer than in projects with corporate sponsorship.

11+:::

12+

13+## Security Disclosures

14+

15+:::important

16+If you believe you have found a vulnerability within OAuth2 Proxy or any of its

17+dependencies, please do NOT open an issue or PR on GitHub, please do NOT post

18+any details publicly.

19+:::

20+

21+Security disclosures MUST be done in private.

22+If you have found an issue that you would like to bring to the attention of the

23+maintenance team for OAuth2 Proxy, please compose an email and send it to the

24+list of maintainers in our [MAINTAINERS](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/MAINTAINERS) file.

25+

26+Please include as much detail as possible.

27+Ideally, your disclosure should include:

28+- A reproducible case that can be used to demonstrate the exploit

29+- How you discovered this vulnerability

30+- A potential fix for the issue (if you have thought of one)

31+- Versions affected (if not present in master)

32+- Your GitHub ID

33+

34+### How will we respond to disclosures?

35+

36+We use [GitHub Security Advisories](https://docs.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories)

37+to privately discuss fixes for disclosed vulnerabilities.

38+If you include a GitHub ID with your disclosure we will add you as a collaborator

39+for the advisory so that you can join the discussion and validate any fixes

40+we may propose.

41+

42+For minor issues and previously disclosed vulnerabilities (typically for

43+dependencies), we may use regular PRs for fixes and forego the security advisory.

44+

45+Once a fix has been agreed upon, we will merge the fix and create a new release.

46+If we have multiple security issues in flight simultaneously, we may delay

47+merging fixes until all patches are ready.

48+We may also backport the fix to previous releases,

49+but this will be at the discretion of the maintainers.

docs/versioned_docs/version-7.13.x/configuration/alpha_config.mdnew file+568

@@ -0,0 +1,568 @@

1+---

2+id: alpha-config

3+title: Alpha Configuration

4+---

5+

6+:::warning

7+This page contains documentation for alpha features.

8+We reserve the right to make breaking changes to the features detailed within this page with no notice.

9+

10+Options described in this page may be changed, removed, renamed or moved without prior warning.

11+Please beware of this before you use alpha configuration options.

12+:::

13+

14+This page details a set of **alpha** configuration options in a new format.

15+Going forward we are intending to add structured configuration in YAML format to

16+replace the existing TOML based configuration file and flags.

17+

18+Below is a reference for the structure of the configuration, with

19+[AlphaOptions](#alphaoptions) as the root of the configuration.

20+

21+When using alpha configuration, your config file will look something like below:

22+

23+```yaml

24+upstreams:

25+ - id: ...

26+ ...: ...

27+injectRequestHeaders:

28+ - name: ...

29+ ...: ...

30+injectResponseHeaders:

31+ - name: ...

32+ ...: ...

33+```

34+

35+Please browse the [reference](#configuration-reference) below for the structure

36+of the new configuration format.

37+

38+## Using Alpha Configuration

39+

40+To use the new **alpha** configuration, generate a YAML file based on the format

41+described in the [reference](#configuration-reference) below.

42+

43+Provide the path to this file using the `--alpha-config` flag.

44+

45+:::note

46+When using the `--alpha-config` flag, some options are no longer available.

47+See [removed options](#removed-options) below for more information.

48+:::

49+

50+### Converting configuration to the new structure

51+

52+Before adding the new `--alpha-config` option, start OAuth2 Proxy using the

53+`convert-config-to-alpha` flag to convert existing configuration to the new format.

54+

55+```bash

56+oauth2-proxy --convert-config-to-alpha --config ./path/to/existing/config.cfg

57+```

58+

59+This will convert any options supported by the new format to YAML and print the

60+new configuration to `STDOUT`.

61+

62+Copy this to a new file, remove any options from your existing configuration

63+noted in [removed options](#removed-options) and then start OAuth2 Proxy using

64+the new config.

65+

66+```bash

67+oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

68+```

69+

70+## Using ENV variables in the alpha configuration

71+

72+The alpha package supports the use of environment variables in place of yaml keys, allowing sensitive values to be pulled from somewhere other than the yaml file.

73+When using environment variables, your yaml will look like this:

74+

75+```yaml

76+ providers:

77+ - provider: azure

78+ clientSecret: ${CLIENT_SECRET}

79+ ...

80+```

81+Where CLIENT_SECRET is an environment variable.

82+More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

83+

84+## Removed options

85+

86+The following flags/options and their respective environment variables are no

87+longer available when using alpha configuration:

88+

89+<!-- Legacy Upstream FlagSet -->

90+- `flush-interval`/`flush_interval`

91+- `pass-host-header`/`pass_host_header`

92+- `proxy-websockets`/`proxy_websockets`

93+- `ssl-upstream-insecure-skip-verify`/`ssl_upstream_insecure_skip_verify`

94+- `upstream`/`upstreams`

95+

96+<!-- Legacy Headers FlagSet -->

97+- `pass-basic-auth`/`pass_basic_auth`

98+- `pass-access-token`/`pass_access_token`

99+- `pass-user-headers`/`pass_user_headers`

100+- `pass-authorization-header`/`pass_authorization_header`

101+- `set-basic-auth`/`set_basic_auth`

102+- `set-xauthrequest`/`set_xauthrequest`

103+- `set-authorization-header`/`set_authorization_header`

104+- `prefer-email-to-user`/`prefer_email_to_user`

105+- `basic-auth-password`/`basic_auth_password`

106+- `skip-auth-strip-headers`/`skip_auth_strip_headers`

107+

108+<!-- Legacy provider FlagSet -->

109+- `client-id`/`client_id`

110+- `client-secret`/`client_secret`, and `client-secret-file`/`client_secret_file`

111+- `provider`

112+- `provider-display-name`/`provider_display_name`

113+- `provider-ca-file`/`provider_ca_files`

114+- `login-url`/`login_url`

115+- `redeem-url`/`redeem_url`

116+- `profile-url`/`profile_url`

117+- `resource`

118+- `validate-url`/`validate_url`

119+- `scope`

120+- `prompt`

121+- `approval-prompt`/`approval_prompt`

122+- `acr-values`/`acr_values`

123+- `user-id-claim`/`user_id_claim`

124+- `allowed-group`/`allowed_groups`

125+- `allowed-role`/`allowed_roles`

126+- `jwt-key`/`jwt_key`

127+- `jwt-key-file`/`jwt_key_file`

128+- `pubjwk-url`/`pubjwk_url`

129+

130+and all provider-specific options, i.e. any option whose name includes `oidc`,

131+`azure`, `bitbucket`, `github`, `gitlab`, `google` or `keycloak`. Attempting to

132+use any of these options via flags or via config when `--alpha-config` is

133+set will result in an error.

134+

135+:::important

136+You must remove these options before starting OAuth2 Proxy with `--alpha-config`

137+:::

138+

139+## Configuration Reference

140+

141+<!--- THIS FILE IS AUTOGENERATED!!! DO NOT EDIT!!! -->

142+

143+### ADFSOptions

144+

145+(**Appears on:** [Provider](#provider))

146+

147+

148+

149+| Field | Type | Description |

150+| ----- | ---- | ----------- |

151+| `skipScope` | _bool_ | Skip adding the scope parameter in login request<br/>Default value is 'false' |

152+

153+### AlphaOptions

154+

155+AlphaOptions contains alpha structured configuration options.

156+Usage of these options allows users to access alpha features that are not

157+available as part of the primary configuration structure for OAuth2 Proxy.

158+

159+:::warning

160+The options within this structure are considered alpha.

161+They may change between releases without notice.

162+:::

163+

164+| Field | Type | Description |

165+| ----- | ---- | ----------- |

166+| `upstreamConfig` | _[UpstreamConfig](#upstreamconfig)_ | UpstreamConfig is used to configure upstream servers.<br/>Once a user is authenticated, requests to the server will be proxied to<br/>these upstream servers based on the path mappings defined in this list. |

167+| `injectRequestHeaders` | _[[]Header](#header)_ | InjectRequestHeaders is used to configure headers that should be added<br/>to requests to upstream servers.<br/>Headers may source values from either the authenticated user's session<br/>or from a static secret value. |

168+| `injectResponseHeaders` | _[[]Header](#header)_ | InjectResponseHeaders is used to configure headers that should be added<br/>to responses from the proxy.<br/>This is typically used when using the proxy as an external authentication<br/>provider in conjunction with another proxy such as NGINX and its<br/>auth_request module.<br/>Headers may source values from either the authenticated user's session<br/>or from a static secret value. |

169+| `server` | _[Server](#server)_ | Server is used to configure the HTTP(S) server for the proxy application.<br/>You may choose to run both HTTP and HTTPS servers simultaneously.<br/>This can be done by setting the BindAddress and the SecureBindAddress simultaneously.<br/>To use the secure server you must configure a TLS certificate and key. |

170+| `metricsServer` | _[Server](#server)_ | MetricsServer is used to configure the HTTP(S) server for metrics.<br/>You may choose to run both HTTP and HTTPS servers simultaneously.<br/>This can be done by setting the BindAddress and the SecureBindAddress simultaneously.<br/>To use the secure server you must configure a TLS certificate and key. |

171+| `providers` | _[Providers](#providers)_ | Providers is used to configure your provider. **Multiple-providers is not<br/>yet working.** [This feature is tracked in<br/>#925](https://github.com/oauth2-proxy/oauth2-proxy/issues/926) |

172+

173+### AzureOptions

174+

175+(**Appears on:** [Provider](#provider))

176+

177+

178+

179+| Field | Type | Description |

180+| ----- | ---- | ----------- |

181+| `tenant` | _string_ | Tenant directs to a tenant-specific or common (tenant-independent) endpoint<br/>Default value is 'common' |

182+| `graphGroupField` | _string_ | GraphGroupField configures the group field to be used when building the groups list from Microsoft Graph<br/>Default value is 'id' |

183+

184+### BitbucketOptions

185+

186+(**Appears on:** [Provider](#provider))

187+

188+

189+

190+| Field | Type | Description |

191+| ----- | ---- | ----------- |

192+| `team` | _string_ | Team sets restrict logins to members of this team |

193+| `repository` | _string_ | Repository sets restrict logins to user with access to this repository |

194+

195+### ClaimSource

196+

197+(**Appears on:** [HeaderValue](#headervalue))

198+

199+ClaimSource allows loading a header value from a claim within the session

200+

201+| Field | Type | Description |

202+| ----- | ---- | ----------- |

203+| `claim` | _string_ | Claim is the name of the claim in the session that the value should be<br/>loaded from. Available claims: `access_token` `id_token` `created_at`<br/>`expires_on` `refresh_token` `email` `user` `groups` `preferred_username`. |

204+| `prefix` | _string_ | Prefix is an optional prefix that will be prepended to the value of the<br/>claim if it is non-empty. |

205+| `basicAuthPassword` | _[SecretSource](#secretsource)_ | BasicAuthPassword converts this claim into a basic auth header.<br/>Note the value of claim will become the basic auth username and the<br/>basicAuthPassword will be used as the password value. |

206+

207+### Duration

208+#### (`string` alias)

209+

210+(**Appears on:** [Upstream](#upstream))

211+

212+Duration is as string representation of a period of time.

213+A duration string is a is a possibly signed sequence of decimal numbers,

214+each with optional fraction and a unit suffix, such as "300ms", "-1.5h" or "2h45m".

215+Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h".

216+

217+### GitHubOptions

218+

219+(**Appears on:** [Provider](#provider))

220+

221+

222+

223+| Field | Type | Description |

224+| ----- | ---- | ----------- |

225+| `org` | _string_ | Org sets restrict logins to members of this organisation |

226+| `team` | _string_ | Team sets restrict logins to members of this team |

227+| `repo` | _string_ | Repo sets restrict logins to collaborators of this repository |

228+| `token` | _string_ | Token is the token to use when verifying repository collaborators<br/>it must have push access to the repository |

229+| `users` | _[]string_ | Users allows users with these usernames to login<br/>even if they do not belong to the specified org and team or collaborators |

230+

231+### GitLabOptions

232+

233+(**Appears on:** [Provider](#provider))

234+

235+

236+

237+| Field | Type | Description |

238+| ----- | ---- | ----------- |

239+| `group` | _[]string_ | Group sets restrict logins to members of this group |

240+| `projects` | _[]string_ | Projects restricts logins to members of these projects |

241+

242+### GoogleOptions

243+

244+(**Appears on:** [Provider](#provider))

245+

246+

247+

248+| Field | Type | Description |

249+| ----- | ---- | ----------- |

250+| `group` | _[]string_ | Groups sets restrict logins to members of this Google group |

251+| `adminEmail` | _string_ | AdminEmail is the Google admin to impersonate for api calls |

252+| `serviceAccountJson` | _string_ | ServiceAccountJSON is the path to the service account json credentials |

253+| `useApplicationDefaultCredentials` | _bool_ | UseApplicationDefaultCredentials is a boolean whether to use Application Default Credentials instead of a ServiceAccountJSON |

254+| `targetPrincipal` | _string_ | TargetPrincipal is the Google Service Account used for Application Default Credentials |

255+| `useOrganizationID` | _bool_ | UseOrganizationId indicates whether to use the organization ID as the UserName claim |

256+| `adminAPIUserScope` | _string_ | admin scope needed for fetching user organization information from admin api, can be one of cloud, user or defaults to readonly |

257+

258+### Header

259+

260+(**Appears on:** [AlphaOptions](#alphaoptions))

261+

262+Header represents an individual header that will be added to a request or

263+response header.

264+

265+| Field | Type | Description |

266+| ----- | ---- | ----------- |

267+| `name` | _string_ | Name is the header name to be used for this set of values.<br/>Names should be unique within a list of Headers. |

268+| `preserveRequestValue` | _bool_ | PreserveRequestValue determines whether any values for this header<br/>should be preserved for the request to the upstream server.<br/>This option only applies to injected request headers.<br/>Defaults to false (headers that match this header will be stripped). |

269+| `InsecureSkipHeaderNormalization` | _bool_ | InsecureSkipHeaderNormalization disables normalizing the header name<br/>According to RFC 7230 Section 3.2 there aren't any rules about<br/>capitalization of header names, but the standard practice is to use<br/>Title-Case (e.g. X-Forwarded-For). By default, header names will be<br/>normalized to Title-Case and any incoming headers that match will be<br/>treated as the same header. Additionally underscores (_) in header names<br/>will be converted to dashes (-) when normalizing.<br/>Defaults to false (header names will be normalized). |

270+| `values` | _[[]HeaderValue](#headervalue)_ | Values contains the desired values for this header |

271+

272+### HeaderValue

273+

274+(**Appears on:** [Header](#header))

275+

276+HeaderValue represents a single header value and the sources that can

277+make up the header value

278+

279+| Field | Type | Description |

280+| ----- | ---- | ----------- |

281+| `value` | _[]byte_ | Value expects a base64 encoded string value. |

282+| `fromEnv` | _string_ | FromEnv expects the name of an environment variable. |

283+| `fromFile` | _string_ | FromFile expects a path to a file containing the secret value. |

284+| `claim` | _string_ | Claim is the name of the claim in the session that the value should be<br/>loaded from. Available claims: `access_token` `id_token` `created_at`<br/>`expires_on` `refresh_token` `email` `user` `groups` `preferred_username`. |

285+| `prefix` | _string_ | Prefix is an optional prefix that will be prepended to the value of the<br/>claim if it is non-empty. |

286+| `basicAuthPassword` | _[SecretSource](#secretsource)_ | BasicAuthPassword converts this claim into a basic auth header.<br/>Note the value of claim will become the basic auth username and the<br/>basicAuthPassword will be used as the password value. |

287+

288+### KeycloakOptions

289+

290+(**Appears on:** [Provider](#provider))

291+

292+

293+

294+| Field | Type | Description |

295+| ----- | ---- | ----------- |

296+| `groups` | _[]string_ | Group enables to restrict login to members of indicated group |

297+| `roles` | _[]string_ | Role enables to restrict login to users with role (only available when using the keycloak-oidc provider) |

298+

299+### LoginGovOptions

300+

301+(**Appears on:** [Provider](#provider))

302+

303+

304+

305+| Field | Type | Description |

306+| ----- | ---- | ----------- |

307+| `jwtKey` | _string_ | JWTKey is a private key in PEM format used to sign JWT, |

308+| `jwtKeyFile` | _string_ | JWTKeyFile is a path to the private key file in PEM format used to sign the JWT |

309+| `pubjwkURL` | _string_ | PubJWKURL is the JWK pubkey access endpoint |

310+

311+### LoginURLParameter

312+

313+(**Appears on:** [Provider](#provider))

314+

315+LoginURLParameter is the configuration for a single query parameter that

316+can be passed through from the `/oauth2/start` endpoint to the IdP login

317+URL. The "default" option specifies the default value or values (if any)

318+that will be passed to the IdP for this parameter, and "allow" is a list

319+of options for ways in which this parameter can be set or overridden via

320+the query string to `/oauth2/start`.

321+If _only_ a default is specified and no "allow" then the parameter is

322+effectively fixed - the default value will always be used and anything

323+passed to the start URL will be ignored. If _only_ "allow" is specified

324+but no default then the parameter will only be passed on to the IdP if

325+the caller provides it, and no value will be sent otherwise.

326+

327+Examples:

328+

329+# A parameter whose value is fixed

330+

331+```

332+name: organization

333+default:

334+- myorg

335+```

336+

337+A parameter that is not passed by default, but may be set to one of a

338+fixed set of values

339+

340+```

341+name: prompt

342+allow:

343+- value: login

344+- value: consent

345+- value: select_account

346+```

347+

348+A parameter that is passed by default but may be overridden by one of

349+a fixed set of values

350+

351+```

352+name: prompt

353+default: ["login"]

354+allow:

355+- value: consent

356+- value: select_account

357+```

358+

359+A parameter that may be overridden, but only by values that match a

360+regular expression. For example to restrict `login_hint` to email

361+addresses in your organization's domain:

362+

363+```

364+name: login_hint

365+allow:

366+- pattern: '^[^@]*@example\.com$'

367+# this allows at most one "@" sign, and requires "example.com" domain.

368+```

369+

370+Note that the YAML rules around exactly which characters are allowed

371+and/or require escaping in different types of string literals are

372+convoluted. For regular expressions the single quoted form is simplest

373+as backslash is not considered to be an escape character. Alternatively

374+use the "chomped block" format `|-`:

375+

376+```

377+ - pattern: |-

378+ ^[^@]*@example\.com$

379+

380+```

381+

382+The hyphen is important, a `|` block would have a trailing newline

383+character.

384+

385+| Field | Type | Description |

386+| ----- | ---- | ----------- |

387+| `name` | _string_ | Name specifies the name of the query parameter. |

388+| `default` | _[]string_ | _(Optional)_ Default specifies a default value or values that will be<br/>passed to the IdP if not overridden. |

389+| `allow` | _[[]URLParameterRule](#urlparameterrule)_ | _(Optional)_ Allow specifies rules about how the default (if any) may be<br/>overridden via the query string to `/oauth2/start`. Only<br/>values that match one or more of the allow rules will be<br/>forwarded to the IdP. |

390+

391+### MicrosoftEntraIDOptions

392+

393+(**Appears on:** [Provider](#provider))

394+

395+

396+

397+| Field | Type | Description |

398+| ----- | ---- | ----------- |

399+| `allowedTenants` | _[]string_ | AllowedTenants is a list of allowed tenants. In case of multi-tenant apps, incoming tokens are<br/>issued by different issuers and OIDC issuer verification needs to be disabled.<br/>When not specified, all tenants are allowed. Redundant for single-tenant apps<br/>(regular ID token validation matches the issuer). |

400+| `federatedTokenAuth` | _bool_ | FederatedTokenAuth enable oAuth2 client authentication with federated token projected<br/>by Entra Workload Identity plugin, instead of client secret. |

401+

402+### OIDCOptions

403+

404+(**Appears on:** [Provider](#provider))

405+

406+

407+

408+| Field | Type | Description |

409+| ----- | ---- | ----------- |

410+| `issuerURL` | _string_ | IssuerURL is the OpenID Connect issuer URL<br/>eg: https://accounts.google.com |

411+| `insecureAllowUnverifiedEmail` | _bool_ | InsecureAllowUnverifiedEmail prevents failures if an email address in an id_token is not verified<br/>default set to 'false' |

412+| `insecureSkipIssuerVerification` | _bool_ | InsecureSkipIssuerVerification skips verification of ID token issuers. When false, ID Token Issuers must match the OIDC discovery URL<br/>default set to 'false' |

413+| `insecureSkipNonce` | _bool_ | InsecureSkipNonce skips verifying the ID Token's nonce claim that must match<br/>the random nonce sent in the initial OAuth flow. Otherwise, the nonce is checked<br/>after the initial OAuth redeem & subsequent token refreshes.<br/>default set to 'true'<br/>Warning: In a future release, this will change to 'false' by default for enhanced security. |

414+| `skipDiscovery` | _bool_ | SkipDiscovery allows to skip OIDC discovery and use manually supplied Endpoints<br/>default set to 'false' |

415+| `jwksURL` | _string_ | JwksURL is the OpenID Connect JWKS URL<br/>eg: https://www.googleapis.com/oauth2/v3/certs |

416+| `publicKeyFiles` | _[]string_ | PublicKeyFiles is a list of paths pointing to public key files in PEM format to use<br/>for verifying JWT tokens |

417+| `emailClaim` | _string_ | EmailClaim indicates which claim contains the user email,<br/>default set to 'email' |

418+| `groupsClaim` | _string_ | GroupsClaim indicates which claim contains the user groups<br/>default set to 'groups' |

419+| `userIDClaim` | _string_ | UserIDClaim indicates which claim contains the user ID<br/>default set to 'email' |

420+| `audienceClaims` | _[]string_ | AudienceClaim allows to define any claim that is verified against the client id<br/>By default `aud` claim is used for verification. |

421+| `extraAudiences` | _[]string_ | ExtraAudiences is a list of additional audiences that are allowed<br/>to pass verification in addition to the client id. |

422+

423+### Provider

424+

425+(**Appears on:** [Providers](#providers))

426+

427+Provider holds all configuration for a single provider

428+

429+| Field | Type | Description |

430+| ----- | ---- | ----------- |

431+| `clientID` | _string_ | ClientID is the OAuth Client ID that is defined in the provider<br/>This value is required for all providers. |

432+| `clientSecret` | _string_ | ClientSecret is the OAuth Client Secret that is defined in the provider<br/>This value is required for all providers. |

433+| `clientSecretFile` | _string_ | ClientSecretFile is the name of the file<br/>containing the OAuth Client Secret, it will be used if ClientSecret is not set. |

434+| `keycloakConfig` | _[KeycloakOptions](#keycloakoptions)_ | KeycloakConfig holds all configurations for Keycloak provider. |

435+| `azureConfig` | _[AzureOptions](#azureoptions)_ | AzureConfig holds all configurations for Azure provider. |

436+| `microsoftEntraIDConfig` | _[MicrosoftEntraIDOptions](#microsoftentraidoptions)_ | MicrosoftEntraIDConfig holds all configurations for Entra ID provider. |

437+| `ADFSConfig` | _[ADFSOptions](#adfsoptions)_ | ADFSConfig holds all configurations for ADFS provider. |

438+| `bitbucketConfig` | _[BitbucketOptions](#bitbucketoptions)_ | BitbucketConfig holds all configurations for Bitbucket provider. |

439+| `githubConfig` | _[GitHubOptions](#githuboptions)_ | GitHubConfig holds all configurations for GitHubC provider. |

440+| `gitlabConfig` | _[GitLabOptions](#gitlaboptions)_ | GitLabConfig holds all configurations for GitLab provider. |

441+| `googleConfig` | _[GoogleOptions](#googleoptions)_ | GoogleConfig holds all configurations for Google provider. |

442+| `oidcConfig` | _[OIDCOptions](#oidcoptions)_ | OIDCConfig holds all configurations for OIDC provider<br/>or providers utilize OIDC configurations. |

443+| `loginGovConfig` | _[LoginGovOptions](#logingovoptions)_ | LoginGovConfig holds all configurations for LoginGov provider. |

444+| `id` | _string_ | ID should be a unique identifier for the provider.<br/>This value is required for all providers. |

445+| `provider` | _[ProviderType](#providertype)_ | Type is the OAuth provider<br/>must be set from the supported providers group,<br/>otherwise 'Google' is set as default |

446+| `name` | _string_ | Name is the providers display name<br/>if set, it will be shown to the users in the login page. |

447+| `caFiles` | _[]string_ | CAFiles is a list of paths to CA certificates that should be used when connecting to the provider.<br/>If not specified, the default Go trust sources are used instead |

448+| `useSystemTrustStore` | _bool_ | UseSystemTrustStore determines if your custom CA files and the system trust store are used<br/>If set to true, your custom CA files and the system trust store are used otherwise only your custom CA files. |

449+| `loginURL` | _string_ | LoginURL is the authentication endpoint |

450+| `loginURLParameters` | _[[]LoginURLParameter](#loginurlparameter)_ | LoginURLParameters defines the parameters that can be passed from the start URL to the IdP login URL |

451+| `authRequestResponseMode` | _string_ | AuthRequestResponseMode defines the response mode to request during authorization request |

452+| `redeemURL` | _string_ | RedeemURL is the token redemption endpoint |

453+| `profileURL` | _string_ | ProfileURL is the profile access endpoint |

454+| `skipClaimsFromProfileURL` | _bool_ | SkipClaimsFromProfileURL allows to skip request to Profile URL for resolving claims not present in id_token<br/>default set to 'false' |

455+| `resource` | _string_ | ProtectedResource is the resource that is protected (Azure AD and ADFS only) |

456+| `validateURL` | _string_ | ValidateURL is the access token validation endpoint |

457+| `scope` | _string_ | Scope is the OAuth scope specification |

458+| `allowedGroups` | _[]string_ | AllowedGroups is a list of restrict logins to members of this group |

459+| `code_challenge_method` | _string_ | The code challenge method |

460+| `backendLogoutURL` | _string_ | URL to call to perform backend logout, `{id_token}` would be replaced by the actual `id_token` if available in the session |

461+

462+### ProviderType

463+#### (`string` alias)

464+

465+(**Appears on:** [Provider](#provider))

466+

467+ProviderType is used to enumerate the different provider type options

468+Valid options are: adfs, azure, bitbucket, digitalocean facebook, github,

469+gitlab, google, keycloak, keycloak-oidc, linkedin, login.gov, nextcloud

470+and oidc.

471+

472+### Providers

473+

474+#### ([[]Provider](#provider) alias)

475+

476+(**Appears on:** [AlphaOptions](#alphaoptions))

477+

478+The provider can be selected using the `provider` configuration value, or

479+set in the [`providers` array using

480+AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers).

481+However, [**the feature to implement multiple providers is not

482+complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

483+

484+### SecretSource

485+

486+(**Appears on:** [ClaimSource](#claimsource), [HeaderValue](#headervalue), [TLS](#tls))

487+

488+SecretSource references an individual secret value.

489+Only one source within the struct should be defined at any time.

490+

491+| Field | Type | Description |

492+| ----- | ---- | ----------- |

493+| `value` | _[]byte_ | Value expects a base64 encoded string value. |

494+| `fromEnv` | _string_ | FromEnv expects the name of an environment variable. |

495+| `fromFile` | _string_ | FromFile expects a path to a file containing the secret value. |

496+

497+### Server

498+

499+(**Appears on:** [AlphaOptions](#alphaoptions))

500+

501+Server represents the configuration for an HTTP(S) server

502+

503+| Field | Type | Description |

504+| ----- | ---- | ----------- |

505+| `BindAddress` | _string_ | BindAddress is the address on which to serve traffic.<br/>Leave blank or set to "-" to disable. |

506+| `SecureBindAddress` | _string_ | SecureBindAddress is the address on which to serve secure traffic.<br/>Leave blank or set to "-" to disable. |

507+| `TLS` | _[TLS](#tls)_ | TLS contains the information for loading the certificate and key for the<br/>secure traffic and further configuration for the TLS server. |

508+

509+### TLS

510+

511+(**Appears on:** [Server](#server))

512+

513+TLS contains the information for loading a TLS certificate and key

514+as well as an optional minimal TLS version that is acceptable.

515+

516+| Field | Type | Description |

517+| ----- | ---- | ----------- |

518+| `Key` | _[SecretSource](#secretsource)_ | Key is the TLS key data to use.<br/>Typically this will come from a file. |

519+| `Cert` | _[SecretSource](#secretsource)_ | Cert is the TLS certificate data to use.<br/>Typically this will come from a file. |

520+| `MinVersion` | _string_ | MinVersion is the minimal TLS version that is acceptable.<br/>E.g. Set to "TLS1.3" to select TLS version 1.3 |

521+| `CipherSuites` | _[]string_ | CipherSuites is a list of TLS cipher suites that are allowed.<br/>E.g.:<br/>- TLS_RSA_WITH_RC4_128_SHA<br/>- TLS_RSA_WITH_AES_256_GCM_SHA384<br/>If not specified, the default Go safe cipher list is used.<br/>List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). |

522+

523+### URLParameterRule

524+

525+(**Appears on:** [LoginURLParameter](#loginurlparameter))

526+

527+URLParameterRule represents a rule by which query parameters

528+passed to the `/oauth2/start` endpoint are checked to determine whether

529+they are valid overrides for the given parameter passed to the IdP's

530+login URL. Either Value or Pattern should be supplied, not both.

531+

532+| Field | Type | Description |

533+| ----- | ---- | ----------- |

534+| `value` | _string_ | A Value rule matches just this specific value |

535+| `pattern` | _string_ | A Pattern rule gives a regular expression that must be matched by<br/>some substring of the value. The expression is _not_ automatically<br/>anchored to the start and end of the value, if you _want_ to restrict<br/>the whole parameter value you must anchor it yourself with `^` and `$`. |

536+

537+### Upstream

538+

539+(**Appears on:** [UpstreamConfig](#upstreamconfig))

540+

541+Upstream represents the configuration for an upstream server.

542+Requests will be proxied to this upstream if the path matches the request path.

543+

544+| Field | Type | Description |

545+| ----- | ---- | ----------- |

546+| `id` | _string_ | ID should be a unique identifier for the upstream.<br/>This value is required for all upstreams. |

547+| `path` | _string_ | Path is used to map requests to the upstream server.<br/>The closest match will take precedence and all Paths must be unique.<br/>Path can also take a pattern when used with RewriteTarget.<br/>Path segments can be captured and matched using regular experessions.<br/>Eg:<br/>- `^/foo$`: Match only the explicit path `/foo`<br/>- `^/bar/$`: Match any path prefixed with `/bar/`<br/>- `^/baz/(.*)$`: Match any path prefixed with `/baz` and capture the remaining path for use with RewriteTarget |

548+| `rewriteTarget` | _string_ | RewriteTarget allows users to rewrite the request path before it is sent to<br/>the upstream server (for an HTTP/HTTPS upstream) or mapped to the filesystem<br/>(for a `file:` upstream).<br/>Use the Path to capture segments for reuse within the rewrite target.<br/>Eg: With a Path of `^/baz/(.*)`, a RewriteTarget of `/foo/$1` would rewrite<br/>the request `/baz/abc/123` to `/foo/abc/123` before proxying to the<br/>upstream server. Or if the upstream were `file:///app`, a request for<br/>`/baz/info.html` would return the contents of the file `/app/foo/info.html`. |

549+| `uri` | _string_ | The URI of the upstream server. This may be an HTTP(S) server of a File<br/>based URL. It may include a path, in which case all requests will be served<br/>under that path.<br/>Eg:<br/>- http://localhost:8080<br/>- https://service.localhost<br/>- https://service.localhost/path<br/>- file://host/path<br/>If the URI's path is "/base" and the incoming request was for "/dir",<br/>the upstream request will be for "/base/dir". |

550+| `insecureSkipTLSVerify` | _bool_ | InsecureSkipTLSVerify will skip TLS verification of upstream HTTPS hosts.<br/>This option is insecure and will allow potential Man-In-The-Middle attacks<br/>between OAuth2 Proxy and the upstream server.<br/>Defaults to false. |

551+| `static` | _bool_ | Static will make all requests to this upstream have a static response.<br/>The response will have a body of "Authenticated" and a response code<br/>matching StaticCode.<br/>If StaticCode is not set, the response will return a 200 response. |

552+| `staticCode` | _int_ | StaticCode determines the response code for the Static response.<br/>This option can only be used with Static enabled. |

553+| `flushInterval` | _[Duration](#duration)_ | FlushInterval is the period between flushing the response buffer when<br/>streaming response from the upstream.<br/>Defaults to 1 second. |

554+| `passHostHeader` | _bool_ | PassHostHeader determines whether the request host header should be proxied<br/>to the upstream server.<br/>Defaults to true. |

555+| `proxyWebSockets` | _bool_ | ProxyWebSockets enables proxying of websockets to upstream servers<br/>Defaults to true. |

556+| `timeout` | _[Duration](#duration)_ | Timeout is the maximum duration the server will wait for a response from the upstream server.<br/>Defaults to 30 seconds. |

557+| `disableKeepAlives` | _bool_ | DisableKeepAlives disables HTTP keep-alive connections to the upstream server.<br/>Defaults to false. |

558+

559+### UpstreamConfig

560+

561+(**Appears on:** [AlphaOptions](#alphaoptions))

562+

563+UpstreamConfig is a collection of definitions for upstream servers.

564+

565+| Field | Type | Description |

566+| ----- | ---- | ----------- |

567+| `proxyRawPath` | _bool_ | ProxyRawPath will pass the raw url path to upstream allowing for urls<br/>like: "/%2F/" which would otherwise be redirected to "/" |

568+| `upstreams` | _[[]Upstream](#upstream)_ | Upstreams represents the configuration for the upstream servers.<br/>Requests will be proxied to this upstream if the path matches the request path. |

docs/versioned_docs/version-7.13.x/configuration/alpha_config.md.tmplnew file+139

@@ -0,0 +1,139 @@

1+---

2+id: alpha-config

3+title: Alpha Configuration

4+---

5+

6+:::warning

7+This page contains documentation for alpha features.

8+We reserve the right to make breaking changes to the features detailed within this page with no notice.

9+

10+Options described in this page may be changed, removed, renamed or moved without prior warning.

11+Please beware of this before you use alpha configuration options.

12+:::

13+

14+This page details a set of **alpha** configuration options in a new format.

15+Going forward we are intending to add structured configuration in YAML format to

16+replace the existing TOML based configuration file and flags.

17+

18+Below is a reference for the structure of the configuration, with

19+[AlphaOptions](#alphaoptions) as the root of the configuration.

20+

21+When using alpha configuration, your config file will look something like below:

22+

23+```yaml

24+upstreams:

25+ - id: ...

26+ ...: ...

27+injectRequestHeaders:

28+ - name: ...

29+ ...: ...

30+injectResponseHeaders:

31+ - name: ...

32+ ...: ...

33+```

34+

35+Please browse the [reference](#configuration-reference) below for the structure

36+of the new configuration format.

37+

38+## Using Alpha Configuration

39+

40+To use the new **alpha** configuration, generate a YAML file based on the format

41+described in the [reference](#configuration-reference) below.

42+

43+Provide the path to this file using the `--alpha-config` flag.

44+

45+:::note

46+When using the `--alpha-config` flag, some options are no longer available.

47+See [removed options](#removed-options) below for more information.

48+:::

49+

50+### Converting configuration to the new structure

51+

52+Before adding the new `--alpha-config` option, start OAuth2 Proxy using the

53+`convert-config-to-alpha` flag to convert existing configuration to the new format.

54+

55+```bash

56+oauth2-proxy --convert-config-to-alpha --config ./path/to/existing/config.cfg

57+```

58+

59+This will convert any options supported by the new format to YAML and print the

60+new configuration to `STDOUT`.

61+

62+Copy this to a new file, remove any options from your existing configuration

63+noted in [removed options](#removed-options) and then start OAuth2 Proxy using

64+the new config.

65+

66+```bash

67+oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

68+```

69+

70+## Using ENV variables in the alpha configuration

71+

72+The alpha package supports the use of environment variables in place of yaml keys, allowing sensitive values to be pulled from somewhere other than the yaml file.

73+When using environment variables, your yaml will look like this:

74+

75+```yaml

76+ providers:

77+ - provider: azure

78+ clientSecret: ${CLIENT_SECRET}

79+ ...

80+```

81+Where CLIENT_SECRET is an environment variable.

82+More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

83+

84+## Removed options

85+

86+The following flags/options and their respective environment variables are no

87+longer available when using alpha configuration:

88+

89+<!-- Legacy Upstream FlagSet -->

90+- `flush-interval`/`flush_interval`

91+- `pass-host-header`/`pass_host_header`

92+- `proxy-websockets`/`proxy_websockets`

93+- `ssl-upstream-insecure-skip-verify`/`ssl_upstream_insecure_skip_verify`

94+- `upstream`/`upstreams`

95+

96+<!-- Legacy Headers FlagSet -->

97+- `pass-basic-auth`/`pass_basic_auth`

98+- `pass-access-token`/`pass_access_token`

99+- `pass-user-headers`/`pass_user_headers`

100+- `pass-authorization-header`/`pass_authorization_header`

101+- `set-basic-auth`/`set_basic_auth`

102+- `set-xauthrequest`/`set_xauthrequest`

103+- `set-authorization-header`/`set_authorization_header`

104+- `prefer-email-to-user`/`prefer_email_to_user`

105+- `basic-auth-password`/`basic_auth_password`

106+- `skip-auth-strip-headers`/`skip_auth_strip_headers`

107+

108+<!-- Legacy provider FlagSet -->

109+- `client-id`/`client_id`

110+- `client-secret`/`client_secret`, and `client-secret-file`/`client_secret_file`

111+- `provider`

112+- `provider-display-name`/`provider_display_name`

113+- `provider-ca-file`/`provider_ca_files`

114+- `login-url`/`login_url`

115+- `redeem-url`/`redeem_url`

116+- `profile-url`/`profile_url`

117+- `resource`

118+- `validate-url`/`validate_url`

119+- `scope`

120+- `prompt`

121+- `approval-prompt`/`approval_prompt`

122+- `acr-values`/`acr_values`

123+- `user-id-claim`/`user_id_claim`

124+- `allowed-group`/`allowed_groups`

125+- `allowed-role`/`allowed_roles`

126+- `jwt-key`/`jwt_key`

127+- `jwt-key-file`/`jwt_key_file`

128+- `pubjwk-url`/`pubjwk_url`

129+

130+and all provider-specific options, i.e. any option whose name includes `oidc`,

131+`azure`, `bitbucket`, `github`, `gitlab`, `google` or `keycloak`. Attempting to

132+use any of these options via flags or via config when `--alpha-config` is

133+set will result in an error.

134+

135+:::important

136+You must remove these options before starting OAuth2 Proxy with `--alpha-config`

137+:::

138+

139+## Configuration Reference

docs/versioned_docs/version-7.13.x/configuration/integrations/caddy.mdnew file+63

@@ -0,0 +1,63 @@

1+---

2+id: caddy

3+title: Caddy

4+---

5+

6+Integrate OAuth2 Proxy with Caddy v2 using the `forward_auth` directive.

7+

8+**Key features:**

9+- Simple forward_auth setup

10+- Automatic header handling

11+- Custom error handling and redirects

12+

13+## Configuring for use with the Caddy (v2) `forward_auth` directive

14+

15+The [Caddy `forward_auth` directive](https://caddyserver.com/docs/caddyfile/directives/forward_auth) allows Caddy to authenticate requests via the `oauth2-proxy`'s `/auth`.

16+

17+This example is for a simple reverse proxy setup where the `/oauth2/` path is kept under the same domain and failed auth requests (401 status returned) will be caught and redirected to the `sign_in` endpoint.

18+

19+**Following options need to be set on `oauth2-proxy`:**

20+- `--reverse-proxy=true`: Enables the use of `X-Forwarded-*` headers to determine redirects correctly

21+

22+```nginx title="Caddyfile"

23+example.com {

24+ # Requests to /oauth2/* are proxied to oauth2-proxy without authentication.

25+ # You can't use `reverse_proxy /oauth2/* oauth2-proxy.internal:4180` here because the reverse_proxy directive has lower precedence than the handle directive.

26+ handle /oauth2/* {

27+ reverse_proxy oauth2-proxy.internal:4180 {

28+ # oauth2-proxy requires the X-Real-IP and X-Forwarded-{Proto,Host,Uri} headers.

29+ # The reverse_proxy directive automatically sets X-Forwarded-{For,Proto,Host} headers.

30+ header_up X-Real-IP {remote_host}

31+ header_up X-Forwarded-Uri {uri}

32+ }

33+ }

34+

35+ # Requests to other paths are first processed by oauth2-proxy for authentication.

36+ handle {

37+ forward_auth oauth2-proxy.internal:4180 {

38+ uri /oauth2/auth

39+

40+ # oauth2-proxy requires the X-Real-IP and X-Forwarded-{Proto,Host,Uri} headers.

41+ # The forward_auth directive automatically sets the X-Forwarded-{For,Proto,Host,Method,Uri} headers.

42+ header_up X-Real-IP {remote_host}

43+

44+ # If needed, you can copy headers from the oauth2-proxy response to the request sent to the upstream.

45+ # Make sure to configure the --set-xauthrequest flag to enable this feature.

46+ #copy_headers X-Auth-Request-User X-Auth-Request-Email

47+

48+ # If oauth2-proxy returns a 401 status, redirect the client to the sign-in page.

49+ @error status 401

50+ handle_response @error {

51+ redir * /oauth2/sign_in?rd={scheme}://{host}{uri}

52+ }

53+ }

54+

55+ # If oauth2-proxy returns a 2xx status, the request is then proxied to the upstream.

56+ reverse_proxy upstream.internal:3000

57+ }

58+}

59+```

60+

61+:::note

62+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

63+:::

docs/versioned_docs/version-7.13.x/configuration/integrations/headlamp.mdnew file+105

@@ -0,0 +1,105 @@

1+---

2+id: headlamp

3+title: Headlamp

4+---

5+

6+Modern, actively maintained Kubernetes web UI with OAuth2 Proxy integration examples.

7+

8+**Key features:**

9+- Active development and maintenance

10+- Modern, intuitive interface

11+- Multi-cluster support

12+- Plugin system

13+- Works with all OAuth2 providers

14+

15+## Configuring for use with Headlamp

16+

17+[Headlamp](https://headlamp.dev/) is a modern, user-friendly Kubernetes web UI that can be integrated with OAuth2 Proxy for authentication. This is a recommended alternative to the deprecated Kubernetes Dashboard.

18+

19+### Architecture

20+

21+```

22+User → Ingress → OAuth2 Proxy → Authentication Provider (e.g., Azure Entra ID)

23+ ↓

24+ Headlamp

25+```

26+

27+### Prerequisites

28+

29+- Kubernetes cluster (e.g., AKS, EKS, GKE, or self-hosted)

30+- Headlamp installed in the cluster

31+- OAuth2 provider configured (Azure Entra ID, Google, GitHub, etc.)

32+- Ingress controller (Nginx, Traefik, etc.)

33+

34+### Configuration Overview

35+

36+When integrating Headlamp with OAuth2 Proxy, the OAuth2 Proxy acts as a reverse proxy in front of Headlamp:

37+

38+1. User requests access to Headlamp

39+2. Ingress forwards to OAuth2 Proxy

40+3. OAuth2 Proxy authenticates the user via the OAuth2 provider

41+4. After successful authentication, OAuth2 Proxy proxies requests to Headlamp

42+5. Headlamp receives the authenticated user information via headers

43+

44+### OAuth2 Proxy Configuration

45+

46+Configure OAuth2 Proxy to proxy to the Headlamp service:

47+

48+```yaml

49+upstreamConfig:

50+ upstreams:

51+ - id: headlamp

52+ path: /

53+ uri: http://headlamp-service.headlamp-namespace.svc.cluster.local:4466

54+```

55+

56+Enable the necessary headers:

57+

58+```yaml

59+extraArgs:

60+ reverse-proxy: true

61+ pass-authorization-header: true

62+ set-xauthrequest: true

63+ email-domain: "*" # Or restrict to your organization

64+```

65+

66+### Example with Azure Entra ID on AKS

67+

68+For detailed instructions on deploying Headlamp with OAuth2 Proxy on Azure Kubernetes Service using Azure Entra ID, see the official Headlamp documentation:

69+

70+https://headlamp.dev/docs/latest/installation/in-cluster/aks-cluster-oauth/

71+

72+Key steps include:

73+

74+1. **Set up AKS with OIDC**: Enable Microsoft Entra ID authentication with Kubernetes RBAC

75+2. **Create Azure App Registration**: Configure redirect URI and create client secret

76+3. **Deploy Headlamp**: Install Headlamp via Helm in your cluster

77+4. **Deploy OAuth2 Proxy**: Configure OAuth2 Proxy with Entra ID provider settings and upstream pointing to Headlamp

78+5. **Configure Ingress**: Set up Ingress to route traffic through OAuth2 Proxy to Headlamp

79+6. **Set RBAC Policies**: Apply Kubernetes RBAC bindings based on users or groups

80+

81+### Integration with Other Providers

82+

83+The same integration pattern works with other OAuth2 providers supported by OAuth2 Proxy:

84+

85+- **Google**: Use the Google provider configuration

86+- **GitHub**: Use the GitHub provider configuration

87+- **GitLab**: Use the GitLab provider configuration

88+- **Keycloak**: Use the Keycloak OIDC provider configuration

89+- **Any OIDC Provider**: Use the generic OIDC provider configuration

90+

91+For provider-specific configuration examples, see the [OAuth Provider Configuration](../providers/index.md) documentation.

92+

93+### Benefits Over Kubernetes Dashboard

94+

95+Headlamp offers several advantages:

96+

97+- **Active Development**: Headlamp is actively maintained and developed

98+- **Modern UI**: Clean, intuitive interface with better UX

99+- **Plugin System**: Extensible with custom plugins

100+- **Multi-cluster Support**: Built-in support for managing multiple clusters

101+- **Desktop App**: Available as both web UI and desktop application

102+

103+:::note

104+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

105+:::

docs/versioned_docs/version-7.13.x/configuration/integrations/index.mdnew file+41

@@ -0,0 +1,41 @@

1+---

2+id: index

3+title: Integrations

4+---

5+

6+This section provides configuration examples for integrating OAuth2 Proxy with various reverse proxies, ingress controllers, and Kubernetes web UIs.

7+

8+## Reverse Proxies and Ingress Controllers

9+

10+OAuth2 Proxy can be integrated with popular reverse proxies and ingress controllers to add authentication to your applications:

11+

12+- [Nginx](nginx.md)

13+- [Traefik](traefik.md)

14+- [caddy](caddy.md)

15+

16+## Kubernetes Web UIs

17+

18+OAuth2 Proxy can also be used to add authentication to Kubernetes web user interfaces:

19+

20+- [Headlamp](headlamp.md) ✨ *Recommended*

21+- [Kubernetes Dashboard](kubernetes-dashboard.md) ⚠️ *Deprecated*

22+

23+:::tip

24+When integrating with Kubernetes web UIs, make sure to:

25+1. Configure the Ingress to pass the Authorization header with the bearer token

26+2. Increase buffer sizes for large OIDC tokens (especially with Azure Entra ID)

27+3. Set up appropriate Kubernetes RBAC permissions for your users or groups

28+:::

29+

30+## General Requirements

31+

32+Most integrations require the following OAuth2 Proxy configuration:

33+

34+- `--reverse-proxy=true`: Required to correctly handle `X-Forwarded-*` headers

35+- **Session storage**: For production deployments with large tokens due to a lot of claims like AD groups, use `--session-store-type=redis`

36+

37+For provider-specific configuration, see the [OAuth Provider Configuration](../providers/index.md) documentation.

38+

39+:::note

40+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

41+:::

docs/versioned_docs/version-7.13.x/configuration/integrations/kubernetes-dashboard.mdnew file+289

@@ -0,0 +1,289 @@

1+---

2+id: kubernetes-dashboard

3+title: Kubernetes Dashboard

4+---

5+

6+:::warning Deprecated Project

7+Kubernetes Dashboard has been deprecated and discontinued as of January 2025. See the [official announcement](https://github.com/kubernetes/dashboard/commit/0ba796dce6916bb6ca5da5ca0b3ab22cecfd1e18) for more information.

8+

9+You may want to consider alternative solutions such as [Headlamp](./headlamp.md).

10+:::

11+

12+## Kubernetes Dashboard on AKS with Azure Entra ID

13+

14+Integration guide for the deprecated Kubernetes Dashboard, including comprehensive Azure Entra ID configuration on AKS with detailed troubleshooting and RBAC setup.

15+

16+### Architecture

17+

18+```

19+User → Nginx Ingress → OAuth2 Proxy → Entra ID

20+ ↓

21+ Kubernetes Dashboard

22+```

23+

24+The integration flow:

25+1. Unauthenticated requests to Dashboard are intercepted by Nginx Ingress

26+2. Nginx redirects to OAuth2 Proxy for authentication

27+3. OAuth2 Proxy redirects to Entra ID login

28+4. After successful authentication, OAuth2 Proxy receives ID token from Entra ID

29+5. OAuth2 Proxy sets Authorization header with the bearer token

30+6. Nginx forwards the request with token to Kubernetes Dashboard

31+7. Dashboard validates the token and grants access based on AKS RBAC configuration

32+

33+### Prerequisites

34+

35+- AKS cluster with Entra ID integration enabled

36+- Kubernetes Dashboard installed (version 7.x or later)

37+- NGINX Ingress Controller installed

38+- Entra ID App Registration configured with:

39+ - Redirect URI: `https://your-oauth2-domain.com/oauth2/callback`

40+ - API Permissions: `openid`, `email`, `profile`

41+ - Groups claim enabled (if using group-based RBAC)

42+- Users or groups assigned appropriate Kubernetes RBAC permissions

43+

44+### Alpha Configuration Example

45+

46+Using [Alpha Configuration](../alpha_config.md) with the OAuth2 Proxy Helm chart:

47+

48+```yaml

49+alphaConfig:

50+ enabled: true

51+ configData:

52+ providers:

53+ - id: azure-entra

54+ provider: entra-id

55+ clientID: YOUR_CLIENT_ID

56+ clientSecret: YOUR_CLIENT_SECRET

57+ oidcConfig:

58+ issuerURL: https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0

59+ audienceClaims:

60+ - aud

61+ emailClaim: email

62+ groupsClaim: groups

63+ userIDClaim: oid

64+ scope: openid email profile

65+

66+ upstreamConfig:

67+ upstreams:

68+ - id: static

69+ path: /

70+ static: true

71+ staticCode: 200

72+

73+ # Response headers passed to Dashboard via Nginx

74+ injectResponseHeaders:

75+ - name: Authorization

76+ values:

77+ - claim: id_token

78+ prefix: "Bearer "

79+ - name: X-Auth-Request-User

80+ values:

81+ - claim: email

82+ - name: X-Auth-Request-Email

83+ values:

84+ - claim: email

85+ - name: X-Auth-Request-Groups

86+ values:

87+ - claim: groups

88+

89+ server:

90+ BindAddress: "0.0.0.0:4180"

91+

92+extraArgs:

93+ cookie-domain: ".your-domain.com"

94+ whitelist-domain: ".your-domain.com"

95+ email-domain: "*" # Or restrict to your organization

96+ skip-provider-button: true

97+ reverse-proxy: true

98+ pass-authorization-header: true

99+ set-xauthrequest: true

100+

101+sessionStorage:

102+ type: redis

103+

104+redis:

105+ enabled: true

106+ auth:

107+ enabled: true

108+

109+ingress:

110+ enabled: true

111+ className: nginx

112+ hosts:

113+ - OAuth2 Proxy.your-domain.com

114+ path: /oauth2

115+ pathType: Prefix

116+```

117+

118+### Kubernetes Dashboard Ingress

119+

120+**Critical**: The Ingress must include `Authorization` in the `auth-response-headers` annotation:

121+

122+```yaml

123+apiVersion: networking.k8s.io/v1

124+kind: Ingress

125+metadata:

126+ name: kubernetes-dashboard

127+ namespace: kubernetes-dashboard

128+ annotations:

129+ nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

130+ nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

131+

132+ # OAuth2 Proxy authentication

133+ nginx.ingress.kubernetes.io/auth-url: "https://OAuth2 Proxy.your-domain.com/oauth2/auth"

134+ nginx.ingress.kubernetes.io/auth-signin: "https://OAuth2 Proxy.your-domain.com/oauth2/start?rd=$scheme://$best_http_host$request_uri"

135+

136+ # Include Authorization header with bearer token

137+ nginx.ingress.kubernetes.io/auth-response-headers: "Authorization, X-Auth-Request-User, X-Auth-Request-Email"

138+

139+ # Buffer sizes for large tokens (Entra tokens can exceed 4KB)

140+ nginx.ingress.kubernetes.io/proxy-buffer-size: "256k"

141+ nginx.ingress.kubernetes.io/proxy-buffers-number: "4"

142+ nginx.ingress.kubernetes.io/proxy-busy-buffers-size: "256k"

143+spec:

144+ ingressClassName: nginx

145+ tls:

146+ - hosts:

147+ - dashboard.your-domain.com

148+ secretName: dashboard-tls

149+ rules:

150+ - host: dashboard.your-domain.com

151+ http:

152+ paths:

153+ - path: /

154+ pathType: Prefix

155+ backend:

156+ service:

157+ name: kubernetes-dashboard-kong-proxy

158+ port:

159+ number: 443

160+```

161+

162+### RBAC Configuration

163+

164+Assign Kubernetes permissions to Entra ID users or groups.

165+

166+**User-based:**

167+```yaml

168+apiVersion: rbac.authorization.k8s.io/v1

169+kind: ClusterRoleBinding

170+metadata:

171+ name: dashboard-user-admin

172+roleRef:

173+ apiGroup: rbac.authorization.k8s.io

174+ kind: ClusterRole

175+ name: cluster-admin

176+subjects:

177+ - kind: User

178+ name: "user@your-domain.com" # Email from Entra ID token

179+ apiGroup: rbac.authorization.k8s.io

180+```

181+

182+**Group-based (recommended):**

183+```yaml

184+apiVersion: rbac.authorization.k8s.io/v1

185+kind: ClusterRoleBinding

186+metadata:

187+ name: dashboard-admins-group

188+roleRef:

189+ apiGroup: rbac.authorization.k8s.io

190+ kind: ClusterRole

191+ name: cluster-admin

192+subjects:

193+ - kind: Group

194+ name: "YOUR_ENTRA_GROUP_OBJECT_ID" # Entra ID Group Object ID

195+ apiGroup: rbac.authorization.k8s.io

196+```

197+

198+For production, create custom roles with limited permissions instead of using `cluster-admin`.

199+

200+### Troubleshooting

201+

202+**Dashboard still asks for token after authentication**

203+

204+Verify that:

205+1. `injectResponseHeaders` in alphaConfig includes Authorization header with id_token claim

206+2. Dashboard Ingress includes `Authorization` in `auth-response-headers` annotation

207+3. Buffer sizes are sufficient for large tokens (set to 256k as shown above)

208+4. Check OAuth2 Proxy logs for successful token generation: `kubectl logs -n OAuth2 Proxy <pod-name>`

209+

210+**"Unauthorized" or "Invalid token" errors**

211+

212+Common causes:

213+1. User/group not configured in Kubernetes RBAC

214+ - Check: `kubectl get clusterrolebindings | grep <user-email>`

215+2. Token validation failed

216+ - Verify AKS Entra ID integration is enabled

217+ - Check Dashboard logs: `kubectl logs -n kubernetes-dashboard <pod-name>`

218+3. Incorrect OAuth2 Proxy configuration

219+ - Ensure `reverse-proxy: true` is set

220+ - Verify issuer URL matches your tenant

221+

222+**Groups not included in token**

223+

224+To include groups in the token:

225+1. In Entra ID App Registration, go to **Token configuration**

226+2. Add **groups claim** and select security groups

227+3. Or edit the manifest and add: `"groupMembershipClaims": "SecurityGroup"`

228+4. For 200+ groups, ensure scope includes `User.Read` for group overage handling

229+5. Verify groups appear in token: check OAuth2 Proxy logs

230+

231+**Session expires too quickly**

232+

233+Configure cookie expiration:

234+```yaml

235+extraArgs:

236+ cookie-expire: "24h"

237+ cookie-refresh: "1h"

238+```

239+

240+### Using Workload Identity (Passwordless)

241+

242+For production environments, use Workload Identity instead of client secrets:

243+

244+```yaml

245+config:

246+ clientID: "YOUR_CLIENT_ID"

247+ secretKeys: # Exclude client-secret

248+ - client-id

249+ - cookie-secret

250+ cookieSecret: "YOUR_COOKIE_SECRET"

251+

252+serviceAccount:

253+ annotations:

254+ azure.workload.identity/client-id: YOUR_CLIENT_ID

255+ azure.workload.identity/tenant-id: YOUR_TENANT_ID

256+

257+podLabels:

258+ azure.workload.identity/use: "true"

259+

260+alphaConfig:

261+ enabled: true

262+ configData:

263+ providers:

264+ - id: azure-entra

265+ provider: entra-id

266+ clientID: YOUR_CLIENT_ID

267+ oidcConfig:

268+ issuerURL: https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0

269+ # ... other config

270+ entraIdConfig:

271+ federatedTokenAuth: true

272+```

273+

274+This requires:

275+- AKS with OIDC issuer and Workload Identity enabled

276+- Federated identity credential configured in Entra ID App Registration

277+- Service account annotated with `azure.workload.identity/client-id`

278+

279+For detailed Workload Identity setup instructions, see the [Workload Identity section](../providers/ms_entra_id.md#workload-identity) in the Microsoft Entra ID provider documentation.

280+

281+## Integration with Other Providers

282+

283+While this guide focuses on Azure Entra ID, Kubernetes Dashboard can be integrated with other OAuth2 providers supported by OAuth2 Proxy. The key requirements remain the same:

284+

285+1. **Authorization Header**: Pass the bearer token via the `Authorization` header

286+2. **RBAC Configuration**: Configure Kubernetes RBAC for your authentication provider's users/groups

287+3. **Buffer Sizes**: Ensure adequate buffer sizes for tokens (especially important for OIDC providers)

288+

289+For provider-specific configuration examples, see the [OAuth Provider Configuration](../providers/index.md) documentation.

docs/versioned_docs/version-7.13.x/configuration/integrations/nginx.mdnew file+174

@@ -0,0 +1,174 @@

1+---

2+id: nginx

3+title: Nginx

4+---

5+

6+Configure OAuth2 Proxy with Nginx using the `auth_request` directive. Includes examples for both standalone Nginx configurations and Kubernetes ingress-nginx with annotations.

7+

8+**Key features:**

9+- Support for `auth_request` directive

10+- Kubernetes Ingress annotations

11+- Multi-part cookie handling for large tokens

12+- Session refresh support

13+

14+## Configuring for use with the Nginx `auth_request` directive

15+

16+**This option requires `--reverse-proxy` option to be set.**

17+

18+The [Nginx `auth_request` directive](http://nginx.org/en/docs/http/ngx_http_auth_request_module.html) allows Nginx to authenticate requests via the oauth2-proxy's `/auth` endpoint, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the request through. For example:

19+

20+```nginx

21+server {

22+ listen 443 ssl;

23+ server_name ...;

24+ include ssl/ssl.conf;

25+

26+ location /oauth2/ {

27+ proxy_pass http://127.0.0.1:4180;

28+ proxy_set_header Host $host;

29+ proxy_set_header X-Real-IP $remote_addr;

30+ proxy_set_header X-Auth-Request-Redirect $request_uri;

31+ # or, if you are handling multiple domains:

32+ # proxy_set_header X-Auth-Request-Redirect $scheme://$host$request_uri;

33+ }

34+ location = /oauth2/auth {

35+ proxy_pass http://127.0.0.1:4180;

36+ proxy_set_header Host $host;

37+ proxy_set_header X-Real-IP $remote_addr;

38+ proxy_set_header X-Forwarded-Uri $request_uri;

39+ # nginx auth_request includes headers but not body

40+ proxy_set_header Content-Length "";

41+ proxy_pass_request_body off;

42+ }

43+

44+ location / {

45+ auth_request /oauth2/auth;

46+ error_page 401 = @oauth2_signin;

47+

48+ # pass information via X-User and X-Email headers to backend,

49+ # requires running with --set-xauthrequest flag

50+ auth_request_set $user $upstream_http_x_auth_request_user;

51+ auth_request_set $email $upstream_http_x_auth_request_email;

52+ proxy_set_header X-User $user;

53+ proxy_set_header X-Email $email;

54+

55+ # if you enabled --pass-access-token, this will pass the token to the backend

56+ auth_request_set $token $upstream_http_x_auth_request_access_token;

57+ proxy_set_header X-Access-Token $token;

58+

59+ # if you enabled --cookie-refresh, this is needed for it to work with auth_request

60+ auth_request_set $auth_cookie $upstream_http_set_cookie;

61+ add_header Set-Cookie $auth_cookie;

62+

63+ # When using the --set-authorization-header flag, some provider's cookies can exceed the 4kb

64+ # limit and so the OAuth2 Proxy splits these into multiple parts.

65+ # Nginx normally only copies the first `Set-Cookie` header from the auth_request to the response,

66+ # so if your cookies are larger than 4kb, you will need to extract additional cookies manually.

67+ auth_request_set $auth_cookie_name_upstream_1 $upstream_cookie_auth_cookie_name_1;

68+

69+ # Extract the Cookie attributes from the first Set-Cookie header and append them

70+ # to the second part ($upstream_cookie_* variables only contain the raw cookie content)

71+ if ($auth_cookie ~* "(; .*)") {

72+ set $auth_cookie_name_0 $auth_cookie;

73+ set $auth_cookie_name_1 "auth_cookie_name_1=$auth_cookie_name_upstream_1$1";

74+ }

75+

76+ # Send both Set-Cookie headers now if there was a second part

77+ if ($auth_cookie_name_upstream_1) {

78+ add_header Set-Cookie $auth_cookie_name_0;

79+ add_header Set-Cookie $auth_cookie_name_1;

80+ }

81+

82+ proxy_pass http://backend/;

83+ # or "root /path/to/site;" or "fastcgi_pass ..." etc

84+ }

85+

86+ # Named location for handling OAuth2 sign-in redirects

87+ # This ensures the browser receives a proper 302 redirect that it will follow

88+ location @oauth2_signin {

89+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

90+ }

91+}

92+```

93+

94+### Understanding the `error_page` redirect pattern

95+

96+The `auth_request` directive expects the authentication endpoint (`/oauth2/auth`) to return:

97+- **2xx**: Request is authenticated, allow access

98+- **401 or 403**: Request is not authenticated, deny access

99+

100+When a 401 is returned, nginx triggers the `error_page` directive. The recommended pattern uses a **named location** (`@oauth2_signin`) that returns a proper **302 redirect**:

101+

102+```nginx

103+error_page 401 = @oauth2_signin;

104+

105+location @oauth2_signin {

106+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

107+}

108+```

109+

110+:::warning Avoid `error_page 401 =403` with sign_in

111+Some older configurations use `error_page 401 =403 /oauth2/sign_in`. While this works for displaying the sign-in page, it returns a **403 status code** with a `Location` header. Browsers do not automatically follow redirects on 403 responses, which can cause issues when using `--skip-provider-button=true` (users see a "Found." link instead of being automatically redirected).

112+

113+The named location pattern above ensures the browser receives a standard **302 redirect** that works correctly with all oauth2-proxy configurations.

114+:::

115+

116+### Browser vs API Routes

117+

118+:::important When to use redirects

119+Redirecting authentication failures (302 to `/oauth2/sign_in`) should **only be used for browser-facing routes**. API or machine clients should receive a plain 401/403 response without redirect.

120+:::

121+

122+#### Browser-facing routes (HTML, UI)

123+

124+For interactive browser routes where users should be redirected to sign in:

125+

126+```nginx

127+location / {

128+ auth_request /oauth2/auth;

129+ error_page 401 = @oauth2_signin;

130+ proxy_pass http://backend/;

131+}

132+

133+location @oauth2_signin {

134+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

135+}

136+```

137+

138+#### API / Machine routes (no redirect)

139+

140+For API endpoints where clients expect a 401/403 status code (not a redirect):

141+

142+```nginx

143+location /api/ {

144+ auth_request /oauth2/auth;

145+ error_page 401 =401; # Pass through the 401 status

146+ proxy_pass http://backend/;

147+}

148+```

149+

150+This ensures:

151+- ✅ Browsers get a redirect and smooth login flow

152+- ✅ API clients fail fast with appropriate HTTP status codes

153+- ✅ `/oauth2/auth` remains a pure boolean oracle (2xx/401)

154+

155+When you use ingress-nginx in Kubernetes, you can configure the same behavior with the following annotations on your Ingress resource:

156+

157+```yaml

158+nginx.ingress.kubernetes.io/auth-url: "https://<oauth2-proxy-fqdn>/oauth2/auth"

159+nginx.ingress.kubernetes.io/auth-signin: "https://<oauth2-proxy-fqdn>/oauth2/start?rd=$escaped_request_uri"

160+```

161+

162+This minimal configuration works for standard authentication flows. Lua/cookie handling is only needed for advanced scenarios (e.g., multi-part cookies, custom session logic). See the official ingress-nginx example: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/.

163+

164+It is recommended to use `--session-store-type=redis` when expecting large sessions/OIDC tokens (_e.g._ with MS Azure).

165+

166+:::tip Kubernetes Dashboard with Azure Entra ID

167+For a complete example of integrating oauth2-proxy with Kubernetes Dashboard on AKS using Azure Entra ID, including RBAC configuration and troubleshooting, see the [Kubernetes Dashboard on AKS](../providers/ms_entra_id.md#kubernetes-dashboard-on-aks) section in the Microsoft Entra ID provider documentation.

168+:::

169+

170+You have to substitute *name* with the actual cookie name you configured via --cookie-name parameter. If you don't set a custom cookie name the variable should be "$upstream_cookie__oauth2_proxy_1" instead of "$upstream_cookie_name_1" and the new cookie-name should be "_oauth2_proxy_1=" instead of "name_1=".

171+

172+:::note

173+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

174+:::

docs/versioned_docs/version-7.13.x/configuration/integrations/traefik.mdnew file+192

@@ -0,0 +1,192 @@

1+---

2+id: traefik

3+title: Traefik

4+---

5+

6+Set up OAuth2 Proxy with Traefik v2 using the `ForwardAuth` middleware. Includes examples for both error-based redirects and static upstream configurations.

7+

8+**Key features:**

9+- ForwardAuth middleware integration

10+- Error middleware for 401 redirects

11+- Static upstream configuration (202 responses)

12+- Dynamic file configuration examples

13+

14+

15+## Configuring for use with the Traefik (v2) `ForwardAuth` middleware

16+

17+**This option requires `--reverse-proxy` option to be set.**

18+

19+### ForwardAuth with 401 errors middleware

20+

21+The [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) allows Traefik to authenticate requests via the oauth2-proxy's `/oauth2/auth` endpoint on every request, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the whole request through. For example, on Dynamic File (YAML) Configuration:

22+

23+```yaml

24+http:

25+ routers:

26+ a-service:

27+ rule: "Host(`a-service.example.com`)"

28+ service: a-service-backend

29+ middlewares:

30+ - oauth-errors

31+ - oauth-auth

32+ tls:

33+ certResolver: default

34+ domains:

35+ - main: "example.com"

36+ sans:

37+ - "*.example.com"

38+ oauth:

39+ rule: "Host(`a-service.example.com`, `oauth.example.com`) && PathPrefix(`/oauth2/`)"

40+ middlewares:

41+ - auth-headers

42+ service: oauth-backend

43+ tls:

44+ certResolver: default

45+ domains:

46+ - main: "example.com"

47+ sans:

48+ - "*.example.com"

49+

50+ services:

51+ a-service-backend:

52+ loadBalancer:

53+ servers:

54+ - url: http://172.16.0.2:7555

55+ oauth-backend:

56+ loadBalancer:

57+ servers:

58+ - url: http://172.16.0.1:4180

59+

60+ middlewares:

61+ auth-headers:

62+ headers:

63+ sslRedirect: true

64+ stsSeconds: 315360000

65+ browserXssFilter: true

66+ contentTypeNosniff: true

67+ forceSTSHeader: true

68+ sslHost: example.com

69+ stsIncludeSubdomains: true

70+ stsPreload: true

71+ frameDeny: true

72+ oauth-auth:

73+ forwardAuth:

74+ address: https://oauth.example.com/oauth2/auth

75+ trustForwardHeader: true

76+ oauth-errors:

77+ errors:

78+ status:

79+ - "401-403"

80+ service: oauth-backend

81+ query: "/oauth2/sign_in?rd={url}"

82+ statusRewrites:

83+ "401": 302

84+```

85+

86+:::info Troubleshooting: Browser shows "Found." instead of redirecting

87+When using the Errors middleware without `statusRewrites`, the redirect response from oauth2-proxy can be served within the original 401/403 status context. This causes some browsers to display a "Found." link instead of automatically following the redirect to the identity provider.

88+

89+Adding `statusRewrites` to rewrite `401 -> 302` ensures the browser treats the response as a proper redirect and follows it automatically.

90+:::

91+

92+### ForwardAuth with static upstreams configuration

93+

94+Redirect to sign_in functionality provided without the use of `errors` middleware with [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) pointing to oauth2-proxy service's `/` endpoint

95+

96+**Following options need to be set on `oauth2-proxy`:**

97+- `--upstream=static://202`: Configures a static response for authenticated sessions

98+- `--reverse-proxy=true`: Enables the use of `X-Forwarded-*` headers to determine redirects correctly

99+

100+```yaml

101+http:

102+ routers:

103+ a-service-route-1:

104+ rule: "Host(`a-service.example.com`, `b-service.example.com`) && PathPrefix(`/`)"

105+ service: a-service-backend

106+ middlewares:

107+ - oauth-auth-redirect # redirects all unauthenticated to oauth2 signin

108+ tls:

109+ certResolver: default

110+ domains:

111+ - main: "example.com"

112+ sans:

113+ - "*.example.com"

114+ a-service-route-2:

115+ rule: "Host(`a-service.example.com`) && PathPrefix(`/no-auto-redirect`)"

116+ service: a-service-backend

117+ middlewares:

118+ - oauth-auth-wo-redirect # unauthenticated session will return a 401

119+ tls:

120+ certResolver: default

121+ domains:

122+ - main: "example.com"

123+ sans:

124+ - "*.example.com"

125+ services-oauth2-route:

126+ rule: "Host(`a-service.example.com`, `b-service.example.com`) && PathPrefix(`/oauth2/`)"

127+ middlewares:

128+ - auth-headers

129+ service: oauth-backend

130+ tls:

131+ certResolver: default

132+ domains:

133+ - main: "example.com"

134+ sans:

135+ - "*.example.com"

136+ oauth2-proxy-route:

137+ rule: "Host(`oauth.example.com`) && PathPrefix(`/`)"

138+ middlewares:

139+ - auth-headers

140+ service: oauth-backend

141+ tls:

142+ certResolver: default

143+ domains:

144+ - main: "example.com"

145+ sans:

146+ - "*.example.com"

147+

148+ services:

149+ a-service-backend:

150+ loadBalancer:

151+ servers:

152+ - url: http://172.16.0.2:7555

153+ b-service-backend:

154+ loadBalancer:

155+ servers:

156+ - url: http://172.16.0.3:7555

157+ oauth-backend:

158+ loadBalancer:

159+ servers:

160+ - url: http://172.16.0.1:4180

161+

162+ middlewares:

163+ auth-headers:

164+ headers:

165+ sslRedirect: true

166+ stsSeconds: 315360000

167+ browserXssFilter: true

168+ contentTypeNosniff: true

169+ forceSTSHeader: true

170+ sslHost: example.com

171+ stsIncludeSubdomains: true

172+ stsPreload: true

173+ frameDeny: true

174+ oauth-auth-redirect:

175+ forwardAuth:

176+ address: https://oauth.example.com/

177+ trustForwardHeader: true

178+ authResponseHeaders:

179+ - X-Auth-Request-Access-Token

180+ - Authorization

181+ oauth-auth-wo-redirect:

182+ forwardAuth:

183+ address: https://oauth.example.com/oauth2/auth

184+ trustForwardHeader: true

185+ authResponseHeaders:

186+ - X-Auth-Request-Access-Token

187+ - Authorization

188+```

189+

190+:::note

191+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

192+:::

docs/versioned_docs/version-7.13.x/configuration/overview.mdnew file+407

@@ -0,0 +1,407 @@

1+---

2+id: overview

3+title: Overview

4+---

5+

6+`oauth2-proxy` can be configured via [command line options](#command-line-options), [environment variables](#environment-variables) or [config file](#config-file) (in decreasing order of precedence, i.e. command line options will overwrite environment variables and environment variables will overwrite configuration file settings).

7+

8+## Generating a Cookie Secret

9+

10+To generate a strong cookie secret use one of the below commands:

11+

12+import Tabs from '@theme/Tabs';

13+import TabItem from '@theme/TabItem';

14+

15+<Tabs defaultValue="python">

16+ <TabItem value="python" label="Python">

17+

18+```shell

19+python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())'

20+```

21+

22+ </TabItem>

23+ <TabItem value="bash" label="Bash">

24+

25+```shell

26+dd if=/dev/urandom bs=32 count=1 2>/dev/null | base64 | tr -d -- '\n' | tr -- '+/' '-_' ; echo

27+```

28+

29+ </TabItem>

30+ <TabItem value="openssl" label="OpenSSL">

31+

32+```shell

33+openssl rand -base64 32 | tr -- '+/' '-_'

34+```

35+

36+ </TabItem>

37+ <TabItem value="powershell" label="PowerShell">

38+

39+```powershell

40+# Add System.Web assembly to session, just in case

41+Add-Type -AssemblyName System.Web

42+[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes([System.Web.Security.Membership]::GeneratePassword(32,4))).Replace("+","-").Replace("/","_")

43+```

44+

45+ </TabItem>

46+ <TabItem value="terraform" label="Terraform">

47+

48+```hcl

49+# Valid 32 Byte Base64 URL encoding set that will decode to 24 []byte AES-192 secret

50+resource "random_password" "cookie_secret" {

51+ length = 32

52+ override_special = "-_"

53+}

54+```

55+

56+ </TabItem>

57+</Tabs>

58+

59+## Config File

60+

61+Every command line argument can be specified in a config file by replacing hyphens (-) with underscores (\_). If the argument can be specified multiple times, the config option should be plural (trailing s).

62+

63+An example [oauth2-proxy.cfg](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/oauth2-proxy.cfg.example) config file is in the contrib directory. It can be used by specifying `--config=/etc/oauth2-proxy.cfg`

64+

65+## Config Options

66+

67+### Command Line Options

68+

69+| Flag | Description |

70+| ----------- | -------------------- |

71+| `--config` | path to config file |

72+| `--version` | print version string |

73+

74+

75+### General Provider Options

76+

77+Provider specific options can be found on their respective subpages.

78+

79+| Flag / Config Field | Type | Description | Default |

80+| --------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |

81+| flag: `--acr-values`<br/>toml: `acr_values` | string | optional, see [docs](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html#acrValues) | `""` |

82+| flag: `--allowed-group`<br/>toml: `allowed_groups` | string \| list | Restrict login to members of a group or list of groups. Furthermore, if you aren't setting the `scope` and use `allowed_groups` with the generic OIDC provider the scope `groups` gets added implicitly. | |

83+| flag: `--approval-prompt`<br/>toml: `approval_prompt` | string | OAuth approval_prompt | `"force"` |

84+| flag: `--backend-logout-url`<br/>toml: `backend_logout_url` | string | URL to perform backend logout, if you use `{id_token}` in the url it will be replaced by the actual `id_token` of the user session | |

85+| flag: `--client-id`<br/>toml: `client_id` | string | the OAuth Client ID, e.g. `"123456.apps.googleusercontent.com"` | |

86+| flag: `--client-secret-file`<br/>toml: `client_secret_file` | string | the file with OAuth Client Secret. The file must contain the secret only, with no trailing newline | |

87+| flag: `--client-secret`<br/>toml: `client_secret` | string | the OAuth Client Secret | |

88+| flag: `--code-challenge-method`<br/>toml: `code_challenge_method` | string | use PKCE code challenges with the specified method. Either 'plain' or 'S256' (recommended) | |

89+| flag: `--insecure-oidc-allow-unverified-email`<br/>toml: `insecure_oidc_allow_unverified_email` | bool | don't fail if an email address in an id_token is not verified | false |

90+| flag: `--insecure-oidc-skip-issuer-verification`<br/>toml: `insecure_oidc_skip_issuer_verification` | bool | allow the OIDC issuer URL to differ from the expected (currently required for Azure multi-tenant compatibility) | false |

91+| flag: `--insecure-oidc-skip-nonce`<br/>toml: `insecure_oidc_skip_nonce` | bool | skip verifying the OIDC ID Token's nonce claim | true |

92+| flag: `--jwt-key-file`<br/>toml: `jwt_key_file` | string | path to the private key file in PEM format used to sign the JWT so that you can say something like `--jwt-key-file=/etc/ssl/private/jwt_signing_key.pem`: required by login.gov | |

93+| flag: `--jwt-key`<br/>toml: `jwt_key` | string | private key in PEM format used to sign JWT, so that you can say something like `--jwt-key="${OAUTH2_PROXY_JWT_KEY}"`: required by login.gov | |

94+| flag: `--login-url`<br/>toml: `login_url` | string | Authentication endpoint | |

95+| flag: `--auth-request-response-mode`<br/>toml: `auth-request-response-mode` | string | Response mode to ask for during authentication request | |

96+| flag: `--oidc-audience-claim`<br/>toml: `oidc_audience_claims` | string | which OIDC claim contains the audience | `"aud"` |

97+| flag: `--oidc-email-claim`<br/>toml: `oidc_email_claim` | string | which OIDC claim contains the user's email | `"email"` |

98+| flag: `--oidc-extra-audience`<br/>toml: `oidc_extra_audiences` | string \| list | additional audiences which are allowed to pass verification | `"[]"` |

99+| flag: `--oidc-groups-claim`<br/>toml: `oidc_groups_claim` | string | which OIDC claim contains the user groups | `"groups"` |

100+| flag: `--oidc-issuer-url`<br/>toml: `oidc_issuer_url` | string | the OpenID Connect issuer URL, e.g. `"https://accounts.google.com"` | |

101+| flag: `--oidc-jwks-url`<br/>toml: `oidc_jwks_url` | string | OIDC JWKS URI for token verification; required if OIDC discovery is disabled and public key files are not provided | |

102+| flag: `--oidc-public-key-file`<br/>toml: `oidc_public_key_files` | string | Path to public key file in PEM format to use for verifying JWT tokens (may be given multiple times). Required if OIDC discovery is disabled na JWKS URL isn't provided | string \| list |

103+| flag: `--profile-url`<br/>toml: `profile_url` | string | Profile access endpoint | |

104+| flag: `--prompt`<br/>toml: `prompt` | string | [OIDC prompt](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest); if present, `approval-prompt` is ignored | `""` |

105+| flag: `--provider-ca-file`<br/>toml: `provider_ca_files` | string \| list | Paths to CA certificates that should be used when connecting to the provider. If not specified, the default Go trust sources are used instead. |

106+| flag: `--provider-display-name`<br/>toml: `provider_display_name` | string | Override the provider's name with the given string; used for the sign-in page | (depends on provider) |

107+| flag: `--provider`<br/>toml: `provider` | string | OAuth provider | google |

108+| flag: `--pubjwk-url`<br/>toml: `pubjwk_url` | string | JWK pubkey access endpoint: required by login.gov | |

109+| flag: `--redeem-url`<br/>toml: `redeem_url` | string | Token redemption endpoint | |

110+| flag: `--scope`<br/>toml:`scope` | string | OAuth scope specification. Every provider has a default list of scopes which will be used in case no scope is configured. | |

111+| flag: `--skip-claims-from-profile-url`<br/>toml: `skip_claims_from_profile_url` | bool | skip request to Profile URL for resolving claims not present in id_token | false |

112+| flag: `--skip-oidc-discovery`<br/>toml: `skip_oidc_discovery` | bool | bypass OIDC endpoint discovery. `--login-url`, `--redeem-url` and `--oidc-jwks-url` must be configured in this case | false |

113+| flag: `--use-system-trust-store`<br/>toml: `use_system_trust_store` | bool | Determines if `provider-ca-file` files and the system trust store are used. If set to true, your custom CA files and the system trust store are used otherwise only your custom CA files. | false |

114+| flag: `--validate-url`<br/>toml: `validate_url` | string | Access token validation endpoint | |

115+

116+### Cookie Options

117+

118+| Flag / Config Field | Type | Description | Default |

119+| --------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |

120+| flag: `--cookie-csrf-expire`<br/>toml: `cookie_csrf_expire` | duration | expire timeframe for CSRF cookie | 15m |

121+| flag: `--cookie-csrf-per-request`<br/>toml:`cookie_csrf_per_request` | bool | Enable having different CSRF cookies per request, making it possible to have parallel requests. | false |

122+| flag: `--cookie-csrf-per-request-limit`<br/>toml: `cookie_csrf_per_request_limit` | int | Sets a limit on the number of CSRF requests cookies that oauth2-proxy will create. The oldest cookie will be removed. Useful if users end up with 431 Request headers too large status codes. Only effective if --cookie-csrf-per-request is true | "infinite" |

123+| flag: `--cookie-domain`<br/>toml: `cookie_domains` | string \| list | Optional cookie domains to force cookies to (e.g. `.yourcompany.com`). The longest domain matching the request's host will be used (or the shortest cookie domain if there is no match). | |

124+| flag: `--cookie-expire`<br/>toml: `cookie_expire` | duration | expire timeframe for cookie. If set to 0, cookie becomes a session-cookie which will expire when the browser is closed. | 168h0m0s |

125+| flag: `--cookie-httponly`<br/>toml: `cookie_httponly` | bool | set HttpOnly cookie flag | true |

126+| flag: `--cookie-name`<br/>toml: `cookie_name` | string | the name of the cookie that the oauth_proxy creates. Should be changed to use a [cookie prefix](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes) (`__Host-` or `__Secure-`) if `--cookie-secure` is set. | `"_oauth2_proxy"` |

127+| flag: `--cookie-path`<br/>toml: `cookie_path` | string | an optional cookie path to force cookies to (e.g. `/poc/`) | `"/"` |

128+| flag: `--cookie-refresh`<br/>toml: `cookie_refresh` | duration | refresh the cookie after this duration; `0` to disable; not supported by all providers&nbsp;[^1] | |

129+| flag: `--cookie-samesite`<br/>toml: `cookie_samesite` | string | set SameSite cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`). | `""` |

130+| flag: `--cookie-secret`<br/>toml: `cookie_secret` | string | the seed string for secure cookies (optionally base64 encoded) | |

131+| flag: `--cookie-secret-file`<br/>toml: `cookie_secret_file` | string | File containing the cookie secret (must be raw binary, exactly 16, 24, or 32 bytes). Use dd if=/dev/urandom bs=32 count=1 > cookie.secret to generate | |

132+| flag: `--cookie-secure`<br/>toml: `cookie_secure` | bool | set [secure (HTTPS only) cookie flag](https://owasp.org/www-community/controls/SecureFlag) | true |

133+

134+[^1]: The following providers support `--cookie-refresh`: ADFS, Azure, GitLab, Google, Keycloak and all other Identity Providers which support the full [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens)

135+

136+### Header Options

137+

138+| Flag / Config Field | Type | Description | Default |

139+| ------------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

140+| flag: `--basic-auth-password`<br/>toml: `basic_auth_password` | string | the password to set when passing the HTTP Basic Auth header | |

141+| flag: `--set-xauthrequest`<br/>toml: `set_xauthrequest` | bool | set X-Auth-Request-User, X-Auth-Request-Groups, X-Auth-Request-Email and X-Auth-Request-Preferred-Username response headers (useful in Nginx auth_request mode). When used with `--pass-access-token`, X-Auth-Request-Access-Token is added to response headers. | false |

142+| flag: `--set-authorization-header`<br/>toml: `set_authorization_header` | bool | set Authorization Bearer response header (useful in Nginx auth_request mode) | false |

143+| flag: `--set-basic-auth`<br/>toml: `set_basic_auth` | bool | set HTTP Basic Auth information in response (useful in Nginx auth_request mode) | false |

144+| flag: `--skip-auth-strip-headers`<br/>toml: `skip_auth_strip_headers` | bool | strips `X-Forwarded-*` style authentication headers & `Authorization` header if they would be set by oauth2-proxy | true |

145+| flag: `--pass-access-token`<br/>toml: `pass_access_token` | bool | pass OAuth access_token to upstream via X-Forwarded-Access-Token header. When used with `--set-xauthrequest` this adds the X-Auth-Request-Access-Token header to the response | false |

146+| flag: `--pass-authorization-header`<br/>toml: `pass_authorization_header` | bool | pass OIDC IDToken to upstream via Authorization Bearer header | false |

147+| flag: `--pass-basic-auth`<br/>toml: `pass_basic_auth` | bool | pass HTTP Basic Auth, X-Forwarded-User, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream | true |

148+| flag: `--prefer-email-to-user`<br/>toml: `prefer_email_to_user` | bool | Prefer to use the Email address as the Username when passing information to upstream. Will only use Username if Email is unavailable, e.g. htaccess authentication. Used in conjunction with `--pass-basic-auth` and `--pass-user-headers` | false |

149+| flag: `--pass-user-headers`<br/>toml: `pass_user_headers` | bool | pass X-Forwarded-User, X-Forwarded-Groups, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream | true |

150+

151+### Logging Options

152+

153+| Flag / Config Field | Type | Description | Default |

154+| --------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------- | --------------------------------------------------- |

155+| flag: `--auth-logging-format`<br/>toml: `auth_logging_format` | string | Template for authentication log lines | see [Logging Configuration](#logging-configuration) |

156+| flag: `--auth-logging`<br/>toml: `auth_logging` | bool | Log authentication attempts | true |

157+| flag: `--errors-to-info-log`<br/>toml: `errors_to_info_log` | bool | redirects error-level logging to default log channel instead of stderr | false |

158+| flag: `--exclude-logging-path`<br/>toml: `exclude_logging_paths` | string | comma separated list of paths to exclude from logging, e.g. `"/ping,/path2"` | `""` (no paths excluded) |

159+| flag: `--logging-compress`<br/>toml: `logging_compress` | bool | Should rotated log files be compressed using gzip | false |

160+| flag: `--logging-filename`<br/>toml: `logging_filename` | string | File to log requests to, empty for `stdout` | `""` (stdout) |

161+| flag: `--logging-local-time`<br/>toml: `logging_local_time` | bool | Use local time in log files and backup filenames instead of UTC | true (local time) |

162+| flag: `--logging-max-age`<br/>toml: `logging_max_age` | int | Maximum number of days to retain old log files | 7 |

163+| flag: `--logging-max-backups`<br/>toml: `logging_max_backups` | int | Maximum number of old log files to retain; 0 to disable | 0 |

164+| flag: `--logging-max-size`<br/>toml: `logging_max_size` | int | Maximum size in megabytes of the log file before rotation | 100 |

165+| flag: `--request-id-header`<br/>toml: `request_id_header` | string | Request header to use as the request ID in logging | X-Request-Id |

166+| flag: `--request-logging-format`<br/>toml: `request_logging_format` | string | Template for request log lines | see [Logging Configuration](#logging-configuration) |

167+| flag: `--request-logging`<br/>toml: `request_logging` | bool | Log requests | true |

168+| flag: `--silence-ping-logging`<br/>toml: `silence_ping_logging` | bool | disable logging of requests to ping & ready endpoints | false |

169+| flag: `--standard-logging-format`<br/>toml: `standard_logging_format` | string | Template for standard log lines | see [Logging Configuration](#logging-configuration) |

170+| flag: `--standard-logging`<br/>toml: `standard_logging` | bool | Log standard runtime information | true |

171+

172+### Page Template Options

173+

174+| Flag / Config Field | Type | Description | Default |

175+| ----------------------------------------------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------- | ------- |

176+| flag: `--banner`<br/>toml: `banner` | string | custom (html) banner string. Use `"-"` to disable default banner. | |

177+| flag: `--custom-sign-in-logo`<br/>toml: `custom_sign_in_logo` | string | path or a URL to an custom image for the sign_in page logo. Use `"-"` to disable default logo. |

178+| flag: `--custom-templates-dir`<br/>toml: `custom_templates_dir` | string | path to custom html templates | |

179+| flag: `--display-htpasswd-form`<br/>toml: `display_htpasswd_form` | bool | display username / password login form if an htpasswd file is provided | true |

180+| flag: `--footer`<br/>toml: `footer` | string | custom (html) footer string. Use `"-"` to disable default footer. (Can be used to obfuscate the version) | |

181+| flag: `--show-debug-on-error`<br/>toml: `show_debug_on_error` | bool | show detailed error information on error pages (WARNING: this may contain sensitive information - do not use in production) | false |

182+

183+### Probe Options

184+

185+| Flag / Config Field | Type | Description | Default |

186+| ------------------------------------------------------- | ------ | ---------------------------------------------------------- | ----------------------------- |

187+| flag: `--ping-path`<br/>toml: `ping_path` | string | the ping endpoint that can be used for basic health checks | `"/ping"` |

188+| flag: `--ping-user-agent`<br/>toml: `ping_user_agent` | string | a User-Agent that can be used for basic health checks | `""` (don't check user agent) |

189+| flag: `--ready-path`<br/>toml: `ready_path` | string | the ready endpoint that can be used for deep health checks | `"/ready"` |

190+| flag: `--gcp-healthchecks`<br/>toml: `gcp_healthchecks` | bool | Enable GCP/GKE healthcheck endpoints (deprecated) | false |

191+

192+### Proxy Options

193+

194+| Flag / Config Field | Type | Description | Default |

195+| ----------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |

196+| flag: `--allow-query-semicolons`<br/>toml: `allow_query_semicolons` | bool | allow the use of semicolons in query args ([required for some legacy applications](https://github.com/golang/go/issues/25192)) | `false` |

197+| flag: `--api-route`<br/>toml: `api_routes` | string \| list | Requests to these paths must already be authenticated with a cookie, or a JWT if `--skip-jwt-bearer-tokens` is set. No redirect to login will be done. Return 401 if not. Format: path_regex | |

198+| flag: `--authenticated-emails-file`<br/>toml: `authenticated_emails_file` | string | authenticate against emails via file (one per line) | |

199+| flag: `--bearer-token-login-fallback`<br/>toml: `bearer_token_login_fallback` | bool | if `--skip-jwt-bearer-tokens` is set, if a request includes an invalid JWT (expired, malformed, missing required audiences, etc), fall back to normal login redirect as if the token were not sent at all. If false, respond 403 | true |

200+| flag: `--email-domain`<br/>toml: `email_domains` | string \| list | authenticate emails with the specified domain (may be given multiple times). Use `*` to authenticate any email | |

201+| flag: `--encode-state`<br/>toml: `encode_state` | bool | encode the state parameter as UrlEncodedBase64 | false |

202+| flag: `--extra-jwt-issuers`<br/>toml: `extra_jwt_issuers` | string | if `--skip-jwt-bearer-tokens` is set, a list of extra JWT `issuer=audience` (see a token's `iss`, `aud` fields) pairs (where the issuer URL has a `.well-known/openid-configuration` or a `.well-known/jwks.json`) | |

203+| flag: `--force-https`<br/>toml: `force_https` | bool | enforce https redirect | `false` |

204+| flag: `--force-json-errors`<br/>toml: `force_json_errors` | bool | force JSON errors instead of HTTP error pages or redirects | `false` |

205+| flag: `--htpasswd-file`<br/>toml: `htpasswd_file` | string | additionally authenticate against a htpasswd file. Entries must be created with `htpasswd -B` for bcrypt encryption | |

206+| flag: `--htpasswd-user-group`<br/>toml: `htpasswd_user_groups` | string \| list | the groups to be set on sessions for htpasswd users | |

207+| flag: `--proxy-prefix`<br/>toml: `proxy_prefix` | string | the url root path that this proxy should be nested under (e.g. /`<oauth2>/sign_in`) | `"/oauth2"` |

208+| flag: `--real-client-ip-header`<br/>toml: `real_client_ip_header` | string | Header used to determine the real IP of the client, requires `--reverse-proxy` to be set (one of: X-Forwarded-For, X-Real-IP, X-ProxyUser-IP, X-Envoy-External-Address, or CF-Connecting-IP) | X-Real-IP |

209+| flag: `--redirect-url`<br/>toml: `redirect_url` | string | the OAuth Redirect URL, e.g. `"https://internalapp.yourcompany.com/oauth2/callback"` | |

210+| flag: `--relative-redirect-url`<br/>toml: `relative_redirect_url` | bool | allow relative OAuth Redirect URL.` | false |

211+| flag: `--reverse-proxy`<br/>toml: `reverse_proxy` | bool | are we running behind a reverse proxy, controls whether headers like X-Real-IP are accepted and allows X-Forwarded-\{Proto,Host,Uri\} headers to be used on redirect selection | false |

212+| flag: `--signature-key`<br/>toml: `signature_key` | string | GAP-Signature request signature key (algorithm:secretkey) | |

213+| flag: `--skip-auth-preflight`<br/>toml: `skip_auth_preflight` | bool | will skip authentication for OPTIONS requests | false |

214+| flag: `--skip-auth-regex`<br/>toml: `skip_auth_regex` | string \| list | (DEPRECATED for `--skip-auth-route`) bypass authentication for requests paths that match (may be given multiple times) | |

215+| flag: `--skip-auth-route`<br/>toml: `skip_auth_routes` | string \| list | bypass authentication for requests that match the method & path. Format: method=path_regex OR method!=path_regex. For all methods: path_regex OR !=path_regex | |

216+| flag: `--skip-jwt-bearer-tokens`<br/>toml: `skip_jwt_bearer_tokens` | bool | will skip requests that have verified JWT bearer tokens (the token must have [`aud`](https://en.wikipedia.org/wiki/JSON_Web_Token#Standard_fields) that matches this client id or one of the extras from `extra-jwt-issuers`) | false |

217+| flag: `--skip-provider-button`<br/>toml: `skip_provider_button` | bool | will skip sign-in-page to directly reach the next step: oauth/start | false |

218+| flag: `--ssl-insecure-skip-verify`<br/>toml: `ssl_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS providers | false |

219+| flag: `--trusted-ip`<br/>toml: `trusted_ips` | string \| list | list of IPs or CIDR ranges to allow to bypass authentication (may be given multiple times). When combined with `--reverse-proxy` and optionally `--real-client-ip-header` this will evaluate the trust of the IP stored in an HTTP header by a reverse proxy rather than the layer-3/4 remote address. WARNING: trusting IPs has inherent security flaws, especially when obtaining the IP address from an HTTP header (reverse-proxy mode). Use this option only if you understand the risks and how to manage them. | |

220+| flag: `--whitelist-domain`<br/>toml: `whitelist_domains` | string \| list | allowed domains for redirection after authentication. Prefix domain with a `.` or a `*.` to allow subdomains (e.g. `.example.com`, `*.example.com`)&nbsp;[^2] | |

221+

222+[^2]: When using the `whitelist-domain` option, any domain prefixed with a `.` or a `*.` will allow any subdomain of the specified domain as a valid redirect URL. By default, only empty ports are allowed. This translates to allowing the default port of the URL's protocol (80 for HTTP, 443 for HTTPS, etc.) since browsers omit them. To allow only a specific port, add it to the whitelisted domain: `example.com:8080`. To allow any port, use `*`: `example.com:*`.

223+

224+### Server Options

225+

226+| Flag / Config Field | Type | Description | Default |

227+| ------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |

228+| flag: `--http-address`<br/>toml: `http_address` | string | `[http://]<addr>:<port>` or `unix://<path>` or `fd:<int>` (case insensitive) to listen on for HTTP clients. Square brackets are required for ipv6 address, e.g. `http://[::1]:4180` | `"127.0.0.1:4180"` |

229+| flag: `--https-address`<br/>toml: `https_address` | string | `[https://]<addr>:<port>` to listen on for HTTPS clients. Square brackets are required for ipv6 address, e.g. `https://[::1]:443` | `":443"` |

230+| flag: `--metrics-address`<br/>toml: `metrics_address` | string | the address prometheus metrics will be scraped from | `""` |

231+| flag: `--metrics-secure-address`<br/>toml: `metrics_secure_address` | string | the address prometheus metrics will be scraped from if using HTTPS | `""` |

232+| flag: `--metrics-tls-cert-file`<br/>toml: `metrics_tls_cert_file` | string | path to certificate file for secure metrics server | `""` |

233+| flag: `--metrics-tls-key-file`<br/>toml: `metrics_tls_key_file` | string | path to private key file for secure metrics server | `""` |

234+| flag: `--tls-cert-file`<br/>toml: `tls_cert_file` | string | path to certificate file | |

235+| flag: `--tls-key-file`<br/>toml: `tls_key_file` | string | path to private key file | |

236+| flag: `--tls-cipher-suite`<br/>toml: `tls_cipher_suites` | string \| list | Restricts TLS cipher suites used by server to those listed (e.g. TLS_RSA_WITH_RC4_128_SHA) (may be given multiple times). If not specified, the default Go safe cipher list is used. List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). | |

237+| flag: `--tls-min-version`<br/>toml: `tls_min_version` | string | minimum TLS version that is acceptable, either `"TLS1.2"` or `"TLS1.3"` | `"TLS1.2"` |

238+

239+### Session Options

240+

241+| Flag / Config Field | Type | Description | Default |

242+| ----------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

243+| flag: `--session-cookie-minimal`<br/>toml: `session_cookie_minimal` | bool | strip OAuth tokens from cookie session stores if they aren't needed (cookie session store only) | false |

244+| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

245+| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

246+| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

247+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. |

248+| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

249+| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

250+| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

251+| flag: `--redis-sentinel-master-name`<br/>toml: `redis_sentinel_master_name` | string | Redis sentinel master name. Used in conjunction with `--redis-use-sentinel` | |

252+| flag: `--redis-sentinel-connection-urls`<br/>toml: `redis_sentinel_connection_urls` | string \| list | List of Redis sentinel connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-sentinel` | |

253+| flag: `--redis-use-cluster`<br/>toml: `redis_use_cluster` | bool | Connect to redis cluster. Must set `--redis-cluster-connection-urls` to use this feature | false |

254+| flag: `--redis-use-sentinel`<br/>toml: `redis_use_sentinel` | bool | Connect to redis via sentinels. Must set `--redis-sentinel-master-name` and `--redis-sentinel-connection-urls` to use this feature | false |

255+| flag: `--redis-connection-idle-timeout`<br/>toml: `redis_connection_idle_timeout` | int | Redis connection idle timeout seconds. If Redis [timeout](https://redis.io/docs/reference/clients/#client-timeouts) option is set to non-zero, the `--redis-connection-idle-timeout` must be less than Redis timeout option. Example: if either redis.conf includes `timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14` | 0 |

256+

257+### Upstream Options

258+

259+| Flag / Config Field | Type | Description | Default |

260+| ----------------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- |

261+| flag: `--flush-interval`<br/>toml: `flush_interval` | duration | period between flushing response buffers when streaming responses | `"1s"` |

262+| flag: `--pass-host-header`<br/>toml: `pass_host_header` | bool | pass the request Host Header to upstream | true |

263+| flag: `--proxy-websockets`<br/>toml: `proxy_websockets` | bool | enables WebSocket proxying | true |

264+| flag: `--ssl-upstream-insecure-skip-verify`<br/>toml: `ssl_upstream_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS upstreams | false |

265+| flag: `--disable-keep-alives`<br/>toml: `disable_keep_alives` | bool | disable HTTP keep-alive connections to the upstream server | false |

266+| flag: `--upstream-timeout`<br/>toml: `upstream_timeout` | duration | maximum amount of time the server will wait for a response from the upstream | 30s |

267+| flag: `--upstream`<br/>toml: `upstreams` | string \| list | the http url(s) of the upstream endpoint, file:// paths for static files or `static://<status_code>` for static response. Routing is based on the path | |

268+

269+## Upstreams Configuration

270+

271+`oauth2-proxy` supports having multiple upstreams, and has the option to pass requests on to HTTP(S) servers, unix socket or serve static files from the file system.

272+

273+To configure **HTTP and HTTPS upstreams**, provide such a URL in `--upstream=URL`. The scheme+host portion and the path portion are extracted to configure proxying behavior. When processing incoming requests, the path portion becomes a lookup key for selecting the destination server of the proxied request.

274+

275+* Upstream URLs *without a trailing slash,* like in `--upstream=http://service2.internal/foo`, will match an incoming request exactly to `/foo` in `https://this.o2p.example.com/foo`, and forward the request on to service2.internal, but not match a request to `https://this.o2p.example.com/foo/more` nor ...`.com/food`.

276+* Upstream URLs *with a trailing slash,* like in `--upstream=http://service1.internal/foo/`, will match any incoming request to any incoming requests's path *starting with* `/foo/`, like `/foo/` and `/foo/more` and `/foo/lots/more?etc`.

277+

278+If multiple `--upstream` URLs' paths match an incoming request, the one with the longest matching path (the most specific match) takes priority over shorter (less specific) ones.

279+

280+**Unix socket upstreams** are configured as `unix:///path/to/unix.sock`.

281+

282+**Static file paths** are configured as a file:// URL. `file:///var/www/static/` will serve the files from that directory at `http://[oauth2-proxy url]/var/www/static/`, which may not be what you want. You can provide the path to where the files should be available by adding a fragment to the configured URL. The value of the fragment will then be used to specify which path the files are available at, e.g. `file:///var/www/static/#/static/` will make `/var/www/static/` available at `http://[oauth2-proxy url]/static/`.

283+

284+Multiple upstreams can either be configured by supplying a comma separated list to the `--upstream` parameter, supplying the parameter multiple times or providing a list in the [config file](#config-file). When multiple upstreams are used routing to them will be based on the path they are set up with.

285+

286+## Environment variables

287+

288+Every command line argument can be specified as an environment variable by

289+prefixing it with `OAUTH2_PROXY_`, capitalising it, and replacing hyphens (`-`)

290+with underscores (`_`). If the argument can be specified multiple times, the

291+environment variable should be plural (trailing `S`).

292+

293+This is particularly useful for storing secrets outside a configuration file

294+or the command line.

295+

296+For example, the `--cookie-secret` flag becomes `OAUTH2_PROXY_COOKIE_SECRET`.

297+If a flag has the type `string | list` like the `--email-domain` flag it is

298+available as an environment variable in plural form e.g. `OAUTH2_PROXY_EMAIL_DOMAINS`

299+

300+Values for type `string | list` usually have a plural environment variable name

301+and need to be seperated by `,` e.g.

302+`OAUTH2_PROXY_SKIP_AUTH_ROUTES="GET=^/api/status,POST=^/api/saved_objects/_import"`

303+

304+Please check the type for each [config option](#config-options) first.

305+

306+## Logging Configuration

307+

308+By default, OAuth2 Proxy logs all output to stdout. Logging can be configured to output to a rotating log file using the `--logging-filename` command.

309+

310+If logging to a file you can also configure the maximum file size (`--logging-max-size`), age (`--logging-max-age`), max backup logs (`--logging-max-backups`), and if backup logs should be compressed (`--logging-compress`).

311+

312+There are three different types of logging: standard, authentication, and HTTP requests. These can each be enabled or disabled with `--standard-logging`, `--auth-logging`, and `--request-logging`.

313+

314+Each type of logging has its own configurable format and variables. By default, these formats are similar to the Apache Combined Log.

315+

316+Logging of requests to the `/ping` endpoint (or using `--ping-user-agent`) and the `/ready` endpoint can be disabled with `--silence-ping-logging` reducing log volume.

317+

318+## Auth Log Format

319+

320+Authentication logs are logs which are guaranteed to contain a username or email address of a user attempting to authenticate. These logs are output by default in the below format:

321+

322+```

323+<REMOTE_ADDRESS> - <REQUEST ID> - <user@domain.com> [2015/03/19 17:20:19] [<STATUS>] <MESSAGE>

324+```

325+

326+The status block will contain one of the below strings:

327+

328+- `AuthSuccess` If a user has authenticated successfully by any method

329+- `AuthFailure` If the user failed to authenticate explicitly

330+- `AuthError` If there was an unexpected error during authentication

331+

332+If you require a different format than that, you can configure it with the `--auth-logging-format` flag.

333+The default format is configured as follows:

334+

335+```

336+{{.Client}} - {{.RequestID}} - {{.Username}} [{{.Timestamp}}] [{{.Status}}] {{.Message}}

337+```

338+

339+Available variables for auth logging:

340+

341+| Variable | Example | Description |

342+| ------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------- |

343+| Client | 74.125.224.72 | The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true. |

344+| Host | domain.com | The value of the Host header. |

345+| Message | Authenticated via OAuth2 | The details of the auth attempt. |

346+| Protocol | HTTP/1.0 | The request protocol. |

347+| RequestID | 00010203-0405-4607-8809-0a0b0c0d0e0f | The request ID pulled from the `--request-id-header`. Random UUID if empty |

348+| RequestMethod | GET | The request method. |

349+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

350+| UserAgent | - | The full user agent as reported by the requesting client. |

351+| Username | username@email.com | The email or username of the auth request. |

352+| Status | AuthSuccess | The status of the auth request. See above for details. |

353+

354+## Request Log Format

355+

356+HTTP request logs will output by default in the below format:

357+

358+```

359+<REMOTE_ADDRESS> - <REQUEST ID> - <user@domain.com> [2015/03/19 17:20:19] <HOST_HEADER> GET <UPSTREAM_HOST> "/path/" HTTP/1.1 "<USER_AGENT>" <RESPONSE_CODE> <RESPONSE_BYTES> <REQUEST_DURATION>

360+```

361+

362+If you require a different format than that, you can configure it with the `--request-logging-format` flag.

363+The default format is configured as follows:

364+

365+```

366+{{.Client}} - {{.RequestID}} - {{.Username}} [{{.Timestamp}}] {{.Host}} {{.RequestMethod}} {{.Upstream}} {{.RequestURI}} {{.Protocol}} {{.UserAgent}} {{.StatusCode}} {{.ResponseSize}} {{.RequestDuration}}

367+```

368+

369+Available variables for request logging:

370+

371+| Variable | Example | Description |

372+| --------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------- |

373+| Client | 74.125.224.72 | The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true. |

374+| Host | domain.com | The value of the Host header. |

375+| Protocol | HTTP/1.0 | The request protocol. |

376+| RequestDuration | 0.001 | The time in seconds that a request took to process. |

377+| RequestID | 00010203-0405-4607-8809-0a0b0c0d0e0f | The request ID pulled from the `--request-id-header`. Random UUID if empty |

378+| RequestMethod | GET | The request method. |

379+| RequestURI | "/oauth2/auth" | The URI path of the request. |

380+| ResponseSize | 12 | The size in bytes of the response. |

381+| StatusCode | 200 | The HTTP status code of the response. |

382+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

383+| Upstream | - | The upstream data of the HTTP request. |

384+| UserAgent | - | The full user agent as reported by the requesting client. |

385+| Username | username@email.com | The email or username of the auth request. |

386+

387+## Standard Log Format

388+

389+All other logging that is not covered by the above two types of logging will be output in this standard logging format. This includes configuration information at startup and errors that occur outside of a session. The default format is below:

390+

391+```

392+[2015/03/19 17:20:19] [main.go:40] <MESSAGE>

393+```

394+

395+If you require a different format than that, you can configure it with the `--standard-logging-format` flag. The default format is configured as follows:

396+

397+```

398+[{{.Timestamp}}] [{{.File}}] {{.Message}}

399+```

400+

401+Available variables for standard logging:

402+

403+| Variable | Example | Description |

404+| --------- | --------------------------------- | -------------------------------------------------- |

405+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

406+| File | main.go:40 | The file and line number of the logging statement. |

407+| Message | HTTP: listening on 127.0.0.1:4180 | The details of the log statement. |

docs/versioned_docs/version-7.13.x/configuration/providers/adfs.mdnew file+19

@@ -0,0 +1,19 @@

1+---

2+id: adfs

3+title: ADFS

4+---

5+

6+1. Open the ADFS administration console on your Windows Server and add a new Application Group

7+2. Provide a name for the integration, select Server Application from the Standalone applications section and click Next

8+3. Follow the wizard to get the client-id, client-secret and configure the application credentials

9+4. Configure the proxy with

10+

11+```

12+ --provider=adfs

13+ --client-id=<application ID from step 3>

14+ --client-secret=<value from step 3>

15+```

16+

17+Note: When using the ADFS Auth provider with nginx and the cookie session store you may find the cookie is too large and

18+doesn't get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the

19+[redis session storage](../sessions.md#redis-storage) should resolve this.

docs/versioned_docs/version-7.13.x/configuration/providers/bitbucket.mdnew file+25

@@ -0,0 +1,25 @@

1+---

2+id: bitbucket

3+title: BitBucket

4+---

5+

6+1. [Add a new OAuth consumer](https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html)

7+ * In "Callback URL" use `https://<oauth2-proxy>/oauth2/callback`, substituting `<oauth2-proxy>` with the actual

8+ hostname that oauth2-proxy is running on.

9+ * In Permissions section select:

10+ * Account -> Email

11+ * Team membership -> Read

12+ * Repositories -> Read

13+2. Note the Client ID and Client Secret.

14+

15+To use the provider, pass the following options:

16+

17+```

18+ --provider=bitbucket

19+ --client-id=<Client ID>

20+ --client-secret=<Client Secret>

21+```

22+

23+The default configuration allows everyone with Bitbucket account to authenticate. To restrict the access to the team

24+members use additional configuration option: `--bitbucket-team=<Team name>`. To restrict the access to only these users

25+who have access to one selected repository use `--bitbucket-repository=<Repository name>`.

docs/versioned_docs/version-7.13.x/configuration/providers/cidaas.mdnew file+37

@@ -0,0 +1,37 @@

1+---

2+id: cidaas

3+title: Cidaas

4+---

5+

6+[Cidaas](https://www.cidaas.com/) is an Identity as a Service (IDaaS) solution that provides authentication and authorization services.

7+It supports various protocols including OpenID Connect, OAuth 2.0, and SAML.

8+

9+However, Cidaas provides groups and their roles as hierarchical claims, which are not supported by oauth2-proxy yet.

10+The Cidaas provider transforms the hierarchical claims into a flat list of groups, which can be used by oauth2-proxy.

11+

12+Example of groups and roles in Cidaas:

13+

14+```json

15+{

16+ "groups": [

17+ {

18+ "groupId": "group1",

19+ "roles": ["role1", "role2"]

20+ },

21+ {

22+ "groupId": "group2",

23+ "roles": ["role3"]

24+ }

25+ ]

26+}

27+```

28+

29+This will be transformed into a flat list of groups:

30+

31+```json

32+{

33+ "groups": ["group1:role1", "group2:role2", "group2:role3"]

34+}

35+```

36+

37+Apart from that the Cidaas provider inherits all the features of the [OpenID Connect provider](openid_connect.md).

docs/versioned_docs/version-7.13.x/configuration/providers/cisco_duo.mdnew file+44

@@ -0,0 +1,44 @@

1+---

2+id: cisco_duo

3+title: Cisco Duo

4+---

5+

6+Cisco Duo SSO can be configured with OAuth2 Proxy using the OIDC provider.

7+

8+1. Create a new **Generic OIDC Relying Party - Single Sign-On** application in the Duo Admin Portal

9+2. Configure OAuth2 Proxy with the following options:

10+

11+```

12+provider = "oidc"

13+provider_display_name = "Duo SSO"

14+scope = "openid email profile"

15+pass_access_token = true

16+code_challenge_method = "S256"

17+```

18+

19+3. Configure Provider endpoints. Copy the following values from the corresponding fields in the Duo Admin Portal:

20+

21+```

22+# Copy from "Client ID" field

23+client_id = "XXXXXXXX"

24+

25+# Copy from "Client Secret" field

26+client_secret = "XXXXXXXX"

27+

28+# Copy from "Issuer" field

29+oidc_issuer_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx"

30+

31+# Copy from "JWKS URL" field

32+oidc_jwks_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/jwks"

33+

34+# Copy from "Token Introspection URL" field

35+validate_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/token_introspection"

36+

37+# Copy from "UserInfo" field

38+profile_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/userinfo"

39+

40+# Copy from "Token URL" field

41+redeem_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/token"

42+```

43+

44+4. Complete Configuration by filling in any remaining required fields and save your configuration.

docs/versioned_docs/version-7.13.x/configuration/providers/digitalocean.mdnew file+21

@@ -0,0 +1,21 @@

1+---

2+id: digitalocean

3+title: DigitalOcean

4+---

5+

6+1. [Create a new OAuth application](https://cloud.digitalocean.com/account/api/applications)

7+ * You can fill in the name, homepage, and description however you wish.

8+ * In the "Application callback URL" field, enter: `https://oauth-proxy/oauth2/callback`, substituting `oauth2-proxy`

9+ with the actual hostname that oauth2-proxy is running on. The URL must match oauth2-proxy's configured redirect URL.

10+2. Note the Client ID and Client Secret.

11+

12+To use the provider, pass the following options:

13+

14+```

15+ --provider=digitalocean

16+ --client-id=<Client ID>

17+ --client-secret=<Client Secret>

18+```

19+

20+Alternatively, set the equivalent options in the config file. The redirect URL defaults to

21+`https://<requested host header>/oauth2/callback`. If you need to change it, you can use the `--redirect-url` command-line option.

docs/versioned_docs/version-7.13.x/configuration/providers/facebook.mdnew file+7

@@ -0,0 +1,7 @@

1+---

2+id: facebook

3+title: Facebook

4+---

5+

6+1. Create a new FB App from https://developers.facebook.com/

7+2. Under FB Login, set your Valid OAuth redirect URIs to `https://internal.yourcompany.com/oauth2/callback`

docs/versioned_docs/version-7.13.x/configuration/providers/gitea.mdnew file+24

@@ -0,0 +1,24 @@

1+---

2+id: gitea

3+title: Gitea / Forgejo

4+---

5+

6+:::note

7+This is not actually a fully serparate provider. For more details and options please refer to the [GitHub Provider Options](github.md)

8+:::

9+

10+1. Create a new application: `https://< your gitea host >/user/settings/applications`

11+2. Under `Redirect URI` enter the correct URL i.e. `https://<proxied host>/oauth2/callback`

12+3. Note the Client ID and Client Secret.

13+4. Pass the following options to the proxy:

14+

15+```

16+ --provider="github"

17+ --redirect-url="https://<proxied host>/oauth2/callback"

18+ --provider-display-name="Gitea"

19+ --client-id="< client_id as generated by Gitea >"

20+ --client-secret="< client_secret as generated by Gitea >"

21+ --login-url="https://< your gitea host >/login/oauth/authorize"

22+ --redeem-url="https://< your gitea host >/login/oauth/access_token"

23+ --validate-url="https://< your gitea host >/api/v1/user/emails"

24+```

docs/versioned_docs/version-7.13.x/configuration/providers/github.mdnew file+81

@@ -0,0 +1,81 @@

1+---

2+id: github

3+title: GitHub

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ---------------- | -------------- | -------------- | ------------------------------------------------------------------------------------------------------------- | ------- |

10+| `--github-org` | `github_org` | string | restrict logins to members of this organisation | |

11+| `--github-team` | `github_team` | string | restrict logins to members of any of these teams (slug) or (org:team), comma separated | |

12+| `--github-repo` | `github_repo` | string | restrict logins to collaborators of this repository formatted as `orgname/repo` | |

13+| `--github-token` | `github_token` | string | the token to use when verifying repository collaborators (must have push access to the repository) | |

14+| `--github-user` | `github_users` | string \| list | To allow users to login by username even if they do not belong to the specified org and team or collaborators | |

15+

16+## Usage

17+

18+1. Create a new project: https://github.com/settings/developers

19+2. Under `Authorization callback URL` enter the correct url ie `https://internal.yourcompany.com/oauth2/callback`

20+

21+The GitHub auth provider supports two additional ways to restrict authentication to either organization and optional

22+team level access, or to collaborators of a repository. Restricting by these options is normally accompanied with `--email-domain=*`. Additionally, all the organizations and teams a user belongs to are set as part of the `X-Forwarded-Groups` header. e.g. `org1:team1,org1:team2,org2:team1`

23+

24+NOTE: When `--github-user` is set, the specified users are allowed to log in even if they do not belong to the specified

25+org and team or collaborators.

26+

27+To restrict access to your organization:

28+

29+```shell

30+ # restrict logins to members of this organisation

31+ --github-org="your-org"

32+```

33+

34+To restrict access to specific teams within an organization:

35+

36+```shell

37+ --github-org="your-org"

38+ # restrict logins to members of any of these teams (slug), comma separated

39+ --github-team="team1,team2,team3"

40+```

41+

42+To restrict to teams within different organizations, keep the organization flag empty and use `--github-team` like so:

43+

44+```shell

45+ # keep empty

46+ --github-org=""

47+ # restrict logins to members to any of the following teams (format <org>:<slug>, like octo:team1), comma separated

48+ --github-team="org1:team1,org2:team1,org3:team42,octo:cat"

49+```

50+

51+If you would rather restrict access to collaborators of a repository, those users must either have push access to a

52+public repository or any access to a private repository:

53+

54+```shell

55+ # restrict logins to collaborators of this repository formatted as orgname/repo

56+ --github-repo=""

57+```

58+

59+If you'd like to allow access to users with **read only** access to a **public** repository you will need to provide a

60+[token](https://github.com/settings/tokens) for a user that has write access to the repository. The token must be

61+created with at least the `public_repo` scope:

62+

63+```shell

64+ # the token to use when verifying repository collaborators

65+ --github-token=""

66+```

67+

68+To allow a user to log in with their username even if they do not belong to the specified org and team or collaborators:

69+

70+```shell

71+ # allow logins by username, comma separated

72+ --github-user=""

73+```

74+

75+If you are using GitHub enterprise, make sure you set the following to the appropriate url:

76+

77+```shell

78+ --login-url="http(s)://<enterprise github host>/login/oauth/authorize"

79+ --redeem-url="http(s)://<enterprise github host>/login/oauth/access_token"

80+ --validate-url="http(s)://<enterprise github host>/api/v3"

81+```

docs/versioned_docs/version-7.13.x/configuration/providers/gitlab.mdnew file+49

@@ -0,0 +1,49 @@

1+---

2+id: gitlab

3+title: GitLab

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

10+| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

12+

13+## Usage

14+

15+This auth provider has been tested against Gitlab version 12.X. Due to Gitlab API changes, it may not work for version

16+prior to 12.X (see [994](https://github.com/oauth2-proxy/oauth2-proxy/issues/994)).

17+

18+Whether you are using GitLab.com or self-hosting GitLab, follow

19+[these steps to add an application](https://docs.gitlab.com/integration/oauth_provider/). Make sure to enable at

20+least the `openid`, `profile` and `email` scopes, and set the redirect url to your application url e.g.

21+https://myapp.com/oauth2/callback.

22+

23+If you need projects filtering, add the extra `read_api` scope to your application.

24+

25+The following config should be set to ensure that the oauth will work properly. To get a cookie secret follow

26+[these steps](../overview.md#generating-a-cookie-secret)

27+

28+```

29+ --provider="gitlab"

30+ --redirect-url="https://myapp.com/oauth2/callback" // Should be the same as the redirect url for the application in gitlab

31+ --client-id=GITLAB_CLIENT_ID

32+ --client-secret=GITLAB_CLIENT_SECRET

33+ --cookie-secret=COOKIE_SECRET

34+```

35+

36+Restricting by group membership is possible with the following option:

37+

38+```shell

39+ --gitlab-group="mygroup,myothergroup" # restrict logins to members of any of these groups (slug), separated by a comma

40+```

41+

42+If you are using self-hosted GitLab, make sure you set the following to the appropriate URL:

43+

44+```shell

45+ --oidc-issuer-url="<your gitlab url>"

46+```

47+

48+If your self-hosted GitLab is on a subdirectory (e.g. domain.tld/gitlab), as opposed to its own subdomain

49+(e.g. gitlab.domain.tld), you may need to add a redirect from domain.tld/oauth pointing at e.g. domain.tld/gitlab/oauth.

docs/versioned_docs/version-7.13.x/configuration/providers/google.mdnew file+84

@@ -0,0 +1,84 @@

1+---

2+id: google

3+title: Google (default)

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+|-------------------------------------------------|----------------------------------------------| ------ |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------|

10+| `--google-admin-email` | `google_admin_email` | string | the google admin to impersonate for api calls | |

11+| `--google-group` | `google_groups` | string | restrict logins to members of this google group (may be given multiple times). If not specified and service account or default credentials are configured, all user groups will be allowed. | |

12+| `--google-service-account-json` | `google_service_account_json` | string | the path to the service account json credentials | |

13+| `--google-use-application-default-credentials` | `google_use_application_default_credentials` | bool | use application default credentials instead of service account json (i.e. GKE Workload Identity) | |

14+| `--google-target-principal` | `google_target_principal` | bool | the target principal to impersonate when using ADC | defaults to the service account configured for ADC |

15+| `--google-use-organization-id` | `google_use_organization_id` | bool | use organization id as preferred username | false |

16+| `--google-admin-api-user-scope` | `google_admin_api_user_scope` | string | the OAuth scope to use when querying the Google Admin SDK for organization id, can be 'readonly', 'user' or 'cloud'<br/> | `readonly` |

17+

18+## Usage

19+

20+For Google, the registration steps are:

21+

22+1. Create a new project: https://console.developers.google.com/project

23+2. Choose the new project from the top right project dropdown (only if another project is selected)

24+3. In the project Dashboard center pane, choose **"APIs & Services"**

25+4. In the left Nav pane, choose **"Credentials"**

26+5. In the center pane, choose **"OAuth consent screen"** tab. Fill in **"Product name shown to users"** and hit save.

27+6. In the center pane, choose **"Credentials"** tab.

28+ - Open the **"New credentials"** drop down

29+ - Choose **"OAuth client ID"**

30+ - Choose **"Web application"**

31+ - Application name is freeform, choose something appropriate

32+ - Authorized JavaScript origins is your domain ex: `https://internal.yourcompany.com`

33+ - Authorized redirect URIs is the location of oauth2/callback ex: `https://internal.yourcompany.com/oauth2/callback`

34+ - Choose **"Create"**

35+7. Take note of the **Client ID** and **Client Secret**

36+

37+It's recommended to refresh sessions on a short interval (1h) with `cookie-refresh` setting which validates that the

38+account is still authorized.

39+

40+#### Restrict auth to specific Google groups on your domain. (optional)

41+

42+1. Create a [service account](https://developers.google.com/identity/protocols/oauth2/service-account) and configure it

43+ to use [Application Default Credentials / Workload Identity / Workload Identity Federation (recommended)](#using-application-default-credentials-adc--workload-identity--workload-identity-federation-recommended) or,

44+ alternatively download the JSON.

45+2. Make note of the Client ID for a future step.

46+3. Under "APIs & Auth", choose APIs.

47+4. Click on Admin SDK and then Enable API.

48+5. Follow the steps on [Set up domain-wide delegation for a service account](https://developers.google.com/workspace/guides/create-credentials#optional_set_up_domain-wide_delegation_for_a_service_account)

49+ and give the client id from step 2 the following oauth scopes:

50+

51+ ```

52+ https://www.googleapis.com/auth/admin.directory.group.member.readonly

53+ ```

54+

55+6. Follow the steps on https://support.google.com/a/answer/60757 to enable Admin API access.

56+7. Create or choose an existing administrative email address on the Gmail domain to assign to the `google-admin-email`

57+ flag. This email will be impersonated by this client to make calls to the Admin SDK. See the note on the link from

58+ step 5 for the reason why.

59+8. Create or choose an existing email group and set that email to the `google-group` flag. You can pass multiple instances

60+ of this flag with different groups and the user will be checked against all the provided groups.

61+

62+(Only if using a JSON file (see step 1))

63+

64+9. Lock down the permissions on the json file downloaded from step 1 so only oauth2-proxy is able to read the file and

65+ set the path to the file in the `google-service-account-json` flag.

66+10. Restart oauth2-proxy.

67+

68+Note: The user is checked against the group members list on initial authentication and every time the token is

69+refreshed ( about once an hour ).

70+

71+##### Using Application Default Credentials (ADC) / Workload Identity / Workload Identity Federation (recommended)

72+oauth2-proxy can make use of [Application Default Credentials](https://cloud.google.com/docs/authentication/application-default-credentials).

73+When deployed within GCP, this means that it can automatically use the service account attached to the resource. When deployed to GKE, ADC

74+can be leveraged through a feature called Workload Identity. Follow Google's [guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)

75+to set up Workload Identity.

76+

77+When deployed outside of GCP, [Workload Identity Federation](https://cloud.google.com/docs/authentication/provide-credentials-adc#wlif) might be an option.

78+

79+##### Using Organization ID as Preferred Username (optional)

80+By default, the google provider uses the google id as username. If you would like to use an organization id instead, you can set the `google-use-organization-id` flag to true.

81+This requires that the service account used to query the Google Admin SDK has one of the following scopes granted in step 5 above:

82+- `https://www.googleapis.com/auth/admin.directory.user.readonly`,

83+- `https://www.googleapis.com/auth/admin.directory.user`

84+- `https://www.googleapis.com/auth/cloud-platform`

docs/versioned_docs/version-7.13.x/configuration/providers/index.mdnew file+46

@@ -0,0 +1,46 @@

1+---

2+id: index

3+title: OAuth Provider Configuration

4+---

5+

6+You will need to register an OAuth application with a Provider (Google, GitHub or another provider), and configure it

7+with Redirect URI(s) for the domain you intend to run `oauth2-proxy` on.

8+

9+Valid providers are :

10+

11+- [ADFS](adfs.md)

12+- [Bitbucket](bitbucket.md)

13+- [Cidaas](cidaas.md)

14+- [CiscoDuo](cisco_duo.md)

15+- [DigitalOcean](digitalocean.md)

16+- [Facebook](facebook.md)

17+- [Gitea](gitea.md)

18+- [GitHub](github.md)

19+- [GitLab](gitlab.md)

20+- [Google](google.md) _default_

21+- [Keycloak](keycloak.md) (Deprecated)

22+- [Keycloak OIDC](keycloak_oidc.md)

23+- [LinkedIn](linkedin.md)

24+- [login.gov](login_gov.md)

25+- [Microsoft Azure](ms_azure_ad.md) (Deprecated)

26+- [Microsoft Entra ID](ms_entra_id.md)

27+- [Nextcloud](nextcloud.md)

28+- [OpenID Connect](openid_connect.md)

29+- [SourceHut](sourcehut.md)

30+

31+The provider can be selected using the `provider` configuration value, or set in the [`providers` array using AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers). However, [**the feature to implement multiple providers is not complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

32+

33+Please note that not all providers support all claims. The `preferred_username` claim is currently only supported by the

34+OpenID Connect provider.

35+

36+## Email Authentication

37+

38+To authorize a specific email-domain use `--email-domain=yourcompany.com`. To authorize individual email addresses use

39+`--authenticated-emails-file=/path/to/file` with one email per line. To authorize all email addresses use `--email-domain=*`.

40+

41+## Adding a new Provider

42+

43+Follow the examples in the [`providers` package](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/) to define a new

44+`Provider` instance. Add a new `case` to

45+[`providers.New()`](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/providers.go) to allow `oauth2-proxy` to use the

46+new `Provider`.

docs/versioned_docs/version-7.13.x/configuration/providers/keycloak.mdnew file+36

@@ -0,0 +1,36 @@

1+---

2+id: keycloak

3+title: Keycloak (Deprecated)

4+---

5+

6+:::note

7+This is the legacy and deprecated provider for Keycloak, use [Keycloak OIDC Auth Provider](keycloak_oidc.md) if possible.

8+:::

9+

10+1. Create new client in your Keycloak realm with **Access Type** 'confidential' and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'

11+2. Take note of the Secret in the credential tab of the client

12+3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.

13+

14+Make sure you set the following to the appropriate url:

15+

16+```

17+ --provider=keycloak

18+ --client-id=<client you have created>

19+ --client-secret=<your client's secret>

20+ --login-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/auth"

21+ --redeem-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/token"

22+ --profile-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"

23+ --validate-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"

24+ --keycloak-group=<first_allowed_user_group>

25+ --keycloak-group=<second_allowed_user_group>

26+```

27+

28+For group based authorization, the optional `--keycloak-group` (legacy) or `--allowed-group` (global standard)

29+flags can be used to specify which groups to limit access to.

30+

31+If these are unset but a `groups` mapper is set up above in step (3), the provider will still

32+populate the `X-Forwarded-Groups` header to your upstream server with the `groups` data in the

33+Keycloak userinfo endpoint response.

34+

35+The group management in keycloak is using a tree. If you create a group named admin in keycloak

36+you should define the 'keycloak-group' value to /admin.

docs/versioned_docs/version-7.13.x/configuration/providers/keycloak_oidc.mdnew file+151

@@ -0,0 +1,151 @@

1+---

2+id: keycloak_oidc

3+title: Keycloak OIDC

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ---------------- | --------------- | -------------- | ------------------------------------------------------------------------------------------------------------------ | ------- |

10+| `--allowed-role` | `allowed_roles` | string \| list | restrict logins to users with this role (may be given multiple times). Only works with the keycloak-oidc provider. | |

11+

12+## Usage

13+

14+```

15+ --provider=keycloak-oidc

16+ --client-id=<your client's id>

17+ --client-secret=<your client's secret>

18+ --redirect-url=https://internal.yourcompany.com/oauth2/callback

19+ --oidc-issuer-url=https://<keycloak host>/realms/<your realm> // For Keycloak versions <17: --oidc-issuer-url=https://<keycloak host>/auth/realms/<your realm>

20+ --email-domain=<yourcompany.com> // Validate email domain for users, see option documentation

21+ --allowed-role=<realm role name> // Optional, required realm role

22+ --allowed-role=<client id>:<client role name> // Optional, required client role

23+ --allowed-group=</group name> // Optional, requires group client scope

24+ --code-challenge-method=S256 // PKCE

25+```

26+

27+:::note

28+Keycloak has updated its admin console and as of version 19.0.0, the new admin console is enabled by default. The

29+legacy admin console has been announced for removal with the release of version 21.0.0.

30+:::

31+

32+**Keycloak legacy admin console**

33+

34+1. Create new client in your Keycloak realm with **Access Type** 'confidential', **Client protocol** 'openid-connect'

35+ and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'

36+2. Take note of the Secret in the credential tab of the client

37+3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.

38+4. Create a mapper with **Mapper Type** 'Audience' and **Included Client Audience** and **Included Custom Audience** set

39+ to your client name.

40+

41+**Keycloak new admin console (default as of v19.0.0)**

42+

43+The following example shows how to create a simple OIDC client using the new Keycloak admin2 console. However, for best

44+practices, it is recommended to consult the Keycloak documentation.

45+

46+The OIDC client must be configured with an _audience mapper_ to include the client's name in the `aud` claim of the JWT token.

47+The `aud` claim specifies the intended recipient of the token, and OAuth2 Proxy expects a match against the values of

48+either `--client-id` or `--oidc-extra-audience`.

49+

50+_In Keycloak, claims are added to JWT tokens through the use of mappers at either the realm level using "client scopes" or

51+through "dedicated" client mappers._

52+

53+**Creating the client**

54+

55+1. Create a new OIDC client in your Keycloak realm by navigating to:

56+ **Clients** -> **Create client**

57+ * **Client Type** 'OpenID Connect'

58+ * **Client ID** `<your client's id>`, please complete the remaining fields as appropriate and click **Next**.

59+ * **Client authentication** 'On'

60+ * **Authentication flow**

61+ * **Standard flow** 'selected'

62+ * **Direct access grants** 'deselect'

63+ * _Save the configuration._

64+ * **Settings / Access settings**:

65+ * **Valid redirect URIs** `https://internal.yourcompany.com/oauth2/callback`

66+ * _Save the configuration._

67+ * Under the **Credentials** tab you will now be able to locate `<your client's secret>`.

68+2. Configure a dedicated *audience mapper* for your client by navigating to **Clients** -> **\<your client's id\>** -> **Client scopes**.

69+* Access the dedicated mappers pane by clicking **\<your client's id\>-dedicated**, located under *Assigned client scope*.

70+ _(It should have a description of "Dedicated scope and mappers for this client")_

71+ * Click **Configure a new mapper** and select **Audience**

72+ * **Name** 'aud-mapper-\<your client's id\>'

73+ * **Included Client Audience** select `<your client's id>` from the dropdown.

74+ * _OAuth2 proxy can be set up to pass both the access and ID JWT tokens to your upstream services.

75+ If you require additional audience entries, you can use the **Included Custom Audience** field in addition

76+ to the "Included Client Audience" dropdown. Note that the "aud" claim of a JWT token should be limited and

77+ only specify its intended recipients._

78+ * **Add to ID token** 'On'

79+ * **Add to access token** 'On' - [#1916](https://github.com/oauth2-proxy/oauth2-proxy/pull/1916)

80+ * _Save the configuration._

81+* Any subsequent dedicated client mappers can be defined by clicking **Dedicated scopes** -> **Add mapper** ->

82+ **By configuration** -> *Select mapper*

83+

84+You should now be able to create a test user in Keycloak and get access to the OAuth2 Proxy instance, make sure to set

85+an email address matching `<yourcompany.com>` and select _Email verified_.

86+

87+**Authorization**

88+

89+_OAuth2 Proxy will perform authorization by requiring a valid user, this authorization can be extended to take into

90+account a user's membership in Keycloak `groups`, `realm roles`, and `client roles` using the keycloak-oidc provider options

91+`--allowed-role` or `--allowed-group`_

92+

93+**Roles**

94+

95+_A standard Keycloak installation comes with the required mappers for **realm roles** and **client roles** through the

96+pre-defined client scope "roles". This ensures that any roles assigned to a user are included in the `JWT` tokens when

97+using an OIDC client that has the "Full scope allowed" feature activated, the feature is enabled by default._

98+

99+_Creating a realm role_

100+* Navigate to **Realm roles** -> **Create role**

101+ * **Role name**, *`<realm role name>`* -> **save**

102+

103+_Creating a client role_

104+* Navigate to **Clients** -> `<your client's id>` -> **Roles** -> **Create role**

105+ * **Role name**, *`<client role name>`* -> **save**

106+

107+

108+_Assign a role to a user_

109+

110+**Users** -> _Username_ -> **Role mapping** -> **Assign role** -> _filter by roles or clients and select_ -> **Assign**.

111+

112+Keycloak "realm roles" can be authorized using the `--allowed-role=<realm role name>` option, while "client roles" can be

113+evaluated using `--allowed-role=<your client's id>:<client role name>`.

114+

115+You may limit the _realm roles_ included in the JWT tokens for any given client by navigating to:

116+**Clients** -> `<your client's id>` -> **Client scopes** -> _\<your client's id\>-dedicated_ -> **Scope**

117+Disabling **Full scope allowed** activates the **Assign role** option, allowing you to select which roles, if assigned

118+to a user, will be included in the user's JWT tokens. This can be useful when a user has many associated roles, and you

119+want to reduce the size and impact of the JWT token.

120+

121+

122+**Groups**

123+

124+You may also do authorization on group memberships by using the OAuth2 Proxy option `--allowed-group`.

125+We will only do a brief description of creating the required _client scope_ **groups** and refer you to read the Keycloak

126+documentation.

127+

128+To summarize, the steps required to authorize Keycloak group membership with OAuth2 Proxy are as follows:

129+

130+* Create a new Client Scope with the name **groups** in Keycloak.

131+ * Include a mapper of type **Group Membership**.

132+ * Set the "Token Claim Name" to **groups** or customize by matching it to the `--oidc-groups-claim` option of OAuth2 Proxy.

133+ * If the "Full group path" option is selected, you need to include a "/" separator in the group names defined in the

134+ `--allowed-group` option of OAuth2 Proxy. Example: "/groupname" or "/groupname/child_group".

135+

136+After creating the _Client Scope_ named _groups_ you will need to attach it to your client.

137+**Clients** -> `<your client's id>` -> **Client scopes** -> **Add client scope** -> Select **groups** and choose Optional

138+and you should now have a client that maps group memberships into the JWT tokens so that Oauth2 Proxy may evaluate them.

139+

140+Create a group by navigating to **Groups** -> **Create group** and _add_ your test user as a member.

141+

142+The OAuth2 Proxy option `--allowed-group=/groupname` will now allow you to filter on group membership

143+

144+Keycloak also has the option of attaching roles to groups, please refer to the Keycloak documentation for more information.

145+

146+**Tip**

147+

148+To check if roles or groups are added to JWT tokens, you can preview a users token in the Keycloak console by following

149+these steps: **Clients** -> `<your client's id>` -> **Client scopes** -> **Evaluate**.

150+Select a _realm user_ and optional _scope parameters_ such as groups, and generate the JSON representation of an access

151+or id token to examine its contents.

docs/versioned_docs/version-7.13.x/configuration/providers/linkedin.mdnew file+13

@@ -0,0 +1,13 @@

1+---

2+id: linkedin

3+title: LinkedIn

4+---

5+

6+For LinkedIn, the registration steps are:

7+

8+1. Create a new project: https://www.linkedin.com/secure/developer

9+2. In the OAuth User Agreement section:

10+ - In default scope, select r_basicprofile and r_emailaddress.

11+ - In "OAuth 2.0 Redirect URLs", enter `https://internal.yourcompany.com/oauth2/callback`

12+3. Fill in the remaining required fields and Save.

13+4. Take note of the **Consumer Key / API Key** and **Consumer Secret / Secret Key**

docs/versioned_docs/version-7.13.x/configuration/providers/login_gov.mdnew file+79

@@ -0,0 +1,79 @@

1+---

2+id: login_gov

3+title: Login.gov

4+---

5+

6+login.gov is an OIDC provider for the US Government.

7+If you are a US Government agency, you can contact the login.gov team through the contact information

8+that you can find on https://login.gov/developers/ and work with them to understand how to get login.gov

9+accounts for integration/test and production access.

10+

11+A developer guide is available here: https://developers.login.gov/, though this proxy handles everything

12+but the data you need to create to register your application in the login.gov dashboard.

13+

14+As a demo, we will assume that you are running your application that you want to secure locally on

15+http://localhost:3000/, that you will be starting your proxy up on http://localhost:4180/, and that

16+you have an agency integration account for testing.

17+

18+First, register your application in the dashboard. The important bits are:

19+* Identity protocol: make this `Openid connect`

20+* Issuer: do what they say for OpenID Connect. We will refer to this string as `${LOGINGOV_ISSUER}`.

21+* Public key: This is a self-signed certificate in .pem format generated from a 2048-bit RSA private key.

22+ A quick way to do this is

23+ `openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 3650 -nodes -subj '/C=US/ST=Washington/L=DC/O=GSA/OU=18F/CN=localhost'`.

24+ The contents of the `key.pem` shall be referred to as `${OAUTH2_PROXY_JWT_KEY}`.

25+* Return to App URL: Make this be `http://localhost:4180/`

26+* Redirect URIs: Make this be `http://localhost:4180/oauth2/callback`.

27+* Attribute Bundle: Make sure that email is selected.

28+

29+Now start the proxy up with the following options:

30+```

31+./oauth2-proxy -provider login.gov \

32+ -client-id=${LOGINGOV_ISSUER} \

33+ -redirect-url=http://localhost:4180/oauth2/callback \

34+ -oidc-issuer-url=https://idp.int.identitysandbox.gov/ \

35+ -cookie-secure=false \

36+ -email-domain=gsa.gov \

37+ -upstream=http://localhost:3000/ \

38+ -cookie-secret=somerandomstring12341234567890AB \

39+ -cookie-domain=localhost \

40+ -skip-provider-button=true \

41+ -pubjwk-url=https://idp.int.identitysandbox.gov/api/openid_connect/certs \

42+ -profile-url=https://idp.int.identitysandbox.gov/api/openid_connect/userinfo \

43+ -jwt-key="${OAUTH2_PROXY_JWT_KEY}"

44+```

45+You can also set all these options with environment variables, for use in cloud/docker environments.

46+One tricky thing that you may encounter is that some cloud environments will pass in environment

47+variables in a docker env-file, which does not allow multiline variables like a PEM file.

48+If you encounter this, then you can create a `jwt_signing_key.pem` file in the top level

49+directory of the repo which contains the key in PEM format and then do your docker build.

50+The docker build process will copy that file into your image which you can then access by

51+setting the `OAUTH2_PROXY_JWT_KEY_FILE=/etc/ssl/private/jwt_signing_key.pem`

52+environment variable, or by setting `--jwt-key-file=/etc/ssl/private/jwt_signing_key.pem` on the commandline.

53+

54+Once it is running, you should be able to go to `http://localhost:4180/` in your browser,

55+get authenticated by the login.gov integration server, and then get proxied on to your

56+application running on `http://localhost:3000/`. In a real deployment, you would secure

57+your application with a firewall or something so that it was only accessible from the

58+proxy, and you would use real hostnames everywhere.

59+

60+#### Skip OIDC discovery

61+

62+Some providers do not support OIDC discovery via their issuer URL, so oauth2-proxy cannot simply grab the authorization,

63+token and jwks URI endpoints from the provider's metadata.

64+

65+In this case, you can set the `--skip-oidc-discovery` option, and supply those required endpoints manually:

66+

67+```

68+ -provider oidc

69+ -client-id oauth2-proxy

70+ -client-secret proxy

71+ -redirect-url http://127.0.0.1:4180/oauth2/callback

72+ -oidc-issuer-url http://127.0.0.1:5556

73+ -skip-oidc-discovery

74+ -login-url http://127.0.0.1:5556/authorize

75+ -redeem-url http://127.0.0.1:5556/token

76+ -oidc-jwks-url http://127.0.0.1:5556/keys

77+ -cookie-secure=false

78+ -email-domain example.com

79+```

docs/versioned_docs/version-7.13.x/configuration/providers/ms_azure_ad.mdnew file+59

@@ -0,0 +1,59 @@

1+---

2+id: azure

3+title: Azure (Deprecated)

4+---

5+

6+:::note

7+This is the legacy and deprecated provider for Azure, use [Microsoft Entra ID](ms_entra_id.md) if possible.

8+:::

9+

10+## Config Options

11+

12+| Flag | Toml Field | Type | Description | Default |

13+| ---------------- | -------------- | ------ | ---------------------------------------------------------------- | ---------- |

14+| `--azure-tenant` | `azure_tenant` | string | go to a tenant-specific or common (tenant-independent) endpoint. | `"common"` |

15+| `--resource` | `resource` | string | The resource that is protected (Azure AD only) | |

16+

17+## Usage

18+

19+1. Add an application: go to [https://portal.azure.com](https://portal.azure.com), choose **Azure Active Directory**, select

20+ **App registrations** and then click on **New registration**.

21+2. Pick a name, check the supported account type(single-tenant, multi-tenant, etc). In the **Redirect URI** section create a new

22+ **Web** platform entry for each app that you want to protect by the oauth2 proxy(e.g.

23+ https://internal.yourcompanycom/oauth2/callback). Click **Register**.

24+3. Next we need to add group read permissions for the app registration, on the **API Permissions** page of the app, click on

25+ **Add a permission**, select **Microsoft Graph**, then select **Application permissions**, then click on **Group** and select

26+ **Group.Read.All**. Hit **Add permissions** and then on **Grant admin consent** (you might need an admin to do this).

27+ <br/>**IMPORTANT**: Even if this permission is listed with **"Admin consent required=No"** the consent might actually

28+ be required, due to AAD policies you won't be able to see. If you get a **"Need admin approval"** during login,

29+ most likely this is what you're missing!

30+4. Next, if you are planning to use v2.0 Azure Auth endpoint, go to the **Manifest** page and set `"accessTokenAcceptedVersion": 2`

31+ in the App registration manifest file.

32+5. On the **Certificates & secrets** page of the app, add a new client secret and note down the value after hitting **Add**.

33+6. Configure the proxy with:

34+- for V1 Azure Auth endpoint (Azure Active Directory Endpoints - https://login.microsoftonline.com/common/oauth2/authorize)

35+

36+```

37+ --provider=azure

38+ --client-id=<application ID from step 3>

39+ --client-secret=<value from step 5>

40+ --azure-tenant={tenant-id}

41+ --oidc-issuer-url=https://sts.windows.net/{tenant-id}/

42+```

43+

44+- for V2 Azure Auth endpoint (Microsoft Identity Platform Endpoints - https://login.microsoftonline.com/common/oauth2/v2.0/authorize)

45+```

46+ --provider=azure

47+ --client-id=<application ID from step 3>

48+ --client-secret=<value from step 5>

49+ --azure-tenant={tenant-id}

50+ --oidc-issuer-url=https://login.microsoftonline.com/{tenant-id}/v2.0

51+```

52+

53+***Notes***:

54+- When using v2.0 Azure Auth endpoint (`https://login.microsoftonline.com/{tenant-id}/v2.0`) as `--oidc_issuer_url`, in conjunction

55+ with `--resource` flag, be sure to append `/.default` at the end of the resource name. See

56+ https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope for more details.

57+- When using the Azure Auth provider with nginx and the cookie session store you may find the cookie is too large and doesn't

58+ get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the

59+ [redis session storage](../sessions.md#redis-storage) should resolve this.

docs/versioned_docs/version-7.13.x/configuration/providers/ms_entra_id.mdnew file+197

@@ -0,0 +1,197 @@

1+---

2+id: ms_entra_id

3+title: Microsoft Entra ID

4+---

5+

6+Provider for Microsoft Entra ID. Fully compliant with OIDC, with support for group overage and multi-tenant apps.

7+

8+## Config Options

9+

10+The provider is OIDC-compliant, so all the OIDC parameters are honored. Additional provider-specific configuration parameters are:

11+

12+| Flag | Toml Field | Type | Description | Default |

13+| --------------------------- | -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

14+| `--entra-id-allowed-tenant` | `entra_id_allowed_tenants` | string \| list | List of allowed tenants. In case of multi-tenant apps, incoming tokens are issued by different issuers and OIDC issuer verification needs to be disabled. When not specified, all tenants are allowed. Redundant for single-tenant apps (regular ID token validation matches the issuer). | |

15+| `--entra-id-federated-token-auth` | `entra_id_federated_token_auth` | boolean | Enable oAuth2 client authentication with federated token projected by Entra Workload Identity plugin, instead of client secret. | false |

16+

17+## Configure App registration

18+To begin, create an App registration, set a redirect URI, and generate a secret. All account types are supported, including single-tenant, multi-tenant, multi-tenant with Microsoft accounts, and Microsoft accounts only.

19+

20+<details>

21+ <summary>See Azure Portal example</summary>

22+ <div class="videoBlock">

23+ <iframe src="https://www.youtube.com/embed/IUNfxhOzr4E"></iframe>

24+ </div>

25+</details>

26+

27+<details>

28+ <summary>See Terraform example</summary>

29+```

30+ resource "azuread_application" "auth" {

31+ display_name = "oauth2-proxy"

32+ sign_in_audience = "AzureADMyOrg" # Others are also supported

33+

34+ web {

35+ redirect_uris = [

36+ "https://podinfo.lakis.tech/oauth2/callback",

37+ ]

38+ }

39+ // We don't specify any required API permissions - we allow user consent only

40+ }

41+

42+ resource "azuread_service_principal" "sp" {

43+ client_id = azuread_application.auth.client_id

44+ app_role_assignment_required = false

45+ }

46+

47+ resource "azuread_service_principal_password" "pass" {

48+ service_principal_id = azuread_service_principal.sp.id

49+ }

50+

51+```

52+</details>

53+

54+### Configure groups

55+If you want to make use of groups, you can configure *groups claim* to be present in ID Tokens issued by the App registration.

56+<details>

57+ <summary>See Azure Portal example</summary>

58+ <div class="videoBlock">

59+ <div class="videoBlock">

60+ <iframe src="https://www.youtube.com/embed/QZmP5MKEJis"></iframe>

61+ </div>

62+ </div>

63+</details>

64+<details>

65+ <summary>See Terraform example</summary>

66+```

67+ resource "azuread_application" "auth" {

68+ display_name = "oauth2-proxy"

69+ sign_in_audience = "AzureADMyOrg"

70+

71+ group_membership_claims = [

72+ "SecurityGroup"

73+ ]

74+

75+ web {

76+ redirect_uris = [

77+ "https://podinfo.lakis.tech/oauth2/callback",

78+ ]

79+ }

80+ }

81+

82+ resource "azuread_service_principal" "sp" {

83+ client_id = azuread_application.auth.client_id

84+ app_role_assignment_required = false

85+ }

86+

87+ resource "azuread_service_principal_password" "pass" {

88+ service_principal_id = azuread_service_principal.sp.id

89+ }

90+

91+```

92+</details>

93+

94+### Scopes and claims

95+For single-tenant and multi-tenant apps without groups, the only required scope is `openid` (See: [Scopes and permissions](https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc#the-openid-scope)).

96+

97+To make use of groups - for example use `allowed_groups` setting or authorize based on groups inside your service - you need to enable *groups claims* in the App Registration. When enabled, list of groups is present in the issued ID token. No additional scopes are required besides `openid`. This works up to 200 groups.

98+

99+When user has more than 200 group memberships, OAuth2-Proxy attempts to retrieve the complete list from Microsoft Graph API's [`transitiveMemberOf`](https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof). Endpoint requires `User.Read` scope (delegated permission). This permission can be by default consented by user during first login. Set scope to `openid User.Read` to request user consent. Without proper scope, user with 200+ groups will authenticate with 0 groups. See: [group overages](https://learn.microsoft.com/en-us/security/zero-trust/develop/configure-tokens-group-claims-app-roles#group-overages).

100+

101+Alternatively to user consent, both `openid` and `User.Read` permissions can be consented by admistrator. Then, user is not asked for consent on the first login, and group overage works with `openid` scope only. Admin consent can also be required for some tenants. It can be granted with [azuread_service_principal_delegated_permission_grant](https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/service_principal_delegated_permission_grant) terraform resource.

102+

103+For personal microsoft accounts, required scope is `openid profile email`.

104+

105+See: [Overview of permissions and consent in the Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview).

106+

107+### Multi-tenant apps

108+To authenticate apps from multiple tenants (including personal Microsoft accounts), set the common OIDC issuer url and disable verification:

109+```toml

110+oidc_issuer_url=https://login.microsoftonline.com/common/v2.0

111+insecure_oidc_skip_issuer_verification=true

112+```

113+`insecure_oidc_skip_issuer_verification` setting is required to disable following checks:

114+* Startup check for matching issuer URL returned from [discovery document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) with `oidc_issuer_url` setting. Required, as document's `issuer` field doesn't equal to `https://login.microsoftonline.com/common/v2.0`. See [OIDC Discovery 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation).

115+* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by different tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

116+

117+To provide additional security, Entra ID provider performs check on the ID token's `issuer` claim to match the `https://login.microsoftonline.com/{tenant-id}/v2.0` template.

118+

119+### Workload Identity

120+Provider supports authentication with federated token, without need of using client secret. Following conditions have to be met:

121+

122+* Cluster has public OIDC provider URL. For major cloud providers, it can be enabled with a single flag, for example for [Azure Kubernetes Service deployed with Terraform](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/kubernetes_cluster), it's `oidc_issuer_enabled`.

123+* Workload Identity admission webhook is deployed on the cluster. For AKS, it can be enabled with a flag (`workload_identity_enabled` in Terraform resource), for clusters outside of Azure, it can be installed from [helm chart](https://github.com/Azure/azure-workload-identity).

124+* Appropriate federated credential is added to application registration.

125+<details>

126+ <summary>See federated credential terraform example</summary>

127+```

128+ resource "azuread_application_federated_identity_credential" "fedcred" {

129+ application_id = azuread_application.application.id # ID of your application

130+ display_name = "federation-cred"

131+ description = "Workload identity for oauth2-proxy"

132+ audiences = ["api://AzureADTokenExchange"] # Fixed value

133+ issuer = "https://cluster-oidc-issuer-url..."

134+ subject = "system:serviceaccount:oauth2-proxy-namespace-name:oauth2-proxy-sa-name" # set proper NS and SA name

135+ }

136+```

137+</details>

138+

139+* Kubernetes service account associated with oauth2-proxy deployment, is annotated with `azure.workload.identity/client-id: <app-registration-client-id>`

140+* oauth2-proxy pod is labeled with `azure.workload.identity/use: "true"`

141+* oauth2-proxy is configured with `entra_id_federated_token_auth` set to `true`.

142+

143+`client_secret` setting can be omitted when using federated token authentication.

144+

145+See: [Azure Workload Identity documentation](https://azure.github.io/azure-workload-identity/docs/).

146+

147+### Example configurations

148+Single-tenant app without groups (*groups claim* not enabled). Consider using generic OIDC provider:

149+```toml

150+provider="entra-id"

151+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

152+client_id="<client-id>"

153+client_secret="<client-secret>"

154+scope="openid"

155+```

156+

157+Single-tenant app with up to 200 groups (*groups claim* enabled). Consider using generic OIDC provider:

158+```toml

159+provider="entra-id"

160+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

161+client_id="<client-id>"

162+client_secret="<client-secret>"

163+scope="openid"

164+allowed_groups=["ac51800c-2679-4ecb-8130-636380a3b491"]

165+```

166+

167+Single-tenant app with more than 200 groups:

168+```toml

169+provider="entra-id"

170+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

171+client_id="<client-id>"

172+client_secret="<client-secret>"

173+scope="openid User.Read"

174+allowed_groups=["968b4844-d5e7-4e18-a834-59927959369f"]

175+```

176+

177+Single-tenant app with more than 200 groups and workload identity enabled:

178+```toml

179+provider="entra-id"

180+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

181+client_id="<client-id>"

182+scope="openid User.Read"

183+allowed_groups=["968b4844-d5e7-4e18-a834-59927959369f"]

184+entra_id_federated_token_auth=true

185+```

186+

187+Multi-tenant app with Microsoft personal accounts & one Entra tenant allowed, with group overage considered:

188+```toml

189+provider="entra-id"

190+oidc_issuer_url="https://login.microsoftonline.com/common/v2.0"

191+client_id="<client-id>"

192+client_secret="<client-secret>"

193+insecure_oidc_skip_issuer_verification=true

194+scope="openid profile email User.Read"

195+entra_id_allowed_tenants=["9188040d-6c67-4c5b-b112-36a304b66dad","<my-tenant-id>"] # Allow only <my-tenant-id> and Personal MS Accounts tenant

196+email_domains="*"

197+```

docs/versioned_docs/version-7.13.x/configuration/providers/nextcloud.mdnew file+28

@@ -0,0 +1,28 @@

1+---

2+id: nextcloud

3+title: NextCloud

4+---

5+

6+The Nextcloud provider allows you to authenticate against users in your

7+Nextcloud instance.

8+

9+When you are using the Nextcloud provider, you must specify the urls via

10+configuration, environment variable, or command line argument. Depending

11+on whether your Nextcloud instance is using pretty urls your urls may be of the

12+form `/index.php/apps/oauth2/*` or `/apps/oauth2/*`.

13+

14+Refer to the [OAuth2

15+documentation](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/oauth2.html)

16+to set up the client id and client secret. Your "Redirection URI" will be

17+`https://internalapp.yourcompany.com/oauth2/callback`.

18+

19+```

20+ -provider nextcloud

21+ -client-id <from nextcloud admin>

22+ -client-secret <from nextcloud admin>

23+ -login-url="<your nextcloud url>/index.php/apps/oauth2/authorize"

24+ -redeem-url="<your nextcloud url>/index.php/apps/oauth2/api/v1/token"

25+ -validate-url="<your nextcloud url>/ocs/v2.php/cloud/user?format=json"

26+```

27+

28+Note: in *all* cases the validate-url will *not* have the `index.php`.

docs/versioned_docs/version-7.13.x/configuration/providers/openid_connect.mdnew file+146

@@ -0,0 +1,146 @@

1+---

2+id: openid_connect

3+title: OpenID Connect

4+---

5+

6+OpenID Connect is a spec for OAUTH 2.0 + identity that is implemented by many major providers and several open source projects.

7+

8+This provider was originally built against CoreOS Dex, and we will use it as an example.

9+The OpenID Connect Provider (OIDC) can also be used to connect to other Identity Providers such as Okta, an example can be found below.

10+

11+#### Dex

12+

13+To configure the OIDC provider for Dex, perform the following steps:

14+

15+1. Download Dex:

16+

17+ ```

18+ go get github.com/dexidp/dex

19+ ```

20+

21+ See the [getting started guide](https://dexidp.io/docs/getting-started/) for more details.

22+

23+2. Setup oauth2-proxy with the correct provider and using the default ports and callbacks. Add a configuration block to

24+ the `staticClients` section of `examples/config-dev.yaml`:

25+

26+ ```

27+ - id: oauth2-proxy

28+ redirectURIs:

29+ - 'http://127.0.0.1:4180/oauth2/callback'

30+ name: 'oauth2-proxy'

31+ secret: proxy

32+ ```

33+

34+3. Launch Dex: from `$GOPATH/github.com/dexidp/dex`, run:

35+

36+ ```

37+ bin/dex serve examples/config-dev.yaml

38+ ```

39+

40+4. In a second terminal, run the oauth2-proxy with the following args:

41+

42+ ```shell

43+ --provider oidc

44+ --provider-display-name "My OIDC Provider"

45+ --client-id oauth2-proxy

46+ --client-secret proxy

47+ --redirect-url http://127.0.0.1:4180/oauth2/callback

48+ --oidc-issuer-url http://127.0.0.1:5556/dex

49+ --cookie-secure=false

50+ --cookie-secret=secret

51+ --email-domain kilgore.trout

52+ ```

53+

54+ To serve the current working directory as a website under the `/static` endpoint, add:

55+

56+ ```shell

57+ --upstream file://$PWD/#/static/

58+ ```

59+

60+5. Test the setup by visiting http://127.0.0.1:4180 or http://127.0.0.1:4180/static .

61+

62+See also [our local testing environment](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/local-environment) for a self-contained example using Docker and etcd as storage for Dex.

63+

64+#### Okta

65+

66+To configure the OIDC provider for Okta, perform the following steps:

67+

68+1. Log in to Okta using an administrative account. It is suggested you try this in preview first, `example.oktapreview.com`

69+2. (OPTIONAL) If you want to configure authorization scopes and claims to be passed on to multiple applications,

70+ you may wish to configure an authorization server for each application. Otherwise, the provided `default` will work.

71+ * Navigate to **Security** then select **API**

72+ * Click **Add Authorization Server**, if this option is not available you may require an additional license for a custom

73+ authorization server.

74+ * Fill out the **Name** with something to describe the application you are protecting. e.g. 'Example App'.

75+ * For **Audience**, pick the URL of the application you wish to protect: https://example.corp.com

76+ * Fill out a **Description**

77+ * Add any **Access Policies** you wish to configure to limit application access.

78+ * The default settings will work for other options.

79+ [See Okta documentation for more information on Authorization Servers](https://developer.okta.com/docs/guides/customize-authz-server/overview/)

80+3. Navigate to **Applications** then select **Add Application**.

81+ * Select **Web** for the **Platform** setting.

82+ * Select **OpenID Connect** and click **Create**

83+ * Pick an **Application Name** such as `Example App`.

84+ * Set the **Login redirect URI** to `https://example.corp.com`.

85+ * Under **General** set the **Allowed grant types** to `Authorization Code` and `Refresh Token`.

86+ * Leave the rest as default, taking note of the `Client ID` and `Client Secret`.

87+ * Under **Assignments** select the users or groups you wish to access your application.

88+4. Create a configuration file like the following:

89+

90+ ```

91+ provider = "oidc"

92+ redirect_url = "https://example.corp.com/oauth2/callback"

93+ oidc_issuer_url = "https://corp.okta.com/oauth2/abCd1234"

94+ upstreams = [

95+ "https://example.corp.com"

96+ ]

97+ email_domains = [

98+ "corp.com"

99+ ]

100+ client_id = "XXXXX"

101+ client_secret = "YYYYY"

102+ pass_access_token = true

103+ cookie_secret = "ZZZZZ"

104+ skip_provider_button = true

105+ ```

106+

107+The `oidc_issuer_url` is based on URL from your **Authorization Server**'s **Issuer** field in step 2, or simply

108+https://corp.okta.com. The `client_id` and `client_secret` are configured in the application settings.

109+Generate a unique `cookie_secret` to encrypt the cookie.

110+

111+Then you can start the oauth2-proxy with `./oauth2-proxy --config /etc/example.cfg`

112+

113+#### Okta - localhost

114+

115+1. Signup for developer account: https://developer.okta.com/signup/

116+2. Create New `Web` Application: https://$\{your-okta-domain\}/dev/console/apps/new

117+3. Example Application Settings for localhost:

118+ * **Name:** My Web App

119+ * **Base URIs:** http://localhost:4180/

120+ * **Login redirect URIs:** http://localhost:4180/oauth2/callback

121+ * **Logout redirect URIs:** http://localhost:4180/

122+ * **Group assignments:** `Everyone`

123+ * **Grant type allowed:** `Authorization Code` and `Refresh Token`

124+4. Make note of the `Client ID` and `Client secret`, they are needed in a future step

125+5. Make note of the **default** Authorization Server Issuer URI from: https://$\{your-okta-domain\}/admin/oauth2/as

126+6. Example config file `/etc/localhost.cfg`

127+ ```shell

128+ provider = "oidc"

129+ redirect_url = "http://localhost:4180/oauth2/callback"

130+ oidc_issuer_url = "https://$\{your-okta-domain\}/oauth2/default"

131+ upstreams = [

132+ "http://0.0.0.0:8080"

133+ ]

134+ email_domains = [

135+ "*"

136+ ]

137+ client_id = "XXX"

138+ client_secret = "YYY"

139+ pass_access_token = true

140+ cookie_secret = "ZZZ"

141+ cookie_secure = false

142+ skip_provider_button = true

143+ # Note: use the following for testing within a container

144+ # http_address = "0.0.0.0:4180"

145+ ```

146+7. Then you can start the oauth2-proxy with `./oauth2-proxy --config /etc/localhost.cfg`

docs/versioned_docs/version-7.13.x/configuration/providers/sourcehut.mdnew file+25

@@ -0,0 +1,25 @@

1+---

2+id: sourcehut

3+title: SourceHut

4+---

5+

6+1. Create a new OAuth client: https://meta.sr.ht/oauth2

7+2. Under `Redirection URI` enter the correct URL, i.e.

8+ `https://internal.yourcompany.com/oauth2/callback`

9+

10+To use the provider, start with `--provider=sourcehut`.

11+

12+If you are hosting your own SourceHut instance, make sure you set the following

13+to the appropriate URLs:

14+

15+```shell

16+ --login-url="https://<meta.your.instance>/oauth2/authorize"

17+ --redeem-url="https://<meta.your.instance>/oauth2/access-token"

18+ --profile-url="https://<meta.your.instance>/query"

19+ --validate-url="https://<meta.your.instance>/profile"

20+```

21+

22+The default configuration allows everyone with an account to authenticate.

23+Restricting access is currently only supported by

24+[email](index.md#email-authentication).

25+

docs/versioned_docs/version-7.13.x/configuration/sessions.mdnew file+99

@@ -0,0 +1,99 @@

1+---

2+id: session_storage

3+title: Session Storage

4+---

5+

6+Sessions allow a user's authentication to be tracked between multiple HTTP

7+requests to a service.

8+

9+The OAuth2 Proxy uses a Cookie to track user sessions and will store the session

10+data in one of the available session storage backends.

11+

12+At present the available backends are (as passed to `--session-store-type`):

13+- [cookie](#cookie-storage) (default)

14+- [redis](#redis-storage)

15+

16+### Cookie Storage

17+

18+The Cookie storage backend is the default backend implementation and has

19+been used in the OAuth2 Proxy historically.

20+

21+With the Cookie storage backend, all session information is stored in client

22+side cookies and transferred with each and every request.

23+

24+The following should be known when using this implementation:

25+- Since all state is stored client side, this storage backend means that the OAuth2 Proxy is completely stateless

26+- Cookies are signed server side to prevent modification client-side

27+- It is mandatory to set a `cookie-secret` which will ensure data is encrypted within the cookie data.

28+- Since multiple requests can be made concurrently to the OAuth2 Proxy, this session implementation

29+cannot lock sessions and while updating and refreshing sessions, there can be conflicts which force

30+users to re-authenticate

31+

32+

33+### Redis Storage

34+

35+The Redis Storage backend stores encrypted sessions in redis. Instead of sending all the information

36+back the client for storage, as in the [Cookie storage](#cookie-storage), a ticket is sent back

37+to the user as the cookie value instead.

38+

39+A ticket is composed as the following:

40+

41+`{CookieName}-{ticketID}.{secret}`

42+

43+Where:

44+

45+- The `CookieName` is the OAuth2 cookie name (_oauth2_proxy by default)

46+- The `ticketID` is a 128-bit random number, hex-encoded

47+- The `secret` is a 128-bit random number, base64url encoded (no padding). The secret is unique for every session.

48+- The pair of `{CookieName}-{ticketID}` comprises a ticket handle, and thus, the redis key

49+to which the session is stored. The encoded session is encrypted with the secret and stored

50+in redis via the `SETEX` command.

51+

52+Encrypting every session uniquely protects the refresh/access/id tokens stored in the session from

53+disclosure. Additionally, the browser only has to send a short Cookie with every request and not the whole JWT,

54+which can get quite big.

55+

56+Two settings are used to configure the OAuth2 Proxy cookie lifetime:

57+

58+ --cookie-refresh duration refresh the cookie after this duration; 0 to disable

59+ --cookie-expire duration expire timeframe for cookie 168h0m0s

60+

61+The "cookie-expire" value should be equal to the lifetime of the Refresh-Token that is issued by the OAuth2 authorization server.

62+If it expires earlier and is deleted by the browser, OAuth2 Proxy cannot find the stored Refresh-Tokens in Redis and thus cannot start

63+the refresh flow to get a new Access-Token. If it is longer, it might be that the old Refresh-Token will be found in Redis but has already

64+expired.

65+

66+The "cookie-refresh" value controls when OAuth2 Proxy tries to refresh an Access-Token. If it is set to "0", the

67+Access-Token will never be refreshed, even if it is already expired and a valid Refresh-Token is available. If set, OAuth2-Proxy will

68+refresh the Access-Token after this many seconds whether it is still valid or not. According to the official OAuth2.0 specification

69+Access-Tokens are not required to follow a specific format. Therefore OAuth2-Proxy cannot check for any expiry date without an

70+introspection endpoint. If an Access-Token expires and you have not set a corresponding "cookie-refresh" value, you will likely

71+encounter expiry issues.

72+

73+Caveat: It can happen that the Access-Token is valid for e.g. "1m" and a request happens after exactly "59s".

74+It would pass OAuth2 Proxy and be forwarded to the backend but is just expired when the backend tries to validate

75+it. This is especially relevant if the backend uses the JWT to make requests to other backends.

76+For this reason, it's advised to set the cookie-refresh a couple of seconds less than the Access-Token lifespan.

77+

78+Recommended settings:

79+

80+* cookie_refresh := Access-Token lifespan - 1m

81+* cookie_expire := Refresh-Token lifespan (i.e. Keycloak client_session_idle)

82+

83+#### Usage

84+

85+When using the redis store, specify `--session-store-type=redis` as well as the Redis connection URL, via

86+`--redis-connection-url=redis://host[:port][/db-number]`.

87+

88+You may also configure the store for Redis Sentinel. In this case, you will want to use the

89+`--redis-use-sentinel=true` flag, as well as configure the flags `--redis-sentinel-master-name`

90+and `--redis-sentinel-connection-urls` appropriately.

91+

92+Redis Cluster is available to be the backend store as well. To leverage it, you will need to set the

93+`--redis-use-cluster=true` flag, and configure the flags `--redis-cluster-connection-urls` appropriately.

94+

95+Note that flags `--redis-use-sentinel=true` and `--redis-use-cluster=true` are mutually exclusive.

96+

97+Note, if Redis timeout option is set to non-zero, the `--redis-connection-idle-timeout`

98+must be less than [Redis timeout option](https://redis.io/docs/reference/clients/#client-timeouts). For example: if either redis.conf includes

99+`timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14`

docs/versioned_docs/version-7.13.x/configuration/systemd_socket.mdnew file+43

@@ -0,0 +1,43 @@

1+---

2+id: systemd_socket

3+title: Systemd Socket Activation

4+---

5+

6+Pass an existing listener created by systemd.socket to oauth2-proxy.

7+

8+To do this create a socket:

9+

10+oauth2-proxy.socket

11+```

12+[Socket]

13+ListenStream=%t/oauth2.sock

14+SocketGroup=www-data

15+SocketMode=0660

16+```

17+

18+Now it's possible to call this socket from e.g. nginx:

19+```

20+server {

21+ location /oauth2/ {

22+ proxy_pass http://unix:/run/oauth2-proxy/oauth2.sock;

23+}

24+```

25+

26+The oauth2-proxy should have `--http-address=fd:3` as a parameter.

27+Here fd is case insensitive and means file descriptor. The number 3 refers to the first non-stdin/stdout/stderr file descriptor,

28+systemd-socket-activate (which is what systemd.socket uses), listens to what it is told and passes

29+the listener it created onto the process, starting with file descriptor 3.

30+

31+```

32+./oauth2-proxy \

33+ --http-address="fd:3" \

34+ --email-domain="yourcompany.com" \

35+ --upstream=http://127.0.0.1:8080/ \

36+ --cookie-secret=... \

37+ --cookie-secure=true \

38+ --provider=... \

39+ --client-id=... \

40+ --client-secret=...

41+```

42+

43+Currently TLS is not supported (but it's doable).

docs/versioned_docs/version-7.13.x/configuration/tls.mdnew file+85

@@ -0,0 +1,85 @@

1+---

2+id: tls

3+title: TLS Configuration

4+---

5+

6+There are two recommended configurations:

7+- [At OAuth2 Proxy](#terminate-tls-at-oauth2-proxy)

8+- [At Reverse Proxy](#terminate-tls-at-reverse-proxy-eg-nginx)

9+

10+### Terminate TLS at OAuth2 Proxy

11+

12+1. Configure SSL Termination with OAuth2 Proxy by providing a `--tls-cert-file=/path/to/cert.pem` and `--tls-key-file=/path/to/cert.key`.

13+

14+ The command line to run `oauth2-proxy` in this configuration would look like this:

15+

16+ ```bash

17+ ./oauth2-proxy \

18+ --email-domain="yourcompany.com" \

19+ --upstream=http://127.0.0.1:8080/ \

20+ --tls-cert-file=/path/to/cert.pem \

21+ --tls-key-file=/path/to/cert.key \

22+ --cookie-secret=... \

23+ --cookie-secure=true \

24+ --provider=... \

25+ --client-id=... \

26+ --client-secret=...

27+ ```

28+

29+2. With this configuration approach the customization of the TLS settings is limited.

30+

31+ The minimal acceptable TLS version can be set with `--tls-min-version=TLS1.3`.

32+ The defaults set `TLS1.2` as the minimal version.

33+ Regardless of the minimum version configured, `TLS1.3` is currently always used as the maximal version.

34+

35+ TLS server side cipher suites can be specified with `--tls-cipher-suite=TLS_RSA_WITH_RC4_128_SHA`.

36+ If not specified, the defaults from [`crypto/tls`](https://pkg.go.dev/crypto/tls#CipherSuites) of the currently used `go` version for building `oauth2-proxy` will be used.

37+ A complete list of valid TLS cipher suite names can be found in [`crypto/tls`](https://pkg.go.dev/crypto/tls#pkg-constants).

38+

39+### Terminate TLS at Reverse Proxy, e.g. Nginx

40+

41+1. Configure SSL Termination with [Nginx](http://nginx.org/) (example config below), Amazon ELB, Google Cloud Platform Load Balancing, or ...

42+

43+ Because `oauth2-proxy` listens on `127.0.0.1:4180` by default, to listen on all interfaces (needed when using an

44+ external load balancer like Amazon ELB or Google Platform Load Balancing) use `--http-address="0.0.0.0:4180"` or

45+ `--http-address="http://:4180"`.

46+

47+ Nginx will listen on port `443` and handle SSL connections while proxying to `oauth2-proxy` on port `4180`.

48+ `oauth2-proxy` will then authenticate requests for an upstream application. The external endpoint for this example

49+ would be `https://internal.yourcompany.com/`.

50+

51+ An example Nginx config follows. Note the use of `Strict-Transport-Security` header to pin requests to SSL

52+ via [HSTS](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security):

53+

54+ ```

55+ server {

56+ listen 443 default ssl;

57+ server_name internal.yourcompany.com;

58+ ssl_certificate /path/to/cert.pem;

59+ ssl_certificate_key /path/to/cert.key;

60+ add_header Strict-Transport-Security max-age=2592000;

61+

62+ location / {

63+ proxy_pass http://127.0.0.1:4180;

64+ proxy_set_header Host $host;

65+ proxy_set_header X-Real-IP $remote_addr;

66+ proxy_connect_timeout 1;

67+ proxy_send_timeout 30;

68+ proxy_read_timeout 30;

69+ }

70+ }

71+ ```

72+

73+2. The command line to run `oauth2-proxy` in this configuration would look like this:

74+

75+ ```bash

76+ ./oauth2-proxy \

77+ --email-domain="yourcompany.com" \

78+ --upstream=http://127.0.0.1:8080/ \

79+ --cookie-secret=... \

80+ --cookie-secure=true \

81+ --provider=... \

82+ --reverse-proxy=true \

83+ --client-id=... \

84+ --client-secret=...

85+ ```

docs/versioned_docs/version-7.13.x/features/endpoints.mdnew file+47

@@ -0,0 +1,47 @@

1+---

2+id: endpoints

3+title: Endpoints

4+---

5+

6+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.

7+

8+- /robots.txt - returns a 200 OK response that disallows all User-agents from all paths; see [robotstxt.org](http://www.robotstxt.org/) for more info

9+- /ping - returns a 200 OK response, which is intended for use with health checks

10+- /ready - returns a 200 OK response if all the underlying connections (e.g., Redis store) are connected

11+- /metrics - Metrics endpoint for Prometheus to scrape, serve on the address specified by `--metrics-address`, disabled by default

12+- /oauth2/sign_in - the login page, which also doubles as a sign-out page (it clears cookies)

13+- /oauth2/sign_out - this URL is used to clear the session cookie

14+- /oauth2/start - a URL that will redirect to start the OAuth cycle

15+- /oauth2/callback - the URL used at the end of the OAuth cycle. The oauth app will be configured with this as the callback url.

16+- /oauth2/userinfo - the URL is used to return user's email from the session in JSON format.

17+- /oauth2/auth - only returns a 202 Accepted response or a 401 Unauthorized response; for use with the [Nginx `auth_request` directive](../configuration/integrations/nginx)

18+- /oauth2/static/\* - stylesheets and other dependencies used in the sign_in and error pages

19+

20+### Sign out

21+

22+To sign the user out, redirect them to `/oauth2/sign_out`. This endpoint only removes oauth2-proxy's own cookies, i.e. the user is still logged in with the authentication provider and may automatically re-login when accessing the application again. You will also need to redirect the user to the authentication provider's sign-out page afterward using the `rd` query parameter, i.e. redirect the user to something like (notice the url-encoding!):

23+

24+```

25+/oauth2/sign_out?rd=https%3A%2F%2Fmy-oidc-provider.example.com%2Fsign_out_page

26+```

27+

28+Alternatively, include the redirect URL in the `X-Auth-Request-Redirect` header:

29+

30+```

31+GET /oauth2/sign_out HTTP/1.1

32+X-Auth-Request-Redirect: https://my-oidc-provider/sign_out_page

33+...

34+```

35+

36+(The "sign_out_page" should be the [`end_session_endpoint`](https://openid.net/specs/openid-connect-session-1_0.html#rfc.section.2.1) from [the metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) if your OIDC provider supports Session Management and Discovery.)

37+

38+BEWARE that the domain you want to redirect to (`my-oidc-provider.example.com` in the example) must be added to the [`--whitelist-domain`](../configuration/overview) configuration option otherwise the redirect will be ignored. Make sure to include the actual domain and port (if needed) and not the URL (e.g "localhost:8081" instead of "http://localhost:8081").

39+

40+### Auth

41+

42+This endpoint returns 202 Accepted response or a 401 Unauthorized response.

43+

44+It can be configured using the following query parameters:

45+- `allowed_groups`: comma separated list of allowed groups

46+- `allowed_email_domains`: comma separated list of allowed email domains

47+- `allowed_emails`: comma separated list of allowed emails

docs/versioned_docs/version-7.13.x/installation.mdnew file+32

@@ -0,0 +1,32 @@

1+---

2+id: installation

3+title: Installation

4+---

5+

6+1. Choose how to deploy:

7+

8+ a. Using a [Prebuilt Binary](https://github.com/oauth2-proxy/oauth2-proxy/releases) (current release is `v7.13.0`)

9+

10+ b. Using Go to install the latest release

11+ ```bash

12+ $ go install github.com/oauth2-proxy/oauth2-proxy/v7@latest

13+ ```

14+ This will install the binary into `$GOPATH/bin`. Make sure you include `$GOPATH` in your `$PATH`. Otherwise your system won't find binaries installed via `go install`

15+

16+ c. Using a [Prebuilt Docker Image](https://quay.io/oauth2-proxy/oauth2-proxy) (AMD64, PPC64LE, S390x, ARMv6, ARMv7, and ARM64 available)

17+

18+ d. Using a [Pre-Release Nightly Docker Image](https://quay.io/oauth2-proxy/oauth2-proxy-nightly) (AMD64, PPC64LE, ARMv6, ARMv7, and ARM64 available)

19+

20+ e. Using the official [Kubernetes manifest](https://github.com/oauth2-proxy/manifests) (Helm)

21+

22+ Prebuilt binaries can be validated by extracting the file and verifying it against the `sha256sum.txt` checksum file provided for each release starting with version `v3.0.0`.

23+

24+ ```

25+ $ sha256sum -c sha256sum.txt

26+ oauth2-proxy-x.y.z.linux-amd64: OK

27+ ```

28+

29+2. [Select a Provider and Register an OAuth Application with a Provider](configuration/providers/index.md)

30+3. [Configure OAuth2 Proxy using config file, command line options, or environment variables](configuration/overview.md)

31+4. [Configure SSL or Deploy behind an SSL endpoint](configuration/tls.md) (example provided for Nginx)

32+5. [Configure OAuth2 Proxy using systemd.socket](configuration/systemd_socket.md) (example provided for Nginx/Systemd)

docs/versioned_docs/version-7.13.x/welcome.mdnew file+23

@@ -0,0 +1,23 @@

1+---

2+id: welcome

3+title: Welcome

4+hide_table_of_contents: true

5+slug: /

6+---

7+

8+

9+

10+A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others)

11+to validate accounts by email, domain or group.

12+

13+:::note

14+This repository was forked from [bitly/OAuth2_Proxy](https://github.com/bitly/oauth2_proxy) on 27/11/2018.

15+Versions v3.0.0 and up are from this fork and will have diverged from any changes in the original fork.

16+A list of changes can be seen in the [CHANGELOG](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/CHANGELOG.md).

17+:::

18+

19+

20+

21+## Architecture

22+

23+

docs/versioned_docs/version-7.14.x/behaviour.mdnew file+26

@@ -0,0 +1,26 @@

1+---

2+id: behaviour

3+title: Behaviour

4+---

5+

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

10+

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.14.x/community/contribution.mdnew file+91

@@ -0,0 +1,91 @@

1+---

2+id: contribution

3+title: Contribution Guide

4+---

5+

6+We track bugs and issues using Github.

7+

8+If you find a bug, please open an Issue. When opening an Issue or Pull Request please follow the preconfigured template and take special note of the checkboxes.

9+

10+If you want to fix a bug, add a new feature or extend existing functionality, please create a fork, create a feature branch and open a PR back to this repo.

11+Please mention open bug issue number(s) within your PR if applicable.

12+

13+We suggest using [Visual Studio Code](https://code.visualstudio.com/docs/languages/go) with the official [Go for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=golang.go) extension.

14+

15+

16+# Go version

17+

18+See the `go.mod` file in the root of this repository for the version of Go used by this project.

19+You can follow [the installation guide for Go](https://go.dev/doc/install),

20+and you can find this specific Go version on [the Go downloads page](https://go.dev/dl/).

21+

22+# Preparing your fork

23+Clone your fork, create a feature branch and update the depedencies to get started.

24+```bash

25+git clone git@github.com:<YOUR_FORK>/oauth2-proxy

26+cd oauth2-proxy

27+git branch feature/<BRANCH_NAME>

28+git push --set-upstream origin feature/<BRANCH_NAME>

29+go mod download

30+```

31+

32+

33+# Testing / Debugging

34+For starting oauth2-proxy locally open the debugging tab and create the `launch.json` and select `Go: Launch Package`.

35+

36+

37+```json

38+{

39+ "version": "0.2.0",

40+ "configurations": [

41+ {

42+ "name": "Launch OAuth2 Proxy with Dex",

43+ "type": "go",

44+ "request": "launch",

45+ "mode": "auto",

46+ "program": "${workspaceFolder}",

47+ "args": [

48+ "--config",

49+ // The following configuration contains settings for a locally deployed

50+ // upstream and dex as an idetity provider

51+ "contrib/local-environment/oauth2-proxy.cfg"

52+ ]

53+ },

54+ {

55+ "name": "Launch OAuth2 Proxy with Keycloak",

56+ "type": "go",

57+ "request": "launch",

58+ "mode": "auto",

59+ "program": "${workspaceFolder}",

60+ "args": [

61+ "--config",

62+ // The following configuration contains settings for a locally deployed

63+ // upstream and keycloak as an idetity provider

64+ "contrib/local-environment/oauth2-proxy-keycloak.cfg"

65+ ]

66+ }

67+ ]

68+}

69+```

70+

71+Before you can start your local version of oauth2-proxy, you will have to use the provided docker compose files to start a local upstream service and identity provider. We suggest using [httpbin](https://hub.docker.com/r/kennethreitz/httpbin) as your upstream for testing as it allows for request and response introspection of all things HTTP.

72+

73+Inside the `contrib/local-environment` directory you can use the `Makefile` for

74+starting different example setups:

75+

76+- Dex as your IdP: `make up` or `make down`

77+- Dex as your IdP using the alpha-config: `make alpha-config-up`

78+- Keycloak as your IdP: `make keycloak-up`

79+- Dex as your IdP & nginx reverse proxy: `make nginx-up`

80+- and many more...

81+

82+Check out the `Makefile` to see what is available.

83+

84+The username and password for all setups is usually `admin@example.com` and `password`.

85+

86+The docker compose setups expose the services with a dynamic reverse DNS resolver: localtest.me

87+

88+- OAuth2 Proxy: http://oauth2-proxy.localtest.me:4180

89+- Upstream: http://httpbin.localtest.me:8080

90+- Dex: http://dex.localtest.me:5556

91+

docs/versioned_docs/version-7.14.x/community/security.mdnew file+49

@@ -0,0 +1,49 @@

1+---

2+id: security

3+title: Security

4+---

5+

6+:::note

7+OAuth2 Proxy is a community project.

8+Maintainers do not work on this project full time, and as such,

9+while we endeavour to respond to disclosures as quickly as possible,

10+this may take longer than in projects with corporate sponsorship.

11+:::

12+

13+## Security Disclosures

14+

15+:::important

16+If you believe you have found a vulnerability within OAuth2 Proxy or any of its

17+dependencies, please do NOT open an issue or PR on GitHub, please do NOT post

18+any details publicly.

19+:::

20+

21+Security disclosures MUST be done in private.

22+If you have found an issue that you would like to bring to the attention of the

23+maintenance team for OAuth2 Proxy, please compose an email and send it to the

24+list of maintainers in our [MAINTAINERS.md](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/MAINTAINERS.md) file.

25+

26+Please include as much detail as possible.

27+Ideally, your disclosure should include:

28+- A reproducible case that can be used to demonstrate the exploit

29+- How you discovered this vulnerability

30+- A potential fix for the issue (if you have thought of one)

31+- Versions affected (if not present in master)

32+- Your GitHub ID

33+

34+### How will we respond to disclosures?

35+

36+We use [GitHub Security Advisories](https://docs.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories)

37+to privately discuss fixes for disclosed vulnerabilities.

38+If you include a GitHub ID with your disclosure we will add you as a collaborator

39+for the advisory so that you can join the discussion and validate any fixes

40+we may propose.

41+

42+For minor issues and previously disclosed vulnerabilities (typically for

43+dependencies), we may use regular PRs for fixes and forego the security advisory.

44+

45+Once a fix has been agreed upon, we will merge the fix and create a new release.

46+If we have multiple security issues in flight simultaneously, we may delay

47+merging fixes until all patches are ready.

48+We may also backport the fix to previous releases,

49+but this will be at the discretion of the maintainers.

docs/versioned_docs/version-7.14.x/configuration/alpha_config.mdnew file+637

@@ -0,0 +1,637 @@

1+---

2+id: alpha-config

3+title: Alpha Configuration

4+---

5+

6+:::warning

7+This page contains documentation for alpha features.

8+We reserve the right to make breaking changes to the features detailed within this page with no notice.

9+

10+Options described in this page may be changed, removed, renamed or moved without prior warning.

11+Please beware of this before you use alpha configuration options.

12+:::

13+

14+This page details a set of **alpha** configuration options in a new format.

15+Going forward we are intending to add structured configuration in YAML format to

16+replace the existing TOML based configuration file and flags.

17+

18+Below is a reference for the structure of the configuration, with

19+[AlphaOptions](#alphaoptions) as the root of the configuration.

20+

21+When using alpha configuration, your config file will look something like below:

22+

23+```yaml

24+upstreams:

25+ - id: ...

26+ ...: ...

27+providers:

28+ - id: ...

29+ ...: ...

30+cookie:

31+ secret: ...

32+ ...: ...

33+injectRequestHeaders:

34+ - secretSource:

35+ ...: ...

36+injectResponseHeaders:

37+ - claimSource:

38+ ...: ...

39+```

40+

41+Please browse the [reference](#configuration-reference) below for the structure

42+of the new configuration format.

43+

44+# Migration Guide

45+

46+This section details breaking changes and migration steps for moving to the new

47+alpha configuration format.

48+

49+## Migrating header injections in v7.14.0

50+

51+From v7.14.0 onward, header injection sources must be explicitly nested. If you

52+previously relied on squashed fields, update to the new structure before

53+upgrading:

54+

55+```yaml

56+# before v7.14.0

57+injectRequestHeaders:

58+- name: X-Forwarded-User

59+ values:

60+ - claim: user

61+- name: X-Custom-Secret-header

62+ values:

63+ - value: my-super-secret

64+

65+# v7.14.0 and later

66+injectRequestHeaders:

67+- name: X-Forwarded-User

68+ values:

69+ - claimSource:

70+ claim: user

71+- name: X-Custom-Secret-header

72+ values:

73+ - secretSource:

74+ value: my-super-secret

75+```

76+

77+## Using Alpha Configuration

78+

79+To use the new **alpha** configuration, generate a YAML file based on the format

80+described in the [reference](#configuration-reference) below.

81+

82+Provide the path to this file using the `--alpha-config` flag.

83+

84+:::note

85+When using the `--alpha-config` flag, some options are no longer available.

86+See [removed options](#removed-options) below for more information.

87+:::

88+

89+### Converting configuration to the new structure

90+

91+Before adding the new `--alpha-config` option, start OAuth2 Proxy using the

92+`convert-config-to-alpha` flag to convert existing configuration to the new format.

93+

94+```bash

95+oauth2-proxy --convert-config-to-alpha --config ./path/to/existing/config.cfg

96+```

97+

98+This will convert any options supported by the new format to YAML and print the

99+new configuration to `STDOUT`.

100+

101+Copy this to a new file, remove any options from your existing configuration

102+noted in [removed options](#removed-options) and then start OAuth2 Proxy using

103+the new config.

104+

105+```bash

106+oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

107+```

108+

109+### How to use environment variables

110+

111+The alpha package supports the use of environment variables in place of yaml values, allowing sensitive data to be pulled from somewhere other than the yaml file.

112+When using environment variables, your yaml will look like this:

113+

114+```yaml

115+ providers:

116+ - provider: azure

117+ clientSecret: ${CLIENT_SECRET}

118+ ...

119+```

120+Where CLIENT_SECRET is an environment variable.

121+More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

122+

123+### How to inject custom headers

124+

125+Configure `injectRequestHeaders` and `injectResponseHeaders` in alpha config YAML.

126+

127+```yaml

128+injectRequestHeaders:

129+ - name: "X-User-Email"

130+ values:

131+ - claimSource:

132+ claim: "email" # extract the email claim contents from the id token

133+ - name: "X-Static-Secret"

134+ values:

135+ # secrets need to be encoded with base64 when directly in the yaml config but will be send decoded

136+ - secretSource:

137+ value: "c3VwZXItc2VjcmV0"

138+ - name: "X-Static-File-Secret"

139+ - secretSource:

140+ fromFile: "/path/to/my/secret"

141+ - name: "X-Static-Env-Secret"

142+ - secretSource:

143+ value: "${MY_SECRET_ENV}" # content still needs to be base64 encoded

144+injectResponseHeaders:

145+ # Following will result in a header "Authorization: Basic <user:password> (encoded)"

146+ - name: "Authorization"

147+ values:

148+ - claimSource:

149+ claim: user

150+ prefix: "Basic "

151+ basicAuthPassword:

152+ value: c3VwZXItc2VjcmV0LXBhc3N3b3Jk # base64 encoded password

153+```

154+

155+**Value sources:**

156+* `claimSource` - `claim` (session claims either from id token or from profile URL)

157+* `secretSource` - `value` (base64), `fromFile` (file path)

158+

159+**Request option:** `preserveRequestValue: true` retains existing header values

160+

161+**Incompatibility:** Remove legacy flags `pass-user-headers`, `set-xauthrequest`

162+

163+## Removed options

164+

165+The following flags/options and their respective environment variables are no

166+longer available when using alpha configuration:

167+

168+<!-- Legacy Upstream FlagSet -->

169+- `flush-interval`/`flush_interval`

170+- `pass-host-header`/`pass_host_header`

171+- `proxy-websockets`/`proxy_websockets`

172+- `ssl-upstream-insecure-skip-verify`/`ssl_upstream_insecure_skip_verify`

173+- `upstream`/`upstreams`

174+

175+<!-- Legacy Headers FlagSet -->

176+- `pass-basic-auth`/`pass_basic_auth`

177+- `pass-access-token`/`pass_access_token`

178+- `pass-user-headers`/`pass_user_headers`

179+- `pass-authorization-header`/`pass_authorization_header`

180+- `set-basic-auth`/`set_basic_auth`

181+- `set-xauthrequest`/`set_xauthrequest`

182+- `set-authorization-header`/`set_authorization_header`

183+- `prefer-email-to-user`/`prefer_email_to_user`

184+- `basic-auth-password`/`basic_auth_password`

185+- `skip-auth-strip-headers`/`skip_auth_strip_headers`

186+

187+<!-- Legacy provider FlagSet -->

188+- `client-id`/`client_id`

189+- `client-secret`/`client_secret`, and `client-secret-file`/`client_secret_file`

190+- `provider`

191+- `provider-display-name`/`provider_display_name`

192+- `provider-ca-file`/`provider_ca_files`

193+- `login-url`/`login_url`

194+- `redeem-url`/`redeem_url`

195+- `profile-url`/`profile_url`

196+- `resource`

197+- `validate-url`/`validate_url`

198+- `scope`

199+- `prompt`

200+- `approval-prompt`/`approval_prompt`

201+- `acr-values`/`acr_values`

202+- `user-id-claim`/`user_id_claim`

203+- `allowed-group`/`allowed_groups`

204+- `allowed-role`/`allowed_roles`

205+- `jwt-key`/`jwt_key`

206+- `jwt-key-file`/`jwt_key_file`

207+- `pubjwk-url`/`pubjwk_url`

208+

209+and all provider-specific options, i.e. any option whose name includes `oidc`,

210+`azure`, `bitbucket`, `github`, `gitlab`, `google` or `keycloak`. Attempting to

211+use any of these options via flags or via config when `--alpha-config` is

212+set will result in an error.

213+

214+:::important

215+You must remove these options before starting OAuth2 Proxy with `--alpha-config`

216+:::

217+

218+## Configuration Reference

219+

220+<!--- THIS FILE IS AUTOGENERATED!!! DO NOT EDIT!!! -->

221+

222+### ADFSOptions

223+

224+(**Appears on:** [Provider](#provider))

225+

226+

227+

228+| Field | Type | Description |

229+| ----- | ---- | ----------- |

230+| `skipScope` | _bool_ | Skip adding the scope parameter in login request<br/>Default value is 'false' |

231+

232+### AlphaOptions

233+

234+AlphaOptions contains alpha structured configuration options.

235+Usage of these options allows users to access alpha features that are not

236+available as part of the primary configuration structure for OAuth2 Proxy.

237+

238+:::warning

239+The options within this structure are considered alpha.

240+They may change between releases without notice.

241+:::

242+

243+| Field | Type | Description |

244+| ----- | ---- | ----------- |

245+| `upstreamConfig` | _[UpstreamConfig](#upstreamconfig)_ | UpstreamConfig is used to configure upstream servers.<br/>Once a user is authenticated, requests to the server will be proxied to<br/>these upstream servers based on the path mappings defined in this list. |

246+| `injectRequestHeaders` | _[[]Header](#header)_ | InjectRequestHeaders is used to configure headers that should be added<br/>to requests to upstream servers.<br/>Headers may source values from either the authenticated user's session<br/>or from a static secret value. |

247+| `injectResponseHeaders` | _[[]Header](#header)_ | InjectResponseHeaders is used to configure headers that should be added<br/>to responses from the proxy.<br/>This is typically used when using the proxy as an external authentication<br/>provider in conjunction with another proxy such as NGINX and its<br/>auth_request module.<br/>Headers may source values from either the authenticated user's session<br/>or from a static secret value. |

248+| `server` | _[Server](#server)_ | Server is used to configure the HTTP(S) server for the proxy application.<br/>You may choose to run both HTTP and HTTPS servers simultaneously.<br/>This can be done by setting the BindAddress and the SecureBindAddress simultaneously.<br/>To use the secure server you must configure a TLS certificate and key. |

249+| `metricsServer` | _[Server](#server)_ | MetricsServer is used to configure the HTTP(S) server for metrics.<br/>You may choose to run both HTTP and HTTPS servers simultaneously.<br/>This can be done by setting the BindAddress and the SecureBindAddress simultaneously.<br/>To use the secure server you must configure a TLS certificate and key. |

250+| `providers` | _[Providers](#providers)_ | Providers is used to configure your provider. **Multiple-providers is not<br/>yet working.** [This feature is tracked in<br/>#925](https://github.com/oauth2-proxy/oauth2-proxy/issues/926) |

251+

252+### AzureOptions

253+

254+(**Appears on:** [Provider](#provider))

255+

256+

257+

258+| Field | Type | Description |

259+| ----- | ---- | ----------- |

260+| `tenant` | _string_ | Tenant directs to a tenant-specific or common (tenant-independent) endpoint<br/>Default value is 'common' |

261+| `graphGroupField` | _string_ | GraphGroupField configures the group field to be used when building the groups list from Microsoft Graph<br/>Default value is 'id' |

262+

263+### BitbucketOptions

264+

265+(**Appears on:** [Provider](#provider))

266+

267+

268+

269+| Field | Type | Description |

270+| ----- | ---- | ----------- |

271+| `team` | _string_ | Team sets restrict logins to members of this team |

272+| `repository` | _string_ | Repository sets restrict logins to user with access to this repository |

273+

274+### ClaimSource

275+

276+(**Appears on:** [HeaderValue](#headervalue))

277+

278+ClaimSource allows loading a header value from a claim within the session

279+

280+| Field | Type | Description |

281+| ----- | ---- | ----------- |

282+| `claim` | _string_ | Claim is the name of the claim in the session that the value should be<br/>loaded from. Available claims: `access_token` `id_token` `created_at`<br/>`expires_on` `refresh_token` `email` `user` `groups` `preferred_username`. |

283+| `prefix` | _string_ | Prefix is an optional prefix that will be prepended to the value of the<br/>claim if it is non-empty. |

284+| `basicAuthPassword` | _[SecretSource](#secretsource)_ | BasicAuthPassword converts this claim into a basic auth header.<br/>Note the value of claim will become the basic auth username and the<br/>basicAuthPassword will be used as the password value. |

285+

286+### GitHubOptions

287+

288+(**Appears on:** [Provider](#provider))

289+

290+

291+

292+| Field | Type | Description |

293+| ----- | ---- | ----------- |

294+| `org` | _string_ | Org sets restrict logins to members of this organisation |

295+| `team` | _string_ | Team sets restrict logins to members of this team |

296+| `repo` | _string_ | Repo sets restrict logins to collaborators of this repository |

297+| `token` | _string_ | Token is the token to use when verifying repository collaborators<br/>it must have push access to the repository |

298+| `users` | _[]string_ | Users allows users with these usernames to login<br/>even if they do not belong to the specified org and team or collaborators |

299+

300+### GitLabOptions

301+

302+(**Appears on:** [Provider](#provider))

303+

304+

305+

306+| Field | Type | Description |

307+| ----- | ---- | ----------- |

308+| `group` | _[]string_ | Group sets restrict logins to members of this group |

309+| `projects` | _[]string_ | Projects restricts logins to members of these projects |

310+

311+### GoogleOptions

312+

313+(**Appears on:** [Provider](#provider))

314+

315+

316+

317+| Field | Type | Description |

318+| ----- | ---- | ----------- |

319+| `group` | _[]string_ | Groups sets restrict logins to members of this Google group |

320+| `adminEmail` | _string_ | AdminEmail is the Google admin to impersonate for api calls |

321+| `serviceAccountJson` | _string_ | ServiceAccountJSON is the path to the service account json credentials |

322+| `useApplicationDefaultCredentials` | _bool_ | UseApplicationDefaultCredentials is a boolean whether to use Application Default Credentials instead of a ServiceAccountJSON |

323+| `targetPrincipal` | _string_ | TargetPrincipal is the Google Service Account used for Application Default Credentials |

324+| `useOrganizationID` | _bool_ | UseOrganizationId indicates whether to use the organization ID as the UserName claim |

325+| `adminAPIUserScope` | _string_ | admin scope needed for fetching user organization information from admin api, can be one of cloud, user or defaults to readonly |

326+

327+### Header

328+

329+(**Appears on:** [AlphaOptions](#alphaoptions))

330+

331+Header represents an individual header that will be added to a request or

332+response header.

333+

334+| Field | Type | Description |

335+| ----- | ---- | ----------- |

336+| `name` | _string_ | Name is the header name to be used for this set of values.<br/>Names should be unique within a list of Headers. |

337+| `preserveRequestValue` | _bool_ | PreserveRequestValue determines whether any values for this header<br/>should be preserved for the request to the upstream server.<br/>This option only applies to injected request headers.<br/>Defaults to false (headers that match this header will be stripped). |

338+| `InsecureSkipHeaderNormalization` | _bool_ | InsecureSkipHeaderNormalization disables normalizing the header name<br/>According to RFC 7230 Section 3.2 there aren't any rules about<br/>capitalization of header names, but the standard practice is to use<br/>Title-Case (e.g. X-Forwarded-For). By default, header names will be<br/>normalized to Title-Case and any incoming headers that match will be<br/>treated as the same header. Additionally underscores (_) in header names<br/>will be converted to dashes (-) when normalizing.<br/>Defaults to false (header names will be normalized). |

339+| `values` | _[[]HeaderValue](#headervalue)_ | Values contains the desired values for this header |

340+

341+### HeaderValue

342+

343+(**Appears on:** [Header](#header))

344+

345+HeaderValue represents a single header value and the sources that can

346+make up the header value

347+

348+| Field | Type | Description |

349+| ----- | ---- | ----------- |

350+| `value` | _[]byte_ | Value expects a base64 encoded string value. |

351+| `fromEnv` | _string_ | FromEnv expects the name of an environment variable. |

352+| `fromFile` | _string_ | FromFile expects a path to a file containing the secret value. |

353+| `claim` | _string_ | Claim is the name of the claim in the session that the value should be<br/>loaded from. Available claims: `access_token` `id_token` `created_at`<br/>`expires_on` `refresh_token` `email` `user` `groups` `preferred_username`. |

354+| `prefix` | _string_ | Prefix is an optional prefix that will be prepended to the value of the<br/>claim if it is non-empty. |

355+| `basicAuthPassword` | _[SecretSource](#secretsource)_ | BasicAuthPassword converts this claim into a basic auth header.<br/>Note the value of claim will become the basic auth username and the<br/>basicAuthPassword will be used as the password value. |

356+

357+### KeycloakOptions

358+

359+(**Appears on:** [Provider](#provider))

360+

361+

362+

363+| Field | Type | Description |

364+| ----- | ---- | ----------- |

365+| `groups` | _[]string_ | Group enables to restrict login to members of indicated group |

366+| `roles` | _[]string_ | Role enables to restrict login to users with role (only available when using the keycloak-oidc provider) |

367+

368+### LoginGovOptions

369+

370+(**Appears on:** [Provider](#provider))

371+

372+

373+

374+| Field | Type | Description |

375+| ----- | ---- | ----------- |

376+| `jwtKey` | _string_ | JWTKey is a private key in PEM format used to sign JWT, |

377+| `jwtKeyFile` | _string_ | JWTKeyFile is a path to the private key file in PEM format used to sign the JWT |

378+| `pubjwkURL` | _string_ | PubJWKURL is the JWK pubkey access endpoint |

379+

380+### LoginURLParameter

381+

382+(**Appears on:** [Provider](#provider))

383+

384+LoginURLParameter is the configuration for a single query parameter that

385+can be passed through from the `/oauth2/start` endpoint to the IdP login

386+URL. The "default" option specifies the default value or values (if any)

387+that will be passed to the IdP for this parameter, and "allow" is a list

388+of options for ways in which this parameter can be set or overridden via

389+the query string to `/oauth2/start`.

390+If _only_ a default is specified and no "allow" then the parameter is

391+effectively fixed - the default value will always be used and anything

392+passed to the start URL will be ignored. If _only_ "allow" is specified

393+but no default then the parameter will only be passed on to the IdP if

394+the caller provides it, and no value will be sent otherwise.

395+

396+Examples:

397+

398+# A parameter whose value is fixed

399+

400+```

401+name: organization

402+default:

403+- myorg

404+```

405+

406+A parameter that is not passed by default, but may be set to one of a

407+fixed set of values

408+

409+```

410+name: prompt

411+allow:

412+- value: login

413+- value: consent

414+- value: select_account

415+```

416+

417+A parameter that is passed by default but may be overridden by one of

418+a fixed set of values

419+

420+```

421+name: prompt

422+default: ["login"]

423+allow:

424+- value: consent

425+- value: select_account

426+```

427+

428+A parameter that may be overridden, but only by values that match a

429+regular expression. For example to restrict `login_hint` to email

430+addresses in your organization's domain:

431+

432+```

433+name: login_hint

434+allow:

435+- pattern: '^[^@]*@example\.com$'

436+# this allows at most one "@" sign, and requires "example.com" domain.

437+```

438+

439+Note that the YAML rules around exactly which characters are allowed

440+and/or require escaping in different types of string literals are

441+convoluted. For regular expressions the single quoted form is simplest

442+as backslash is not considered to be an escape character. Alternatively

443+use the "chomped block" format `|-`:

444+

445+```

446+ - pattern: |-

447+ ^[^@]*@example\.com$

448+

449+```

450+

451+The hyphen is important, a `|` block would have a trailing newline

452+character.

453+

454+| Field | Type | Description |

455+| ----- | ---- | ----------- |

456+| `name` | _string_ | Name specifies the name of the query parameter. |

457+| `default` | _[]string_ | _(Optional)_ Default specifies a default value or values that will be<br/>passed to the IdP if not overridden. |

458+| `allow` | _[[]URLParameterRule](#urlparameterrule)_ | _(Optional)_ Allow specifies rules about how the default (if any) may be<br/>overridden via the query string to `/oauth2/start`. Only<br/>values that match one or more of the allow rules will be<br/>forwarded to the IdP. |

459+

460+### MicrosoftEntraIDOptions

461+

462+(**Appears on:** [Provider](#provider))

463+

464+

465+

466+| Field | Type | Description |

467+| ----- | ---- | ----------- |

468+| `allowedTenants` | _[]string_ | AllowedTenants is a list of allowed tenants. In case of multi-tenant apps, incoming tokens are<br/>issued by different issuers and OIDC issuer verification needs to be disabled.<br/>When not specified, all tenants are allowed. Redundant for single-tenant apps<br/>(regular ID token validation matches the issuer). |

469+| `federatedTokenAuth` | _bool_ | FederatedTokenAuth enable oAuth2 client authentication with federated token projected<br/>by Entra Workload Identity plugin, instead of client secret. |

470+

471+### OIDCOptions

472+

473+(**Appears on:** [Provider](#provider))

474+

475+

476+

477+| Field | Type | Description |

478+| ----- | ---- | ----------- |

479+| `issuerURL` | _string_ | IssuerURL is the OpenID Connect issuer URL<br/>eg: https://accounts.google.com |

480+| `insecureAllowUnverifiedEmail` | _bool_ | InsecureAllowUnverifiedEmail prevents failures if an email address in an id_token is not verified<br/>default set to 'false' |

481+| `insecureSkipIssuerVerification` | _bool_ | InsecureSkipIssuerVerification skips verification of ID token issuers. When false, ID Token Issuers must match the OIDC discovery URL<br/>default set to 'false' |

482+| `insecureSkipNonce` | _bool_ | InsecureSkipNonce skips verifying the ID Token's nonce claim that must match<br/>the random nonce sent in the initial OAuth flow. Otherwise, the nonce is checked<br/>after the initial OAuth redeem & subsequent token refreshes.<br/>default set to 'true'<br/>Warning: In a future release, this will change to 'false' by default for enhanced security. |

483+| `skipDiscovery` | _bool_ | SkipDiscovery allows to skip OIDC discovery and use manually supplied Endpoints<br/>default set to 'false' |

484+| `jwksURL` | _string_ | JwksURL is the OpenID Connect JWKS URL<br/>eg: https://www.googleapis.com/oauth2/v3/certs |

485+| `publicKeyFiles` | _[]string_ | PublicKeyFiles is a list of paths pointing to public key files in PEM format to use<br/>for verifying JWT tokens |

486+| `emailClaim` | _string_ | EmailClaim indicates which claim contains the user email,<br/>default set to 'email' |

487+| `groupsClaim` | _string_ | GroupsClaim indicates which claim contains the user groups<br/>default set to 'groups' |

488+| `userIDClaim` | _string_ | UserIDClaim indicates which claim contains the user ID<br/>default set to 'email' |

489+| `audienceClaims` | _[]string_ | AudienceClaim allows to define any claim that is verified against the client id<br/>By default `aud` claim is used for verification. |

490+| `extraAudiences` | _[]string_ | ExtraAudiences is a list of additional audiences that are allowed<br/>to pass verification in addition to the client id. |

491+

492+### Provider

493+

494+(**Appears on:** [Providers](#providers))

495+

496+Provider holds all configuration for a single provider

497+

498+| Field | Type | Description |

499+| ----- | ---- | ----------- |

500+| `clientID` | _string_ | ClientID is the OAuth Client ID that is defined in the provider<br/>This value is required for all providers. |

501+| `clientSecret` | _string_ | ClientSecret is the OAuth Client Secret that is defined in the provider<br/>This value is required for all providers. |

502+| `clientSecretFile` | _string_ | ClientSecretFile is the name of the file<br/>containing the OAuth Client Secret, it will be used if ClientSecret is not set. |

503+| `keycloakConfig` | _[KeycloakOptions](#keycloakoptions)_ | KeycloakConfig holds all configurations for Keycloak provider. |

504+| `azureConfig` | _[AzureOptions](#azureoptions)_ | AzureConfig holds all configurations for Azure provider. |

505+| `microsoftEntraIDConfig` | _[MicrosoftEntraIDOptions](#microsoftentraidoptions)_ | MicrosoftEntraIDConfig holds all configurations for Entra ID provider. |

506+| `ADFSConfig` | _[ADFSOptions](#adfsoptions)_ | ADFSConfig holds all configurations for ADFS provider. |

507+| `bitbucketConfig` | _[BitbucketOptions](#bitbucketoptions)_ | BitbucketConfig holds all configurations for Bitbucket provider. |

508+| `githubConfig` | _[GitHubOptions](#githuboptions)_ | GitHubConfig holds all configurations for GitHubC provider. |

509+| `gitlabConfig` | _[GitLabOptions](#gitlaboptions)_ | GitLabConfig holds all configurations for GitLab provider. |

510+| `googleConfig` | _[GoogleOptions](#googleoptions)_ | GoogleConfig holds all configurations for Google provider. |

511+| `oidcConfig` | _[OIDCOptions](#oidcoptions)_ | OIDCConfig holds all configurations for OIDC provider<br/>or providers utilize OIDC configurations. |

512+| `loginGovConfig` | _[LoginGovOptions](#logingovoptions)_ | LoginGovConfig holds all configurations for LoginGov provider. |

513+| `id` | _string_ | ID should be a unique identifier for the provider.<br/>This value is required for all providers. |

514+| `provider` | _[ProviderType](#providertype)_ | Type is the OAuth provider<br/>must be set from the supported providers group,<br/>otherwise 'Google' is set as default |

515+| `name` | _string_ | Name is the providers display name<br/>if set, it will be shown to the users in the login page. |

516+| `caFiles` | _[]string_ | CAFiles is a list of paths to CA certificates that should be used when connecting to the provider.<br/>If not specified, the default Go trust sources are used instead |

517+| `useSystemTrustStore` | _bool_ | UseSystemTrustStore determines if your custom CA files and the system trust store are used<br/>If set to true, your custom CA files and the system trust store are used otherwise only your custom CA files. |

518+| `loginURL` | _string_ | LoginURL is the authentication endpoint |

519+| `loginURLParameters` | _[[]LoginURLParameter](#loginurlparameter)_ | LoginURLParameters defines the parameters that can be passed from the start URL to the IdP login URL |

520+| `authRequestResponseMode` | _string_ | AuthRequestResponseMode defines the response mode to request during authorization request |

521+| `redeemURL` | _string_ | RedeemURL is the token redemption endpoint |

522+| `profileURL` | _string_ | ProfileURL is the profile access endpoint |

523+| `skipClaimsFromProfileURL` | _bool_ | SkipClaimsFromProfileURL allows to skip request to Profile URL for resolving claims not present in id_token<br/>default set to 'false' |

524+| `resource` | _string_ | ProtectedResource is the resource that is protected (Azure AD and ADFS only) |

525+| `validateURL` | _string_ | ValidateURL is the access token validation endpoint |

526+| `scope` | _string_ | Scope is the OAuth scope specification |

527+| `allowedGroups` | _[]string_ | AllowedGroups is a list of restrict logins to members of this group |

528+| `code_challenge_method` | _string_ | The code challenge method |

529+| `backendLogoutURL` | _string_ | URL to call to perform backend logout, `{id_token}` would be replaced by the actual `id_token` if available in the session |

530+

531+### ProviderType

532+#### (`string` alias)

533+

534+(**Appears on:** [Provider](#provider))

535+

536+ProviderType is used to enumerate the different provider type options

537+Valid options are: adfs, azure, bitbucket, digitalocean facebook, github,

538+gitlab, google, keycloak, keycloak-oidc, linkedin, login.gov, nextcloud

539+and oidc.

540+

541+### Providers

542+

543+#### ([[]Provider](#provider) alias)

544+

545+(**Appears on:** [AlphaOptions](#alphaoptions))

546+

547+The provider can be selected using the `provider` configuration value, or

548+set in the [`providers` array using

549+AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers).

550+However, [**the feature to implement multiple providers is not

551+complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

552+

553+### SecretSource

554+

555+(**Appears on:** [ClaimSource](#claimsource), [HeaderValue](#headervalue), [TLS](#tls))

556+

557+SecretSource references an individual secret value.

558+Only one source within the struct should be defined at any time.

559+

560+| Field | Type | Description |

561+| ----- | ---- | ----------- |

562+| `value` | _[]byte_ | Value expects a base64 encoded string value. |

563+| `fromEnv` | _string_ | FromEnv expects the name of an environment variable. |

564+| `fromFile` | _string_ | FromFile expects a path to a file containing the secret value. |

565+

566+### Server

567+

568+(**Appears on:** [AlphaOptions](#alphaoptions))

569+

570+Server represents the configuration for an HTTP(S) server

571+

572+| Field | Type | Description |

573+| ----- | ---- | ----------- |

574+| `bindAddress` | _string_ | BindAddress is the address on which to serve traffic.<br/>Leave blank or set to "-" to disable. |

575+| `secureBindAddress` | _string_ | SecureBindAddress is the address on which to serve secure traffic.<br/>Leave blank or set to "-" to disable. |

576+| `tls` | _[TLS](#tls)_ | TLS contains the information for loading the certificate and key for the<br/>secure traffic and further configuration for the TLS server. |

577+

578+### TLS

579+

580+(**Appears on:** [Server](#server))

581+

582+TLS contains the information for loading a TLS certificate and key

583+as well as an optional minimal TLS version that is acceptable.

584+

585+| Field | Type | Description |

586+| ----- | ---- | ----------- |

587+| `key` | _[SecretSource](#secretsource)_ | Key is the TLS key data to use.<br/>Typically this will come from a file. |

588+| `cert` | _[SecretSource](#secretsource)_ | Cert is the TLS certificate data to use.<br/>Typically this will come from a file. |

589+| `minVersion` | _string_ | MinVersion is the minimal TLS version that is acceptable.<br/>E.g. Set to "TLS1.3" to select TLS version 1.3 |

590+| `cipherSuites` | _[]string_ | CipherSuites is a list of TLS cipher suites that are allowed.<br/>E.g.:<br/>- TLS_RSA_WITH_RC4_128_SHA<br/>- TLS_RSA_WITH_AES_256_GCM_SHA384<br/>If not specified, the default Go safe cipher list is used.<br/>List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). |

591+

592+### URLParameterRule

593+

594+(**Appears on:** [LoginURLParameter](#loginurlparameter))

595+

596+URLParameterRule represents a rule by which query parameters

597+passed to the `/oauth2/start` endpoint are checked to determine whether

598+they are valid overrides for the given parameter passed to the IdP's

599+login URL. Either Value or Pattern should be supplied, not both.

600+

601+| Field | Type | Description |

602+| ----- | ---- | ----------- |

603+| `value` | _string_ | A Value rule matches just this specific value |

604+| `pattern` | _string_ | A Pattern rule gives a regular expression that must be matched by<br/>some substring of the value. The expression is _not_ automatically<br/>anchored to the start and end of the value, if you _want_ to restrict<br/>the whole parameter value you must anchor it yourself with `^` and `$`. |

605+

606+### Upstream

607+

608+(**Appears on:** [UpstreamConfig](#upstreamconfig))

609+

610+Upstream represents the configuration for an upstream server.

611+Requests will be proxied to this upstream if the path matches the request path.

612+

613+| Field | Type | Description |

614+| ----- | ---- | ----------- |

615+| `id` | _string_ | ID should be a unique identifier for the upstream.<br/>This value is required for all upstreams. |

616+| `path` | _string_ | Path is used to map requests to the upstream server.<br/>The closest match will take precedence and all Paths must be unique.<br/>Path can also take a pattern when used with RewriteTarget.<br/>Path segments can be captured and matched using regular experessions.<br/>Eg:<br/>- `^/foo$`: Match only the explicit path `/foo`<br/>- `^/bar/$`: Match any path prefixed with `/bar/`<br/>- `^/baz/(.*)$`: Match any path prefixed with `/baz` and capture the remaining path for use with RewriteTarget |

617+| `rewriteTarget` | _string_ | RewriteTarget allows users to rewrite the request path before it is sent to<br/>the upstream server (for an HTTP/HTTPS upstream) or mapped to the filesystem<br/>(for a `file:` upstream).<br/>Use the Path to capture segments for reuse within the rewrite target.<br/>Eg: With a Path of `^/baz/(.*)`, a RewriteTarget of `/foo/$1` would rewrite<br/>the request `/baz/abc/123` to `/foo/abc/123` before proxying to the<br/>upstream server. Or if the upstream were `file:///app`, a request for<br/>`/baz/info.html` would return the contents of the file `/app/foo/info.html`. |

618+| `uri` | _string_ | The URI of the upstream server. This may be an HTTP(S) server of a File<br/>based URL. It may include a path, in which case all requests will be served<br/>under that path.<br/>Eg:<br/>- http://localhost:8080<br/>- https://service.localhost<br/>- https://service.localhost/path<br/>- file://host/path<br/>If the URI's path is "/base" and the incoming request was for "/dir",<br/>the upstream request will be for "/base/dir". |

619+| `insecureSkipTLSVerify` | _bool_ | InsecureSkipTLSVerify will skip TLS verification of upstream HTTPS hosts.<br/>This option is insecure and will allow potential Man-In-The-Middle attacks<br/>between OAuth2 Proxy and the upstream server.<br/>Defaults to false. |

620+| `static` | _bool_ | Static will make all requests to this upstream have a static response.<br/>The response will have a body of "Authenticated" and a response code<br/>matching StaticCode.<br/>If StaticCode is not set, the response will return a 200 response. |

621+| `staticCode` | _int_ | StaticCode determines the response code for the Static response.<br/>This option can only be used with Static enabled. |

622+| `flushInterval` | _duration_ | FlushInterval is the period between flushing the response buffer when<br/>streaming response from the upstream.<br/>Defaults to 1 second. |

623+| `passHostHeader` | _bool_ | PassHostHeader determines whether the request host header should be proxied<br/>to the upstream server.<br/>Defaults to true. |

624+| `proxyWebSockets` | _bool_ | ProxyWebSockets enables proxying of websockets to upstream servers<br/>Defaults to true. |

625+| `timeout` | _duration_ | Timeout is the maximum duration the server will wait for a response from the upstream server.<br/>Defaults to 30 seconds. |

626+| `disableKeepAlives` | _bool_ | DisableKeepAlives disables HTTP keep-alive connections to the upstream server.<br/>Defaults to false. |

627+

628+### UpstreamConfig

629+

630+(**Appears on:** [AlphaOptions](#alphaoptions))

631+

632+UpstreamConfig is a collection of definitions for upstream servers.

633+

634+| Field | Type | Description |

635+| ----- | ---- | ----------- |

636+| `proxyRawPath` | _bool_ | ProxyRawPath will pass the raw url path to upstream allowing for urls<br/>like: "/%2F/" which would otherwise be redirected to "/" |

637+| `upstreams` | _[[]Upstream](#upstream)_ | Upstreams represents the configuration for the upstream servers.<br/>Requests will be proxied to this upstream if the path matches the request path. |

docs/versioned_docs/version-7.14.x/configuration/alpha_config.md.tmplnew file+218

@@ -0,0 +1,218 @@

1+---

2+id: alpha-config

3+title: Alpha Configuration

4+---

5+

6+:::warning

7+This page contains documentation for alpha features.

8+We reserve the right to make breaking changes to the features detailed within this page with no notice.

9+

10+Options described in this page may be changed, removed, renamed or moved without prior warning.

11+Please beware of this before you use alpha configuration options.

12+:::

13+

14+This page details a set of **alpha** configuration options in a new format.

15+Going forward we are intending to add structured configuration in YAML format to

16+replace the existing TOML based configuration file and flags.

17+

18+Below is a reference for the structure of the configuration, with

19+[AlphaOptions](#alphaoptions) as the root of the configuration.

20+

21+When using alpha configuration, your config file will look something like below:

22+

23+```yaml

24+upstreams:

25+ - id: ...

26+ ...: ...

27+providers:

28+ - id: ...

29+ ...: ...

30+cookie:

31+ secret: ...

32+ ...: ...

33+injectRequestHeaders:

34+ - secretSource:

35+ ...: ...

36+injectResponseHeaders:

37+ - claimSource:

38+ ...: ...

39+```

40+

41+Please browse the [reference](#configuration-reference) below for the structure

42+of the new configuration format.

43+

44+# Migration Guide

45+

46+This section details breaking changes and migration steps for moving to the new

47+alpha configuration format.

48+

49+## Migrating header injections in v7.14.0

50+

51+From v7.14.0 onward, header injection sources must be explicitly nested. If you

52+previously relied on squashed fields, update to the new structure before

53+upgrading:

54+

55+```yaml

56+# before v7.14.0

57+injectRequestHeaders:

58+- name: X-Forwarded-User

59+ values:

60+ - claim: user

61+- name: X-Custom-Secret-header

62+ values:

63+ - value: my-super-secret

64+

65+# v7.14.0 and later

66+injectRequestHeaders:

67+- name: X-Forwarded-User

68+ values:

69+ - claimSource:

70+ claim: user

71+- name: X-Custom-Secret-header

72+ values:

73+ - secretSource:

74+ value: my-super-secret

75+```

76+

77+## Using Alpha Configuration

78+

79+To use the new **alpha** configuration, generate a YAML file based on the format

80+described in the [reference](#configuration-reference) below.

81+

82+Provide the path to this file using the `--alpha-config` flag.

83+

84+:::note

85+When using the `--alpha-config` flag, some options are no longer available.

86+See [removed options](#removed-options) below for more information.

87+:::

88+

89+### Converting configuration to the new structure

90+

91+Before adding the new `--alpha-config` option, start OAuth2 Proxy using the

92+`convert-config-to-alpha` flag to convert existing configuration to the new format.

93+

94+```bash

95+oauth2-proxy --convert-config-to-alpha --config ./path/to/existing/config.cfg

96+```

97+

98+This will convert any options supported by the new format to YAML and print the

99+new configuration to `STDOUT`.

100+

101+Copy this to a new file, remove any options from your existing configuration

102+noted in [removed options](#removed-options) and then start OAuth2 Proxy using

103+the new config.

104+

105+```bash

106+oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

107+```

108+

109+### How to use environment variables

110+

111+The alpha package supports the use of environment variables in place of yaml values, allowing sensitive data to be pulled from somewhere other than the yaml file.

112+When using environment variables, your yaml will look like this:

113+

114+```yaml

115+ providers:

116+ - provider: azure

117+ clientSecret: ${CLIENT_SECRET}

118+ ...

119+```

120+Where CLIENT_SECRET is an environment variable.

121+More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

122+

123+### How to inject custom headers

124+

125+Configure `injectRequestHeaders` and `injectResponseHeaders` in alpha config YAML.

126+

127+```yaml

128+injectRequestHeaders:

129+ - name: "X-User-Email"

130+ values:

131+ - claimSource:

132+ claim: "email" # extract the email claim contents from the id token

133+ - name: "X-Static-Secret"

134+ values:

135+ # secrets need to be encoded with base64 when directly in the yaml config but will be send decoded

136+ - secretSource:

137+ value: "c3VwZXItc2VjcmV0"

138+ - name: "X-Static-File-Secret"

139+ - secretSource:

140+ fromFile: "/path/to/my/secret"

141+ - name: "X-Static-Env-Secret"

142+ - secretSource:

143+ value: "${MY_SECRET_ENV}" # content still needs to be base64 encoded

144+injectResponseHeaders:

145+ # Following will result in a header "Authorization: Basic <user:password> (encoded)"

146+ - name: "Authorization"

147+ values:

148+ - claimSource:

149+ claim: user

150+ prefix: "Basic "

151+ basicAuthPassword:

152+ value: c3VwZXItc2VjcmV0LXBhc3N3b3Jk # base64 encoded password

153+```

154+

155+**Value sources:**

156+* `claimSource` - `claim` (session claims either from id token or from profile URL)

157+* `secretSource` - `value` (base64), `fromFile` (file path)

158+

159+**Request option:** `preserveRequestValue: true` retains existing header values

160+

161+**Incompatibility:** Remove legacy flags `pass-user-headers`, `set-xauthrequest`

162+

163+## Removed options

164+

165+The following flags/options and their respective environment variables are no

166+longer available when using alpha configuration:

167+

168+<!-- Legacy Upstream FlagSet -->

169+- `flush-interval`/`flush_interval`

170+- `pass-host-header`/`pass_host_header`

171+- `proxy-websockets`/`proxy_websockets`

172+- `ssl-upstream-insecure-skip-verify`/`ssl_upstream_insecure_skip_verify`

173+- `upstream`/`upstreams`

174+

175+<!-- Legacy Headers FlagSet -->

176+- `pass-basic-auth`/`pass_basic_auth`

177+- `pass-access-token`/`pass_access_token`

178+- `pass-user-headers`/`pass_user_headers`

179+- `pass-authorization-header`/`pass_authorization_header`

180+- `set-basic-auth`/`set_basic_auth`

181+- `set-xauthrequest`/`set_xauthrequest`

182+- `set-authorization-header`/`set_authorization_header`

183+- `prefer-email-to-user`/`prefer_email_to_user`

184+- `basic-auth-password`/`basic_auth_password`

185+- `skip-auth-strip-headers`/`skip_auth_strip_headers`

186+

187+<!-- Legacy provider FlagSet -->

188+- `client-id`/`client_id`

189+- `client-secret`/`client_secret`, and `client-secret-file`/`client_secret_file`

190+- `provider`

191+- `provider-display-name`/`provider_display_name`

192+- `provider-ca-file`/`provider_ca_files`

193+- `login-url`/`login_url`

194+- `redeem-url`/`redeem_url`

195+- `profile-url`/`profile_url`

196+- `resource`

197+- `validate-url`/`validate_url`

198+- `scope`

199+- `prompt`

200+- `approval-prompt`/`approval_prompt`

201+- `acr-values`/`acr_values`

202+- `user-id-claim`/`user_id_claim`

203+- `allowed-group`/`allowed_groups`

204+- `allowed-role`/`allowed_roles`

205+- `jwt-key`/`jwt_key`

206+- `jwt-key-file`/`jwt_key_file`

207+- `pubjwk-url`/`pubjwk_url`

208+

209+and all provider-specific options, i.e. any option whose name includes `oidc`,

210+`azure`, `bitbucket`, `github`, `gitlab`, `google` or `keycloak`. Attempting to

211+use any of these options via flags or via config when `--alpha-config` is

212+set will result in an error.

213+

214+:::important

215+You must remove these options before starting OAuth2 Proxy with `--alpha-config`

216+:::

217+

218+## Configuration Reference

docs/versioned_docs/version-7.14.x/configuration/integrations/caddy.mdnew file+63

@@ -0,0 +1,63 @@

1+---

2+id: caddy

3+title: Caddy

4+---

5+

6+Integrate OAuth2 Proxy with Caddy v2 using the `forward_auth` directive.

7+

8+**Key features:**

9+- Simple forward_auth setup

10+- Automatic header handling

11+- Custom error handling and redirects

12+

13+## Configuring for use with the Caddy (v2) `forward_auth` directive

14+

15+The [Caddy `forward_auth` directive](https://caddyserver.com/docs/caddyfile/directives/forward_auth) allows Caddy to authenticate requests via the `oauth2-proxy`'s `/auth`.

16+

17+This example is for a simple reverse proxy setup where the `/oauth2/` path is kept under the same domain and failed auth requests (401 status returned) will be caught and redirected to the `sign_in` endpoint.

18+

19+**Following options need to be set on `oauth2-proxy`:**

20+- `--reverse-proxy=true`: Enables the use of `X-Forwarded-*` headers to determine redirects correctly

21+

22+```nginx title="Caddyfile"

23+example.com {

24+ # Requests to /oauth2/* are proxied to oauth2-proxy without authentication.

25+ # You can't use `reverse_proxy /oauth2/* oauth2-proxy.internal:4180` here because the reverse_proxy directive has lower precedence than the handle directive.

26+ handle /oauth2/* {

27+ reverse_proxy oauth2-proxy.internal:4180 {

28+ # oauth2-proxy requires the X-Real-IP and X-Forwarded-{Proto,Host,Uri} headers.

29+ # The reverse_proxy directive automatically sets X-Forwarded-{For,Proto,Host} headers.

30+ header_up X-Real-IP {remote_host}

31+ header_up X-Forwarded-Uri {uri}

32+ }

33+ }

34+

35+ # Requests to other paths are first processed by oauth2-proxy for authentication.

36+ handle {

37+ forward_auth oauth2-proxy.internal:4180 {

38+ uri /oauth2/auth

39+

40+ # oauth2-proxy requires the X-Real-IP and X-Forwarded-{Proto,Host,Uri} headers.

41+ # The forward_auth directive automatically sets the X-Forwarded-{For,Proto,Host,Method,Uri} headers.

42+ header_up X-Real-IP {remote_host}

43+

44+ # If needed, you can copy headers from the oauth2-proxy response to the request sent to the upstream.

45+ # Make sure to configure the --set-xauthrequest flag to enable this feature.

46+ #copy_headers X-Auth-Request-User X-Auth-Request-Email

47+

48+ # If oauth2-proxy returns a 401 status, redirect the client to the sign-in page.

49+ @error status 401

50+ handle_response @error {

51+ redir * /oauth2/sign_in?rd={scheme}://{host}{uri}

52+ }

53+ }

54+

55+ # If oauth2-proxy returns a 2xx status, the request is then proxied to the upstream.

56+ reverse_proxy upstream.internal:3000

57+ }

58+}

59+```

60+

61+:::note

62+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

63+:::

docs/versioned_docs/version-7.14.x/configuration/integrations/headlamp.mdnew file+105

@@ -0,0 +1,105 @@

1+---

2+id: headlamp

3+title: Headlamp

4+---

5+

6+Modern, actively maintained Kubernetes web UI with OAuth2 Proxy integration examples.

7+

8+**Key features:**

9+- Active development and maintenance

10+- Modern, intuitive interface

11+- Multi-cluster support

12+- Plugin system

13+- Works with all OAuth2 providers

14+

15+## Configuring for use with Headlamp

16+

17+[Headlamp](https://headlamp.dev/) is a modern, user-friendly Kubernetes web UI that can be integrated with OAuth2 Proxy for authentication. This is a recommended alternative to the deprecated Kubernetes Dashboard.

18+

19+### Architecture

20+

21+```

22+User → Ingress → OAuth2 Proxy → Authentication Provider (e.g., Azure Entra ID)

23+ ↓

24+ Headlamp

25+```

26+

27+### Prerequisites

28+

29+- Kubernetes cluster (e.g., AKS, EKS, GKE, or self-hosted)

30+- Headlamp installed in the cluster

31+- OAuth2 provider configured (Azure Entra ID, Google, GitHub, etc.)

32+- Ingress controller (Nginx, Traefik, etc.)

33+

34+### Configuration Overview

35+

36+When integrating Headlamp with OAuth2 Proxy, the OAuth2 Proxy acts as a reverse proxy in front of Headlamp:

37+

38+1. User requests access to Headlamp

39+2. Ingress forwards to OAuth2 Proxy

40+3. OAuth2 Proxy authenticates the user via the OAuth2 provider

41+4. After successful authentication, OAuth2 Proxy proxies requests to Headlamp

42+5. Headlamp receives the authenticated user information via headers

43+

44+### OAuth2 Proxy Configuration

45+

46+Configure OAuth2 Proxy to proxy to the Headlamp service:

47+

48+```yaml

49+upstreamConfig:

50+ upstreams:

51+ - id: headlamp

52+ path: /

53+ uri: http://headlamp-service.headlamp-namespace.svc.cluster.local:4466

54+```

55+

56+Enable the necessary headers:

57+

58+```yaml

59+extraArgs:

60+ reverse-proxy: true

61+ pass-authorization-header: true

62+ set-xauthrequest: true

63+ email-domain: "*" # Or restrict to your organization

64+```

65+

66+### Example with Azure Entra ID on AKS

67+

68+For detailed instructions on deploying Headlamp with OAuth2 Proxy on Azure Kubernetes Service using Azure Entra ID, see the official Headlamp documentation:

69+

70+https://headlamp.dev/docs/latest/installation/in-cluster/aks-cluster-oauth/

71+

72+Key steps include:

73+

74+1. **Set up AKS with OIDC**: Enable Microsoft Entra ID authentication with Kubernetes RBAC

75+2. **Create Azure App Registration**: Configure redirect URI and create client secret

76+3. **Deploy Headlamp**: Install Headlamp via Helm in your cluster

77+4. **Deploy OAuth2 Proxy**: Configure OAuth2 Proxy with Entra ID provider settings and upstream pointing to Headlamp

78+5. **Configure Ingress**: Set up Ingress to route traffic through OAuth2 Proxy to Headlamp

79+6. **Set RBAC Policies**: Apply Kubernetes RBAC bindings based on users or groups

80+

81+### Integration with Other Providers

82+

83+The same integration pattern works with other OAuth2 providers supported by OAuth2 Proxy:

84+

85+- **Google**: Use the Google provider configuration

86+- **GitHub**: Use the GitHub provider configuration

87+- **GitLab**: Use the GitLab provider configuration

88+- **Keycloak**: Use the Keycloak OIDC provider configuration

89+- **Any OIDC Provider**: Use the generic OIDC provider configuration

90+

91+For provider-specific configuration examples, see the [OAuth Provider Configuration](../providers/index.md) documentation.

92+

93+### Benefits Over Kubernetes Dashboard

94+

95+Headlamp offers several advantages:

96+

97+- **Active Development**: Headlamp is actively maintained and developed

98+- **Modern UI**: Clean, intuitive interface with better UX

99+- **Plugin System**: Extensible with custom plugins

100+- **Multi-cluster Support**: Built-in support for managing multiple clusters

101+- **Desktop App**: Available as both web UI and desktop application

102+

103+:::note

104+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

105+:::

docs/versioned_docs/version-7.14.x/configuration/integrations/index.mdnew file+41

@@ -0,0 +1,41 @@

1+---

2+id: index

3+title: Integrations

4+---

5+

6+This section provides configuration examples for integrating OAuth2 Proxy with various reverse proxies, ingress controllers, and Kubernetes web UIs.

7+

8+## Reverse Proxies and Ingress Controllers

9+

10+OAuth2 Proxy can be integrated with popular reverse proxies and ingress controllers to add authentication to your applications:

11+

12+- [Nginx](nginx.md)

13+- [Traefik](traefik.md)

14+- [caddy](caddy.md)

15+

16+## Kubernetes Web UIs

17+

18+OAuth2 Proxy can also be used to add authentication to Kubernetes web user interfaces:

19+

20+- [Headlamp](headlamp.md) ✨ *Recommended*

21+- [Kubernetes Dashboard](kubernetes-dashboard.md) ⚠️ *Deprecated*

22+

23+:::tip

24+When integrating with Kubernetes web UIs, make sure to:

25+1. Configure the Ingress to pass the Authorization header with the bearer token

26+2. Increase buffer sizes for large OIDC tokens (especially with Azure Entra ID)

27+3. Set up appropriate Kubernetes RBAC permissions for your users or groups

28+:::

29+

30+## General Requirements

31+

32+Most integrations require the following OAuth2 Proxy configuration:

33+

34+- `--reverse-proxy=true`: Required to correctly handle `X-Forwarded-*` headers

35+- **Session storage**: For production deployments with large tokens due to a lot of claims like AD groups, use `--session-store-type=redis`

36+

37+For provider-specific configuration, see the [OAuth Provider Configuration](../providers/index.md) documentation.

38+

39+:::note

40+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

41+:::

docs/versioned_docs/version-7.14.x/configuration/integrations/kubernetes-dashboard.mdnew file+289

@@ -0,0 +1,289 @@

1+---

2+id: kubernetes-dashboard

3+title: Kubernetes Dashboard

4+---

5+

6+:::warning Deprecated Project

7+Kubernetes Dashboard has been deprecated and discontinued as of January 2025. See the [official announcement](https://github.com/kubernetes/dashboard/commit/0ba796dce6916bb6ca5da5ca0b3ab22cecfd1e18) for more information.

8+

9+You may want to consider alternative solutions such as [Headlamp](./headlamp.md).

10+:::

11+

12+## Kubernetes Dashboard on AKS with Azure Entra ID

13+

14+Integration guide for the deprecated Kubernetes Dashboard, including comprehensive Azure Entra ID configuration on AKS with detailed troubleshooting and RBAC setup.

15+

16+### Architecture

17+

18+```

19+User → Nginx Ingress → OAuth2 Proxy → Entra ID

20+ ↓

21+ Kubernetes Dashboard

22+```

23+

24+The integration flow:

25+1. Unauthenticated requests to Dashboard are intercepted by Nginx Ingress

26+2. Nginx redirects to OAuth2 Proxy for authentication

27+3. OAuth2 Proxy redirects to Entra ID login

28+4. After successful authentication, OAuth2 Proxy receives ID token from Entra ID

29+5. OAuth2 Proxy sets Authorization header with the bearer token

30+6. Nginx forwards the request with token to Kubernetes Dashboard

31+7. Dashboard validates the token and grants access based on AKS RBAC configuration

32+

33+### Prerequisites

34+

35+- AKS cluster with Entra ID integration enabled

36+- Kubernetes Dashboard installed (version 7.x or later)

37+- NGINX Ingress Controller installed

38+- Entra ID App Registration configured with:

39+ - Redirect URI: `https://your-oauth2-domain.com/oauth2/callback`

40+ - API Permissions: `openid`, `email`, `profile`

41+ - Groups claim enabled (if using group-based RBAC)

42+- Users or groups assigned appropriate Kubernetes RBAC permissions

43+

44+### Alpha Configuration Example

45+

46+Using [Alpha Configuration](../alpha_config.md) with the OAuth2 Proxy Helm chart:

47+

48+```yaml

49+alphaConfig:

50+ enabled: true

51+ configData:

52+ providers:

53+ - id: azure-entra

54+ provider: entra-id

55+ clientID: YOUR_CLIENT_ID

56+ clientSecret: YOUR_CLIENT_SECRET

57+ oidcConfig:

58+ issuerURL: https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0

59+ audienceClaims:

60+ - aud

61+ emailClaim: email

62+ groupsClaim: groups

63+ userIDClaim: oid

64+ scope: openid email profile

65+

66+ upstreamConfig:

67+ upstreams:

68+ - id: static

69+ path: /

70+ static: true

71+ staticCode: 200

72+

73+ # Response headers passed to Dashboard via Nginx

74+ injectResponseHeaders:

75+ - name: Authorization

76+ values:

77+ - claim: id_token

78+ prefix: "Bearer "

79+ - name: X-Auth-Request-User

80+ values:

81+ - claim: email

82+ - name: X-Auth-Request-Email

83+ values:

84+ - claim: email

85+ - name: X-Auth-Request-Groups

86+ values:

87+ - claim: groups

88+

89+ server:

90+ BindAddress: "0.0.0.0:4180"

91+

92+extraArgs:

93+ cookie-domain: ".your-domain.com"

94+ whitelist-domain: ".your-domain.com"

95+ email-domain: "*" # Or restrict to your organization

96+ skip-provider-button: true

97+ reverse-proxy: true

98+ pass-authorization-header: true

99+ set-xauthrequest: true

100+

101+sessionStorage:

102+ type: redis

103+

104+redis:

105+ enabled: true

106+ auth:

107+ enabled: true

108+

109+ingress:

110+ enabled: true

111+ className: nginx

112+ hosts:

113+ - OAuth2 Proxy.your-domain.com

114+ path: /oauth2

115+ pathType: Prefix

116+```

117+

118+### Kubernetes Dashboard Ingress

119+

120+**Critical**: The Ingress must include `Authorization` in the `auth-response-headers` annotation:

121+

122+```yaml

123+apiVersion: networking.k8s.io/v1

124+kind: Ingress

125+metadata:

126+ name: kubernetes-dashboard

127+ namespace: kubernetes-dashboard

128+ annotations:

129+ nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

130+ nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

131+

132+ # OAuth2 Proxy authentication

133+ nginx.ingress.kubernetes.io/auth-url: "https://OAuth2 Proxy.your-domain.com/oauth2/auth"

134+ nginx.ingress.kubernetes.io/auth-signin: "https://OAuth2 Proxy.your-domain.com/oauth2/start?rd=$scheme://$best_http_host$request_uri"

135+

136+ # Include Authorization header with bearer token

137+ nginx.ingress.kubernetes.io/auth-response-headers: "Authorization, X-Auth-Request-User, X-Auth-Request-Email"

138+

139+ # Buffer sizes for large tokens (Entra tokens can exceed 4KB)

140+ nginx.ingress.kubernetes.io/proxy-buffer-size: "256k"

141+ nginx.ingress.kubernetes.io/proxy-buffers-number: "4"

142+ nginx.ingress.kubernetes.io/proxy-busy-buffers-size: "256k"

143+spec:

144+ ingressClassName: nginx

145+ tls:

146+ - hosts:

147+ - dashboard.your-domain.com

148+ secretName: dashboard-tls

149+ rules:

150+ - host: dashboard.your-domain.com

151+ http:

152+ paths:

153+ - path: /

154+ pathType: Prefix

155+ backend:

156+ service:

157+ name: kubernetes-dashboard-kong-proxy

158+ port:

159+ number: 443

160+```

161+

162+### RBAC Configuration

163+

164+Assign Kubernetes permissions to Entra ID users or groups.

165+

166+**User-based:**

167+```yaml

168+apiVersion: rbac.authorization.k8s.io/v1

169+kind: ClusterRoleBinding

170+metadata:

171+ name: dashboard-user-admin

172+roleRef:

173+ apiGroup: rbac.authorization.k8s.io

174+ kind: ClusterRole

175+ name: cluster-admin

176+subjects:

177+ - kind: User

178+ name: "user@your-domain.com" # Email from Entra ID token

179+ apiGroup: rbac.authorization.k8s.io

180+```

181+

182+**Group-based (recommended):**

183+```yaml

184+apiVersion: rbac.authorization.k8s.io/v1

185+kind: ClusterRoleBinding

186+metadata:

187+ name: dashboard-admins-group

188+roleRef:

189+ apiGroup: rbac.authorization.k8s.io

190+ kind: ClusterRole

191+ name: cluster-admin

192+subjects:

193+ - kind: Group

194+ name: "YOUR_ENTRA_GROUP_OBJECT_ID" # Entra ID Group Object ID

195+ apiGroup: rbac.authorization.k8s.io

196+```

197+

198+For production, create custom roles with limited permissions instead of using `cluster-admin`.

199+

200+### Troubleshooting

201+

202+**Dashboard still asks for token after authentication**

203+

204+Verify that:

205+1. `injectResponseHeaders` in alphaConfig includes Authorization header with id_token claim

206+2. Dashboard Ingress includes `Authorization` in `auth-response-headers` annotation

207+3. Buffer sizes are sufficient for large tokens (set to 256k as shown above)

208+4. Check OAuth2 Proxy logs for successful token generation: `kubectl logs -n OAuth2 Proxy <pod-name>`

209+

210+**"Unauthorized" or "Invalid token" errors**

211+

212+Common causes:

213+1. User/group not configured in Kubernetes RBAC

214+ - Check: `kubectl get clusterrolebindings | grep <user-email>`

215+2. Token validation failed

216+ - Verify AKS Entra ID integration is enabled

217+ - Check Dashboard logs: `kubectl logs -n kubernetes-dashboard <pod-name>`

218+3. Incorrect OAuth2 Proxy configuration

219+ - Ensure `reverse-proxy: true` is set

220+ - Verify issuer URL matches your tenant

221+

222+**Groups not included in token**

223+

224+To include groups in the token:

225+1. In Entra ID App Registration, go to **Token configuration**

226+2. Add **groups claim** and select security groups

227+3. Or edit the manifest and add: `"groupMembershipClaims": "SecurityGroup"`

228+4. For 200+ groups, ensure scope includes `User.Read` for group overage handling

229+5. Verify groups appear in token: check OAuth2 Proxy logs

230+

231+**Session expires too quickly**

232+

233+Configure cookie expiration:

234+```yaml

235+extraArgs:

236+ cookie-expire: "24h"

237+ cookie-refresh: "1h"

238+```

239+

240+### Using Workload Identity (Passwordless)

241+

242+For production environments, use Workload Identity instead of client secrets:

243+

244+```yaml

245+config:

246+ clientID: "YOUR_CLIENT_ID"

247+ secretKeys: # Exclude client-secret

248+ - client-id

249+ - cookie-secret

250+ cookieSecret: "YOUR_COOKIE_SECRET"

251+

252+serviceAccount:

253+ annotations:

254+ azure.workload.identity/client-id: YOUR_CLIENT_ID

255+ azure.workload.identity/tenant-id: YOUR_TENANT_ID

256+

257+podLabels:

258+ azure.workload.identity/use: "true"

259+

260+alphaConfig:

261+ enabled: true

262+ configData:

263+ providers:

264+ - id: azure-entra

265+ provider: entra-id

266+ clientID: YOUR_CLIENT_ID

267+ oidcConfig:

268+ issuerURL: https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0

269+ # ... other config

270+ entraIdConfig:

271+ federatedTokenAuth: true

272+```

273+

274+This requires:

275+- AKS with OIDC issuer and Workload Identity enabled

276+- Federated identity credential configured in Entra ID App Registration

277+- Service account annotated with `azure.workload.identity/client-id`

278+

279+For detailed Workload Identity setup instructions, see the [Workload Identity section](../providers/ms_entra_id.md#workload-identity) in the Microsoft Entra ID provider documentation.

280+

281+## Integration with Other Providers

282+

283+While this guide focuses on Azure Entra ID, Kubernetes Dashboard can be integrated with other OAuth2 providers supported by OAuth2 Proxy. The key requirements remain the same:

284+

285+1. **Authorization Header**: Pass the bearer token via the `Authorization` header

286+2. **RBAC Configuration**: Configure Kubernetes RBAC for your authentication provider's users/groups

287+3. **Buffer Sizes**: Ensure adequate buffer sizes for tokens (especially important for OIDC providers)

288+

289+For provider-specific configuration examples, see the [OAuth Provider Configuration](../providers/index.md) documentation.

docs/versioned_docs/version-7.14.x/configuration/integrations/nginx.mdnew file+174

@@ -0,0 +1,174 @@

1+---

2+id: nginx

3+title: Nginx

4+---

5+

6+Configure OAuth2 Proxy with Nginx using the `auth_request` directive. Includes examples for both standalone Nginx configurations and Kubernetes ingress-nginx with annotations.

7+

8+**Key features:**

9+- Support for `auth_request` directive

10+- Kubernetes Ingress annotations

11+- Multi-part cookie handling for large tokens

12+- Session refresh support

13+

14+## Configuring for use with the Nginx `auth_request` directive

15+

16+**This option requires `--reverse-proxy` option to be set.**

17+

18+The [Nginx `auth_request` directive](http://nginx.org/en/docs/http/ngx_http_auth_request_module.html) allows Nginx to authenticate requests via the oauth2-proxy's `/auth` endpoint, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the request through. For example:

19+

20+```nginx

21+server {

22+ listen 443 ssl;

23+ server_name ...;

24+ include ssl/ssl.conf;

25+

26+ location /oauth2/ {

27+ proxy_pass http://127.0.0.1:4180;

28+ proxy_set_header Host $host;

29+ proxy_set_header X-Real-IP $remote_addr;

30+ proxy_set_header X-Auth-Request-Redirect $request_uri;

31+ # or, if you are handling multiple domains:

32+ # proxy_set_header X-Auth-Request-Redirect $scheme://$host$request_uri;

33+ }

34+ location = /oauth2/auth {

35+ proxy_pass http://127.0.0.1:4180;

36+ proxy_set_header Host $host;

37+ proxy_set_header X-Real-IP $remote_addr;

38+ proxy_set_header X-Forwarded-Uri $request_uri;

39+ # nginx auth_request includes headers but not body

40+ proxy_set_header Content-Length "";

41+ proxy_pass_request_body off;

42+ }

43+

44+ location / {

45+ auth_request /oauth2/auth;

46+ error_page 401 = @oauth2_signin;

47+

48+ # pass information via X-User and X-Email headers to backend,

49+ # requires running with --set-xauthrequest flag

50+ auth_request_set $user $upstream_http_x_auth_request_user;

51+ auth_request_set $email $upstream_http_x_auth_request_email;

52+ proxy_set_header X-User $user;

53+ proxy_set_header X-Email $email;

54+

55+ # if you enabled --pass-access-token, this will pass the token to the backend

56+ auth_request_set $token $upstream_http_x_auth_request_access_token;

57+ proxy_set_header X-Access-Token $token;

58+

59+ # if you enabled --cookie-refresh, this is needed for it to work with auth_request

60+ auth_request_set $auth_cookie $upstream_http_set_cookie;

61+ add_header Set-Cookie $auth_cookie;

62+

63+ # When using the --set-authorization-header flag, some provider's cookies can exceed the 4kb

64+ # limit and so the OAuth2 Proxy splits these into multiple parts.

65+ # Nginx normally only copies the first `Set-Cookie` header from the auth_request to the response,

66+ # so if your cookies are larger than 4kb, you will need to extract additional cookies manually.

67+ auth_request_set $auth_cookie_name_upstream_1 $upstream_cookie_auth_cookie_name_1;

68+

69+ # Extract the Cookie attributes from the first Set-Cookie header and append them

70+ # to the second part ($upstream_cookie_* variables only contain the raw cookie content)

71+ if ($auth_cookie ~* "(; .*)") {

72+ set $auth_cookie_name_0 $auth_cookie;

73+ set $auth_cookie_name_1 "auth_cookie_name_1=$auth_cookie_name_upstream_1$1";

74+ }

75+

76+ # Send both Set-Cookie headers now if there was a second part

77+ if ($auth_cookie_name_upstream_1) {

78+ add_header Set-Cookie $auth_cookie_name_0;

79+ add_header Set-Cookie $auth_cookie_name_1;

80+ }

81+

82+ proxy_pass http://backend/;

83+ # or "root /path/to/site;" or "fastcgi_pass ..." etc

84+ }

85+

86+ # Named location for handling OAuth2 sign-in redirects

87+ # This ensures the browser receives a proper 302 redirect that it will follow

88+ location @oauth2_signin {

89+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

90+ }

91+}

92+```

93+

94+### Understanding the `error_page` redirect pattern

95+

96+The `auth_request` directive expects the authentication endpoint (`/oauth2/auth`) to return:

97+- **2xx**: Request is authenticated, allow access

98+- **401 or 403**: Request is not authenticated, deny access

99+

100+When a 401 is returned, nginx triggers the `error_page` directive. The recommended pattern uses a **named location** (`@oauth2_signin`) that returns a proper **302 redirect**:

101+

102+```nginx

103+error_page 401 = @oauth2_signin;

104+

105+location @oauth2_signin {

106+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

107+}

108+```

109+

110+:::warning Avoid `error_page 401 =403` with sign_in

111+Some older configurations use `error_page 401 =403 /oauth2/sign_in`. While this works for displaying the sign-in page, it returns a **403 status code** with a `Location` header. Browsers do not automatically follow redirects on 403 responses, which can cause issues when using `--skip-provider-button=true` (users see a "Found." link instead of being automatically redirected).

112+

113+The named location pattern above ensures the browser receives a standard **302 redirect** that works correctly with all oauth2-proxy configurations.

114+:::

115+

116+### Browser vs API Routes

117+

118+:::important When to use redirects

119+Redirecting authentication failures (302 to `/oauth2/sign_in`) should **only be used for browser-facing routes**. API or machine clients should receive a plain 401/403 response without redirect.

120+:::

121+

122+#### Browser-facing routes (HTML, UI)

123+

124+For interactive browser routes where users should be redirected to sign in:

125+

126+```nginx

127+location / {

128+ auth_request /oauth2/auth;

129+ error_page 401 = @oauth2_signin;

130+ proxy_pass http://backend/;

131+}

132+

133+location @oauth2_signin {

134+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

135+}

136+```

137+

138+#### API / Machine routes (no redirect)

139+

140+For API endpoints where clients expect a 401/403 status code (not a redirect):

141+

142+```nginx

143+location /api/ {

144+ auth_request /oauth2/auth;

145+ error_page 401 =401; # Pass through the 401 status

146+ proxy_pass http://backend/;

147+}

148+```

149+

150+This ensures:

151+- ✅ Browsers get a redirect and smooth login flow

152+- ✅ API clients fail fast with appropriate HTTP status codes

153+- ✅ `/oauth2/auth` remains a pure boolean oracle (2xx/401)

154+

155+When you use ingress-nginx in Kubernetes, you can configure the same behavior with the following annotations on your Ingress resource:

156+

157+```yaml

158+nginx.ingress.kubernetes.io/auth-url: "https://<oauth2-proxy-fqdn>/oauth2/auth"

159+nginx.ingress.kubernetes.io/auth-signin: "https://<oauth2-proxy-fqdn>/oauth2/start?rd=$escaped_request_uri"

160+```

161+

162+This minimal configuration works for standard authentication flows. Lua/cookie handling is only needed for advanced scenarios (e.g., multi-part cookies, custom session logic). See the official ingress-nginx example: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/.

163+

164+It is recommended to use `--session-store-type=redis` when expecting large sessions/OIDC tokens (_e.g._ with MS Azure).

165+

166+:::tip Kubernetes Dashboard with Azure Entra ID

167+For a complete example of integrating oauth2-proxy with Kubernetes Dashboard on AKS using Azure Entra ID, including RBAC configuration and troubleshooting, see the [Kubernetes Dashboard on AKS](../providers/ms_entra_id.md#kubernetes-dashboard-on-aks) section in the Microsoft Entra ID provider documentation.

168+:::

169+

170+You have to substitute *name* with the actual cookie name you configured via --cookie-name parameter. If you don't set a custom cookie name the variable should be "$upstream_cookie__oauth2_proxy_1" instead of "$upstream_cookie_name_1" and the new cookie-name should be "_oauth2_proxy_1=" instead of "name_1=".

171+

172+:::note

173+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

174+:::

docs/versioned_docs/version-7.14.x/configuration/integrations/traefik.mdnew file+192

@@ -0,0 +1,192 @@

1+---

2+id: traefik

3+title: Traefik

4+---

5+

6+Set up OAuth2 Proxy with Traefik v2 using the `ForwardAuth` middleware. Includes examples for both error-based redirects and static upstream configurations.

7+

8+**Key features:**

9+- ForwardAuth middleware integration

10+- Error middleware for 401 redirects

11+- Static upstream configuration (202 responses)

12+- Dynamic file configuration examples

13+

14+

15+## Configuring for use with the Traefik (v2) `ForwardAuth` middleware

16+

17+**This option requires `--reverse-proxy` option to be set.**

18+

19+### ForwardAuth with 401 errors middleware

20+

21+The [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) allows Traefik to authenticate requests via the oauth2-proxy's `/oauth2/auth` endpoint on every request, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the whole request through. For example, on Dynamic File (YAML) Configuration:

22+

23+```yaml

24+http:

25+ routers:

26+ a-service:

27+ rule: "Host(`a-service.example.com`)"

28+ service: a-service-backend

29+ middlewares:

30+ - oauth-errors

31+ - oauth-auth

32+ tls:

33+ certResolver: default

34+ domains:

35+ - main: "example.com"

36+ sans:

37+ - "*.example.com"

38+ oauth:

39+ rule: "Host(`a-service.example.com`, `oauth.example.com`) && PathPrefix(`/oauth2/`)"

40+ middlewares:

41+ - auth-headers

42+ service: oauth-backend

43+ tls:

44+ certResolver: default

45+ domains:

46+ - main: "example.com"

47+ sans:

48+ - "*.example.com"

49+

50+ services:

51+ a-service-backend:

52+ loadBalancer:

53+ servers:

54+ - url: http://172.16.0.2:7555

55+ oauth-backend:

56+ loadBalancer:

57+ servers:

58+ - url: http://172.16.0.1:4180

59+

60+ middlewares:

61+ auth-headers:

62+ headers:

63+ sslRedirect: true

64+ stsSeconds: 315360000

65+ browserXssFilter: true

66+ contentTypeNosniff: true

67+ forceSTSHeader: true

68+ sslHost: example.com

69+ stsIncludeSubdomains: true

70+ stsPreload: true

71+ frameDeny: true

72+ oauth-auth:

73+ forwardAuth:

74+ address: https://oauth.example.com/oauth2/auth

75+ trustForwardHeader: true

76+ oauth-errors:

77+ errors:

78+ status:

79+ - "401-403"

80+ service: oauth-backend

81+ query: "/oauth2/sign_in?rd={url}"

82+ statusRewrites:

83+ "401": 302

84+```

85+

86+:::info Troubleshooting: Browser shows "Found." instead of redirecting

87+When using the Errors middleware without `statusRewrites`, the redirect response from oauth2-proxy can be served within the original 401/403 status context. This causes some browsers to display a "Found." link instead of automatically following the redirect to the identity provider.

88+

89+Adding `statusRewrites` to rewrite `401 -> 302` ensures the browser treats the response as a proper redirect and follows it automatically.

90+:::

91+

92+### ForwardAuth with static upstreams configuration

93+

94+Redirect to sign_in functionality provided without the use of `errors` middleware with [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) pointing to oauth2-proxy service's `/` endpoint

95+

96+**Following options need to be set on `oauth2-proxy`:**

97+- `--upstream=static://202`: Configures a static response for authenticated sessions

98+- `--reverse-proxy=true`: Enables the use of `X-Forwarded-*` headers to determine redirects correctly

99+

100+```yaml

101+http:

102+ routers:

103+ a-service-route-1:

104+ rule: "Host(`a-service.example.com`, `b-service.example.com`) && PathPrefix(`/`)"

105+ service: a-service-backend

106+ middlewares:

107+ - oauth-auth-redirect # redirects all unauthenticated to oauth2 signin

108+ tls:

109+ certResolver: default

110+ domains:

111+ - main: "example.com"

112+ sans:

113+ - "*.example.com"

114+ a-service-route-2:

115+ rule: "Host(`a-service.example.com`) && PathPrefix(`/no-auto-redirect`)"

116+ service: a-service-backend

117+ middlewares:

118+ - oauth-auth-wo-redirect # unauthenticated session will return a 401

119+ tls:

120+ certResolver: default

121+ domains:

122+ - main: "example.com"

123+ sans:

124+ - "*.example.com"

125+ services-oauth2-route:

126+ rule: "Host(`a-service.example.com`, `b-service.example.com`) && PathPrefix(`/oauth2/`)"

127+ middlewares:

128+ - auth-headers

129+ service: oauth-backend

130+ tls:

131+ certResolver: default

132+ domains:

133+ - main: "example.com"

134+ sans:

135+ - "*.example.com"

136+ oauth2-proxy-route:

137+ rule: "Host(`oauth.example.com`) && PathPrefix(`/`)"

138+ middlewares:

139+ - auth-headers

140+ service: oauth-backend

141+ tls:

142+ certResolver: default

143+ domains:

144+ - main: "example.com"

145+ sans:

146+ - "*.example.com"

147+

148+ services:

149+ a-service-backend:

150+ loadBalancer:

151+ servers:

152+ - url: http://172.16.0.2:7555

153+ b-service-backend:

154+ loadBalancer:

155+ servers:

156+ - url: http://172.16.0.3:7555

157+ oauth-backend:

158+ loadBalancer:

159+ servers:

160+ - url: http://172.16.0.1:4180

161+

162+ middlewares:

163+ auth-headers:

164+ headers:

165+ sslRedirect: true

166+ stsSeconds: 315360000

167+ browserXssFilter: true

168+ contentTypeNosniff: true

169+ forceSTSHeader: true

170+ sslHost: example.com

171+ stsIncludeSubdomains: true

172+ stsPreload: true

173+ frameDeny: true

174+ oauth-auth-redirect:

175+ forwardAuth:

176+ address: https://oauth.example.com/

177+ trustForwardHeader: true

178+ authResponseHeaders:

179+ - X-Auth-Request-Access-Token

180+ - Authorization

181+ oauth-auth-wo-redirect:

182+ forwardAuth:

183+ address: https://oauth.example.com/oauth2/auth

184+ trustForwardHeader: true

185+ authResponseHeaders:

186+ - X-Auth-Request-Access-Token

187+ - Authorization

188+```

189+

190+:::note

191+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

192+:::

docs/versioned_docs/version-7.14.x/configuration/overview.mdnew file+407

@@ -0,0 +1,407 @@

1+---

2+id: overview

3+title: Overview

4+---

5+

6+`oauth2-proxy` can be configured via [command line options](#command-line-options), [environment variables](#environment-variables) or [config file](#config-file) (in decreasing order of precedence, i.e. command line options will overwrite environment variables and environment variables will overwrite configuration file settings).

7+

8+## Generating a Cookie Secret

9+

10+To generate a strong cookie secret use one of the below commands:

11+

12+import Tabs from '@theme/Tabs';

13+import TabItem from '@theme/TabItem';

14+

15+<Tabs defaultValue="python">

16+ <TabItem value="python" label="Python">

17+

18+```shell

19+python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())'

20+```

21+

22+ </TabItem>

23+ <TabItem value="bash" label="Bash">

24+

25+```shell

26+dd if=/dev/urandom bs=32 count=1 2>/dev/null | base64 | tr -d -- '\n' | tr -- '+/' '-_' ; echo

27+```

28+

29+ </TabItem>

30+ <TabItem value="openssl" label="OpenSSL">

31+

32+```shell

33+openssl rand -base64 32 | tr -- '+/' '-_'

34+```

35+

36+ </TabItem>

37+ <TabItem value="powershell" label="PowerShell">

38+

39+```powershell

40+# Add System.Web assembly to session, just in case

41+Add-Type -AssemblyName System.Web

42+[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes([System.Web.Security.Membership]::GeneratePassword(32,4))).Replace("+","-").Replace("/","_")

43+```

44+

45+ </TabItem>

46+ <TabItem value="terraform" label="Terraform">

47+

48+```hcl

49+# Valid 32 Byte Base64 URL encoding set that will decode to 24 []byte AES-192 secret

50+resource "random_password" "cookie_secret" {

51+ length = 32

52+ override_special = "-_"

53+}

54+```

55+

56+ </TabItem>

57+</Tabs>

58+

59+## Config File

60+

61+Every command line argument can be specified in a config file by replacing hyphens (-) with underscores (\_). If the argument can be specified multiple times, the config option should be plural (trailing s).

62+

63+An example [oauth2-proxy.cfg](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/oauth2-proxy.cfg.example) config file is in the contrib directory. It can be used by specifying `--config=/etc/oauth2-proxy.cfg`

64+

65+## Config Options

66+

67+### Command Line Options

68+

69+| Flag | Description |

70+| ----------- | -------------------- |

71+| `--config` | path to config file |

72+| `--version` | print version string |

73+

74+

75+### General Provider Options

76+

77+Provider specific options can be found on their respective subpages.

78+

79+| Flag / Config Field | Type | Description | Default |

80+| --------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |

81+| flag: `--acr-values`<br/>toml: `acr_values` | string | optional, see [docs](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html#acrValues) | `""` |

82+| flag: `--allowed-group`<br/>toml: `allowed_groups` | string \| list | Restrict login to members of a group or list of groups. Furthermore, if you aren't setting the `scope` and use `allowed_groups` with the generic OIDC provider the scope `groups` gets added implicitly. | |

83+| flag: `--approval-prompt`<br/>toml: `approval_prompt` | string | OAuth approval_prompt | `"force"` |

84+| flag: `--backend-logout-url`<br/>toml: `backend_logout_url` | string | URL to perform backend logout, if you use `{id_token}` in the url it will be replaced by the actual `id_token` of the user session | |

85+| flag: `--client-id`<br/>toml: `client_id` | string | the OAuth Client ID, e.g. `"123456.apps.googleusercontent.com"` | |

86+| flag: `--client-secret-file`<br/>toml: `client_secret_file` | string | the file with OAuth Client Secret. The file must contain the secret only, with no trailing newline | |

87+| flag: `--client-secret`<br/>toml: `client_secret` | string | the OAuth Client Secret | |

88+| flag: `--code-challenge-method`<br/>toml: `code_challenge_method` | string | use PKCE code challenges with the specified method. Either 'plain' or 'S256' (recommended) | |

89+| flag: `--insecure-oidc-allow-unverified-email`<br/>toml: `insecure_oidc_allow_unverified_email` | bool | don't fail if an email address in an id_token is not verified | false |

90+| flag: `--insecure-oidc-skip-issuer-verification`<br/>toml: `insecure_oidc_skip_issuer_verification` | bool | allow the OIDC issuer URL to differ from the expected (currently required for Azure multi-tenant compatibility) | false |

91+| flag: `--insecure-oidc-skip-nonce`<br/>toml: `insecure_oidc_skip_nonce` | bool | skip verifying the OIDC ID Token's nonce claim | true |

92+| flag: `--jwt-key-file`<br/>toml: `jwt_key_file` | string | path to the private key file in PEM format used to sign the JWT so that you can say something like `--jwt-key-file=/etc/ssl/private/jwt_signing_key.pem`: required by login.gov | |

93+| flag: `--jwt-key`<br/>toml: `jwt_key` | string | private key in PEM format used to sign JWT, so that you can say something like `--jwt-key="${OAUTH2_PROXY_JWT_KEY}"`: required by login.gov | |

94+| flag: `--login-url`<br/>toml: `login_url` | string | Authentication endpoint | |

95+| flag: `--auth-request-response-mode`<br/>toml: `auth-request-response-mode` | string | Response mode to ask for during authentication request | |

96+| flag: `--oidc-audience-claim`<br/>toml: `oidc_audience_claims` | string | which OIDC claim contains the audience | `"aud"` |

97+| flag: `--oidc-email-claim`<br/>toml: `oidc_email_claim` | string | which OIDC claim contains the user's email | `"email"` |

98+| flag: `--oidc-extra-audience`<br/>toml: `oidc_extra_audiences` | string \| list | additional audiences which are allowed to pass verification | `"[]"` |

99+| flag: `--oidc-groups-claim`<br/>toml: `oidc_groups_claim` | string | which OIDC claim contains the user groups | `"groups"` |

100+| flag: `--oidc-issuer-url`<br/>toml: `oidc_issuer_url` | string | the OpenID Connect issuer URL, e.g. `"https://accounts.google.com"` | |

101+| flag: `--oidc-jwks-url`<br/>toml: `oidc_jwks_url` | string | OIDC JWKS URI for token verification; required if OIDC discovery is disabled and public key files are not provided | |

102+| flag: `--oidc-public-key-file`<br/>toml: `oidc_public_key_files` | string | Path to public key file in PEM format to use for verifying JWT tokens (may be given multiple times). Required if OIDC discovery is disabled na JWKS URL isn't provided | string \| list |

103+| flag: `--profile-url`<br/>toml: `profile_url` | string | Profile access endpoint | |

104+| flag: `--prompt`<br/>toml: `prompt` | string | [OIDC prompt](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest); if present, `approval-prompt` is ignored | `""` |

105+| flag: `--provider-ca-file`<br/>toml: `provider_ca_files` | string \| list | Paths to CA certificates that should be used when connecting to the provider. If not specified, the default Go trust sources are used instead. |

106+| flag: `--provider-display-name`<br/>toml: `provider_display_name` | string | Override the provider's name with the given string; used for the sign-in page | (depends on provider) |

107+| flag: `--provider`<br/>toml: `provider` | string | OAuth provider | google |

108+| flag: `--pubjwk-url`<br/>toml: `pubjwk_url` | string | JWK pubkey access endpoint: required by login.gov | |

109+| flag: `--redeem-url`<br/>toml: `redeem_url` | string | Token redemption endpoint | |

110+| flag: `--scope`<br/>toml:`scope` | string | OAuth scope specification. Every provider has a default list of scopes which will be used in case no scope is configured. | |

111+| flag: `--skip-claims-from-profile-url`<br/>toml: `skip_claims_from_profile_url` | bool | skip request to Profile URL for resolving claims not present in id_token | false |

112+| flag: `--skip-oidc-discovery`<br/>toml: `skip_oidc_discovery` | bool | bypass OIDC endpoint discovery. `--login-url`, `--redeem-url` and `--oidc-jwks-url` must be configured in this case | false |

113+| flag: `--use-system-trust-store`<br/>toml: `use_system_trust_store` | bool | Determines if `provider-ca-file` files and the system trust store are used. If set to true, your custom CA files and the system trust store are used otherwise only your custom CA files. | false |

114+| flag: `--validate-url`<br/>toml: `validate_url` | string | Access token validation endpoint | |

115+

116+### Cookie Options

117+

118+| Flag / Config Field | Type | Description | Default |

119+| --------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |

120+| flag: `--cookie-csrf-expire`<br/>toml: `cookie_csrf_expire` | duration | expire timeframe for CSRF cookie | 15m |

121+| flag: `--cookie-csrf-per-request`<br/>toml:`cookie_csrf_per_request` | bool | Enable having different CSRF cookies per request, making it possible to have parallel requests. | false |

122+| flag: `--cookie-csrf-per-request-limit`<br/>toml: `cookie_csrf_per_request_limit` | int | Sets a limit on the number of CSRF requests cookies that oauth2-proxy will create. The oldest cookie will be removed. Useful if users end up with 431 Request headers too large status codes. Only effective if --cookie-csrf-per-request is true | "infinite" |

123+| flag: `--cookie-domain`<br/>toml: `cookie_domains` | string \| list | Optional cookie domains to force cookies to (e.g. `.yourcompany.com`). The longest domain matching the request's host will be used (or the shortest cookie domain if there is no match). | |

124+| flag: `--cookie-expire`<br/>toml: `cookie_expire` | duration | expire timeframe for cookie. If set to 0, cookie becomes a session-cookie which will expire when the browser is closed. | 168h0m0s |

125+| flag: `--cookie-httponly`<br/>toml: `cookie_httponly` | bool | set HttpOnly cookie flag | true |

126+| flag: `--cookie-name`<br/>toml: `cookie_name` | string | the name of the cookie that the oauth_proxy creates. Should be changed to use a [cookie prefix](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes) (`__Host-` or `__Secure-`) if `--cookie-secure` is set. | `"_oauth2_proxy"` |

127+| flag: `--cookie-path`<br/>toml: `cookie_path` | string | an optional cookie path to force cookies to (e.g. `/poc/`) | `"/"` |

128+| flag: `--cookie-refresh`<br/>toml: `cookie_refresh` | duration | refresh the cookie after this duration; `0` to disable; not supported by all providers&nbsp;[^1] | |

129+| flag: `--cookie-samesite`<br/>toml: `cookie_samesite` | string | set SameSite cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`). | `""` |

130+| flag: `--cookie-secret`<br/>toml: `cookie_secret` | string | the seed string for secure cookies (optionally base64 encoded) | |

131+| flag: `--cookie-secret-file`<br/>toml: `cookie_secret_file` | string | File containing the cookie secret (must be raw binary, exactly 16, 24, or 32 bytes). Use dd if=/dev/urandom bs=32 count=1 > cookie.secret to generate | |

132+| flag: `--cookie-secure`<br/>toml: `cookie_secure` | bool | set [secure (HTTPS only) cookie flag](https://owasp.org/www-community/controls/SecureFlag) | true |

133+

134+[^1]: The following providers support `--cookie-refresh`: ADFS, Azure, GitLab, Google, Keycloak and all other Identity Providers which support the full [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens)

135+

136+### Header Options

137+

138+| Flag / Config Field | Type | Description | Default |

139+| ------------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

140+| flag: `--basic-auth-password`<br/>toml: `basic_auth_password` | string | the password to set when passing the HTTP Basic Auth header | |

141+| flag: `--set-xauthrequest`<br/>toml: `set_xauthrequest` | bool | set X-Auth-Request-User, X-Auth-Request-Groups, X-Auth-Request-Email and X-Auth-Request-Preferred-Username response headers (useful in Nginx auth_request mode). When used with `--pass-access-token`, X-Auth-Request-Access-Token is added to response headers. | false |

142+| flag: `--set-authorization-header`<br/>toml: `set_authorization_header` | bool | set Authorization Bearer response header (useful in Nginx auth_request mode) | false |

143+| flag: `--set-basic-auth`<br/>toml: `set_basic_auth` | bool | set HTTP Basic Auth information in response (useful in Nginx auth_request mode) | false |

144+| flag: `--skip-auth-strip-headers`<br/>toml: `skip_auth_strip_headers` | bool | strips `X-Forwarded-*` style authentication headers & `Authorization` header if they would be set by oauth2-proxy | true |

145+| flag: `--pass-access-token`<br/>toml: `pass_access_token` | bool | pass OAuth access_token to upstream via X-Forwarded-Access-Token header. When used with `--set-xauthrequest` this adds the X-Auth-Request-Access-Token header to the response | false |

146+| flag: `--pass-authorization-header`<br/>toml: `pass_authorization_header` | bool | pass OIDC IDToken to upstream via Authorization Bearer header | false |

147+| flag: `--pass-basic-auth`<br/>toml: `pass_basic_auth` | bool | pass HTTP Basic Auth, X-Forwarded-User, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream | true |

148+| flag: `--prefer-email-to-user`<br/>toml: `prefer_email_to_user` | bool | Prefer to use the Email address as the Username when passing information to upstream. Will only use Username if Email is unavailable, e.g. htaccess authentication. Used in conjunction with `--pass-basic-auth` and `--pass-user-headers` | false |

149+| flag: `--pass-user-headers`<br/>toml: `pass_user_headers` | bool | pass X-Forwarded-User, X-Forwarded-Groups, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream | true |

150+

151+### Logging Options

152+

153+| Flag / Config Field | Type | Description | Default |

154+| --------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------- | --------------------------------------------------- |

155+| flag: `--auth-logging-format`<br/>toml: `auth_logging_format` | string | Template for authentication log lines | see [Logging Configuration](#logging-configuration) |

156+| flag: `--auth-logging`<br/>toml: `auth_logging` | bool | Log authentication attempts | true |

157+| flag: `--errors-to-info-log`<br/>toml: `errors_to_info_log` | bool | redirects error-level logging to default log channel instead of stderr | false |

158+| flag: `--exclude-logging-path`<br/>toml: `exclude_logging_paths` | string | comma separated list of paths to exclude from logging, e.g. `"/ping,/path2"` | `""` (no paths excluded) |

159+| flag: `--logging-compress`<br/>toml: `logging_compress` | bool | Should rotated log files be compressed using gzip | false |

160+| flag: `--logging-filename`<br/>toml: `logging_filename` | string | File to log requests to, empty for `stdout` | `""` (stdout) |

161+| flag: `--logging-local-time`<br/>toml: `logging_local_time` | bool | Use local time in log files and backup filenames instead of UTC | true (local time) |

162+| flag: `--logging-max-age`<br/>toml: `logging_max_age` | int | Maximum number of days to retain old log files | 7 |

163+| flag: `--logging-max-backups`<br/>toml: `logging_max_backups` | int | Maximum number of old log files to retain; 0 to disable | 0 |

164+| flag: `--logging-max-size`<br/>toml: `logging_max_size` | int | Maximum size in megabytes of the log file before rotation | 100 |

165+| flag: `--request-id-header`<br/>toml: `request_id_header` | string | Request header to use as the request ID in logging | X-Request-Id |

166+| flag: `--request-logging-format`<br/>toml: `request_logging_format` | string | Template for request log lines | see [Logging Configuration](#logging-configuration) |

167+| flag: `--request-logging`<br/>toml: `request_logging` | bool | Log requests | true |

168+| flag: `--silence-ping-logging`<br/>toml: `silence_ping_logging` | bool | disable logging of requests to ping & ready endpoints | false |

169+| flag: `--standard-logging-format`<br/>toml: `standard_logging_format` | string | Template for standard log lines | see [Logging Configuration](#logging-configuration) |

170+| flag: `--standard-logging`<br/>toml: `standard_logging` | bool | Log standard runtime information | true |

171+

172+### Page Template Options

173+

174+| Flag / Config Field | Type | Description | Default |

175+| ----------------------------------------------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------- | ------- |

176+| flag: `--banner`<br/>toml: `banner` | string | custom (html) banner string. Use `"-"` to disable default banner. | |

177+| flag: `--custom-sign-in-logo`<br/>toml: `custom_sign_in_logo` | string | path or a URL to an custom image for the sign_in page logo. Use `"-"` to disable default logo. |

178+| flag: `--custom-templates-dir`<br/>toml: `custom_templates_dir` | string | path to custom html templates | |

179+| flag: `--display-htpasswd-form`<br/>toml: `display_htpasswd_form` | bool | display username / password login form if an htpasswd file is provided | true |

180+| flag: `--footer`<br/>toml: `footer` | string | custom (html) footer string. Use `"-"` to disable default footer. (Can be used to obfuscate the version) | |

181+| flag: `--show-debug-on-error`<br/>toml: `show_debug_on_error` | bool | show detailed error information on error pages (WARNING: this may contain sensitive information - do not use in production) | false |

182+

183+### Probe Options

184+

185+| Flag / Config Field | Type | Description | Default |

186+| ------------------------------------------------------- | ------ | ---------------------------------------------------------- | ----------------------------- |

187+| flag: `--ping-path`<br/>toml: `ping_path` | string | the ping endpoint that can be used for basic health checks | `"/ping"` |

188+| flag: `--ping-user-agent`<br/>toml: `ping_user_agent` | string | a User-Agent that can be used for basic health checks | `""` (don't check user agent) |

189+| flag: `--ready-path`<br/>toml: `ready_path` | string | the ready endpoint that can be used for deep health checks | `"/ready"` |

190+| flag: `--gcp-healthchecks`<br/>toml: `gcp_healthchecks` | bool | Enable GCP/GKE healthcheck endpoints (deprecated) | false |

191+

192+### Proxy Options

193+

194+| Flag / Config Field | Type | Description | Default |

195+| ----------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |

196+| flag: `--allow-query-semicolons`<br/>toml: `allow_query_semicolons` | bool | allow the use of semicolons in query args ([required for some legacy applications](https://github.com/golang/go/issues/25192)) | `false` |

197+| flag: `--api-route`<br/>toml: `api_routes` | string \| list | Requests to these paths must already be authenticated with a cookie, or a JWT if `--skip-jwt-bearer-tokens` is set. No redirect to login will be done. Return 401 if not. Format: path_regex | |

198+| flag: `--authenticated-emails-file`<br/>toml: `authenticated_emails_file` | string | authenticate against emails via file (one per line) | |

199+| flag: `--bearer-token-login-fallback`<br/>toml: `bearer_token_login_fallback` | bool | if `--skip-jwt-bearer-tokens` is set, if a request includes an invalid JWT (expired, malformed, missing required audiences, etc), fall back to normal login redirect as if the token were not sent at all. If false, respond 403 | true |

200+| flag: `--email-domain`<br/>toml: `email_domains` | string \| list | authenticate emails with the specified domain (may be given multiple times). Use `*` to authenticate any email | |

201+| flag: `--encode-state`<br/>toml: `encode_state` | bool | encode the state parameter as UrlEncodedBase64 | false |

202+| flag: `--extra-jwt-issuers`<br/>toml: `extra_jwt_issuers` | string | if `--skip-jwt-bearer-tokens` is set, a list of extra JWT `issuer=audience` (see a token's `iss`, `aud` fields) pairs (where the issuer URL has a `.well-known/openid-configuration` or a `.well-known/jwks.json`) | |

203+| flag: `--force-https`<br/>toml: `force_https` | bool | enforce https redirect | `false` |

204+| flag: `--force-json-errors`<br/>toml: `force_json_errors` | bool | force JSON errors instead of HTTP error pages or redirects | `false` |

205+| flag: `--htpasswd-file`<br/>toml: `htpasswd_file` | string | additionally authenticate against a htpasswd file. Entries must be created with `htpasswd -B` for bcrypt encryption | |

206+| flag: `--htpasswd-user-group`<br/>toml: `htpasswd_user_groups` | string \| list | the groups to be set on sessions for htpasswd users | |

207+| flag: `--proxy-prefix`<br/>toml: `proxy_prefix` | string | the url root path that this proxy should be nested under (e.g. /`<oauth2>/sign_in`) | `"/oauth2"` |

208+| flag: `--real-client-ip-header`<br/>toml: `real_client_ip_header` | string | Header used to determine the real IP of the client, requires `--reverse-proxy` to be set (one of: X-Forwarded-For, X-Real-IP, X-ProxyUser-IP, X-Envoy-External-Address, or CF-Connecting-IP) | X-Real-IP |

209+| flag: `--redirect-url`<br/>toml: `redirect_url` | string | the OAuth Redirect URL, e.g. `"https://internalapp.yourcompany.com/oauth2/callback"` | |

210+| flag: `--relative-redirect-url`<br/>toml: `relative_redirect_url` | bool | allow relative OAuth Redirect URL.` | false |

211+| flag: `--reverse-proxy`<br/>toml: `reverse_proxy` | bool | are we running behind a reverse proxy, controls whether headers like X-Real-IP are accepted and allows X-Forwarded-\{Proto,Host,Uri\} headers to be used on redirect selection | false |

212+| flag: `--signature-key`<br/>toml: `signature_key` | string | GAP-Signature request signature key (algorithm:secretkey) | |

213+| flag: `--skip-auth-preflight`<br/>toml: `skip_auth_preflight` | bool | will skip authentication for OPTIONS requests | false |

214+| flag: `--skip-auth-regex`<br/>toml: `skip_auth_regex` | string \| list | (DEPRECATED for `--skip-auth-route`) bypass authentication for requests paths that match (may be given multiple times) | |

215+| flag: `--skip-auth-route`<br/>toml: `skip_auth_routes` | string \| list | bypass authentication for requests that match the method & path. Format: method=path_regex OR method!=path_regex. For all methods: path_regex OR !=path_regex | |

216+| flag: `--skip-jwt-bearer-tokens`<br/>toml: `skip_jwt_bearer_tokens` | bool | will skip requests that have verified JWT bearer tokens (the token must have [`aud`](https://en.wikipedia.org/wiki/JSON_Web_Token#Standard_fields) that matches this client id or one of the extras from `extra-jwt-issuers`) | false |

217+| flag: `--skip-provider-button`<br/>toml: `skip_provider_button` | bool | will skip sign-in-page to directly reach the next step: oauth/start | false |

218+| flag: `--ssl-insecure-skip-verify`<br/>toml: `ssl_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS providers | false |

219+| flag: `--trusted-ip`<br/>toml: `trusted_ips` | string \| list | list of IPs or CIDR ranges to allow to bypass authentication (may be given multiple times). When combined with `--reverse-proxy` and optionally `--real-client-ip-header` this will evaluate the trust of the IP stored in an HTTP header by a reverse proxy rather than the layer-3/4 remote address. WARNING: trusting IPs has inherent security flaws, especially when obtaining the IP address from an HTTP header (reverse-proxy mode). Use this option only if you understand the risks and how to manage them. | |

220+| flag: `--whitelist-domain`<br/>toml: `whitelist_domains` | string \| list | allowed domains for redirection after authentication. Prefix domain with a `.` or a `*.` to allow subdomains (e.g. `.example.com`, `*.example.com`)&nbsp;[^2] | |

221+

222+[^2]: When using the `whitelist-domain` option, any domain prefixed with a `.` or a `*.` will allow any subdomain of the specified domain as a valid redirect URL. By default, only empty ports are allowed. This translates to allowing the default port of the URL's protocol (80 for HTTP, 443 for HTTPS, etc.) since browsers omit them. To allow only a specific port, add it to the whitelisted domain: `example.com:8080`. To allow any port, use `*`: `example.com:*`.

223+

224+### Server Options

225+

226+| Flag / Config Field | Type | Description | Default |

227+| ------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |

228+| flag: `--http-address`<br/>toml: `http_address` | string | `[http://]<addr>:<port>` or `unix://<path>` or `fd:<int>` (case insensitive) to listen on for HTTP clients. Square brackets are required for ipv6 address, e.g. `http://[::1]:4180` | `"127.0.0.1:4180"` |

229+| flag: `--https-address`<br/>toml: `https_address` | string | `[https://]<addr>:<port>` to listen on for HTTPS clients. Square brackets are required for ipv6 address, e.g. `https://[::1]:443` | `":443"` |

230+| flag: `--metrics-address`<br/>toml: `metrics_address` | string | the address prometheus metrics will be scraped from | `""` |

231+| flag: `--metrics-secure-address`<br/>toml: `metrics_secure_address` | string | the address prometheus metrics will be scraped from if using HTTPS | `""` |

232+| flag: `--metrics-tls-cert-file`<br/>toml: `metrics_tls_cert_file` | string | path to certificate file for secure metrics server | `""` |

233+| flag: `--metrics-tls-key-file`<br/>toml: `metrics_tls_key_file` | string | path to private key file for secure metrics server | `""` |

234+| flag: `--tls-cert-file`<br/>toml: `tls_cert_file` | string | path to certificate file | |

235+| flag: `--tls-key-file`<br/>toml: `tls_key_file` | string | path to private key file | |

236+| flag: `--tls-cipher-suite`<br/>toml: `tls_cipher_suites` | string \| list | Restricts TLS cipher suites used by server to those listed (e.g. TLS_RSA_WITH_RC4_128_SHA) (may be given multiple times). If not specified, the default Go safe cipher list is used. List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). | |

237+| flag: `--tls-min-version`<br/>toml: `tls_min_version` | string | minimum TLS version that is acceptable, either `"TLS1.2"` or `"TLS1.3"` | `"TLS1.2"` |

238+

239+### Session Options

240+

241+| Flag / Config Field | Type | Description | Default |

242+| ----------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

243+| flag: `--session-cookie-minimal`<br/>toml: `session_cookie_minimal` | bool | strip OAuth tokens from cookie session stores if they aren't needed (cookie session store only) | false |

244+| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

245+| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

246+| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

247+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. |

248+| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

249+| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

250+| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

251+| flag: `--redis-sentinel-master-name`<br/>toml: `redis_sentinel_master_name` | string | Redis sentinel master name. Used in conjunction with `--redis-use-sentinel` | |

252+| flag: `--redis-sentinel-connection-urls`<br/>toml: `redis_sentinel_connection_urls` | string \| list | List of Redis sentinel connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-sentinel` | |

253+| flag: `--redis-use-cluster`<br/>toml: `redis_use_cluster` | bool | Connect to redis cluster. Must set `--redis-cluster-connection-urls` to use this feature | false |

254+| flag: `--redis-use-sentinel`<br/>toml: `redis_use_sentinel` | bool | Connect to redis via sentinels. Must set `--redis-sentinel-master-name` and `--redis-sentinel-connection-urls` to use this feature | false |

255+| flag: `--redis-connection-idle-timeout`<br/>toml: `redis_connection_idle_timeout` | int | Redis connection idle timeout seconds. If Redis [timeout](https://redis.io/docs/reference/clients/#client-timeouts) option is set to non-zero, the `--redis-connection-idle-timeout` must be less than Redis timeout option. Example: if either redis.conf includes `timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14` | 0 |

256+

257+### Upstream Options

258+

259+| Flag / Config Field | Type | Description | Default |

260+| ----------------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- |

261+| flag: `--flush-interval`<br/>toml: `flush_interval` | duration | period between flushing response buffers when streaming responses | `"1s"` |

262+| flag: `--pass-host-header`<br/>toml: `pass_host_header` | bool | pass the request Host Header to upstream | true |

263+| flag: `--proxy-websockets`<br/>toml: `proxy_websockets` | bool | enables WebSocket proxying | true |

264+| flag: `--ssl-upstream-insecure-skip-verify`<br/>toml: `ssl_upstream_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS upstreams | false |

265+| flag: `--disable-keep-alives`<br/>toml: `disable_keep_alives` | bool | disable HTTP keep-alive connections to the upstream server | false |

266+| flag: `--upstream-timeout`<br/>toml: `upstream_timeout` | duration | maximum amount of time the server will wait for a response from the upstream | 30s |

267+| flag: `--upstream`<br/>toml: `upstreams` | string \| list | the http url(s) of the upstream endpoint, file:// paths for static files or `static://<status_code>` for static response. Routing is based on the path | |

268+

269+## Upstreams Configuration

270+

271+`oauth2-proxy` supports having multiple upstreams, and has the option to pass requests on to HTTP(S) servers, unix socket or serve static files from the file system.

272+

273+To configure **HTTP and HTTPS upstreams**, provide such a URL in `--upstream=URL`. The scheme+host portion and the path portion are extracted to configure proxying behavior. When processing incoming requests, the path portion becomes a lookup key for selecting the destination server of the proxied request.

274+

275+* Upstream URLs *without a trailing slash,* like in `--upstream=http://service2.internal/foo`, will match an incoming request exactly to `/foo` in `https://this.o2p.example.com/foo`, and forward the request on to service2.internal, but not match a request to `https://this.o2p.example.com/foo/more` nor ...`.com/food`.

276+* Upstream URLs *with a trailing slash,* like in `--upstream=http://service1.internal/foo/`, will match any incoming request to any incoming requests's path *starting with* `/foo/`, like `/foo/` and `/foo/more` and `/foo/lots/more?etc`.

277+

278+If multiple `--upstream` URLs' paths match an incoming request, the one with the longest matching path (the most specific match) takes priority over shorter (less specific) ones.

279+

280+**Unix socket upstreams** are configured as `unix:///path/to/unix.sock`.

281+

282+**Static file paths** are configured as a file:// URL. `file:///var/www/static/` will serve the files from that directory at `http://[oauth2-proxy url]/var/www/static/`, which may not be what you want. You can provide the path to where the files should be available by adding a fragment to the configured URL. The value of the fragment will then be used to specify which path the files are available at, e.g. `file:///var/www/static/#/static/` will make `/var/www/static/` available at `http://[oauth2-proxy url]/static/`.

283+

284+Multiple upstreams can either be configured by supplying a comma separated list to the `--upstream` parameter, supplying the parameter multiple times or providing a list in the [config file](#config-file). When multiple upstreams are used routing to them will be based on the path they are set up with.

285+

286+## Environment variables

287+

288+Every command line argument can be specified as an environment variable by

289+prefixing it with `OAUTH2_PROXY_`, capitalising it, and replacing hyphens (`-`)

290+with underscores (`_`). If the argument can be specified multiple times, the

291+environment variable should be plural (trailing `S`).

292+

293+This is particularly useful for storing secrets outside a configuration file

294+or the command line.

295+

296+For example, the `--cookie-secret` flag becomes `OAUTH2_PROXY_COOKIE_SECRET`.

297+If a flag has the type `string | list` like the `--email-domain` flag it is

298+available as an environment variable in plural form e.g. `OAUTH2_PROXY_EMAIL_DOMAINS`

299+

300+Values for type `string | list` usually have a plural environment variable name

301+and need to be seperated by `,` e.g.

302+`OAUTH2_PROXY_SKIP_AUTH_ROUTES="GET=^/api/status,POST=^/api/saved_objects/_import"`

303+

304+Please check the type for each [config option](#config-options) first.

305+

306+## Logging Configuration

307+

308+By default, OAuth2 Proxy logs all output to stdout. Logging can be configured to output to a rotating log file using the `--logging-filename` command.

309+

310+If logging to a file you can also configure the maximum file size (`--logging-max-size`), age (`--logging-max-age`), max backup logs (`--logging-max-backups`), and if backup logs should be compressed (`--logging-compress`).

311+

312+There are three different types of logging: standard, authentication, and HTTP requests. These can each be enabled or disabled with `--standard-logging`, `--auth-logging`, and `--request-logging`.

313+

314+Each type of logging has its own configurable format and variables. By default, these formats are similar to the Apache Combined Log.

315+

316+Logging of requests to the `/ping` endpoint (or using `--ping-user-agent`) and the `/ready` endpoint can be disabled with `--silence-ping-logging` reducing log volume.

317+

318+## Auth Log Format

319+

320+Authentication logs are logs which are guaranteed to contain a username or email address of a user attempting to authenticate. These logs are output by default in the below format:

321+

322+```

323+<REMOTE_ADDRESS> - <REQUEST ID> - <user@domain.com> [2015/03/19 17:20:19] [<STATUS>] <MESSAGE>

324+```

325+

326+The status block will contain one of the below strings:

327+

328+- `AuthSuccess` If a user has authenticated successfully by any method

329+- `AuthFailure` If the user failed to authenticate explicitly

330+- `AuthError` If there was an unexpected error during authentication

331+

332+If you require a different format than that, you can configure it with the `--auth-logging-format` flag.

333+The default format is configured as follows:

334+

335+```

336+{{.Client}} - {{.RequestID}} - {{.Username}} [{{.Timestamp}}] [{{.Status}}] {{.Message}}

337+```

338+

339+Available variables for auth logging:

340+

341+| Variable | Example | Description |

342+| ------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------- |

343+| Client | 74.125.224.72 | The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true. |

344+| Host | domain.com | The value of the Host header. |

345+| Message | Authenticated via OAuth2 | The details of the auth attempt. |

346+| Protocol | HTTP/1.0 | The request protocol. |

347+| RequestID | 00010203-0405-4607-8809-0a0b0c0d0e0f | The request ID pulled from the `--request-id-header`. Random UUID if empty |

348+| RequestMethod | GET | The request method. |

349+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

350+| UserAgent | - | The full user agent as reported by the requesting client. |

351+| Username | username@email.com | The email or username of the auth request. |

352+| Status | AuthSuccess | The status of the auth request. See above for details. |

353+

354+## Request Log Format

355+

356+HTTP request logs will output by default in the below format:

357+

358+```

359+<REMOTE_ADDRESS> - <REQUEST ID> - <user@domain.com> [2015/03/19 17:20:19] <HOST_HEADER> GET <UPSTREAM_HOST> "/path/" HTTP/1.1 "<USER_AGENT>" <RESPONSE_CODE> <RESPONSE_BYTES> <REQUEST_DURATION>

360+```

361+

362+If you require a different format than that, you can configure it with the `--request-logging-format` flag.

363+The default format is configured as follows:

364+

365+```

366+{{.Client}} - {{.RequestID}} - {{.Username}} [{{.Timestamp}}] {{.Host}} {{.RequestMethod}} {{.Upstream}} {{.RequestURI}} {{.Protocol}} {{.UserAgent}} {{.StatusCode}} {{.ResponseSize}} {{.RequestDuration}}

367+```

368+

369+Available variables for request logging:

370+

371+| Variable | Example | Description |

372+| --------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------- |

373+| Client | 74.125.224.72 | The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true. |

374+| Host | domain.com | The value of the Host header. |

375+| Protocol | HTTP/1.0 | The request protocol. |

376+| RequestDuration | 0.001 | The time in seconds that a request took to process. |

377+| RequestID | 00010203-0405-4607-8809-0a0b0c0d0e0f | The request ID pulled from the `--request-id-header`. Random UUID if empty |

378+| RequestMethod | GET | The request method. |

379+| RequestURI | "/oauth2/auth" | The URI path of the request. |

380+| ResponseSize | 12 | The size in bytes of the response. |

381+| StatusCode | 200 | The HTTP status code of the response. |

382+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

383+| Upstream | - | The upstream data of the HTTP request. |

384+| UserAgent | - | The full user agent as reported by the requesting client. |

385+| Username | username@email.com | The email or username of the auth request. |

386+

387+## Standard Log Format

388+

389+All other logging that is not covered by the above two types of logging will be output in this standard logging format. This includes configuration information at startup and errors that occur outside of a session. The default format is below:

390+

391+```

392+[2015/03/19 17:20:19] [main.go:40] <MESSAGE>

393+```

394+

395+If you require a different format than that, you can configure it with the `--standard-logging-format` flag. The default format is configured as follows:

396+

397+```

398+[{{.Timestamp}}] [{{.File}}] {{.Message}}

399+```

400+

401+Available variables for standard logging:

402+

403+| Variable | Example | Description |

404+| --------- | --------------------------------- | -------------------------------------------------- |

405+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

406+| File | main.go:40 | The file and line number of the logging statement. |

407+| Message | HTTP: listening on 127.0.0.1:4180 | The details of the log statement. |

docs/versioned_docs/version-7.14.x/configuration/providers/adfs.mdnew file+19

@@ -0,0 +1,19 @@

1+---

2+id: adfs

3+title: ADFS

4+---

5+

6+1. Open the ADFS administration console on your Windows Server and add a new Application Group

7+2. Provide a name for the integration, select Server Application from the Standalone applications section and click Next

8+3. Follow the wizard to get the client-id, client-secret and configure the application credentials

9+4. Configure the proxy with

10+

11+```

12+ --provider=adfs

13+ --client-id=<application ID from step 3>

14+ --client-secret=<value from step 3>

15+```

16+

17+Note: When using the ADFS Auth provider with nginx and the cookie session store you may find the cookie is too large and

18+doesn't get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the

19+[redis session storage](../sessions.md#redis-storage) should resolve this.

docs/versioned_docs/version-7.14.x/configuration/providers/bitbucket.mdnew file+25

@@ -0,0 +1,25 @@

1+---

2+id: bitbucket

3+title: BitBucket

4+---

5+

6+1. [Add a new OAuth consumer](https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html)

7+ * In "Callback URL" use `https://<oauth2-proxy>/oauth2/callback`, substituting `<oauth2-proxy>` with the actual

8+ hostname that oauth2-proxy is running on.

9+ * In Permissions section select:

10+ * Account -> Email

11+ * Team membership -> Read

12+ * Repositories -> Read

13+2. Note the Client ID and Client Secret.

14+

15+To use the provider, pass the following options:

16+

17+```

18+ --provider=bitbucket

19+ --client-id=<Client ID>

20+ --client-secret=<Client Secret>

21+```

22+

23+The default configuration allows everyone with Bitbucket account to authenticate. To restrict the access to the team

24+members use additional configuration option: `--bitbucket-team=<Team name>`. To restrict the access to only these users

25+who have access to one selected repository use `--bitbucket-repository=<Repository name>`.

docs/versioned_docs/version-7.14.x/configuration/providers/cidaas.mdnew file+37

@@ -0,0 +1,37 @@

1+---

2+id: cidaas

3+title: Cidaas

4+---

5+

6+[Cidaas](https://www.cidaas.com/) is an Identity as a Service (IDaaS) solution that provides authentication and authorization services.

7+It supports various protocols including OpenID Connect, OAuth 2.0, and SAML.

8+

9+However, Cidaas provides groups and their roles as hierarchical claims, which are not supported by oauth2-proxy yet.

10+The Cidaas provider transforms the hierarchical claims into a flat list of groups, which can be used by oauth2-proxy.

11+

12+Example of groups and roles in Cidaas:

13+

14+```json

15+{

16+ "groups": [

17+ {

18+ "groupId": "group1",

19+ "roles": ["role1", "role2"]

20+ },

21+ {

22+ "groupId": "group2",

23+ "roles": ["role3"]

24+ }

25+ ]

26+}

27+```

28+

29+This will be transformed into a flat list of groups:

30+

31+```json

32+{

33+ "groups": ["group1:role1", "group2:role2", "group2:role3"]

34+}

35+```

36+

37+Apart from that the Cidaas provider inherits all the features of the [OpenID Connect provider](openid_connect.md).

docs/versioned_docs/version-7.14.x/configuration/providers/cisco_duo.mdnew file+44

@@ -0,0 +1,44 @@

1+---

2+id: cisco_duo

3+title: Cisco Duo

4+---

5+

6+Cisco Duo SSO can be configured with OAuth2 Proxy using the OIDC provider.

7+

8+1. Create a new **Generic OIDC Relying Party - Single Sign-On** application in the Duo Admin Portal

9+2. Configure OAuth2 Proxy with the following options:

10+

11+```

12+provider = "oidc"

13+provider_display_name = "Duo SSO"

14+scope = "openid email profile"

15+pass_access_token = true

16+code_challenge_method = "S256"

17+```

18+

19+3. Configure Provider endpoints. Copy the following values from the corresponding fields in the Duo Admin Portal:

20+

21+```

22+# Copy from "Client ID" field

23+client_id = "XXXXXXXX"

24+

25+# Copy from "Client Secret" field

26+client_secret = "XXXXXXXX"

27+

28+# Copy from "Issuer" field

29+oidc_issuer_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx"

30+

31+# Copy from "JWKS URL" field

32+oidc_jwks_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/jwks"

33+

34+# Copy from "Token Introspection URL" field

35+validate_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/token_introspection"

36+

37+# Copy from "UserInfo" field

38+profile_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/userinfo"

39+

40+# Copy from "Token URL" field

41+redeem_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/token"

42+```

43+

44+4. Complete Configuration by filling in any remaining required fields and save your configuration.

docs/versioned_docs/version-7.14.x/configuration/providers/digitalocean.mdnew file+21

@@ -0,0 +1,21 @@

1+---

2+id: digitalocean

3+title: DigitalOcean

4+---

5+

6+1. [Create a new OAuth application](https://cloud.digitalocean.com/account/api/applications)

7+ * You can fill in the name, homepage, and description however you wish.

8+ * In the "Application callback URL" field, enter: `https://oauth-proxy/oauth2/callback`, substituting `oauth2-proxy`

9+ with the actual hostname that oauth2-proxy is running on. The URL must match oauth2-proxy's configured redirect URL.

10+2. Note the Client ID and Client Secret.

11+

12+To use the provider, pass the following options:

13+

14+```

15+ --provider=digitalocean

16+ --client-id=<Client ID>

17+ --client-secret=<Client Secret>

18+```

19+

20+Alternatively, set the equivalent options in the config file. The redirect URL defaults to

21+`https://<requested host header>/oauth2/callback`. If you need to change it, you can use the `--redirect-url` command-line option.

docs/versioned_docs/version-7.14.x/configuration/providers/facebook.mdnew file+7

@@ -0,0 +1,7 @@

1+---

2+id: facebook

3+title: Facebook

4+---

5+

6+1. Create a new FB App from https://developers.facebook.com/

7+2. Under FB Login, set your Valid OAuth redirect URIs to `https://internal.yourcompany.com/oauth2/callback`

docs/versioned_docs/version-7.14.x/configuration/providers/gitea.mdnew file+24

@@ -0,0 +1,24 @@

1+---

2+id: gitea

3+title: Gitea / Forgejo

4+---

5+

6+:::note

7+This is not actually a fully serparate provider. For more details and options please refer to the [GitHub Provider Options](github.md)

8+:::

9+

10+1. Create a new application: `https://< your gitea host >/user/settings/applications`

11+2. Under `Redirect URI` enter the correct URL i.e. `https://<proxied host>/oauth2/callback`

12+3. Note the Client ID and Client Secret.

13+4. Pass the following options to the proxy:

14+

15+```

16+ --provider="github"

17+ --redirect-url="https://<proxied host>/oauth2/callback"

18+ --provider-display-name="Gitea"

19+ --client-id="< client_id as generated by Gitea >"

20+ --client-secret="< client_secret as generated by Gitea >"

21+ --login-url="https://< your gitea host >/login/oauth/authorize"

22+ --redeem-url="https://< your gitea host >/login/oauth/access_token"

23+ --validate-url="https://< your gitea host >/api/v1/user/emails"

24+```

docs/versioned_docs/version-7.14.x/configuration/providers/github.mdnew file+81

@@ -0,0 +1,81 @@

1+---

2+id: github

3+title: GitHub

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ---------------- | -------------- | -------------- | ------------------------------------------------------------------------------------------------------------- | ------- |

10+| `--github-org` | `github_org` | string | restrict logins to members of this organisation | |

11+| `--github-team` | `github_team` | string | restrict logins to members of any of these teams (slug) or (org:team), comma separated | |

12+| `--github-repo` | `github_repo` | string | restrict logins to collaborators of this repository formatted as `orgname/repo` | |

13+| `--github-token` | `github_token` | string | the token to use when verifying repository collaborators (must have push access to the repository) | |

14+| `--github-user` | `github_users` | string \| list | To allow users to login by username even if they do not belong to the specified org and team or collaborators | |

15+

16+## Usage

17+

18+1. Create a new project: https://github.com/settings/developers

19+2. Under `Authorization callback URL` enter the correct url ie `https://internal.yourcompany.com/oauth2/callback`

20+

21+The GitHub auth provider supports two additional ways to restrict authentication to either organization and optional

22+team level access, or to collaborators of a repository. Restricting by these options is normally accompanied with `--email-domain=*`. Additionally, all the organizations and teams a user belongs to are set as part of the `X-Forwarded-Groups` header. e.g. `org1:team1,org1:team2,org2:team1`

23+

24+NOTE: When `--github-user` is set, the specified users are allowed to log in even if they do not belong to the specified

25+org and team or collaborators.

26+

27+To restrict access to your organization:

28+

29+```shell

30+ # restrict logins to members of this organisation

31+ --github-org="your-org"

32+```

33+

34+To restrict access to specific teams within an organization:

35+

36+```shell

37+ --github-org="your-org"

38+ # restrict logins to members of any of these teams (slug), comma separated

39+ --github-team="team1,team2,team3"

40+```

41+

42+To restrict to teams within different organizations, keep the organization flag empty and use `--github-team` like so:

43+

44+```shell

45+ # keep empty

46+ --github-org=""

47+ # restrict logins to members to any of the following teams (format <org>:<slug>, like octo:team1), comma separated

48+ --github-team="org1:team1,org2:team1,org3:team42,octo:cat"

49+```

50+

51+If you would rather restrict access to collaborators of a repository, those users must either have push access to a

52+public repository or any access to a private repository:

53+

54+```shell

55+ # restrict logins to collaborators of this repository formatted as orgname/repo

56+ --github-repo=""

57+```

58+

59+If you'd like to allow access to users with **read only** access to a **public** repository you will need to provide a

60+[token](https://github.com/settings/tokens) for a user that has write access to the repository. The token must be

61+created with at least the `public_repo` scope:

62+

63+```shell

64+ # the token to use when verifying repository collaborators

65+ --github-token=""

66+```

67+

68+To allow a user to log in with their username even if they do not belong to the specified org and team or collaborators:

69+

70+```shell

71+ # allow logins by username, comma separated

72+ --github-user=""

73+```

74+

75+If you are using GitHub enterprise, make sure you set the following to the appropriate url:

76+

77+```shell

78+ --login-url="http(s)://<enterprise github host>/login/oauth/authorize"

79+ --redeem-url="http(s)://<enterprise github host>/login/oauth/access_token"

80+ --validate-url="http(s)://<enterprise github host>/api/v3"

81+```

docs/versioned_docs/version-7.14.x/configuration/providers/gitlab.mdnew file+49

@@ -0,0 +1,49 @@

1+---

2+id: gitlab

3+title: GitLab

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

10+| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

12+

13+## Usage

14+

15+This auth provider has been tested against Gitlab version 12.X. Due to Gitlab API changes, it may not work for version

16+prior to 12.X (see [994](https://github.com/oauth2-proxy/oauth2-proxy/issues/994)).

17+

18+Whether you are using GitLab.com or self-hosting GitLab, follow

19+[these steps to add an application](https://docs.gitlab.com/integration/oauth_provider/). Make sure to enable at

20+least the `openid`, `profile` and `email` scopes, and set the redirect url to your application url e.g.

21+https://myapp.com/oauth2/callback.

22+

23+If you need projects filtering, add the extra `read_api` scope to your application.

24+

25+The following config should be set to ensure that the oauth will work properly. To get a cookie secret follow

26+[these steps](../overview.md#generating-a-cookie-secret)

27+

28+```

29+ --provider="gitlab"

30+ --redirect-url="https://myapp.com/oauth2/callback" // Should be the same as the redirect url for the application in gitlab

31+ --client-id=GITLAB_CLIENT_ID

32+ --client-secret=GITLAB_CLIENT_SECRET

33+ --cookie-secret=COOKIE_SECRET

34+```

35+

36+Restricting by group membership is possible with the following option:

37+

38+```shell

39+ --gitlab-group="mygroup,myothergroup" # restrict logins to members of any of these groups (slug), separated by a comma

40+```

41+

42+If you are using self-hosted GitLab, make sure you set the following to the appropriate URL:

43+

44+```shell

45+ --oidc-issuer-url="<your gitlab url>"

46+```

47+

48+If your self-hosted GitLab is on a subdirectory (e.g. domain.tld/gitlab), as opposed to its own subdomain

49+(e.g. gitlab.domain.tld), you may need to add a redirect from domain.tld/oauth pointing at e.g. domain.tld/gitlab/oauth.

docs/versioned_docs/version-7.14.x/configuration/providers/google.mdnew file+84

@@ -0,0 +1,84 @@

1+---

2+id: google

3+title: Google (default)

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+|-------------------------------------------------|----------------------------------------------| ------ |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------|

10+| `--google-admin-email` | `google_admin_email` | string | the google admin to impersonate for api calls | |

11+| `--google-group` | `google_groups` | string | restrict logins to members of this google group (may be given multiple times). If not specified and service account or default credentials are configured, all user groups will be allowed. | |

12+| `--google-service-account-json` | `google_service_account_json` | string | the path to the service account json credentials | |

13+| `--google-use-application-default-credentials` | `google_use_application_default_credentials` | bool | use application default credentials instead of service account json (i.e. GKE Workload Identity) | |

14+| `--google-target-principal` | `google_target_principal` | bool | the target principal to impersonate when using ADC | defaults to the service account configured for ADC |

15+| `--google-use-organization-id` | `google_use_organization_id` | bool | use organization id as preferred username | false |

16+| `--google-admin-api-user-scope` | `google_admin_api_user_scope` | string | the OAuth scope to use when querying the Google Admin SDK for organization id, can be 'readonly', 'user' or 'cloud'<br/> | `readonly` |

17+

18+## Usage

19+

20+For Google, the registration steps are:

21+

22+1. Create a new project: https://console.developers.google.com/project

23+2. Choose the new project from the top right project dropdown (only if another project is selected)

24+3. In the project Dashboard center pane, choose **"APIs & Services"**

25+4. In the left Nav pane, choose **"Credentials"**

26+5. In the center pane, choose **"OAuth consent screen"** tab. Fill in **"Product name shown to users"** and hit save.

27+6. In the center pane, choose **"Credentials"** tab.

28+ - Open the **"New credentials"** drop down

29+ - Choose **"OAuth client ID"**

30+ - Choose **"Web application"**

31+ - Application name is freeform, choose something appropriate

32+ - Authorized JavaScript origins is your domain ex: `https://internal.yourcompany.com`

33+ - Authorized redirect URIs is the location of oauth2/callback ex: `https://internal.yourcompany.com/oauth2/callback`

34+ - Choose **"Create"**

35+7. Take note of the **Client ID** and **Client Secret**

36+

37+It's recommended to refresh sessions on a short interval (1h) with `cookie-refresh` setting which validates that the

38+account is still authorized.

39+

40+#### Restrict auth to specific Google groups on your domain. (optional)

41+

42+1. Create a [service account](https://developers.google.com/identity/protocols/oauth2/service-account) and configure it

43+ to use [Application Default Credentials / Workload Identity / Workload Identity Federation (recommended)](#using-application-default-credentials-adc--workload-identity--workload-identity-federation-recommended) or,

44+ alternatively download the JSON.

45+2. Make note of the Client ID for a future step.

46+3. Under "APIs & Auth", choose APIs.

47+4. Click on Admin SDK and then Enable API.

48+5. Follow the steps on [Set up domain-wide delegation for a service account](https://developers.google.com/workspace/guides/create-credentials#optional_set_up_domain-wide_delegation_for_a_service_account)

49+ and give the client id from step 2 the following oauth scopes:

50+

51+ ```

52+ https://www.googleapis.com/auth/admin.directory.group.member.readonly

53+ ```

54+

55+6. Follow the steps on https://support.google.com/a/answer/60757 to enable Admin API access.

56+7. Create or choose an existing administrative email address on the Gmail domain to assign to the `google-admin-email`

57+ flag. This email will be impersonated by this client to make calls to the Admin SDK. See the note on the link from

58+ step 5 for the reason why.

59+8. Create or choose an existing email group and set that email to the `google-group` flag. You can pass multiple instances

60+ of this flag with different groups and the user will be checked against all the provided groups.

61+

62+(Only if using a JSON file (see step 1))

63+

64+9. Lock down the permissions on the json file downloaded from step 1 so only oauth2-proxy is able to read the file and

65+ set the path to the file in the `google-service-account-json` flag.

66+10. Restart oauth2-proxy.

67+

68+Note: The user is checked against the group members list on initial authentication and every time the token is

69+refreshed ( about once an hour ).

70+

71+##### Using Application Default Credentials (ADC) / Workload Identity / Workload Identity Federation (recommended)

72+oauth2-proxy can make use of [Application Default Credentials](https://cloud.google.com/docs/authentication/application-default-credentials).

73+When deployed within GCP, this means that it can automatically use the service account attached to the resource. When deployed to GKE, ADC

74+can be leveraged through a feature called Workload Identity. Follow Google's [guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)

75+to set up Workload Identity.

76+

77+When deployed outside of GCP, [Workload Identity Federation](https://cloud.google.com/docs/authentication/provide-credentials-adc#wlif) might be an option.

78+

79+##### Using Organization ID as Preferred Username (optional)

80+By default, the google provider uses the google id as username. If you would like to use an organization id instead, you can set the `google-use-organization-id` flag to true.

81+This requires that the service account used to query the Google Admin SDK has one of the following scopes granted in step 5 above:

82+- `https://www.googleapis.com/auth/admin.directory.user.readonly`,

83+- `https://www.googleapis.com/auth/admin.directory.user`

84+- `https://www.googleapis.com/auth/cloud-platform`

docs/versioned_docs/version-7.14.x/configuration/providers/index.mdnew file+46

@@ -0,0 +1,46 @@

1+---

2+id: index

3+title: OAuth Provider Configuration

4+---

5+

6+You will need to register an OAuth application with a Provider (Google, GitHub or another provider), and configure it

7+with Redirect URI(s) for the domain you intend to run `oauth2-proxy` on.

8+

9+Valid providers are :

10+

11+- [ADFS](adfs.md)

12+- [Bitbucket](bitbucket.md)

13+- [Cidaas](cidaas.md)

14+- [CiscoDuo](cisco_duo.md)

15+- [DigitalOcean](digitalocean.md)

16+- [Facebook](facebook.md)

17+- [Gitea](gitea.md)

18+- [GitHub](github.md)

19+- [GitLab](gitlab.md)

20+- [Google](google.md) _default_

21+- [Keycloak](keycloak.md) (Deprecated)

22+- [Keycloak OIDC](keycloak_oidc.md)

23+- [LinkedIn](linkedin.md)

24+- [login.gov](login_gov.md)

25+- [Microsoft Azure](ms_azure_ad.md) (Deprecated)

26+- [Microsoft Entra ID](ms_entra_id.md)

27+- [Nextcloud](nextcloud.md)

28+- [OpenID Connect](openid_connect.md)

29+- [SourceHut](sourcehut.md)

30+

31+The provider can be selected using the `provider` configuration value, or set in the [`providers` array using AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers). However, [**the feature to implement multiple providers is not complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

32+

33+Please note that not all providers support all claims. The `preferred_username` claim is currently only supported by the

34+OpenID Connect provider.

35+

36+## Email Authentication

37+

38+To authorize a specific email-domain use `--email-domain=yourcompany.com`. To authorize individual email addresses use

39+`--authenticated-emails-file=/path/to/file` with one email per line. To authorize all email addresses use `--email-domain=*`.

40+

41+## Adding a new Provider

42+

43+Follow the examples in the [`providers` package](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/) to define a new

44+`Provider` instance. Add a new `case` to

45+[`providers.New()`](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/providers.go) to allow `oauth2-proxy` to use the

46+new `Provider`.

docs/versioned_docs/version-7.14.x/configuration/providers/keycloak.mdnew file+36

@@ -0,0 +1,36 @@

1+---

2+id: keycloak

3+title: Keycloak (Deprecated)

4+---

5+

6+:::note

7+This is the legacy and deprecated provider for Keycloak, use [Keycloak OIDC Auth Provider](keycloak_oidc.md) if possible.

8+:::

9+

10+1. Create new client in your Keycloak realm with **Access Type** 'confidential' and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'

11+2. Take note of the Secret in the credential tab of the client

12+3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.

13+

14+Make sure you set the following to the appropriate url:

15+

16+```

17+ --provider=keycloak

18+ --client-id=<client you have created>

19+ --client-secret=<your client's secret>

20+ --login-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/auth"

21+ --redeem-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/token"

22+ --profile-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"

23+ --validate-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"

24+ --keycloak-group=<first_allowed_user_group>

25+ --keycloak-group=<second_allowed_user_group>

26+```

27+

28+For group based authorization, the optional `--keycloak-group` (legacy) or `--allowed-group` (global standard)

29+flags can be used to specify which groups to limit access to.

30+

31+If these are unset but a `groups` mapper is set up above in step (3), the provider will still

32+populate the `X-Forwarded-Groups` header to your upstream server with the `groups` data in the

33+Keycloak userinfo endpoint response.

34+

35+The group management in keycloak is using a tree. If you create a group named admin in keycloak

36+you should define the 'keycloak-group' value to /admin.

docs/versioned_docs/version-7.14.x/configuration/providers/keycloak_oidc.mdnew file+151

@@ -0,0 +1,151 @@

1+---

2+id: keycloak_oidc

3+title: Keycloak OIDC

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ---------------- | --------------- | -------------- | ------------------------------------------------------------------------------------------------------------------ | ------- |

10+| `--allowed-role` | `allowed_roles` | string \| list | restrict logins to users with this role (may be given multiple times). Only works with the keycloak-oidc provider. | |

11+

12+## Usage

13+

14+```

15+ --provider=keycloak-oidc

16+ --client-id=<your client's id>

17+ --client-secret=<your client's secret>

18+ --redirect-url=https://internal.yourcompany.com/oauth2/callback

19+ --oidc-issuer-url=https://<keycloak host>/realms/<your realm> // For Keycloak versions <17: --oidc-issuer-url=https://<keycloak host>/auth/realms/<your realm>

20+ --email-domain=<yourcompany.com> // Validate email domain for users, see option documentation

21+ --allowed-role=<realm role name> // Optional, required realm role

22+ --allowed-role=<client id>:<client role name> // Optional, required client role

23+ --allowed-group=</group name> // Optional, requires group client scope

24+ --code-challenge-method=S256 // PKCE

25+```

26+

27+:::note

28+Keycloak has updated its admin console and as of version 19.0.0, the new admin console is enabled by default. The

29+legacy admin console has been announced for removal with the release of version 21.0.0.

30+:::

31+

32+**Keycloak legacy admin console**

33+

34+1. Create new client in your Keycloak realm with **Access Type** 'confidential', **Client protocol** 'openid-connect'

35+ and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'

36+2. Take note of the Secret in the credential tab of the client

37+3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.

38+4. Create a mapper with **Mapper Type** 'Audience' and **Included Client Audience** and **Included Custom Audience** set

39+ to your client name.

40+

41+**Keycloak new admin console (default as of v19.0.0)**

42+

43+The following example shows how to create a simple OIDC client using the new Keycloak admin2 console. However, for best

44+practices, it is recommended to consult the Keycloak documentation.

45+

46+The OIDC client must be configured with an _audience mapper_ to include the client's name in the `aud` claim of the JWT token.

47+The `aud` claim specifies the intended recipient of the token, and OAuth2 Proxy expects a match against the values of

48+either `--client-id` or `--oidc-extra-audience`.

49+

50+_In Keycloak, claims are added to JWT tokens through the use of mappers at either the realm level using "client scopes" or

51+through "dedicated" client mappers._

52+

53+**Creating the client**

54+

55+1. Create a new OIDC client in your Keycloak realm by navigating to:

56+ **Clients** -> **Create client**

57+ * **Client Type** 'OpenID Connect'

58+ * **Client ID** `<your client's id>`, please complete the remaining fields as appropriate and click **Next**.

59+ * **Client authentication** 'On'

60+ * **Authentication flow**

61+ * **Standard flow** 'selected'

62+ * **Direct access grants** 'deselect'

63+ * _Save the configuration._

64+ * **Settings / Access settings**:

65+ * **Valid redirect URIs** `https://internal.yourcompany.com/oauth2/callback`

66+ * _Save the configuration._

67+ * Under the **Credentials** tab you will now be able to locate `<your client's secret>`.

68+2. Configure a dedicated *audience mapper* for your client by navigating to **Clients** -> **\<your client's id\>** -> **Client scopes**.

69+* Access the dedicated mappers pane by clicking **\<your client's id\>-dedicated**, located under *Assigned client scope*.

70+ _(It should have a description of "Dedicated scope and mappers for this client")_

71+ * Click **Configure a new mapper** and select **Audience**

72+ * **Name** 'aud-mapper-\<your client's id\>'

73+ * **Included Client Audience** select `<your client's id>` from the dropdown.

74+ * _OAuth2 proxy can be set up to pass both the access and ID JWT tokens to your upstream services.

75+ If you require additional audience entries, you can use the **Included Custom Audience** field in addition

76+ to the "Included Client Audience" dropdown. Note that the "aud" claim of a JWT token should be limited and

77+ only specify its intended recipients._

78+ * **Add to ID token** 'On'

79+ * **Add to access token** 'On' - [#1916](https://github.com/oauth2-proxy/oauth2-proxy/pull/1916)

80+ * _Save the configuration._

81+* Any subsequent dedicated client mappers can be defined by clicking **Dedicated scopes** -> **Add mapper** ->

82+ **By configuration** -> *Select mapper*

83+

84+You should now be able to create a test user in Keycloak and get access to the OAuth2 Proxy instance, make sure to set

85+an email address matching `<yourcompany.com>` and select _Email verified_.

86+

87+**Authorization**

88+

89+_OAuth2 Proxy will perform authorization by requiring a valid user, this authorization can be extended to take into

90+account a user's membership in Keycloak `groups`, `realm roles`, and `client roles` using the keycloak-oidc provider options

91+`--allowed-role` or `--allowed-group`_

92+

93+**Roles**

94+

95+_A standard Keycloak installation comes with the required mappers for **realm roles** and **client roles** through the

96+pre-defined client scope "roles". This ensures that any roles assigned to a user are included in the `JWT` tokens when

97+using an OIDC client that has the "Full scope allowed" feature activated, the feature is enabled by default._

98+

99+_Creating a realm role_

100+* Navigate to **Realm roles** -> **Create role**

101+ * **Role name**, *`<realm role name>`* -> **save**

102+

103+_Creating a client role_

104+* Navigate to **Clients** -> `<your client's id>` -> **Roles** -> **Create role**

105+ * **Role name**, *`<client role name>`* -> **save**

106+

107+

108+_Assign a role to a user_

109+

110+**Users** -> _Username_ -> **Role mapping** -> **Assign role** -> _filter by roles or clients and select_ -> **Assign**.

111+

112+Keycloak "realm roles" can be authorized using the `--allowed-role=<realm role name>` option, while "client roles" can be

113+evaluated using `--allowed-role=<your client's id>:<client role name>`.

114+

115+You may limit the _realm roles_ included in the JWT tokens for any given client by navigating to:

116+**Clients** -> `<your client's id>` -> **Client scopes** -> _\<your client's id\>-dedicated_ -> **Scope**

117+Disabling **Full scope allowed** activates the **Assign role** option, allowing you to select which roles, if assigned

118+to a user, will be included in the user's JWT tokens. This can be useful when a user has many associated roles, and you

119+want to reduce the size and impact of the JWT token.

120+

121+

122+**Groups**

123+

124+You may also do authorization on group memberships by using the OAuth2 Proxy option `--allowed-group`.

125+We will only do a brief description of creating the required _client scope_ **groups** and refer you to read the Keycloak

126+documentation.

127+

128+To summarize, the steps required to authorize Keycloak group membership with OAuth2 Proxy are as follows:

129+

130+* Create a new Client Scope with the name **groups** in Keycloak.

131+ * Include a mapper of type **Group Membership**.

132+ * Set the "Token Claim Name" to **groups** or customize by matching it to the `--oidc-groups-claim` option of OAuth2 Proxy.

133+ * If the "Full group path" option is selected, you need to include a "/" separator in the group names defined in the

134+ `--allowed-group` option of OAuth2 Proxy. Example: "/groupname" or "/groupname/child_group".

135+

136+After creating the _Client Scope_ named _groups_ you will need to attach it to your client.

137+**Clients** -> `<your client's id>` -> **Client scopes** -> **Add client scope** -> Select **groups** and choose Optional

138+and you should now have a client that maps group memberships into the JWT tokens so that Oauth2 Proxy may evaluate them.

139+

140+Create a group by navigating to **Groups** -> **Create group** and _add_ your test user as a member.

141+

142+The OAuth2 Proxy option `--allowed-group=/groupname` will now allow you to filter on group membership

143+

144+Keycloak also has the option of attaching roles to groups, please refer to the Keycloak documentation for more information.

145+

146+**Tip**

147+

148+To check if roles or groups are added to JWT tokens, you can preview a users token in the Keycloak console by following

149+these steps: **Clients** -> `<your client's id>` -> **Client scopes** -> **Evaluate**.

150+Select a _realm user_ and optional _scope parameters_ such as groups, and generate the JSON representation of an access

151+or id token to examine its contents.

docs/versioned_docs/version-7.14.x/configuration/providers/linkedin.mdnew file+13

@@ -0,0 +1,13 @@

1+---

2+id: linkedin

3+title: LinkedIn

4+---

5+

6+For LinkedIn, the registration steps are:

7+

8+1. Create a new project: https://www.linkedin.com/secure/developer

9+2. In the OAuth User Agreement section:

10+ - In default scope, select r_basicprofile and r_emailaddress.

11+ - In "OAuth 2.0 Redirect URLs", enter `https://internal.yourcompany.com/oauth2/callback`

12+3. Fill in the remaining required fields and Save.

13+4. Take note of the **Consumer Key / API Key** and **Consumer Secret / Secret Key**

docs/versioned_docs/version-7.14.x/configuration/providers/login_gov.mdnew file+79

@@ -0,0 +1,79 @@

1+---

2+id: login_gov

3+title: Login.gov

4+---

5+

6+login.gov is an OIDC provider for the US Government.

7+If you are a US Government agency, you can contact the login.gov team through the contact information

8+that you can find on https://login.gov/developers/ and work with them to understand how to get login.gov

9+accounts for integration/test and production access.

10+

11+A developer guide is available here: https://developers.login.gov/, though this proxy handles everything

12+but the data you need to create to register your application in the login.gov dashboard.

13+

14+As a demo, we will assume that you are running your application that you want to secure locally on

15+http://localhost:3000/, that you will be starting your proxy up on http://localhost:4180/, and that

16+you have an agency integration account for testing.

17+

18+First, register your application in the dashboard. The important bits are:

19+* Identity protocol: make this `Openid connect`

20+* Issuer: do what they say for OpenID Connect. We will refer to this string as `${LOGINGOV_ISSUER}`.

21+* Public key: This is a self-signed certificate in .pem format generated from a 2048-bit RSA private key.

22+ A quick way to do this is

23+ `openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 3650 -nodes -subj '/C=US/ST=Washington/L=DC/O=GSA/OU=18F/CN=localhost'`.

24+ The contents of the `key.pem` shall be referred to as `${OAUTH2_PROXY_JWT_KEY}`.

25+* Return to App URL: Make this be `http://localhost:4180/`

26+* Redirect URIs: Make this be `http://localhost:4180/oauth2/callback`.

27+* Attribute Bundle: Make sure that email is selected.

28+

29+Now start the proxy up with the following options:

30+```

31+./oauth2-proxy -provider login.gov \

32+ -client-id=${LOGINGOV_ISSUER} \

33+ -redirect-url=http://localhost:4180/oauth2/callback \

34+ -oidc-issuer-url=https://idp.int.identitysandbox.gov/ \

35+ -cookie-secure=false \

36+ -email-domain=gsa.gov \

37+ -upstream=http://localhost:3000/ \

38+ -cookie-secret=somerandomstring12341234567890AB \

39+ -cookie-domain=localhost \

40+ -skip-provider-button=true \

41+ -pubjwk-url=https://idp.int.identitysandbox.gov/api/openid_connect/certs \

42+ -profile-url=https://idp.int.identitysandbox.gov/api/openid_connect/userinfo \

43+ -jwt-key="${OAUTH2_PROXY_JWT_KEY}"

44+```

45+You can also set all these options with environment variables, for use in cloud/docker environments.

46+One tricky thing that you may encounter is that some cloud environments will pass in environment

47+variables in a docker env-file, which does not allow multiline variables like a PEM file.

48+If you encounter this, then you can create a `jwt_signing_key.pem` file in the top level

49+directory of the repo which contains the key in PEM format and then do your docker build.

50+The docker build process will copy that file into your image which you can then access by

51+setting the `OAUTH2_PROXY_JWT_KEY_FILE=/etc/ssl/private/jwt_signing_key.pem`

52+environment variable, or by setting `--jwt-key-file=/etc/ssl/private/jwt_signing_key.pem` on the commandline.

53+

54+Once it is running, you should be able to go to `http://localhost:4180/` in your browser,

55+get authenticated by the login.gov integration server, and then get proxied on to your

56+application running on `http://localhost:3000/`. In a real deployment, you would secure

57+your application with a firewall or something so that it was only accessible from the

58+proxy, and you would use real hostnames everywhere.

59+

60+#### Skip OIDC discovery

61+

62+Some providers do not support OIDC discovery via their issuer URL, so oauth2-proxy cannot simply grab the authorization,

63+token and jwks URI endpoints from the provider's metadata.

64+

65+In this case, you can set the `--skip-oidc-discovery` option, and supply those required endpoints manually:

66+

67+```

68+ -provider oidc

69+ -client-id oauth2-proxy

70+ -client-secret proxy

71+ -redirect-url http://127.0.0.1:4180/oauth2/callback

72+ -oidc-issuer-url http://127.0.0.1:5556

73+ -skip-oidc-discovery

74+ -login-url http://127.0.0.1:5556/authorize

75+ -redeem-url http://127.0.0.1:5556/token

76+ -oidc-jwks-url http://127.0.0.1:5556/keys

77+ -cookie-secure=false

78+ -email-domain example.com

79+```

docs/versioned_docs/version-7.14.x/configuration/providers/ms_azure_ad.mdnew file+59

@@ -0,0 +1,59 @@

1+---

2+id: azure

3+title: Azure (Deprecated)

4+---

5+

6+:::note

7+This is the legacy and deprecated provider for Azure, use [Microsoft Entra ID](ms_entra_id.md) if possible.

8+:::

9+

10+## Config Options

11+

12+| Flag | Toml Field | Type | Description | Default |

13+| ---------------- | -------------- | ------ | ---------------------------------------------------------------- | ---------- |

14+| `--azure-tenant` | `azure_tenant` | string | go to a tenant-specific or common (tenant-independent) endpoint. | `"common"` |

15+| `--resource` | `resource` | string | The resource that is protected (Azure AD only) | |

16+

17+## Usage

18+

19+1. Add an application: go to [https://portal.azure.com](https://portal.azure.com), choose **Azure Active Directory**, select

20+ **App registrations** and then click on **New registration**.

21+2. Pick a name, check the supported account type(single-tenant, multi-tenant, etc). In the **Redirect URI** section create a new

22+ **Web** platform entry for each app that you want to protect by the oauth2 proxy(e.g.

23+ https://internal.yourcompanycom/oauth2/callback). Click **Register**.

24+3. Next we need to add group read permissions for the app registration, on the **API Permissions** page of the app, click on

25+ **Add a permission**, select **Microsoft Graph**, then select **Application permissions**, then click on **Group** and select

26+ **Group.Read.All**. Hit **Add permissions** and then on **Grant admin consent** (you might need an admin to do this).

27+ <br/>**IMPORTANT**: Even if this permission is listed with **"Admin consent required=No"** the consent might actually

28+ be required, due to AAD policies you won't be able to see. If you get a **"Need admin approval"** during login,

29+ most likely this is what you're missing!

30+4. Next, if you are planning to use v2.0 Azure Auth endpoint, go to the **Manifest** page and set `"accessTokenAcceptedVersion": 2`

31+ in the App registration manifest file.

32+5. On the **Certificates & secrets** page of the app, add a new client secret and note down the value after hitting **Add**.

33+6. Configure the proxy with:

34+- for V1 Azure Auth endpoint (Azure Active Directory Endpoints - https://login.microsoftonline.com/common/oauth2/authorize)

35+

36+```

37+ --provider=azure

38+ --client-id=<application ID from step 3>

39+ --client-secret=<value from step 5>

40+ --azure-tenant={tenant-id}

41+ --oidc-issuer-url=https://sts.windows.net/{tenant-id}/

42+```

43+

44+- for V2 Azure Auth endpoint (Microsoft Identity Platform Endpoints - https://login.microsoftonline.com/common/oauth2/v2.0/authorize)

45+```

46+ --provider=azure

47+ --client-id=<application ID from step 3>

48+ --client-secret=<value from step 5>

49+ --azure-tenant={tenant-id}

50+ --oidc-issuer-url=https://login.microsoftonline.com/{tenant-id}/v2.0

51+```

52+

53+***Notes***:

54+- When using v2.0 Azure Auth endpoint (`https://login.microsoftonline.com/{tenant-id}/v2.0`) as `--oidc_issuer_url`, in conjunction

55+ with `--resource` flag, be sure to append `/.default` at the end of the resource name. See

56+ https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope for more details.

57+- When using the Azure Auth provider with nginx and the cookie session store you may find the cookie is too large and doesn't

58+ get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the

59+ [redis session storage](../sessions.md#redis-storage) should resolve this.

docs/versioned_docs/version-7.14.x/configuration/providers/ms_entra_id.mdnew file+197

@@ -0,0 +1,197 @@

1+---

2+id: ms_entra_id

3+title: Microsoft Entra ID

4+---

5+

6+Provider for Microsoft Entra ID. Fully compliant with OIDC, with support for group overage and multi-tenant apps.

7+

8+## Config Options

9+

10+The provider is OIDC-compliant, so all the OIDC parameters are honored. Additional provider-specific configuration parameters are:

11+

12+| Flag | Toml Field | Type | Description | Default |

13+| --------------------------- | -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

14+| `--entra-id-allowed-tenant` | `entra_id_allowed_tenants` | string \| list | List of allowed tenants. In case of multi-tenant apps, incoming tokens are issued by different issuers and OIDC issuer verification needs to be disabled. When not specified, all tenants are allowed. Redundant for single-tenant apps (regular ID token validation matches the issuer). | |

15+| `--entra-id-federated-token-auth` | `entra_id_federated_token_auth` | boolean | Enable oAuth2 client authentication with federated token projected by Entra Workload Identity plugin, instead of client secret. | false |

16+

17+## Configure App registration

18+To begin, create an App registration, set a redirect URI, and generate a secret. All account types are supported, including single-tenant, multi-tenant, multi-tenant with Microsoft accounts, and Microsoft accounts only.

19+

20+<details>

21+ <summary>See Azure Portal example</summary>

22+ <div class="videoBlock">

23+ <iframe src="https://www.youtube.com/embed/IUNfxhOzr4E"></iframe>

24+ </div>

25+</details>

26+

27+<details>

28+ <summary>See Terraform example</summary>

29+```

30+ resource "azuread_application" "auth" {

31+ display_name = "oauth2-proxy"

32+ sign_in_audience = "AzureADMyOrg" # Others are also supported

33+

34+ web {

35+ redirect_uris = [

36+ "https://podinfo.lakis.tech/oauth2/callback",

37+ ]

38+ }

39+ // We don't specify any required API permissions - we allow user consent only

40+ }

41+

42+ resource "azuread_service_principal" "sp" {

43+ client_id = azuread_application.auth.client_id

44+ app_role_assignment_required = false

45+ }

46+

47+ resource "azuread_service_principal_password" "pass" {

48+ service_principal_id = azuread_service_principal.sp.id

49+ }

50+

51+```

52+</details>

53+

54+### Configure groups

55+If you want to make use of groups, you can configure *groups claim* to be present in ID Tokens issued by the App registration.

56+<details>

57+ <summary>See Azure Portal example</summary>

58+ <div class="videoBlock">

59+ <div class="videoBlock">

60+ <iframe src="https://www.youtube.com/embed/QZmP5MKEJis"></iframe>

61+ </div>

62+ </div>

63+</details>

64+<details>

65+ <summary>See Terraform example</summary>

66+```

67+ resource "azuread_application" "auth" {

68+ display_name = "oauth2-proxy"

69+ sign_in_audience = "AzureADMyOrg"

70+

71+ group_membership_claims = [

72+ "SecurityGroup"

73+ ]

74+

75+ web {

76+ redirect_uris = [

77+ "https://podinfo.lakis.tech/oauth2/callback",

78+ ]

79+ }

80+ }

81+

82+ resource "azuread_service_principal" "sp" {

83+ client_id = azuread_application.auth.client_id

84+ app_role_assignment_required = false

85+ }

86+

87+ resource "azuread_service_principal_password" "pass" {

88+ service_principal_id = azuread_service_principal.sp.id

89+ }

90+

91+```

92+</details>

93+

94+### Scopes and claims

95+For single-tenant and multi-tenant apps without groups, the only required scope is `openid` (See: [Scopes and permissions](https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc#the-openid-scope)).

96+

97+To make use of groups - for example use `allowed_groups` setting or authorize based on groups inside your service - you need to enable *groups claims* in the App Registration. When enabled, list of groups is present in the issued ID token. No additional scopes are required besides `openid`. This works up to 200 groups.

98+

99+When user has more than 200 group memberships, OAuth2-Proxy attempts to retrieve the complete list from Microsoft Graph API's [`transitiveMemberOf`](https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof). Endpoint requires `User.Read` scope (delegated permission). This permission can be by default consented by user during first login. Set scope to `openid User.Read` to request user consent. Without proper scope, user with 200+ groups will authenticate with 0 groups. See: [group overages](https://learn.microsoft.com/en-us/security/zero-trust/develop/configure-tokens-group-claims-app-roles#group-overages).

100+

101+Alternatively to user consent, both `openid` and `User.Read` permissions can be consented by admistrator. Then, user is not asked for consent on the first login, and group overage works with `openid` scope only. Admin consent can also be required for some tenants. It can be granted with [azuread_service_principal_delegated_permission_grant](https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/service_principal_delegated_permission_grant) terraform resource.

102+

103+For personal microsoft accounts, required scope is `openid profile email`.

104+

105+See: [Overview of permissions and consent in the Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview).

106+

107+### Multi-tenant apps

108+To authenticate apps from multiple tenants (including personal Microsoft accounts), set the common OIDC issuer url and disable verification:

109+```toml

110+oidc_issuer_url=https://login.microsoftonline.com/common/v2.0

111+insecure_oidc_skip_issuer_verification=true

112+```

113+`insecure_oidc_skip_issuer_verification` setting is required to disable following checks:

114+* Startup check for matching issuer URL returned from [discovery document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) with `oidc_issuer_url` setting. Required, as document's `issuer` field doesn't equal to `https://login.microsoftonline.com/common/v2.0`. See [OIDC Discovery 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation).

115+* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by different tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

116+

117+To provide additional security, Entra ID provider performs check on the ID token's `issuer` claim to match the `https://login.microsoftonline.com/{tenant-id}/v2.0` template.

118+

119+### Workload Identity

120+Provider supports authentication with federated token, without need of using client secret. Following conditions have to be met:

121+

122+* Cluster has public OIDC provider URL. For major cloud providers, it can be enabled with a single flag, for example for [Azure Kubernetes Service deployed with Terraform](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/kubernetes_cluster), it's `oidc_issuer_enabled`.

123+* Workload Identity admission webhook is deployed on the cluster. For AKS, it can be enabled with a flag (`workload_identity_enabled` in Terraform resource), for clusters outside of Azure, it can be installed from [helm chart](https://github.com/Azure/azure-workload-identity).

124+* Appropriate federated credential is added to application registration.

125+<details>

126+ <summary>See federated credential terraform example</summary>

127+```

128+ resource "azuread_application_federated_identity_credential" "fedcred" {

129+ application_id = azuread_application.application.id # ID of your application

130+ display_name = "federation-cred"

131+ description = "Workload identity for oauth2-proxy"

132+ audiences = ["api://AzureADTokenExchange"] # Fixed value

133+ issuer = "https://cluster-oidc-issuer-url..."

134+ subject = "system:serviceaccount:oauth2-proxy-namespace-name:oauth2-proxy-sa-name" # set proper NS and SA name

135+ }

136+```

137+</details>

138+

139+* Kubernetes service account associated with oauth2-proxy deployment, is annotated with `azure.workload.identity/client-id: <app-registration-client-id>`

140+* oauth2-proxy pod is labeled with `azure.workload.identity/use: "true"`

141+* oauth2-proxy is configured with `entra_id_federated_token_auth` set to `true`.

142+

143+`client_secret` setting can be omitted when using federated token authentication.

144+

145+See: [Azure Workload Identity documentation](https://azure.github.io/azure-workload-identity/docs/).

146+

147+### Example configurations

148+Single-tenant app without groups (*groups claim* not enabled). Consider using generic OIDC provider:

149+```toml

150+provider="entra-id"

151+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

152+client_id="<client-id>"

153+client_secret="<client-secret>"

154+scope="openid"

155+```

156+

157+Single-tenant app with up to 200 groups (*groups claim* enabled). Consider using generic OIDC provider:

158+```toml

159+provider="entra-id"

160+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

161+client_id="<client-id>"

162+client_secret="<client-secret>"

163+scope="openid"

164+allowed_groups=["ac51800c-2679-4ecb-8130-636380a3b491"]

165+```

166+

167+Single-tenant app with more than 200 groups:

168+```toml

169+provider="entra-id"

170+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

171+client_id="<client-id>"

172+client_secret="<client-secret>"

173+scope="openid User.Read"

174+allowed_groups=["968b4844-d5e7-4e18-a834-59927959369f"]

175+```

176+

177+Single-tenant app with more than 200 groups and workload identity enabled:

178+```toml

179+provider="entra-id"

180+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

181+client_id="<client-id>"

182+scope="openid User.Read"

183+allowed_groups=["968b4844-d5e7-4e18-a834-59927959369f"]

184+entra_id_federated_token_auth=true

185+```

186+

187+Multi-tenant app with Microsoft personal accounts & one Entra tenant allowed, with group overage considered:

188+```toml

189+provider="entra-id"

190+oidc_issuer_url="https://login.microsoftonline.com/common/v2.0"

191+client_id="<client-id>"

192+client_secret="<client-secret>"

193+insecure_oidc_skip_issuer_verification=true

194+scope="openid profile email User.Read"

195+entra_id_allowed_tenants=["9188040d-6c67-4c5b-b112-36a304b66dad","<my-tenant-id>"] # Allow only <my-tenant-id> and Personal MS Accounts tenant

196+email_domains="*"

197+```

docs/versioned_docs/version-7.14.x/configuration/providers/nextcloud.mdnew file+28

@@ -0,0 +1,28 @@

1+---

2+id: nextcloud

3+title: NextCloud

4+---

5+

6+The Nextcloud provider allows you to authenticate against users in your

7+Nextcloud instance.

8+

9+When you are using the Nextcloud provider, you must specify the urls via

10+configuration, environment variable, or command line argument. Depending

11+on whether your Nextcloud instance is using pretty urls your urls may be of the

12+form `/index.php/apps/oauth2/*` or `/apps/oauth2/*`.

13+

14+Refer to the [OAuth2

15+documentation](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/oauth2.html)

16+to set up the client id and client secret. Your "Redirection URI" will be

17+`https://internalapp.yourcompany.com/oauth2/callback`.

18+

19+```

20+ -provider nextcloud

21+ -client-id <from nextcloud admin>

22+ -client-secret <from nextcloud admin>

23+ -login-url="<your nextcloud url>/index.php/apps/oauth2/authorize"

24+ -redeem-url="<your nextcloud url>/index.php/apps/oauth2/api/v1/token"

25+ -validate-url="<your nextcloud url>/ocs/v2.php/cloud/user?format=json"

26+```

27+

28+Note: in *all* cases the validate-url will *not* have the `index.php`.

docs/versioned_docs/version-7.14.x/configuration/providers/openid_connect.mdnew file+146

@@ -0,0 +1,146 @@

1+---

2+id: openid_connect

3+title: OpenID Connect

4+---

5+

6+OpenID Connect is a spec for OAUTH 2.0 + identity that is implemented by many major providers and several open source projects.

7+

8+This provider was originally built against CoreOS Dex, and we will use it as an example.

9+The OpenID Connect Provider (OIDC) can also be used to connect to other Identity Providers such as Okta, an example can be found below.

10+

11+#### Dex

12+

13+To configure the OIDC provider for Dex, perform the following steps:

14+

15+1. Download Dex:

16+

17+ ```

18+ go get github.com/dexidp/dex

19+ ```

20+

21+ See the [getting started guide](https://dexidp.io/docs/getting-started/) for more details.

22+

23+2. Setup oauth2-proxy with the correct provider and using the default ports and callbacks. Add a configuration block to

24+ the `staticClients` section of `examples/config-dev.yaml`:

25+

26+ ```

27+ - id: oauth2-proxy

28+ redirectURIs:

29+ - 'http://127.0.0.1:4180/oauth2/callback'

30+ name: 'oauth2-proxy'

31+ secret: proxy

32+ ```

33+

34+3. Launch Dex: from `$GOPATH/github.com/dexidp/dex`, run:

35+

36+ ```

37+ bin/dex serve examples/config-dev.yaml

38+ ```

39+

40+4. In a second terminal, run the oauth2-proxy with the following args:

41+

42+ ```shell

43+ --provider oidc

44+ --provider-display-name "My OIDC Provider"

45+ --client-id oauth2-proxy

46+ --client-secret proxy

47+ --redirect-url http://127.0.0.1:4180/oauth2/callback

48+ --oidc-issuer-url http://127.0.0.1:5556/dex

49+ --cookie-secure=false

50+ --cookie-secret=secret

51+ --email-domain kilgore.trout

52+ ```

53+

54+ To serve the current working directory as a website under the `/static` endpoint, add:

55+

56+ ```shell

57+ --upstream file://$PWD/#/static/

58+ ```

59+

60+5. Test the setup by visiting http://127.0.0.1:4180 or http://127.0.0.1:4180/static .

61+

62+See also [our local testing environment](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/local-environment) for a self-contained example using Docker and etcd as storage for Dex.

63+

64+#### Okta

65+

66+To configure the OIDC provider for Okta, perform the following steps:

67+

68+1. Log in to Okta using an administrative account. It is suggested you try this in preview first, `example.oktapreview.com`

69+2. (OPTIONAL) If you want to configure authorization scopes and claims to be passed on to multiple applications,

70+ you may wish to configure an authorization server for each application. Otherwise, the provided `default` will work.

71+ * Navigate to **Security** then select **API**

72+ * Click **Add Authorization Server**, if this option is not available you may require an additional license for a custom

73+ authorization server.

74+ * Fill out the **Name** with something to describe the application you are protecting. e.g. 'Example App'.

75+ * For **Audience**, pick the URL of the application you wish to protect: https://example.corp.com

76+ * Fill out a **Description**

77+ * Add any **Access Policies** you wish to configure to limit application access.

78+ * The default settings will work for other options.

79+ [See Okta documentation for more information on Authorization Servers](https://developer.okta.com/docs/guides/customize-authz-server/overview/)

80+3. Navigate to **Applications** then select **Add Application**.

81+ * Select **Web** for the **Platform** setting.

82+ * Select **OpenID Connect** and click **Create**

83+ * Pick an **Application Name** such as `Example App`.

84+ * Set the **Login redirect URI** to `https://example.corp.com`.

85+ * Under **General** set the **Allowed grant types** to `Authorization Code` and `Refresh Token`.

86+ * Leave the rest as default, taking note of the `Client ID` and `Client Secret`.

87+ * Under **Assignments** select the users or groups you wish to access your application.

88+4. Create a configuration file like the following:

89+

90+ ```

91+ provider = "oidc"

92+ redirect_url = "https://example.corp.com/oauth2/callback"

93+ oidc_issuer_url = "https://corp.okta.com/oauth2/abCd1234"

94+ upstreams = [

95+ "https://example.corp.com"

96+ ]

97+ email_domains = [

98+ "corp.com"

99+ ]

100+ client_id = "XXXXX"

101+ client_secret = "YYYYY"

102+ pass_access_token = true

103+ cookie_secret = "ZZZZZ"

104+ skip_provider_button = true

105+ ```

106+

107+The `oidc_issuer_url` is based on URL from your **Authorization Server**'s **Issuer** field in step 2, or simply

108+https://corp.okta.com. The `client_id` and `client_secret` are configured in the application settings.

109+Generate a unique `cookie_secret` to encrypt the cookie.

110+

111+Then you can start the oauth2-proxy with `./oauth2-proxy --config /etc/example.cfg`

112+

113+#### Okta - localhost

114+

115+1. Signup for developer account: https://developer.okta.com/signup/

116+2. Create New `Web` Application: https://$\{your-okta-domain\}/dev/console/apps/new

117+3. Example Application Settings for localhost:

118+ * **Name:** My Web App

119+ * **Base URIs:** http://localhost:4180/

120+ * **Login redirect URIs:** http://localhost:4180/oauth2/callback

121+ * **Logout redirect URIs:** http://localhost:4180/

122+ * **Group assignments:** `Everyone`

123+ * **Grant type allowed:** `Authorization Code` and `Refresh Token`

124+4. Make note of the `Client ID` and `Client secret`, they are needed in a future step

125+5. Make note of the **default** Authorization Server Issuer URI from: https://$\{your-okta-domain\}/admin/oauth2/as

126+6. Example config file `/etc/localhost.cfg`

127+ ```shell

128+ provider = "oidc"

129+ redirect_url = "http://localhost:4180/oauth2/callback"

130+ oidc_issuer_url = "https://$\{your-okta-domain\}/oauth2/default"

131+ upstreams = [

132+ "http://0.0.0.0:8080"

133+ ]

134+ email_domains = [

135+ "*"

136+ ]

137+ client_id = "XXX"

138+ client_secret = "YYY"

139+ pass_access_token = true

140+ cookie_secret = "ZZZ"

141+ cookie_secure = false

142+ skip_provider_button = true

143+ # Note: use the following for testing within a container

144+ # http_address = "0.0.0.0:4180"

145+ ```

146+7. Then you can start the oauth2-proxy with `./oauth2-proxy --config /etc/localhost.cfg`

docs/versioned_docs/version-7.14.x/configuration/providers/sourcehut.mdnew file+25

@@ -0,0 +1,25 @@

1+---

2+id: sourcehut

3+title: SourceHut

4+---

5+

6+1. Create a new OAuth client: https://meta.sr.ht/oauth2

7+2. Under `Redirection URI` enter the correct URL, i.e.

8+ `https://internal.yourcompany.com/oauth2/callback`

9+

10+To use the provider, start with `--provider=sourcehut`.

11+

12+If you are hosting your own SourceHut instance, make sure you set the following

13+to the appropriate URLs:

14+

15+```shell

16+ --login-url="https://<meta.your.instance>/oauth2/authorize"

17+ --redeem-url="https://<meta.your.instance>/oauth2/access-token"

18+ --profile-url="https://<meta.your.instance>/query"

19+ --validate-url="https://<meta.your.instance>/profile"

20+```

21+

22+The default configuration allows everyone with an account to authenticate.

23+Restricting access is currently only supported by

24+[email](index.md#email-authentication).

25+

docs/versioned_docs/version-7.14.x/configuration/sessions.mdnew file+99

@@ -0,0 +1,99 @@

1+---

2+id: session_storage

3+title: Session Storage

4+---

5+

6+Sessions allow a user's authentication to be tracked between multiple HTTP

7+requests to a service.

8+

9+The OAuth2 Proxy uses a Cookie to track user sessions and will store the session

10+data in one of the available session storage backends.

11+

12+At present the available backends are (as passed to `--session-store-type`):

13+- [cookie](#cookie-storage) (default)

14+- [redis](#redis-storage)

15+

16+### Cookie Storage

17+

18+The Cookie storage backend is the default backend implementation and has

19+been used in the OAuth2 Proxy historically.

20+

21+With the Cookie storage backend, all session information is stored in client

22+side cookies and transferred with each and every request.

23+

24+The following should be known when using this implementation:

25+- Since all state is stored client side, this storage backend means that the OAuth2 Proxy is completely stateless

26+- Cookies are signed server side to prevent modification client-side

27+- It is mandatory to set a `cookie-secret` which will ensure data is encrypted within the cookie data.

28+- Since multiple requests can be made concurrently to the OAuth2 Proxy, this session implementation

29+cannot lock sessions and while updating and refreshing sessions, there can be conflicts which force

30+users to re-authenticate

31+

32+

33+### Redis Storage

34+

35+The Redis Storage backend stores encrypted sessions in redis. Instead of sending all the information

36+back the client for storage, as in the [Cookie storage](#cookie-storage), a ticket is sent back

37+to the user as the cookie value instead.

38+

39+A ticket is composed as the following:

40+

41+`{CookieName}-{ticketID}.{secret}`

42+

43+Where:

44+

45+- The `CookieName` is the OAuth2 cookie name (_oauth2_proxy by default)

46+- The `ticketID` is a 128-bit random number, hex-encoded

47+- The `secret` is a 128-bit random number, base64url encoded (no padding). The secret is unique for every session.

48+- The pair of `{CookieName}-{ticketID}` comprises a ticket handle, and thus, the redis key

49+to which the session is stored. The encoded session is encrypted with the secret and stored

50+in redis via the `SETEX` command.

51+

52+Encrypting every session uniquely protects the refresh/access/id tokens stored in the session from

53+disclosure. Additionally, the browser only has to send a short Cookie with every request and not the whole JWT,

54+which can get quite big.

55+

56+Two settings are used to configure the OAuth2 Proxy cookie lifetime:

57+

58+ --cookie-refresh duration refresh the cookie after this duration; 0 to disable

59+ --cookie-expire duration expire timeframe for cookie 168h0m0s

60+

61+The "cookie-expire" value should be equal to the lifetime of the Refresh-Token that is issued by the OAuth2 authorization server.

62+If it expires earlier and is deleted by the browser, OAuth2 Proxy cannot find the stored Refresh-Tokens in Redis and thus cannot start

63+the refresh flow to get a new Access-Token. If it is longer, it might be that the old Refresh-Token will be found in Redis but has already

64+expired.

65+

66+The "cookie-refresh" value controls when OAuth2 Proxy tries to refresh an Access-Token. If it is set to "0", the

67+Access-Token will never be refreshed, even if it is already expired and a valid Refresh-Token is available. If set, OAuth2 Proxy will

68+refresh the Access-Token after this many seconds whether it is still valid or not. According to the official OAuth2.0 specification

69+Access-Tokens are not required to follow a specific format. Therefore OAuth2 Proxy cannot check for any expiry date without an

70+introspection endpoint. If an Access-Token expires and you have not set a corresponding "cookie-refresh" value, you will likely

71+encounter expiry issues.

72+

73+Caveat: It can happen that the Access-Token is valid for e.g. "1m" and a request happens after exactly "59s".

74+It would pass OAuth2 Proxy and be forwarded to the backend but is just expired when the backend tries to validate

75+it. This is especially relevant if the backend uses the JWT to make requests to other backends.

76+For this reason, it's advised to set the cookie-refresh a couple of seconds less than the Access-Token lifespan.

77+

78+Recommended settings:

79+

80+* cookie_refresh := Access-Token lifespan - 1m

81+* cookie_expire := Refresh-Token lifespan (i.e. Keycloak client_session_idle)

82+

83+#### Usage

84+

85+When using the redis store, specify `--session-store-type=redis` as well as the Redis connection URL, via

86+`--redis-connection-url=redis://host[:port][/db-number]`.

87+

88+You may also configure the store for Redis Sentinel. In this case, you will want to use the

89+`--redis-use-sentinel=true` flag, as well as configure the flags `--redis-sentinel-master-name`

90+and `--redis-sentinel-connection-urls` appropriately.

91+

92+Redis Cluster is available to be the backend store as well. To leverage it, you will need to set the

93+`--redis-use-cluster=true` flag, and configure the flags `--redis-cluster-connection-urls` appropriately.

94+

95+Note that flags `--redis-use-sentinel=true` and `--redis-use-cluster=true` are mutually exclusive.

96+

97+Note, if Redis timeout option is set to non-zero, the `--redis-connection-idle-timeout`

98+must be less than [Redis timeout option](https://redis.io/docs/reference/clients/#client-timeouts). For example: if either redis.conf includes

99+`timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14`

docs/versioned_docs/version-7.14.x/configuration/systemd_socket.mdnew file+43

@@ -0,0 +1,43 @@

1+---

2+id: systemd_socket

3+title: Systemd Socket Activation

4+---

5+

6+Pass an existing listener created by systemd.socket to oauth2-proxy.

7+

8+To do this create a socket:

9+

10+oauth2-proxy.socket

11+```

12+[Socket]

13+ListenStream=%t/oauth2.sock

14+SocketGroup=www-data

15+SocketMode=0660

16+```

17+

18+Now it's possible to call this socket from e.g. nginx:

19+```

20+server {

21+ location /oauth2/ {

22+ proxy_pass http://unix:/run/oauth2-proxy/oauth2.sock;

23+}

24+```

25+

26+The oauth2-proxy should have `--http-address=fd:3` as a parameter.

27+Here fd is case insensitive and means file descriptor. The number 3 refers to the first non-stdin/stdout/stderr file descriptor,

28+systemd-socket-activate (which is what systemd.socket uses), listens to what it is told and passes

29+the listener it created onto the process, starting with file descriptor 3.

30+

31+```

32+./oauth2-proxy \

33+ --http-address="fd:3" \

34+ --email-domain="yourcompany.com" \

35+ --upstream=http://127.0.0.1:8080/ \

36+ --cookie-secret=... \

37+ --cookie-secure=true \

38+ --provider=... \

39+ --client-id=... \

40+ --client-secret=...

41+```

42+

43+Currently TLS is not supported (but it's doable).

docs/versioned_docs/version-7.14.x/configuration/tls.mdnew file+85

@@ -0,0 +1,85 @@

1+---

2+id: tls

3+title: TLS Configuration

4+---

5+

6+There are two recommended configurations:

7+- [At OAuth2 Proxy](#terminate-tls-at-oauth2-proxy)

8+- [At Reverse Proxy](#terminate-tls-at-reverse-proxy-eg-nginx)

9+

10+### Terminate TLS at OAuth2 Proxy

11+

12+1. Configure SSL Termination with OAuth2 Proxy by providing a `--tls-cert-file=/path/to/cert.pem` and `--tls-key-file=/path/to/cert.key`.

13+

14+ The command line to run `oauth2-proxy` in this configuration would look like this:

15+

16+ ```bash

17+ ./oauth2-proxy \

18+ --email-domain="yourcompany.com" \

19+ --upstream=http://127.0.0.1:8080/ \

20+ --tls-cert-file=/path/to/cert.pem \

21+ --tls-key-file=/path/to/cert.key \

22+ --cookie-secret=... \

23+ --cookie-secure=true \

24+ --provider=... \

25+ --client-id=... \

26+ --client-secret=...

27+ ```

28+

29+2. With this configuration approach the customization of the TLS settings is limited.

30+

31+ The minimal acceptable TLS version can be set with `--tls-min-version=TLS1.3`.

32+ The defaults set `TLS1.2` as the minimal version.

33+ Regardless of the minimum version configured, `TLS1.3` is currently always used as the maximal version.

34+

35+ TLS server side cipher suites can be specified with `--tls-cipher-suite=TLS_RSA_WITH_RC4_128_SHA`.

36+ If not specified, the defaults from [`crypto/tls`](https://pkg.go.dev/crypto/tls#CipherSuites) of the currently used `go` version for building `oauth2-proxy` will be used.

37+ A complete list of valid TLS cipher suite names can be found in [`crypto/tls`](https://pkg.go.dev/crypto/tls#pkg-constants).

38+

39+### Terminate TLS at Reverse Proxy, e.g. Nginx

40+

41+1. Configure SSL Termination with [Nginx](http://nginx.org/) (example config below), Amazon ELB, Google Cloud Platform Load Balancing, or ...

42+

43+ Because `oauth2-proxy` listens on `127.0.0.1:4180` by default, to listen on all interfaces (needed when using an

44+ external load balancer like Amazon ELB or Google Platform Load Balancing) use `--http-address="0.0.0.0:4180"` or

45+ `--http-address="http://:4180"`.

46+

47+ Nginx will listen on port `443` and handle SSL connections while proxying to `oauth2-proxy` on port `4180`.

48+ `oauth2-proxy` will then authenticate requests for an upstream application. The external endpoint for this example

49+ would be `https://internal.yourcompany.com/`.

50+

51+ An example Nginx config follows. Note the use of `Strict-Transport-Security` header to pin requests to SSL

52+ via [HSTS](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security):

53+

54+ ```

55+ server {

56+ listen 443 default ssl;

57+ server_name internal.yourcompany.com;

58+ ssl_certificate /path/to/cert.pem;

59+ ssl_certificate_key /path/to/cert.key;

60+ add_header Strict-Transport-Security max-age=2592000;

61+

62+ location / {

63+ proxy_pass http://127.0.0.1:4180;

64+ proxy_set_header Host $host;

65+ proxy_set_header X-Real-IP $remote_addr;

66+ proxy_connect_timeout 1;

67+ proxy_send_timeout 30;

68+ proxy_read_timeout 30;

69+ }

70+ }

71+ ```

72+

73+2. The command line to run `oauth2-proxy` in this configuration would look like this:

74+

75+ ```bash

76+ ./oauth2-proxy \

77+ --email-domain="yourcompany.com" \

78+ --upstream=http://127.0.0.1:8080/ \

79+ --cookie-secret=... \

80+ --cookie-secure=true \

81+ --provider=... \

82+ --reverse-proxy=true \

83+ --client-id=... \

84+ --client-secret=...

85+ ```

docs/versioned_docs/version-7.14.x/features/endpoints.mdnew file+59

@@ -0,0 +1,59 @@

1+---

2+id: endpoints

3+title: Endpoints

4+---

5+

6+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.

7+

8+- / - the proxy endpoint provides authentication and returns the appropriate 40x error if not authenticated or authorized then passes the request upstream.

9+- /robots.txt - returns a 200 OK response that disallows all User-agents from all paths; see [robotstxt.org](http://www.robotstxt.org/) for more info

10+- /ping - returns a 200 OK response, which is intended for use with health checks

11+- /ready - returns a 200 OK response if all the underlying connections (e.g., Redis store) are connected

12+- /metrics - Metrics endpoint for Prometheus to scrape, serve on the address specified by `--metrics-address`, disabled by default

13+- /oauth2/sign_in - the login page, which also doubles as a sign-out page (it clears cookies)

14+- /oauth2/sign_out - this URL is used to clear the session cookie

15+- /oauth2/start - a URL that will redirect to start the OAuth cycle

16+- /oauth2/callback - the URL used at the end of the OAuth cycle. The oauth app will be configured with this as the callback url.

17+- /oauth2/userinfo - the URL is used to return user's email from the session in JSON format.

18+- /oauth2/auth - only returns a 202 Accepted response or a 401 Unauthorized response; for use with the [Nginx `auth_request` directive](../configuration/integrations/nginx)

19+- /oauth2/static/\* - stylesheets and other dependencies used in the sign_in and error pages

20+

21+### Sign out

22+

23+To sign the user out, redirect them to `/oauth2/sign_out`. This endpoint only removes oauth2-proxy's own cookies, i.e. the user is still logged in with the authentication provider and may automatically re-login when accessing the application again. You will also need to redirect the user to the authentication provider's sign-out page afterward using the `rd` query parameter, i.e. redirect the user to something like (notice the url-encoding!):

24+

25+```

26+/oauth2/sign_out?rd=https%3A%2F%2Fmy-oidc-provider.example.com%2Fsign_out_page

27+```

28+

29+Alternatively, include the redirect URL in the `X-Auth-Request-Redirect` header:

30+

31+```

32+GET /oauth2/sign_out HTTP/1.1

33+X-Auth-Request-Redirect: https://my-oidc-provider/sign_out_page

34+...

35+```

36+

37+(The "sign_out_page" should be the [`end_session_endpoint`](https://openid.net/specs/openid-connect-session-1_0.html#rfc.section.2.1) from [the metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) if your OIDC provider supports Session Management and Discovery.)

38+

39+BEWARE that the domain you want to redirect to (`my-oidc-provider.example.com` in the example) must be added to the [`--whitelist-domain`](../configuration/overview) configuration option otherwise the redirect will be ignored. Make sure to include the actual domain and port (if needed) and not the URL (e.g "localhost:8081" instead of "http://localhost:8081").

40+

41+### Auth

42+

43+This endpoint returns 202 Accepted response or a 401 Unauthorized response.

44+

45+It can be configured using the following query parameters:

46+- `allowed_groups`: comma separated list of allowed groups

47+- `allowed_email_domains`: comma separated list of allowed email domains

48+- `allowed_emails`: comma separated list of allowed emails

49+

50+### Proxy (/)

51+

52+This endpoint returns the upstream response if authenticated.

53+If unauthenticated it returns a 401 Unauthorized. If the authenticatd user

54+is not in one of the allowed groups, or emails then it returns a 403 forbidden

55+

56+It can be configured using the following query parameters:

57+- `allowed_groups`: comma separated list of allowed groups

58+- `allowed_email_domains`: comma separated list of allowed email domains

59+- `allowed_emails`: comma separated list of allowed emails

docs/versioned_docs/version-7.14.x/installation.mdnew file+32

@@ -0,0 +1,32 @@

1+---

2+id: installation

3+title: Installation

4+---

5+

6+1. Choose how to deploy:

7+

8+ a. Using a [Prebuilt Binary](https://github.com/oauth2-proxy/oauth2-proxy/releases) (current release is `v7.14.3`)

9+

10+ b. Using Go to install the latest release

11+ ```bash

12+ $ go install github.com/oauth2-proxy/oauth2-proxy/v7@latest

13+ ```

14+ This will install the binary into `$GOPATH/bin`. Make sure you include `$GOPATH` in your `$PATH`. Otherwise your system won't find binaries installed via `go install`

15+

16+ c. Using a [Prebuilt Docker Image](https://quay.io/oauth2-proxy/oauth2-proxy) (AMD64, PPC64LE, S390x, ARMv6, ARMv7, and ARM64 available)

17+

18+ d. Using a [Pre-Release Nightly Docker Image](https://quay.io/oauth2-proxy/oauth2-proxy-nightly) (AMD64, PPC64LE, ARMv6, ARMv7, and ARM64 available)

19+

20+ e. Using the official [Kubernetes manifest](https://github.com/oauth2-proxy/manifests) (Helm)

21+

22+ Prebuilt binaries can be validated by extracting the file and verifying it against the `sha256sum.txt` checksum file provided for each release starting with version `v3.0.0`.

23+

24+ ```

25+ $ sha256sum -c sha256sum.txt

26+ oauth2-proxy-x.y.z.linux-amd64: OK

27+ ```

28+

29+2. [Select a Provider and Register an OAuth Application with a Provider](configuration/providers/index.md)

30+3. [Configure OAuth2 Proxy using config file, command line options, or environment variables](configuration/overview.md)

31+4. [Configure SSL or Deploy behind an SSL endpoint](configuration/tls.md) (example provided for Nginx)

32+5. [Configure OAuth2 Proxy using systemd.socket](configuration/systemd_socket.md) (example provided for Nginx/Systemd)

docs/versioned_docs/version-7.14.x/welcome.mdnew file+32

@@ -0,0 +1,32 @@

1+---

2+id: welcome

3+title: Welcome

4+hide_table_of_contents: true

5+slug: /

6+---

7+

8+

9+

10+A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others)

11+to validate accounts by email, domain or group.

12+

13+:::note

14+This repository was forked from [bitly/OAuth2_Proxy](https://github.com/bitly/oauth2_proxy) on 27/11/2018.

15+Versions v3.0.0 and up are from this fork and will have diverged from any changes in the original fork.

16+A list of changes can be seen in the [CHANGELOG](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/CHANGELOG.md).

17+:::

18+

19+

20+

21+## Architecture

22+

23+

24+

25+## Cloud Native Computing Foundation

26+

27+OAuth2 Proxy is a [Cloud Native Computing Foundation](https://cncf.io) Sandbox project.

28+

29+

30+

31+The Linux Foundation® (TLF) has registered trademarks and uses trademarks. For a list of TLF trademarks, see [Trademark Usage](https://www.linuxfoundation.org/legal/trademark-usage).

32+

docs/versioned_docs/version-7.15.x/behaviour.mdnew file+26

@@ -0,0 +1,26 @@

1+---

2+id: behaviour

3+title: Behaviour

4+---

5+

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

10+

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.15.x/community/contribution.mdnew file+91

@@ -0,0 +1,91 @@

1+---

2+id: contribution

3+title: Contribution Guide

4+---

5+

6+We track bugs and issues using Github.

7+

8+If you find a bug, please open an Issue. When opening an Issue or Pull Request please follow the preconfigured template and take special note of the checkboxes.

9+

10+If you want to fix a bug, add a new feature or extend existing functionality, please create a fork, create a feature branch and open a PR back to this repo.

11+Please mention open bug issue number(s) within your PR if applicable.

12+

13+We suggest using [Visual Studio Code](https://code.visualstudio.com/docs/languages/go) with the official [Go for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=golang.go) extension.

14+

15+

16+# Go version

17+

18+See the `go.mod` file in the root of this repository for the version of Go used by this project.

19+You can follow [the installation guide for Go](https://go.dev/doc/install),

20+and you can find this specific Go version on [the Go downloads page](https://go.dev/dl/).

21+

22+# Preparing your fork

23+Clone your fork, create a feature branch and update the depedencies to get started.

24+```bash

25+git clone git@github.com:<YOUR_FORK>/oauth2-proxy

26+cd oauth2-proxy

27+git branch feature/<BRANCH_NAME>

28+git push --set-upstream origin feature/<BRANCH_NAME>

29+go mod download

30+```

31+

32+

33+# Testing / Debugging

34+For starting oauth2-proxy locally open the debugging tab and create the `launch.json` and select `Go: Launch Package`.

35+

36+

37+```json

38+{

39+ "version": "0.2.0",

40+ "configurations": [

41+ {

42+ "name": "Launch OAuth2 Proxy with Dex",

43+ "type": "go",

44+ "request": "launch",

45+ "mode": "auto",

46+ "program": "${workspaceFolder}",

47+ "args": [

48+ "--config",

49+ // The following configuration contains settings for a locally deployed

50+ // upstream and dex as an idetity provider

51+ "contrib/local-environment/oauth2-proxy.cfg"

52+ ]

53+ },

54+ {

55+ "name": "Launch OAuth2 Proxy with Keycloak",

56+ "type": "go",

57+ "request": "launch",

58+ "mode": "auto",

59+ "program": "${workspaceFolder}",

60+ "args": [

61+ "--config",

62+ // The following configuration contains settings for a locally deployed

63+ // upstream and keycloak as an idetity provider

64+ "contrib/local-environment/oauth2-proxy-keycloak.cfg"

65+ ]

66+ }

67+ ]

68+}

69+```

70+

71+Before you can start your local version of oauth2-proxy, you will have to use the provided docker compose files to start a local upstream service and identity provider. We suggest using [httpbin](https://hub.docker.com/r/kennethreitz/httpbin) as your upstream for testing as it allows for request and response introspection of all things HTTP.

72+

73+Inside the `contrib/local-environment` directory you can use the `Makefile` for

74+starting different example setups:

75+

76+- Dex as your IdP: `make up` or `make down`

77+- Dex as your IdP using the alpha-config: `make alpha-config-up`

78+- Keycloak as your IdP: `make keycloak-up`

79+- Dex as your IdP & nginx reverse proxy: `make nginx-up`

80+- and many more...

81+

82+Check out the `Makefile` to see what is available.

83+

84+The username and password for all setups is usually `admin@example.com` and `password`.

85+

86+The docker compose setups expose the services with a dynamic reverse DNS resolver: localtest.me

87+

88+- OAuth2 Proxy: http://oauth2-proxy.localtest.me:4180

89+- Upstream: http://httpbin.localtest.me:8080

90+- Dex: http://dex.localtest.me:5556

91+

docs/versioned_docs/version-7.15.x/community/security.mdnew file+49

@@ -0,0 +1,49 @@

1+---

2+id: security

3+title: Security

4+---

5+

6+:::note

7+OAuth2 Proxy is a community project.

8+Maintainers do not work on this project full time, and as such,

9+while we endeavour to respond to disclosures as quickly as possible,

10+this may take longer than in projects with corporate sponsorship.

11+:::

12+

13+## Security Disclosures

14+

15+:::important

16+If you believe you have found a vulnerability within OAuth2 Proxy or any of its

17+dependencies, please do NOT open an issue or PR on GitHub, please do NOT post

18+any details publicly.

19+:::

20+

21+Security disclosures MUST be done in private.

22+If you have found an issue that you would like to bring to the attention of the

23+maintenance team for OAuth2 Proxy, please compose an email and send it to the

24+list of maintainers in our [MAINTAINERS.md](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/MAINTAINERS.md) file.

25+

26+Please include as much detail as possible.

27+Ideally, your disclosure should include:

28+- A reproducible case that can be used to demonstrate the exploit

29+- How you discovered this vulnerability

30+- A potential fix for the issue (if you have thought of one)

31+- Versions affected (if not present in master)

32+- Your GitHub ID

33+

34+### How will we respond to disclosures?

35+

36+We use [GitHub Security Advisories](https://docs.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories)

37+to privately discuss fixes for disclosed vulnerabilities.

38+If you include a GitHub ID with your disclosure we will add you as a collaborator

39+for the advisory so that you can join the discussion and validate any fixes

40+we may propose.

41+

42+For minor issues and previously disclosed vulnerabilities (typically for

43+dependencies), we may use regular PRs for fixes and forego the security advisory.

44+

45+Once a fix has been agreed upon, we will merge the fix and create a new release.

46+If we have multiple security issues in flight simultaneously, we may delay

47+merging fixes until all patches are ready.

48+We may also backport the fix to previous releases,

49+but this will be at the discretion of the maintainers.

docs/versioned_docs/version-7.15.x/configuration/alpha_config.mdnew file+702

@@ -0,0 +1,702 @@

1+---

2+id: alpha-config

3+title: Alpha Configuration

4+---

5+

6+:::warning

7+This page contains documentation for alpha features.

8+We reserve the right to make breaking changes to the features detailed within this page with no notice.

9+

10+Options described in this page may be changed, removed, renamed or moved without prior warning.

11+Please beware of this before you use alpha configuration options.

12+:::

13+

14+This page details a set of **alpha** configuration options in a new format.

15+Going forward we are intending to add structured configuration in YAML format to

16+replace the existing TOML based configuration file and flags.

17+

18+Below is a reference for the structure of the configuration, with

19+[AlphaOptions](#alphaoptions) as the root of the configuration.

20+

21+When using alpha configuration, your config file will look something like below:

22+

23+```yaml

24+upstreams:

25+ - id: ...

26+ ...: ...

27+providers:

28+ - id: ...

29+ ...: ...

30+cookie:

31+ secret: ...

32+ ...: ...

33+injectRequestHeaders:

34+ - secretSource:

35+ ...: ...

36+injectResponseHeaders:

37+ - claimSource:

38+ ...: ...

39+```

40+

41+Please browse the [reference](#configuration-reference) below for the structure

42+of the new configuration format.

43+

44+# Migration Guide

45+

46+This section details breaking changes and migration steps for moving to the new

47+alpha configuration format.

48+

49+## Migrating header injections in v7.14.0

50+

51+From v7.14.0 onward, header injection sources must be explicitly nested. If you

52+previously relied on squashed fields, update to the new structure before

53+upgrading:

54+

55+```yaml

56+# before v7.14.0

57+injectRequestHeaders:

58+- name: X-Forwarded-User

59+ values:

60+ - claim: user

61+- name: X-Custom-Secret-header

62+ values:

63+ - value: my-super-secret

64+

65+# v7.14.0 and later

66+injectRequestHeaders:

67+- name: X-Forwarded-User

68+ values:

69+ - claimSource:

70+ claim: user

71+- name: X-Custom-Secret-header

72+ values:

73+ - secretSource:

74+ value: my-super-secret

75+```

76+

77+## Using Alpha Configuration

78+

79+To use the new **alpha** configuration, generate a YAML file based on the format

80+described in the [reference](#configuration-reference) below.

81+

82+Provide the path to this file using the `--alpha-config` flag.

83+

84+:::note

85+When using the `--alpha-config` flag, some options are no longer available.

86+See [removed options](#removed-options) below for more information.

87+:::

88+

89+### Converting configuration to the new structure

90+

91+Before adding the new `--alpha-config` option, start OAuth2 Proxy using the

92+`convert-config-to-alpha` flag to convert existing configuration to the new format.

93+

94+```bash

95+oauth2-proxy --convert-config-to-alpha --config ./path/to/existing/config.cfg

96+```

97+

98+This will convert any options supported by the new format to YAML and print the

99+new configuration to `STDOUT`.

100+

101+Copy this to a new file, remove any options from your existing configuration

102+noted in [removed options](#removed-options) and then start OAuth2 Proxy using

103+the new config.

104+

105+```bash

106+oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

107+```

108+

109+### Validating Alpha Configuration

110+

111+Use `--config-test` to validate your alpha configuration without starting the proxy:

112+

113+```bash

114+oauth2-proxy --config core.cfg --alpha-config alpha.yaml --config-test

115+```

116+

117+This is useful for CI/CD pipelines to catch configuration errors before deployment.

118+See the [Configuration Validation](./overview.md#configuration-validation) section for more details.

119+

120+### How to use environment variables

121+

122+The alpha package supports the use of environment variables in place of yaml values, allowing sensitive data to be pulled from somewhere other than the yaml file.

123+When using environment variables, your yaml will look like this:

124+

125+```yaml

126+ providers:

127+ - provider: azure

128+ clientSecret: ${CLIENT_SECRET}

129+ ...

130+```

131+Where CLIENT_SECRET is an environment variable.

132+More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

133+

134+### How to inject custom headers

135+

136+Configure `injectRequestHeaders` and `injectResponseHeaders` in alpha config YAML.

137+

138+```yaml

139+injectRequestHeaders:

140+ - name: "X-User-Email"

141+ values:

142+ - claimSource:

143+ claim: "email" # extract the email claim contents from the id token

144+ - name: "X-Static-Secret"

145+ values:

146+ # secrets need to be encoded with base64 when directly in the yaml config but will be send decoded

147+ - secretSource:

148+ value: "c3VwZXItc2VjcmV0"

149+ - name: "X-Static-File-Secret"

150+ - secretSource:

151+ fromFile: "/path/to/my/secret"

152+ - name: "X-Static-Env-Secret"

153+ - secretSource:

154+ value: "${MY_SECRET_ENV}" # content still needs to be base64 encoded

155+injectResponseHeaders:

156+ # Following will result in a header "Authorization: Basic <user:password> (encoded)"

157+ - name: "Authorization"

158+ values:

159+ - claimSource:

160+ claim: user

161+ prefix: "Basic "

162+ basicAuthPassword:

163+ value: c3VwZXItc2VjcmV0LXBhc3N3b3Jk # base64 encoded password

164+```

165+

166+**Value sources:**

167+* `claimSource` - `claim` (session claims either from id token or from profile URL)

168+* `secretSource` - `value` (base64), `fromFile` (file path)

169+

170+**Request option:** `preserveRequestValue: true` retains existing header values

171+

172+**Incompatibility:** Remove legacy flags `pass-user-headers`, `set-xauthrequest`

173+

174+### How to utilize arbitrary claims provided by your Identity Provider

175+

176+With the additionalClaims attribute you can specify which claims you want to extract

177+from the ID Token or userinfo (ProfileURL) endpoint.

178+

179+Configure these on the relevant provider entry:

180+

181+```yaml

182+providers:

183+ - id: my-oidc-provider

184+ provider: oidc

185+ clientID: ${OAUTH_CLIENT_ID}

186+ clientSecret: ${OAUTH_CLIENT_SECRET}

187+ oidcConfig:

188+ issuerURL: https://issuer.example.com

189+ profileURL: https://issuer.example.com/oauth2/userinfo

190+ additionalClaims:

191+ - department

192+ - employee_id

193+ - organization.name

194+```

195+

196+OAuth2 Proxy resolves each configured claim using the following order:

197+

198+1. The raw ID token is checked first.

199+2. If the claim is not present there and `profileURL` is configured, the userinfo endpoint is queried.

200+3. If `skipClaimsFromProfileURL: true` is set, only the ID token is used.

201+

202+Claims that are not found are ignored rather than causing authentication to fail.

203+

204+You can use dot-separated paths for nested JSON objects, for example `organization.name`.

205+Array indexes are not supported.

206+

207+Once loaded, these claims are stored in the session as `additionalClaims`. They can then be

208+used anywhere session claims are accepted, including header injection:

209+

210+```yaml

211+injectRequestHeaders:

212+ - name: X-Department

213+ values:

214+ - claimSource:

215+ claim: department

216+ - name: X-Organization

217+ values:

218+ - claimSource:

219+ claim: organization.name

220+```

221+

222+This is useful when your IdP exposes application-specific attributes such as department,

223+tenant, employee ID, entitlement, or other custom claims that are not part of the default

224+OAuth2 Proxy session fields.

225+

226+## Removed options

227+

228+The following flags/options and their respective environment variables are no

229+longer available when using alpha configuration:

230+

231+<!-- Legacy Upstream FlagSet -->

232+- `flush-interval`/`flush_interval`

233+- `pass-host-header`/`pass_host_header`

234+- `proxy-websockets`/`proxy_websockets`

235+- `ssl-upstream-insecure-skip-verify`/`ssl_upstream_insecure_skip_verify`

236+- `upstream`/`upstreams`

237+

238+<!-- Legacy Headers FlagSet -->

239+- `pass-basic-auth`/`pass_basic_auth`

240+- `pass-access-token`/`pass_access_token`

241+- `pass-user-headers`/`pass_user_headers`

242+- `pass-authorization-header`/`pass_authorization_header`

243+- `set-basic-auth`/`set_basic_auth`

244+- `set-xauthrequest`/`set_xauthrequest`

245+- `set-authorization-header`/`set_authorization_header`

246+- `prefer-email-to-user`/`prefer_email_to_user`

247+- `basic-auth-password`/`basic_auth_password`

248+- `skip-auth-strip-headers`/`skip_auth_strip_headers`

249+

250+<!-- Legacy provider FlagSet -->

251+- `client-id`/`client_id`

252+- `client-secret`/`client_secret`, and `client-secret-file`/`client_secret_file`

253+- `provider`

254+- `provider-display-name`/`provider_display_name`

255+- `provider-ca-file`/`provider_ca_files`

256+- `login-url`/`login_url`

257+- `redeem-url`/`redeem_url`

258+- `profile-url`/`profile_url`

259+- `resource`

260+- `validate-url`/`validate_url`

261+- `scope`

262+- `prompt`

263+- `approval-prompt`/`approval_prompt`

264+- `acr-values`/`acr_values`

265+- `user-id-claim`/`user_id_claim`

266+- `allowed-group`/`allowed_groups`

267+- `allowed-role`/`allowed_roles`

268+- `jwt-key`/`jwt_key`

269+- `jwt-key-file`/`jwt_key_file`

270+- `pubjwk-url`/`pubjwk_url`

271+

272+and all provider-specific options, i.e. any option whose name includes `oidc`,

273+`azure`, `bitbucket`, `github`, `gitlab`, `google` or `keycloak`. Attempting to

274+use any of these options via flags or via config when `--alpha-config` is

275+set will result in an error.

276+

277+:::important

278+You must remove these options before starting OAuth2 Proxy with `--alpha-config`

279+:::

280+

281+## Configuration Reference

282+

283+<!--- THIS FILE IS AUTOGENERATED!!! DO NOT EDIT!!! -->

284+

285+### ADFSOptions

286+

287+(**Appears on:** [Provider](#provider))

288+

289+

290+

291+| Field | Type | Description |

292+| ----- | ---- | ----------- |

293+| `skipScope` | _bool_ | Skip adding the scope parameter in login request<br/>Default value is 'false' |

294+

295+### AlphaOptions

296+

297+AlphaOptions contains alpha structured configuration options.

298+Usage of these options allows users to access alpha features that are not

299+available as part of the primary configuration structure for OAuth2 Proxy.

300+

301+:::warning

302+The options within this structure are considered alpha.

303+They may change between releases without notice.

304+:::

305+

306+| Field | Type | Description |

307+| ----- | ---- | ----------- |

308+| `upstreamConfig` | _[UpstreamConfig](#upstreamconfig)_ | UpstreamConfig is used to configure upstream servers.<br/>Once a user is authenticated, requests to the server will be proxied to<br/>these upstream servers based on the path mappings defined in this list. |

309+| `injectRequestHeaders` | _[[]Header](#header)_ | InjectRequestHeaders is used to configure headers that should be added<br/>to requests to upstream servers.<br/>Headers may source values from either the authenticated user's session<br/>or from a static secret value. |

310+| `injectResponseHeaders` | _[[]Header](#header)_ | InjectResponseHeaders is used to configure headers that should be added<br/>to responses from the proxy.<br/>This is typically used when using the proxy as an external authentication<br/>provider in conjunction with another proxy such as NGINX and its<br/>auth_request module.<br/>Headers may source values from either the authenticated user's session<br/>or from a static secret value. |

311+| `server` | _[Server](#server)_ | Server is used to configure the HTTP(S) server for the proxy application.<br/>You may choose to run both HTTP and HTTPS servers simultaneously.<br/>This can be done by setting the BindAddress and the SecureBindAddress simultaneously.<br/>To use the secure server you must configure a TLS certificate and key. |

312+| `metricsServer` | _[Server](#server)_ | MetricsServer is used to configure the HTTP(S) server for metrics.<br/>You may choose to run both HTTP and HTTPS servers simultaneously.<br/>This can be done by setting the BindAddress and the SecureBindAddress simultaneously.<br/>To use the secure server you must configure a TLS certificate and key. |

313+| `providers` | _[Providers](#providers)_ | Providers is used to configure your provider. **Multiple-providers is not<br/>yet working.** [This feature is tracked in<br/>#925](https://github.com/oauth2-proxy/oauth2-proxy/issues/926) |

314+

315+### AzureOptions

316+

317+(**Appears on:** [Provider](#provider))

318+

319+

320+

321+| Field | Type | Description |

322+| ----- | ---- | ----------- |

323+| `tenant` | _string_ | Tenant directs to a tenant-specific or common (tenant-independent) endpoint<br/>Default value is 'common' |

324+| `graphGroupField` | _string_ | GraphGroupField configures the group field to be used when building the groups list from Microsoft Graph<br/>Default value is 'id' |

325+

326+### BitbucketOptions

327+

328+(**Appears on:** [Provider](#provider))

329+

330+

331+

332+| Field | Type | Description |

333+| ----- | ---- | ----------- |

334+| `team` | _string_ | Team sets restrict logins to members of this team |

335+| `repository` | _string_ | Repository sets restrict logins to user with access to this repository |

336+

337+### ClaimSource

338+

339+(**Appears on:** [HeaderValue](#headervalue))

340+

341+ClaimSource allows loading a header value from a claim within the session

342+

343+| Field | Type | Description |

344+| ----- | ---- | ----------- |

345+| `claim` | _string_ | Claim is the name of the claim in the session that the value should be<br/>loaded from. Available claims: `access_token` `id_token` `created_at`<br/>`expires_on` `refresh_token` `email` `user` `groups` `preferred_username`. |

346+| `prefix` | _string_ | Prefix is an optional prefix that will be prepended to the value of the<br/>claim if it is non-empty. |

347+| `basicAuthPassword` | _[SecretSource](#secretsource)_ | BasicAuthPassword converts this claim into a basic auth header.<br/>Note the value of claim will become the basic auth username and the<br/>basicAuthPassword will be used as the password value. |

348+

349+### GitHubOptions

350+

351+(**Appears on:** [Provider](#provider))

352+

353+

354+

355+| Field | Type | Description |

356+| ----- | ---- | ----------- |

357+| `org` | _string_ | Org sets restrict logins to members of this organisation |

358+| `team` | _string_ | Team sets restrict logins to members of this team |

359+| `repo` | _string_ | Repo sets restrict logins to collaborators of this repository |

360+| `token` | _string_ | Token is the token to use when verifying repository collaborators<br/>it must have push access to the repository |

361+| `users` | _[]string_ | Users allows users with these usernames to login<br/>even if they do not belong to the specified org and team or collaborators |

362+

363+### GitLabOptions

364+

365+(**Appears on:** [Provider](#provider))

366+

367+

368+

369+| Field | Type | Description |

370+| ----- | ---- | ----------- |

371+| `group` | _[]string_ | Group sets restrict logins to members of this group |

372+| `projects` | _[]string_ | Projects restricts logins to members of these projects |

373+

374+### GoogleOptions

375+

376+(**Appears on:** [Provider](#provider))

377+

378+

379+

380+| Field | Type | Description |

381+| ----- | ---- | ----------- |

382+| `group` | _[]string_ | Groups sets restrict logins to members of this Google group |

383+| `adminEmail` | _string_ | AdminEmail is the Google admin to impersonate for api calls |

384+| `serviceAccountJson` | _string_ | ServiceAccountJSON is the path to the service account json credentials |

385+| `useApplicationDefaultCredentials` | _bool_ | UseApplicationDefaultCredentials is a boolean whether to use Application Default Credentials instead of a ServiceAccountJSON |

386+| `targetPrincipal` | _string_ | TargetPrincipal is the Google Service Account used for Application Default Credentials |

387+| `useOrganizationID` | _bool_ | UseOrganizationId indicates whether to use the organization ID as the UserName claim |

388+| `adminAPIUserScope` | _string_ | admin scope needed for fetching user organization information from admin api, can be one of cloud, user or defaults to readonly |

389+

390+### Header

391+

392+(**Appears on:** [AlphaOptions](#alphaoptions))

393+

394+Header represents an individual header that will be added to a request or

395+response header.

396+

397+| Field | Type | Description |

398+| ----- | ---- | ----------- |

399+| `name` | _string_ | Name is the header name to be used for this set of values.<br/>Names should be unique within a list of Headers. |

400+| `preserveRequestValue` | _bool_ | PreserveRequestValue determines whether any values for this header<br/>should be preserved for the request to the upstream server.<br/>This option only applies to injected request headers.<br/>Defaults to false (headers that match this header will be stripped). |

401+| `InsecureSkipHeaderNormalization` | _bool_ | InsecureSkipHeaderNormalization disables normalizing the header name<br/>According to RFC 7230 Section 3.2 there aren't any rules about<br/>capitalization of header names, but the standard practice is to use<br/>Title-Case (e.g. X-Forwarded-For). By default, header names will be<br/>normalized to Title-Case and any incoming headers that match will be<br/>treated as the same header. Additionally underscores (_) in header names<br/>will be converted to dashes (-) when normalizing.<br/>Defaults to false (header names will be normalized). |

402+| `values` | _[[]HeaderValue](#headervalue)_ | Values contains the desired values for this header |

403+

404+### HeaderValue

405+

406+(**Appears on:** [Header](#header))

407+

408+HeaderValue represents a single header value and the sources that can

409+make up the header value

410+

411+| Field | Type | Description |

412+| ----- | ---- | ----------- |

413+| `value` | _[]byte_ | Value expects a base64 encoded string value. |

414+| `fromEnv` | _string_ | FromEnv expects the name of an environment variable. |

415+| `fromFile` | _string_ | FromFile expects a path to a file containing the secret value. |

416+| `claim` | _string_ | Claim is the name of the claim in the session that the value should be<br/>loaded from. Available claims: `access_token` `id_token` `created_at`<br/>`expires_on` `refresh_token` `email` `user` `groups` `preferred_username`. |

417+| `prefix` | _string_ | Prefix is an optional prefix that will be prepended to the value of the<br/>claim if it is non-empty. |

418+| `basicAuthPassword` | _[SecretSource](#secretsource)_ | BasicAuthPassword converts this claim into a basic auth header.<br/>Note the value of claim will become the basic auth username and the<br/>basicAuthPassword will be used as the password value. |

419+

420+### KeycloakOptions

421+

422+(**Appears on:** [Provider](#provider))

423+

424+

425+

426+| Field | Type | Description |

427+| ----- | ---- | ----------- |

428+| `groups` | _[]string_ | Group enables to restrict login to members of indicated group |

429+| `roles` | _[]string_ | Role enables to restrict login to users with role (only available when using the keycloak-oidc provider) |

430+

431+### LoginGovOptions

432+

433+(**Appears on:** [Provider](#provider))

434+

435+

436+

437+| Field | Type | Description |

438+| ----- | ---- | ----------- |

439+| `jwtKey` | _string_ | JWTKey is a private key in PEM format used to sign JWT, |

440+| `jwtKeyFile` | _string_ | JWTKeyFile is a path to the private key file in PEM format used to sign the JWT |

441+| `pubjwkURL` | _string_ | PubJWKURL is the JWK pubkey access endpoint |

442+

443+### LoginURLParameter

444+

445+(**Appears on:** [Provider](#provider))

446+

447+LoginURLParameter is the configuration for a single query parameter that

448+can be passed through from the `/oauth2/start` endpoint to the IdP login

449+URL. The "default" option specifies the default value or values (if any)

450+that will be passed to the IdP for this parameter, and "allow" is a list

451+of options for ways in which this parameter can be set or overridden via

452+the query string to `/oauth2/start`.

453+If _only_ a default is specified and no "allow" then the parameter is

454+effectively fixed - the default value will always be used and anything

455+passed to the start URL will be ignored. If _only_ "allow" is specified

456+but no default then the parameter will only be passed on to the IdP if

457+the caller provides it, and no value will be sent otherwise.

458+

459+Examples:

460+

461+# A parameter whose value is fixed

462+

463+```

464+name: organization

465+default:

466+- myorg

467+```

468+

469+A parameter that is not passed by default, but may be set to one of a

470+fixed set of values

471+

472+```

473+name: prompt

474+allow:

475+- value: login

476+- value: consent

477+- value: select_account

478+```

479+

480+A parameter that is passed by default but may be overridden by one of

481+a fixed set of values

482+

483+```

484+name: prompt

485+default: ["login"]

486+allow:

487+- value: consent

488+- value: select_account

489+```

490+

491+A parameter that may be overridden, but only by values that match a

492+regular expression. For example to restrict `login_hint` to email

493+addresses in your organization's domain:

494+

495+```

496+name: login_hint

497+allow:

498+- pattern: '^[^@]*@example\.com$'

499+# this allows at most one "@" sign, and requires "example.com" domain.

500+```

501+

502+Note that the YAML rules around exactly which characters are allowed

503+and/or require escaping in different types of string literals are

504+convoluted. For regular expressions the single quoted form is simplest

505+as backslash is not considered to be an escape character. Alternatively

506+use the "chomped block" format `|-`:

507+

508+```

509+ - pattern: |-

510+ ^[^@]*@example\.com$

511+

512+```

513+

514+The hyphen is important, a `|` block would have a trailing newline

515+character.

516+

517+| Field | Type | Description |

518+| ----- | ---- | ----------- |

519+| `name` | _string_ | Name specifies the name of the query parameter. |

520+| `default` | _[]string_ | _(Optional)_ Default specifies a default value or values that will be<br/>passed to the IdP if not overridden. |

521+| `allow` | _[[]URLParameterRule](#urlparameterrule)_ | _(Optional)_ Allow specifies rules about how the default (if any) may be<br/>overridden via the query string to `/oauth2/start`. Only<br/>values that match one or more of the allow rules will be<br/>forwarded to the IdP. |

522+

523+### MicrosoftEntraIDOptions

524+

525+(**Appears on:** [Provider](#provider))

526+

527+

528+

529+| Field | Type | Description |

530+| ----- | ---- | ----------- |

531+| `allowedTenants` | _[]string_ | AllowedTenants is a list of allowed tenants. In case of multi-tenant apps, incoming tokens are<br/>issued by different issuers and OIDC issuer verification needs to be disabled.<br/>When not specified, all tenants are allowed. Redundant for single-tenant apps<br/>(regular ID token validation matches the issuer). |

532+| `federatedTokenAuth` | _bool_ | FederatedTokenAuth enable oAuth2 client authentication with federated token projected<br/>by Entra Workload Identity plugin, instead of client secret. |

533+

534+### OIDCOptions

535+

536+(**Appears on:** [Provider](#provider))

537+

538+

539+

540+| Field | Type | Description |

541+| ----- | ---- | ----------- |

542+| `issuerURL` | _string_ | IssuerURL is the OpenID Connect issuer URL<br/>eg: https://accounts.google.com |

543+| `insecureAllowUnverifiedEmail` | _bool_ | InsecureAllowUnverifiedEmail prevents failures if an email address in an id_token is not verified<br/>default set to 'false' |

544+| `insecureSkipIssuerVerification` | _bool_ | InsecureSkipIssuerVerification skips verification of ID token issuers. When false, ID Token Issuers must match the OIDC discovery URL<br/>default set to 'false' |

545+| `insecureSkipNonce` | _bool_ | InsecureSkipNonce skips verifying the ID Token's nonce claim that must match<br/>the random nonce sent in the initial OAuth flow. Otherwise, the nonce is checked<br/>after the initial OAuth redeem & subsequent token refreshes.<br/>default set to 'true'<br/>Warning: In a future release, this will change to 'false' by default for enhanced security. |

546+| `skipDiscovery` | _bool_ | SkipDiscovery allows to skip OIDC discovery and use manually supplied Endpoints<br/>default set to 'false' |

547+| `jwksURL` | _string_ | JwksURL is the OpenID Connect JWKS URL<br/>eg: https://www.googleapis.com/oauth2/v3/certs |

548+| `publicKeyFiles` | _[]string_ | PublicKeyFiles is a list of paths pointing to public key files in PEM format to use<br/>for verifying JWT tokens |

549+| `emailClaim` | _string_ | EmailClaim indicates which claim contains the user email,<br/>default set to 'email' |

550+| `groupsClaim` | _string_ | GroupsClaim indicates which claim contains the user groups<br/>default set to 'groups' |

551+| `userIDClaim` | _string_ | UserIDClaim indicates which claim contains the user ID<br/>default set to 'email' |

552+| `audienceClaims` | _[]string_ | AudienceClaim allows to define any claim that is verified against the client id<br/>By default `aud` claim is used for verification. |

553+| `extraAudiences` | _[]string_ | ExtraAudiences is a list of additional audiences that are allowed<br/>to pass verification in addition to the client id. |

554+| `enabledSigningAlgs` | _[]string_ | EnabledSigningAlgs is a list of allowed JWT signing algorithms.<br/>When discovery is enabled, the effective set is the intersection<br/>between this list and the provider's discovered supported algorithms.<br/>By default `RS256` is used if nothing has been discovered or specified. |

555+

556+### Provider

557+

558+(**Appears on:** [Providers](#providers))

559+

560+Provider holds all configuration for a single provider

561+

562+| Field | Type | Description |

563+| ----- | ---- | ----------- |

564+| `clientID` | _string_ | ClientID is the OAuth Client ID that is defined in the provider<br/>This value is required for all providers. |

565+| `clientSecret` | _string_ | ClientSecret is the OAuth Client Secret that is defined in the provider<br/>This value is required for all providers. |

566+| `clientSecretFile` | _string_ | ClientSecretFile is the name of the file<br/>containing the OAuth Client Secret, it will be used if ClientSecret is not set. |

567+| `keycloakConfig` | _[KeycloakOptions](#keycloakoptions)_ | KeycloakConfig holds all configurations for Keycloak provider. |

568+| `azureConfig` | _[AzureOptions](#azureoptions)_ | AzureConfig holds all configurations for Azure provider. |

569+| `microsoftEntraIDConfig` | _[MicrosoftEntraIDOptions](#microsoftentraidoptions)_ | MicrosoftEntraIDConfig holds all configurations for Entra ID provider. |

570+| `ADFSConfig` | _[ADFSOptions](#adfsoptions)_ | ADFSConfig holds all configurations for ADFS provider. |

571+| `bitbucketConfig` | _[BitbucketOptions](#bitbucketoptions)_ | BitbucketConfig holds all configurations for Bitbucket provider. |

572+| `githubConfig` | _[GitHubOptions](#githuboptions)_ | GitHubConfig holds all configurations for GitHubC provider. |

573+| `gitlabConfig` | _[GitLabOptions](#gitlaboptions)_ | GitLabConfig holds all configurations for GitLab provider. |

574+| `googleConfig` | _[GoogleOptions](#googleoptions)_ | GoogleConfig holds all configurations for Google provider. |

575+| `oidcConfig` | _[OIDCOptions](#oidcoptions)_ | OIDCConfig holds all configurations for OIDC provider<br/>or providers utilize OIDC configurations. |

576+| `loginGovConfig` | _[LoginGovOptions](#logingovoptions)_ | LoginGovConfig holds all configurations for LoginGov provider. |

577+| `id` | _string_ | ID should be a unique identifier for the provider.<br/>This value is required for all providers. |

578+| `provider` | _[ProviderType](#providertype)_ | Type is the OAuth provider<br/>must be set from the supported providers group,<br/>otherwise 'Google' is set as default |

579+| `name` | _string_ | Name is the providers display name<br/>if set, it will be shown to the users in the login page. |

580+| `caFiles` | _[]string_ | CAFiles is a list of paths to CA certificates that should be used when connecting to the provider.<br/>If not specified, the default Go trust sources are used instead |

581+| `useSystemTrustStore` | _bool_ | UseSystemTrustStore determines if your custom CA files and the system trust store are used<br/>If set to true, your custom CA files and the system trust store are used otherwise only your custom CA files. |

582+| `loginURL` | _string_ | LoginURL is the authentication endpoint |

583+| `loginURLParameters` | _[[]LoginURLParameter](#loginurlparameter)_ | LoginURLParameters defines the parameters that can be passed from the start URL to the IdP login URL |

584+| `authRequestResponseMode` | _string_ | AuthRequestResponseMode defines the response mode to request during authorization request |

585+| `redeemURL` | _string_ | RedeemURL is the token redemption endpoint |

586+| `profileURL` | _string_ | ProfileURL is the profile access endpoint |

587+| `skipClaimsFromProfileURL` | _bool_ | SkipClaimsFromProfileURL allows to skip request to Profile URL for resolving claims not present in id_token<br/>default set to 'false' |

588+| `resource` | _string_ | ProtectedResource is the resource that is protected (Azure AD and ADFS only) |

589+| `validateURL` | _string_ | ValidateURL is the access token validation endpoint |

590+| `scope` | _string_ | Scope is the OAuth scope specification |

591+| `allowedGroups` | _[]string_ | AllowedGroups is a list of restrict logins to members of this group |

592+| `code_challenge_method` | _string_ | The code challenge method |

593+| `additionalClaims` | _[]string_ | Additional claims to be obtained from the upstream IDP, either from the id_token or from the userinfo endpoint if configured. |

594+| `backendLogoutURL` | _string_ | URL to call to perform backend logout, `{id_token}` would be replaced by the actual `id_token` if available in the session |

595+

596+### ProviderType

597+#### (`string` alias)

598+

599+(**Appears on:** [Provider](#provider))

600+

601+ProviderType is used to enumerate the different provider type options

602+Valid options are: adfs, azure, bitbucket, digitalocean facebook, github,

603+gitlab, google, keycloak, keycloak-oidc, linkedin, login.gov, nextcloud

604+and oidc.

605+

606+### Providers

607+

608+#### ([[]Provider](#provider) alias)

609+

610+(**Appears on:** [AlphaOptions](#alphaoptions))

611+

612+The provider can be selected using the `provider` configuration value, or

613+set in the [`providers` array using

614+AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers).

615+However, [**the feature to implement multiple providers is not

616+complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

617+

618+### SecretSource

619+

620+(**Appears on:** [ClaimSource](#claimsource), [HeaderValue](#headervalue), [TLS](#tls))

621+

622+SecretSource references an individual secret value.

623+Only one source within the struct should be defined at any time.

624+

625+| Field | Type | Description |

626+| ----- | ---- | ----------- |

627+| `value` | _[]byte_ | Value expects a base64 encoded string value. |

628+| `fromEnv` | _string_ | FromEnv expects the name of an environment variable. |

629+| `fromFile` | _string_ | FromFile expects a path to a file containing the secret value. |

630+

631+### Server

632+

633+(**Appears on:** [AlphaOptions](#alphaoptions))

634+

635+Server represents the configuration for an HTTP(S) server

636+

637+| Field | Type | Description |

638+| ----- | ---- | ----------- |

639+| `bindAddress` | _string_ | BindAddress is the address on which to serve traffic.<br/>Different types of bind addresses are supported:<br/>* `[http://]<addr>:<port>`<br/>* `fd:<int>` (case insensitive)<br/>* `unix://<path>`<br/>Unix sockets are created with default system umask mode, which can be overridden, e.g.: `unix://my-socket,mode=0777`<br/>Square brackets are required for ipv6 address, e.g. `http://[::1]:4180`<br/>Leave blank or set to "-" to disable. |

640+| `secureBindAddress` | _string_ | SecureBindAddress is the address on which to serve secure traffic.<br/>Secure bind addresses need to respond with valid SSL and use the following format:<br/>* `[https://]<addr>:<port>`<br/>Square brackets are required for ipv6 address, e.g. `https://[::1]:4180`<br/>Leave blank or set to "-" to disable. |

641+| `tls` | _[TLS](#tls)_ | TLS contains the information for loading the certificate and key for the<br/>secure traffic and further configuration for the TLS server. |

642+

643+### TLS

644+

645+(**Appears on:** [Server](#server))

646+

647+TLS contains the information for loading a TLS certificate and key

648+as well as an optional minimal TLS version that is acceptable.

649+

650+| Field | Type | Description |

651+| ----- | ---- | ----------- |

652+| `key` | _[SecretSource](#secretsource)_ | Key is the TLS key data to use.<br/>Typically this will come from a file. |

653+| `cert` | _[SecretSource](#secretsource)_ | Cert is the TLS certificate data to use.<br/>Typically this will come from a file. |

654+| `minVersion` | _string_ | MinVersion is the minimal TLS version that is acceptable.<br/>E.g. Set to "TLS1.3" to select TLS version 1.3 |

655+| `cipherSuites` | _[]string_ | CipherSuites is a list of TLS cipher suites that are allowed.<br/>E.g.:<br/>- TLS_RSA_WITH_RC4_128_SHA<br/>- TLS_RSA_WITH_AES_256_GCM_SHA384<br/>If not specified, the default Go safe cipher list is used.<br/>List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). |

656+

657+### URLParameterRule

658+

659+(**Appears on:** [LoginURLParameter](#loginurlparameter))

660+

661+URLParameterRule represents a rule by which query parameters

662+passed to the `/oauth2/start` endpoint are checked to determine whether

663+they are valid overrides for the given parameter passed to the IdP's

664+login URL. Either Value or Pattern should be supplied, not both.

665+

666+| Field | Type | Description |

667+| ----- | ---- | ----------- |

668+| `value` | _string_ | A Value rule matches just this specific value |

669+| `pattern` | _string_ | A Pattern rule gives a regular expression that must be matched by<br/>some substring of the value. The expression is _not_ automatically<br/>anchored to the start and end of the value, if you _want_ to restrict<br/>the whole parameter value you must anchor it yourself with `^` and `$`. |

670+

671+### Upstream

672+

673+(**Appears on:** [UpstreamConfig](#upstreamconfig))

674+

675+Upstream represents the configuration for an upstream server.

676+Requests will be proxied to this upstream if the path matches the request path.

677+

678+| Field | Type | Description |

679+| ----- | ---- | ----------- |

680+| `id` | _string_ | ID should be a unique identifier for the upstream.<br/>This value is required for all upstreams. |

681+| `path` | _string_ | Path is used to map requests to the upstream server.<br/>The closest match will take precedence and all Paths must be unique.<br/>Path can also take a pattern when used with RewriteTarget.<br/>Path segments can be captured and matched using regular experessions.<br/>Eg:<br/>- `^/foo$`: Match only the explicit path `/foo`<br/>- `^/bar/$`: Match any path prefixed with `/bar/`<br/>- `^/baz/(.*)$`: Match any path prefixed with `/baz` and capture the remaining path for use with RewriteTarget |

682+| `rewriteTarget` | _string_ | RewriteTarget allows users to rewrite the request path before it is sent to<br/>the upstream server (for an HTTP/HTTPS upstream) or mapped to the filesystem<br/>(for a `file:` upstream).<br/>Use the Path to capture segments for reuse within the rewrite target.<br/>Eg: With a Path of `^/baz/(.*)`, a RewriteTarget of `/foo/$1` would rewrite<br/>the request `/baz/abc/123` to `/foo/abc/123` before proxying to the<br/>upstream server. Or if the upstream were `file:///app`, a request for<br/>`/baz/info.html` would return the contents of the file `/app/foo/info.html`. |

683+| `uri` | _string_ | The URI of the upstream server. This may be an HTTP(S) server of a File<br/>based URL. It may include a path, in which case all requests will be served<br/>under that path.<br/>Eg:<br/>- http://localhost:8080<br/>- https://service.localhost<br/>- https://service.localhost/path<br/>- file://host/path<br/>If the URI's path is "/base" and the incoming request was for "/dir",<br/>the upstream request will be for "/base/dir". |

684+| `insecureSkipTLSVerify` | _bool_ | InsecureSkipTLSVerify will skip TLS verification of upstream HTTPS hosts.<br/>This option is insecure and will allow potential Man-In-The-Middle attacks<br/>between OAuth2 Proxy and the upstream server.<br/>Defaults to false. |

685+| `static` | _bool_ | Static will make all requests to this upstream have a static response.<br/>The response will have a body of "Authenticated" and a response code<br/>matching StaticCode.<br/>If StaticCode is not set, the response will return a 200 response. |

686+| `staticCode` | _int_ | StaticCode determines the response code for the Static response.<br/>This option can only be used with Static enabled. |

687+| `flushInterval` | _duration_ | FlushInterval is the period between flushing the response buffer when<br/>streaming response from the upstream.<br/>Defaults to 1 second. |

688+| `passHostHeader` | _bool_ | PassHostHeader determines whether the request host header should be proxied<br/>to the upstream server.<br/>Defaults to true. |

689+| `proxyWebSockets` | _bool_ | ProxyWebSockets enables proxying of websockets to upstream servers<br/>Defaults to true. |

690+| `timeout` | _duration_ | Timeout is the maximum duration the server will wait for a response from the upstream server.<br/>Defaults to 30 seconds. |

691+| `disableKeepAlives` | _bool_ | DisableKeepAlives disables HTTP keep-alive connections to the upstream server.<br/>Defaults to false. |

692+

693+### UpstreamConfig

694+

695+(**Appears on:** [AlphaOptions](#alphaoptions))

696+

697+UpstreamConfig is a collection of definitions for upstream servers.

698+

699+| Field | Type | Description |

700+| ----- | ---- | ----------- |

701+| `proxyRawPath` | _bool_ | ProxyRawPath will pass the raw url path to upstream allowing for urls<br/>like: "/%2F/" which would otherwise be redirected to "/" |

702+| `upstreams` | _[[]Upstream](#upstream)_ | Upstreams represents the configuration for the upstream servers.<br/>Requests will be proxied to this upstream if the path matches the request path. |

docs/versioned_docs/version-7.15.x/configuration/alpha_config.md.tmplnew file+281

@@ -0,0 +1,281 @@

1+---

2+id: alpha-config

3+title: Alpha Configuration

4+---

5+

6+:::warning

7+This page contains documentation for alpha features.

8+We reserve the right to make breaking changes to the features detailed within this page with no notice.

9+

10+Options described in this page may be changed, removed, renamed or moved without prior warning.

11+Please beware of this before you use alpha configuration options.

12+:::

13+

14+This page details a set of **alpha** configuration options in a new format.

15+Going forward we are intending to add structured configuration in YAML format to

16+replace the existing TOML based configuration file and flags.

17+

18+Below is a reference for the structure of the configuration, with

19+[AlphaOptions](#alphaoptions) as the root of the configuration.

20+

21+When using alpha configuration, your config file will look something like below:

22+

23+```yaml

24+upstreams:

25+ - id: ...

26+ ...: ...

27+providers:

28+ - id: ...

29+ ...: ...

30+cookie:

31+ secret: ...

32+ ...: ...

33+injectRequestHeaders:

34+ - secretSource:

35+ ...: ...

36+injectResponseHeaders:

37+ - claimSource:

38+ ...: ...

39+```

40+

41+Please browse the [reference](#configuration-reference) below for the structure

42+of the new configuration format.

43+

44+# Migration Guide

45+

46+This section details breaking changes and migration steps for moving to the new

47+alpha configuration format.

48+

49+## Migrating header injections in v7.14.0

50+

51+From v7.14.0 onward, header injection sources must be explicitly nested. If you

52+previously relied on squashed fields, update to the new structure before

53+upgrading:

54+

55+```yaml

56+# before v7.14.0

57+injectRequestHeaders:

58+- name: X-Forwarded-User

59+ values:

60+ - claim: user

61+- name: X-Custom-Secret-header

62+ values:

63+ - value: my-super-secret

64+

65+# v7.14.0 and later

66+injectRequestHeaders:

67+- name: X-Forwarded-User

68+ values:

69+ - claimSource:

70+ claim: user

71+- name: X-Custom-Secret-header

72+ values:

73+ - secretSource:

74+ value: my-super-secret

75+```

76+

77+## Using Alpha Configuration

78+

79+To use the new **alpha** configuration, generate a YAML file based on the format

80+described in the [reference](#configuration-reference) below.

81+

82+Provide the path to this file using the `--alpha-config` flag.

83+

84+:::note

85+When using the `--alpha-config` flag, some options are no longer available.

86+See [removed options](#removed-options) below for more information.

87+:::

88+

89+### Converting configuration to the new structure

90+

91+Before adding the new `--alpha-config` option, start OAuth2 Proxy using the

92+`convert-config-to-alpha` flag to convert existing configuration to the new format.

93+

94+```bash

95+oauth2-proxy --convert-config-to-alpha --config ./path/to/existing/config.cfg

96+```

97+

98+This will convert any options supported by the new format to YAML and print the

99+new configuration to `STDOUT`.

100+

101+Copy this to a new file, remove any options from your existing configuration

102+noted in [removed options](#removed-options) and then start OAuth2 Proxy using

103+the new config.

104+

105+```bash

106+oauth2-proxy --alpha-config ./path/to/new/config.yaml --config ./path/to/existing/config.cfg

107+```

108+

109+### Validating Alpha Configuration

110+

111+Use `--config-test` to validate your alpha configuration without starting the proxy:

112+

113+```bash

114+oauth2-proxy --config core.cfg --alpha-config alpha.yaml --config-test

115+```

116+

117+This is useful for CI/CD pipelines to catch configuration errors before deployment.

118+See the [Configuration Validation](./overview.md#configuration-validation) section for more details.

119+

120+### How to use environment variables

121+

122+The alpha package supports the use of environment variables in place of yaml values, allowing sensitive data to be pulled from somewhere other than the yaml file.

123+When using environment variables, your yaml will look like this:

124+

125+```yaml

126+ providers:

127+ - provider: azure

128+ clientSecret: ${CLIENT_SECRET}

129+ ...

130+```

131+Where CLIENT_SECRET is an environment variable.

132+More information and available patterns can be found [here](https://github.com/a8m/envsubst#docs)

133+

134+### How to inject custom headers

135+

136+Configure `injectRequestHeaders` and `injectResponseHeaders` in alpha config YAML.

137+

138+```yaml

139+injectRequestHeaders:

140+ - name: "X-User-Email"

141+ values:

142+ - claimSource:

143+ claim: "email" # extract the email claim contents from the id token

144+ - name: "X-Static-Secret"

145+ values:

146+ # secrets need to be encoded with base64 when directly in the yaml config but will be send decoded

147+ - secretSource:

148+ value: "c3VwZXItc2VjcmV0"

149+ - name: "X-Static-File-Secret"

150+ - secretSource:

151+ fromFile: "/path/to/my/secret"

152+ - name: "X-Static-Env-Secret"

153+ - secretSource:

154+ value: "${MY_SECRET_ENV}" # content still needs to be base64 encoded

155+injectResponseHeaders:

156+ # Following will result in a header "Authorization: Basic <user:password> (encoded)"

157+ - name: "Authorization"

158+ values:

159+ - claimSource:

160+ claim: user

161+ prefix: "Basic "

162+ basicAuthPassword:

163+ value: c3VwZXItc2VjcmV0LXBhc3N3b3Jk # base64 encoded password

164+```

165+

166+**Value sources:**

167+* `claimSource` - `claim` (session claims either from id token or from profile URL)

168+* `secretSource` - `value` (base64), `fromFile` (file path)

169+

170+**Request option:** `preserveRequestValue: true` retains existing header values

171+

172+**Incompatibility:** Remove legacy flags `pass-user-headers`, `set-xauthrequest`

173+

174+### How to utilize arbitrary claims provided by your Identity Provider

175+

176+With the additionalClaims attribute you can specify which claims you want to extract

177+from the ID Token or userinfo (ProfileURL) endpoint.

178+

179+Configure these on the relevant provider entry:

180+

181+```yaml

182+providers:

183+ - id: my-oidc-provider

184+ provider: oidc

185+ clientID: ${OAUTH_CLIENT_ID}

186+ clientSecret: ${OAUTH_CLIENT_SECRET}

187+ oidcConfig:

188+ issuerURL: https://issuer.example.com

189+ profileURL: https://issuer.example.com/oauth2/userinfo

190+ additionalClaims:

191+ - department

192+ - employee_id

193+ - organization.name

194+```

195+

196+OAuth2 Proxy resolves each configured claim using the following order:

197+

198+1. The raw ID token is checked first.

199+2. If the claim is not present there and `profileURL` is configured, the userinfo endpoint is queried.

200+3. If `skipClaimsFromProfileURL: true` is set, only the ID token is used.

201+

202+Claims that are not found are ignored rather than causing authentication to fail.

203+

204+You can use dot-separated paths for nested JSON objects, for example `organization.name`.

205+Array indexes are not supported.

206+

207+Once loaded, these claims are stored in the session as `additionalClaims`. They can then be

208+used anywhere session claims are accepted, including header injection:

209+

210+```yaml

211+injectRequestHeaders:

212+ - name: X-Department

213+ values:

214+ - claimSource:

215+ claim: department

216+ - name: X-Organization

217+ values:

218+ - claimSource:

219+ claim: organization.name

220+```

221+

222+This is useful when your IdP exposes application-specific attributes such as department,

223+tenant, employee ID, entitlement, or other custom claims that are not part of the default

224+OAuth2 Proxy session fields.

225+

226+## Removed options

227+

228+The following flags/options and their respective environment variables are no

229+longer available when using alpha configuration:

230+

231+<!-- Legacy Upstream FlagSet -->

232+- `flush-interval`/`flush_interval`

233+- `pass-host-header`/`pass_host_header`

234+- `proxy-websockets`/`proxy_websockets`

235+- `ssl-upstream-insecure-skip-verify`/`ssl_upstream_insecure_skip_verify`

236+- `upstream`/`upstreams`

237+

238+<!-- Legacy Headers FlagSet -->

239+- `pass-basic-auth`/`pass_basic_auth`

240+- `pass-access-token`/`pass_access_token`

241+- `pass-user-headers`/`pass_user_headers`

242+- `pass-authorization-header`/`pass_authorization_header`

243+- `set-basic-auth`/`set_basic_auth`

244+- `set-xauthrequest`/`set_xauthrequest`

245+- `set-authorization-header`/`set_authorization_header`

246+- `prefer-email-to-user`/`prefer_email_to_user`

247+- `basic-auth-password`/`basic_auth_password`

248+- `skip-auth-strip-headers`/`skip_auth_strip_headers`

249+

250+<!-- Legacy provider FlagSet -->

251+- `client-id`/`client_id`

252+- `client-secret`/`client_secret`, and `client-secret-file`/`client_secret_file`

253+- `provider`

254+- `provider-display-name`/`provider_display_name`

255+- `provider-ca-file`/`provider_ca_files`

256+- `login-url`/`login_url`

257+- `redeem-url`/`redeem_url`

258+- `profile-url`/`profile_url`

259+- `resource`

260+- `validate-url`/`validate_url`

261+- `scope`

262+- `prompt`

263+- `approval-prompt`/`approval_prompt`

264+- `acr-values`/`acr_values`

265+- `user-id-claim`/`user_id_claim`

266+- `allowed-group`/`allowed_groups`

267+- `allowed-role`/`allowed_roles`

268+- `jwt-key`/`jwt_key`

269+- `jwt-key-file`/`jwt_key_file`

270+- `pubjwk-url`/`pubjwk_url`

271+

272+and all provider-specific options, i.e. any option whose name includes `oidc`,

273+`azure`, `bitbucket`, `github`, `gitlab`, `google` or `keycloak`. Attempting to

274+use any of these options via flags or via config when `--alpha-config` is

275+set will result in an error.

276+

277+:::important

278+You must remove these options before starting OAuth2 Proxy with `--alpha-config`

279+:::

280+

281+## Configuration Reference

docs/versioned_docs/version-7.15.x/configuration/integrations/caddy.mdnew file+63

@@ -0,0 +1,63 @@

1+---

2+id: caddy

3+title: Caddy

4+---

5+

6+Integrate OAuth2 Proxy with Caddy v2 using the `forward_auth` directive.

7+

8+**Key features:**

9+- Simple forward_auth setup

10+- Automatic header handling

11+- Custom error handling and redirects

12+

13+## Configuring for use with the Caddy (v2) `forward_auth` directive

14+

15+The [Caddy `forward_auth` directive](https://caddyserver.com/docs/caddyfile/directives/forward_auth) allows Caddy to authenticate requests via the `oauth2-proxy`'s `/auth`.

16+

17+This example is for a simple reverse proxy setup where the `/oauth2/` path is kept under the same domain and failed auth requests (401 status returned) will be caught and redirected to the `sign_in` endpoint.

18+

19+**Following options need to be set on `oauth2-proxy`:**

20+- `--reverse-proxy=true`: Enables the use of `X-Forwarded-*` headers to determine redirects correctly

21+

22+```nginx title="Caddyfile"

23+example.com {

24+ # Requests to /oauth2/* are proxied to oauth2-proxy without authentication.

25+ # You can't use `reverse_proxy /oauth2/* oauth2-proxy.internal:4180` here because the reverse_proxy directive has lower precedence than the handle directive.

26+ handle /oauth2/* {

27+ reverse_proxy oauth2-proxy.internal:4180 {

28+ # oauth2-proxy requires the X-Real-IP and X-Forwarded-{Proto,Host,Uri} headers.

29+ # The reverse_proxy directive automatically sets X-Forwarded-{For,Proto,Host} headers.

30+ header_up X-Real-IP {remote_host}

31+ header_up X-Forwarded-Uri {uri}

32+ }

33+ }

34+

35+ # Requests to other paths are first processed by oauth2-proxy for authentication.

36+ handle {

37+ forward_auth oauth2-proxy.internal:4180 {

38+ uri /oauth2/auth

39+

40+ # oauth2-proxy requires the X-Real-IP and X-Forwarded-{Proto,Host,Uri} headers.

41+ # The forward_auth directive automatically sets the X-Forwarded-{For,Proto,Host,Method,Uri} headers.

42+ header_up X-Real-IP {remote_host}

43+

44+ # If needed, you can copy headers from the oauth2-proxy response to the request sent to the upstream.

45+ # Make sure to configure the --set-xauthrequest flag to enable this feature.

46+ #copy_headers X-Auth-Request-User X-Auth-Request-Email

47+

48+ # If oauth2-proxy returns a 401 status, redirect the client to the sign-in page.

49+ @error status 401

50+ handle_response @error {

51+ redir * /oauth2/sign_in?rd={scheme}://{host}{uri}

52+ }

53+ }

54+

55+ # If oauth2-proxy returns a 2xx status, the request is then proxied to the upstream.

56+ reverse_proxy upstream.internal:3000

57+ }

58+}

59+```

60+

61+:::note

62+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

63+:::

docs/versioned_docs/version-7.15.x/configuration/integrations/headlamp.mdnew file+105

@@ -0,0 +1,105 @@

1+---

2+id: headlamp

3+title: Headlamp

4+---

5+

6+Modern, actively maintained Kubernetes web UI with OAuth2 Proxy integration examples.

7+

8+**Key features:**

9+- Active development and maintenance

10+- Modern, intuitive interface

11+- Multi-cluster support

12+- Plugin system

13+- Works with all OAuth2 providers

14+

15+## Configuring for use with Headlamp

16+

17+[Headlamp](https://headlamp.dev/) is a modern, user-friendly Kubernetes web UI that can be integrated with OAuth2 Proxy for authentication. This is a recommended alternative to the deprecated Kubernetes Dashboard.

18+

19+### Architecture

20+

21+```

22+User → Ingress → OAuth2 Proxy → Authentication Provider (e.g., Azure Entra ID)

23+ ↓

24+ Headlamp

25+```

26+

27+### Prerequisites

28+

29+- Kubernetes cluster (e.g., AKS, EKS, GKE, or self-hosted)

30+- Headlamp installed in the cluster

31+- OAuth2 provider configured (Azure Entra ID, Google, GitHub, etc.)

32+- Ingress controller (Nginx, Traefik, etc.)

33+

34+### Configuration Overview

35+

36+When integrating Headlamp with OAuth2 Proxy, the OAuth2 Proxy acts as a reverse proxy in front of Headlamp:

37+

38+1. User requests access to Headlamp

39+2. Ingress forwards to OAuth2 Proxy

40+3. OAuth2 Proxy authenticates the user via the OAuth2 provider

41+4. After successful authentication, OAuth2 Proxy proxies requests to Headlamp

42+5. Headlamp receives the authenticated user information via headers

43+

44+### OAuth2 Proxy Configuration

45+

46+Configure OAuth2 Proxy to proxy to the Headlamp service:

47+

48+```yaml

49+upstreamConfig:

50+ upstreams:

51+ - id: headlamp

52+ path: /

53+ uri: http://headlamp-service.headlamp-namespace.svc.cluster.local:4466

54+```

55+

56+Enable the necessary headers:

57+

58+```yaml

59+extraArgs:

60+ reverse-proxy: true

61+ pass-authorization-header: true

62+ set-xauthrequest: true

63+ email-domain: "*" # Or restrict to your organization

64+```

65+

66+### Example with Azure Entra ID on AKS

67+

68+For detailed instructions on deploying Headlamp with OAuth2 Proxy on Azure Kubernetes Service using Azure Entra ID, see the official Headlamp documentation:

69+

70+https://headlamp.dev/docs/latest/installation/in-cluster/aks-cluster-oauth/

71+

72+Key steps include:

73+

74+1. **Set up AKS with OIDC**: Enable Microsoft Entra ID authentication with Kubernetes RBAC

75+2. **Create Azure App Registration**: Configure redirect URI and create client secret

76+3. **Deploy Headlamp**: Install Headlamp via Helm in your cluster

77+4. **Deploy OAuth2 Proxy**: Configure OAuth2 Proxy with Entra ID provider settings and upstream pointing to Headlamp

78+5. **Configure Ingress**: Set up Ingress to route traffic through OAuth2 Proxy to Headlamp

79+6. **Set RBAC Policies**: Apply Kubernetes RBAC bindings based on users or groups

80+

81+### Integration with Other Providers

82+

83+The same integration pattern works with other OAuth2 providers supported by OAuth2 Proxy:

84+

85+- **Google**: Use the Google provider configuration

86+- **GitHub**: Use the GitHub provider configuration

87+- **GitLab**: Use the GitLab provider configuration

88+- **Keycloak**: Use the Keycloak OIDC provider configuration

89+- **Any OIDC Provider**: Use the generic OIDC provider configuration

90+

91+For provider-specific configuration examples, see the [OAuth Provider Configuration](../providers/index.md) documentation.

92+

93+### Benefits Over Kubernetes Dashboard

94+

95+Headlamp offers several advantages:

96+

97+- **Active Development**: Headlamp is actively maintained and developed

98+- **Modern UI**: Clean, intuitive interface with better UX

99+- **Plugin System**: Extensible with custom plugins

100+- **Multi-cluster Support**: Built-in support for managing multiple clusters

101+- **Desktop App**: Available as both web UI and desktop application

102+

103+:::note

104+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

105+:::

docs/versioned_docs/version-7.15.x/configuration/integrations/index.mdnew file+41

@@ -0,0 +1,41 @@

1+---

2+id: index

3+title: Integrations

4+---

5+

6+This section provides configuration examples for integrating OAuth2 Proxy with various reverse proxies, ingress controllers, and Kubernetes web UIs.

7+

8+## Reverse Proxies and Ingress Controllers

9+

10+OAuth2 Proxy can be integrated with popular reverse proxies and ingress controllers to add authentication to your applications:

11+

12+- [Nginx](nginx.md)

13+- [Traefik](traefik.md)

14+- [caddy](caddy.md)

15+

16+## Kubernetes Web UIs

17+

18+OAuth2 Proxy can also be used to add authentication to Kubernetes web user interfaces:

19+

20+- [Headlamp](headlamp.md) ✨ *Recommended*

21+- [Kubernetes Dashboard](kubernetes-dashboard.md) ⚠️ *Deprecated*

22+

23+:::tip

24+When integrating with Kubernetes web UIs, make sure to:

25+1. Configure the Ingress to pass the Authorization header with the bearer token

26+2. Increase buffer sizes for large OIDC tokens (especially with Azure Entra ID)

27+3. Set up appropriate Kubernetes RBAC permissions for your users or groups

28+:::

29+

30+## General Requirements

31+

32+Most integrations require the following OAuth2 Proxy configuration:

33+

34+- `--reverse-proxy=true`: Required to correctly handle `X-Forwarded-*` headers

35+- **Session storage**: For production deployments with large tokens due to a lot of claims like AD groups, use `--session-store-type=redis`

36+

37+For provider-specific configuration, see the [OAuth Provider Configuration](../providers/index.md) documentation.

38+

39+:::note

40+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

41+:::

docs/versioned_docs/version-7.15.x/configuration/integrations/kubernetes-dashboard.mdnew file+289

@@ -0,0 +1,289 @@

1+---

2+id: kubernetes-dashboard

3+title: Kubernetes Dashboard

4+---

5+

6+:::warning Deprecated Project

7+Kubernetes Dashboard has been deprecated and discontinued as of January 2025. See the [official announcement](https://github.com/kubernetes/dashboard/commit/0ba796dce6916bb6ca5da5ca0b3ab22cecfd1e18) for more information.

8+

9+You may want to consider alternative solutions such as [Headlamp](./headlamp.md).

10+:::

11+

12+## Kubernetes Dashboard on AKS with Azure Entra ID

13+

14+Integration guide for the deprecated Kubernetes Dashboard, including comprehensive Azure Entra ID configuration on AKS with detailed troubleshooting and RBAC setup.

15+

16+### Architecture

17+

18+```

19+User → Nginx Ingress → OAuth2 Proxy → Entra ID

20+ ↓

21+ Kubernetes Dashboard

22+```

23+

24+The integration flow:

25+1. Unauthenticated requests to Dashboard are intercepted by Nginx Ingress

26+2. Nginx redirects to OAuth2 Proxy for authentication

27+3. OAuth2 Proxy redirects to Entra ID login

28+4. After successful authentication, OAuth2 Proxy receives ID token from Entra ID

29+5. OAuth2 Proxy sets Authorization header with the bearer token

30+6. Nginx forwards the request with token to Kubernetes Dashboard

31+7. Dashboard validates the token and grants access based on AKS RBAC configuration

32+

33+### Prerequisites

34+

35+- AKS cluster with Entra ID integration enabled

36+- Kubernetes Dashboard installed (version 7.x or later)

37+- NGINX Ingress Controller installed

38+- Entra ID App Registration configured with:

39+ - Redirect URI: `https://your-oauth2-domain.com/oauth2/callback`

40+ - API Permissions: `openid`, `email`, `profile`

41+ - Groups claim enabled (if using group-based RBAC)

42+- Users or groups assigned appropriate Kubernetes RBAC permissions

43+

44+### Alpha Configuration Example

45+

46+Using [Alpha Configuration](../alpha_config.md) with the OAuth2 Proxy Helm chart:

47+

48+```yaml

49+alphaConfig:

50+ enabled: true

51+ configData:

52+ providers:

53+ - id: azure-entra

54+ provider: entra-id

55+ clientID: YOUR_CLIENT_ID

56+ clientSecret: YOUR_CLIENT_SECRET

57+ oidcConfig:

58+ issuerURL: https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0

59+ audienceClaims:

60+ - aud

61+ emailClaim: email

62+ groupsClaim: groups

63+ userIDClaim: oid

64+ scope: openid email profile

65+

66+ upstreamConfig:

67+ upstreams:

68+ - id: static

69+ path: /

70+ static: true

71+ staticCode: 200

72+

73+ # Response headers passed to Dashboard via Nginx

74+ injectResponseHeaders:

75+ - name: Authorization

76+ values:

77+ - claim: id_token

78+ prefix: "Bearer "

79+ - name: X-Auth-Request-User

80+ values:

81+ - claim: email

82+ - name: X-Auth-Request-Email

83+ values:

84+ - claim: email

85+ - name: X-Auth-Request-Groups

86+ values:

87+ - claim: groups

88+

89+ server:

90+ BindAddress: "0.0.0.0:4180"

91+

92+extraArgs:

93+ cookie-domain: ".your-domain.com"

94+ whitelist-domain: ".your-domain.com"

95+ email-domain: "*" # Or restrict to your organization

96+ skip-provider-button: true

97+ reverse-proxy: true

98+ pass-authorization-header: true

99+ set-xauthrequest: true

100+

101+sessionStorage:

102+ type: redis

103+

104+redis:

105+ enabled: true

106+ auth:

107+ enabled: true

108+

109+ingress:

110+ enabled: true

111+ className: nginx

112+ hosts:

113+ - OAuth2 Proxy.your-domain.com

114+ path: /oauth2

115+ pathType: Prefix

116+```

117+

118+### Kubernetes Dashboard Ingress

119+

120+**Critical**: The Ingress must include `Authorization` in the `auth-response-headers` annotation:

121+

122+```yaml

123+apiVersion: networking.k8s.io/v1

124+kind: Ingress

125+metadata:

126+ name: kubernetes-dashboard

127+ namespace: kubernetes-dashboard

128+ annotations:

129+ nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

130+ nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

131+

132+ # OAuth2 Proxy authentication

133+ nginx.ingress.kubernetes.io/auth-url: "https://OAuth2 Proxy.your-domain.com/oauth2/auth"

134+ nginx.ingress.kubernetes.io/auth-signin: "https://OAuth2 Proxy.your-domain.com/oauth2/start?rd=$scheme://$best_http_host$request_uri"

135+

136+ # Include Authorization header with bearer token

137+ nginx.ingress.kubernetes.io/auth-response-headers: "Authorization, X-Auth-Request-User, X-Auth-Request-Email"

138+

139+ # Buffer sizes for large tokens (Entra tokens can exceed 4KB)

140+ nginx.ingress.kubernetes.io/proxy-buffer-size: "256k"

141+ nginx.ingress.kubernetes.io/proxy-buffers-number: "4"

142+ nginx.ingress.kubernetes.io/proxy-busy-buffers-size: "256k"

143+spec:

144+ ingressClassName: nginx

145+ tls:

146+ - hosts:

147+ - dashboard.your-domain.com

148+ secretName: dashboard-tls

149+ rules:

150+ - host: dashboard.your-domain.com

151+ http:

152+ paths:

153+ - path: /

154+ pathType: Prefix

155+ backend:

156+ service:

157+ name: kubernetes-dashboard-kong-proxy

158+ port:

159+ number: 443

160+```

161+

162+### RBAC Configuration

163+

164+Assign Kubernetes permissions to Entra ID users or groups.

165+

166+**User-based:**

167+```yaml

168+apiVersion: rbac.authorization.k8s.io/v1

169+kind: ClusterRoleBinding

170+metadata:

171+ name: dashboard-user-admin

172+roleRef:

173+ apiGroup: rbac.authorization.k8s.io

174+ kind: ClusterRole

175+ name: cluster-admin

176+subjects:

177+ - kind: User

178+ name: "user@your-domain.com" # Email from Entra ID token

179+ apiGroup: rbac.authorization.k8s.io

180+```

181+

182+**Group-based (recommended):**

183+```yaml

184+apiVersion: rbac.authorization.k8s.io/v1

185+kind: ClusterRoleBinding

186+metadata:

187+ name: dashboard-admins-group

188+roleRef:

189+ apiGroup: rbac.authorization.k8s.io

190+ kind: ClusterRole

191+ name: cluster-admin

192+subjects:

193+ - kind: Group

194+ name: "YOUR_ENTRA_GROUP_OBJECT_ID" # Entra ID Group Object ID

195+ apiGroup: rbac.authorization.k8s.io

196+```

197+

198+For production, create custom roles with limited permissions instead of using `cluster-admin`.

199+

200+### Troubleshooting

201+

202+**Dashboard still asks for token after authentication**

203+

204+Verify that:

205+1. `injectResponseHeaders` in alphaConfig includes Authorization header with id_token claim

206+2. Dashboard Ingress includes `Authorization` in `auth-response-headers` annotation

207+3. Buffer sizes are sufficient for large tokens (set to 256k as shown above)

208+4. Check OAuth2 Proxy logs for successful token generation: `kubectl logs -n OAuth2 Proxy <pod-name>`

209+

210+**"Unauthorized" or "Invalid token" errors**

211+

212+Common causes:

213+1. User/group not configured in Kubernetes RBAC

214+ - Check: `kubectl get clusterrolebindings | grep <user-email>`

215+2. Token validation failed

216+ - Verify AKS Entra ID integration is enabled

217+ - Check Dashboard logs: `kubectl logs -n kubernetes-dashboard <pod-name>`

218+3. Incorrect OAuth2 Proxy configuration

219+ - Ensure `reverse-proxy: true` is set

220+ - Verify issuer URL matches your tenant

221+

222+**Groups not included in token**

223+

224+To include groups in the token:

225+1. In Entra ID App Registration, go to **Token configuration**

226+2. Add **groups claim** and select security groups

227+3. Or edit the manifest and add: `"groupMembershipClaims": "SecurityGroup"`

228+4. For 200+ groups, ensure scope includes `User.Read` for group overage handling

229+5. Verify groups appear in token: check OAuth2 Proxy logs

230+

231+**Session expires too quickly**

232+

233+Configure cookie expiration:

234+```yaml

235+extraArgs:

236+ cookie-expire: "24h"

237+ cookie-refresh: "1h"

238+```

239+

240+### Using Workload Identity (Passwordless)

241+

242+For production environments, use Workload Identity instead of client secrets:

243+

244+```yaml

245+config:

246+ clientID: "YOUR_CLIENT_ID"

247+ secretKeys: # Exclude client-secret

248+ - client-id

249+ - cookie-secret

250+ cookieSecret: "YOUR_COOKIE_SECRET"

251+

252+serviceAccount:

253+ annotations:

254+ azure.workload.identity/client-id: YOUR_CLIENT_ID

255+ azure.workload.identity/tenant-id: YOUR_TENANT_ID

256+

257+podLabels:

258+ azure.workload.identity/use: "true"

259+

260+alphaConfig:

261+ enabled: true

262+ configData:

263+ providers:

264+ - id: azure-entra

265+ provider: entra-id

266+ clientID: YOUR_CLIENT_ID

267+ oidcConfig:

268+ issuerURL: https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0

269+ # ... other config

270+ entraIdConfig:

271+ federatedTokenAuth: true

272+```

273+

274+This requires:

275+- AKS with OIDC issuer and Workload Identity enabled

276+- Federated identity credential configured in Entra ID App Registration

277+- Service account annotated with `azure.workload.identity/client-id`

278+

279+For detailed Workload Identity setup instructions, see the [Workload Identity section](../providers/ms_entra_id.md#workload-identity) in the Microsoft Entra ID provider documentation.

280+

281+## Integration with Other Providers

282+

283+While this guide focuses on Azure Entra ID, Kubernetes Dashboard can be integrated with other OAuth2 providers supported by OAuth2 Proxy. The key requirements remain the same:

284+

285+1. **Authorization Header**: Pass the bearer token via the `Authorization` header

286+2. **RBAC Configuration**: Configure Kubernetes RBAC for your authentication provider's users/groups

287+3. **Buffer Sizes**: Ensure adequate buffer sizes for tokens (especially important for OIDC providers)

288+

289+For provider-specific configuration examples, see the [OAuth Provider Configuration](../providers/index.md) documentation.

docs/versioned_docs/version-7.15.x/configuration/integrations/nginx.mdnew file+174

@@ -0,0 +1,174 @@

1+---

2+id: nginx

3+title: Nginx

4+---

5+

6+Configure OAuth2 Proxy with Nginx using the `auth_request` directive. Includes examples for both standalone Nginx configurations and Kubernetes ingress-nginx with annotations.

7+

8+**Key features:**

9+- Support for `auth_request` directive

10+- Kubernetes Ingress annotations

11+- Multi-part cookie handling for large tokens

12+- Session refresh support

13+

14+## Configuring for use with the Nginx `auth_request` directive

15+

16+**This option requires `--reverse-proxy` option to be set.**

17+

18+The [Nginx `auth_request` directive](http://nginx.org/en/docs/http/ngx_http_auth_request_module.html) allows Nginx to authenticate requests via the oauth2-proxy's `/auth` endpoint, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the request through. For example:

19+

20+```nginx

21+server {

22+ listen 443 ssl;

23+ server_name ...;

24+ include ssl/ssl.conf;

25+

26+ location /oauth2/ {

27+ proxy_pass http://127.0.0.1:4180;

28+ proxy_set_header Host $host;

29+ proxy_set_header X-Real-IP $remote_addr;

30+ proxy_set_header X-Auth-Request-Redirect $request_uri;

31+ # or, if you are handling multiple domains:

32+ # proxy_set_header X-Auth-Request-Redirect $scheme://$host$request_uri;

33+ }

34+ location = /oauth2/auth {

35+ proxy_pass http://127.0.0.1:4180;

36+ proxy_set_header Host $host;

37+ proxy_set_header X-Real-IP $remote_addr;

38+ proxy_set_header X-Forwarded-Uri $request_uri;

39+ # nginx auth_request includes headers but not body

40+ proxy_set_header Content-Length "";

41+ proxy_pass_request_body off;

42+ }

43+

44+ location / {

45+ auth_request /oauth2/auth;

46+ error_page 401 = @oauth2_signin;

47+

48+ # pass information via X-User and X-Email headers to backend,

49+ # requires running with --set-xauthrequest flag

50+ auth_request_set $user $upstream_http_x_auth_request_user;

51+ auth_request_set $email $upstream_http_x_auth_request_email;

52+ proxy_set_header X-User $user;

53+ proxy_set_header X-Email $email;

54+

55+ # if you enabled --pass-access-token, this will pass the token to the backend

56+ auth_request_set $token $upstream_http_x_auth_request_access_token;

57+ proxy_set_header X-Access-Token $token;

58+

59+ # if you enabled --cookie-refresh, this is needed for it to work with auth_request

60+ auth_request_set $auth_cookie $upstream_http_set_cookie;

61+ add_header Set-Cookie $auth_cookie;

62+

63+ # When using the --set-authorization-header flag, some provider's cookies can exceed the 4kb

64+ # limit and so the OAuth2 Proxy splits these into multiple parts.

65+ # Nginx normally only copies the first `Set-Cookie` header from the auth_request to the response,

66+ # so if your cookies are larger than 4kb, you will need to extract additional cookies manually.

67+ auth_request_set $auth_cookie_name_upstream_1 $upstream_cookie_auth_cookie_name_1;

68+

69+ # Extract the Cookie attributes from the first Set-Cookie header and append them

70+ # to the second part ($upstream_cookie_* variables only contain the raw cookie content)

71+ if ($auth_cookie ~* "(; .*)") {

72+ set $auth_cookie_name_0 $auth_cookie;

73+ set $auth_cookie_name_1 "auth_cookie_name_1=$auth_cookie_name_upstream_1$1";

74+ }

75+

76+ # Send both Set-Cookie headers now if there was a second part

77+ if ($auth_cookie_name_upstream_1) {

78+ add_header Set-Cookie $auth_cookie_name_0;

79+ add_header Set-Cookie $auth_cookie_name_1;

80+ }

81+

82+ proxy_pass http://backend/;

83+ # or "root /path/to/site;" or "fastcgi_pass ..." etc

84+ }

85+

86+ # Named location for handling OAuth2 sign-in redirects

87+ # This ensures the browser receives a proper 302 redirect that it will follow

88+ location @oauth2_signin {

89+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

90+ }

91+}

92+```

93+

94+### Understanding the `error_page` redirect pattern

95+

96+The `auth_request` directive expects the authentication endpoint (`/oauth2/auth`) to return:

97+- **2xx**: Request is authenticated, allow access

98+- **401 or 403**: Request is not authenticated, deny access

99+

100+When a 401 is returned, nginx triggers the `error_page` directive. The recommended pattern uses a **named location** (`@oauth2_signin`) that returns a proper **302 redirect**:

101+

102+```nginx

103+error_page 401 = @oauth2_signin;

104+

105+location @oauth2_signin {

106+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

107+}

108+```

109+

110+:::warning Avoid `error_page 401 =403` with sign_in

111+Some older configurations use `error_page 401 =403 /oauth2/sign_in`. While this works for displaying the sign-in page, it returns a **403 status code** with a `Location` header. Browsers do not automatically follow redirects on 403 responses, which can cause issues when using `--skip-provider-button=true` (users see a "Found." link instead of being automatically redirected).

112+

113+The named location pattern above ensures the browser receives a standard **302 redirect** that works correctly with all oauth2-proxy configurations.

114+:::

115+

116+### Browser vs API Routes

117+

118+:::important When to use redirects

119+Redirecting authentication failures (302 to `/oauth2/sign_in`) should **only be used for browser-facing routes**. API or machine clients should receive a plain 401/403 response without redirect.

120+:::

121+

122+#### Browser-facing routes (HTML, UI)

123+

124+For interactive browser routes where users should be redirected to sign in:

125+

126+```nginx

127+location / {

128+ auth_request /oauth2/auth;

129+ error_page 401 = @oauth2_signin;

130+ proxy_pass http://backend/;

131+}

132+

133+location @oauth2_signin {

134+ return 302 /oauth2/sign_in?rd=$scheme://$host$request_uri;

135+}

136+```

137+

138+#### API / Machine routes (no redirect)

139+

140+For API endpoints where clients expect a 401/403 status code (not a redirect):

141+

142+```nginx

143+location /api/ {

144+ auth_request /oauth2/auth;

145+ error_page 401 =401; # Pass through the 401 status

146+ proxy_pass http://backend/;

147+}

148+```

149+

150+This ensures:

151+- ✅ Browsers get a redirect and smooth login flow

152+- ✅ API clients fail fast with appropriate HTTP status codes

153+- ✅ `/oauth2/auth` remains a pure boolean oracle (2xx/401)

154+

155+When you use ingress-nginx in Kubernetes, you can configure the same behavior with the following annotations on your Ingress resource:

156+

157+```yaml

158+nginx.ingress.kubernetes.io/auth-url: "https://<oauth2-proxy-fqdn>/oauth2/auth"

159+nginx.ingress.kubernetes.io/auth-signin: "https://<oauth2-proxy-fqdn>/oauth2/start?rd=$escaped_request_uri"

160+```

161+

162+This minimal configuration works for standard authentication flows. Lua/cookie handling is only needed for advanced scenarios (e.g., multi-part cookies, custom session logic). See the official ingress-nginx example: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/.

163+

164+It is recommended to use `--session-store-type=redis` when expecting large sessions/OIDC tokens (_e.g._ with MS Azure).

165+

166+:::tip Kubernetes Dashboard with Azure Entra ID

167+For a complete example of integrating oauth2-proxy with Kubernetes Dashboard on AKS using Azure Entra ID, including RBAC configuration and troubleshooting, see the [Kubernetes Dashboard on AKS](../providers/ms_entra_id.md#kubernetes-dashboard-on-aks) section in the Microsoft Entra ID provider documentation.

168+:::

169+

170+You have to substitute *name* with the actual cookie name you configured via --cookie-name parameter. If you don't set a custom cookie name the variable should be "$upstream_cookie__oauth2_proxy_1" instead of "$upstream_cookie_name_1" and the new cookie-name should be "_oauth2_proxy_1=" instead of "name_1=".

171+

172+:::note

173+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

174+:::

docs/versioned_docs/version-7.15.x/configuration/integrations/traefik.mdnew file+192

@@ -0,0 +1,192 @@

1+---

2+id: traefik

3+title: Traefik

4+---

5+

6+Set up OAuth2 Proxy with Traefik v2 using the `ForwardAuth` middleware. Includes examples for both error-based redirects and static upstream configurations.

7+

8+**Key features:**

9+- ForwardAuth middleware integration

10+- Error middleware for 401 redirects

11+- Static upstream configuration (202 responses)

12+- Dynamic file configuration examples

13+

14+

15+## Configuring for use with the Traefik (v2) `ForwardAuth` middleware

16+

17+**This option requires `--reverse-proxy` option to be set.**

18+

19+### ForwardAuth with 401 errors middleware

20+

21+The [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) allows Traefik to authenticate requests via the oauth2-proxy's `/oauth2/auth` endpoint on every request, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the whole request through. For example, on Dynamic File (YAML) Configuration:

22+

23+```yaml

24+http:

25+ routers:

26+ a-service:

27+ rule: "Host(`a-service.example.com`)"

28+ service: a-service-backend

29+ middlewares:

30+ - oauth-errors

31+ - oauth-auth

32+ tls:

33+ certResolver: default

34+ domains:

35+ - main: "example.com"

36+ sans:

37+ - "*.example.com"

38+ oauth:

39+ rule: "Host(`a-service.example.com`, `oauth.example.com`) && PathPrefix(`/oauth2/`)"

40+ middlewares:

41+ - auth-headers

42+ service: oauth-backend

43+ tls:

44+ certResolver: default

45+ domains:

46+ - main: "example.com"

47+ sans:

48+ - "*.example.com"

49+

50+ services:

51+ a-service-backend:

52+ loadBalancer:

53+ servers:

54+ - url: http://172.16.0.2:7555

55+ oauth-backend:

56+ loadBalancer:

57+ servers:

58+ - url: http://172.16.0.1:4180

59+

60+ middlewares:

61+ auth-headers:

62+ headers:

63+ sslRedirect: true

64+ stsSeconds: 315360000

65+ browserXssFilter: true

66+ contentTypeNosniff: true

67+ forceSTSHeader: true

68+ sslHost: example.com

69+ stsIncludeSubdomains: true

70+ stsPreload: true

71+ frameDeny: true

72+ oauth-auth:

73+ forwardAuth:

74+ address: https://oauth.example.com/oauth2/auth

75+ trustForwardHeader: true

76+ oauth-errors:

77+ errors:

78+ status:

79+ - "401-403"

80+ service: oauth-backend

81+ query: "/oauth2/sign_in?rd={url}"

82+ statusRewrites:

83+ "401": 302

84+```

85+

86+:::caution Troubleshooting: Browser shows "Found." instead of redirecting

87+When using the Errors middleware without `statusRewrites`, the redirect response from oauth2-proxy can be served within the original 401/403 status context. This causes some browsers to display a "Found." link instead of automatically following the redirect to the identity provider.

88+

89+Adding `statusRewrites` to rewrite `401 -> 302` ensures the browser treats the response as a proper redirect and follows it automatically.

90+:::

91+

92+### ForwardAuth with static upstreams configuration

93+

94+Redirect to sign_in functionality provided without the use of `errors` middleware with [Traefik v2 `ForwardAuth` middleware](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) pointing to oauth2-proxy service's `/` endpoint

95+

96+**Following options need to be set on `oauth2-proxy`:**

97+- `--upstream=static://202`: Configures a static response for authenticated sessions

98+- `--reverse-proxy=true`: Enables the use of `X-Forwarded-*` headers to determine redirects correctly

99+

100+```yaml

101+http:

102+ routers:

103+ a-service-route-1:

104+ rule: "Host(`a-service.example.com`, `b-service.example.com`) && PathPrefix(`/`)"

105+ service: a-service-backend

106+ middlewares:

107+ - oauth-auth-redirect # redirects all unauthenticated to oauth2 signin

108+ tls:

109+ certResolver: default

110+ domains:

111+ - main: "example.com"

112+ sans:

113+ - "*.example.com"

114+ a-service-route-2:

115+ rule: "Host(`a-service.example.com`) && PathPrefix(`/no-auto-redirect`)"

116+ service: a-service-backend

117+ middlewares:

118+ - oauth-auth-wo-redirect # unauthenticated session will return a 401

119+ tls:

120+ certResolver: default

121+ domains:

122+ - main: "example.com"

123+ sans:

124+ - "*.example.com"

125+ services-oauth2-route:

126+ rule: "Host(`a-service.example.com`, `b-service.example.com`) && PathPrefix(`/oauth2/`)"

127+ middlewares:

128+ - auth-headers

129+ service: oauth-backend

130+ tls:

131+ certResolver: default

132+ domains:

133+ - main: "example.com"

134+ sans:

135+ - "*.example.com"

136+ oauth2-proxy-route:

137+ rule: "Host(`oauth.example.com`) && PathPrefix(`/`)"

138+ middlewares:

139+ - auth-headers

140+ service: oauth-backend

141+ tls:

142+ certResolver: default

143+ domains:

144+ - main: "example.com"

145+ sans:

146+ - "*.example.com"

147+

148+ services:

149+ a-service-backend:

150+ loadBalancer:

151+ servers:

152+ - url: http://172.16.0.2:7555

153+ b-service-backend:

154+ loadBalancer:

155+ servers:

156+ - url: http://172.16.0.3:7555

157+ oauth-backend:

158+ loadBalancer:

159+ servers:

160+ - url: http://172.16.0.1:4180

161+

162+ middlewares:

163+ auth-headers:

164+ headers:

165+ sslRedirect: true

166+ stsSeconds: 315360000

167+ browserXssFilter: true

168+ contentTypeNosniff: true

169+ forceSTSHeader: true

170+ sslHost: example.com

171+ stsIncludeSubdomains: true

172+ stsPreload: true

173+ frameDeny: true

174+ oauth-auth-redirect:

175+ forwardAuth:

176+ address: https://oauth.example.com/

177+ trustForwardHeader: true

178+ authResponseHeaders:

179+ - X-Auth-Request-Access-Token

180+ - Authorization

181+ oauth-auth-wo-redirect:

182+ forwardAuth:

183+ address: https://oauth.example.com/oauth2/auth

184+ trustForwardHeader: true

185+ authResponseHeaders:

186+ - X-Auth-Request-Access-Token

187+ - Authorization

188+```

189+

190+:::note

191+If you set up your OAuth2 provider to rotate your client secret, you can use the `client-secret-file` option to reload the secret when it is updated.

192+:::

docs/versioned_docs/version-7.15.x/configuration/overview.mdnew file+451

@@ -0,0 +1,451 @@

1+---

2+id: overview

3+title: Overview

4+---

5+

6+`oauth2-proxy` can be configured via [command line options](#command-line-options), [environment variables](#environment-variables) or [config file](#config-file) (in decreasing order of precedence, i.e. command line options will overwrite environment variables and environment variables will overwrite configuration file settings).

7+

8+## Generating a Cookie Secret

9+

10+To generate a strong cookie secret use one of the below commands:

11+

12+import Tabs from '@theme/Tabs';

13+import TabItem from '@theme/TabItem';

14+

15+<Tabs defaultValue="python">

16+ <TabItem value="python" label="Python">

17+

18+```shell

19+python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())'

20+```

21+

22+ </TabItem>

23+ <TabItem value="bash" label="Bash">

24+

25+```shell

26+dd if=/dev/urandom bs=32 count=1 2>/dev/null | base64 | tr -d -- '\n' | tr -- '+/' '-_' ; echo

27+```

28+

29+ </TabItem>

30+ <TabItem value="openssl" label="OpenSSL">

31+

32+```shell

33+openssl rand -base64 32 | tr -- '+/' '-_'

34+```

35+

36+ </TabItem>

37+ <TabItem value="powershell" label="PowerShell">

38+

39+```powershell

40+# Add System.Web assembly to session, just in case

41+Add-Type -AssemblyName System.Web

42+[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes([System.Web.Security.Membership]::GeneratePassword(32,4))).Replace("+","-").Replace("/","_")

43+```

44+

45+ </TabItem>

46+ <TabItem value="terraform" label="Terraform">

47+

48+```hcl

49+# Valid 32 Byte Base64 URL encoding set that will decode to 24 []byte AES-192 secret

50+resource "random_password" "cookie_secret" {

51+ length = 32

52+ override_special = "-_"

53+}

54+```

55+

56+ </TabItem>

57+</Tabs>

58+

59+## Config File

60+

61+Every command line argument can be specified in a config file by replacing hyphens (-) with underscores (\_). If the argument can be specified multiple times, the config option should be plural (trailing s).

62+

63+An example [oauth2-proxy.cfg](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/oauth2-proxy.cfg.example) config file is in the contrib directory. It can be used by specifying `--config=/etc/oauth2-proxy.cfg`

64+

65+## Config Options

66+

67+### Command Line Options

68+

69+| Flag | Description |

70+| ---------------- | ------------------------------------------------------- |

71+| `--config` | path to config file |

72+| `--config-test` | test configuration and exit (for CI/CD validation) |

73+| `--version` | print version string |

74+

75+### General Provider Options

76+

77+Provider specific options can be found on their respective subpages.

78+

79+| Flag / Config Field | Type | Description | Default |

80+| --------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |

81+| flag: `--acr-values`<br/>toml: `acr_values` | string | optional, see [docs](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html#acrValues) | `""` |

82+| flag: `--allowed-group`<br/>toml: `allowed_groups` | string \| list | Restrict login to members of a group or list of groups. Furthermore, if you aren't setting the `scope` and use `allowed_groups` with the generic OIDC provider the scope `groups` gets added implicitly. | |

83+| flag: `--approval-prompt`<br/>toml: `approval_prompt` | string | OAuth approval_prompt | `"force"` |

84+| flag: `--backend-logout-url`<br/>toml: `backend_logout_url` | string | URL to perform backend logout, if you use `{id_token}` in the url it will be replaced by the actual `id_token` of the user session | |

85+| flag: `--client-id`<br/>toml: `client_id` | string | the OAuth Client ID, e.g. `"123456.apps.googleusercontent.com"` | |

86+| flag: `--client-secret-file`<br/>toml: `client_secret_file` | string | the file with OAuth Client Secret. The file must contain the secret only, with no trailing newline | |

87+| flag: `--client-secret`<br/>toml: `client_secret` | string | the OAuth Client Secret | |

88+| flag: `--code-challenge-method`<br/>toml: `code_challenge_method` | string | use PKCE code challenges with the specified method. Either 'plain' or 'S256' (recommended) | |

89+| flag: `--insecure-oidc-allow-unverified-email`<br/>toml: `insecure_oidc_allow_unverified_email` | bool | don't fail if an email address in an id_token is not verified | false |

90+| flag: `--insecure-oidc-skip-issuer-verification`<br/>toml: `insecure_oidc_skip_issuer_verification` | bool | allow the OIDC issuer URL to differ from the expected (currently required for Azure multi-tenant compatibility) | false |

91+| flag: `--insecure-oidc-skip-nonce`<br/>toml: `insecure_oidc_skip_nonce` | bool | skip verifying the OIDC ID Token's nonce claim | true |

92+| flag: `--jwt-key-file`<br/>toml: `jwt_key_file` | string | path to the private key file in PEM format used to sign the JWT so that you can say something like `--jwt-key-file=/etc/ssl/private/jwt_signing_key.pem`: required by login.gov | |

93+| flag: `--jwt-key`<br/>toml: `jwt_key` | string | private key in PEM format used to sign JWT, so that you can say something like `--jwt-key="${OAUTH2_PROXY_JWT_KEY}"`: required by login.gov | |

94+| flag: `--login-url`<br/>toml: `login_url` | string | Authentication endpoint | |

95+| flag: `--auth-request-response-mode`<br/>toml: `auth-request-response-mode` | string | Response mode to ask for during authentication request | |

96+| flag: `--oidc-audience-claim`<br/>toml: `oidc_audience_claims` | string | which OIDC claim contains the audience | `"aud"` |

97+| flag: `--oidc-email-claim`<br/>toml: `oidc_email_claim` | string | which OIDC claim contains the user's email | `"email"` |

98+| flag: `--oidc-extra-audience`<br/>toml: `oidc_extra_audiences` | string \| list | additional audiences which are allowed to pass verification | `"[]"` |

99+| flag: `--oidc-groups-claim`<br/>toml: `oidc_groups_claim` | string | which OIDC claim contains the user groups | `"groups"` |

100+| flag: `--oidc-issuer-url`<br/>toml: `oidc_issuer_url` | string | the OpenID Connect issuer URL, e.g. `"https://accounts.google.com"` | |

101+| flag: `--oidc-jwks-url`<br/>toml: `oidc_jwks_url` | string | OIDC JWKS URI for token verification; required if OIDC discovery is disabled and public key files are not provided | |

102+| flag: `--oidc-public-key-file`<br/>toml: `oidc_public_key_files` | string | Path to public key file in PEM format to use for verifying JWT tokens (may be given multiple times). Required if OIDC discovery is disabled na JWKS URL isn't provided | |

103+| flag: `--oidc-enabled-signing-alg`<br/>toml: `oidc_enabled_signing_algs` | string \| list | List of allowed JWT signing algorithms. When oidc discovery is enabled, the effective set is the intersection between this list and the provider's discovered supported algorithms. | |

104+| flag: `--profile-url`<br/>toml: `profile_url` | string | Profile access endpoint | |

105+| flag: `--prompt`<br/>toml: `prompt` | string | [OIDC prompt](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest); if present, `approval-prompt` is ignored | `""` |

106+| flag: `--provider-ca-file`<br/>toml: `provider_ca_files` | string \| list | Paths to CA certificates that should be used when connecting to the provider. If not specified, the default Go trust sources are used instead. | |

107+| flag: `--provider-display-name`<br/>toml: `provider_display_name` | string | Override the provider's name with the given string; used for the sign-in page | (depends on provider) |

108+| flag: `--provider`<br/>toml: `provider` | string | OAuth provider | google |

109+| flag: `--pubjwk-url`<br/>toml: `pubjwk_url` | string | JWK pubkey access endpoint: required by login.gov | |

110+| flag: `--redeem-url`<br/>toml: `redeem_url` | string | Token redemption endpoint | |

111+| flag: `--scope`<br/>toml:`scope` | string | OAuth scope specification. Every provider has a default list of scopes which will be used in case no scope is configured. | |

112+| flag: `--skip-claims-from-profile-url`<br/>toml: `skip_claims_from_profile_url` | bool | skip request to Profile URL for resolving claims not present in id_token | false |

113+| flag: `--skip-oidc-discovery`<br/>toml: `skip_oidc_discovery` | bool | bypass OIDC endpoint discovery. `--login-url`, `--redeem-url` and `--oidc-jwks-url` must be configured in this case | false |

114+| flag: `--use-system-trust-store`<br/>toml: `use_system_trust_store` | bool | Determines if `provider-ca-file` files and the system trust store are used. If set to true, your custom CA files and the system trust store are used otherwise only your custom CA files. | false |

115+| flag: `--validate-url`<br/>toml: `validate_url` | string | Access token validation endpoint | |

116+

117+### Cookie Options

118+

119+| Flag / Config Field | Type | Description | Default |

120+| --------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |

121+| flag: `--cookie-csrf-expire`<br/>toml: `cookie_csrf_expire` | duration | expire timeframe for CSRF cookie | 15m |

122+| flag: `--cookie-csrf-per-request`<br/>toml:`cookie_csrf_per_request` | bool | Enable having different CSRF cookies per request, making it possible to have parallel requests. | false |

123+| flag: `--cookie-csrf-per-request-limit`<br/>toml: `cookie_csrf_per_request_limit` | int | Sets a limit on the number of CSRF requests cookies that oauth2-proxy will create. The oldest cookie will be removed. Useful if users end up with 431 Request headers too large status codes. Only effective if --cookie-csrf-per-request is true | "infinite" |

124+| flag: `--cookie-csrf-samesite`<br/>toml: `cookie_csrf_samesite` | string | set SameSite CSRF cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`). When using the default setting, the CSRF cookie samesite value is taken from the session cookie configuration. | `""` |

125+| flag: `--cookie-domain`<br/>toml: `cookie_domains` | string \| list | Optional cookie domains to force cookies to (e.g. `.yourcompany.com`). The longest domain matching the request's host will be used (or the shortest cookie domain if there is no match). | |

126+| flag: `--cookie-expire`<br/>toml: `cookie_expire` | duration | expire timeframe for cookie. If set to 0, cookie becomes a session-cookie which will expire when the browser is closed. | 168h0m0s |

127+| flag: `--cookie-httponly`<br/>toml: `cookie_httponly` | bool | set HttpOnly cookie flag | true |

128+| flag: `--cookie-name`<br/>toml: `cookie_name` | string | the name of the cookie that the oauth_proxy creates. Should be changed to use a [cookie prefix](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes) (`__Host-` or `__Secure-`) if `--cookie-secure` is set. | `"_oauth2_proxy"` |

129+| flag: `--cookie-path`<br/>toml: `cookie_path` | string | an optional cookie path to force cookies to (e.g. `/poc/`) | `"/"` |

130+| flag: `--cookie-refresh`<br/>toml: `cookie_refresh` | duration | refresh the cookie after this duration; `0` to disable; not supported by all providers&nbsp;[^1] | |

131+| flag: `--cookie-samesite`<br/>toml: `cookie_samesite` | string | set SameSite cookie attribute (`"lax"`, `"strict"`, `"none"`, or `""`). | `""` |

132+| flag: `--cookie-secret`<br/>toml: `cookie_secret` | string | the seed string for secure cookies (optionally base64 encoded) | |

133+| flag: `--cookie-secret-file`<br/>toml: `cookie_secret_file` | string | File containing the cookie secret (must be raw binary, exactly 16, 24, or 32 bytes). Use dd if=/dev/urandom bs=32 count=1 > cookie.secret to generate | |

134+| flag: `--cookie-secure`<br/>toml: `cookie_secure` | bool | set [secure (HTTPS only) cookie flag](https://owasp.org/www-community/controls/SecureFlag) | true |

135+

136+[^1]: The following providers support `--cookie-refresh`: ADFS, Azure, GitLab, Google, Keycloak and all other Identity Providers which support the full [OIDC specification](https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens)

137+

138+### Header Options

139+

140+| Flag / Config Field | Type | Description | Default |

141+| ------------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

142+| flag: `--basic-auth-password`<br/>toml: `basic_auth_password` | string | the password to set when passing the HTTP Basic Auth header | |

143+| flag: `--set-xauthrequest`<br/>toml: `set_xauthrequest` | bool | set X-Auth-Request-User, X-Auth-Request-Groups, X-Auth-Request-Email and X-Auth-Request-Preferred-Username response headers (useful in Nginx auth_request mode). When used with `--pass-access-token`, X-Auth-Request-Access-Token is added to response headers. | false |

144+| flag: `--set-authorization-header`<br/>toml: `set_authorization_header` | bool | set Authorization Bearer response header (useful in Nginx auth_request mode) | false |

145+| flag: `--set-basic-auth`<br/>toml: `set_basic_auth` | bool | set HTTP Basic Auth information in response (useful in Nginx auth_request mode) | false |

146+| flag: `--skip-auth-strip-headers`<br/>toml: `skip_auth_strip_headers` | bool | strips `X-Forwarded-*` style authentication headers & `Authorization` header if they would be set by oauth2-proxy | true |

147+| flag: `--pass-access-token`<br/>toml: `pass_access_token` | bool | pass OAuth access_token to upstream via X-Forwarded-Access-Token header. When used with `--set-xauthrequest` this adds the X-Auth-Request-Access-Token header to the response | false |

148+| flag: `--pass-authorization-header`<br/>toml: `pass_authorization_header` | bool | pass OIDC IDToken to upstream via Authorization Bearer header | false |

149+| flag: `--pass-basic-auth`<br/>toml: `pass_basic_auth` | bool | pass HTTP Basic Auth, X-Forwarded-User, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream | true |

150+| flag: `--prefer-email-to-user`<br/>toml: `prefer_email_to_user` | bool | Prefer to use the Email address as the Username when passing information to upstream. Will only use Username if Email is unavailable, e.g. htaccess authentication. Used in conjunction with `--pass-basic-auth` and `--pass-user-headers` | false |

151+| flag: `--pass-user-headers`<br/>toml: `pass_user_headers` | bool | pass X-Forwarded-User, X-Forwarded-Groups, X-Forwarded-Email and X-Forwarded-Preferred-Username information to upstream | true |

152+

153+### Logging Options

154+

155+| Flag / Config Field | Type | Description | Default |

156+| --------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------- | --------------------------------------------------- |

157+| flag: `--auth-logging-format`<br/>toml: `auth_logging_format` | string | Template for authentication log lines | see [Logging Configuration](#logging-configuration) |

158+| flag: `--auth-logging`<br/>toml: `auth_logging` | bool | Log authentication attempts | true |

159+| flag: `--errors-to-info-log`<br/>toml: `errors_to_info_log` | bool | redirects error-level logging to default log channel instead of stderr | false |

160+| flag: `--exclude-logging-path`<br/>toml: `exclude_logging_paths` | string | comma separated list of paths to exclude from logging, e.g. `"/ping,/path2"` | `""` (no paths excluded) |

161+| flag: `--logging-compress`<br/>toml: `logging_compress` | bool | Should rotated log files be compressed using gzip | false |

162+| flag: `--logging-filename`<br/>toml: `logging_filename` | string | File to log requests to, empty for `stdout` | `""` (stdout) |

163+| flag: `--logging-local-time`<br/>toml: `logging_local_time` | bool | Use local time in log files and backup filenames instead of UTC | true (local time) |

164+| flag: `--logging-max-age`<br/>toml: `logging_max_age` | int | Maximum number of days to retain old log files | 7 |

165+| flag: `--logging-max-backups`<br/>toml: `logging_max_backups` | int | Maximum number of old log files to retain; 0 to disable | 0 |

166+| flag: `--logging-max-size`<br/>toml: `logging_max_size` | int | Maximum size in megabytes of the log file before rotation | 100 |

167+| flag: `--request-id-header`<br/>toml: `request_id_header` | string | Request header to use as the request ID in logging | X-Request-Id |

168+| flag: `--request-logging-format`<br/>toml: `request_logging_format` | string | Template for request log lines | see [Logging Configuration](#logging-configuration) |

169+| flag: `--request-logging`<br/>toml: `request_logging` | bool | Log requests | true |

170+| flag: `--silence-ping-logging`<br/>toml: `silence_ping_logging` | bool | disable logging of requests to ping & ready endpoints | false |

171+| flag: `--standard-logging-format`<br/>toml: `standard_logging_format` | string | Template for standard log lines | see [Logging Configuration](#logging-configuration) |

172+| flag: `--standard-logging`<br/>toml: `standard_logging` | bool | Log standard runtime information | true |

173+

174+### Page Template Options

175+

176+| Flag / Config Field | Type | Description | Default |

177+| ----------------------------------------------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------- | ------- |

178+| flag: `--banner`<br/>toml: `banner` | string | custom (html) banner string. Use `"-"` to disable default banner. | |

179+| flag: `--custom-sign-in-logo`<br/>toml: `custom_sign_in_logo` | string | path or a URL to an custom image for the sign_in page logo. Use `"-"` to disable default logo. | |

180+| flag: `--custom-templates-dir`<br/>toml: `custom_templates_dir` | string | path to custom html templates | |

181+| flag: `--display-htpasswd-form`<br/>toml: `display_htpasswd_form` | bool | display username / password login form if an htpasswd file is provided | true |

182+| flag: `--footer`<br/>toml: `footer` | string | custom (html) footer string. Use `"-"` to disable default footer. (Can be used to obfuscate the version) | |

183+| flag: `--show-debug-on-error`<br/>toml: `show_debug_on_error` | bool | show detailed error information on error pages (WARNING: this may contain sensitive information - do not use in production) | false |

184+

185+### Probe Options

186+

187+| Flag / Config Field | Type | Description | Default |

188+| ------------------------------------------------------- | ------ | ---------------------------------------------------------- | ----------------------------- |

189+| flag: `--ping-path`<br/>toml: `ping_path` | string | the ping endpoint that can be used for basic health checks | `"/ping"` |

190+| flag: `--ping-user-agent`<br/>toml: `ping_user_agent` | string | a User-Agent that can be used for basic health checks | `""` (don't check user agent) |

191+| flag: `--ready-path`<br/>toml: `ready_path` | string | the ready endpoint that can be used for deep health checks | `"/ready"` |

192+| flag: `--gcp-healthchecks`<br/>toml: `gcp_healthchecks` | bool | Enable GCP/GKE healthcheck endpoints (deprecated) | false |

193+

194+### Proxy Options

195+

196+:::warning

197+When `--reverse-proxy` is enabled, configure `--trusted-proxy-ip` to the IPs or CIDR ranges of the reverse proxies that are allowed to send `X-Forwarded-*` headers. If you leave it unset, OAuth2 Proxy currently trusts all source IPs for backwards compatibility, which means a client that can reach OAuth2 Proxy directly may be able to spoof forwarded headers.

198+:::

199+

200+| Flag / Config Field | Type | Description | Default |

201+| ----------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |

202+| flag: `--allow-query-semicolons`<br/>toml: `allow_query_semicolons` | bool | allow the use of semicolons in query args ([required for some legacy applications](https://github.com/golang/go/issues/25192)) | `false` |

203+| flag: `--api-route`<br/>toml: `api_routes` | string \| list | Requests to these paths must already be authenticated with a cookie, or a JWT if `--skip-jwt-bearer-tokens` is set. No redirect to login will be done. Return 401 if not. Format: path_regex | |

204+| flag: `--authenticated-emails-file`<br/>toml: `authenticated_emails_file` | string | authenticate against emails via file (one per line) | |

205+| flag: `--bearer-token-login-fallback`<br/>toml: `bearer_token_login_fallback` | bool | if `--skip-jwt-bearer-tokens` is set, if a request includes an invalid JWT (expired, malformed, missing required audiences, etc), fall back to normal login redirect as if the token were not sent at all. If false, respond 403 | true |

206+| flag: `--email-domain`<br/>toml: `email_domains` | string \| list | authenticate emails with the specified domain (may be given multiple times). Use `*` to authenticate any email | |

207+| flag: `--encode-state`<br/>toml: `encode_state` | bool | encode the state parameter as UrlEncodedBase64 | false |

208+| flag: `--extra-jwt-issuers`<br/>toml: `extra_jwt_issuers` | string | if `--skip-jwt-bearer-tokens` is set, a list of extra JWT `issuer=audience` (see a token's `iss`, `aud` fields) pairs (where the issuer URL has a `.well-known/openid-configuration` or a `.well-known/jwks.json`) | |

209+| flag: `--force-https`<br/>toml: `force_https` | bool | enforce https redirect | `false` |

210+| flag: `--force-json-errors`<br/>toml: `force_json_errors` | bool | force JSON errors instead of HTTP error pages or redirects | `false` |

211+| flag: `--htpasswd-file`<br/>toml: `htpasswd_file` | string | additionally authenticate against a htpasswd file. Entries must be created with `htpasswd -B` for bcrypt encryption | |

212+| flag: `--htpasswd-user-group`<br/>toml: `htpasswd_user_groups` | string \| list | the groups to be set on sessions for htpasswd users | |

213+| flag: `--proxy-prefix`<br/>toml: `proxy_prefix` | string | the url root path that this proxy should be nested under (e.g. /`<oauth2>/sign_in`) | `"/oauth2"` |

214+| flag: `--real-client-ip-header`<br/>toml: `real_client_ip_header` | string | Header used to determine the real IP of the client, requires `--reverse-proxy` to be set (one of: X-Forwarded-For, X-Real-IP, X-ProxyUser-IP, X-Envoy-External-Address, or CF-Connecting-IP) | X-Real-IP |

215+| flag: `--redirect-url`<br/>toml: `redirect_url` | string | the OAuth Redirect URL, e.g. `"https://internalapp.yourcompany.com/oauth2/callback"` | |

216+| flag: `--relative-redirect-url`<br/>toml: `relative_redirect_url` | bool | allow relative OAuth Redirect URL.` | false |

217+| flag: `--reverse-proxy`<br/>toml: `reverse_proxy` | bool | are we running behind a reverse proxy, controls whether headers like X-Real-IP are accepted and allows X-Forwarded-\{Proto,Host,Uri\} headers to be used on redirect selection | false |

218+| flag: `--trusted-proxy-ip`<br/>toml: `trusted_proxy_ips` | string \| list | list of IPs or CIDR ranges allowed to supply `X-Forwarded-*` headers when `--reverse-proxy` is enabled. If not set, OAuth2 Proxy preserves backwards compatibility by trusting all source IPs (`0.0.0.0/0`, `::/0`) and logs a warning at startup. Configure this to your reverse proxy addresses to prevent forwarded header spoofing. | `"0.0.0.0/0", "::/0"` |

219+| flag: `--signature-key`<br/>toml: `signature_key` | string | GAP-Signature request signature key (algorithm:secretkey) | |

220+| flag: `--skip-auth-preflight`<br/>toml: `skip_auth_preflight` | bool | will skip authentication for OPTIONS requests | false |

221+| flag: `--skip-auth-regex`<br/>toml: `skip_auth_regex` | string \| list | (DEPRECATED for `--skip-auth-route`) bypass authentication for requests paths that match (may be given multiple times) | |

222+| flag: `--skip-auth-route`<br/>toml: `skip_auth_routes` | string \| list | bypass authentication for requests that match the method & path. Format: method=path_regex OR method!=path_regex. For all methods: path_regex OR !=path_regex | |

223+| flag: `--skip-jwt-bearer-tokens`<br/>toml: `skip_jwt_bearer_tokens` | bool | will skip requests that have verified JWT bearer tokens (the token must have [`aud`](https://en.wikipedia.org/wiki/JSON_Web_Token#Standard_fields) that matches this client id or one of the extras from `extra-jwt-issuers`) | false |

224+| flag: `--skip-provider-button`<br/>toml: `skip_provider_button` | bool | will skip sign-in-page to directly reach the next step: oauth/start | false |

225+| flag: `--ssl-insecure-skip-verify`<br/>toml: `ssl_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS providers | false |

226+| flag: `--trusted-ip`<br/>toml: `trusted_ips` | string \| list | list of IPs or CIDR ranges to allow to bypass authentication (may be given multiple times). When combined with `--reverse-proxy` and optionally `--real-client-ip-header` this will evaluate the trust of the IP stored in an HTTP header by a reverse proxy rather than the layer-3/4 remote address. WARNING: trusting IPs has inherent security flaws, especially when obtaining the IP address from an HTTP header (reverse-proxy mode). Use this option only if you understand the risks and how to manage them. | |

227+| flag: `--whitelist-domain`<br/>toml: `whitelist_domains` | string \| list | allowed domains for redirection after authentication. Prefix domain with a `.` or a `*.` to allow subdomains (e.g. `.example.com`, `*.example.com`)&nbsp;[^2] | |

228+

229+[^2]: When using the `whitelist-domain` option, any domain prefixed with a `.` or a `*.` will allow any subdomain of the specified domain as a valid redirect URL. By default, only empty ports are allowed. This translates to allowing the default port of the URL's protocol (80 for HTTP, 443 for HTTPS, etc.) since browsers omit them. To allow only a specific port, add it to the whitelisted domain: `example.com:8080`. To allow any port, use `*`: `example.com:*`.

230+

231+### Server Options

232+

233+| Flag / Config Field | Type | Description | Default |

234+| ------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |

235+| flag: `--http-address`<br/>toml: `http_address` | string | `[http://]<addr>:<port>` or `unix://<path>` or `fd:<int>` (case insensitive) to listen on for HTTP clients. Unix sockets are created with default system umask mode, which can be overridden, e.g. `unix://my-socket,mode=0777`. Square brackets are required for ipv6 address, e.g. `http://[::1]:4180` | `"127.0.0.1:4180"` |

236+| flag: `--https-address`<br/>toml: `https_address` | string | `[https://]<addr>:<port>` to listen on for HTTPS clients. Square brackets are required for ipv6 address, e.g. `https://[::1]:443` | `":443"` |

237+| flag: `--metrics-address`<br/>toml: `metrics_address` | string | the address prometheus metrics will be scraped from | `""` |

238+| flag: `--metrics-secure-address`<br/>toml: `metrics_secure_address` | string | the address prometheus metrics will be scraped from if using HTTPS | `""` |

239+| flag: `--metrics-tls-cert-file`<br/>toml: `metrics_tls_cert_file` | string | path to certificate file for secure metrics server | `""` |

240+| flag: `--metrics-tls-key-file`<br/>toml: `metrics_tls_key_file` | string | path to private key file for secure metrics server | `""` |

241+| flag: `--tls-cert-file`<br/>toml: `tls_cert_file` | string | path to certificate file | |

242+| flag: `--tls-key-file`<br/>toml: `tls_key_file` | string | path to private key file | |

243+| flag: `--tls-cipher-suite`<br/>toml: `tls_cipher_suites` | string \| list | Restricts TLS cipher suites used by server to those listed (e.g. TLS_RSA_WITH_RC4_128_SHA) (may be given multiple times). If not specified, the default Go safe cipher list is used. List of valid cipher suites can be found in the [crypto/tls documentation](https://pkg.go.dev/crypto/tls#pkg-constants). | |

244+| flag: `--tls-min-version`<br/>toml: `tls_min_version` | string | minimum TLS version that is acceptable, either `"TLS1.2"` or `"TLS1.3"` | `"TLS1.2"` |

245+

246+### Session Options

247+

248+| Flag / Config Field | Type | Description | Default |

249+| ----------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

250+| flag: `--session-cookie-minimal`<br/>toml: `session_cookie_minimal` | bool | strip OAuth tokens from cookie session stores if they aren't needed (cookie session store only) | false |

251+| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

252+| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

253+| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

254+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. | |

255+| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

256+| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

257+| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

258+| flag: `--redis-sentinel-master-name`<br/>toml: `redis_sentinel_master_name` | string | Redis sentinel master name. Used in conjunction with `--redis-use-sentinel` | |

259+| flag: `--redis-sentinel-connection-urls`<br/>toml: `redis_sentinel_connection_urls` | string \| list | List of Redis sentinel connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-sentinel` | |

260+| flag: `--redis-use-cluster`<br/>toml: `redis_use_cluster` | bool | Connect to redis cluster. Must set `--redis-cluster-connection-urls` to use this feature | false |

261+| flag: `--redis-use-sentinel`<br/>toml: `redis_use_sentinel` | bool | Connect to redis via sentinels. Must set `--redis-sentinel-master-name` and `--redis-sentinel-connection-urls` to use this feature | false |

262+| flag: `--redis-connection-idle-timeout`<br/>toml: `redis_connection_idle_timeout` | int | Redis connection idle timeout seconds. If Redis [timeout](https://redis.io/docs/reference/clients/#client-timeouts) option is set to non-zero, the `--redis-connection-idle-timeout` must be less than Redis timeout option. Example: if either redis.conf includes `timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14` | 0 |

263+

264+### Upstream Options

265+

266+| Flag / Config Field | Type | Description | Default |

267+| ----------------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- |

268+| flag: `--flush-interval`<br/>toml: `flush_interval` | duration | period between flushing response buffers when streaming responses | `"1s"` |

269+| flag: `--pass-host-header`<br/>toml: `pass_host_header` | bool | pass the request Host Header to upstream | true |

270+| flag: `--proxy-websockets`<br/>toml: `proxy_websockets` | bool | enables WebSocket proxying | true |

271+| flag: `--ssl-upstream-insecure-skip-verify`<br/>toml: `ssl_upstream_insecure_skip_verify` | bool | skip validation of certificates presented when using HTTPS upstreams | false |

272+| flag: `--disable-keep-alives`<br/>toml: `disable_keep_alives` | bool | disable HTTP keep-alive connections to the upstream server | false |

273+| flag: `--upstream-timeout`<br/>toml: `upstream_timeout` | duration | maximum amount of time the server will wait for a response from the upstream | 30s |

274+| flag: `--upstream`<br/>toml: `upstreams` | string \| list | the http url(s) of the upstream endpoint, file:// paths for static files or `static://<status_code>` for static response. Routing is based on the path | |

275+

276+## Configuration Validation

277+

278+The `--config-test` flag validates your configuration file without starting the proxy server. This is useful for:

279+- **CI/CD pipelines**: Pre-deployment validation

280+- **Configuration management**: Testing before applying changes

281+- **Debugging**: Verifying syntax and required fields

282+

283+### Usage

284+

285+```bash

286+# Test legacy config

287+oauth2-proxy --config /etc/oauth2-proxy.cfg --config-test

288+

289+# Test alpha config

290+oauth2-proxy --config /etc/core.cfg --alpha-config /etc/alpha.yaml --config-test

291+

292+# CI/CD pre-deployment check

293+# Returns with exit code 1 if any validation errors occur

294+oauth2-proxy --config new-config.cfg --config-test

295+```

296+

297+### Exit Codes

298+

299+- **0**: Configuration is valid ✅

300+- **1**: Configuration is invalid (errors printed to stderr) ❌

301+

302+### Validation Coverage

303+

304+The `--config-test` flag performs the **same comprehensive validation** as normal startup, including:

305+- Required fields (client ID, client secret, cookie secret, etc.)

306+- Syntax validation (TOML/YAML parsing)

307+- Provider configuration

308+- Upstream server definitions

309+- Session store connectivity (e.g., Redis network checks if configured)

310+

311+**Note**: Cannot be combined with `--convert-config-to-alpha`.

312+

313+## Upstreams Configuration

314+

315+`oauth2-proxy` supports having multiple upstreams, and has the option to pass requests on to HTTP(S) servers, unix socket or serve static files from the file system.

316+

317+To configure **HTTP and HTTPS upstreams**, provide such a URL in `--upstream=URL`. The scheme+host portion and the path portion are extracted to configure proxying behavior. When processing incoming requests, the path portion becomes a lookup key for selecting the destination server of the proxied request.

318+

319+* Upstream URLs *without a trailing slash,* like in `--upstream=http://service2.internal/foo`, will match an incoming request exactly to `/foo` in `https://this.o2p.example.com/foo`, and forward the request on to service2.internal, but not match a request to `https://this.o2p.example.com/foo/more` nor ...`.com/food`.

320+* Upstream URLs *with a trailing slash,* like in `--upstream=http://service1.internal/foo/`, will match any incoming request to any incoming requests's path *starting with* `/foo/`, like `/foo/` and `/foo/more` and `/foo/lots/more?etc`.

321+

322+If multiple `--upstream` URLs' paths match an incoming request, the one with the longest matching path (the most specific match) takes priority over shorter (less specific) ones.

323+

324+**Unix socket upstreams** are configured as `unix:///path/to/unix.sock`.

325+

326+**Static file paths** are configured as a file:// URL. `file:///var/www/static/` will serve the files from that directory at `http://[oauth2-proxy url]/var/www/static/`, which may not be what you want. You can provide the path to where the files should be available by adding a fragment to the configured URL. The value of the fragment will then be used to specify which path the files are available at, e.g. `file:///var/www/static/#/static/` will make `/var/www/static/` available at `http://[oauth2-proxy url]/static/`.

327+

328+Multiple upstreams can either be configured by supplying a comma separated list to the `--upstream` parameter, supplying the parameter multiple times or providing a list in the [config file](#config-file). When multiple upstreams are used routing to them will be based on the path they are set up with.

329+

330+## Environment variables

331+

332+Every command line argument can be specified as an environment variable by

333+prefixing it with `OAUTH2_PROXY_`, capitalising it, and replacing hyphens (`-`)

334+with underscores (`_`). If the argument can be specified multiple times, the

335+environment variable should be plural (trailing `S`).

336+

337+This is particularly useful for storing secrets outside a configuration file

338+or the command line.

339+

340+For example, the `--cookie-secret` flag becomes `OAUTH2_PROXY_COOKIE_SECRET`.

341+If a flag has the type `string | list` like the `--email-domain` flag it is

342+available as an environment variable in plural form e.g. `OAUTH2_PROXY_EMAIL_DOMAINS`

343+

344+Values for type `string | list` usually have a plural environment variable name

345+and need to be seperated by `,` e.g.

346+`OAUTH2_PROXY_SKIP_AUTH_ROUTES="GET=^/api/status,POST=^/api/saved_objects/_import"`

347+

348+Please check the type for each [config option](#config-options) first.

349+

350+## Logging Configuration

351+

352+By default, OAuth2 Proxy logs all output to stdout. Logging can be configured to output to a rotating log file using the `--logging-filename` command.

353+

354+If logging to a file you can also configure the maximum file size (`--logging-max-size`), age (`--logging-max-age`), max backup logs (`--logging-max-backups`), and if backup logs should be compressed (`--logging-compress`).

355+

356+There are three different types of logging: standard, authentication, and HTTP requests. These can each be enabled or disabled with `--standard-logging`, `--auth-logging`, and `--request-logging`.

357+

358+Each type of logging has its own configurable format and variables. By default, these formats are similar to the Apache Combined Log.

359+

360+Logging of requests to the `/ping` endpoint (or using `--ping-user-agent`) and the `/ready` endpoint can be disabled with `--silence-ping-logging` reducing log volume.

361+

362+## Auth Log Format

363+

364+Authentication logs are logs which are guaranteed to contain a username or email address of a user attempting to authenticate. These logs are output by default in the below format:

365+

366+```

367+<REMOTE_ADDRESS> - <REQUEST ID> - <user@domain.com> [2015/03/19 17:20:19] [<STATUS>] <MESSAGE>

368+```

369+

370+The status block will contain one of the below strings:

371+

372+- `AuthSuccess` If a user has authenticated successfully by any method

373+- `AuthFailure` If the user failed to authenticate explicitly

374+- `AuthError` If there was an unexpected error during authentication

375+

376+If you require a different format than that, you can configure it with the `--auth-logging-format` flag.

377+The default format is configured as follows:

378+

379+```

380+{{.Client}} - {{.RequestID}} - {{.Username}} [{{.Timestamp}}] [{{.Status}}] {{.Message}}

381+```

382+

383+Available variables for auth logging:

384+

385+| Variable | Example | Description |

386+| ------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------- |

387+| Client | 74.125.224.72 | The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true. |

388+| Host | domain.com | The value of the Host header. |

389+| Message | Authenticated via OAuth2 | The details of the auth attempt. |

390+| Protocol | HTTP/1.0 | The request protocol. |

391+| RequestID | 00010203-0405-4607-8809-0a0b0c0d0e0f | The request ID pulled from the `--request-id-header`. Random UUID if empty |

392+| RequestMethod | GET | The request method. |

393+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

394+| UserAgent | - | The full user agent as reported by the requesting client. |

395+| Username | username@email.com | The email or username of the auth request. |

396+| Status | AuthSuccess | The status of the auth request. See above for details. |

397+

398+## Request Log Format

399+

400+HTTP request logs will output by default in the below format:

401+

402+```

403+<REMOTE_ADDRESS> - <REQUEST ID> - <user@domain.com> [2015/03/19 17:20:19] <HOST_HEADER> GET <UPSTREAM_HOST> "/path/" HTTP/1.1 "<USER_AGENT>" <RESPONSE_CODE> <RESPONSE_BYTES> <REQUEST_DURATION>

404+```

405+

406+If you require a different format than that, you can configure it with the `--request-logging-format` flag.

407+The default format is configured as follows:

408+

409+```

410+{{.Client}} - {{.RequestID}} - {{.Username}} [{{.Timestamp}}] {{.Host}} {{.RequestMethod}} {{.Upstream}} {{.RequestURI}} {{.Protocol}} {{.UserAgent}} {{.StatusCode}} {{.ResponseSize}} {{.RequestDuration}}

411+```

412+

413+Available variables for request logging:

414+

415+| Variable | Example | Description |

416+| --------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------- |

417+| Client | 74.125.224.72 | The client/remote IP address. Will use the X-Real-IP header it if exists & reverse-proxy is set to true. |

418+| Host | domain.com | The value of the Host header. |

419+| Protocol | HTTP/1.0 | The request protocol. |

420+| RequestDuration | 0.001 | The time in seconds that a request took to process. |

421+| RequestID | 00010203-0405-4607-8809-0a0b0c0d0e0f | The request ID pulled from the `--request-id-header`. Random UUID if empty |

422+| RequestMethod | GET | The request method. |

423+| RequestURI | "/oauth2/auth" | The URI path of the request. |

424+| ResponseSize | 12 | The size in bytes of the response. |

425+| StatusCode | 200 | The HTTP status code of the response. |

426+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

427+| Upstream | - | The upstream data of the HTTP request. |

428+| UserAgent | - | The full user agent as reported by the requesting client. |

429+| Username | username@email.com | The email or username of the auth request. |

430+

431+## Standard Log Format

432+

433+All other logging that is not covered by the above two types of logging will be output in this standard logging format. This includes configuration information at startup and errors that occur outside of a session. The default format is below:

434+

435+```

436+[2015/03/19 17:20:19] [main.go:40] <MESSAGE>

437+```

438+

439+If you require a different format than that, you can configure it with the `--standard-logging-format` flag. The default format is configured as follows:

440+

441+```

442+[{{.Timestamp}}] [{{.File}}] {{.Message}}

443+```

444+

445+Available variables for standard logging:

446+

447+| Variable | Example | Description |

448+| --------- | --------------------------------- | -------------------------------------------------- |

449+| Timestamp | 2015/03/19 17:20:19 | The date and time of the logging event. |

450+| File | main.go:40 | The file and line number of the logging statement. |

451+| Message | HTTP: listening on 127.0.0.1:4180 | The details of the log statement. |

docs/versioned_docs/version-7.15.x/configuration/providers/adfs.mdnew file+19

@@ -0,0 +1,19 @@

1+---

2+id: adfs

3+title: ADFS

4+---

5+

6+1. Open the ADFS administration console on your Windows Server and add a new Application Group

7+2. Provide a name for the integration, select Server Application from the Standalone applications section and click Next

8+3. Follow the wizard to get the client-id, client-secret and configure the application credentials

9+4. Configure the proxy with

10+

11+```

12+ --provider=adfs

13+ --client-id=<application ID from step 3>

14+ --client-secret=<value from step 3>

15+```

16+

17+Note: When using the ADFS Auth provider with nginx and the cookie session store you may find the cookie is too large and

18+doesn't get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the

19+[redis session storage](../sessions.md#redis-storage) should resolve this.

docs/versioned_docs/version-7.15.x/configuration/providers/bitbucket.mdnew file+25

@@ -0,0 +1,25 @@

1+---

2+id: bitbucket

3+title: BitBucket

4+---

5+

6+1. [Add a new OAuth consumer](https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html)

7+ * In "Callback URL" use `https://<oauth2-proxy>/oauth2/callback`, substituting `<oauth2-proxy>` with the actual

8+ hostname that oauth2-proxy is running on.

9+ * In Permissions section select:

10+ * Account -> Email

11+ * Team membership -> Read

12+ * Repositories -> Read

13+2. Note the Client ID and Client Secret.

14+

15+To use the provider, pass the following options:

16+

17+```

18+ --provider=bitbucket

19+ --client-id=<Client ID>

20+ --client-secret=<Client Secret>

21+```

22+

23+The default configuration allows everyone with Bitbucket account to authenticate. To restrict the access to the team

24+members use additional configuration option: `--bitbucket-team=<Team name>`. To restrict the access to only these users

25+who have access to one selected repository use `--bitbucket-repository=<Repository name>`.

docs/versioned_docs/version-7.15.x/configuration/providers/cidaas.mdnew file+37

@@ -0,0 +1,37 @@

1+---

2+id: cidaas

3+title: Cidaas

4+---

5+

6+[Cidaas](https://www.cidaas.com/) is an Identity as a Service (IDaaS) solution that provides authentication and authorization services.

7+It supports various protocols including OpenID Connect, OAuth 2.0, and SAML.

8+

9+However, Cidaas provides groups and their roles as hierarchical claims, which are not supported by oauth2-proxy yet.

10+The Cidaas provider transforms the hierarchical claims into a flat list of groups, which can be used by oauth2-proxy.

11+

12+Example of groups and roles in Cidaas:

13+

14+```json

15+{

16+ "groups": [

17+ {

18+ "groupId": "group1",

19+ "roles": ["role1", "role2"]

20+ },

21+ {

22+ "groupId": "group2",

23+ "roles": ["role3"]

24+ }

25+ ]

26+}

27+```

28+

29+This will be transformed into a flat list of groups:

30+

31+```json

32+{

33+ "groups": ["group1:role1", "group2:role2", "group2:role3"]

34+}

35+```

36+

37+Apart from that the Cidaas provider inherits all the features of the [OpenID Connect provider](openid_connect.md).

docs/versioned_docs/version-7.15.x/configuration/providers/cisco_duo.mdnew file+44

@@ -0,0 +1,44 @@

1+---

2+id: cisco_duo

3+title: Cisco Duo

4+---

5+

6+Cisco Duo SSO can be configured with OAuth2 Proxy using the OIDC provider.

7+

8+1. Create a new **Generic OIDC Relying Party - Single Sign-On** application in the Duo Admin Portal

9+2. Configure OAuth2 Proxy with the following options:

10+

11+```

12+provider = "oidc"

13+provider_display_name = "Duo SSO"

14+scope = "openid email profile"

15+pass_access_token = true

16+code_challenge_method = "S256"

17+```

18+

19+3. Configure Provider endpoints. Copy the following values from the corresponding fields in the Duo Admin Portal:

20+

21+```

22+# Copy from "Client ID" field

23+client_id = "XXXXXXXX"

24+

25+# Copy from "Client Secret" field

26+client_secret = "XXXXXXXX"

27+

28+# Copy from "Issuer" field

29+oidc_issuer_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx"

30+

31+# Copy from "JWKS URL" field

32+oidc_jwks_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/jwks"

33+

34+# Copy from "Token Introspection URL" field

35+validate_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/token_introspection"

36+

37+# Copy from "UserInfo" field

38+profile_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/userinfo"

39+

40+# Copy from "Token URL" field

41+redeem_url = "https://sso-xxxxxxxx.sso.duosecurity.com/oidc/xxxxxxxx/token"

42+```

43+

44+4. Complete Configuration by filling in any remaining required fields and save your configuration.

docs/versioned_docs/version-7.15.x/configuration/providers/digitalocean.mdnew file+21

@@ -0,0 +1,21 @@

1+---

2+id: digitalocean

3+title: DigitalOcean

4+---

5+

6+1. [Create a new OAuth application](https://cloud.digitalocean.com/account/api/applications)

7+ * You can fill in the name, homepage, and description however you wish.

8+ * In the "Application callback URL" field, enter: `https://oauth-proxy/oauth2/callback`, substituting `oauth2-proxy`

9+ with the actual hostname that oauth2-proxy is running on. The URL must match oauth2-proxy's configured redirect URL.

10+2. Note the Client ID and Client Secret.

11+

12+To use the provider, pass the following options:

13+

14+```

15+ --provider=digitalocean

16+ --client-id=<Client ID>

17+ --client-secret=<Client Secret>

18+```

19+

20+Alternatively, set the equivalent options in the config file. The redirect URL defaults to

21+`https://<requested host header>/oauth2/callback`. If you need to change it, you can use the `--redirect-url` command-line option.

docs/versioned_docs/version-7.15.x/configuration/providers/facebook.mdnew file+7

@@ -0,0 +1,7 @@

1+---

2+id: facebook

3+title: Facebook

4+---

5+

6+1. Create a new FB App from https://developers.facebook.com/

7+2. Under FB Login, set your Valid OAuth redirect URIs to `https://internal.yourcompany.com/oauth2/callback`

docs/versioned_docs/version-7.15.x/configuration/providers/gitea.mdnew file+24

@@ -0,0 +1,24 @@

1+---

2+id: gitea

3+title: Gitea / Forgejo

4+---

5+

6+:::note

7+This is not actually a fully serparate provider. For more details and options please refer to the [GitHub Provider Options](github.md)

8+:::

9+

10+1. Create a new application: `https://< your gitea host >/user/settings/applications`

11+2. Under `Redirect URI` enter the correct URL i.e. `https://<proxied host>/oauth2/callback`

12+3. Note the Client ID and Client Secret.

13+4. Pass the following options to the proxy:

14+

15+```

16+ --provider="github"

17+ --redirect-url="https://<proxied host>/oauth2/callback"

18+ --provider-display-name="Gitea"

19+ --client-id="< client_id as generated by Gitea >"

20+ --client-secret="< client_secret as generated by Gitea >"

21+ --login-url="https://< your gitea host >/login/oauth/authorize"

22+ --redeem-url="https://< your gitea host >/login/oauth/access_token"

23+ --validate-url="https://< your gitea host >/api/v1/user/emails"

24+```

docs/versioned_docs/version-7.15.x/configuration/providers/github.mdnew file+81

@@ -0,0 +1,81 @@

1+---

2+id: github

3+title: GitHub

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ---------------- | -------------- | -------------- | ------------------------------------------------------------------------------------------------------------- | ------- |

10+| `--github-org` | `github_org` | string | restrict logins to members of this organisation | |

11+| `--github-team` | `github_team` | string | restrict logins to members of any of these teams (slug) or (org:team), comma separated | |

12+| `--github-repo` | `github_repo` | string | restrict logins to collaborators of this repository formatted as `orgname/repo` | |

13+| `--github-token` | `github_token` | string | the token to use when verifying repository collaborators (must have push access to the repository) | |

14+| `--github-user` | `github_users` | string \| list | To allow users to login by username even if they do not belong to the specified org and team or collaborators | |

15+

16+## Usage

17+

18+1. Create a new project: https://github.com/settings/developers

19+2. Under `Authorization callback URL` enter the correct url ie `https://internal.yourcompany.com/oauth2/callback`

20+

21+The GitHub auth provider supports two additional ways to restrict authentication to either organization and optional

22+team level access, or to collaborators of a repository. Restricting by these options is normally accompanied with `--email-domain=*`. Additionally, all the organizations and teams a user belongs to are set as part of the `X-Forwarded-Groups` header. e.g. `org1:team1,org1:team2,org2:team1`

23+

24+NOTE: When `--github-user` is set, the specified users are allowed to log in even if they do not belong to the specified

25+org and team or collaborators.

26+

27+To restrict access to your organization:

28+

29+```shell

30+ # restrict logins to members of this organisation

31+ --github-org="your-org"

32+```

33+

34+To restrict access to specific teams within an organization:

35+

36+```shell

37+ --github-org="your-org"

38+ # restrict logins to members of any of these teams (slug), comma separated

39+ --github-team="team1,team2,team3"

40+```

41+

42+To restrict to teams within different organizations, keep the organization flag empty and use `--github-team` like so:

43+

44+```shell

45+ # keep empty

46+ --github-org=""

47+ # restrict logins to members to any of the following teams (format <org>:<slug>, like octo:team1), comma separated

48+ --github-team="org1:team1,org2:team1,org3:team42,octo:cat"

49+```

50+

51+If you would rather restrict access to collaborators of a repository, those users must either have push access to a

52+public repository or any access to a private repository:

53+

54+```shell

55+ # restrict logins to collaborators of this repository formatted as orgname/repo

56+ --github-repo=""

57+```

58+

59+If you'd like to allow access to users with **read only** access to a **public** repository you will need to provide a

60+[token](https://github.com/settings/tokens) for a user that has write access to the repository. The token must be

61+created with at least the `public_repo` scope:

62+

63+```shell

64+ # the token to use when verifying repository collaborators

65+ --github-token=""

66+```

67+

68+To allow a user to log in with their username even if they do not belong to the specified org and team or collaborators:

69+

70+```shell

71+ # allow logins by username, comma separated

72+ --github-user=""

73+```

74+

75+If you are using GitHub enterprise, make sure you set the following to the appropriate url:

76+

77+```shell

78+ --login-url="http(s)://<enterprise github host>/login/oauth/authorize"

79+ --redeem-url="http(s)://<enterprise github host>/login/oauth/access_token"

80+ --validate-url="http(s)://<enterprise github host>/api/v3"

81+```

docs/versioned_docs/version-7.15.x/configuration/providers/gitlab.mdnew file+49

@@ -0,0 +1,49 @@

1+---

2+id: gitlab

3+title: GitLab

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

10+| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

12+

13+## Usage

14+

15+This auth provider has been tested against Gitlab version 12.X. Due to Gitlab API changes, it may not work for version

16+prior to 12.X (see [994](https://github.com/oauth2-proxy/oauth2-proxy/issues/994)).

17+

18+Whether you are using GitLab.com or self-hosting GitLab, follow

19+[these steps to add an application](https://docs.gitlab.com/integration/oauth_provider/). Make sure to enable at

20+least the `openid`, `profile` and `email` scopes, and set the redirect url to your application url e.g.

21+https://myapp.com/oauth2/callback.

22+

23+If you need projects filtering, add the extra `read_api` scope to your application.

24+

25+The following config should be set to ensure that the oauth will work properly. To get a cookie secret follow

26+[these steps](../overview.md#generating-a-cookie-secret)

27+

28+```

29+ --provider="gitlab"

30+ --redirect-url="https://myapp.com/oauth2/callback" // Should be the same as the redirect url for the application in gitlab

31+ --client-id=GITLAB_CLIENT_ID

32+ --client-secret=GITLAB_CLIENT_SECRET

33+ --cookie-secret=COOKIE_SECRET

34+```

35+

36+Restricting by group membership is possible with the following option:

37+

38+```shell

39+ --gitlab-group="mygroup,myothergroup" # restrict logins to members of any of these groups (slug), separated by a comma

40+```

41+

42+If you are using self-hosted GitLab, make sure you set the following to the appropriate URL:

43+

44+```shell

45+ --oidc-issuer-url="<your gitlab url>"

46+```

47+

48+If your self-hosted GitLab is on a subdirectory (e.g. domain.tld/gitlab), as opposed to its own subdomain

49+(e.g. gitlab.domain.tld), you may need to add a redirect from domain.tld/oauth pointing at e.g. domain.tld/gitlab/oauth.

docs/versioned_docs/version-7.15.x/configuration/providers/google.mdnew file+84

@@ -0,0 +1,84 @@

1+---

2+id: google

3+title: Google (default)

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+|-------------------------------------------------|----------------------------------------------| ------ |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------|

10+| `--google-admin-email` | `google_admin_email` | string | the google admin to impersonate for api calls | |

11+| `--google-group` | `google_groups` | string | restrict logins to members of this google group (may be given multiple times). If not specified and service account or default credentials are configured, all user groups will be allowed. | |

12+| `--google-service-account-json` | `google_service_account_json` | string | the path to the service account json credentials | |

13+| `--google-use-application-default-credentials` | `google_use_application_default_credentials` | bool | use application default credentials instead of service account json (i.e. GKE Workload Identity) | |

14+| `--google-target-principal` | `google_target_principal` | bool | the target principal to impersonate when using ADC | defaults to the service account configured for ADC |

15+| `--google-use-organization-id` | `google_use_organization_id` | bool | use organization id as preferred username | false |

16+| `--google-admin-api-user-scope` | `google_admin_api_user_scope` | string | the OAuth scope to use when querying the Google Admin SDK for organization id, can be 'readonly', 'user' or 'cloud'<br/> | `readonly` |

17+

18+## Usage

19+

20+For Google, the registration steps are:

21+

22+1. Create a new project: https://console.developers.google.com/project

23+2. Choose the new project from the top right project dropdown (only if another project is selected)

24+3. In the project Dashboard center pane, choose **"APIs & Services"**

25+4. In the left Nav pane, choose **"Credentials"**

26+5. In the center pane, choose **"OAuth consent screen"** tab. Fill in **"Product name shown to users"** and hit save.

27+6. In the center pane, choose **"Credentials"** tab.

28+ - Open the **"New credentials"** drop down

29+ - Choose **"OAuth client ID"**

30+ - Choose **"Web application"**

31+ - Application name is freeform, choose something appropriate

32+ - Authorized JavaScript origins is your domain ex: `https://internal.yourcompany.com`

33+ - Authorized redirect URIs is the location of oauth2/callback ex: `https://internal.yourcompany.com/oauth2/callback`

34+ - Choose **"Create"**

35+7. Take note of the **Client ID** and **Client Secret**

36+

37+It's recommended to refresh sessions on a short interval (1h) with `cookie-refresh` setting which validates that the

38+account is still authorized.

39+

40+#### Restrict auth to specific Google groups on your domain. (optional)

41+

42+1. Create a [service account](https://developers.google.com/identity/protocols/oauth2/service-account) and configure it

43+ to use [Application Default Credentials / Workload Identity / Workload Identity Federation (recommended)](#using-application-default-credentials-adc--workload-identity--workload-identity-federation-recommended) or,

44+ alternatively download the JSON.

45+2. Make note of the Client ID for a future step.

46+3. Under "APIs & Auth", choose APIs.

47+4. Click on Admin SDK and then Enable API.

48+5. Follow the steps on [Set up domain-wide delegation for a service account](https://developers.google.com/workspace/guides/create-credentials#optional_set_up_domain-wide_delegation_for_a_service_account)

49+ and give the client id from step 2 the following oauth scopes:

50+

51+ ```

52+ https://www.googleapis.com/auth/admin.directory.group.member.readonly

53+ ```

54+

55+6. Follow the steps on https://support.google.com/a/answer/60757 to enable Admin API access.

56+7. Create or choose an existing administrative email address on the Gmail domain to assign to the `google-admin-email`

57+ flag. This email will be impersonated by this client to make calls to the Admin SDK. See the note on the link from

58+ step 5 for the reason why.

59+8. Create or choose an existing email group and set that email to the `google-group` flag. You can pass multiple instances

60+ of this flag with different groups and the user will be checked against all the provided groups.

61+

62+(Only if using a JSON file (see step 1))

63+

64+9. Lock down the permissions on the json file downloaded from step 1 so only oauth2-proxy is able to read the file and

65+ set the path to the file in the `google-service-account-json` flag.

66+10. Restart oauth2-proxy.

67+

68+Note: The user is checked against the group members list on initial authentication and every time the token is

69+refreshed ( about once an hour ).

70+

71+##### Using Application Default Credentials (ADC) / Workload Identity / Workload Identity Federation (recommended)

72+oauth2-proxy can make use of [Application Default Credentials](https://cloud.google.com/docs/authentication/application-default-credentials).

73+When deployed within GCP, this means that it can automatically use the service account attached to the resource. When deployed to GKE, ADC

74+can be leveraged through a feature called Workload Identity. Follow Google's [guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)

75+to set up Workload Identity.

76+

77+When deployed outside of GCP, [Workload Identity Federation](https://cloud.google.com/docs/authentication/provide-credentials-adc#wlif) might be an option.

78+

79+##### Using Organization ID as Preferred Username (optional)

80+By default, the google provider uses the google id as username. If you would like to use an organization id instead, you can set the `google-use-organization-id` flag to true.

81+This requires that the service account used to query the Google Admin SDK has one of the following scopes granted in step 5 above:

82+- `https://www.googleapis.com/auth/admin.directory.user.readonly`,

83+- `https://www.googleapis.com/auth/admin.directory.user`

84+- `https://www.googleapis.com/auth/cloud-platform`

docs/versioned_docs/version-7.15.x/configuration/providers/index.mdnew file+46

@@ -0,0 +1,46 @@

1+---

2+id: index

3+title: OAuth Provider Configuration

4+---

5+

6+You will need to register an OAuth application with a Provider (Google, GitHub or another provider), and configure it

7+with Redirect URI(s) for the domain you intend to run `oauth2-proxy` on.

8+

9+Valid providers are :

10+

11+- [ADFS](adfs.md)

12+- [Bitbucket](bitbucket.md)

13+- [Cidaas](cidaas.md)

14+- [CiscoDuo](cisco_duo.md)

15+- [DigitalOcean](digitalocean.md)

16+- [Facebook](facebook.md)

17+- [Gitea](gitea.md)

18+- [GitHub](github.md)

19+- [GitLab](gitlab.md)

20+- [Google](google.md) _default_

21+- [Keycloak](keycloak.md) (Deprecated)

22+- [Keycloak OIDC](keycloak_oidc.md)

23+- [LinkedIn](linkedin.md)

24+- [login.gov](login_gov.md)

25+- [Microsoft Azure](ms_azure_ad.md) (Deprecated)

26+- [Microsoft Entra ID](ms_entra_id.md)

27+- [Nextcloud](nextcloud.md)

28+- [OpenID Connect](openid_connect.md)

29+- [SourceHut](sourcehut.md)

30+

31+The provider can be selected using the `provider` configuration value, or set in the [`providers` array using AlphaConfig](https://oauth2-proxy.github.io/oauth2-proxy/configuration/alpha-config#providers). However, [**the feature to implement multiple providers is not complete**](https://github.com/oauth2-proxy/oauth2-proxy/issues/926).

32+

33+Please note that not all providers support all claims. The `preferred_username` claim is currently only supported by the

34+OpenID Connect provider.

35+

36+## Email Authentication

37+

38+To authorize a specific email-domain use `--email-domain=yourcompany.com`. To authorize individual email addresses use

39+`--authenticated-emails-file=/path/to/file` with one email per line. To authorize all email addresses use `--email-domain=*`.

40+

41+## Adding a new Provider

42+

43+Follow the examples in the [`providers` package](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/) to define a new

44+`Provider` instance. Add a new `case` to

45+[`providers.New()`](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/providers/providers.go) to allow `oauth2-proxy` to use the

46+new `Provider`.

docs/versioned_docs/version-7.15.x/configuration/providers/keycloak.mdnew file+36

@@ -0,0 +1,36 @@

1+---

2+id: keycloak

3+title: Keycloak (Deprecated)

4+---

5+

6+:::note

7+This is the legacy and deprecated provider for Keycloak, use [Keycloak OIDC Auth Provider](keycloak_oidc.md) if possible.

8+:::

9+

10+1. Create new client in your Keycloak realm with **Access Type** 'confidential' and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'

11+2. Take note of the Secret in the credential tab of the client

12+3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.

13+

14+Make sure you set the following to the appropriate url:

15+

16+```

17+ --provider=keycloak

18+ --client-id=<client you have created>

19+ --client-secret=<your client's secret>

20+ --login-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/auth"

21+ --redeem-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/token"

22+ --profile-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"

23+ --validate-url="http(s)://<keycloak host>/auth/realms/<your realm>/protocol/openid-connect/userinfo"

24+ --keycloak-group=<first_allowed_user_group>

25+ --keycloak-group=<second_allowed_user_group>

26+```

27+

28+For group based authorization, the optional `--keycloak-group` (legacy) or `--allowed-group` (global standard)

29+flags can be used to specify which groups to limit access to.

30+

31+If these are unset but a `groups` mapper is set up above in step (3), the provider will still

32+populate the `X-Forwarded-Groups` header to your upstream server with the `groups` data in the

33+Keycloak userinfo endpoint response.

34+

35+The group management in keycloak is using a tree. If you create a group named admin in keycloak

36+you should define the 'keycloak-group' value to /admin.

docs/versioned_docs/version-7.15.x/configuration/providers/keycloak_oidc.mdnew file+151

@@ -0,0 +1,151 @@

1+---

2+id: keycloak_oidc

3+title: Keycloak OIDC

4+---

5+

6+## Config Options

7+

8+| Flag | Toml Field | Type | Description | Default |

9+| ---------------- | --------------- | -------------- | ------------------------------------------------------------------------------------------------------------------ | ------- |

10+| `--allowed-role` | `allowed_roles` | string \| list | restrict logins to users with this role (may be given multiple times). Only works with the keycloak-oidc provider. | |

11+

12+## Usage

13+

14+```

15+ --provider=keycloak-oidc

16+ --client-id=<your client's id>

17+ --client-secret=<your client's secret>

18+ --redirect-url=https://internal.yourcompany.com/oauth2/callback

19+ --oidc-issuer-url=https://<keycloak host>/realms/<your realm> // For Keycloak versions <17: --oidc-issuer-url=https://<keycloak host>/auth/realms/<your realm>

20+ --email-domain=<yourcompany.com> // Validate email domain for users, see option documentation

21+ --allowed-role=<realm role name> // Optional, required realm role

22+ --allowed-role=<client id>:<client role name> // Optional, required client role

23+ --allowed-group=</group name> // Optional, requires group client scope

24+ --code-challenge-method=S256 // PKCE

25+```

26+

27+:::note

28+Keycloak has updated its admin console and as of version 19.0.0, the new admin console is enabled by default. The

29+legacy admin console has been announced for removal with the release of version 21.0.0.

30+:::

31+

32+**Keycloak legacy admin console**

33+

34+1. Create new client in your Keycloak realm with **Access Type** 'confidential', **Client protocol** 'openid-connect'

35+ and **Valid Redirect URIs** 'https://internal.yourcompany.com/oauth2/callback'

36+2. Take note of the Secret in the credential tab of the client

37+3. Create a mapper with **Mapper Type** 'Group Membership' and **Token Claim Name** 'groups'.

38+4. Create a mapper with **Mapper Type** 'Audience' and **Included Client Audience** and **Included Custom Audience** set

39+ to your client name.

40+

41+**Keycloak new admin console (default as of v19.0.0)**

42+

43+The following example shows how to create a simple OIDC client using the new Keycloak admin2 console. However, for best

44+practices, it is recommended to consult the Keycloak documentation.

45+

46+The OIDC client must be configured with an _audience mapper_ to include the client's name in the `aud` claim of the JWT token.

47+The `aud` claim specifies the intended recipient of the token, and OAuth2 Proxy expects a match against the values of

48+either `--client-id` or `--oidc-extra-audience`.

49+

50+_In Keycloak, claims are added to JWT tokens through the use of mappers at either the realm level using "client scopes" or

51+through "dedicated" client mappers._

52+

53+**Creating the client**

54+

55+1. Create a new OIDC client in your Keycloak realm by navigating to:

56+ **Clients** -> **Create client**

57+ * **Client Type** 'OpenID Connect'

58+ * **Client ID** `<your client's id>`, please complete the remaining fields as appropriate and click **Next**.

59+ * **Client authentication** 'On'

60+ * **Authentication flow**

61+ * **Standard flow** 'selected'

62+ * **Direct access grants** 'deselect'

63+ * _Save the configuration._

64+ * **Settings / Access settings**:

65+ * **Valid redirect URIs** `https://internal.yourcompany.com/oauth2/callback`

66+ * _Save the configuration._

67+ * Under the **Credentials** tab you will now be able to locate `<your client's secret>`.

68+2. Configure a dedicated *audience mapper* for your client by navigating to **Clients** -> **\<your client's id\>** -> **Client scopes**.

69+* Access the dedicated mappers pane by clicking **\<your client's id\>-dedicated**, located under *Assigned client scope*.

70+ _(It should have a description of "Dedicated scope and mappers for this client")_

71+ * Click **Configure a new mapper** and select **Audience**

72+ * **Name** 'aud-mapper-\<your client's id\>'

73+ * **Included Client Audience** select `<your client's id>` from the dropdown.

74+ * _OAuth2 proxy can be set up to pass both the access and ID JWT tokens to your upstream services.

75+ If you require additional audience entries, you can use the **Included Custom Audience** field in addition

76+ to the "Included Client Audience" dropdown. Note that the "aud" claim of a JWT token should be limited and

77+ only specify its intended recipients._

78+ * **Add to ID token** 'On'

79+ * **Add to access token** 'On' - [#1916](https://github.com/oauth2-proxy/oauth2-proxy/pull/1916)

80+ * _Save the configuration._

81+* Any subsequent dedicated client mappers can be defined by clicking **Dedicated scopes** -> **Add mapper** ->

82+ **By configuration** -> *Select mapper*

83+

84+You should now be able to create a test user in Keycloak and get access to the OAuth2 Proxy instance, make sure to set

85+an email address matching `<yourcompany.com>` and select _Email verified_.

86+

87+**Authorization**

88+

89+_OAuth2 Proxy will perform authorization by requiring a valid user, this authorization can be extended to take into

90+account a user's membership in Keycloak `groups`, `realm roles`, and `client roles` using the keycloak-oidc provider options

91+`--allowed-role` or `--allowed-group`_

92+

93+**Roles**

94+

95+_A standard Keycloak installation comes with the required mappers for **realm roles** and **client roles** through the

96+pre-defined client scope "roles". This ensures that any roles assigned to a user are included in the `JWT` tokens when

97+using an OIDC client that has the "Full scope allowed" feature activated, the feature is enabled by default._

98+

99+_Creating a realm role_

100+* Navigate to **Realm roles** -> **Create role**

101+ * **Role name**, *`<realm role name>`* -> **save**

102+

103+_Creating a client role_

104+* Navigate to **Clients** -> `<your client's id>` -> **Roles** -> **Create role**

105+ * **Role name**, *`<client role name>`* -> **save**

106+

107+

108+_Assign a role to a user_

109+

110+**Users** -> _Username_ -> **Role mapping** -> **Assign role** -> _filter by roles or clients and select_ -> **Assign**.

111+

112+Keycloak "realm roles" can be authorized using the `--allowed-role=<realm role name>` option, while "client roles" can be

113+evaluated using `--allowed-role=<your client's id>:<client role name>`.

114+

115+You may limit the _realm roles_ included in the JWT tokens for any given client by navigating to:

116+**Clients** -> `<your client's id>` -> **Client scopes** -> _\<your client's id\>-dedicated_ -> **Scope**

117+Disabling **Full scope allowed** activates the **Assign role** option, allowing you to select which roles, if assigned

118+to a user, will be included in the user's JWT tokens. This can be useful when a user has many associated roles, and you

119+want to reduce the size and impact of the JWT token.

120+

121+

122+**Groups**

123+

124+You may also do authorization on group memberships by using the OAuth2 Proxy option `--allowed-group`.

125+We will only do a brief description of creating the required _client scope_ **groups** and refer you to read the Keycloak

126+documentation.

127+

128+To summarize, the steps required to authorize Keycloak group membership with OAuth2 Proxy are as follows:

129+

130+* Create a new Client Scope with the name **groups** in Keycloak.

131+ * Include a mapper of type **Group Membership**.

132+ * Set the "Token Claim Name" to **groups** or customize by matching it to the `--oidc-groups-claim` option of OAuth2 Proxy.

133+ * If the "Full group path" option is selected, you need to include a "/" separator in the group names defined in the

134+ `--allowed-group` option of OAuth2 Proxy. Example: "/groupname" or "/groupname/child_group".

135+

136+After creating the _Client Scope_ named _groups_ you will need to attach it to your client.

137+**Clients** -> `<your client's id>` -> **Client scopes** -> **Add client scope** -> Select **groups** and choose Optional

138+and you should now have a client that maps group memberships into the JWT tokens so that Oauth2 Proxy may evaluate them.

139+

140+Create a group by navigating to **Groups** -> **Create group** and _add_ your test user as a member.

141+

142+The OAuth2 Proxy option `--allowed-group=/groupname` will now allow you to filter on group membership

143+

144+Keycloak also has the option of attaching roles to groups, please refer to the Keycloak documentation for more information.

145+

146+**Tip**

147+

148+To check if roles or groups are added to JWT tokens, you can preview a users token in the Keycloak console by following

149+these steps: **Clients** -> `<your client's id>` -> **Client scopes** -> **Evaluate**.

150+Select a _realm user_ and optional _scope parameters_ such as groups, and generate the JSON representation of an access

151+or id token to examine its contents.

docs/versioned_docs/version-7.15.x/configuration/providers/linkedin.mdnew file+13

@@ -0,0 +1,13 @@

1+---

2+id: linkedin

3+title: LinkedIn

4+---

5+

6+For LinkedIn, the registration steps are:

7+

8+1. Create a new project: https://www.linkedin.com/secure/developer

9+2. In the OAuth User Agreement section:

10+ - In default scope, select r_basicprofile and r_emailaddress.

11+ - In "OAuth 2.0 Redirect URLs", enter `https://internal.yourcompany.com/oauth2/callback`

12+3. Fill in the remaining required fields and Save.

13+4. Take note of the **Consumer Key / API Key** and **Consumer Secret / Secret Key**

docs/versioned_docs/version-7.15.x/configuration/providers/login_gov.mdnew file+79

@@ -0,0 +1,79 @@

1+---

2+id: login_gov

3+title: Login.gov

4+---

5+

6+login.gov is an OIDC provider for the US Government.

7+If you are a US Government agency, you can contact the login.gov team through the contact information

8+that you can find on https://login.gov/developers/ and work with them to understand how to get login.gov

9+accounts for integration/test and production access.

10+

11+A developer guide is available here: https://developers.login.gov/, though this proxy handles everything

12+but the data you need to create to register your application in the login.gov dashboard.

13+

14+As a demo, we will assume that you are running your application that you want to secure locally on

15+http://localhost:3000/, that you will be starting your proxy up on http://localhost:4180/, and that

16+you have an agency integration account for testing.

17+

18+First, register your application in the dashboard. The important bits are:

19+* Identity protocol: make this `Openid connect`

20+* Issuer: do what they say for OpenID Connect. We will refer to this string as `${LOGINGOV_ISSUER}`.

21+* Public key: This is a self-signed certificate in .pem format generated from a 2048-bit RSA private key.

22+ A quick way to do this is

23+ `openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 3650 -nodes -subj '/C=US/ST=Washington/L=DC/O=GSA/OU=18F/CN=localhost'`.

24+ The contents of the `key.pem` shall be referred to as `${OAUTH2_PROXY_JWT_KEY}`.

25+* Return to App URL: Make this be `http://localhost:4180/`

26+* Redirect URIs: Make this be `http://localhost:4180/oauth2/callback`.

27+* Attribute Bundle: Make sure that email is selected.

28+

29+Now start the proxy up with the following options:

30+```

31+./oauth2-proxy -provider login.gov \

32+ -client-id=${LOGINGOV_ISSUER} \

33+ -redirect-url=http://localhost:4180/oauth2/callback \

34+ -oidc-issuer-url=https://idp.int.identitysandbox.gov/ \

35+ -cookie-secure=false \

36+ -email-domain=gsa.gov \

37+ -upstream=http://localhost:3000/ \

38+ -cookie-secret=somerandomstring12341234567890AB \

39+ -cookie-domain=localhost \

40+ -skip-provider-button=true \

41+ -pubjwk-url=https://idp.int.identitysandbox.gov/api/openid_connect/certs \

42+ -profile-url=https://idp.int.identitysandbox.gov/api/openid_connect/userinfo \

43+ -jwt-key="${OAUTH2_PROXY_JWT_KEY}"

44+```

45+You can also set all these options with environment variables, for use in cloud/docker environments.

46+One tricky thing that you may encounter is that some cloud environments will pass in environment

47+variables in a docker env-file, which does not allow multiline variables like a PEM file.

48+If you encounter this, then you can create a `jwt_signing_key.pem` file in the top level

49+directory of the repo which contains the key in PEM format and then do your docker build.

50+The docker build process will copy that file into your image which you can then access by

51+setting the `OAUTH2_PROXY_JWT_KEY_FILE=/etc/ssl/private/jwt_signing_key.pem`

52+environment variable, or by setting `--jwt-key-file=/etc/ssl/private/jwt_signing_key.pem` on the commandline.

53+

54+Once it is running, you should be able to go to `http://localhost:4180/` in your browser,

55+get authenticated by the login.gov integration server, and then get proxied on to your

56+application running on `http://localhost:3000/`. In a real deployment, you would secure

57+your application with a firewall or something so that it was only accessible from the

58+proxy, and you would use real hostnames everywhere.

59+

60+#### Skip OIDC discovery

61+

62+Some providers do not support OIDC discovery via their issuer URL, so oauth2-proxy cannot simply grab the authorization,

63+token and jwks URI endpoints from the provider's metadata.

64+

65+In this case, you can set the `--skip-oidc-discovery` option, and supply those required endpoints manually:

66+

67+```

68+ -provider oidc

69+ -client-id oauth2-proxy

70+ -client-secret proxy

71+ -redirect-url http://127.0.0.1:4180/oauth2/callback

72+ -oidc-issuer-url http://127.0.0.1:5556

73+ -skip-oidc-discovery

74+ -login-url http://127.0.0.1:5556/authorize

75+ -redeem-url http://127.0.0.1:5556/token

76+ -oidc-jwks-url http://127.0.0.1:5556/keys

77+ -cookie-secure=false

78+ -email-domain example.com

79+```

docs/versioned_docs/version-7.15.x/configuration/providers/ms_azure_ad.mdnew file+59

@@ -0,0 +1,59 @@

1+---

2+id: azure

3+title: Azure (Deprecated)

4+---

5+

6+:::note

7+This is the legacy and deprecated provider for Azure, use [Microsoft Entra ID](ms_entra_id.md) if possible.

8+:::

9+

10+## Config Options

11+

12+| Flag | Toml Field | Type | Description | Default |

13+| ---------------- | -------------- | ------ | ---------------------------------------------------------------- | ---------- |

14+| `--azure-tenant` | `azure_tenant` | string | go to a tenant-specific or common (tenant-independent) endpoint. | `"common"` |

15+| `--resource` | `resource` | string | The resource that is protected (Azure AD only) | |

16+

17+## Usage

18+

19+1. Add an application: go to [https://portal.azure.com](https://portal.azure.com), choose **Azure Active Directory**, select

20+ **App registrations** and then click on **New registration**.

21+2. Pick a name, check the supported account type(single-tenant, multi-tenant, etc). In the **Redirect URI** section create a new

22+ **Web** platform entry for each app that you want to protect by the oauth2 proxy(e.g.

23+ https://internal.yourcompanycom/oauth2/callback). Click **Register**.

24+3. Next we need to add group read permissions for the app registration, on the **API Permissions** page of the app, click on

25+ **Add a permission**, select **Microsoft Graph**, then select **Application permissions**, then click on **Group** and select

26+ **Group.Read.All**. Hit **Add permissions** and then on **Grant admin consent** (you might need an admin to do this).

27+ <br/>**IMPORTANT**: Even if this permission is listed with **"Admin consent required=No"** the consent might actually

28+ be required, due to AAD policies you won't be able to see. If you get a **"Need admin approval"** during login,

29+ most likely this is what you're missing!

30+4. Next, if you are planning to use v2.0 Azure Auth endpoint, go to the **Manifest** page and set `"accessTokenAcceptedVersion": 2`

31+ in the App registration manifest file.

32+5. On the **Certificates & secrets** page of the app, add a new client secret and note down the value after hitting **Add**.

33+6. Configure the proxy with:

34+- for V1 Azure Auth endpoint (Azure Active Directory Endpoints - https://login.microsoftonline.com/common/oauth2/authorize)

35+

36+```

37+ --provider=azure

38+ --client-id=<application ID from step 3>

39+ --client-secret=<value from step 5>

40+ --azure-tenant={tenant-id}

41+ --oidc-issuer-url=https://sts.windows.net/{tenant-id}/

42+```

43+

44+- for V2 Azure Auth endpoint (Microsoft Identity Platform Endpoints - https://login.microsoftonline.com/common/oauth2/v2.0/authorize)

45+```

46+ --provider=azure

47+ --client-id=<application ID from step 3>

48+ --client-secret=<value from step 5>

49+ --azure-tenant={tenant-id}

50+ --oidc-issuer-url=https://login.microsoftonline.com/{tenant-id}/v2.0

51+```

52+

53+***Notes***:

54+- When using v2.0 Azure Auth endpoint (`https://login.microsoftonline.com/{tenant-id}/v2.0`) as `--oidc_issuer_url`, in conjunction

55+ with `--resource` flag, be sure to append `/.default` at the end of the resource name. See

56+ https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope for more details.

57+- When using the Azure Auth provider with nginx and the cookie session store you may find the cookie is too large and doesn't

58+ get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the

59+ [redis session storage](../sessions.md#redis-storage) should resolve this.

docs/versioned_docs/version-7.15.x/configuration/providers/ms_entra_id.mdnew file+201

@@ -0,0 +1,201 @@

1+---

2+id: ms_entra_id

3+title: Microsoft Entra ID

4+---

5+

6+Provider for Microsoft Entra ID. Fully compliant with OIDC, with support for group overage and multi-tenant apps.

7+

8+## Config Options

9+

10+The provider is OIDC-compliant, so all the OIDC parameters are honored. Additional provider-specific configuration parameters are:

11+

12+| Flag | Toml Field | Type | Description | Default |

13+| --------------------------- | -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

14+| `--entra-id-allowed-tenant` | `entra_id_allowed_tenants` | string \| list | List of allowed tenants. In case of multi-tenant apps, incoming tokens are issued by different issuers and OIDC issuer verification needs to be disabled. When not specified, all tenants are allowed. Redundant for single-tenant apps (regular ID token validation matches the issuer). | |

15+| `--entra-id-federated-token-auth` | `entra_id_federated_token_auth` | boolean | Enable oAuth2 client authentication with federated token projected by Entra Workload Identity plugin, instead of client secret. | false |

16+

17+## Configure App registration

18+To begin, create an App registration, set a redirect URI, and generate a secret. All account types are supported, including single-tenant, multi-tenant, multi-tenant with Microsoft accounts, and Microsoft accounts only.

19+

20+<details>

21+ <summary>See Azure Portal example</summary>

22+ <div class="videoBlock">

23+ <iframe src="https://www.youtube.com/embed/IUNfxhOzr4E"></iframe>

24+ </div>

25+</details>

26+

27+<details>

28+ <summary>See Terraform example</summary>

29+```

30+ resource "azuread_application" "auth" {

31+ display_name = "oauth2-proxy"

32+ sign_in_audience = "AzureADMyOrg" # Others are also supported

33+

34+ web {

35+ redirect_uris = [

36+ "https://podinfo.lakis.tech/oauth2/callback",

37+ ]

38+ }

39+ // We don't specify any required API permissions - we allow user consent only

40+ }

41+

42+ resource "azuread_service_principal" "sp" {

43+ client_id = azuread_application.auth.client_id

44+ app_role_assignment_required = false

45+ }

46+

47+ resource "azuread_service_principal_password" "pass" {

48+ service_principal_id = azuread_service_principal.sp.id

49+ }

50+

51+```

52+</details>

53+

54+### Configure groups

55+If you want to make use of groups, you can configure *groups claim* to be present in ID Tokens issued by the App registration.

56+<details>

57+ <summary>See Azure Portal example</summary>

58+ <div class="videoBlock">

59+ <div class="videoBlock">

60+ <iframe src="https://www.youtube.com/embed/QZmP5MKEJis"></iframe>

61+ </div>

62+ </div>

63+</details>

64+<details>

65+ <summary>See Terraform example</summary>

66+```

67+ resource "azuread_application" "auth" {

68+ display_name = "oauth2-proxy"

69+ sign_in_audience = "AzureADMyOrg"

70+

71+ group_membership_claims = [

72+ "SecurityGroup"

73+ ]

74+

75+ web {

76+ redirect_uris = [

77+ "https://podinfo.lakis.tech/oauth2/callback",

78+ ]

79+ }

80+ }

81+

82+ resource "azuread_service_principal" "sp" {

83+ client_id = azuread_application.auth.client_id

84+ app_role_assignment_required = false

85+ }

86+

87+ resource "azuread_service_principal_password" "pass" {

88+ service_principal_id = azuread_service_principal.sp.id

89+ }

90+

91+```

92+</details>

93+

94+### Scopes and claims

95+For single-tenant and multi-tenant apps without groups, the only required scope is `openid` (See: [Scopes and permissions](https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc#the-openid-scope)).

96+

97+To make use of groups - for example use `allowed_groups` setting or authorize based on groups inside your service - you need to enable *groups claims* in the App Registration. When enabled, list of groups is present in the issued ID token. No additional scopes are required besides `openid`. This works up to 200 groups.

98+

99+When user has more than 200 group memberships, OAuth2-Proxy attempts to retrieve the complete list from Microsoft Graph API's [`transitiveMemberOf`](https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof). Endpoint requires `User.Read` scope (delegated permission). This permission can be by default consented by user during first login. Set scope to `openid User.Read` to request user consent. Without proper scope, user with 200+ groups will authenticate with 0 groups. See: [group overages](https://learn.microsoft.com/en-us/security/zero-trust/develop/configure-tokens-group-claims-app-roles#group-overages).

100+

101+Alternatively to user consent, both `openid` and `User.Read` permissions can be consented by admistrator. Then, user is not asked for consent on the first login, and group overage works with `openid` scope only. Admin consent can also be required for some tenants. It can be granted with [azuread_service_principal_delegated_permission_grant](https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/resources/service_principal_delegated_permission_grant) terraform resource.

102+

103+For personal microsoft accounts, required scope is `openid profile email`.

104+

105+See: [Overview of permissions and consent in the Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview).

106+

107+### Multi-tenant apps

108+To authenticate apps from multiple tenants (including personal Microsoft accounts), set the common OIDC issuer url and disable verification:

109+```toml

110+oidc_issuer_url=https://login.microsoftonline.com/common/v2.0

111+insecure_oidc_skip_issuer_verification=true

112+```

113+`insecure_oidc_skip_issuer_verification` setting is required to disable following checks:

114+* Startup check for matching issuer URL returned from [discovery document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) with `oidc_issuer_url` setting. Required, as document's `issuer` field doesn't equal to `https://login.microsoftonline.com/common/v2.0`. See [OIDC Discovery 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation).

115+* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by different tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

116+

117+To provide additional security, Entra ID provider performs check on the ID token's `issuer` claim to match the `https://login.microsoftonline.com/{tenant-id}/v2.0` template.

118+

119+### Workload Identity

120+Provider supports authentication with federated token, without need of using client secret. Following conditions have to be met:

121+

122+* Cluster has public OIDC provider URL. For major cloud providers, it can be enabled with a single flag, for example for [Azure Kubernetes Service deployed with Terraform](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/kubernetes_cluster), it's `oidc_issuer_enabled`.

123+* Workload Identity admission webhook is deployed on the cluster. For AKS, it can be enabled with a flag (`workload_identity_enabled` in Terraform resource), for clusters outside of Azure, it can be installed from [helm chart](https://github.com/Azure/azure-workload-identity).

124+* Appropriate federated credential is added to application registration.

125+<details>

126+ <summary>See federated credential terraform example</summary>

127+```

128+ resource "azuread_application_federated_identity_credential" "fedcred" {

129+ application_id = azuread_application.application.id # ID of your application

130+ display_name = "federation-cred"

131+ description = "Workload identity for oauth2-proxy"

132+ audiences = ["api://AzureADTokenExchange"] # Fixed value

133+ issuer = "https://cluster-oidc-issuer-url..."

134+ subject = "system:serviceaccount:oauth2-proxy-namespace-name:oauth2-proxy-sa-name" # set proper NS and SA name

135+ }

136+```

137+</details>

138+

139+* Kubernetes service account associated with oauth2-proxy deployment, is annotated with `azure.workload.identity/client-id: <app-registration-client-id>`

140+* oauth2-proxy pod is labeled with `azure.workload.identity/use: "true"`

141+* oauth2-proxy is configured with `entra_id_federated_token_auth` set to `true`.

142+

143+`client_secret` setting can be omitted when using federated token authentication.

144+

145+See: [Azure Workload Identity documentation](https://azure.github.io/azure-workload-identity/docs/).

146+

147+### Example configurations

148+Single-tenant app without groups (*groups claim* not enabled). Consider using generic OIDC provider:

149+```toml

150+provider="entra-id"

151+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

152+client_id="<client-id>"

153+client_secret="<client-secret>"

154+scope="openid"

155+```

156+

157+Single-tenant app with up to 200 groups (*groups claim* enabled). Consider using generic OIDC provider:

158+```toml

159+provider="entra-id"

160+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

161+client_id="<client-id>"

162+client_secret="<client-secret>"

163+scope="openid"

164+allowed_groups=["ac51800c-2679-4ecb-8130-636380a3b491"]

165+```

166+

167+Single-tenant app with more than 200 groups:

168+```toml

169+provider="entra-id"

170+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

171+client_id="<client-id>"

172+client_secret="<client-secret>"

173+scope="openid User.Read"

174+allowed_groups=["968b4844-d5e7-4e18-a834-59927959369f"]

175+```

176+

177+Single-tenant app with more than 200 groups and workload identity enabled:

178+```toml

179+provider="entra-id"

180+oidc_issuer_url="https://login.microsoftonline.com/<tenant-id>/v2.0"

181+client_id="<client-id>"

182+scope="openid User.Read"

183+allowed_groups=["968b4844-d5e7-4e18-a834-59927959369f"]

184+entra_id_federated_token_auth=true

185+```

186+

187+Multi-tenant app with Microsoft personal accounts & one Entra tenant allowed, with group overage considered:

188+```toml

189+provider="entra-id"

190+oidc_issuer_url="https://login.microsoftonline.com/common/v2.0"

191+client_id="<client-id>"

192+client_secret="<client-secret>"

193+insecure_oidc_skip_issuer_verification=true

194+scope="openid profile email User.Read"

195+entra_id_allowed_tenants=["9188040d-6c67-4c5b-b112-36a304b66dad","<my-tenant-id>"] # Allow only <my-tenant-id> and Personal MS Accounts tenant

196+email_domains="*"

197+```

198+

199+## Kubernetes Dashboard Integration

200+

201+For a complete guide on integrating oauth2-proxy with Kubernetes Dashboard on AKS using Azure Entra ID authentication, including detailed configuration examples, RBAC setup, troubleshooting, and Workload Identity setup, see the [Kubernetes Dashboard integration guide](../integrations/kubernetes-dashboard.md).

docs/versioned_docs/version-7.15.x/configuration/providers/nextcloud.mdnew file+28

@@ -0,0 +1,28 @@

1+---

2+id: nextcloud

3+title: NextCloud

4+---

5+

6+The Nextcloud provider allows you to authenticate against users in your

7+Nextcloud instance.

8+

9+When you are using the Nextcloud provider, you must specify the urls via

10+configuration, environment variable, or command line argument. Depending

11+on whether your Nextcloud instance is using pretty urls your urls may be of the

12+form `/index.php/apps/oauth2/*` or `/apps/oauth2/*`.

13+

14+Refer to the [OAuth2

15+documentation](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/oauth2.html)

16+to set up the client id and client secret. Your "Redirection URI" will be

17+`https://internalapp.yourcompany.com/oauth2/callback`.

18+

19+```

20+ -provider nextcloud

21+ -client-id <from nextcloud admin>

22+ -client-secret <from nextcloud admin>

23+ -login-url="<your nextcloud url>/index.php/apps/oauth2/authorize"

24+ -redeem-url="<your nextcloud url>/index.php/apps/oauth2/api/v1/token"

25+ -validate-url="<your nextcloud url>/ocs/v2.php/cloud/user?format=json"

26+```

27+

28+Note: in *all* cases the validate-url will *not* have the `index.php`.

docs/versioned_docs/version-7.15.x/configuration/providers/openid_connect.mdnew file+146

@@ -0,0 +1,146 @@

1+---

2+id: openid_connect

3+title: OpenID Connect

4+---

5+

6+OpenID Connect is a spec for OAUTH 2.0 + identity that is implemented by many major providers and several open source projects.

7+

8+This provider was originally built against CoreOS Dex, and we will use it as an example.

9+The OpenID Connect Provider (OIDC) can also be used to connect to other Identity Providers such as Okta, an example can be found below.

10+

11+#### Dex

12+

13+To configure the OIDC provider for Dex, perform the following steps:

14+

15+1. Download Dex:

16+

17+ ```

18+ go get github.com/dexidp/dex

19+ ```

20+

21+ See the [getting started guide](https://dexidp.io/docs/getting-started/) for more details.

22+

23+2. Setup oauth2-proxy with the correct provider and using the default ports and callbacks. Add a configuration block to

24+ the `staticClients` section of `examples/config-dev.yaml`:

25+

26+ ```

27+ - id: oauth2-proxy

28+ redirectURIs:

29+ - 'http://127.0.0.1:4180/oauth2/callback'

30+ name: 'oauth2-proxy'

31+ secret: proxy

32+ ```

33+

34+3. Launch Dex: from `$GOPATH/github.com/dexidp/dex`, run:

35+

36+ ```

37+ bin/dex serve examples/config-dev.yaml

38+ ```

39+

40+4. In a second terminal, run the oauth2-proxy with the following args:

41+

42+ ```shell

43+ --provider oidc

44+ --provider-display-name "My OIDC Provider"

45+ --client-id oauth2-proxy

46+ --client-secret proxy

47+ --redirect-url http://127.0.0.1:4180/oauth2/callback

48+ --oidc-issuer-url http://127.0.0.1:5556/dex

49+ --cookie-secure=false

50+ --cookie-secret=secret

51+ --email-domain kilgore.trout

52+ ```

53+

54+ To serve the current working directory as a website under the `/static` endpoint, add:

55+

56+ ```shell

57+ --upstream file://$PWD/#/static/

58+ ```

59+

60+5. Test the setup by visiting http://127.0.0.1:4180 or http://127.0.0.1:4180/static .

61+

62+See also [our local testing environment](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/local-environment) for a self-contained example using Docker and etcd as storage for Dex.

63+

64+#### Okta

65+

66+To configure the OIDC provider for Okta, perform the following steps:

67+

68+1. Log in to Okta using an administrative account. It is suggested you try this in preview first, `example.oktapreview.com`

69+2. (OPTIONAL) If you want to configure authorization scopes and claims to be passed on to multiple applications,

70+ you may wish to configure an authorization server for each application. Otherwise, the provided `default` will work.

71+ * Navigate to **Security** then select **API**

72+ * Click **Add Authorization Server**, if this option is not available you may require an additional license for a custom

73+ authorization server.

74+ * Fill out the **Name** with something to describe the application you are protecting. e.g. 'Example App'.

75+ * For **Audience**, pick the URL of the application you wish to protect: https://example.corp.com

76+ * Fill out a **Description**

77+ * Add any **Access Policies** you wish to configure to limit application access.

78+ * The default settings will work for other options.

79+ [See Okta documentation for more information on Authorization Servers](https://developer.okta.com/docs/guides/customize-authz-server/overview/)

80+3. Navigate to **Applications** then select **Add Application**.

81+ * Select **Web** for the **Platform** setting.

82+ * Select **OpenID Connect** and click **Create**

83+ * Pick an **Application Name** such as `Example App`.

84+ * Set the **Login redirect URI** to `https://example.corp.com`.

85+ * Under **General** set the **Allowed grant types** to `Authorization Code` and `Refresh Token`.

86+ * Leave the rest as default, taking note of the `Client ID` and `Client Secret`.

87+ * Under **Assignments** select the users or groups you wish to access your application.

88+4. Create a configuration file like the following:

89+

90+ ```

91+ provider = "oidc"

92+ redirect_url = "https://example.corp.com/oauth2/callback"

93+ oidc_issuer_url = "https://corp.okta.com/oauth2/abCd1234"

94+ upstreams = [

95+ "https://example.corp.com"

96+ ]

97+ email_domains = [

98+ "corp.com"

99+ ]

100+ client_id = "XXXXX"

101+ client_secret = "YYYYY"

102+ pass_access_token = true

103+ cookie_secret = "ZZZZZ"

104+ skip_provider_button = true

105+ ```

106+

107+The `oidc_issuer_url` is based on URL from your **Authorization Server**'s **Issuer** field in step 2, or simply

108+https://corp.okta.com. The `client_id` and `client_secret` are configured in the application settings.

109+Generate a unique `cookie_secret` to encrypt the cookie.

110+

111+Then you can start the oauth2-proxy with `./oauth2-proxy --config /etc/example.cfg`

112+

113+#### Okta - localhost

114+

115+1. Signup for developer account: https://developer.okta.com/signup/

116+2. Create New `Web` Application: https://$\{your-okta-domain\}/dev/console/apps/new

117+3. Example Application Settings for localhost:

118+ * **Name:** My Web App

119+ * **Base URIs:** http://localhost:4180/

120+ * **Login redirect URIs:** http://localhost:4180/oauth2/callback

121+ * **Logout redirect URIs:** http://localhost:4180/

122+ * **Group assignments:** `Everyone`

123+ * **Grant type allowed:** `Authorization Code` and `Refresh Token`

124+4. Make note of the `Client ID` and `Client secret`, they are needed in a future step

125+5. Make note of the **default** Authorization Server Issuer URI from: https://$\{your-okta-domain\}/admin/oauth2/as

126+6. Example config file `/etc/localhost.cfg`

127+ ```shell

128+ provider = "oidc"

129+ redirect_url = "http://localhost:4180/oauth2/callback"

130+ oidc_issuer_url = "https://$\{your-okta-domain\}/oauth2/default"

131+ upstreams = [

132+ "http://0.0.0.0:8080"

133+ ]

134+ email_domains = [

135+ "*"

136+ ]

137+ client_id = "XXX"

138+ client_secret = "YYY"

139+ pass_access_token = true

140+ cookie_secret = "ZZZ"

141+ cookie_secure = false

142+ skip_provider_button = true

143+ # Note: use the following for testing within a container

144+ # http_address = "0.0.0.0:4180"

145+ ```

146+7. Then you can start the oauth2-proxy with `./oauth2-proxy --config /etc/localhost.cfg`

docs/versioned_docs/version-7.15.x/configuration/providers/sourcehut.mdnew file+25

@@ -0,0 +1,25 @@

1+---

2+id: sourcehut

3+title: SourceHut

4+---

5+

6+1. Create a new OAuth client: https://meta.sr.ht/oauth2

7+2. Under `Redirection URI` enter the correct URL, i.e.

8+ `https://internal.yourcompany.com/oauth2/callback`

9+

10+To use the provider, start with `--provider=sourcehut`.

11+

12+If you are hosting your own SourceHut instance, make sure you set the following

13+to the appropriate URLs:

14+

15+```shell

16+ --login-url="https://<meta.your.instance>/oauth2/authorize"

17+ --redeem-url="https://<meta.your.instance>/oauth2/access-token"

18+ --profile-url="https://<meta.your.instance>/query"

19+ --validate-url="https://<meta.your.instance>/profile"

20+```

21+

22+The default configuration allows everyone with an account to authenticate.

23+Restricting access is currently only supported by

24+[email](index.md#email-authentication).

25+

docs/versioned_docs/version-7.15.x/configuration/sessions.mdnew file+99

@@ -0,0 +1,99 @@

1+---

2+id: session_storage

3+title: Session Storage

4+---

5+

6+Sessions allow a user's authentication to be tracked between multiple HTTP

7+requests to a service.

8+

9+The OAuth2 Proxy uses a Cookie to track user sessions and will store the session

10+data in one of the available session storage backends.

11+

12+At present the available backends are (as passed to `--session-store-type`):

13+- [cookie](#cookie-storage) (default)

14+- [redis](#redis-storage)

15+

16+### Cookie Storage

17+

18+The Cookie storage backend is the default backend implementation and has

19+been used in the OAuth2 Proxy historically.

20+

21+With the Cookie storage backend, all session information is stored in client

22+side cookies and transferred with each and every request.

23+

24+The following should be known when using this implementation:

25+- Since all state is stored client side, this storage backend means that the OAuth2 Proxy is completely stateless

26+- Cookies are signed server side to prevent modification client-side

27+- It is mandatory to set a `cookie-secret` which will ensure data is encrypted within the cookie data.

28+- Since multiple requests can be made concurrently to the OAuth2 Proxy, this session implementation

29+cannot lock sessions and while updating and refreshing sessions, there can be conflicts which force

30+users to re-authenticate

31+

32+

33+### Redis Storage

34+

35+The Redis Storage backend stores encrypted sessions in redis. Instead of sending all the information

36+back the client for storage, as in the [Cookie storage](#cookie-storage), a ticket is sent back

37+to the user as the cookie value instead.

38+

39+A ticket is composed as the following:

40+

41+`{CookieName}-{ticketID}.{secret}`

42+

43+Where:

44+

45+- The `CookieName` is the OAuth2 cookie name (_oauth2_proxy by default)

46+- The `ticketID` is a 128-bit random number, hex-encoded

47+- The `secret` is a 128-bit random number, base64url encoded (no padding). The secret is unique for every session.

48+- The pair of `{CookieName}-{ticketID}` comprises a ticket handle, and thus, the redis key

49+to which the session is stored. The encoded session is encrypted with the secret and stored

50+in redis via the `SETEX` command.

51+

52+Encrypting every session uniquely protects the refresh/access/id tokens stored in the session from

53+disclosure. Additionally, the browser only has to send a short Cookie with every request and not the whole JWT,

54+which can get quite big.

55+

56+Two settings are used to configure the OAuth2 Proxy cookie lifetime:

57+

58+ --cookie-refresh duration refresh the cookie after this duration; 0 to disable

59+ --cookie-expire duration expire timeframe for cookie 168h0m0s

60+

61+The "cookie-expire" value should be equal to the lifetime of the Refresh-Token that is issued by the OAuth2 authorization server.

62+If it expires earlier and is deleted by the browser, OAuth2 Proxy cannot find the stored Refresh-Tokens in Redis and thus cannot start

63+the refresh flow to get a new Access-Token. If it is longer, it might be that the old Refresh-Token will be found in Redis but has already

64+expired.

65+

66+The "cookie-refresh" value controls when OAuth2 Proxy tries to refresh an Access-Token. If it is set to "0", the

67+Access-Token will never be refreshed, even if it is already expired and a valid Refresh-Token is available. If set, OAuth2 Proxy will

68+refresh the Access-Token after this many seconds whether it is still valid or not. According to the official OAuth2.0 specification

69+Access-Tokens are not required to follow a specific format. Therefore OAuth2 Proxy cannot check for any expiry date without an

70+introspection endpoint. If an Access-Token expires and you have not set a corresponding "cookie-refresh" value, you will likely

71+encounter expiry issues.

72+

73+Caveat: It can happen that the Access-Token is valid for e.g. "1m" and a request happens after exactly "59s".

74+It would pass OAuth2 Proxy and be forwarded to the backend but is just expired when the backend tries to validate

75+it. This is especially relevant if the backend uses the JWT to make requests to other backends.

76+For this reason, it's advised to set the cookie-refresh a couple of seconds less than the Access-Token lifespan.

77+

78+Recommended settings:

79+

80+* cookie_refresh := Access-Token lifespan - 1m

81+* cookie_expire := Refresh-Token lifespan (i.e. Keycloak client_session_idle)

82+

83+#### Usage

84+

85+When using the redis store, specify `--session-store-type=redis` as well as the Redis connection URL, via

86+`--redis-connection-url=redis://host[:port][/db-number]`.

87+

88+You may also configure the store for Redis Sentinel. In this case, you will want to use the

89+`--redis-use-sentinel=true` flag, as well as configure the flags `--redis-sentinel-master-name`

90+and `--redis-sentinel-connection-urls` appropriately.

91+

92+Redis Cluster is available to be the backend store as well. To leverage it, you will need to set the

93+`--redis-use-cluster=true` flag, and configure the flags `--redis-cluster-connection-urls` appropriately.

94+

95+Note that flags `--redis-use-sentinel=true` and `--redis-use-cluster=true` are mutually exclusive.

96+

97+Note, if Redis timeout option is set to non-zero, the `--redis-connection-idle-timeout`

98+must be less than [Redis timeout option](https://redis.io/docs/reference/clients/#client-timeouts). For example: if either redis.conf includes

99+`timeout 15` or using `CONFIG SET timeout 15` the `--redis-connection-idle-timeout` must be at least `--redis-connection-idle-timeout=14`

docs/versioned_docs/version-7.15.x/configuration/systemd_socket.mdnew file+51

@@ -0,0 +1,51 @@

1+---

2+id: systemd_socket

3+title: Systemd Socket Activation

4+---

5+

6+Pass an existing listener created by systemd.socket to oauth2-proxy.

7+

8+To do this create a socket:

9+

10+oauth2-proxy.socket

11+```

12+[Socket]

13+ListenStream=%t/oauth2.sock

14+SocketGroup=www-data

15+SocketMode=0660

16+```

17+

18+Now it's possible to call this socket from e.g. nginx:

19+```

20+server {

21+ location /oauth2/ {

22+ proxy_pass http://unix:/run/oauth2-proxy/oauth2.sock;

23+}

24+```

25+

26+The oauth2-proxy should have `--http-address=fd:3` as a parameter.

27+Here fd is case insensitive and means file descriptor. The number 3 refers to the first non-stdin/stdout/stderr file descriptor,

28+systemd-socket-activate (which is what systemd.socket uses), listens to what it is told and passes

29+the listener it created onto the process, starting with file descriptor 3.

30+

31+```

32+./oauth2-proxy \

33+ --http-address="fd:3" \

34+ --email-domain="yourcompany.com" \

35+ --upstream=http://127.0.0.1:8080/ \

36+ --cookie-secret=... \

37+ --cookie-secure=true \

38+ --provider=... \

39+ --client-id=... \

40+ --client-secret=...

41+```

42+

43+## Trusted IPs

44+

45+When listening on a Unix socket, Go sets `http.Request.RemoteAddr` to `"@"` instead of the usual `"host:port"` format. This means there is no client IP available from the connection itself.

46+

47+As a result, `--trusted-ip` entries cannot match against the direct connection address for Unix socket listeners. Requests arriving over a Unix socket will never be considered "trusted" based on their `RemoteAddr`. IP-based trust decisions will still work if a trusted reverse proxy sets `X-Forwarded-For` or `X-Real-IP` headers and `--reverse-proxy=true` is configured.

48+

49+## TLS

50+

51+Currently TLS is not supported (but it's doable).

docs/versioned_docs/version-7.15.x/configuration/tls.mdnew file+85

@@ -0,0 +1,85 @@

1+---

2+id: tls

3+title: TLS Configuration

4+---

5+

6+There are two recommended configurations:

7+- [At OAuth2 Proxy](#terminate-tls-at-oauth2-proxy)

8+- [At Reverse Proxy](#terminate-tls-at-reverse-proxy-eg-nginx)

9+

10+### Terminate TLS at OAuth2 Proxy

11+

12+1. Configure SSL Termination with OAuth2 Proxy by providing a `--tls-cert-file=/path/to/cert.pem` and `--tls-key-file=/path/to/cert.key`.

13+

14+ The command line to run `oauth2-proxy` in this configuration would look like this:

15+

16+ ```bash

17+ ./oauth2-proxy \

18+ --email-domain="yourcompany.com" \

19+ --upstream=http://127.0.0.1:8080/ \

20+ --tls-cert-file=/path/to/cert.pem \

21+ --tls-key-file=/path/to/cert.key \

22+ --cookie-secret=... \

23+ --cookie-secure=true \

24+ --provider=... \

25+ --client-id=... \

26+ --client-secret=...

27+ ```

28+

29+2. With this configuration approach the customization of the TLS settings is limited.

30+

31+ The minimal acceptable TLS version can be set with `--tls-min-version=TLS1.3`.

32+ The defaults set `TLS1.2` as the minimal version.

33+ Regardless of the minimum version configured, `TLS1.3` is currently always used as the maximal version.

34+

35+ TLS server side cipher suites can be specified with `--tls-cipher-suite=TLS_RSA_WITH_RC4_128_SHA`.

36+ If not specified, the defaults from [`crypto/tls`](https://pkg.go.dev/crypto/tls#CipherSuites) of the currently used `go` version for building `oauth2-proxy` will be used.

37+ A complete list of valid TLS cipher suite names can be found in [`crypto/tls`](https://pkg.go.dev/crypto/tls#pkg-constants).

38+

39+### Terminate TLS at Reverse Proxy, e.g. Nginx

40+

41+1. Configure SSL Termination with [Nginx](http://nginx.org/) (example config below), Amazon ELB, Google Cloud Platform Load Balancing, or ...

42+

43+ Because `oauth2-proxy` listens on `127.0.0.1:4180` by default, to listen on all interfaces (needed when using an

44+ external load balancer like Amazon ELB or Google Platform Load Balancing) use `--http-address="0.0.0.0:4180"` or

45+ `--http-address="http://:4180"`.

46+

47+ Nginx will listen on port `443` and handle SSL connections while proxying to `oauth2-proxy` on port `4180`.

48+ `oauth2-proxy` will then authenticate requests for an upstream application. The external endpoint for this example

49+ would be `https://internal.yourcompany.com/`.

50+

51+ An example Nginx config follows. Note the use of `Strict-Transport-Security` header to pin requests to SSL

52+ via [HSTS](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security):

53+

54+ ```

55+ server {

56+ listen 443 default ssl;

57+ server_name internal.yourcompany.com;

58+ ssl_certificate /path/to/cert.pem;

59+ ssl_certificate_key /path/to/cert.key;

60+ add_header Strict-Transport-Security max-age=2592000;

61+

62+ location / {

63+ proxy_pass http://127.0.0.1:4180;

64+ proxy_set_header Host $host;

65+ proxy_set_header X-Real-IP $remote_addr;

66+ proxy_connect_timeout 1;

67+ proxy_send_timeout 30;

68+ proxy_read_timeout 30;

69+ }

70+ }

71+ ```

72+

73+2. The command line to run `oauth2-proxy` in this configuration would look like this:

74+

75+ ```bash

76+ ./oauth2-proxy \

77+ --email-domain="yourcompany.com" \

78+ --upstream=http://127.0.0.1:8080/ \

79+ --cookie-secret=... \

80+ --cookie-secure=true \

81+ --provider=... \

82+ --reverse-proxy=true \

83+ --client-id=... \

84+ --client-secret=...

85+ ```

docs/versioned_docs/version-7.15.x/features/endpoints.mdnew file+73

@@ -0,0 +1,73 @@

1+---

2+id: endpoints

3+title: Endpoints

4+---

5+

6+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.

7+

8+- / - the proxy endpoint provides authentication and returns the appropriate 40x error if not authenticated or authorized then passes the request upstream.

9+- /robots.txt - returns a 200 OK response that disallows all User-agents from all paths; see [robotstxt.org](http://www.robotstxt.org/) for more info

10+- /ping - returns a 200 OK response, which is intended for use with health checks

11+- /ready - returns a 200 OK response if all the underlying connections (e.g., Redis store) are connected

12+- /metrics - Metrics endpoint for Prometheus to scrape, serve on the address specified by `--metrics-address`, disabled by default

13+- /oauth2/sign_in - the login page, which also doubles as a sign-out page (it clears cookies)

14+- /oauth2/sign_out - this URL is used to clear the session cookie

15+- /oauth2/start - a URL that will redirect to start the OAuth cycle

16+- /oauth2/callback - the URL used at the end of the OAuth cycle. The oauth app will be configured with this as the callback url.

17+- /oauth2/userinfo - the URL is used to return user's email from the session in JSON format.

18+- /oauth2/auth - only returns a 202 Accepted response or a 401 Unauthorized response; for use with the [Nginx `auth_request` directive](../configuration/integrations/nginx)

19+- /oauth2/static/\* - stylesheets and other dependencies used in the sign_in and error pages

20+

21+### Sign out

22+

23+To sign the user out, redirect them to `/oauth2/sign_out`. This endpoint only removes oauth2-proxy's own cookies, i.e. the user is still logged in with the authentication provider and may automatically re-login when accessing the application again. You will also need to redirect the user to the authentication provider's sign-out page afterward using the `rd` query parameter, i.e. redirect the user to something like (notice the url-encoding!):

24+

25+```

26+/oauth2/sign_out?rd=https%3A%2F%2Fmy-oidc-provider.example.com%2Fsign_out_page

27+```

28+

29+Alternatively, include the redirect URL in the `X-Auth-Request-Redirect` header:

30+

31+```

32+GET /oauth2/sign_out HTTP/1.1

33+X-Auth-Request-Redirect: https://my-oidc-provider/sign_out_page

34+...

35+```

36+

37+(The "sign_out_page" should be the [`end_session_endpoint`](https://openid.net/specs/openid-connect-session-1_0.html#rfc.section.2.1) from [the metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) if your OIDC provider supports Session Management and Discovery.)

38+

39+BEWARE that the domain you want to redirect to (`my-oidc-provider.example.com` in the example) must be added to the [`--whitelist-domain`](../configuration/overview) configuration option otherwise the redirect will be ignored. Make sure to include the actual domain and port (if needed) and not the URL (e.g "localhost:8081" instead of "http://localhost:8081").

40+

41+ID Token can be injected in the redirect url by using `{id_token}` placeholder. For example to redirect to `https://my-oidc-provider.example.com/sign_out_page?id_token_hint={id_token}&post_logout_redirect_uri=https://my-app.example.com`;

42+

43+```

44+/oauth2/sign_out?rd=https%3A%2F%2Fmy-oidc-provider.example.com%2Fsign_out_page%3Fid_token_hint%3D%7Bid_token%7D%26post_logout_redirect_uri%3Dhttps%3A%2F%2Fmy-app.example.com

45+```

46+

47+or alternatively in the header:

48+

49+```

50+GET /oauth2/sign_out HTTP/1.1

51+X-Auth-Request-Redirect: https://my-oidc-provider.example.com/sign_out_page?id_token_hint={id_token}&post_logout_redirect_uri=https://my-app.example.com

52+...

53+```

54+

55+### Auth

56+

57+This endpoint returns 202 Accepted response or a 401 Unauthorized response.

58+

59+It can be configured using the following query parameters:

60+- `allowed_groups`: comma separated list of allowed groups

61+- `allowed_email_domains`: comma separated list of allowed email domains

62+- `allowed_emails`: comma separated list of allowed emails

63+

64+### Proxy (/)

65+

66+This endpoint returns the upstream response if authenticated.

67+If unauthenticated it returns a 401 Unauthorized. If the authenticatd user

68+is not in one of the allowed groups, or emails then it returns a 403 forbidden

69+

70+It can be configured using the following query parameters:

71+- `allowed_groups`: comma separated list of allowed groups

72+- `allowed_email_domains`: comma separated list of allowed email domains

73+- `allowed_emails`: comma separated list of allowed emails

docs/versioned_docs/version-7.15.x/installation.mdnew file+32

@@ -0,0 +1,32 @@

1+---

2+id: installation

3+title: Installation

4+---

5+

6+1. Choose how to deploy:

7+

8+ a. Using a [Prebuilt Binary](https://github.com/oauth2-proxy/oauth2-proxy/releases) (current release is `v7.15.4`)

9+

10+ b. Using Go to install the latest release

11+ ```bash

12+ $ go install github.com/oauth2-proxy/oauth2-proxy/v7@latest

13+ ```

14+ This will install the binary into `$GOPATH/bin`. Make sure you include `$GOPATH` in your `$PATH`. Otherwise your system won't find binaries installed via `go install`

15+

16+ c. Using a [Prebuilt Docker Image](https://quay.io/oauth2-proxy/oauth2-proxy) (AMD64, PPC64LE, S390x, ARMv6, ARMv7, and ARM64 available)

17+

18+ d. Using a [Pre-Release Nightly Docker Image](https://quay.io/oauth2-proxy/oauth2-proxy-nightly) (AMD64, PPC64LE, ARMv6, ARMv7, and ARM64 available)

19+

20+ e. Using the official [Kubernetes manifest](https://github.com/oauth2-proxy/manifests) (Helm)

21+

22+ Prebuilt binaries can be validated by extracting the file and verifying it against the `sha256sum.txt` checksum file provided for each release starting with version `v3.0.0`.

23+

24+ ```

25+ $ sha256sum -c sha256sum.txt

26+ oauth2-proxy-x.y.z.linux-amd64: OK

27+ ```

28+

29+2. [Select a Provider and Register an OAuth Application with a Provider](configuration/providers/index.md)

30+3. [Configure OAuth2 Proxy using config file, command line options, or environment variables](configuration/overview.md)

31+4. [Configure SSL or Deploy behind an SSL endpoint](configuration/tls.md) (example provided for Nginx)

32+5. [Configure OAuth2 Proxy using systemd.socket](configuration/systemd_socket.md) (example provided for Nginx/Systemd)

docs/versioned_docs/version-7.15.x/welcome.mdnew file+33

@@ -0,0 +1,33 @@

1+---

2+id: welcome

3+title: Welcome

4+hide_table_of_contents: true

5+slug: /

6+---

7+

8+

9+

10+A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others)

11+to validate accounts by email, domain or group.

12+

13+:::note

14+This repository was forked from [bitly/OAuth2_Proxy](https://github.com/bitly/oauth2_proxy) on 27/11/2018.

15+Versions v3.0.0 and up are from this fork and will have diverged from any changes in the original fork.

16+A list of changes can be seen in the [CHANGELOG](https://github.com/oauth2-proxy/oauth2-proxy/blob/master/CHANGELOG.md).

17+:::

18+

19+

20+

21+## Architecture

22+

23+

24+

25+

26+## Cloud Native Computing Foundation

27+

28+OAuth2 Proxy is a [Cloud Native Computing Foundation](https://cncf.io) Sandbox project.

29+

30+

31+

32+The Linux Foundation® (TLF) has registered trademarks and uses trademarks. For a list of TLF trademarks, see [Trademark Usage](https://www.linuxfoundation.org/legal/trademark-usage).

33+

docs/versioned_docs/version-7.2.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.3.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.4.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.5.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.6.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.6.x/configuration/overview.md+1

@@ -237,6 +237,7 @@ Provider specific options can be found on their respective subpages.

237237| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

238238| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

239239| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

240+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. |

240241| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

241242| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

242243| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

docs/versioned_docs/version-7.6.x/configuration/providers/gitlab.md+1−1

@@ -8,7 +8,7 @@ title: GitLab

88| Flag | Toml Field | Type | Description | Default |

99| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

1010| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11−| `--gitlab-projects` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

1212

1313## Usage

1414

docs/versioned_docs/version-7.7.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.7.x/configuration/overview.md+1

@@ -237,6 +237,7 @@ Provider specific options can be found on their respective subpages.

237237| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

238238| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

239239| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

240+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. |

240241| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

241242| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

242243| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

docs/versioned_docs/version-7.7.x/configuration/providers/gitlab.md+1−1

@@ -8,7 +8,7 @@ title: GitLab

88| Flag | Toml Field | Type | Description | Default |

99| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

1010| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11−| `--gitlab-projects` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

1212

1313## Usage

1414

docs/versioned_docs/version-7.8.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.8.x/configuration/overview.md+1

@@ -239,6 +239,7 @@ Provider specific options can be found on their respective subpages.

239239| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

240240| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

241241| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

242+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. |

242243| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

243244| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

244245| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

docs/versioned_docs/version-7.8.x/configuration/providers/gitlab.md+1−1

@@ -8,7 +8,7 @@ title: GitLab

88| Flag | Toml Field | Type | Description | Default |

99| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

1010| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11−| `--gitlab-projects` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

1212

1313## Usage

1414

docs/versioned_docs/version-7.8.x/configuration/providers/ms_entra_id.md+1−1

@@ -112,7 +112,7 @@ insecure_oidc_skip_issuer_verification=true

112112```

113113`insecure_oidc_skip_issuer_verification` setting is required to disable following checks:

114114* Startup check for matching issuer URL returned from [discovery document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) with `oidc_issuer_url` setting. Required, as document's `issuer` field doesn't equal to `https://login.microsoftonline.com/common/v2.0`. See [OIDC Discovery 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation).

115−* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by diffrerent tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

115+* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by different tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

116116

117117To provide additional security, Entra ID provider performs check on the ID token's `issuer` claim to match the `https://login.microsoftonline.com/{tenant-id}/v2.0` template.

118118

docs/versioned_docs/version-7.9.x/behaviour.md+20−5

@@ -3,9 +3,24 @@ id: behaviour

33title: Behaviour

44---

55

6−1. Any request passing through the proxy (and not matched by `--skip-auth-regex`) is checked for the proxy's session cookie (`--cookie-name`) (or, if allowed, a JWT token - see `--skip-jwt-bearer-tokens`).

7−2. If authentication is required but missing then the user is asked to log in and redirected to the authentication provider (unless it is an Ajax request, i.e. one with `Accept: application/json`, in which case 401 Unauthorized is returned)

8−3. After returning from the authentication provider, the oauth tokens are stored in the configured session store (cookie, redis, ...) and a cookie is set

9−4. The request is forwarded to the upstream server with added user info and authentication headers (depending on the configuration)

6+1. Authentication Requirement: All requests passing through the proxy to upstream applications require authentication, excluding default proxy endpoints.

7+ - Exception: If the request matches a skipped route (configured via `--skip-auth-route`):

8+ - Authentication is not enforced, but the proxy will opportunistically attempt to validate a session cookie (`--cookie-name`) or JWT (`--skip-jwt-bearer-tokens`) if present in the request.

9+ - Configured user info and authentication headers (e.g., `--pass-access-token`) are injected to upstream routes when validation succeeds.

1010

11−Notice that the proxy also provides a number of useful [endpoints](features/endpoints.md).

11+2. Unauthenticated Requests: When authentication is missing but required, the user is redirected to the configured Identity Provider (IdP) login page by default.

12+ - Ajax Requests: If the request has `Accept: application/json` header:

13+ - Returns `401 Unauthorized`.

14+ - Invalid JWT Tokens: If `--skip-jwt-bearer-tokens` is set and the request includes an invalid JWT:

15+ - Redirects to the login page by default.

16+ - Returns `403 Forbidden` if `--bearer-token-login-fallback` is set to `false`.

17+

18+3. Post-Authentication: After successful authentication with the IdP, OAuth tokens are stored in the configured session store (cookie or Redis), and a cookie is set.

19+

20+4. Request Forwarding: The authenticated request is processed based on configuration:

21+ - Forwarded to the configured upstream application with added user info and authentication headers, or

22+ - Returns a valid status code for downstream processing by another proxy or load balancer (e.g., Nginx or Traefik).

23+

24+---

25+

26+Note: The proxy also provides a number of useful [endpoints](features/endpoints.md) for monitoring and management.

docs/versioned_docs/version-7.9.x/configuration/overview.md+1

@@ -241,6 +241,7 @@ Provider specific options can be found on their respective subpages.

241241| flag: `--session-store-type`<br/>toml: `session_store_type` | string | [Session data storage backend](sessions.md); redis or cookie | cookie |

242242| flag: `--redis-cluster-connection-urls`<br/>toml: `redis_cluster_connection_urls` | string \| list | List of Redis cluster connection URLs (e.g. `redis://HOST[:PORT]`). Used in conjunction with `--redis-use-cluster` | |

243243| flag: `--redis-connection-url`<br/>toml: `redis_connection_url` | string | URL of redis server for redis session storage (e.g. `redis://HOST[:PORT]`) | |

244+| flag: `--redis-ca-path`<br/>toml: `redis_ca_path` | string | Path to a CA certificates file that should be used when connecting to redis. If not specified, the system cert pool is used instead. |

244245| flag: `--redis-insecure-skip-tls-verify`<br/>toml: `redis_insecure_skip_tls_verify` | bool | skip TLS verification when connecting to Redis | false |

245246| flag: `--redis-password`<br/>toml: `redis_password` | string | Redis password. Applicable for all Redis configurations. Will override any password set in `--redis-connection-url` | |

246247| flag: `--redis-sentinel-password`<br/>toml: `redis_sentinel_password` | string | Redis sentinel password. Used only for sentinel connection; any redis node passwords need to use `--redis-password` | |

docs/versioned_docs/version-7.9.x/configuration/providers/gitlab.md+1−1

@@ -8,7 +8,7 @@ title: GitLab

88| Flag | Toml Field | Type | Description | Default |

99| ------------------- | ----------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |

1010| `--gitlab-group` | `gitlab_groups` | string \| list | restrict logins to members of any of these groups (slug), separated by a comma | |

11−| `--gitlab-projects` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

11+| `--gitlab-project` | `gitlab_projects` | string \| list | restrict logins to members of any of these projects (may be given multiple times) formatted as `orgname/repo=accesslevel`. Access level should be a value matching [Gitlab access levels](https://docs.gitlab.com/ee/api/members.html#valid-access-levels), defaulted to 20 if absent | |

1212

1313## Usage

1414

docs/versioned_docs/version-7.9.x/configuration/providers/ms_entra_id.md+1−1

@@ -112,7 +112,7 @@ insecure_oidc_skip_issuer_verification=true

112112```

113113`insecure_oidc_skip_issuer_verification` setting is required to disable following checks:

114114* Startup check for matching issuer URL returned from [discovery document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) with `oidc_issuer_url` setting. Required, as document's `issuer` field doesn't equal to `https://login.microsoftonline.com/common/v2.0`. See [OIDC Discovery 4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation).

115−* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by diffrerent tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

115+* Matching ID token's `issuer` claim with `oidc_issuer_url` setting during ID token validation. Required to support tokens issued by different tenants. See [OIDC Core 3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).

116116

117117To provide additional security, Entra ID provider performs check on the ID token's `issuer` claim to match the `https://login.microsoftonline.com/{tenant-id}/v2.0` template.

118118

docs/versioned_sidebars/version-7.11.x-sidebars.json+2−1

@@ -46,7 +46,8 @@

4646 "configuration/providers/login_gov",

4747 "configuration/providers/ms_entra_id",

4848 "configuration/providers/nextcloud",

49− "configuration/providers/openid_connect"

49+ "configuration/providers/openid_connect",

50+ "configuration/providers/sourcehut"

5051 ]

5152 },

5253 "configuration/session_storage",

docs/versioned_sidebars/version-7.12.x-sidebars.jsonnew file+84

@@ -0,0 +1,84 @@

1+{

2+ "docs": [

3+ {

4+ "type": "doc",

5+ "id": "welcome"

6+ },

7+ {

8+ "type": "doc",

9+ "id": "installation"

10+ },

11+ {

12+ "type": "doc",

13+ "id": "behaviour"

14+ },

15+ {

16+ "type": "category",

17+ "label": "Configuration",

18+ "link": {

19+ "type": "doc",

20+ "id": "configuration/overview"

21+ },

22+ "collapsed": false,

23+ "items": [

24+ "configuration/overview",

25+ "configuration/integration",

26+ {

27+ "type": "category",

28+ "label": "OAuth Provider Configuration",

29+ "link": {

30+ "type": "doc",

31+ "id": "configuration/providers/index"

32+ },

33+ "items": [

34+ "configuration/providers/adfs",

35+ "configuration/providers/azure",

36+ "configuration/providers/bitbucket",

37+ "configuration/providers/digitalocean",

38+ "configuration/providers/facebook",

39+ "configuration/providers/gitea",

40+ "configuration/providers/github",

41+ "configuration/providers/gitlab",

42+ "configuration/providers/google",

43+ "configuration/providers/keycloak",

44+ "configuration/providers/keycloak_oidc",

45+ "configuration/providers/linkedin",

46+ "configuration/providers/login_gov",

47+ "configuration/providers/ms_entra_id",

48+ "configuration/providers/nextcloud",

49+ "configuration/providers/openid_connect",

50+ "configuration/providers/sourcehut"

51+ ]

52+ },

53+ "configuration/session_storage",

54+ "configuration/tls",

55+ "configuration/alpha-config"

56+ ]

57+ },

58+ {

59+ "type": "category",

60+ "label": "Features",

61+ "link": {

62+ "type": "doc",

63+ "id": "features/endpoints"

64+ },

65+ "collapsed": false,

66+ "items": [

67+ "features/endpoints"

68+ ]

69+ },

70+ {

71+ "type": "category",

72+ "label": "Community",

73+ "link": {

74+ "type": "doc",

75+ "id": "community/security"

76+ },

77+ "collapsed": false,

78+ "items": [

79+ "community/contribution",

80+ "community/security"

81+ ]

82+ }

83+ ]

84+}

docs/versioned_sidebars/version-7.13.x-sidebars.jsonnew file+100

@@ -0,0 +1,100 @@

1+{

2+ "docs": [

3+ {

4+ "type": "doc",

5+ "id": "welcome"

6+ },

7+ {

8+ "type": "doc",

9+ "id": "installation"

10+ },

11+ {

12+ "type": "doc",

13+ "id": "behaviour"

14+ },

15+ {

16+ "type": "category",

17+ "label": "Configuration",

18+ "link": {

19+ "type": "doc",

20+ "id": "configuration/overview"

21+ },

22+ "collapsed": false,

23+ "items": [

24+ "configuration/overview",

25+ {

26+ "type": "category",

27+ "label": "Integration Guides",

28+ "link": {

29+ "type": "doc",

30+ "id": "configuration/integrations/index"

31+ },

32+ "items": [

33+ "configuration/integrations/nginx",

34+ "configuration/integrations/traefik",

35+ "configuration/integrations/caddy",

36+ "configuration/integrations/headlamp",

37+ "configuration/integrations/kubernetes-dashboard"

38+ ]

39+ },

40+ {

41+ "type": "category",

42+ "label": "OAuth Provider Configuration",

43+ "link": {

44+ "type": "doc",

45+ "id": "configuration/providers/index"

46+ },

47+ "items": [

48+ "configuration/providers/adfs",

49+ "configuration/providers/azure",

50+ "configuration/providers/bitbucket",

51+ "configuration/providers/cidaas",

52+ "configuration/providers/cisco_duo",

53+ "configuration/providers/digitalocean",

54+ "configuration/providers/facebook",

55+ "configuration/providers/gitea",

56+ "configuration/providers/github",

57+ "configuration/providers/gitlab",

58+ "configuration/providers/google",

59+ "configuration/providers/keycloak",

60+ "configuration/providers/keycloak_oidc",

61+ "configuration/providers/linkedin",

62+ "configuration/providers/login_gov",

63+ "configuration/providers/ms_entra_id",

64+ "configuration/providers/nextcloud",

65+ "configuration/providers/openid_connect",

66+ "configuration/providers/sourcehut"

67+ ]

68+ },

69+ "configuration/session_storage",

70+ "configuration/tls",

71+ "configuration/alpha-config"

72+ ]

73+ },

74+ {

75+ "type": "category",

76+ "label": "Features",

77+ "link": {

78+ "type": "doc",

79+ "id": "features/endpoints"

80+ },

81+ "collapsed": false,

82+ "items": [

83+ "features/endpoints"

84+ ]

85+ },

86+ {

87+ "type": "category",

88+ "label": "Community",

89+ "link": {

90+ "type": "doc",

91+ "id": "community/security"

92+ },

93+ "collapsed": false,

94+ "items": [

95+ "community/contribution",

96+ "community/security"

97+ ]

98+ }

99+ ]

100+}

docs/versioned_sidebars/version-7.14.x-sidebars.jsonnew file+100

@@ -0,0 +1,100 @@

1+{

2+ "docs": [

3+ {

4+ "type": "doc",

5+ "id": "welcome"

6+ },

7+ {

8+ "type": "doc",

9+ "id": "installation"

10+ },

11+ {

12+ "type": "doc",

13+ "id": "behaviour"

14+ },

15+ {

16+ "type": "category",

17+ "label": "Configuration",

18+ "link": {

19+ "type": "doc",

20+ "id": "configuration/overview"

21+ },

22+ "collapsed": false,

23+ "items": [

24+ "configuration/overview",

25+ {

26+ "type": "category",

27+ "label": "Integration Guides",

28+ "link": {

29+ "type": "doc",

30+ "id": "configuration/integrations/index"

31+ },

32+ "items": [

33+ "configuration/integrations/nginx",

34+ "configuration/integrations/traefik",

35+ "configuration/integrations/caddy",

36+ "configuration/integrations/headlamp",

37+ "configuration/integrations/kubernetes-dashboard"

38+ ]

39+ },

40+ {

41+ "type": "category",

42+ "label": "OAuth Provider Configuration",

43+ "link": {

44+ "type": "doc",

45+ "id": "configuration/providers/index"

46+ },

47+ "items": [

48+ "configuration/providers/adfs",

49+ "configuration/providers/azure",

50+ "configuration/providers/bitbucket",

51+ "configuration/providers/cidaas",

52+ "configuration/providers/cisco_duo",

53+ "configuration/providers/digitalocean",

54+ "configuration/providers/facebook",

55+ "configuration/providers/gitea",

56+ "configuration/providers/github",

57+ "configuration/providers/gitlab",

58+ "configuration/providers/google",

59+ "configuration/providers/keycloak",

60+ "configuration/providers/keycloak_oidc",

61+ "configuration/providers/linkedin",

62+ "configuration/providers/login_gov",

63+ "configuration/providers/ms_entra_id",

64+ "configuration/providers/nextcloud",

65+ "configuration/providers/openid_connect",

66+ "configuration/providers/sourcehut"

67+ ]

68+ },

69+ "configuration/session_storage",

70+ "configuration/tls",

71+ "configuration/alpha-config"

72+ ]

73+ },

74+ {

75+ "type": "category",

76+ "label": "Features",

77+ "link": {

78+ "type": "doc",

79+ "id": "features/endpoints"

80+ },

81+ "collapsed": false,

82+ "items": [

83+ "features/endpoints"

84+ ]

85+ },

86+ {

87+ "type": "category",

88+ "label": "Community",

89+ "link": {

90+ "type": "doc",

91+ "id": "community/security"

92+ },

93+ "collapsed": false,

94+ "items": [

95+ "community/contribution",

96+ "community/security"

97+ ]

98+ }

99+ ]

100+}

docs/versioned_sidebars/version-7.15.x-sidebars.jsonnew file+100

@@ -0,0 +1,100 @@

1+{

2+ "docs": [

3+ {

4+ "type": "doc",

5+ "id": "welcome"

6+ },

7+ {

8+ "type": "doc",

9+ "id": "installation"

10+ },

11+ {

12+ "type": "doc",

13+ "id": "behaviour"

14+ },

15+ {

16+ "type": "category",

17+ "label": "Configuration",

18+ "link": {

19+ "type": "doc",

20+ "id": "configuration/overview"

21+ },

22+ "collapsed": false,

23+ "items": [

24+ "configuration/overview",

25+ {

26+ "type": "category",

27+ "label": "Integration Guides",

28+ "link": {

29+ "type": "doc",

30+ "id": "configuration/integrations/index"

31+ },

32+ "items": [

33+ "configuration/integrations/nginx",

34+ "configuration/integrations/traefik",

35+ "configuration/integrations/caddy",

36+ "configuration/integrations/headlamp",

37+ "configuration/integrations/kubernetes-dashboard"

38+ ]

39+ },

40+ {

41+ "type": "category",

42+ "label": "OAuth Provider Configuration",

43+ "link": {

44+ "type": "doc",

45+ "id": "configuration/providers/index"

46+ },

47+ "items": [

48+ "configuration/providers/adfs",

49+ "configuration/providers/azure",

50+ "configuration/providers/bitbucket",

51+ "configuration/providers/cidaas",

52+ "configuration/providers/cisco_duo",

53+ "configuration/providers/digitalocean",

54+ "configuration/providers/facebook",

55+ "configuration/providers/gitea",

56+ "configuration/providers/github",

57+ "configuration/providers/gitlab",

58+ "configuration/providers/google",

59+ "configuration/providers/keycloak",

60+ "configuration/providers/keycloak_oidc",

61+ "configuration/providers/linkedin",

62+ "configuration/providers/login_gov",

63+ "configuration/providers/ms_entra_id",

64+ "configuration/providers/nextcloud",

65+ "configuration/providers/openid_connect",

66+ "configuration/providers/sourcehut"

67+ ]

68+ },

69+ "configuration/session_storage",

70+ "configuration/tls",

71+ "configuration/alpha-config"

72+ ]

73+ },

74+ {

75+ "type": "category",

76+ "label": "Features",

77+ "link": {

78+ "type": "doc",

79+ "id": "features/endpoints"

80+ },

81+ "collapsed": false,

82+ "items": [

83+ "features/endpoints"

84+ ]

85+ },

86+ {

87+ "type": "category",

88+ "label": "Community",

89+ "link": {

90+ "type": "doc",

91+ "id": "community/security"

92+ },

93+ "collapsed": false,

94+ "items": [

95+ "community/contribution",

96+ "community/security"

97+ ]

98+ }

99+ ]

100+}

docs/versions.json+4

@@ -1,4 +1,8 @@

11[

2+ "7.15.x",

3+ "7.14.x",

4+ "7.13.x",

5+ "7.12.x",

26 "7.11.x",

37 "7.10.x",

48 "7.9.x",

go.mod+52−60

@@ -1,91 +1,83 @@

11module github.com/oauth2-proxy/oauth2-proxy/v7

22

3−go 1.24.6

3+go 1.26.0

44

55require (

6− cloud.google.com/go/compute/metadata v0.7.0

6+ cloud.google.com/go/compute/metadata v0.9.0

77 github.com/Bose/minisentinel v0.0.0-20200130220412-917c5a9223bb

88 github.com/a8m/envsubst v1.4.3

9− github.com/alicebob/miniredis/v2 v2.35.0

10− github.com/benbjohnson/clock v1.3.5

9+ github.com/alicebob/miniredis/v2 v2.38.0

1110 github.com/bitly/go-simplejson v0.5.1

12− github.com/bsm/redislock v0.9.4

13− github.com/coreos/go-oidc/v3 v3.14.1

11+ github.com/bsm/redislock v0.10.0

12+ github.com/coreos/go-oidc/v3 v3.20.0

1413 github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf

15− github.com/fsnotify/fsnotify v1.9.0

16− github.com/ghodss/yaml v1.0.1-0.20220118164431-d8423dcdf344

17− github.com/go-jose/go-jose/v3 v3.0.4

18− github.com/go-viper/mapstructure/v2 v2.4.0

19− github.com/golang-jwt/jwt/v5 v5.2.3

14+ github.com/fsnotify/fsnotify v1.10.1

15+ github.com/go-jose/go-jose/v3 v3.0.5

16+ github.com/go-jose/go-jose/v4 v4.1.4

17+ github.com/go-viper/mapstructure/v2 v2.5.0

18+ github.com/golang-jwt/jwt/v5 v5.3.1

2019 github.com/google/go-cmp v0.7.0

2120 github.com/google/uuid v1.6.0

2221 github.com/gorilla/mux v1.8.1

2322 github.com/justinas/alice v1.2.0

24− github.com/mbland/hmacauth v0.0.0-20170912233209-44256dfd4bfa

2523 github.com/oauth2-proxy/mockoidc v0.0.0-20240214162133-caebfff84d25

26− github.com/onsi/ginkgo/v2 v2.23.4

27− github.com/onsi/gomega v1.37.0

28− github.com/pierrec/lz4/v4 v4.1.22

29− github.com/prometheus/client_golang v1.22.0

30− github.com/redis/go-redis/v9 v9.11.0

31− github.com/spf13/cast v1.9.2

32− github.com/spf13/pflag v1.0.7

33− github.com/spf13/viper v1.20.1

34− github.com/stretchr/testify v1.10.0

24+ github.com/onsi/ginkgo/v2 v2.32.1

25+ github.com/onsi/gomega v1.42.1

26+ github.com/pierrec/lz4/v4 v4.1.28

27+ github.com/prometheus/client_golang v1.24.1

28+ github.com/redis/go-redis/v9 v9.22.0

29+ github.com/spf13/cast v1.10.0

30+ github.com/spf13/pflag v1.0.10

31+ github.com/spf13/viper v1.21.0

32+ github.com/stretchr/testify v1.12.0

3533 github.com/vmihailenco/msgpack/v5 v5.4.1

36− golang.org/x/crypto v0.40.0

37− golang.org/x/net v0.42.0

38− golang.org/x/oauth2 v0.30.0

39− golang.org/x/sync v0.16.0

40− google.golang.org/api v0.242.0

34+ go.yaml.in/yaml/v3 v3.0.5

35+ golang.org/x/crypto v0.55.0

36+ golang.org/x/net v0.58.0

37+ golang.org/x/oauth2 v0.36.0

38+ golang.org/x/sync v0.22.0

39+ google.golang.org/api v0.293.0

4140 gopkg.in/natefinch/lumberjack.v2 v2.2.1

42− k8s.io/apimachinery v0.33.3

41+ k8s.io/apimachinery v0.36.3

4342)

4443

4544require (

46− cloud.google.com/go/auth v0.16.2 // indirect

45+ cloud.google.com/go/auth v0.23.1 // indirect

4746 cloud.google.com/go/auth/oauth2adapt v0.2.8 // indirect

47+ github.com/Masterminds/semver/v3 v3.5.0 // indirect

4848 github.com/beorn7/perks v1.0.1 // indirect

49− github.com/bmizerany/assert v0.0.0-20160611221934-b7ed37b82869 // indirect

5049 github.com/cespare/xxhash/v2 v2.3.0 // indirect

51− github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc // indirect

52− github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f // indirect

53− github.com/felixge/httpsnoop v1.0.4 // indirect

54− github.com/go-jose/go-jose/v4 v4.1.1 // indirect

55− github.com/go-logr/logr v1.4.3 // indirect

50+ github.com/felixge/httpsnoop v1.1.0 // indirect

51+ github.com/go-logr/logr v1.4.4 // indirect

5652 github.com/go-logr/stdr v1.2.2 // indirect

5753 github.com/go-task/slim-sprig/v3 v3.0.0 // indirect

58− github.com/google/pprof v0.0.0-20250630185457-6e76a2b096b5 // indirect

54+ github.com/google/pprof v0.0.0-20260802141513-ef3492d7dac3 // indirect

5955 github.com/google/s2a-go v0.1.9 // indirect

60− github.com/googleapis/enterprise-certificate-proxy v0.3.6 // indirect

61− github.com/googleapis/gax-go/v2 v2.15.0 // indirect

56+ github.com/googleapis/enterprise-certificate-proxy v0.3.21 // indirect

57+ github.com/googleapis/gax-go/v2 v2.23.0 // indirect

6258 github.com/kylelemons/godebug v1.1.0 // indirect

6359 github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect

64− github.com/pelletier/go-toml/v2 v2.2.4 // indirect

65− github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 // indirect

60+ github.com/pelletier/go-toml/v2 v2.4.3 // indirect

6661 github.com/prometheus/client_model v0.6.2 // indirect

67− github.com/prometheus/common v0.65.0 // indirect

68− github.com/prometheus/procfs v0.17.0 // indirect

69− github.com/rogpeppe/go-internal v1.14.1 // indirect

70− github.com/sagikazarmark/locafero v0.9.0 // indirect

71− github.com/sourcegraph/conc v0.3.0 // indirect

72− github.com/spf13/afero v1.14.0 // indirect

62+ github.com/prometheus/common v0.70.1 // indirect

63+ github.com/prometheus/procfs v0.21.1 // indirect

64+ github.com/sagikazarmark/locafero v0.12.0 // indirect

65+ github.com/spf13/afero v1.15.0 // indirect

7366 github.com/subosito/gotenv v1.6.0 // indirect

7467 github.com/vmihailenco/tagparser/v2 v2.0.0 // indirect

75− github.com/yuin/gopher-lua v1.1.1 // indirect

76− go.opentelemetry.io/auto/sdk v1.1.0 // indirect

77− go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.62.0 // indirect

78− go.opentelemetry.io/otel v1.37.0 // indirect

79− go.opentelemetry.io/otel/metric v1.37.0 // indirect

80− go.opentelemetry.io/otel/trace v1.37.0 // indirect

81− go.uber.org/automaxprocs v1.6.0 // indirect

82− go.uber.org/multierr v1.11.0 // indirect

83− golang.org/x/sys v0.34.0 // indirect

84− golang.org/x/text v0.27.0 // indirect

85− golang.org/x/tools v0.35.0 // indirect

86− google.golang.org/genproto/googleapis/rpc v0.0.0-20250707201910-8d1bb00bc6a7 // indirect

87− google.golang.org/grpc v1.73.0 // indirect

88− google.golang.org/protobuf v1.36.6 // indirect

89− gopkg.in/yaml.v2 v2.4.0 // indirect

68+ github.com/yuin/gopher-lua v1.1.2 // indirect

69+ go.opentelemetry.io/auto/sdk v1.2.1 // indirect

70+ go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.70.0 // indirect

71+ go.opentelemetry.io/otel v1.45.0 // indirect

72+ go.opentelemetry.io/otel/metric v1.45.0 // indirect

73+ go.opentelemetry.io/otel/trace v1.45.0 // indirect

74+ go.uber.org/atomic v1.11.0 // indirect

75+ golang.org/x/mod v0.40.0 // indirect

76+ golang.org/x/sys v0.47.0 // indirect

77+ golang.org/x/text v0.41.0 // indirect

78+ golang.org/x/tools v0.49.0 // indirect

79+ google.golang.org/genproto/googleapis/rpc v0.0.0-20260817212433-ac3dfec99bb1 // indirect

80+ google.golang.org/grpc v1.83.0 // indirect

81+ google.golang.org/protobuf v1.36.12 // indirect

9082 gopkg.in/yaml.v3 v3.0.1 // indirect

9183)

go.sum+148−163

@@ -1,74 +1,70 @@

1−cloud.google.com/go/auth v0.16.2 h1:QvBAGFPLrDeoiNjyfVunhQ10HKNYuOwZ5noee0M5df4=

2−cloud.google.com/go/auth v0.16.2/go.mod h1:sRBas2Y1fB1vZTdurouM0AzuYQBMZinrUYL8EufhtEA=

1+cloud.google.com/go/auth v0.23.1 h1:1tPpBPG02lQHmoiAvs9egyCASqXP0xgobptjZzov/Jg=

2+cloud.google.com/go/auth v0.23.1/go.mod h1:4DhBRcqvtljQN3dJ57qtqbib5ZGCYE5f2crfiiC2EM0=

33cloud.google.com/go/auth/oauth2adapt v0.2.8 h1:keo8NaayQZ6wimpNSmW5OPc283g65QNIiLpZnkHRbnc=

44cloud.google.com/go/auth/oauth2adapt v0.2.8/go.mod h1:XQ9y31RkqZCcwJWNSx2Xvric3RrU88hAYYbjDWYDL+c=

5−cloud.google.com/go/compute/metadata v0.7.0 h1:PBWF+iiAerVNe8UCHxdOt6eHLVc3ydFeOCw78U8ytSU=

6−cloud.google.com/go/compute/metadata v0.7.0/go.mod h1:j5MvL9PprKL39t166CoB1uVHfQMs4tFQZZcKwksXUjo=

5+cloud.google.com/go/compute/metadata v0.9.0 h1:pDUj4QMoPejqq20dK0Pg2N4yG9zIkYGdBtwLoEkH9Zs=

6+cloud.google.com/go/compute/metadata v0.9.0/go.mod h1:E0bWwX5wTnLPedCKqk3pJmVgCBSM6qQI1yTBdEb3C10=

77github.com/Bose/minisentinel v0.0.0-20200130220412-917c5a9223bb h1:ZVN4Iat3runWOFLaBCDVU5a9X/XikSRBosye++6gojw=

88github.com/Bose/minisentinel v0.0.0-20200130220412-917c5a9223bb/go.mod h1:WsAABbY4HQBgd3mGuG4KMNTbHJCPvx9IVBHzysbknss=

99github.com/FZambia/sentinel v1.0.0 h1:KJ0ryjKTZk5WMp0dXvSdNqp3lFaW1fNFuEYfrkLOYIc=

1010github.com/FZambia/sentinel v1.0.0/go.mod h1:ytL1Am/RLlAoAXG6Kj5LNuw/TRRQrv2rt2FT26vP5gI=

11+github.com/Masterminds/semver/v3 v3.5.0 h1:kQceYJfbupGfZOKZQg0kou0DgAKhzDg2NZPAwZ/2OOE=

12+github.com/Masterminds/semver/v3 v3.5.0/go.mod h1:4V+yj/TJE1HU9XfppCwVMZq3I84lprf4nC11bSS5beM=

1113github.com/a8m/envsubst v1.4.3 h1:kDF7paGK8QACWYaQo6KtyYBozY2jhQrTuNNuUxQkhJY=

1214github.com/a8m/envsubst v1.4.3/go.mod h1:4jjHWQlZoaXPoLQUb7H2qT4iLkZDdmEQiOUogdUmqVU=

1315github.com/alicebob/gopher-json v0.0.0-20180125190556-5a6b3ba71ee6/go.mod h1:SGnFV6hVsYE877CKEZ6tDNTjaSXYUk6QqoIK6PrAtcc=

1416github.com/alicebob/miniredis/v2 v2.11.1/go.mod h1:UA48pmi7aSazcGAvcdKcBB49z521IC9VjTTRz2nIaJE=

15−github.com/alicebob/miniredis/v2 v2.35.0 h1:QwLphYqCEAo1eu1TqPRN2jgVMPBweeQcR21jeqDCONI=

16−github.com/alicebob/miniredis/v2 v2.35.0/go.mod h1:TcL7YfarKPGDAthEtl5NBeHZfeUQj6OXMm/+iu5cLMM=

17−github.com/benbjohnson/clock v1.3.5 h1:VvXlSJBzZpA/zum6Sj74hxwYI2DIxRWuNIoXAzHZz5o=

18−github.com/benbjohnson/clock v1.3.5/go.mod h1:J11/hYXuz8f4ySSvYwY0FKfm+ezbsZBKZxNJlLklBHA=

17+github.com/alicebob/miniredis/v2 v2.38.0 h1:nZAzCR+Lj+Vxk4ZXzm2NuKq2O33RXj1XxJ2e2uP9jiw=

18+github.com/alicebob/miniredis/v2 v2.38.0/go.mod h1:TcL7YfarKPGDAthEtl5NBeHZfeUQj6OXMm/+iu5cLMM=

1919github.com/beorn7/perks v1.0.1 h1:VlbKKnNfV8bJzeqoa4cOKqO6bYr3WgKZxO8Z16+hsOM=

2020github.com/beorn7/perks v1.0.1/go.mod h1:G2ZrVWU2WbWT9wwq4/hrbKbnv/1ERSJQ0ibhJ6rlkpw=

2121github.com/bitly/go-simplejson v0.5.1 h1:xgwPbetQScXt1gh9BmoJ6j9JMr3TElvuIyjR8pgdoow=

2222github.com/bitly/go-simplejson v0.5.1/go.mod h1:YOPVLzCfwK14b4Sff3oP1AmGhI9T9Vsg84etUnlyp+Q=

23−github.com/bmizerany/assert v0.0.0-20160611221934-b7ed37b82869 h1:DDGfHa7BWjL4YnC6+E63dPcxHo2sUxDIu8g3QgEJdRY=

24−github.com/bmizerany/assert v0.0.0-20160611221934-b7ed37b82869/go.mod h1:Ekp36dRnpXw/yCqJaO+ZrUyxD+3VXMFFr56k5XYrpB4=

2523github.com/bsm/ginkgo/v2 v2.12.0 h1:Ny8MWAHyOepLGlLKYmXG4IEkioBysk6GpaRTLC8zwWs=

2624github.com/bsm/ginkgo/v2 v2.12.0/go.mod h1:SwYbGRRDovPVboqFv0tPTcG1sN61LM1Z4ARdbAV9g4c=

2725github.com/bsm/gomega v1.27.10 h1:yeMWxP2pV2fG3FgAODIY8EiRE3dy0aeFYt4l7wh6yKA=

2826github.com/bsm/gomega v1.27.10/go.mod h1:JyEr/xRbxbtgWNi8tIEVPUYZ5Dzef52k01W3YH0H+O0=

29−github.com/bsm/redislock v0.9.4 h1:X/Wse1DPpiQgHbVYRE9zv6m070UcKoOGekgvpNhiSvw=

30−github.com/bsm/redislock v0.9.4/go.mod h1:Epf7AJLiSFwLCiZcfi6pWFO/8eAYrYpQXFxEDPoDeAk=

27+github.com/bsm/redislock v0.10.0 h1:NAe1OHDnwPmWEzD+LpWBZXAdZrWld/xj/wmqEcQednQ=

28+github.com/bsm/redislock v0.10.0/go.mod h1:M05WZGjPbX/8ne7LmB7AbOsa2kv7Jzx4fqkLpDFZvJs=

3129github.com/cespare/xxhash/v2 v2.3.0 h1:UL815xU9SqsFlibzuggzjXhog7bL6oX9BbNZnL2UFvs=

3230github.com/cespare/xxhash/v2 v2.3.0/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs=

3331github.com/chzyer/logex v1.1.10/go.mod h1:+Ywpsq7O8HXn0nuIou7OrIPyXbp3wmkHB+jjWRnGsAI=

3432github.com/chzyer/readline v0.0.0-20180603132655-2972be24d48e/go.mod h1:nSuG5e5PlCu98SY8svDHJxuZscDgtXS6KTTbou5AhLI=

3533github.com/chzyer/test v0.0.0-20180213035817-a1ea475d72b1/go.mod h1:Q3SI9o4m/ZMnBNeIyt5eFwwo7qiLfzFZmjNmxjkiQlU=

36−github.com/coreos/go-oidc/v3 v3.14.1 h1:9ePWwfdwC4QKRlCXsJGou56adA/owXczOzwKdOumLqk=

37−github.com/coreos/go-oidc/v3 v3.14.1/go.mod h1:HaZ3szPaZ0e4r6ebqvsLWlk2Tn+aejfmrfah6hnSYEU=

34+github.com/coreos/go-oidc/v3 v3.20.0 h1:EtE0WIBHk03N+DqGkY4+UONzzZHk7amKt6IyNd7OsZE=

35+github.com/coreos/go-oidc/v3 v3.20.0/go.mod h1:DYCf24+ncYi+XkIH97GY1+dqoRlbaSI26KVTCI9SrY4=

3836github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf h1:iW4rZ826su+pqaw19uhpSCzhj44qo35pNgKFGqzDKkU=

3937github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4=

4038github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=

41−github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc h1:U9qPSI2PIWSS1VwoXQT9A3Wy9MM3WgvqSxFWenqJduM=

42−github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=

43−github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f h1:lO4WD4F/rVNCu3HqELle0jiPLLBs70cWOduZpkS1E78=

44−github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f/go.mod h1:cuUVRXasLTGF7a8hSLbxyZXjz+1KgoB3wDUb6vlszIc=

45−github.com/felixge/httpsnoop v1.0.4 h1:NFTV2Zj1bL4mc9sqWACXbQFVBBg2W3GPvqp8/ESS2Wg=

46−github.com/felixge/httpsnoop v1.0.4/go.mod h1:m8KPJKqk1gH5J9DgRY2ASl2lWCfGKXixSwevea8zH2U=

39+github.com/felixge/httpsnoop v1.1.0 h1:3YtUj32ZZkqZtt3sZZsClsymw/QDuVfpNhoA31zeORc=

40+github.com/felixge/httpsnoop v1.1.0/go.mod h1:Zqxgdd+1Rkcz8euOqdr7lqgCRJztwr5hp9vDSi5UZCE=

4741github.com/frankban/quicktest v1.14.6 h1:7Xjx+VpznH+oBnejlPUj8oUpdxnVs4f8XU8WnHkI4W8=

4842github.com/frankban/quicktest v1.14.6/go.mod h1:4ptaffx2x8+WTWXmUCuVU6aPUX1/Mz7zb5vbUoiM6w0=

49−github.com/fsnotify/fsnotify v1.9.0 h1:2Ml+OJNzbYCTzsxtv8vKSFD9PbJjmhYF14k/jKC7S9k=

50−github.com/fsnotify/fsnotify v1.9.0/go.mod h1:8jBTzvmWwFyi3Pb8djgCCO5IBqzKJ/Jwo8TRcHyHii0=

51−github.com/ghodss/yaml v1.0.1-0.20220118164431-d8423dcdf344 h1:Arcl6UOIS/kgO2nW3A65HN+7CMjSDP/gofXL4CZt1V4=

52−github.com/ghodss/yaml v1.0.1-0.20220118164431-d8423dcdf344/go.mod h1:GIjDIg/heH5DOkXY3YJ/wNhfHsQHoXGjl8G8amsYQ1I=

53−github.com/go-jose/go-jose/v3 v3.0.4 h1:Wp5HA7bLQcKnf6YYao/4kpRpVMp/yf6+pJKV8WFSaNY=

54−github.com/go-jose/go-jose/v3 v3.0.4/go.mod h1:5b+7YgP7ZICgJDBdfjZaIt+H/9L9T/YQrVfLAMboGkQ=

55−github.com/go-jose/go-jose/v4 v4.1.1 h1:JYhSgy4mXXzAdF3nUx3ygx347LRXJRrpgyU3adRmkAI=

56−github.com/go-jose/go-jose/v4 v4.1.1/go.mod h1:BdsZGqgdO3b6tTc6LSE56wcDbMMLuPsw5d4ZD5f94kA=

43+github.com/fsnotify/fsnotify v1.10.1 h1:b0/UzAf9yR5rhf3RPm9gf3ehBPpf0oZKIjtpKrx59Ho=

44+github.com/fsnotify/fsnotify v1.10.1/go.mod h1:TLheqan6HD6GBK6PrDWyDPBaEV8LspOxvPSjC+bVfgo=

45+github.com/gkampitakis/ciinfo v0.3.2 h1:JcuOPk8ZU7nZQjdUhctuhQofk7BGHuIy0c9Ez8BNhXs=

46+github.com/gkampitakis/ciinfo v0.3.2/go.mod h1:1NIwaOcFChN4fa/B0hEBdAb6npDlFL8Bwx4dfRLRqAo=

47+github.com/gkampitakis/go-diff v1.3.2 h1:Qyn0J9XJSDTgnsgHRdz9Zp24RaJeKMUHg2+PDZZdC4M=

48+github.com/gkampitakis/go-diff v1.3.2/go.mod h1:LLgOrpqleQe26cte8s36HTWcTmMEur6OPYerdAAS9tk=

49+github.com/gkampitakis/go-snaps v0.5.15 h1:amyJrvM1D33cPHwVrjo9jQxX8g/7E2wYdZ+01KS3zGE=

50+github.com/gkampitakis/go-snaps v0.5.15/go.mod h1:HNpx/9GoKisdhw9AFOBT1N7DBs9DiHo/hGheFGBZ+mc=

51+github.com/go-jose/go-jose/v3 v3.0.5 h1:BLLJWbC4nMZOfuPVxoZIxeYsn6Nl2r1fITaJ78UQlVQ=

52+github.com/go-jose/go-jose/v3 v3.0.5/go.mod h1:5b+7YgP7ZICgJDBdfjZaIt+H/9L9T/YQrVfLAMboGkQ=

53+github.com/go-jose/go-jose/v4 v4.1.4 h1:moDMcTHmvE6Groj34emNPLs/qtYXRVcd6S7NHbHz3kA=

54+github.com/go-jose/go-jose/v4 v4.1.4/go.mod h1:x4oUasVrzR7071A4TnHLGSPpNOm2a21K9Kf04k1rs08=

5755github.com/go-logr/logr v1.2.2/go.mod h1:jdQByPbusPIv2/zmleS9BjJVeZ6kBagPoEUsqbVz/1A=

58−github.com/go-logr/logr v1.4.3 h1:CjnDlHq8ikf6E492q6eKboGOC0T8CDaOvkHCIg8idEI=

59−github.com/go-logr/logr v1.4.3/go.mod h1:9T104GzyrTigFIr8wt5mBrctHMim0Nb2HLGrmQ40KvY=

56+github.com/go-logr/logr v1.4.4 h1:tG4xh9yMsRCAiodLVTxyrkzSZ9+o0L1Kg/+cPVcbP/8=

57+github.com/go-logr/logr v1.4.4/go.mod h1:9T104GzyrTigFIr8wt5mBrctHMim0Nb2HLGrmQ40KvY=

6058github.com/go-logr/stdr v1.2.2 h1:hSWxHoqTgW2S2qGc0LTAI563KZ5YKYRhT3MFKZMbjag=

6159github.com/go-logr/stdr v1.2.2/go.mod h1:mMo/vtBO5dYbehREoey6XUKy/eSumjCCveDpRre4VKE=

6260github.com/go-task/slim-sprig/v3 v3.0.0 h1:sUs3vkvUymDpBKi3qH1YSqBQk9+9D/8M2mN1vB6EwHI=

6361github.com/go-task/slim-sprig/v3 v3.0.0/go.mod h1:W848ghGpv3Qj3dhTPRyJypKRiqCdHZiAzKg9hl15HA8=

64−github.com/go-viper/mapstructure/v2 v2.3.0 h1:27XbWsHIqhbdR5TIC911OfYvgSaW93HM+dX7970Q7jk=

65−github.com/go-viper/mapstructure/v2 v2.3.0/go.mod h1:oJDH3BJKyqBA2TXFhDsKDGDTlndYOZ6rGS0BRZIxGhM=

66−github.com/go-viper/mapstructure/v2 v2.4.0 h1:EBsztssimR/CONLSZZ04E8qAkxNYq4Qp9LvH92wZUgs=

67−github.com/go-viper/mapstructure/v2 v2.4.0/go.mod h1:oJDH3BJKyqBA2TXFhDsKDGDTlndYOZ6rGS0BRZIxGhM=

68−github.com/golang-jwt/jwt/v5 v5.2.2 h1:Rl4B7itRWVtYIHFrSNd7vhTiz9UpLdi6gZhZ3wEeDy8=

69−github.com/golang-jwt/jwt/v5 v5.2.2/go.mod h1:pqrtFR0X4osieyHYxtmOUWsAWrfe1Q5UVIyoH402zdk=

70−github.com/golang-jwt/jwt/v5 v5.2.3 h1:kkGXqQOBSDDWRhWNXTFpqGSCMyh/PLnqUvMGJPDJDs0=

71−github.com/golang-jwt/jwt/v5 v5.2.3/go.mod h1:pqrtFR0X4osieyHYxtmOUWsAWrfe1Q5UVIyoH402zdk=

62+github.com/go-viper/mapstructure/v2 v2.5.0 h1:vM5IJoUAy3d7zRSVtIwQgBj7BiWtMPfmPEgAXnvj1Ro=

63+github.com/go-viper/mapstructure/v2 v2.5.0/go.mod h1:oJDH3BJKyqBA2TXFhDsKDGDTlndYOZ6rGS0BRZIxGhM=

64+github.com/goccy/go-yaml v1.18.0 h1:8W7wMFS12Pcas7KU+VVkaiCng+kG8QiFeFwzFb+rwuw=

65+github.com/goccy/go-yaml v1.18.0/go.mod h1:XBurs7gK8ATbW4ZPGKgcbrY1Br56PdM69F7LkFRi1kA=

66+github.com/golang-jwt/jwt/v5 v5.3.1 h1:kYf81DTWFe7t+1VvL7eS+jKFVWaUnK9cB1qbwn63YCY=

67+github.com/golang-jwt/jwt/v5 v5.3.1/go.mod h1:fxCRLWMO43lRc8nhHWY6LGqRcf+1gQWArsqaEUEa5bE=

7268github.com/golang/protobuf v1.5.4 h1:i7eJL8qZTpSEXOPTxNKhASYpMn+8e5Q6AdndVa1dWek=

7369github.com/golang/protobuf v1.5.4/go.mod h1:lnTiLA8Wa4RWRcIUkrtSVa5nRhsEGBg48fD6rSs7xps=

7470github.com/gomodule/redigo v1.7.1-0.20190322064113-39e2c31b7ca3 h1:6amM4HsNPOvMLVc2ZnyqrjeQ92YAVWn7T4WBKK87inY=

@@ -76,84 +72,88 @@ github.com/gomodule/redigo v1.7.1-0.20190322064113-39e2c31b7ca3/go.mod h1:B4C85q

7672github.com/google/go-cmp v0.5.9/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY=

7773github.com/google/go-cmp v0.7.0 h1:wk8382ETsv4JYUZwIsn6YpYiWiBsYLSJiTsyBybVuN8=

7874github.com/google/go-cmp v0.7.0/go.mod h1:pXiqmnSA92OHEEa9HXL2W4E7lf9JzCmGVUdgjX3N/iU=

79−github.com/google/pprof v0.0.0-20250630185457-6e76a2b096b5 h1:xhMrHhTJ6zxu3gA4enFM9MLn9AY7613teCdFnlUVbSQ=

80−github.com/google/pprof v0.0.0-20250630185457-6e76a2b096b5/go.mod h1:5hDyRhoBCxViHszMt12TnOpEI4VVi+U8Gm9iphldiMA=

75+github.com/google/pprof v0.0.0-20260802141513-ef3492d7dac3 h1:LMLX+LgTNWpfvCBdFebv6EsYotImrt/Ppc5cXIriCSo=

76+github.com/google/pprof v0.0.0-20260802141513-ef3492d7dac3/go.mod h1:jl5iWTm0/hd5PjEYEOuwAJ57L/CibdZfrqZ5XA5GrCk=

8177github.com/google/s2a-go v0.1.9 h1:LGD7gtMgezd8a/Xak7mEWL0PjoTQFvpRudN895yqKW0=

8278github.com/google/s2a-go v0.1.9/go.mod h1:YA0Ei2ZQL3acow2O62kdp9UlnvMmU7kA6Eutn0dXayM=

8379github.com/google/uuid v1.1.1/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=

8480github.com/google/uuid v1.6.0 h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0=

8581github.com/google/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=

86−github.com/googleapis/enterprise-certificate-proxy v0.3.6 h1:GW/XbdyBFQ8Qe+YAmFU9uHLo7OnF5tL52HFAgMmyrf4=

87−github.com/googleapis/enterprise-certificate-proxy v0.3.6/go.mod h1:MkHOF77EYAE7qfSuSS9PU6g4Nt4e11cnsDUowfwewLA=

88−github.com/googleapis/gax-go/v2 v2.14.2 h1:eBLnkZ9635krYIPD+ag1USrOAI0Nr0QYF3+/3GqO0k0=

89−github.com/googleapis/gax-go/v2 v2.14.2/go.mod h1:ON64QhlJkhVtSqp4v1uaK92VyZ2gmvDQsweuyLV+8+w=

90−github.com/googleapis/gax-go/v2 v2.15.0 h1:SyjDc1mGgZU5LncH8gimWo9lW1DtIfPibOG81vgd/bo=

91−github.com/googleapis/gax-go/v2 v2.15.0/go.mod h1:zVVkkxAQHa1RQpg9z2AUCMnKhi0Qld9rcmyfL1OZhoc=

82+github.com/googleapis/enterprise-certificate-proxy v0.3.21 h1:OFdQ3tnCX/zaQ0Cedur3D3z7kI6HiLX9g3TiAN4/DFU=

83+github.com/googleapis/enterprise-certificate-proxy v0.3.21/go.mod h1:L3D/IQExI6LqEjBdXcZQ1WluSgigQmSwBboFstVPM4w=

84+github.com/googleapis/gax-go/v2 v2.23.0 h1:Tchl7qkvE7Ip3y+ztvNufYFvkfqTe7NfLTYGIdJRLuE=

85+github.com/googleapis/gax-go/v2 v2.23.0/go.mod h1:rBQKOVJCdb8IFEzg+FCwlt1LP/xMDGuqUXhUG+XMXEg=

9286github.com/gorilla/mux v1.8.1 h1:TuBL49tXwgrFYWhqrNgrUNEY92u81SPhu7sTdzQEiWY=

9387github.com/gorilla/mux v1.8.1/go.mod h1:AKf9I4AEqPTmMytcMc0KkNouC66V3BtZ4qD5fmWSiMQ=

88+github.com/joshdk/go-junit v1.0.0 h1:S86cUKIdwBHWwA6xCmFlf3RTLfVXYQfvanM5Uh+K6GE=

89+github.com/joshdk/go-junit v1.0.0/go.mod h1:TiiV0PqkaNfFXjEiyjWM3XXrhVyCa1K4Zfga6W52ung=

9490github.com/justinas/alice v1.2.0 h1:+MHSA/vccVCF4Uq37S42jwlkvI2Xzl7zTPCN5BnZNVo=

9591github.com/justinas/alice v1.2.0/go.mod h1:fN5HRH/reO/zrUflLfTN43t3vXvKzvZIENsNEe7i7qA=

96−github.com/klauspost/compress v1.18.0 h1:c/Cqfb0r+Yi+JtIEq73FWXVkRonBlf0CRNYc8Zttxdo=

97−github.com/klauspost/compress v1.18.0/go.mod h1:2Pp+KzxcywXVXMr50+X0Q/Lsb43OQHYWRCY2AiWywWQ=

92+github.com/klauspost/compress v1.19.1 h1:VsB4HPswih7mmZ8WleSFQ75c/Ui1M4trX5oAsJnhSlk=

93+github.com/klauspost/compress v1.19.1/go.mod h1:cwPg85FWrGar70rWktvGQj8/hthj3wpl0PGDogxkrSQ=

94+github.com/klauspost/cpuid/v2 v2.2.10 h1:tBs3QSyvjDyFTq3uoc/9xFpCuOsJQFNPiAhYdw2skhE=

95+github.com/klauspost/cpuid/v2 v2.2.10/go.mod h1:hqwkgyIinND0mEev00jJYCxPNVRVXFQeu1XKlok6oO0=

9896github.com/kr/pretty v0.3.1 h1:flRD4NNwYAUpkphVc1HcthR4KEIFJ65n8Mw5qdRn3LE=

9997github.com/kr/pretty v0.3.1/go.mod h1:hoEshYVHaxMs3cyo3Yncou5ZscifuDolrwPKZanG3xk=

10098github.com/kr/text v0.2.0 h1:5Nx0Ya0ZqY2ygV366QzturHI13Jq95ApcVaJBhpS+AY=

10199github.com/kr/text v0.2.0/go.mod h1:eLer722TekiGuMkidMxC/pM04lWEeraHUUmBw8l2grE=

102100github.com/kylelemons/godebug v1.1.0 h1:RPNrshWIDI6G2gRW9EHilWtl7Z6Sb1BR0xunSBf0SNc=

103101github.com/kylelemons/godebug v1.1.0/go.mod h1:9/0rRGxNHcop5bhtWyNeEfOS8JIWk580+fNqagV/RAw=

102+github.com/maruel/natural v1.1.1 h1:Hja7XhhmvEFhcByqDoHz9QZbkWey+COd9xWfCfn1ioo=

103+github.com/maruel/natural v1.1.1/go.mod h1:v+Rfd79xlw1AgVBjbO0BEQmptqb5HvL/k9GRHB7ZKEg=

104104github.com/matryer/is v1.2.0 h1:92UTHpy8CDwaJ08GqLDzhhuixiBUUD1p3AU6PHddz4A=

105105github.com/matryer/is v1.2.0/go.mod h1:2fLPjFQM9rhQ15aVEtbuwhJinnOqrmgXPNdZsdwlWXA=

106−github.com/mbland/hmacauth v0.0.0-20170912233209-44256dfd4bfa h1:hI1uC2A3vJFjwvBn0G0a7QBRdBUp6Y048BtLAHRTKPo=

107−github.com/mbland/hmacauth v0.0.0-20170912233209-44256dfd4bfa/go.mod h1:8vxFeeg++MqgCHwehSuwTlYCF0ALyDJbYJ1JsKi7v6s=

106+github.com/mfridman/tparse v0.18.0 h1:wh6dzOKaIwkUGyKgOntDW4liXSo37qg5AXbIhkMV3vE=

107+github.com/mfridman/tparse v0.18.0/go.mod h1:gEvqZTuCgEhPbYk/2lS3Kcxg1GmTxxU7kTC8DvP0i/A=

108108github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 h1:C3w9PqII01/Oq1c1nUAm88MOHcQC9l5mIlSMApZMrHA=

109109github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ=

110110github.com/oauth2-proxy/mockoidc v0.0.0-20240214162133-caebfff84d25 h1:9bCMuD3TcnjeqjPT2gSlha4asp8NvgcFRYExCaikCxk=

111111github.com/oauth2-proxy/mockoidc v0.0.0-20240214162133-caebfff84d25/go.mod h1:eDjgYHYDJbPLBLsyZ6qRaugP0mX8vePOhZ5id1fdzJw=

112−github.com/onsi/ginkgo/v2 v2.23.4 h1:ktYTpKJAVZnDT4VjxSbiBenUjmlL/5QkBEocaWXiQus=

113−github.com/onsi/ginkgo/v2 v2.23.4/go.mod h1:Bt66ApGPBFzHyR+JO10Zbt0Gsp4uWxu5mIOTusL46e8=

114−github.com/onsi/gomega v1.37.0 h1:CdEG8g0S133B4OswTDC/5XPSzE1OeP29QOioj2PID2Y=

115−github.com/onsi/gomega v1.37.0/go.mod h1:8D9+Txp43QWKhM24yyOBEdpkzN8FvJyAwecBgsU4KU0=

116−github.com/pelletier/go-toml/v2 v2.2.4 h1:mye9XuhQ6gvn5h28+VilKrrPoQVanw5PMw/TB0t5Ec4=

117−github.com/pelletier/go-toml/v2 v2.2.4/go.mod h1:2gIqNv+qfxSVS7cM2xJQKtLSTLUE9V8t9Stt+h56mCY=

118−github.com/pierrec/lz4/v4 v4.1.22 h1:cKFw6uJDK+/gfw5BcDL0JL5aBsAFdsIT18eRtLj7VIU=

119−github.com/pierrec/lz4/v4 v4.1.22/go.mod h1:gZWDp/Ze/IJXGXf23ltt2EXimqmTUXEy0GFuRQyBid4=

112+github.com/onsi/ginkgo/v2 v2.32.1 h1:6tlvcDm/3sE8lGJbZ4+d4mO3RLy24/tQWOFzVSQNIfw=

113+github.com/onsi/ginkgo/v2 v2.32.1/go.mod h1:+aXOY+vzZ5mu2iI2HpTZUPmM//oQfsNFX6gU9kNcA44=

114+github.com/onsi/gomega v1.42.1 h1:iN1rCUX+44NZ1Dc97MPoeFYbFR0vh8zxoxMFwKdyZ6I=

115+github.com/onsi/gomega v1.42.1/go.mod h1:REff/hsDsodHoKlWsP2mAPhu1+5/6hVYNf9rIEBpeSg=

116+github.com/pelletier/go-toml/v2 v2.4.3 h1:GTRvJQutkOSftxIFD5xw9aepkYNuPWmVJpffdDPYVpY=

117+github.com/pelletier/go-toml/v2 v2.4.3/go.mod h1:2gIqNv+qfxSVS7cM2xJQKtLSTLUE9V8t9Stt+h56mCY=

118+github.com/pierrec/lz4/v4 v4.1.28 h1:pPEPwRJ4kybBTfGt28q7lQsRJQHhC08axprdLD5Ppio=

119+github.com/pierrec/lz4/v4 v4.1.28/go.mod h1:EoQMVJgeeEOMsCqCzqFm2O0cJvljX2nGZjcRIPL34O4=

120120github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=

121−github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 h1:Jamvg5psRIccs7FGNTlIRMkT8wgtp5eCXdBlqhYGL6U=

122−github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=

123−github.com/prashantv/gostub v1.1.0 h1:BTyx3RfQjRHnUWaGF9oQos79AlQ5k8WNktv7VGvVH4g=

124−github.com/prashantv/gostub v1.1.0/go.mod h1:A5zLQHz7ieHGG7is6LLXLz7I8+3LZzsrV0P1IAHhP5U=

125−github.com/prometheus/client_golang v1.22.0 h1:rb93p9lokFEsctTys46VnV1kLCDpVZ0a/Y92Vm0Zc6Q=

126−github.com/prometheus/client_golang v1.22.0/go.mod h1:R7ljNsLXhuQXYZYtw6GAE9AZg8Y7vEW5scdCXrWRXC0=

121+github.com/prometheus/client_golang v1.24.1 h1:JnJkREXzWxUdCuPFpIWZiPispT9xVV59uiuyR2bPlnU=

122+github.com/prometheus/client_golang v1.24.1/go.mod h1:F+oSRECHg4sse5ucfYpYDeIv/hu68Zo0uoHKetWnzcE=

127123github.com/prometheus/client_model v0.6.2 h1:oBsgwpGs7iVziMvrGhE53c/GrLUsZdHnqNwqPLxwZyk=

128124github.com/prometheus/client_model v0.6.2/go.mod h1:y3m2F6Gdpfy6Ut/GBsUqTWZqCUvMVzSfMLjcu6wAwpE=

129−github.com/prometheus/common v0.65.0 h1:QDwzd+G1twt//Kwj/Ww6E9FQq1iVMmODnILtW1t2VzE=

130−github.com/prometheus/common v0.65.0/go.mod h1:0gZns+BLRQ3V6NdaerOhMbwwRbNh9hkGINtQAsP5GS8=

131−github.com/prometheus/procfs v0.17.0 h1:FuLQ+05u4ZI+SS/w9+BWEM2TXiHKsUQ9TADiRH7DuK0=

132−github.com/prometheus/procfs v0.17.0/go.mod h1:oPQLaDAMRbA+u8H5Pbfq+dl3VDAvHxMUOVhe0wYB2zw=

133−github.com/redis/go-redis/v9 v9.11.0 h1:E3S08Gl/nJNn5vkxd2i78wZxWAPNZgUNTp8WIJUAiIs=

134−github.com/redis/go-redis/v9 v9.11.0/go.mod h1:huWgSWd8mW6+m0VPhJjSSQ+d6Nh1VICQ6Q5lHuCH/Iw=

125+github.com/prometheus/common v0.70.1 h1:1HvjP4D5oL3t8RsPlwxA9onvvStjtIHYE5XuuwOi/PY=

126+github.com/prometheus/common v0.70.1/go.mod h1:VdFUQDMZK3VLkurFUVhia6uys/0suUp86TJz5qbJRhc=

127+github.com/prometheus/procfs v0.21.1 h1:GljZCt+zSTS+NZq88cyQ1LjZ+RCHp3uVuabBWA5+OJI=

128+github.com/prometheus/procfs v0.21.1/go.mod h1:aB55Cww9pdSJVHk0hUf0inxWyyjPogFIjmHKYgMKmtY=

129+github.com/redis/go-redis/v9 v9.22.0 h1:laDvpYXTJtZLloinw1fA5Kqd6HAEH2XKxOkG/PDq2F0=

130+github.com/redis/go-redis/v9 v9.22.0/go.mod h1:y2g0Wj8rQvuK0ELM+oxSudcLtC09JScs98I/X9gRWY4=

135131github.com/rogpeppe/go-internal v1.14.1 h1:UQB4HGPB6osV0SQTLymcB4TgvyWu6ZyliaW0tI/otEQ=

136132github.com/rogpeppe/go-internal v1.14.1/go.mod h1:MaRKkUm5W0goXpeCfT7UZI6fk/L7L7so1lCWt35ZSgc=

137−github.com/sagikazarmark/locafero v0.9.0 h1:GbgQGNtTrEmddYDSAH9QLRyfAHY12md+8YFTqyMTC9k=

138−github.com/sagikazarmark/locafero v0.9.0/go.mod h1:UBUyz37V+EdMS3hDF3QWIiVr/2dPrx49OMO0Bn0hJqk=

139−github.com/sourcegraph/conc v0.3.0 h1:OQTbbt6P72L20UqAkXXuLOj79LfEanQ+YQFNpLA9ySo=

140−github.com/sourcegraph/conc v0.3.0/go.mod h1:Sdozi7LEKbFPqYX2/J+iBAM6HpqSLTASQIKqDmF7Mt0=

141−github.com/spf13/afero v1.14.0 h1:9tH6MapGnn/j0eb0yIXiLjERO8RB6xIVZRDCX7PtqWA=

142−github.com/spf13/afero v1.14.0/go.mod h1:acJQ8t0ohCGuMN3O+Pv0V0hgMxNYDlvdk+VTfyZmbYo=

143−github.com/spf13/cast v1.9.2 h1:SsGfm7M8QOFtEzumm7UZrZdLLquNdzFYfIbEXntcFbE=

144−github.com/spf13/cast v1.9.2/go.mod h1:jNfB8QC9IA6ZuY2ZjDp0KtFO2LZZlg4S/7bzP6qqeHo=

145−github.com/spf13/pflag v1.0.6 h1:jFzHGLGAlb3ruxLB8MhbI6A8+AQX/2eW4qeyNZXNp2o=

146−github.com/spf13/pflag v1.0.6/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=

147−github.com/spf13/pflag v1.0.7 h1:vN6T9TfwStFPFM5XzjsvmzZkLuaLX+HS+0SeFLRgU6M=

148−github.com/spf13/pflag v1.0.7/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=

149−github.com/spf13/viper v1.20.1 h1:ZMi+z/lvLyPSCoNtFCpqjy0S4kPbirhpTMwl8BkW9X4=

150−github.com/spf13/viper v1.20.1/go.mod h1:P9Mdzt1zoHIG8m2eZQinpiBjo6kCmZSKBClNNqjJvu4=

133+github.com/sagikazarmark/locafero v0.12.0 h1:/NQhBAkUb4+fH1jivKHWusDYFjMOOKU88eegjfxfHb4=

134+github.com/sagikazarmark/locafero v0.12.0/go.mod h1:sZh36u/YSZ918v0Io+U9ogLYQJ9tLLBmM4eneO6WwsI=

135+github.com/spf13/afero v1.15.0 h1:b/YBCLWAJdFWJTN9cLhiXXcD7mzKn9Dm86dNnfyQw1I=

136+github.com/spf13/afero v1.15.0/go.mod h1:NC2ByUVxtQs4b3sIUphxK0NioZnmxgyCrfzeuq8lxMg=

137+github.com/spf13/cast v1.10.0 h1:h2x0u2shc1QuLHfxi+cTJvs30+ZAHOGRic8uyGTDWxY=

138+github.com/spf13/cast v1.10.0/go.mod h1:jNfB8QC9IA6ZuY2ZjDp0KtFO2LZZlg4S/7bzP6qqeHo=

139+github.com/spf13/pflag v1.0.10 h1:4EBh2KAYBwaONj6b2Ye1GiHfwjqyROoF4RwYO+vPwFk=

140+github.com/spf13/pflag v1.0.10/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=

141+github.com/spf13/viper v1.21.0 h1:x5S+0EU27Lbphp4UKm1C+1oQO+rKx36vfCoaVebLFSU=

142+github.com/spf13/viper v1.21.0/go.mod h1:P0lhsswPGWD/1lZJ9ny3fYnVqxiegrlNrEmgLjbTCAY=

151143github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=

152144github.com/stretchr/testify v1.7.0/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=

153−github.com/stretchr/testify v1.10.0 h1:Xv5erBjTwe/5IxqUQTdXv5kgmIvbHo3QQyRwhJsOfJA=

154−github.com/stretchr/testify v1.10.0/go.mod h1:r2ic/lqez/lEtzL7wO/rwa5dbSLXVDPFyf8C91i36aY=

145+github.com/stretchr/testify v1.12.0 h1:K6Mr6jO9JICuend/5xzTM03ydSV3vdNRYAdPSukj8uI=

146+github.com/stretchr/testify v1.12.0/go.mod h1:bOYBZb5qJ00vPzWfIqBUZPaxK8jWiXc6d3ErP4Ca9Gw=

155147github.com/subosito/gotenv v1.6.0 h1:9NlTDc1FTs4qu0DDq7AEtTPNw6SVm7uBMsUCUjABIf8=

156148github.com/subosito/gotenv v1.6.0/go.mod h1:Dk4QP5c2W3ibzajGcXpNraDfq2IrhjMIvMSWPKKo0FU=

149+github.com/tidwall/gjson v1.18.0 h1:FIDeeyB800efLX89e5a8Y0BNH+LOngJyGrIWxG2FKQY=

150+github.com/tidwall/gjson v1.18.0/go.mod h1:/wbyibRr2FHMks5tjHJ5F8dMZh3AcwJEMf5vlfC0lxk=

151+github.com/tidwall/match v1.1.1 h1:+Ho715JplO36QYgwN9PGYNhgZvoUSc9X2c80KVTi+GA=

152+github.com/tidwall/match v1.1.1/go.mod h1:eRSPERbgtNPcGhD8UCthc6PmLEQXEWd3PRB5JTxsfmM=

153+github.com/tidwall/pretty v1.2.1 h1:qjsOFOWWQl+N3RsoF5/ssm1pHmJJwhjlSbZ51I6wMl4=

154+github.com/tidwall/pretty v1.2.1/go.mod h1:ITEVvHYasfjBbM0u2Pg8T2nJnzm8xPwvNhhsoaGGjNU=

155+github.com/tidwall/sjson v1.2.5 h1:kLy8mja+1c9jlljvWTlSazM7cKDRfJuR/bOJhcY5NcY=

156+github.com/tidwall/sjson v1.2.5/go.mod h1:Fvgq9kS/6ociJEDnK0Fk1cpYF4FIW6ZF7LAe+6jwd28=

157157github.com/vmihailenco/msgpack/v5 v5.4.1 h1:cQriyiUvjTwOHg8QZaPihLWeRAAVoCpE00IUPn0Bjt8=

158158github.com/vmihailenco/msgpack/v5 v5.4.1/go.mod h1:GaZTsDaehaPpQVyxrf5mtQlH+pc21PIudVV/E3rRQok=

159159github.com/vmihailenco/tagparser/v2 v2.0.0 h1:y09buUbR+b5aycVFQs/g70pqKVZNBmxwAhO7/IwNM9g=

@@ -161,55 +161,57 @@ github.com/vmihailenco/tagparser/v2 v2.0.0/go.mod h1:Wri+At7QHww0WTrCBeu4J6bNtoV

161161github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY=

162162github.com/yuin/gopher-lua v0.0.0-20190206043414-8bfc7677f583/go.mod h1:gqRgreBUhTSL0GeU64rtZ3Uq3wtjOa/TB2YfrtkCbVQ=

163163github.com/yuin/gopher-lua v0.0.0-20191213034115-f46add6fdb5c/go.mod h1:gqRgreBUhTSL0GeU64rtZ3Uq3wtjOa/TB2YfrtkCbVQ=

164−github.com/yuin/gopher-lua v1.1.1 h1:kYKnWBjvbNP4XLT3+bPEwAXJx262OhaHDWDVOPjL46M=

165−github.com/yuin/gopher-lua v1.1.1/go.mod h1:GBR0iDaNXjAgGg9zfCvksxSRnQx76gclCIb7kdAd1Pw=

166−go.opentelemetry.io/auto/sdk v1.1.0 h1:cH53jehLUN6UFLY71z+NDOiNJqDdPRaXzTel0sJySYA=

167−go.opentelemetry.io/auto/sdk v1.1.0/go.mod h1:3wSPjt5PWp2RhlCcmmOial7AvC4DQqZb7a7wCow3W8A=

168−go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.61.0 h1:q4XOmH/0opmeuJtPsbFNivyl7bCt7yRBbeEm2sC/XtQ=

169−go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.61.0/go.mod h1:snMWehoOh2wsEwnvvwtDyFCxVeDAODenXHtn5vzrKjo=

170−go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.62.0 h1:Hf9xI/XLML9ElpiHVDNwvqI0hIFlzV8dgIr35kV1kRU=

171−go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.62.0/go.mod h1:NfchwuyNoMcZ5MLHwPrODwUF1HWCXWrL31s8gSAdIKY=

172−go.opentelemetry.io/otel v1.37.0 h1:9zhNfelUvx0KBfu/gb+ZgeAfAgtWrfHJZcAqFC228wQ=

173−go.opentelemetry.io/otel v1.37.0/go.mod h1:ehE/umFRLnuLa/vSccNq9oS1ErUlkkK71gMcN34UG8I=

174−go.opentelemetry.io/otel/metric v1.37.0 h1:mvwbQS5m0tbmqML4NqK+e3aDiO02vsf/WgbsdpcPoZE=

175−go.opentelemetry.io/otel/metric v1.37.0/go.mod h1:04wGrZurHYKOc+RKeye86GwKiTb9FKm1WHtO+4EVr2E=

176−go.opentelemetry.io/otel/sdk v1.37.0 h1:ItB0QUqnjesGRvNcmAcU0LyvkVyGJ2xftD29bWdDvKI=

177−go.opentelemetry.io/otel/sdk v1.37.0/go.mod h1:VredYzxUvuo2q3WRcDnKDjbdvmO0sCzOvVAiY+yUkAg=

178−go.opentelemetry.io/otel/sdk/metric v1.37.0 h1:90lI228XrB9jCMuSdA0673aubgRobVZFhbjxHHspCPc=

179−go.opentelemetry.io/otel/sdk/metric v1.37.0/go.mod h1:cNen4ZWfiD37l5NhS+Keb5RXVWZWpRE+9WyVCpbo5ps=

180−go.opentelemetry.io/otel/trace v1.37.0 h1:HLdcFNbRQBE2imdSEgm/kwqmQj1Or1l/7bW6mxVK7z4=

181−go.opentelemetry.io/otel/trace v1.37.0/go.mod h1:TlgrlQ+PtQO5XFerSPUYG0JSgGyryXewPGyayAWSBS0=

182−go.uber.org/automaxprocs v1.6.0 h1:O3y2/QNTOdbF+e/dpXNNW7Rx2hZ4sTIPyybbxyNqTUs=

183−go.uber.org/automaxprocs v1.6.0/go.mod h1:ifeIMSnPZuznNm6jmdzmU3/bfk01Fe2fotchwEFJ8r8=

184−go.uber.org/multierr v1.11.0 h1:blXXJkSxSSfBVBlC76pxqeO+LN3aDfLQo+309xJstO0=

185−go.uber.org/multierr v1.11.0/go.mod h1:20+QtiLqy0Nd6FdQB9TLXag12DsQkrbs3htMFfDN80Y=

164+github.com/yuin/gopher-lua v1.1.2 h1:yF/FjE3hD65tBbt0VXLE13HWS9h34fdzJmrWRXwobGA=

165+github.com/yuin/gopher-lua v1.1.2/go.mod h1:7aRmXIWl37SqRf0koeyylBEzJ+aPt8A+mmkQ4f1ntR8=

166+github.com/zeebo/xxh3 v1.1.0 h1:s7DLGDK45Dyfg7++yxI0khrfwq9661w9EN78eP/UZVs=

167+github.com/zeebo/xxh3 v1.1.0/go.mod h1:IisAie1LELR4xhVinxWS5+zf1lA4p0MW4T+w+W07F5s=

168+go.opentelemetry.io/auto/sdk v1.2.1 h1:jXsnJ4Lmnqd11kwkBV2LgLoFMZKizbCi5fNZ/ipaZ64=

169+go.opentelemetry.io/auto/sdk v1.2.1/go.mod h1:KRTj+aOaElaLi+wW1kO/DZRXwkF4C5xPbEe3ZiIhN7Y=

170+go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.67.0 h1:yI1/OhfEPy7J9eoa6Sj051C7n5dvpj0QX8g4sRchg04=

171+go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.67.0/go.mod h1:NoUCKYWK+3ecatC4HjkRktREheMeEtrXoQxrqYFeHSc=

172+go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.70.0 h1:LMuyCAyfalSjDyjdC65nK6N0zoTT63+E/u95X0JovZI=

173+go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.70.0/go.mod h1:085m8qbm4hgc8rZWGDEa4vmyyo2c3nPxUslYUKUIU04=

174+go.opentelemetry.io/otel v1.45.0 h1:pdrWmLHofpubmArBv1LgFSv1Z0Ie/ppdZzu+kUN5EeU=

175+go.opentelemetry.io/otel v1.45.0/go.mod h1:XZxIqPapzEYnhNSScF5DIqXhm/rYi0FzCe2XddAwZfQ=

176+go.opentelemetry.io/otel/metric v1.45.0 h1:7Eg1uH7CJ5cXv9is6tnBe1FI6rj1nwUdbFypRm3br/M=

177+go.opentelemetry.io/otel/metric v1.45.0/go.mod h1:HAPbm1nd3p1PmFH7v2dR+6BjXxw+Lq4a2+pndMAm08s=

178+go.opentelemetry.io/otel/sdk v1.45.0 h1:4VVSMgQ83dUgW2aoX5f6JgLvHwIvzcuLnF9lUdCSpCw=

179+go.opentelemetry.io/otel/sdk v1.45.0/go.mod h1:Sr40LgXV7DsKMMJMKOhUWOgMWTfAaqvm2kF0g7ilwuA=

180+go.opentelemetry.io/otel/sdk/metric v1.45.0 h1:oVFszMfyj1Am6s24Vtc7wBb8BKLcwepJjNEYILuiE3o=

181+go.opentelemetry.io/otel/sdk/metric v1.45.0/go.mod h1:vUWUxDZvu1WVRj8JA8S0AdhsPrZoDpA2DdZauIh4mDA=

182+go.opentelemetry.io/otel/trace v1.45.0 h1:l/mP6Uv7oNO7/TblbhpbgMidxhq1uO/rPsikOyVhxag=

183+go.opentelemetry.io/otel/trace v1.45.0/go.mod h1:qoJJA2xNMnxRrdISU/kLtfUH2wNeQbiv+jhs/CxI8bc=

184+go.uber.org/atomic v1.11.0 h1:ZvwS0R+56ePWxUNi+Atn9dWONBPp/AUETXlHW0DxSjE=

185+go.uber.org/atomic v1.11.0/go.mod h1:LUxbIzbOniOlMKjJjyPfpl4v+PKK2cNJn91OQbhoJI0=

186+go.uber.org/goleak v1.3.0 h1:2K3zAYmnTNqV73imy9J1T3WC+gmCePx2hEGkimedGto=

187+go.uber.org/goleak v1.3.0/go.mod h1:CoHD4mav9JJNrW/WLlf7HGZPjdw8EucARQHekz1X6bE=

188+go.yaml.in/yaml/v2 v2.4.4 h1:tuyd0P+2Ont/d6e2rl3be67goVK4R6deVxCUX5vyPaQ=

189+go.yaml.in/yaml/v2 v2.4.4/go.mod h1:gMZqIpDtDqOfM0uNfy0SkpRhvUryYH0Z6wdMYcacYXQ=

190+go.yaml.in/yaml/v3 v3.0.5 h1:N6y/pJk8buWs9NY5ERU2HSMfm+IuD/OtfdAnq6kESPw=

191+go.yaml.in/yaml/v3 v3.0.5/go.mod h1:HVTZu1O7/Vkt2N+BFy8Zza+lnLsABggaTM2ZpNIGuKg=

186192golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=

187193golang.org/x/crypto v0.0.0-20210921155107-089bfa567519/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc=

188194golang.org/x/crypto v0.19.0/go.mod h1:Iy9bg/ha4yyC70EfRS8jz+B6ybOBKMaSxLj6P6oBDfU=

189−golang.org/x/crypto v0.39.0 h1:SHs+kF4LP+f+p14esP5jAoDpHU8Gu/v9lFRK6IT5imM=

190−golang.org/x/crypto v0.39.0/go.mod h1:L+Xg3Wf6HoL4Bn4238Z6ft6KfEpN0tJGo53AAPC632U=

191−golang.org/x/crypto v0.40.0 h1:r4x+VvoG5Fm+eJcxMaY8CQM7Lb0l1lsmjGBQ6s8BfKM=

192−golang.org/x/crypto v0.40.0/go.mod h1:Qr1vMER5WyS2dfPHAlsOj01wgLbsyWtFn/aY+5+ZdxY=

195+golang.org/x/crypto v0.55.0 h1:+KWHjbgOaAQ66dh/YlkZKHlz9ZUlq61AFirAR9ntP8M=

196+golang.org/x/crypto v0.55.0/go.mod h1:uq0V9dE/fzQuJtbnL+2EhWOE63vo164FY8xqEnV9xis=

193197golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4/go.mod h1:jJ57K6gSWd91VN4djpZkiMVwK6gcyfeH4XE8wZrZaV4=

194198golang.org/x/mod v0.8.0/go.mod h1:iBbtSCu2XBx23ZKBPSOrRkjjQPZFPuis4dIYUhu/chs=

199+golang.org/x/mod v0.40.0 h1:hUv+3cXcdRHz08UmSiOob7sadHig73uo5bkXxQ/tvUs=

200+golang.org/x/mod v0.40.0/go.mod h1:0/weTWkPWGBikyTWAX3dkjVztMmBA5hM0DH6BElSupE=

195201golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=

196202golang.org/x/net v0.0.0-20210226172049-e18ecbb05110/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg=

197203golang.org/x/net v0.0.0-20220722155237-a158d28d115b/go.mod h1:XRhObCWvk6IyKnWLug+ECip1KBveYUHfp+8e9klMJ9c=

198204golang.org/x/net v0.6.0/go.mod h1:2Tu9+aMcznHK/AK1HMvgo6xiTLG5rD5rZLDS+rp2Bjs=

199205golang.org/x/net v0.10.0/go.mod h1:0qNGK6F8kojg2nk9dLZ2mShWaEBan6FAoqfSigmmuDg=

200−golang.org/x/net v0.41.0 h1:vBTly1HeNPEn3wtREYfy4GZ/NECgw2Cnl+nK6Nz3uvw=

201−golang.org/x/net v0.41.0/go.mod h1:B/K4NNqkfmg07DQYrbwvSluqCJOOXwUjeb/5lOisjbA=

202−golang.org/x/net v0.42.0 h1:jzkYrhi3YQWD6MLBJcsklgQsoAcw89EcZbJw8Z614hs=

203−golang.org/x/net v0.42.0/go.mod h1:FF1RA5d3u7nAYA4z2TkclSCKh68eSXtiFwcWQpPXdt8=

204−golang.org/x/oauth2 v0.30.0 h1:dnDm7JmhM45NNpd8FDDeLhK6FwqbOf4MLCM9zb1BOHI=

205−golang.org/x/oauth2 v0.30.0/go.mod h1:B++QgG3ZKulg6sRPGD/mqlHQs5rB3Ml9erfeDY7xKlU=

206+golang.org/x/net v0.58.0 h1:ynWG7rqYi4ccpTEuPZ2QGWHktVEM9DMCj9yzDE0Q7To=

207+golang.org/x/net v0.58.0/go.mod h1:YwCddHnFlT7eLQqVprV19OnhLGtc5xOKgE0RyqgfWAU=

208+golang.org/x/oauth2 v0.36.0 h1:peZ/1z27fi9hUOFCAZaHyrpWG5lwe0RJEEEeH0ThlIs=

209+golang.org/x/oauth2 v0.36.0/go.mod h1:YDBUJMTkDnJS+A4BP4eZBjCqtokkg1hODuPjwiGPO7Q=

206210golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=

207211golang.org/x/sync v0.0.0-20220722155255-886fb9371eb4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=

208212golang.org/x/sync v0.1.0/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=

209−golang.org/x/sync v0.15.0 h1:KWH3jNZsfyT6xfAfKiz6MRNmd46ByHDYaZ7KSkCtdW8=

210−golang.org/x/sync v0.15.0/go.mod h1:1dzgHSNfp02xaA81J2MS99Qcpr2w7fw1gpm99rleRqA=

211−golang.org/x/sync v0.16.0 h1:ycBJEhp9p4vXvUZNszeOq0kGTPghopOL8q0fq3vstxw=

212−golang.org/x/sync v0.16.0/go.mod h1:1dzgHSNfp02xaA81J2MS99Qcpr2w7fw1gpm99rleRqA=

213+golang.org/x/sync v0.22.0 h1:SZjpbeLmrCk4xhRSZFNZW5gFUeCeFgjekvI/+gfScek=

214+golang.org/x/sync v0.22.0/go.mod h1:9xrNwdLfx4jkKbNva9FpL6vEN7evnE43NNNJQ2LF3+0=

213215golang.org/x/sys v0.0.0-20190204203706-41f3e6584952/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=

214216golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=

215217golang.org/x/sys v0.0.0-20201119102817-f84b799fce68/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=

@@ -219,10 +221,8 @@ golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f/go.mod h1:oPkhp1MJrh7nUepCBc

219221golang.org/x/sys v0.5.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=

220222golang.org/x/sys v0.8.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=

221223golang.org/x/sys v0.17.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA=

222−golang.org/x/sys v0.33.0 h1:q3i8TbbEz+JRD9ywIRlyRAQbM0qF7hu24q3teo2hbuw=

223−golang.org/x/sys v0.33.0/go.mod h1:BJP2sWEmIv4KK5OTEluFJCKSidICx8ciO85XgH3Ak8k=

224−golang.org/x/sys v0.34.0 h1:H5Y5sJ2L2JRdyv7ROF1he/lPdvFsd0mJHFw2ThKHxLA=

225−golang.org/x/sys v0.34.0/go.mod h1:BJP2sWEmIv4KK5OTEluFJCKSidICx8ciO85XgH3Ak8k=

224+golang.org/x/sys v0.47.0 h1:o7XGOvZQCADBQQ4Y7VNq2dRWQR7JmOUW8Kxx4ZsNgWs=

225+golang.org/x/sys v0.47.0/go.mod h1:4GL1E5IUh+htKOUEOaiffhrAeqysfVGipDYzABqnCmw=

226226golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=

227227golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8=

228228golang.org/x/term v0.5.0/go.mod h1:jMB1sMXY+tzblOD4FWmEbocvup2/aLOaQEp7JmGp78k=

@@ -234,53 +234,38 @@ golang.org/x/text v0.3.7/go.mod h1:u+2+/6zg+i71rQMx5EYifcz6MCKuco9NR6JIITiCfzQ=

234234golang.org/x/text v0.7.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8=

235235golang.org/x/text v0.9.0/go.mod h1:e1OnstbJyHTd6l/uOt8jFFHp6TRDWZR/bV3emEE/zU8=

236236golang.org/x/text v0.14.0/go.mod h1:18ZOQIKpY8NJVqYksKHtTdi31H5itFRjB5/qKTNYzSU=

237−golang.org/x/text v0.26.0 h1:P42AVeLghgTYr4+xUnTRKDMqpar+PtX7KWuNQL21L8M=

238−golang.org/x/text v0.26.0/go.mod h1:QK15LZJUUQVJxhz7wXgxSy/CJaTFjd0G+YLonydOVQA=

239−golang.org/x/text v0.27.0 h1:4fGWRpyh641NLlecmyl4LOe6yDdfaYNrGb2zdfo4JV4=

240−golang.org/x/text v0.27.0/go.mod h1:1D28KMCvyooCX9hBiosv5Tz/+YLxj0j7XhWjpSUF7CU=

241−golang.org/x/time v0.12.0 h1:ScB/8o8olJvc+CQPWrK3fPZNfh7qgwCrY0zJmoEQLSE=

242−golang.org/x/time v0.12.0/go.mod h1:CDIdPxbZBQxdj6cxyCIdrNogrJKMJ7pr37NYpMcMDSg=

237+golang.org/x/text v0.41.0 h1:vz/seA0lnX87Othu2f/0L24RcgrXD9/YFTSuGjj3rH8=

238+golang.org/x/text v0.41.0/go.mod h1:jvf1O8ajNzZqhSrQBPbutR/EB83Cc0CFrezNQIwbb5M=

239+golang.org/x/time v0.15.0 h1:bbrp8t3bGUeFOx08pvsMYRTCVSMk89u4tKbNOZbp88U=

240+golang.org/x/time v0.15.0/go.mod h1:Y4YMaQmXwGQZoFaVFk4YpCt4FLQMYKZe9oeV/f4MSno=

243241golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=

244242golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=

245243golang.org/x/tools v0.1.12/go.mod h1:hNGJHUnrk76NpqgfD5Aqm5Crs+Hm0VOH/i9J2+nxYbc=

246244golang.org/x/tools v0.6.0/go.mod h1:Xwgl3UAJ/d3gWutnCtw505GrjyAbvKui8lOU390QaIU=

247−golang.org/x/tools v0.34.0 h1:qIpSLOxeCYGg9TrcJokLBG4KFA6d795g0xkBkiESGlo=

248−golang.org/x/tools v0.34.0/go.mod h1:pAP9OwEaY1CAW3HOmg3hLZC5Z0CCmzjAF2UQMSqNARg=

249−golang.org/x/tools v0.35.0 h1:mBffYraMEf7aa0sB+NuKnuCy8qI/9Bughn8dC2Gu5r0=

250−golang.org/x/tools v0.35.0/go.mod h1:NKdj5HkL/73byiZSJjqJgKn3ep7KjFkBOkR/Hps3VPw=

245+golang.org/x/tools v0.49.0 h1:3NI7VXzL9+1WZD52Dx2ttoPwD5DWrFGpl9mFZDlmisI=

246+golang.org/x/tools v0.49.0/go.mod h1:SJNXV9DBKT0UbdttsQjbfJlAE/q+y36++zo3uL3N0Oo=

251247golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=

252−google.golang.org/api v0.240.0 h1:PxG3AA2UIqT1ofIzWV2COM3j3JagKTKSwy7L6RHNXNU=

253−google.golang.org/api v0.240.0/go.mod h1:cOVEm2TpdAGHL2z+UwyS+kmlGr3bVWQQ6sYEqkKje50=

254−google.golang.org/api v0.241.0 h1:QKwqWQlkc6O895LchPEDUSYr22Xp3NCxpQRiWTB6avE=

255−google.golang.org/api v0.241.0/go.mod h1:cOVEm2TpdAGHL2z+UwyS+kmlGr3bVWQQ6sYEqkKje50=

256−google.golang.org/api v0.242.0 h1:7Lnb1nfnpvbkCiZek6IXKdJ0MFuAZNAJKQfA1ws62xg=

257−google.golang.org/api v0.242.0/go.mod h1:cOVEm2TpdAGHL2z+UwyS+kmlGr3bVWQQ6sYEqkKje50=

258−google.golang.org/genproto v0.0.0-20250505200425-f936aa4a68b2 h1:1tXaIXCracvtsRxSBsYDiSBN0cuJvM7QYW+MrpIRY78=

259−google.golang.org/genproto v0.0.0-20250505200425-f936aa4a68b2/go.mod h1:49MsLSx0oWMOZqcpB3uL8ZOkAh1+TndpJ8ONoCBWiZk=

260−google.golang.org/genproto v0.0.0-20250603155806-513f23925822 h1:rHWScKit0gvAPuOnu87KpaYtjK5zBMLcULh7gxkCXu4=

261−google.golang.org/genproto/googleapis/api v0.0.0-20250505200425-f936aa4a68b2 h1:vPV0tzlsK6EzEDHNNH5sa7Hs9bd7iXR7B1tSiPepkV0=

262−google.golang.org/genproto/googleapis/api v0.0.0-20250505200425-f936aa4a68b2/go.mod h1:pKLAc5OolXC3ViWGI62vvC0n10CpwAtRcTNCFwTKBEw=

263−google.golang.org/genproto/googleapis/api v0.0.0-20250603155806-513f23925822 h1:oWVWY3NzT7KJppx2UKhKmzPq4SRe0LdCijVRwvGeikY=

264−google.golang.org/genproto/googleapis/rpc v0.0.0-20250603155806-513f23925822 h1:fc6jSaCT0vBduLYZHYrBBNY4dsWuvgyff9noRNDdBeE=

265−google.golang.org/genproto/googleapis/rpc v0.0.0-20250603155806-513f23925822/go.mod h1:qQ0YXyHHx3XkvlzUtpXDkS29lDSafHMZBAZDc03LQ3A=

266−google.golang.org/genproto/googleapis/rpc v0.0.0-20250707201910-8d1bb00bc6a7 h1:pFyd6EwwL2TqFf8emdthzeX+gZE1ElRq3iM8pui4KBY=

267−google.golang.org/genproto/googleapis/rpc v0.0.0-20250707201910-8d1bb00bc6a7/go.mod h1:qQ0YXyHHx3XkvlzUtpXDkS29lDSafHMZBAZDc03LQ3A=

268−google.golang.org/grpc v1.73.0 h1:VIWSmpI2MegBtTuFt5/JWy2oXxtjJ/e89Z70ImfD2ok=

269−google.golang.org/grpc v1.73.0/go.mod h1:50sbHOUqWoCQGI8V2HQLJM0B+LMlIUjNSZmow7EVBQc=

270−google.golang.org/protobuf v1.36.6 h1:z1NpPI8ku2WgiWnf+t9wTPsn6eP1L7ksHUlkfLvd9xY=

271−google.golang.org/protobuf v1.36.6/go.mod h1:jduwjTPXsFjZGTmRluh+L6NjiWu7pchiJ2/5YcXBHnY=

248+gonum.org/v1/gonum v0.17.0 h1:VbpOemQlsSMrYmn7T2OUvQ4dqxQXU+ouZFQsZOx50z4=

249+gonum.org/v1/gonum v0.17.0/go.mod h1:El3tOrEuMpv2UdMrbNlKEh9vd86bmQ6vqIcDwxEOc1E=

250+google.golang.org/api v0.293.0 h1:p9XIWOf63U4OgYx120ZwVU8+vl4XTPmWfgVPnmOAS9w=

251+google.golang.org/api v0.293.0/go.mod h1:6n5tjEB1gzwniZTepZ0g5u+wM7Bof5GeULCx/zh8ZE0=

252+google.golang.org/genproto v0.0.0-20260319201613-d00831a3d3e7 h1:XzmzkmB14QhVhgnawEVsOn6OFsnpyxNPRY9QV01dNB0=

253+google.golang.org/genproto v0.0.0-20260319201613-d00831a3d3e7/go.mod h1:L43LFes82YgSonw6iTXTxXUX1OlULt4AQtkik4ULL/I=

254+google.golang.org/genproto/googleapis/api v0.0.0-20260630182238-925bb5da69e7 h1:jQ9p21COKWjP3VwuFrNRiiOTMh3mPpN45R7SLrH/HUU=

255+google.golang.org/genproto/googleapis/api v0.0.0-20260630182238-925bb5da69e7/go.mod h1:KqHwBx2upmfa1XSi1WuRvC+2VGCLtooKkfmyvRbUmqA=

256+google.golang.org/genproto/googleapis/rpc v0.0.0-20260817212433-ac3dfec99bb1 h1:utmqiUzZAEINbLmRyAt1QjVkMyLQ+lvIwCpLaB1rZfw=

257+google.golang.org/genproto/googleapis/rpc v0.0.0-20260817212433-ac3dfec99bb1/go.mod h1:4Hqkh8ycfw05ld/3BWL7rJOSfebL2Q+DVDeRgYgxUU8=

258+google.golang.org/grpc v1.83.0 h1:JeNZEKJFbQxArAMl+hiytHauacDNqJUllNfmIMmpqnQ=

259+google.golang.org/grpc v1.83.0/go.mod h1:kDyl6SKsiHKt0uylY5gtn5cEjkrIOhQOGDgIc4JGwzQ=

260+google.golang.org/protobuf v1.36.12 h1:pJOKDDOyeXErUroCihFAd5LQuwXBSpVnKGrj5o/fwxc=

261+google.golang.org/protobuf v1.36.12/go.mod h1:HTf+CrKn2C3g5S8VImy6tdcUvCska2kB7j23XfzDpco=

272262gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=

273263gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c h1:Hei/4ADfdWqJk1ZMxUNpqntNwaWcugrBjAiHlqqRiVk=

274264gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c/go.mod h1:JHkPIbrfpd72SG/EVd6muEfDQjcINNoR0C8j2r3qZ4Q=

275265gopkg.in/natefinch/lumberjack.v2 v2.2.1 h1:bBRl1b0OH9s/DuPhuXpNl+VtCaJXFZ5/uEFST95x9zc=

276266gopkg.in/natefinch/lumberjack.v2 v2.2.1/go.mod h1:YD8tP3GAjkrDg1eZH7EGmyESg/lsYskCTPBJVb9jqSc=

277−gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=

278−gopkg.in/yaml.v2 v2.4.0 h1:D8xgwECY7CYvx+Y2n4sBz93Jn9JRvxdiyyo8CTfuKaY=

279−gopkg.in/yaml.v2 v2.4.0/go.mod h1:RDklbk79AGWmwhnvt/jBztapEOGDOx6ZbXqjP6csGnQ=

280267gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=

281268gopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA=

282269gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=

283−k8s.io/apimachinery v0.33.2 h1:IHFVhqg59mb8PJWTLi8m1mAoepkUNYmptHsV+Z1m5jY=

284−k8s.io/apimachinery v0.33.2/go.mod h1:BHW0YOu7n22fFv/JkYOEfkUYNRN0fj0BlvMFWA7b+SM=

285−k8s.io/apimachinery v0.33.3 h1:4ZSrmNa0c/ZpZJhAgRdcsFcZOw1PQU1bALVQ0B3I5LA=

286−k8s.io/apimachinery v0.33.3/go.mod h1:BHW0YOu7n22fFv/JkYOEfkUYNRN0fj0BlvMFWA7b+SM=

270+k8s.io/apimachinery v0.36.3 h1:PkzMRBRG8joFD8EhCuQAtNPvJlxb82FwplP26HIzvAM=

271+k8s.io/apimachinery v0.36.3/go.mod h1:cTSjBWgPe/6CQyBKzY/hDIRWCQQQeK0mfLbml0UYFHE=

main.go+45−14

This diff is too big to show here.

main_test.go+161−54

This diff is too big to show here.

oauthproxy.go+68−31

This diff is too big to show here.

oauthproxy_test.go+411−70

This diff is too big to show here.

pkg/apis/middleware/scope.go+48−1

This diff is too big to show here.

pkg/apis/middleware/scope_test.go+34

This diff is too big to show here.

pkg/apis/middleware/session.go+5−1

This diff is too big to show here.

pkg/apis/options/alpha_options.go+22−15

This diff is too big to show here.

pkg/apis/options/common.godeleted−63

This diff is too big to show here.

pkg/apis/options/common_test.godeleted−87

This diff is too big to show here.

pkg/apis/options/cookie.go+3

This diff is too big to show here.

pkg/apis/options/doc.go+1−1

This diff is too big to show here.

pkg/apis/options/header.go+52−8

This diff is too big to show here.

pkg/apis/options/hooks.gonew file+57

This diff is too big to show here.

pkg/apis/options/hooks_test.gonew file+96

This diff is too big to show here.

pkg/apis/options/legacy_options.go+75−45

This diff is too big to show here.

pkg/apis/options/legacy_options_test.go+123−75

This diff is too big to show here.

pkg/apis/options/load.go+83−43

This diff is too big to show here.

pkg/apis/options/load_test.go+13−11

This diff is too big to show here.

pkg/apis/options/login_url_parameters.go+5−5

This diff is too big to show here.

pkg/apis/options/options.go+22

This diff is too big to show here.

pkg/apis/options/providers.go+205−71

This diff is too big to show here.

pkg/apis/options/secret_source.gonew file+19

This diff is too big to show here.

pkg/apis/options/server.go+16−7

This diff is too big to show here.

pkg/apis/options/upstreams.go+106−21

This diff is too big to show here.

pkg/apis/sessions/session_state.go+30−7

This diff is too big to show here.

pkg/apis/sessions/session_state_test.go+105−15

This diff is too big to show here.

pkg/app/redirect/director_test.go+33−2

This diff is too big to show here.

pkg/authentication/hmacauth/LICENSE.mdnew file+5

This diff is too big to show here.

pkg/authentication/hmacauth/hmacauth.gonew file+237

This diff is too big to show here.

pkg/authentication/hmacauth/hmacauth_test.gonew file+302

This diff is too big to show here.

pkg/clock/clock.godeleted−157

This diff is too big to show here.

pkg/clock/clock_suite_test.godeleted−17

This diff is too big to show here.

pkg/clock/clock_test.godeleted−380

This diff is too big to show here.

pkg/cookies/cookies.go+18−8

This diff is too big to show here.

pkg/cookies/cookies_suite_test.go+4

This diff is too big to show here.

pkg/cookies/cookies_test.go+39−51

This diff is too big to show here.

pkg/cookies/csrf.go+42−23

This diff is too big to show here.

pkg/cookies/csrf_per_request_test.go+17−12

This diff is too big to show here.

pkg/cookies/csrf_test.go+287−4

This diff is too big to show here.

pkg/ip/parse_ip_net.go+16

This diff is too big to show here.

pkg/ip/parse_ip_net_test.gonew file+118

This diff is too big to show here.

pkg/ip/realclientip.go+7−1

This diff is too big to show here.

pkg/ip/realclientip_test.go+4

This diff is too big to show here.

pkg/middleware/headers.go+40−5

This diff is too big to show here.

pkg/middleware/headers_test.go+49−4

This diff is too big to show here.

pkg/middleware/healthcheck.go+7−4

This diff is too big to show here.

pkg/middleware/healthcheck_test.go+31−9

This diff is too big to show here.

pkg/middleware/jwt_session_test.go+2−2

This diff is too big to show here.

pkg/middleware/redirect_to_https_test.go+15

This diff is too big to show here.

pkg/middleware/scope.go+5−3

This diff is too big to show here.

pkg/middleware/scope_test.go+18−4

This diff is too big to show here.

pkg/middleware/stored_session.go+46−2

This diff is too big to show here.

pkg/middleware/stored_session_test.go+66−10

This diff is too big to show here.

pkg/providers/oidc/provider_verifier.go+39−1

This diff is too big to show here.

pkg/providers/oidc/provider_verifier_test.go+92

This diff is too big to show here.

pkg/providers/util/claim_extractor.go+10−74

This diff is too big to show here.

pkg/providers/util/claim_extractor_test.go+2−53

This diff is too big to show here.

pkg/http/http_suite_test.go → pkg/proxyhttp/http_suite_test.gorenamed+1−1

This diff is too big to show here.

pkg/http/server.go → pkg/proxyhttp/server.gorenamed+51−3

This diff is too big to show here.

pkg/http/server_group.go → pkg/proxyhttp/server_group.gorenamed+1−1

This diff is too big to show here.

pkg/http/server_group_test.go → pkg/proxyhttp/server_group_test.gorenamed+1−1

This diff is too big to show here.

pkg/http/server_test.go → pkg/proxyhttp/server_test.gorenamed+51−1

This diff is too big to show here.

pkg/http/systemd_socket.go → pkg/proxyhttp/systemd_socket.gorenamed+1−1

This diff is too big to show here.

pkg/http/systemd_unsupported.go → pkg/proxyhttp/systemd_unsupported.gorenamed+1−1

This diff is too big to show here.

pkg/requests/builder_test.go+15−15

This diff is too big to show here.

pkg/requests/result_test.go+2−2

This diff is too big to show here.

pkg/requests/util/util.go+28−15

This diff is too big to show here.

pkg/requests/util/util_test.go+74−12

This diff is too big to show here.

pkg/sessions/cookie/session_store.go+23−13

This diff is too big to show here.

pkg/sessions/persistence/ticket.go+31−17

This diff is too big to show here.

pkg/sessions/redis/redis_store.go+15−8

This diff is too big to show here.

pkg/sessions/redis/redis_store_test.go+50

This diff is too big to show here.

pkg/sessions/tests/session_store_tests.go+48−1

This diff is too big to show here.

pkg/upstream/http.go+79−26

This diff is too big to show here.

pkg/upstream/http_test.go+141−33

This diff is too big to show here.

pkg/upstream/proxy.go+18−17

This diff is too big to show here.

pkg/upstream/proxy_test.go+39−6

This diff is too big to show here.

pkg/upstream/static.go+3−11

This diff is too big to show here.

pkg/upstream/upstream_suite_test.go+3−1

This diff is too big to show here.

pkg/util/ptr/ptr.gonew file+14

This diff is too big to show here.

pkg/util/ptr/ptr_test.gonew file+38

This diff is too big to show here.

pkg/util/util.go+64

This diff is too big to show here.

pkg/util/util_test.go+70

This diff is too big to show here.

pkg/validation/allowlist.go+13

This diff is too big to show here.

pkg/validation/allowlist_test.go+30

This diff is too big to show here.

pkg/validation/header.go+1

This diff is too big to show here.

pkg/validation/options.go+3−2

This diff is too big to show here.

pkg/validation/options_test.go+3−2

This diff is too big to show here.

pkg/validation/providers.go+39−4

This diff is too big to show here.

pkg/validation/providers_test.go+53

This diff is too big to show here.

pkg/validation/upstreams.go+10−8

This diff is too big to show here.

pkg/validation/upstreams_test.go+26−8

This diff is too big to show here.

providers/adfs.go+2−1

This diff is too big to show here.

providers/adfs_test.gomode 100755 → 100644+2−1

This diff is too big to show here.

providers/atlassian-cloud.gonew file+99

This diff is too big to show here.

providers/atlassian-cloud_test.gonew file+93

This diff is too big to show here.

providers/azure.go+3−2

This diff is too big to show here.

providers/dtt_sso.gonew file+202

This diff is too big to show here.

providers/dtt_sso_test.gonew file+237

This diff is too big to show here.

providers/github.go+30−6

This diff is too big to show here.

providers/google.go+79−10

This diff is too big to show here.

providers/google_test.go+80

This diff is too big to show here.

providers/internal_util.go+2−1

This diff is too big to show here.

providers/internal_util_test.go+6

This diff is too big to show here.

providers/keycloak_oidc.go+1

This diff is too big to show here.

providers/logingov.go+2−1

This diff is too big to show here.

providers/ms_entra_id.go+6−2

This diff is too big to show here.

providers/ms_entra_id_test.go+4−3

This diff is too big to show here.

providers/oidc.go+24−10

This diff is too big to show here.

providers/oidc_test.go+1−1

This diff is too big to show here.

providers/provider_data.go+44−5

This diff is too big to show here.

providers/provider_data_test.go+23

This diff is too big to show here.

providers/provider_default.go+3−1

This diff is too big to show here.

providers/provider_default_test.go+15−2

This diff is too big to show here.

providers/providers.go+14−7

This diff is too big to show here.

providers/providers_test.go+95−4

This diff is too big to show here.

providers/srht.go+2−1

This diff is too big to show here.

providers/util_test.go+33

This diff is too big to show here.

validator.go+4−1

This diff is too big to show here.

validator_test.go+21

This diff is too big to show here.