Compare commits

..

1 Commits

Author SHA1 Message Date
James Elliott 5013952bae
refactor: single quote yaml strings
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
2023-05-07 16:41:41 +10:00
376 changed files with 8616 additions and 21340 deletions

View File

@ -4,44 +4,44 @@
# secret leaks.
steps:
# Blocking pipeline for master branch deployments (concurrency_group).
- label: ":pipeline: Setup Pipeline"
command: ".buildkite/pipeline.sh | buildkite-agent pipeline upload"
- label: ':pipeline: Setup Pipeline'
command: '.buildkite/pipeline.sh | buildkite-agent pipeline upload'
concurrency: 1
concurrency_group: "deployments"
if: build.branch == "master"
concurrency_group: 'deployments'
if: 'build.branch == "master"'
# Non-blocking pipeline for all others (tagged commits/local branches/PRs).
- label: ":pipeline: Setup Pipeline"
command: ".buildkite/pipeline.sh | buildkite-agent pipeline upload"
if: build.branch != "master"
- label: ':pipeline: Setup Pipeline'
command: '.buildkite/pipeline.sh | buildkite-agent pipeline upload'
if: 'build.branch != "master"'
- wait: # yamllint disable-line rule:empty-values
if: build.pull_request.repository.fork != true && build.branch !~ /^(dependabot|renovate)\/.*/ && build.message !~ /^docs/ # yamllint disable-line rule:line-length
if: 'build.pull_request.repository.fork != true && build.branch !~ /^(dependabot|renovate)\/.*/ && build.message !~ /^docs/' # yamllint disable-line rule:line-length
# Manual intervention by team required to deploy for forked PRs (prevent secret leakage).
- block: "Public fork needs approval"
if: build.pull_request.repository.fork == true
- block: 'Public fork needs approval'
if: 'build.pull_request.repository.fork == true'
# Blocking deployment for master branch deployments (concurrency_group).
- label: ":rocket: Setup Deployment"
command: ".buildkite/deployment.sh | buildkite-agent pipeline upload"
- label: ':rocket: Setup Deployment'
command: '.buildkite/deployment.sh | buildkite-agent pipeline upload'
concurrency: 1
concurrency_group: "deployments"
depends_on: ~
if: build.branch == "master" && build.message !~ /^docs/
concurrency_group: 'deployments'
depends_on: '~'
if: 'build.branch == "master" && build.message !~ /^docs/'
# Non-blocking deployment for all others (tagged commits/local branches).
- label: ":rocket: Setup Deployment"
command: ".buildkite/deployment.sh | buildkite-agent pipeline upload"
- label: ':rocket: Setup Deployment'
command: '.buildkite/deployment.sh | buildkite-agent pipeline upload'
depends_on: ~
if: build.branch != "master" && build.branch !~ /^(dependabot|renovate)\/.*/ && build.message !~ /^docs/ && build.pull_request.repository.fork != true # yamllint disable-line rule:line-length
if: 'build.branch != "master" && build.branch !~ /^(dependabot|renovate)\/.*/ && build.message !~ /^docs/ && build.pull_request.repository.fork != true' # yamllint disable-line rule:line-length
# Removed dependency optimisation for forked PRs to enforce block step.
- label: ":rocket: Setup Deployment"
command: ".buildkite/deployment.sh | buildkite-agent pipeline upload"
if: build.message !~ /^docs/ && build.pull_request.repository.fork == true
- label: ':rocket: Setup Deployment'
command: '.buildkite/deployment.sh | buildkite-agent pipeline upload'
if: 'build.message !~ /^docs/ && build.pull_request.repository.fork == true'
notify:
- webhook: "<REDACTED WEBHOOK_URL>"
if: build.state == "blocked"
- webhook: '<REDACTED WEBHOOK_URL>'
if: 'build.state == "blocked"'
...

View File

@ -3,42 +3,42 @@ codecov:
require_ci_to_pass: true
comment:
layout: "reach, diff, flags, files"
behavior: default
layout: 'reach, diff, flags, files'
behavior: 'default'
require_changes: false
coverage:
precision: 2
round: down
range: "70...100"
round: 'down'
range: '70...100'
status:
project:
default: false
backend:
base: auto
threshold: 0.15%
base: 'auto'
threshold: '0.15%'
flags:
- backend
- 'backend'
frontend:
base: auto
threshold: 0.15%
base: 'auto'
threshold: '0.15%'
flags:
- frontend
- 'frontend'
flags:
backend:
paths:
- "cmd/authelia/"
- "internal/"
- "!internal/suites/"
- 'cmd/authelia/'
- 'internal/'
- '!internal/suites/'
frontend:
paths:
- "web/"
- "!web/coverage/"
- 'web/'
- '!web/coverage/'
ignore:
- "web/src/serviceWorker.ts"
- "**/coverage.txt"
- 'web/src/serviceWorker.ts'
- '**/coverage.txt'
parsers:
gcov:

View File

@ -7,4 +7,3 @@
!entrypoint.sh
!healthcheck.sh
!.healthcheck.env
!dist/public_html/

View File

@ -10,14 +10,14 @@
# the `language` matrix defined below to confirm you have the correct set of
# supported CodeQL languages.
#
name: "CodeQL"
name: 'CodeQL'
# yamllint disable-line rule:truthy
on:
push:
branches:
- master
- gh-pages
- 'master'
- 'gh-pages'
paths:
- 'go.mod'
- 'go.sum'
@ -29,7 +29,7 @@ on:
pull_request:
# The branches below must be a subset of the branches above
branches:
- master
- 'master'
paths:
- 'go.mod'
- 'go.sum'
@ -43,12 +43,12 @@ on:
jobs:
analyze:
name: Analyze
runs-on: ubuntu-latest
name: 'Analyze'
runs-on: 'ubuntu-latest'
permissions:
actions: read
contents: read
security-events: write
actions: 'read'
contents: 'read'
security-events: 'write'
strategy:
fail-fast: false
@ -59,23 +59,23 @@ jobs:
- 'javascript'
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: 'Checkout repository'
uses: 'actions/checkout@v3'
# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init@v1
- name: 'Initialize CodeQL'
uses: 'github/codeql-action/init@v1'
with:
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# queries: ./path/to/local/query, your-org/your-repo/queries@main
languages: ${{ matrix.language }}
languages: '${{ matrix.language }}'
# Autobuild attempts to build any compiled languages (C/C++, C#, or Java).
# If this step fails, then you should remove it and run the build manually (see below)
- name: Autobuild
uses: github/codeql-action/autobuild@v1
- name: 'Autobuild'
uses: 'github/codeql-action/autobuild@v1'
# Command-line programs to run using the OS shell.
# 📚 https://git.io/JvXDl
@ -88,6 +88,6 @@ jobs:
# make bootstrap
# make release
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v1
- name: 'Perform CodeQL Analysis'
uses: 'github/codeql-action/analyze@v1'
...

View File

@ -1,6 +1,6 @@
---
run:
timeout: 3m
timeout: '3m'
linters-settings:
goconst:
@ -11,40 +11,40 @@ linters-settings:
godot:
check-all: true
goimports:
local-prefixes: github.com/authelia/authelia
local-prefixes: 'github.com/authelia/authelia'
revive:
confidence: 0.8
linters:
enable:
- asciicheck
- goconst
- gocritic
- gocyclo
- godot
- gofmt
- goimports
- gosec
- misspell
- nolintlint
- prealloc
- revive
- unconvert
- unparam
- whitespace
- wsl
- 'asciicheck'
- 'goconst'
- 'gocritic'
- 'gocyclo'
- 'godot'
- 'gofmt'
- 'goimports'
- 'gosec'
- 'misspell'
- 'nolintlint'
- 'prealloc'
- 'revive'
- 'unconvert'
- 'unparam'
- 'whitespace'
- 'wsl'
issues:
exclude:
- Error return value of .((os\.)?std(out|err)\..*|.*Close|.*Flush|os\.Remove(All)?|.*printf?|os\.(Un)?Setenv). is not checked # yamllint disable-line rule:line-length
- func name will be used as test\.Test.* by other packages, and that stutters; consider calling this
- (possible misuse of unsafe.Pointer|should have signature)
- ineffective break statement. Did you mean to break out of the outer loop
- Use of unsafe calls should be audited
- Subprocess launch(ed with variable|ing should be audited)
- (G104|G307)
- (Expect directory permissions to be 0750 or less|Expect file permissions to be 0600 or less)
- Potential file inclusion via variable
- 'Error return value of .((os\.)?std(out|err)\..*|.*Close|.*Flush|os\.Remove(All)?|.*printf?|os\.(Un)?Setenv). is not checked' # yamllint disable-line rule:line-length
- 'func name will be used as test\.Test.* by other packages, and that stutters; consider calling this'
- '(possible misuse of unsafe.Pointer|should have signature)'
- 'ineffective break statement. Did you mean to break out of the outer loop'
- 'Use of unsafe calls should be audited'
- 'Subprocess launch(ed with variable|ing should be audited)'
- '(G104|G307)'
- '(Expect directory permissions to be 0750 or less|Expect file permissions to be 0600 or less)'
- 'Potential file inclusion via variable'
exclude-use-default: false
max-issues-per-linter: 0
max-same-issues: 0

View File

@ -1,19 +1,19 @@
---
runner:
golangci:
cmd: golangci-lint run
cmd: 'golangci-lint run'
errorformat:
- '%E%f:%l:%c: %m'
- '%E%f:%l: %m'
- '%C%.%#'
level: error
level: 'error'
eslint:
cmd: cd web && eslint -f rdjson '*/**/*.{js,ts,tsx}'
format: rdjson
level: error
cmd: 'cd web && eslint -f rdjson "*/**/*.{js,ts,tsx}"'
format: 'rdjson'
level: 'error'
yamllint:
cmd: yamllint --format parsable .
cmd: 'yamllint --format parsable .'
errorformat:
- '%f:%l:%c: %m'
level: warning
level: 'warning'
...

View File

@ -1,7 +1,7 @@
---
extends: default
extends: 'default'
locale: en_US.UTF-8
locale: 'en_US.UTF-8'
yaml-files:
- '*.yaml'
@ -19,13 +19,13 @@ ignore: |
.github/ISSUE_TEMPLATE/bug-report.yml
rules:
document-end:
level: warning
level: 'warning'
empty-values:
level: warning
level: 'warning'
indentation:
spaces: 2
check-multi-line-strings: true
line-length:
max: 120
octal-values: enable
octal-values: 'enable'
...

View File

@ -1,7 +1,7 @@
# ===================================
# ===== Authelia official image =====
# ===================================
FROM alpine:3.18.2
FROM alpine:3.17.3
ARG TARGETOS
ARG TARGETARCH

View File

@ -15,7 +15,7 @@ RUN yarn global add pnpm && \
# =======================================
# ===== Build image for the backend =====
# =======================================
FROM golang:1.20.5-alpine AS builder-backend
FROM golang:1.20.4-alpine AS builder-backend
WORKDIR /go/src/app
@ -46,7 +46,7 @@ RUN \
# ===================================
# ===== Authelia official image =====
# ===================================
FROM alpine:3.18.2
FROM alpine:3.17.3
RUN apk --no-cache add ca-certificates tzdata

View File

@ -13,7 +13,7 @@ RUN yarn install --frozen-lockfile && yarn build
# =======================================
# ===== Build image for the backend =====
# =======================================
FROM golang:1.20.5-alpine AS builder-backend
FROM golang:1.20.4-alpine AS builder-backend
WORKDIR /go/src/app
@ -43,7 +43,7 @@ RUN \
# ===================================
# ===== Authelia official image =====
# ===================================
FROM alpine:3.18.2
FROM alpine:3.17.3
WORKDIR /app

View File

@ -1,95 +0,0 @@
# Ausführen
Um die Anwendung lokal auszuführen, können die folgenden Befehle verwendet werden.
```
export GOPATH=/tmp
source bootstrap.sh
authelia-scripts suites setup Standalone
```
Nun sollte der "Haupt-Enpunkt" unter `https://home.example.com:8080` und die API unter `https://authelia.example.com:9091` erreichbar sein. Achtung: es wird ein selbstsigniertes Zertifikat verwendet!
Mithilfe der Hot-Reload kann jetzt gecoded werden.
---
Nach der Entwicklung kann die Testumgebung durch den folgenden Befehl wieder zurückgesetzt werden.
```
go run ./cmd/authelia-scripts/ suites teardown Standalone
```
## Benutzerdefinierte Zertifikate
Um ein benutzerdefiniertes Zertifikat für die Ausführung zu verwenden, muss die Datai `public.backend.crt` und `private.bakend.pem` unter [diesem](/internal/suites/common/pki/) Verzeichnis abgeändert werden.
Um die Gültigkeit zu testen, kann der folgendende Befehl ausgeführt werden.
```
curl https://auth.rpjosh.de:9091 --connect-to 'auth.rpjosh.de:9091:authelia.example.com:9091'
```
## Externe erreichbarkeit
Im aktuellen Zustand sind die Endpunkte nur unter den Docker internen IP-Adressen erreichbar. Daher muss noch ein NAT Regel angelegt werden.
```
ip=$(ping -c 1 authelia.example.com | gawk -F'[()]' '/PING/{print $2}')
sudo iptables -t nat -A PREROUTING -p tcp --dport 9091 -d 192.168.0.15 -j DNAT --to-destination 192.168.240.50:9091 -m comment --comment "Authelia-Test"
sudo iptables -t nat -A PREROUTING -p tcp --dport 9092 -d 192.168.0.15 -j DNAT --to-destination 192.168.240.50:9092 -m comment --comment "Authelia-Test"
sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 9091 -j DNAT --to-destination 192.168.240.50:9091
```
# Customizations
Für das Starten des *gRPC* Servers müssen die folgenden Abhängigkeiten installiert werden.
```
go get github.com/envoyproxy/go-control-plane
go get github.com/envoyproxy/go-control-plane/envoy/config/core/v3
go get github.com/gogo/googleapis/google/rpc
go get google.golang.org/grpc
```
## Konfiguration ändern
Wenn die Konfiguration geändert wurde, müssen die Keys zur Validierung wieder erneut gebaut werden.
```
go run ./cmd/authelia-gen code keys
```
## Mocks abgeändert
Wenn interfaces von den Mocks geändert werden, muss folgendes wieder ausgeführt werden:
```
export PATH=$PATH:$(go env GOPATH)/bin
go generate ./...
```
## Bauen
Um ein Docker Image für authelia zu bauen, müssen die folgenden Befehle ausgeführt werden.
```sh
# Dieser Befehle funktionieren aktuell nicht
authelia-scripts docker build
authelia-scripts build
# => Manuell bauen
export CC=musl-gcc
authelia-scripts build
cp -r dist/public_html internal/server/
go build -buildmode=pie -ldflags "-linkmode=external -s -w" -trimpath -buildmode=pie -o authelia ./cmd/authelia
mv authelia authelia-linux-amd64-musl
# Build docker image
docker build --tag git.rpjosh.de/rpjosh/authelia/authelia:4.38.0-dev .
docker push git.rpjosh.de/rpjosh/authelia/authelia:4.38.0-dev
# Cleanup
rm -rf internal/server/public_html/ ./authelia-linux-amd64-musl
```
# gRCP
Um einen gRCP Endpunkt nutzen zu können, brauch mein eine *.proto* Datei. Für Envoy sieht diese wie in [dieser Datei](/ext-auth.proto) folgendermaßen aus.

View File

@ -200,9 +200,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -213,9 +210,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -279,9 +273,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -292,9 +283,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -354,9 +342,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -367,9 +352,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -429,9 +411,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:

View File

@ -61,24 +61,6 @@ func rootSubCommandsRunE(cmd *cobra.Command, args []string) (err error) {
return err
}
subCmds := sortCmds(cmd)
for _, subCmd := range subCmds {
if subCmd.Use == cmdUseCompletion || strings.HasPrefix(subCmd.Use, "help ") || utils.IsStringSliceContainsAny([]string{resolveCmdName(subCmd), subCmd.Use}, exclude) {
continue
}
rootCmd.SetArgs(rootCmdGetArgs(subCmd, args))
if err = rootCmd.Execute(); err != nil {
return err
}
}
return nil
}
func sortCmds(cmd *cobra.Command) []*cobra.Command {
subCmds := cmd.Commands()
switch cmd.Use {
@ -108,7 +90,19 @@ func sortCmds(cmd *cobra.Command) []*cobra.Command {
})
}
return subCmds
for _, subCmd := range subCmds {
if subCmd.Use == cmdUseCompletion || strings.HasPrefix(subCmd.Use, "help ") || utils.IsStringSliceContainsAny([]string{resolveCmdName(subCmd), subCmd.Use}, exclude) {
continue
}
rootCmd.SetArgs(rootCmdGetArgs(subCmd, args))
if err = rootCmd.Execute(); err != nil {
return err
}
}
return nil
}
func resolveCmdName(cmd *cobra.Command) string {
@ -123,7 +117,7 @@ func resolveCmdName(cmd *cobra.Command) string {
func rootCmdGetArgs(cmd *cobra.Command, args []string) []string {
for {
if cmd == nil || cmd == rootCmd {
if cmd == rootCmd {
break
}

View File

@ -1,125 +0,0 @@
package main
import (
"testing"
"github.com/spf13/cobra"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func TestResolveCmdName(t *testing.T) {
testCases := []struct {
name string
have *cobra.Command
expected string
}{
{
"ShouldResolveRootCmd",
newRootCmd(),
"authelia-gen",
},
{
"ShouldResolveDocsCmd",
newDocsCmd(),
"docs",
},
{
"ShouldResolveDocsSubCmd",
newRootCmd().Commands()[0].Commands()[0],
"code.keys",
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expected, resolveCmdName(tc.have))
})
}
}
func TestRootCmdGetArgs(t *testing.T) {
testCases := []struct {
name string
have func() *cobra.Command
args []string
expected []string
}{
{
"ShouldReturnRootCmdArgs",
func() *cobra.Command {
cmd := newRootCmd()
cmd.SetArgs([]string{"a", "b"})
return cmd.Commands()[0]
},
[]string{"c", "d"},
[]string{"authelia-gen", "code", "c", "d"},
},
{
"ShouldReturnRootCmdWithoutArgs",
func() *cobra.Command {
cmd := newRootCmd()
return cmd.Commands()[0]
},
nil,
[]string{"authelia-gen", "code"},
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expected, rootCmdGetArgs(tc.have(), tc.args))
})
}
}
func TestSortCmds(t *testing.T) {
testCases := []struct {
name string
have *cobra.Command
expected []string
}{
{
"ShouldSortRootCmd",
newRootCmd(),
[]string{"code", "commit-lint", "github", "locales", "docs"},
},
{
"ShouldSortDocsCmd",
newDocsCmd(),
[]string{"cli", "data", "date"},
},
{
"ShouldSortGitHubCmd",
newGitHubCmd(),
[]string{"issue-templates"},
},
{
"ShouldSortLocalesCmd",
newLocalesCmd(),
nil,
},
{
"ShouldSortDocsDataCmd",
newDocsDataCmd(),
[]string{"keys", "misc"},
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
actual := sortCmds(tc.have)
n := len(tc.expected)
require.Len(t, actual, n)
for i := 0; i < n; i++ {
assert.Equal(t, tc.expected[i], actual[i].Use)
}
})
}
}

View File

@ -1,145 +0,0 @@
package main
import (
"net/mail"
"reflect"
"testing"
"github.com/spf13/pflag"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
"github.com/authelia/authelia/v4/internal/configuration/schema"
)
func TestGetPFlagPath(t *testing.T) {
testCases := []struct {
name string
have func(t *testing.T) *pflag.FlagSet
names []string
expected string
err string
}{
{
"ShouldFailEmptyFlagSet",
func(t *testing.T) *pflag.FlagSet {
return pflag.NewFlagSet("example", pflag.ContinueOnError)
},
[]string{"abc", "123"},
"",
"failed to lookup flag 'abc': flag accessed but not defined: abc",
},
{
"ShouldFailEmptyFlagNames",
func(t *testing.T) *pflag.FlagSet {
return pflag.NewFlagSet("example", pflag.ContinueOnError)
},
nil,
"",
"no flag names",
},
{
"ShouldLookupFlagNames",
func(t *testing.T) *pflag.FlagSet {
flagset := pflag.NewFlagSet("example", pflag.ContinueOnError)
flagset.String("dir.one", "", "")
flagset.String("dir.two", "", "")
flagset.String("file.name", "", "")
require.NoError(t, flagset.Parse([]string{"--dir.one=abc", "--dir.two=123", "--file.name=path.txt"}))
return flagset
},
[]string{"dir.one", "dir.two", "file.name"},
"abc/123/path.txt",
"",
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
actual, theError := getPFlagPath(tc.have(t), tc.names...)
if tc.err == "" {
assert.NoError(t, theError)
assert.Equal(t, tc.expected, actual)
} else {
assert.EqualError(t, theError, tc.err)
assert.Equal(t, "", actual)
}
})
}
}
func TestBuildCSP(t *testing.T) {
testCases := []struct {
name string
have string
ruleSets [][]CSPValue
expected string
}{
{
"ShouldParseDefault",
codeCSPProductionDefaultSrc,
[][]CSPValue{
codeCSPValuesCommon,
codeCSPValuesProduction,
},
"default-src 'self'; frame-src 'none'; object-src 'none'; style-src 'self' 'nonce-%s'; frame-ancestors 'none'; base-uri 'self'",
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expected, buildCSP(tc.have, tc.ruleSets...))
})
}
}
func TestContainsType(t *testing.T) {
astring := ""
testCases := []struct {
name string
have any
expected bool
}{
{
"ShouldContainMailAddress",
mail.Address{},
true,
},
{
"ShouldContainSchemaAddressPtr",
&schema.Address{},
true,
},
{
"ShouldNotContainString",
astring,
false,
},
{
"ShouldNotContainStringPtr",
&astring,
false,
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expected, containsType(reflect.TypeOf(tc.have), decodedTypes))
})
}
}
func TestReadTags(t *testing.T) {
assert.NotPanics(t, func() {
readTags("", reflect.TypeOf(schema.Configuration{}), false)
})
assert.NotPanics(t, func() {
readTags("", reflect.TypeOf(schema.Configuration{}), true)
})
}

View File

@ -1,13 +0,0 @@
package main
import (
"testing"
"github.com/stretchr/testify/assert"
)
func TestShouldFailToLoadBadTemplate(t *testing.T) {
assert.Panics(t, func() {
mustLoadTmplFS("bad tmpl")
})
}

View File

@ -120,11 +120,6 @@ const (
labelAreaPrefixStatus = "status"
)
type label interface {
String() string
LabelDescription() string
}
type labelPriority int
//nolint:deadcode,varcheck // Kept for future use.
@ -134,7 +129,6 @@ const (
labelPriorityMedium
labelPriorityNormal
labelPriorityLow
labelPriorityVeryLow
)
var labelPriorityDescriptions = [...]string{
@ -143,15 +137,14 @@ var labelPriorityDescriptions = [...]string{
"Medium",
"Normal",
"Low",
"Very Low",
}
func (l labelPriority) String() string {
return fmt.Sprintf("%s/%d/%s", labelAreaPrefixPriority, l+1, labelFormatString(labelPriorityDescriptions[l]))
func (p labelPriority) String() string {
return fmt.Sprintf("%s/%d/%s", labelAreaPrefixPriority, p+1, strings.ToLower(labelPriorityDescriptions[p]))
}
func (l labelPriority) LabelDescription() string {
return labelPriorityDescriptions[l]
func (p labelPriority) Description() string {
return labelPriorityDescriptions[p]
}
type labelStatus int
@ -162,16 +155,12 @@ const (
)
var labelStatusDescriptions = [...]string{
"Needs Design",
"Needs Triage",
"needs-design",
"needs-triage",
}
func (l labelStatus) String() string {
return fmt.Sprintf("%s/%s", labelAreaPrefixStatus, labelFormatString(labelStatusDescriptions[l]))
}
func (l labelStatus) LabelDescription() string {
return labelStatusDescriptions[l]
func (s labelStatus) String() string {
return fmt.Sprintf("%s/%s", labelAreaPrefixStatus, labelStatusDescriptions[s])
}
type labelType int
@ -184,24 +173,13 @@ const (
)
var labelTypeDescriptions = [...]string{
"Feature",
"Bug: Unconfirmed",
"Bug",
"feature",
"bug/unconfirmed",
"bug",
}
func (l labelType) String() string {
return fmt.Sprintf("%s/%s", labelAreaPrefixType, labelFormatString(labelTypeDescriptions[l]))
}
func (l labelType) LabelDescription() string {
return labelTypeDescriptions[l]
}
func labelFormatString(in string) string {
in = strings.ReplaceAll(in, ": ", "/")
in = strings.ReplaceAll(in, " ", "-")
return strings.ToLower(in)
func (t labelType) String() string {
return fmt.Sprintf("%s/%s", labelAreaPrefixType, labelTypeDescriptions[t])
}
// CSPValue represents individual CSP values.

View File

@ -1,90 +0,0 @@
package main
import (
"testing"
"github.com/stretchr/testify/assert"
)
func TestLabels(t *testing.T) {
testCases := []struct {
name string
have label
expectedDescription string
expectedString string
}{
{
"ShouldShowCorrectPriorityCriticalValues",
labelPriorityCritical,
"Critical",
"priority/1/critical",
},
{
"ShouldShowCorrectPriorityHighValues",
labelPriorityHigh,
"High",
"priority/2/high",
},
{
"ShouldShowCorrectPriorityMediumValues",
labelPriorityMedium,
"Medium",
"priority/3/medium",
},
{
"ShouldShowCorrectPriorityNormalValues",
labelPriorityNormal,
"Normal",
"priority/4/normal",
},
{
"ShouldShowCorrectPriorityLowValues",
labelPriorityLow,
"Low",
"priority/5/low",
},
{
"ShouldShowCorrectPriorityVeryLowValues",
labelPriorityVeryLow,
"Very Low",
"priority/6/very-low",
},
{
"ShouldShowCorrectStatusNeedsDesignValues",
labelStatusNeedsDesign,
"Needs Design",
"status/needs-design",
},
{
"ShouldShowCorrectStatusNeedsTriageValues",
labelStatusNeedsTriage,
"Needs Triage",
"status/needs-triage",
},
{
"ShouldShowCorrectTypeFeatureValues",
labelTypeFeature,
"Feature",
"type/feature",
},
{
"ShouldShowCorrectTypeBugUnconfirmedValues",
labelTypeBugUnconfirmed,
"Bug: Unconfirmed",
"type/bug/unconfirmed",
},
{
"ShouldShowCorrectTypeBugValues",
labelTypeBug,
"Bug",
"type/bug",
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expectedString, tc.have.String())
assert.Equal(t, tc.expectedDescription, tc.have.LabelDescription())
})
}
}

View File

@ -7,5 +7,5 @@
package cmd
const (
versionSwaggerUI = "5.0.0"
versionSwaggerUI = "4.18.3"
)

File diff suppressed because it is too large Load Diff

View File

@ -1 +1 @@
baseurl = "https://authelia-next.netlify.app/"
baseurl = "https://authelia-staging.netlify.app/"

View File

@ -31,14 +31,14 @@ with all major proxies supported excluding Microsoft IIS.
[Envoy]: https://www.envoyproxy.io/
[Istio]: https://istio.io/
## OpenID Connect 1.0 Improvements
## OpenID Connect Improvements
Several items from the [OpenID Connect 1.0 Roadmap](../../roadmap/active/openid-connect.md) are being checked off in this
Several items from the [OpenID Connect Roadmap](../../roadmap/active/openid-connect.md) are being checked off in this
release.
### Hashed Client Secrets
We'll be supporting hashed OpenID Connect 1.0 client secrets in this release. People will still be able to use plaintext
We'll be supporting hashed OpenID Connect client secrets in this release. People will still be able to use plaintext
secrets if they wish however we'll be recommending people utilize PBKDF2, BCrypt or SHA512 SHA2CRYPT (see
[Password Algorithms](#password-algorithms) for a full compatibility list). This doesn't change anything for OpenID
Connect Relying Parties, it only requires a change in the Authelia configuration.

View File

@ -101,20 +101,16 @@ authentication_backend:
base_dn: 'DC=example,DC=com'
additional_users_dn: 'OU=users'
users_filter: '(&({username_attribute}={input})(objectClass=person))'
username_attribute: 'uid'
mail_attribute: 'mail'
display_name_attribute: 'displayName'
additional_groups_dn: 'OU=groups'
groups_filter: '(&(member={dn})(objectClass=groupOfNames))'
group_search_mode: 'filter'
group_name_attribute: 'cn'
permit_referrals: false
permit_unauthenticated_bind: false
user: 'CN=admin,DC=example,DC=com'
password: 'password'
attributes:
distinguished_name: 'distinguishedName'
username: 'uid'
display_name: 'displayName'
mail: 'mail'
member_of: 'memberOf'
group_name: 'cn'
```
## Options
@ -125,8 +121,8 @@ This section describes the individual configuration options.
{{< confkey type="string" required="yes" >}}
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
*__Reference Note:__ This configuration option uses the [Address](../prologue/common.md#address) format. Please see the
[documentation](../prologue/common.md#address) on this format for more information.*
The LDAP URL which consists of a scheme, hostname, and port. Format is `[<scheme>://]<hostname>[:<port>]`. The default
scheme is `ldapi` if the path is absolute otherwise it's `ldaps`, and the permitted schemes are `ldap`, `ldaps`, or
@ -177,11 +173,8 @@ URL's are slightly more secure.
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
Controls the TLS connection validation parameters for either StartTLS or the TLS socket.
Controls the TLS connection validation process. You can see how to configure the tls
section [here](../prologue/common.md#tls-configuration).
### base_dn
@ -213,33 +206,66 @@ The LDAP filter to narrow down which users are valid. This is important to set c
The default value is dependent on the [implementation](#implementation), refer to the
[attribute defaults](../../reference/guides/ldap.md#attribute-defaults) for more information.
### username_attribute
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults](../../reference/guides/ldap.md#attribute-defaults)
for more information.*
The LDAP attribute that maps to the username in *Authelia*. This must contain the `{username_attribute}`
[placeholder](../../reference/guides/ldap.md#users-filter-replacements).
### mail_attribute
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults](../../reference/guides/ldap.md#attribute-defaults)
for more information.*
The attribute to retrieve which contains the users email addresses. This is important for the device registration and
password reset processes. The user must have an email address in order for Authelia to perform identity verification
when a user attempts to reset their password or register a second factor device.
### display_name_attribute
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults](#attribute-defaults) for more information.*
The attribute to retrieve which is shown on the Web UI to the user when they log in.
### additional_groups_dn
{{< confkey type="string" required="no" >}}
Similar to [additional_users_dn](#additionalusersdn) but it applies to group searches.
Similar to [additional_users_dn](#additional_users_dn) but it applies to group searches.
### groups_filter
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [filter defaults](../../reference/guides/ldap.md#filter-defaults) for
more information.*
default negating this requirement. Refer to the [filter defaults](#filter-defaults) for more information.*
Similar to [users_filter](#usersfilter) but it applies to group searches. In order to include groups the member is not
Similar to [users_filter](#users_filter) but it applies to group searches. In order to include groups the member is not
a direct member of, but is a member of another group that is a member of those (i.e. recursive groups), you may try
using the following filter which is currently only tested against Microsoft Active Directory:
`(&(member:1.2.840.113556.1.4.1941:={dn})(objectClass=group)(objectCategory=group))`
### group_search_mode
### group_name_attribute
{{< confkey type="string" default="filter" required="no" >}}
{{< confkey type="string" required="situational" >}}
The group search mode controls how user groups are discovered. The default of `filter` directly uses the filter to
determine the result. The `memberof` experimental mode does another special filtered search. See the
[Reference Documentation](../../reference/guides/ldap.md#group-search-modes) for more information.
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults](#attribute-defaults) for more
information.*
The LDAP attribute that is used by Authelia to determine the group name.
### permit_referrals
@ -284,71 +310,6 @@ It's __strongly recommended__ this is a
[Random Alphanumeric String](../../reference/guides/generating-secure-values.md#generating-a-random-alphanumeric-string) with 64 or more
characters and the user password is changed to this value.
### attributes
The following options configure The directory server attribute mappings.
#### distinguished_name
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically not required however it is required when using the group search mode
`memberof` replacement `{memberof:dn}`.*
The directory server attribute which contains the distinguished name, primarily used to perform filtered searches. There
is a clear distinction between the actual distinguished name and a distinguished name attribute, all directories have
distinguished names for objects, but not all have an attribute representing this that can be searched on.
The only known support at this time is with Active Directory.
#### username
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute that maps to the username in *Authelia*. This must contain the `{username_attribute}` [placeholder].
#### display_name
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute to retrieve which is shown on the Web UI to the user when they log in.
#### mail
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute to retrieve which contains the users email addresses. This is important for the device
registration and password reset processes. The user must have an email address in order for Authelia to perform
identity verification when a user attempts to reset their password or register a second factor device.
#### member_of
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute which contains the groups a user is a member of. This is currently only used for the
`memberof` group search mode.
#### group_name
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute that is used by Authelia to determine the group name.
## Refresh Interval
It's recommended you either use the default [refresh interval](introduction.md#refreshinterval) or configure this to
@ -368,8 +329,6 @@ for your users.
- [LDAP Reference Guide](../../reference/guides/ldap.md)
[username attribute]: #username
[username attribute]: #usernameattribute
[TechNet wiki]: https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx
[RFC2307]: https://datatracker.ietf.org/doc/html/rfc2307
[attribute defaults]: ../../reference/guides/ldap.md#attribute-defaults
[placeholder]: ../../reference/guides/ldap.md#users-filter-replacements

View File

@ -14,6 +14,6 @@ aliases:
- /docs/configuration/identity-providers/
---
## OpenID Connect 1.0
## OpenID Connect
The only identity provider implementation supported at this time is [OpenID Connect 1.0](openid-connect/provider.md).
The only identity provider implementation supported at this time is [OpenID Connect 1.0](open-id-connect.md).

View File

@ -0,0 +1,616 @@
---
title: "OpenID Connect"
description: "OpenID Connect Configuration"
lead: "Authelia can operate as an OpenID Connect 1.0 Provider. This section describes how to configure this."
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
menu:
configuration:
parent: "identity-providers"
weight: 190200
toc: true
aliases:
- /c/oidc
- /docs/configuration/identity-providers/oidc.html
---
__Authelia__ currently supports the [OpenID Connect 1.0] Provider role as an open
[__beta__](../../roadmap/active/openid-connect.md) feature. We currently do not support the [OpenID Connect 1.0] Relying
Party role. This means other applications that implement the [OpenID Connect 1.0] Relying Party role can use Authelia as
an [OpenID Connect 1.0] Provider similar to how you may use social media or development platforms for login.
The [OpenID Connect 1.0] Relying Party role is the role which allows an application to use GitHub, Google, or other
[OpenID Connect 1.0] Providers for authentication and authorization. We do not intend to support this functionality at
this moment in time.
More information about the beta can be found in the [roadmap](../../roadmap/active/openid-connect.md).
## Configuration
{{< config-alert-example >}}
```yaml
identity_providers:
oidc:
hmac_secret: 'this_is_a_secret_abc123abc123abc'
issuer_certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIC5jCCAc6gAwIBAgIRAK4Sj7FiN6PXo/urPfO4E7owDQYJKoZIhvcNAQELBQAw
EzERMA8GA1UEChMIQXV0aGVsaWEwHhcNNzAwMTAxMDAwMDAwWhcNNzEwMTAxMDAw
MDAwWjATMREwDwYDVQQKEwhBdXRoZWxpYTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAPKv3pSyP4ozGEiVLJ14dIWFCEGEgq7WUMI0SZZqQA2ID0L59U/Q
/Usyy7uC9gfMUzODTpANtkOjFQcQAsxlR1FOjVBrX5QgjSvXwbQn3DtwMA7XWSl6
LuYx2rBYSlMSN5UZQm/RxMtXfLK2b51WgEEYDFi+nECSqKzR4R54eOPkBEWRfvuY
91AMjlhpivg8e4JWkq4LVQUKbmiFYwIdK8XQiN4blY9WwXwJFYs5sQ/UYMwBFi0H
kWOh7GEjfxgoUOPauIueZSMSlQp7zqAH39N0ZSYb6cS0Npj57QoWZSY3ak87ebcR
Nf4rCvZLby7LoN7qYCKxmCaDD3x2+NYpWH8CAwEAAaM1MDMwDgYDVR0PAQH/BAQD
AgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN
AQELBQADggEBAHSITqIQSNzonFl3DzxHPEzr2hp6peo45buAAtu8FZHoA+U7Icfh
/ZXjPg7Xz+hgFwM/DTNGXkMWacQA/PaNWvZspgRJf2AXvNbMSs2UQODr7Tbv+Fb4
lyblmMUNYFMCFVAMU0eIxXAFq2qcwv8UMcQFT0Z/35s6PVOakYnAGGQjTfp5Ljuq
wsdc/xWmM0cHWube6sdRRUD7SY20KU/kWzl8iFO0VbSSrDf1AlEhnLEkp1SPaxXg
OdBnl98MeoramNiJ7NT6Jnyb3zZ578fjaWfThiBpagItI8GZmG4s4Ovh2JbheN8i
ZsjNr9jqHTjhyLVbDRlmJzcqoj4JhbKs6/I^invalid DO NOT USE=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDBDCCAeygAwIBAgIRALJsPg21kA0zY4F1wUCIuoMwDQYJKoZIhvcNAQELBQAw
EzERMA8GA1UEChMIQXV0aGVsaWEwHhcNNzAwMTAxMDAwMDAwWhcNNzEwMTAxMDAw
MDAwWjATMREwDwYDVQQKEwhBdXRoZWxpYTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMXHBvVxUzYk0u34/DINMSF+uiOekKOAjOrC6Mi9Ww8ytPVO7t2S
zfTvM+XnEJqkFQFgimERfG/eGhjF9XIEY6LtnXe8ATvOK4nTwdufzBaoeQu3Gd50
5VXr6OHRo//ErrGvFXwP3g8xLePABsi/fkH3oDN+ztewOBMDzpd+KgTrk8ysv2ou
kNRMKFZZqASvCgv0LD5KWvUCnL6wgf1oTXG7aztduA4oSkUP321GpOmBC5+5ElU7
ysoRzvD12o9QJ/IfEaulIX06w9yVMo60C/h6A3U6GdkT1SiyTIqR7v7KU/IWd/Qi
Lfftcj91VhCmJ73Meff2e2S2PrpjdXbG5FMCAwEAAaNTMFEwDgYDVR0PAQH/BAQD
AgKkMA8GA1UdJQQIMAYGBFUdJQAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU
Z7AtA3mzFc0InSBA5fiMfeLXA3owDQYJKoZIhvcNAQELBQADggEBAEE5hm1mtlk/
kviCoHH4evbpw7rxPxDftIQlqYTtvMM4eWY/6icFoSZ4fUHEWYyps8SsPu/8f2tf
71LGgZn0FdHi1QU2H8m0HHK7TFw+5Q6RLrLdSyk0PItJ71s9en7r8pX820nAFEHZ
HkOSfJZ7B5hFgUDkMtVM6bardXAhoqcMk4YCU96e9d4PB4eI+xGc+mNuYvov3RbB
D0s8ICyojeyPVLerz4wHjZu68Z5frAzhZ68YbzNs8j2fIBKKHkHyLG1iQyF+LJVj
2PjCP+auJsj6fQQpMGoyGtpLcSDh+ptcTngUD8JsWipzTCjmaNqdPHAOYmcgtf4b
qocikt3WAdU^invalid DO NOT USE=
-----END CERTIFICATE-----
issuer_private_key: |
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA8q/elLI/ijMYSJUsnXh0hYUIQYSCrtZQwjRJlmpADYgPQvn1
T9D9SzLLu4L2B8xTM4NOkA22Q6MVBxACzGVHUU6NUGtflCCNK9fBtCfcO3AwDtdZ
KXou5jHasFhKUxI3lRlCb9HEy1d8srZvnVaAQRgMWL6cQJKorNHhHnh44+QERZF+
+5j3UAyOWGmK+Dx7glaSrgtVBQpuaIVjAh0rxdCI3huVj1bBfAkVizmxD9RgzAEW
LQeRY6HsYSN/GChQ49q4i55lIxKVCnvOoAff03RlJhvpxLQ2mPntChZlJjdqTzt5
txE1/isK9ktvLsug3upgIrGYJoMPfHb41ilYfwIDAQABAoIBAQDTOdFf2JjHH1um
aPgRAvNf9v7Nj5jytaRKs5nM6iNf46ls4QPreXnMhqSeSwj6lpNgBYxOgzC9Q+cc
Y4ob/paJJPaIJTxmP8K/gyWcOQlNToL1l+eJ20eQoZm23NGr5fIsunSBwLEpTrdB
ENqqtcwhW937K8Pxy/Q1nuLyU2bc6Tn/ivLozc8n27dpQWWKh8537VY7ancIaACr
LJJLYxKqhQpjtBWAyCDvZQirnAOm9KnvIHaGXIswCZ4Xbsu0Y9NL+woARPyRVQvG
jfxy4EmO9s1s6y7OObSukwKDSNihAKHx/VIbvVWx8g2Lv5fGOa+J2Y7o9Qurs8t5
BQwMTt0BAoGBAPUw5Z32EszNepAeV3E2mPFUc5CLiqAxagZJuNDO2pKtyN29ETTR
Ma4O1cWtGb6RqcNNN/Iukfkdk27Q5nC9VJSUUPYelOLc1WYOoUf6oKRzE72dkMQV
R4bf6TkjD+OVR17fAfkswkGahZ5XA7j48KIQ+YC4jbnYKSxZTYyKPjH/AoGBAP1i
tqXt36OVlP+y84wWqZSjMelBIVa9phDVGJmmhz3i1cMni8eLpJzWecA3pfnG6Tm9
ze5M4whASleEt+M00gEvNaU9ND+z0wBfi+/DwJYIbv8PQdGrBiZFrPhTPjGQUldR
lXccV2meeLZv7TagVxSi3DO6dSJfSEHyemd5j9mBAoGAX8Hv+0gOQZQCSOTAq8Nx
6dZcp9gHlNaXnMsP9eTDckOSzh636JPGvj6m+GPJSSbkURUIQ3oyokMNwFqvlNos
fTaLhAOfjBZI9WnDTTQxpugWjphJ4HqbC67JC/qIiw5S6FdaEvGLEEoD4zoChywZ
9oGAn+fz2d/0/JAH/FpFPgsCgYEAp/ipZgPzziiZ9ov1wbdAQcWRj7RaWnssPFpX
jXwEiXT3CgEMO4MJ4+KWIWOChrti3qFBg6i6lDyyS6Qyls7sLFbUdC7HlTcrOEMe
rBoTcCI1GqZNlqWOVQ65ZIEiaI7o1vPBZo2GMQEZuq8mDKFsOMThvvTrM5cAep84
n6HJR4ECgYABWcbsSnr0MKvVth/inxjbKapbZnp2HUCuw87Ie5zK2Of/tbC20wwk
yKw3vrGoE3O1t1g2m2tn8UGGASeZ842jZWjIODdSi5+icysQGuULKt86h/woz2SQ
27GoE2i5mh6Yez6VAYbUuns3FcwIsMyWLq043Tu2DNkx9ijOOAuQzw^invalid..
DO NOT USE==
-----END RSA PRIVATE KEY-----
access_token_lifespan: '1h'
authorize_code_lifespan: '1m'
id_token_lifespan: '1h'
refresh_token_lifespan: '90m'
enable_client_debug_messages: false
enforce_pkce: 'public_clients_only'
cors:
endpoints:
- 'authorization'
- 'token'
- 'revocation'
- 'introspection'
allowed_origins:
- 'https://example.com'
allowed_origins_from_client_redirect_uris: false
clients:
- id: 'myapp'
description: 'My Application'
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
sector_identifier: ''
public: false
authorization_policy: 'two_factor'
consent_mode: 'explicit'
pre_configured_consent_duration: '1w'
audience: []
scopes:
- 'openid'
- 'groups'
- 'email'
- 'profile'
redirect_uris:
- 'https://oidc.example.com:8080/oauth2/callback'
grant_types:
- 'refresh_token'
- 'authorization_code'
response_types:
- 'code'
response_modes:
- 'form_post'
- 'query'
- 'fragment'
userinfo_signing_algorithm: 'none'
```
## Options
This section describes the individual configuration options.
### hmac_secret
{{< confkey type="string" required="yes" >}}
*__Important Note:__ This can also be defined using a [secret](../methods/secrets.md) which is __strongly recommended__
especially for containerized deployments.*
The HMAC secret used to sign the [JWT]'s. The provided string is hashed to a SHA256 ([RFC6234]) byte string for the
purpose of meeting the required format.
It's __strongly recommended__ this is a
[Random Alphanumeric String](../../reference/guides/generating-secure-values.md#generating-a-random-alphanumeric-string)
with 64 or more characters.
### issuer_certificate_chain
{{< confkey type="string" required="no" >}}
The certificate chain/bundle to be used with the [issuer_private_key](#issuer_private_key) DER base64 ([RFC4648])
encoded PEM format used to sign/encrypt the [OpenID Connect 1.0] [JWT]'s. When configured it enables the [x5c] and [x5t]
JSON key's in the JWKs [Discoverable Endpoint](../../integration/openid-connect/introduction.md#discoverable-endpoints)
as per [RFC7517].
[RFC7517]: https://datatracker.ietf.org/doc/html/rfc7517
[x5c]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.7
[x5t]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.8
The first certificate in the chain must have the public key for the [issuer_private_key](#issuerprivatekey), each
certificate in the chain must be valid for the current date, and each certificate in the chain should be signed by the
certificate immediately following it if present.
### issuer_private_key
{{< confkey type="string" required="yes" >}}
*__Important Note:__ This can also be defined using a [secret](../methods/secrets.md) which is __strongly recommended__
especially for containerized deployments.*
The private key used to sign/encrypt the [OpenID Connect 1.0] issued [JWT]'s. The key must be generated by the administrator
and can be done by following the
[Generating an RSA Keypair](../../reference/guides/generating-secure-values.md#generating-an-rsa-keypair) guide.
The private key *__MUST__*:
* Be a PEM block encoded in the DER base64 format ([RFC4648]).
* Be an RSA Key.
* Have a key size of at least 2048 bits.
If the [issuer_certificate_chain](#issuercertificatechain) is provided the private key must include matching public
key data for the first certificate in the chain.
### access_token_lifespan
{{< confkey type="duration" default="1h" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
The maximum lifetime of an access token. It's generally recommended keeping this short similar to the default.
For more information read these docs about [token lifespan].
### authorize_code_lifespan
{{< confkey type="duration" default="1m" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
The maximum lifetime of an authorize code. This can be rather short, as the authorize code should only be needed to
obtain the other token types. For more information read these docs about [token lifespan].
### id_token_lifespan
{{< confkey type="duration" default="1h" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
The maximum lifetime of an ID token. For more information read these docs about [token lifespan].
### refresh_token_lifespan
{{< confkey type="string" default="90m" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
The maximum lifetime of a refresh token. The
refresh token can be used to obtain new refresh tokens as well as access tokens or id tokens with an
up-to-date expiration. For more information read these docs about [token lifespan].
A good starting point is 50% more or 30 minutes more (which ever is less) time than the highest lifespan out of the
[access token lifespan](#access_token_lifespan), the [authorize code lifespan](#authorize_code_lifespan), and the
[id token lifespan](#id_token_lifespan). For instance the default for all of these is 60 minutes, so the default refresh
token lifespan is 90 minutes.
### enable_client_debug_messages
{{< confkey type="boolean" default="false" required="no" >}}
Allows additional debug messages to be sent to the clients.
### minimum_parameter_entropy
{{< confkey type="integer" default="8" required="no" >}}
This controls the minimum length of the `nonce` and `state` parameters.
*__Security Notice:__* Changing this value is generally discouraged, reducing it from the default can theoretically
make certain scenarios less secure. It is highly encouraged that if your OpenID Connect RP does not send these
parameters or sends parameters with a lower length than the default that they implement a change rather than changing
this value.
### enforce_pkce
{{< confkey type="string" default="public_clients_only" required="no" >}}
[Proof Key for Code Exchange](https://datatracker.ietf.org/doc/html/rfc7636) enforcement policy: if specified, must be
either `never`, `public_clients_only` or `always`.
If set to `public_clients_only` (default), [PKCE] will be required for public clients using the
[Authorization Code Flow].
When set to `always`, [PKCE] will be required for all clients using the Authorization Code flow.
*__Security Notice:__* Changing this value to `never` is generally discouraged, reducing it from the default can
theoretically make certain client-side applications (mobile applications, SPA) vulnerable to CSRF and authorization code
interception attacks.
### enable_pkce_plain_challenge
{{< confkey type="boolean" default="false" required="no" >}}
Allows [PKCE] `plain` challenges when set to `true`.
*__Security Notice:__* Changing this value is generally discouraged. Applications should use the `S256` [PKCE] challenge
method instead.
### pushed_authorizations
Controls the behaviour of [Pushed Authorization Requests].
#### enforce
{{< confkey type="boolean" default="false" required="no" >}}
When enabled all authorization requests must use the [Pushed Authorization Requests] flow.
#### context_lifespan
{{< confkey type="duration" default="5m" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
The maximum amount of time between the [Pushed Authorization Requests] flow being initiated and the generated
`request_uri` being utilized by a client.
### cors
Some [OpenID Connect 1.0] Endpoints need to allow cross-origin resource sharing, however some are optional. This section allows
you to configure the optional parts. We reply with CORS headers when the request includes the Origin header.
#### endpoints
{{< confkey type="list(string)" required="no" >}}
A list of endpoints to configure with cross-origin resource sharing headers. It is recommended that the `userinfo`
option is at least in this list. The potential endpoints which this can be enabled on are as follows:
* authorization
* pushed-authorization-request
* token
* revocation
* introspection
* userinfo
#### allowed_origins
{{< confkey type="list(string)" required="no" >}}
A list of permitted origins.
Any origin with https is permitted unless this option is configured or the
[allowed_origins_from_client_redirect_uris](#allowed_origins_from_client_redirect_uris) option is enabled. This means
you must configure this option manually if you want http endpoints to be permitted to make cross-origin requests to the
[OpenID Connect 1.0] endpoints, however this is not recommended.
Origins must only have the scheme, hostname and port, they may not have a trailing slash or path.
In addition to an Origin URI, you may specify the wildcard origin in the allowed_origins. It MUST be specified by itself
and the [allowed_origins_from_client_redirect_uris](#allowedoriginsfromclientredirecturis) MUST NOT be enabled. The
wildcard origin is denoted as `*`. Examples:
```yaml
identity_providers:
oidc:
cors:
allowed_origins: "*"
```
```yaml
identity_providers:
oidc:
cors:
allowed_origins:
- "*"
```
#### allowed_origins_from_client_redirect_uris
{{< confkey type="boolean" default="false" required="no" >}}
Automatically adds the origin portion of all redirect URI's on all clients to the list of
[allowed_origins](#allowed_origins), provided they have the scheme http or https and do not have the hostname of
localhost.
### clients
{{< confkey type="list" required="yes" >}}
A list of clients to configure. The options for each client are described below.
#### id
{{< confkey type="string" required="yes" >}}
The Client ID for this client. It must exactly match the Client ID configured in the application
consuming this client.
#### description
{{< confkey type="string" default="*same as id*" required="no" >}}
A friendly description for this client shown in the UI. This defaults to the same as the ID.
#### secret
{{< confkey type="string" required="situational" >}}
The shared secret between Authelia and the application consuming this client. This secret must match the secret
configured in the application.
This secret must be generated by the administrator and can be done by following the
[How Do I Generate Client Secrets](../../integration/openid-connect/frequently-asked-questions.md#how-do-i-generate-client-secrets) FAQ.
This must be provided when the client is a confidential client type, and must be blank when using the public client
type. To set the client type to public see the [public](#public) configuration option.
#### sector_identifier
{{< confkey type="string" required="no" >}}
*__Important Note:__ because adjusting this option will inevitably change the `sub` claim of all tokens generated for
the specified client, changing this should cause the relying party to detect all future authorizations as completely new
users.*
Must be an empty string or the host component of a URL. This is commonly just the domain name, but may also include a
port.
Authelia utilizes UUID version 4 subject identifiers. By default the public [Subject Identifier Type] is utilized for
all clients. This means the subject identifiers will be the same for all clients. This configuration option enables
[Pairwise Identifier Algorithm] for this client, and configures the sector identifier utilized for both the storage and
the lookup of the subject identifier.
1. All clients who do not have this configured will generate the same subject identifier for a particular user
regardless of which client obtains the ID token.
2. All clients which have the same sector identifier will:
1. have the same subject identifier for a particular user when compared to clients with the same sector identifier.
2. have a completely different subject identifier for a particular user whe compared to:
1. any client with the public subject identifier type.
2. any client with a differing sector identifier.
In specific but limited scenarios this option is beneficial for privacy reasons. In particular this is useful when the
party utilizing the *Authelia* [OpenID Connect 1.0] Authorization Server is foreign and not controlled by the user. It would
prevent the third party utilizing the subject identifier with another third party in order to track the user.
Keep in mind depending on the other claims they may still be able to perform this tracking and it is not a silver
bullet. There are very few benefits when utilizing this in a homelab or business where no third party is utilizing
the server.
#### public
{{< confkey type="bool" default="false" required="no" >}}
This enables the public client type for this client. This is for clients that are not capable of maintaining
confidentiality of credentials, you can read more about client types in [RFC6749 Section 2.1]. This is particularly
useful for SPA's and CLI tools. This option requires setting the [client secret](#secret) to a blank string.
#### redirect_uris
{{< confkey type="list(string)" required="yes" >}}
A list of valid callback URIs this client will redirect to. All other callbacks will be considered unsafe. The URIs are
case-sensitive and they differ from application to application - the community has provided
[a list of URL´s for common applications](../../integration/openid-connect/introduction.md).
Some restrictions that have been placed on clients and
their redirect URIs are as follows:
1. If a client attempts to authorize with Authelia and its redirect URI is not listed in the client configuration the
attempt to authorize will fail and an error will be generated.
2. The redirect URIs are case-sensitive.
3. The URI must include a scheme and that scheme must be one of `http` or `https`.
#### audience
{{< confkey type="list(string)" required="no" >}}
A list of audiences this client is allowed to request.
#### scopes
{{< confkey type="list(string)" default="openid, groups, profile, email" required="no" >}}
A list of scopes to allow this client to consume. See
[scope definitions](../../integration/openid-connect/introduction.md#scope-definitions) for more information. The
documentation for the application you are trying to configure [OpenID Connect 1.0] for will likely have a list of scopes
or claims required which can be matched with the above guide.
#### response_types
{{< confkey type="list(string)" default="code" required="no" >}}
*__Security Note:__ It is recommended that only the `code` response type (i.e. the default) is used. The other response
types are not as secure as this response type.*
A list of response types this client supports. If a response type not in this list is requested by a client then an
error will be returned to the client. The response type indicates the types of values that are returned to the client.
See the [Response Types](../../integration/openid-connect/introduction.md#response-types) section of the
[OpenID Connect 1.0 Integration Guide](../../integration/openid-connect/introduction.md#response-types) for more information.
#### response_modes
{{< confkey type="list(string)" default="form_post, query" required="no" >}}
*__Important Note:__ It is recommended that this isn't configured at this time unless you know what you're doing.*
A list of response modes this client supports. If a response mode not in this list is requested by a client then an
error will be returned to the client. The response mode controls how the response type is returned to the client.
See the [Response Modes](../../integration/openid-connect/introduction.md#response-modes) section of the
[OpenID Connect 1.0 Integration Guide](../../integration/openid-connect/introduction.md#response-modes) for more
information.
The default values are based on the [response_types](#responsetypes) values. When the [response_types](#responsetypes)
values include the `code` type then the `query` response mode will be included. When any other type is included the
`fragment` response mode will be included. It's important to note at this time we do not support the `none` response
type, but when it is supported it will include the `query` response mode.
#### grant_types
{{< confkey type="list(string)" default="authorization_code" required="no" >}}
*__Important Note:__ It is recommended that this isn't configured at this time unless you know what you're doing.*
The list of grant types this client is permitted to use in order to obtain access to the relevant tokens.
See the [Grant Types](../../integration/openid-connect/introduction.md#grant-types) section of the
[OpenID Connect 1.0 Integration Guide](../../integration/openid-connect/introduction.md#grant-types) for more information.
#### authorization_policy
{{< confkey type="string" default="two_factor" required="no" >}}
The authorization policy for this client: either `one_factor` or `two_factor`.
#### enforce_par
{{< confkey type="boolean" default="false" required="no" >}}
Enforces the use of a [Pushed Authorization Requests] flow for this client.
#### enforce_pkce
{{< confkey type="bool" default="false" required="no" >}}
This setting enforces the use of [PKCE] for this individual client. To enforce it for all clients see the global
[enforce_pkce](#enforcepkce) setting.
#### pkce_challenge_method
{{< confkey type="string" default="" required="no" >}}
This setting enforces the use of the specified [PKCE] challenge method for this individual client. This setting also
effectively enables the [enforce_pkce](#enforcepkce-1) option for this client.
Valid values are an empty string, `plain`, or `S256`. It should be noted that `S256` is strongly recommended if the
relying party supports it.
#### userinfo_signing_algorithm
{{< confkey type="string" default="none" required="no" >}}
The algorithm used to sign the userinfo endpoint responses. This can either be `none` or `RS256`.
See the [integration guide](../../integration/openid-connect/introduction.md#user-information-signing-algorithm) for
more information.
#### token_endpoint_auth_method
{{< confkey type="string" default="" required="no" >}}
The registered client authentication mechanism used by this client for the [Token Endpoint]. If no method is defined
the confidential client type will accept any supported method. The public client type defaults to `none` as this
is required by the specification. This may be required as a breaking change in future versions.
Supported values are `client_secret_basic`, `client_secret_post`, and `none`.
See the [integration guide](../../integration/openid-connect/introduction.md#client-authentication-method) for
more information.
#### consent_mode
{{< confkey type="string" default="auto" required="no" >}}
*__Important Note:__ the `implicit` consent mode is not technically part of the specification. It theoretically could be
misused in certain conditions specifically with the public client type or when the client credentials (i.e. client
secret) has been exposed to an attacker. For these reasons this mode is discouraged.*
Configures the consent mode. The following table describes the different modes:
| Value | Description |
|:--------------:|:----------------------------------------------------------------------------------------------------------------------------------------------:|
| auto | Automatically determined (default). Uses `explicit` unless [pre_configured_consent_duration] is specified in which case uses `pre-configured`. |
| explicit | Requires the user provide unique explicit consent for every authorization. |
| implicit | Automatically assumes consent for every authorization, never asking the user if they wish to give consent. |
| pre-configured | Allows the end-user to remember their consent for the [pre_configured_consent_duration]. |
[pre_configured_consent_duration]: #preconfiguredconsentduration
#### pre_configured_consent_duration
{{< confkey type="duration" default="1w" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
Specifying this in the configuration without a consent [consent_mode] enables the `pre-configured` mode. If this is
specified as well as the [consent_mode] then it only has an effect if the [consent_mode] is `pre-configured` or `auto`.
The period of time dictates how long a users choice to remember the pre-configured consent lasts.
Pre-configured consents are only valid if the subject, client id are exactly the same and the requested scopes/audience
match exactly with the granted scopes/audience.
[consent_mode]: #consentmode
## Integration
To integrate Authelia's [OpenID Connect 1.0] implementation with a relying party please see the
[integration docs](../../integration/openid-connect/introduction.md).
[token lifespan]: https://docs.apigee.com/api-platform/antipatterns/oauth-long-expiration
[OpenID Connect 1.0]: https://openid.net/connect/
[Token Endpoint]: https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint
[JWT]: https://datatracker.ietf.org/doc/html/rfc7519
[RFC6234]: https://datatracker.ietf.org/doc/html/rfc6234
[RFC4648]: https://datatracker.ietf.org/doc/html/rfc4648
[RFC7468]: https://datatracker.ietf.org/doc/html/rfc7468
[RFC6749 Section 2.1]: https://datatracker.ietf.org/doc/html/rfc6749#section-2.1
[PKCE]: https://datatracker.ietf.org/doc/html/rfc7636
[Authorization Code Flow]: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
[Subject Identifier Type]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[Pairwise Identifier Algorithm]: https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
[Pushed Authorization Requests]: https://datatracker.ietf.org/doc/html/rfc9126

View File

@ -1,15 +0,0 @@
---
title: "OpenID Connect 1.0"
description: ""
lead: ""
date: 2023-05-15T10:32:10+10:00
lastmod: 2022-01-18T20:07:56+01:00
draft: false
images: []
menu:
docs:
parent: "identity-providers"
identifier: "openid-connect"
weight: 190120
toc: true
---

View File

@ -1,469 +0,0 @@
---
title: "OpenID Connect 1.0 Clients"
description: "OpenID Connect 1.0 Registered Clients Configuration"
lead: "Authelia can operate as an OpenID Connect 1.0 Provider. This section describes how to configure the registered clients."
date: 2023-05-15T10:32:10+10:00
draft: false
images: []
menu:
configuration:
parent: "openid-connect"
weight: 190220
toc: true
---
This section covers specifics regarding configuring the providers registered clients for [OpenID Connect 1.0]. For the
provider specific configuration and information not related to clients see the [OpenID Connect 1.0 Provider](provider.md)
documentation.
More information about OpenID Connect 1.0 can be found in the [roadmap](../../../roadmap/active/openid-connect.md) and
in the [integration](../../../integration/openid-connect/introduction.md) documentation.
## Configuration
The following snippet provides a configuration example for the [OpenID Connect 1.0] Registered Clients. This is not
intended for production use it's used to provide context and an indentation example.
```yaml
identity_providers:
oidc:
clients:
- id: 'myapp'
description: 'My Application'
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
sector_identifier: ''
public: false
redirect_uris:
- 'https://oidc.example.com:8080/oauth2/callback'
audience: []
scopes:
- 'openid'
- 'groups'
- 'email'
- 'profile'
grant_types:
- 'refresh_token'
- 'authorization_code'
response_types:
- 'code'
response_modes:
- 'form_post'
- 'query'
- 'fragment'
authorization_policy: 'two_factor'
consent_mode: 'explicit'
pre_configured_consent_duration: '1 week'
enforce_par: false
enforce_pkce: false
pkce_challenge_method: 'S256'
id_token_signing_alg: 'RS256'
id_token_signing_key_id: ''
userinfo_signing_alg: 'none'
userinfo_signing_key_id: ''
request_object_signing_alg: 'RS256'
token_endpoint_auth_signing_alg: 'RS256'
token_endpoint_auth_method: ''
```
## Options
### id
{{< confkey type="string" required="yes" >}}
The Client ID for this client. It must exactly match the Client ID configured in the application consuming this client.
### description
{{< confkey type="string" default="*same as id*" required="no" >}}
A friendly description for this client shown in the UI. This defaults to the same as the ID.
### secret
{{< confkey type="string" required="situational" >}}
The shared secret between Authelia and the application consuming this client. This secret must match the secret
configured in the application.
This secret must be generated by the administrator and can be done by following the
[How Do I Generate Client Secrets](../../../integration/openid-connect/frequently-asked-questions.md#how-do-i-generate-client-secrets) FAQ.
This must be provided when the client is a confidential client type, and must be blank when using the public client
type. To set the client type to public see the [public](#public) configuration option.
### sector_identifier
{{< confkey type="string" required="no" >}}
*__Important Note:__ because adjusting this option will inevitably change the `sub` claim of all tokens generated for
the specified client, changing this should cause the relying party to detect all future authorizations as completely new
users.*
Must be an empty string or the host component of a URL. This is commonly just the domain name, but may also include a
port.
Authelia utilizes UUID version 4 subject identifiers. By default the public [Subject Identifier Type] is utilized for
all clients. This means the subject identifiers will be the same for all clients. This configuration option enables
[Pairwise Identifier Algorithm] for this client, and configures the sector identifier utilized for both the storage and
the lookup of the subject identifier.
1. All clients who do not have this configured will generate the same subject identifier for a particular user
regardless of which client obtains the ID token.
2. All clients which have the same sector identifier will:
1. have the same subject identifier for a particular user when compared to clients with the same sector identifier.
2. have a completely different subject identifier for a particular user whe compared to:
1. any client with the public subject identifier type.
2. any client with a differing sector identifier.
In specific but limited scenarios this option is beneficial for privacy reasons. In particular this is useful when the
party utilizing the *Authelia* [OpenID Connect 1.0] Authorization Server is foreign and not controlled by the user. It would
prevent the third party utilizing the subject identifier with another third party in order to track the user.
Keep in mind depending on the other claims they may still be able to perform this tracking and it is not a silver
bullet. There are very few benefits when utilizing this in a homelab or business where no third party is utilizing
the server.
### public
{{< confkey type="bool" default="false" required="no" >}}
This enables the public client type for this client. This is for clients that are not capable of maintaining
confidentiality of credentials, you can read more about client types in [RFC6749 Section 2.1]. This is particularly
useful for SPA's and CLI tools. This option requires setting the [client secret](#secret) to a blank string.
### redirect_uris
{{< confkey type="list(string)" required="yes" >}}
A list of valid callback URIs this client will redirect to. All other callbacks will be considered unsafe. The URIs are
case-sensitive and they differ from application to application - the community has provided
[a list of URL´s for common applications](../../../integration/openid-connect/introduction.md).
Some restrictions that have been placed on clients and
their redirect URIs are as follows:
1. If a client attempts to authorize with Authelia and its redirect URI is not listed in the client configuration the
attempt to authorize will fail and an error will be generated.
2. The redirect URIs are case-sensitive.
3. The URI must include a scheme and that scheme must be one of `http` or `https`.
### audience
{{< confkey type="list(string)" required="no" >}}
A list of audiences this client is allowed to request.
### scopes
{{< confkey type="list(string)" default="openid, groups, profile, email" required="no" >}}
A list of scopes to allow this client to consume. See
[scope definitions](../../../integration/openid-connect/introduction.md#scope-definitions) for more information. The
documentation for the application you are trying to configure [OpenID Connect 1.0] for will likely have a list of scopes
or claims required which can be matched with the above guide.
### grant_types
{{< confkey type="list(string)" default="authorization_code" required="no" >}}
*__Important Note:__ It is recommended that this isn't configured at this time unless you know what you're doing.*
The list of grant types this client is permitted to use in order to obtain access to the relevant tokens.
See the [Grant Types](../../../integration/openid-connect/introduction.md#grant-types) section of the
[OpenID Connect 1.0 Integration Guide](../../../integration/openid-connect/introduction.md#grant-types) for more information.
### response_types
{{< confkey type="list(string)" default="code" required="no" >}}
*__Security Note:__ It is recommended that only the `code` response type (i.e. the default) is used. The other response
types are not as secure as this response type.*
A list of response types this client supports. If a response type not in this list is requested by a client then an
error will be returned to the client. The response type indicates the types of values that are returned to the client.
See the [Response Types](../../../integration/openid-connect/introduction.md#response-types) section of the
[OpenID Connect 1.0 Integration Guide](../../../integration/openid-connect/introduction.md#response-types) for more information.
### response_modes
{{< confkey type="list(string)" default="form_post, query" required="no" >}}
*__Important Note:__ It is recommended that this isn't configured at this time unless you know what you're doing.*
A list of response modes this client supports. If a response mode not in this list is requested by a client then an
error will be returned to the client. The response mode controls how the response type is returned to the client.
See the [Response Modes](../../../integration/openid-connect/introduction.md#response-modes) section of the
[OpenID Connect 1.0 Integration Guide](../../../integration/openid-connect/introduction.md#response-modes) for more
information.
The default values are based on the [response_types](#responsetypes) values. When the [response_types](#responsetypes)
values include the `code` type then the `query` response mode will be included. When any other type is included the
`fragment` response mode will be included. It's important to note at this time we do not support the `none` response
type, but when it is supported it will include the `query` response mode.
### authorization_policy
{{< confkey type="string" default="two_factor" required="no" >}}
The authorization policy for this client: either `one_factor` or `two_factor`.
### consent_mode
{{< confkey type="string" default="auto" required="no" >}}
*__Important Note:__ the `implicit` consent mode is not technically part of the specification. It theoretically could be
misused in certain conditions specifically with the public client type or when the client credentials (i.e. client
secret) has been exposed to an attacker. For these reasons this mode is discouraged.*
Configures the consent mode. The following table describes the different modes:
| Value | Description |
|:--------------:|:----------------------------------------------------------------------------------------------------------------------------------------------:|
| auto | Automatically determined (default). Uses `explicit` unless [pre_configured_consent_duration] is specified in which case uses `pre-configured`. |
| explicit | Requires the user provide unique explicit consent for every authorization. |
| implicit | Automatically assumes consent for every authorization, never asking the user if they wish to give consent. |
| pre-configured | Allows the end-user to remember their consent for the [pre_configured_consent_duration]. |
[pre_configured_consent_duration]: #preconfiguredconsentduration
### pre_configured_consent_duration
{{< confkey type="duration" default="1w" required="no" >}}
*__Note:__ This setting uses the [duration notation format](../../prologue/common.md#duration-notation-format). Please see
the [common options](../../prologue/common.md#duration-notation-format) documentation for information on this format.*
Specifying this in the configuration without a consent [consent_mode] enables the `pre-configured` mode. If this is
specified as well as the [consent_mode] then it only has an effect if the [consent_mode] is `pre-configured` or `auto`.
The period of time dictates how long a users choice to remember the pre-configured consent lasts.
Pre-configured consents are only valid if the subject, client id are exactly the same and the requested scopes/audience
match exactly with the granted scopes/audience.
[consent_mode]: #consentmode
### enforce_par
{{< confkey type="boolean" default="false" required="no" >}}
This configuration option enforces the use of a [Pushed Authorization Requests] flow for this registered client.
To enforce it for all clients see the global [pushed_authorizations enforce](provider.md#enforce) provider configuration
option.
### enforce_pkce
{{< confkey type="bool" default="false" required="no" >}}
This configuration option enforces the use of [PKCE] for this registered client. To enforce it for all clients see the
global [enforce_pkce](provider.md#enforcepkce) provider configuration option.
### pkce_challenge_method
{{< confkey type="string" default="" required="no" >}}
This setting enforces the use of the specified [PKCE] challenge method for this individual client. This setting also
effectively enables the [enforce_pkce](#enforcepkce) option for this client.
Valid values are an empty string, `plain`, or `S256`. It should be noted that `S256` is strongly recommended if the
relying party supports it.
### id_token_signing_alg
{{< confkey type="string" default="RS256" required="no" >}}
The algorithm used to sign the ID Tokens in the token responses.
See the response object section of the
[integration guide](../../../integration/openid-connect/introduction.md#response-object) for more information including
the algorithm column for supported values. In addition to the values listed we also support `none` as a value for this
endpoint.
The algorithm chosen must have a key configured in the [issuer_private_keys](provider.md#issuerprivatekeys) section to
be considered valid.
This option has no effect if the [id_token_signing_key_id](#idtokensigningkid) is specified as the algorithm is
automatically assumed by the configured key.
### id_token_signing_key_id
{{< confkey type="string" required="no" >}}
The key id of the JWK used to sign the ID Tokens in the token responses. This option takes precedence over
[id_token_signing_alg](#idtokensigningalg). The value of this must one of those provided or calculated in the
[issuer_private_keys](provider.md#issuerprivatekeys).
### userinfo_signing_alg
{{< confkey type="string" default="none" required="no" >}}
The algorithm used to sign the userinfo endpoint responses.
See the response object section of the [integration guide](../../../integration/openid-connect/introduction.md#response-object)
for more information including the algorithm column for supported values. In addition to the values listed we also
support `none` as a value for this endpoint.
The algorithm chosen must have a key configured in the [issuer_private_keys](provider.md#issuerprivatekeys) section to
be considered valid.
This option has no effect if the [userinfo_signing_key_id](#userinfosigningkeyid) is specified as the algorithm is
automatically assumed by the configured key.
### userinfo_signing_key_id
{{< confkey type="string" required="no" >}}
The key id of the JWK used to sign the userinfo endpoint responses in the token responses. This option takes precedence
over [userinfo_signing_alg](#userinfosigningalg). The value of this must one of those provided or calculated in the
[issuer_private_keys](provider.md#issuerprivatekeys).
### request_object_signing_alg
{{< confkey type="string" default="RSA256" required="no" >}}
The JWT signing algorithm accepted for request objects.
See the request object section of the
[integration guide](../../../integration/openid-connect/introduction.md#request-object) for more information including
the algorithm column for supported values.
### token_endpoint_auth_method
{{< confkey type="string" default="" required="no" >}}
The registered client authentication mechanism used by this client for the [Token Endpoint]. If no method is defined
the confidential client type will accept any supported method. The public client type defaults to `none` as this
is required by the specification. This may be required as a breaking change in future versions.
Supported values are `client_secret_basic`, `client_secret_post`, `client_secret_jwt`, `private_key_jwt`, and `none`.
See the [integration guide](../../../integration/openid-connect/introduction.md#client-authentication-method) for
more information.
### token_endpoint_auth_signing_alg
{{< confkey type="string" default="RS256" required="no" >}}
The JWT signing algorithm accepted when the [token_endpoint_auth_method](#tokenendpointauthmethod) is configured as
`client_secret_jwt` or `private_key_jwt`.
See the request object section of the [integration guide](../../../integration/openid-connect/introduction.md#request-object)
for more information including the algorithm column for supported values.
It's recommended that you specifically configure this when the following options are configured to specific values
otherwise we assume the default value:
| Configuration Option | Value | Default |
|:----------------------------------------------------------:|:-------------------:|:-------:|
| [token_endpoint_auth_method](#tokenendpointauthsigningalg) | `private_key_jwt` | `RS256` |
| [token_endpoint_auth_method](#tokenendpointauthsigningalg) | `client_secret_jwt` | `HS256` |
### public_keys
This section configures the trusted JSON Web Keys or JWKS for this registered client. This can either be static values
(recommended) or a URI using the `https` scheme. This section is situational required. These are used to validate the
[JWT] assertions from clients.
Required when the following options are configured:
- [request_object_signing_alg](#requestobjectsigningalg)
- [token_endpoint_auth_signing_alg](#tokenendpointauthsigningalg)
Required when the following options are configured to specific values:
- [token_endpoint_auth_method](#tokenendpointauthsigningalg): `private_key_jwt`
#### uri
{{< confkey type="string" required="no" >}}
The fully qualified, `https` scheme, and appropriately signed URI for the JWKS endpoint that implements
[RFC7517 Section 5](https://datatracker.ietf.org/doc/html/rfc7517#section-5). Must not be configured at the same time
as [values](#values). It's recommended that you do not configure this option, but statically configure [values](#values)
instead.
*__Important Note:__ the URL given in this value MUST be resolvable by Authelia and MUST present a certificate signed by
a certificate trusted by your environment. It is beyond our intentions to support anything other than this.*
#### values
{{< confkey type="list(object)" required="situational" >}}
A list of static keys.
##### key_id
{{< confkey type="string" required="yes" >}}
The Key ID used to match the request object's JWT header `kid` value against.
##### use
{{< confkey type="string" default="sig" required="no" >}}
The key usage. Defaults to `sig` which is the only available option at this time.
##### algorithm
{{< confkey type="string" default="RS256" required="situational" >}}
The algorithm for this key. This value typically optional as it can be automatically detected based on the type of key
in some situations. It is however strongly recommended this is set.
See the request object table in the [integration guide](../../../integration/openid-connect/introduction.md#request-object)
for more information. The `Algorithm` column lists supported values, the `Key` column references the required
[key](#key) type constraints that exist for the algorithm, and the `JWK Default Conditions` column briefly explains the
conditions under which it's the default algorithm.
##### key
{{< confkey type="string" required="yes" >}}
The public key portion of the JSON Web Key.
The public key the clients use to sign/encrypt the [OpenID Connect 1.0] asserted [JWT]'s. The key is generated by the
client application or the administrator of the client application.
The key *__MUST__*:
* Be a PEM block encoded in the DER base64 format ([RFC4648]).
* Be either:
* An RSA public key:
* With a key size of at least 2048 bits.
* An ECDSA public key with one of:
* A P-256 elliptical curve.
* A P-384 elliptical curve.
* A P-512 elliptical curve.
If the [certificate_chain](#certificatechain) is provided the private key must include matching public
key data for the first certificate in the chain.
##### certificate_chain
{{< confkey type="string" required="no" >}}
The certificate chain/bundle to be used with the [key](#key) DER base64 ([RFC4648])
encoded PEM format used to sign/encrypt the [OpenID Connect 1.0] [JWT]'s.
## Integration
To integrate Authelia's [OpenID Connect 1.0] implementation with a relying party please see the
[integration docs](../../../integration/openid-connect/introduction.md).
[token lifespan]: https://docs.apigee.com/api-platform/antipatterns/oauth-long-expiration
[OpenID Connect 1.0]: https://openid.net/connect/
[Token Endpoint]: https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint
[JWT]: https://datatracker.ietf.org/doc/html/rfc7519
[RFC6234]: https://datatracker.ietf.org/doc/html/rfc6234
[RFC4648]: https://datatracker.ietf.org/doc/html/rfc4648
[RFC7468]: https://datatracker.ietf.org/doc/html/rfc7468
[RFC6749 Section 2.1]: https://datatracker.ietf.org/doc/html/rfc6749#section-2.1
[PKCE]: https://datatracker.ietf.org/doc/html/rfc7636
[Authorization Code Flow]: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
[Subject Identifier Type]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[Pairwise Identifier Algorithm]: https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
[Pushed Authorization Requests]: https://datatracker.ietf.org/doc/html/rfc9126

View File

@ -1,432 +0,0 @@
---
title: "OpenID Connect 1.0 Provider"
description: "OpenID Connect 1.0 Provider Configuration"
lead: "Authelia can operate as an OpenID Connect 1.0 Provider. This section describes how to configure this."
date: 2023-05-15T10:32:10+10:00
draft: false
images: []
menu:
configuration:
parent: "openid-connect"
weight: 190200
toc: true
aliases:
- /c/oidc
- /docs/configuration/identity-providers/oidc.html
---
__Authelia__ currently supports the [OpenID Connect 1.0] Provider role as an open
[__beta__](../../../roadmap/active/openid-connect.md) feature. We currently do not support the [OpenID Connect 1.0] Relying
Party role. This means other applications that implement the [OpenID Connect 1.0] Relying Party role can use Authelia as
an [OpenID Connect 1.0] Provider similar to how you may use social media or development platforms for login.
The [OpenID Connect 1.0] Relying Party role is the role which allows an application to use GitHub, Google, or other
[OpenID Connect 1.0] Providers for authentication and authorization. We do not intend to support this functionality at
this moment in time.
This section covers the [OpenID Connect 1.0] Provider configuration. For information on configuring individual
registered clients see the [OpenID Connect 1.0 Clients](clients.md) documentation.
More information about the beta can be found in the [roadmap](../../../roadmap/active/openid-connect.md) and in the
[integration](../../../integration/openid-connect/introduction.md) documentation.
## Configuration
The following snippet provides a configuration example for the [OpenID Connect 1.0] Provider. This is not
intended for production use it's used to provide context and an indentation example.
```yaml
identity_providers:
oidc:
hmac_secret: this_is_a_secret_abc123abc123abc
issuer_private_keys:
- key_id: example
algorithm: RS256
use: sig
key: |
-----BEGIN RSA PUBLIC KEY-----
MEgCQQDAwV26ZA1lodtOQxNrJ491gWT+VzFum9IeZ+WTmMypYWyW1CzXKwsvTHDz
9ec+jserR3EMQ0Rr24lj13FL1ib5AgMBAAE=
-----END RSA PUBLIC KEY----
certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIBWzCCAQWgAwIBAgIQYAKsXhJOXKfyySlmpKicTzANBgkqhkiG9w0BAQsFADAT
MREwDwYDVQQKEwhBdXRoZWxpYTAeFw0yMzA0MjEwMDA3NDRaFw0yNDA0MjAwMDA3
NDRaMBMxETAPBgNVBAoTCEF1dGhlbGlhMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
AK2i7RlJEYo/Xa6mQmv9zmT0XUj3DcEhRJGPVw2qMyadUFxNg/ZFp7aTcToHMf00
z6T3b7mwdBkCFQOL3Kb7WRcCAwEAAaM1MDMwDgYDVR0PAQH/BAQDAgWgMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADQQB8
Of2iM7fPadmtChCMna8lYWH+lEplj6BxOJlRuGRawxszLwi78bnq0sCR33LU6xMx
1oAPwIHNaJJwC4z6oG9E_DO_NOT_USE=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBWzCCAQWgAwIBAgIQYAKsXhJOXKfyySlmpKicTzANBgkqhkiG9w0BAQsFADAT
MREwDwYDVQQKEwhBdXRoZWxpYTAeFw0yMzA0MjEwMDA3NDRaFw0yNDA0MjAwMDA3
NDRaMBMxETAPBgNVBAoTCEF1dGhlbGlhMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
AK2i7RlJEYo/Xa6mQmv9zmT0XUj3DcEhRJGPVw2qMyadUFxNg/ZFp7aTcToHMf00
z6T3b7mwdBkCFQOL3Kb7WRcCAwEAAaM1MDMwDgYDVR0PAQH/BAQDAgWgMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADQQB8
Of2iM7fPadmtChCMna8lYWH+lEplj6BxOJlRuGRawxszLwi78bnq0sCR33LU6xMx
1oAPwIHNaJJwC4z6oG9E_DO_NOT_USE=
-----END CERTIFICATE-----
issuer_private_key: |
-----BEGIN RSA PUBLIC KEY-----
MEgCQQDAwV26ZA1lodtOQxNrJ491gWT+VzFum9IeZ+WTmMypYWyW1CzXKwsvTHDz
9ec+jserR3EMQ0Rr24lj13FL1ib5AgMBAAE=
-----END RSA PUBLIC KEY----
issuer_certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIBWzCCAQWgAwIBAgIQYAKsXhJOXKfyySlmpKicTzANBgkqhkiG9w0BAQsFADAT
MREwDwYDVQQKEwhBdXRoZWxpYTAeFw0yMzA0MjEwMDA3NDRaFw0yNDA0MjAwMDA3
NDRaMBMxETAPBgNVBAoTCEF1dGhlbGlhMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
AK2i7RlJEYo/Xa6mQmv9zmT0XUj3DcEhRJGPVw2qMyadUFxNg/ZFp7aTcToHMf00
z6T3b7mwdBkCFQOL3Kb7WRcCAwEAAaM1MDMwDgYDVR0PAQH/BAQDAgWgMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADQQB8
Of2iM7fPadmtChCMna8lYWH+lEplj6BxOJlRuGRawxszLwi78bnq0sCR33LU6xMx
1oAPwIHNaJJwC4z6oG9E_DO_NOT_USE=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBWzCCAQWgAwIBAgIQYAKsXhJOXKfyySlmpKicTzANBgkqhkiG9w0BAQsFADAT
MREwDwYDVQQKEwhBdXRoZWxpYTAeFw0yMzA0MjEwMDA3NDRaFw0yNDA0MjAwMDA3
NDRaMBMxETAPBgNVBAoTCEF1dGhlbGlhMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
AK2i7RlJEYo/Xa6mQmv9zmT0XUj3DcEhRJGPVw2qMyadUFxNg/ZFp7aTcToHMf00
z6T3b7mwdBkCFQOL3Kb7WRcCAwEAAaM1MDMwDgYDVR0PAQH/BAQDAgWgMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADQQB8
Of2iM7fPadmtChCMna8lYWH+lEplj6BxOJlRuGRawxszLwi78bnq0sCR33LU6xMx
1oAPwIHNaJJwC4z6oG9E_DO_NOT_USE=
-----END CERTIFICATE-----
access_token_lifespan: 1h
authorize_code_lifespan: 1m
id_token_lifespan: 1h
refresh_token_lifespan: 90m
enable_client_debug_messages: false
minimum_parameter_entropy: 8
enforce_pkce: public_clients_only
enable_pkce_plain_challenge: false
pushed_authorizations:
enforce: false
context_lifespan: 5m
cors:
endpoints:
- authorization
- token
- revocation
- introspection
allowed_origins:
- https://example.com
allowed_origins_from_client_redirect_uris: false
```
## Options
### hmac_secret
{{< confkey type="string" required="yes" >}}
*__Important Note:__ This can also be defined using a [secret](../../methods/secrets.md) which is __strongly recommended__
especially for containerized deployments.*
The HMAC secret used to sign the [JWT]'s. The provided string is hashed to a SHA256 ([RFC6234]) byte string for the
purpose of meeting the required format.
It's __strongly recommended__ this is a
[Random Alphanumeric String](../../../reference/guides/generating-secure-values.md#generating-a-random-alphanumeric-string)
with 64 or more characters.
### issuer_private_keys
{{< confkey type="list(object" required="no" >}}
The list of JWKS instead of or in addition to the [issuer_private_key](#issuerprivatekey) and
[issuer_certificate_chain](#issuercertificatechain). Can also accept ECDSA Private Key's and Certificates.
The default key for each algorithm is is decided based on the order of this list. The first key for each algorithm is
considered the default if a client is not configured to use a specific key id. For example if a client has
[id_token_signing_alg](clients.md#idtokensigningalg) `ES256` and [id_token_signing_key_id](clients.md#idtokensigningkid) is
not specified then the first `ES256` key in this list is used.
#### key_id
{{< confkey type="string" default="<thumbprint of public key>" required="no" >}}
Completely optional, and generally discouraged unless there is a collision between the automatically generated key id's.
If provided must be a unique string with 100 or less characters, with a recommendation to use a length less
than 10. In addition it must meet the following rules:
- Match the regular expression `^[a-zA-Z0-9](([a-zA-Z0-9._~-]*)([a-zA-Z0-9]))?$` which should enforce the following rules:
- Start with an alphanumeric character.
- End with an alphanumeric character.
- Only contain the [RFC3986 Unreserved Characters](https://datatracker.ietf.org/doc/html/rfc3986#section-2.3).
The default if this value is omitted is the first 7 characters of the public key SHA256 thumbprint encoded into
hexadecimal.
#### use
{{< confkey type="string" default="sig" required="no" >}}
The key usage. Defaults to `sig` which is the only available option at this time.
#### algorithm
{{< confkey type="string" default="RS256" required="situational" >}}
The algorithm for this key. This value typically optional as it can be automatically detected based on the type of key
in some situations.
See the response object table in the [integration guide](../../../integration/openid-connect/introduction.md#response-object)
for more information. The `Algorithm` column lists supported values, the `Key` column references the required
[key](#key) type constraints that exist for the algorithm, and the `JWK Default Conditions` column briefly explains the
conditions under which it's the default algorithm.
At least one `RSA256` key must be provided.
#### key
{{< confkey type="string" required="yes" >}}
The private key associated with this key entry.
The private key used to sign/encrypt the [OpenID Connect 1.0] issued [JWT]'s. The key must be generated by the
administrator and can be done by following the
[Generating an RSA Keypair](../../../reference/guides/generating-secure-values.md#generating-an-rsa-keypair) guide.
The private key *__MUST__*:
* Be a PEM block encoded in the DER base64 format ([RFC4648]).
* Be one of:
* An RSA key with a key size of at least 2048 bits.
* An ECDSA private key with one of the P-256, P-384, or P-521 elliptical curves.
If the [certificate_chain](#certificatechain) is provided the private key must include matching public
key data for the first certificate in the chain.
#### certificate_chain
{{< confkey type="string" required="no" >}}
The certificate chain/bundle to be used with the [key](#key) DER base64 ([RFC4648])
encoded PEM format used to sign/encrypt the [OpenID Connect 1.0] [JWT]'s. When configured it enables the [x5c] and [x5t]
JSON key's in the JWKs [Discoverable Endpoint](../../../integration/openid-connect/introduction.md#discoverable-endpoints)
as per [RFC7517].
[RFC7517]: https://datatracker.ietf.org/doc/html/rfc7517
[x5c]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.7
[x5t]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.8
The first certificate in the chain must have the public key for the [key](#key), each certificate in the chain must be
valid for the current date, and each certificate in the chain should be signed by the certificate immediately following
it if present.
### issuer_private_key
{{< confkey type="string" required="yes" >}}
The private key used to sign/encrypt the [OpenID Connect 1.0] issued [JWT]'s. The key must be generated by the
administrator and can be done by following the
[Generating an RSA Keypair](../../../reference/guides/generating-secure-values.md#generating-an-rsa-keypair) guide.
This private key is automatically appended to the [issuer_private_keys](#issuerprivatekeys) and assumed to be for the
`RS256` algorithm. If provided it is always the first key in this list. As such this key is assumed to be the default
for `RS256` if provided.
The issuer private key *__MUST__*:
* Be a PEM block encoded in the DER base64 format ([RFC4648]).
* Be an RSA private key:
* With a key size of at least 2048 bits.
If the [issuer_certificate_chain](#issuercertificatechain) is provided the private key must include matching public
key data for the first certificate in the chain.
### issuer_certificate_chain
{{< confkey type="string" required="no" >}}
The certificate chain/bundle to be used with the [issuer_private_key](#issuerprivatekey) DER base64 ([RFC4648])
encoded PEM format used to sign/encrypt the [OpenID Connect 1.0] [JWT]'s. When configured it enables the [x5c] and [x5t]
JSON key's in the JWKs [Discoverable Endpoint](../../../integration/openid-connect/introduction.md#discoverable-endpoints)
as per [RFC7517].
[RFC7517]: https://datatracker.ietf.org/doc/html/rfc7517
[x5c]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.7
[x5t]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.8
The first certificate in the chain must have the public key for the [issuer_private_key](#issuerprivatekey), each
certificate in the chain must be valid for the current date, and each certificate in the chain should be signed by the
certificate immediately following it if present.
### access_token_lifespan
{{< confkey type="duration" default="1h" required="no" >}}
The maximum lifetime of an access token. It's generally recommended keeping this short similar to the default.
For more information read these docs about [token lifespan].
### authorize_code_lifespan
{{< confkey type="duration" default="1m" required="no" >}}
The maximum lifetime of an authorize code. This can be rather short, as the authorize code should only be needed to
obtain the other token types. For more information read these docs about [token lifespan].
### id_token_lifespan
{{< confkey type="duration" default="1h" required="no" >}}
The maximum lifetime of an ID token. For more information read these docs about [token lifespan].
### refresh_token_lifespan
{{< confkey type="string" default="90m" required="no" >}}
The maximum lifetime of a refresh token. The
refresh token can be used to obtain new refresh tokens as well as access tokens or id tokens with an
up-to-date expiration. For more information read these docs about [token lifespan].
A good starting point is 50% more or 30 minutes more (which ever is less) time than the highest lifespan out of the
[access token lifespan](#accesstokenlifespan), the [authorize code lifespan](#authorizecodelifespan), and the
[id token lifespan](#idtokenlifespan). For instance the default for all of these is 60 minutes, so the default refresh
token lifespan is 90 minutes.
### enable_client_debug_messages
{{< confkey type="boolean" default="false" required="no" >}}
Allows additional debug messages to be sent to the clients.
### minimum_parameter_entropy
{{< confkey type="integer" default="8" required="no" >}}
This controls the minimum length of the `nonce` and `state` parameters.
*__Security Notice:__* Changing this value is generally discouraged, reducing it from the default can theoretically
make certain scenarios less secure. It is highly encouraged that if your OpenID Connect 1.0 Relying Party does not send
these parameters or sends parameters with a lower length than the default that they implement a change rather than
changing this value.
This restriction can also be disabled entirely when set to `-1`.
### enforce_pkce
{{< confkey type="string" default="public_clients_only" required="no" >}}
[Proof Key for Code Exchange](https://datatracker.ietf.org/doc/html/rfc7636) enforcement policy: if specified, must be
either `never`, `public_clients_only` or `always`.
If set to `public_clients_only` (default), [PKCE] will be required for public clients using the
[Authorization Code Flow].
When set to `always`, [PKCE] will be required for all clients using the Authorization Code flow.
*__Security Notice:__* Changing this value to `never` is generally discouraged, reducing it from the default can
theoretically make certain client-side applications (mobile applications, SPA) vulnerable to CSRF and authorization code
interception attacks.
### enable_pkce_plain_challenge
{{< confkey type="boolean" default="false" required="no" >}}
Allows [PKCE] `plain` challenges when set to `true`.
*__Security Notice:__* Changing this value is generally discouraged. Applications should use the `S256` [PKCE] challenge
method instead.
### pushed_authorizations
Controls the behaviour of [Pushed Authorization Requests].
#### enforce
{{< confkey type="boolean" default="false" required="no" >}}
When enabled all authorization requests must use the [Pushed Authorization Requests] flow.
#### context_lifespan
{{< confkey type="duration" default="5m" required="no" >}}
The maximum amount of time between the [Pushed Authorization Requests] flow being initiated and the generated
`request_uri` being utilized by a client.
### cors
Some [OpenID Connect 1.0] Endpoints need to allow cross-origin resource sharing, however some are optional. This section allows
you to configure the optional parts. We reply with CORS headers when the request includes the Origin header.
#### endpoints
{{< confkey type="list(string)" required="no" >}}
A list of endpoints to configure with cross-origin resource sharing headers. It is recommended that the `userinfo`
option is at least in this list. The potential endpoints which this can be enabled on are as follows:
* authorization
* pushed-authorization-request
* token
* revocation
* introspection
* userinfo
#### allowed_origins
{{< confkey type="list(string)" required="no" >}}
A list of permitted origins.
Any origin with https is permitted unless this option is configured or the
[allowed_origins_from_client_redirect_uris](#allowedoriginsfromclientredirecturis) option is enabled. This means
you must configure this option manually if you want http endpoints to be permitted to make cross-origin requests to the
[OpenID Connect 1.0] endpoints, however this is not recommended.
Origins must only have the scheme, hostname and port, they may not have a trailing slash or path.
In addition to an Origin URI, you may specify the wildcard origin in the allowed_origins. It MUST be specified by itself
and the [allowed_origins_from_client_redirect_uris](#allowedoriginsfromclientredirecturis) MUST NOT be enabled. The
wildcard origin is denoted as `*`. Examples:
```yaml
identity_providers:
oidc:
cors:
allowed_origins: "*"
```
```yaml
identity_providers:
oidc:
cors:
allowed_origins:
- "*"
```
#### allowed_origins_from_client_redirect_uris
{{< confkey type="boolean" default="false" required="no" >}}
Automatically adds the origin portion of all redirect URI's on all clients to the list of
[allowed_origins](#allowed_origins), provided they have the scheme http or https and do not have the hostname of
localhost.
### clients
See the [OpenID Connect 1.0 Registered Clients](clients.md) documentation for configuring clients.
## Integration
To integrate Authelia's [OpenID Connect 1.0] implementation with a relying party please see the
[integration docs](../../../integration/openid-connect/introduction.md).
[token lifespan]: https://docs.apigee.com/api-platform/antipatterns/oauth-long-expiration
[OpenID Connect 1.0]: https://openid.net/connect/
[Token Endpoint]: https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint
[JWT]: https://datatracker.ietf.org/doc/html/rfc7519
[RFC6234]: https://datatracker.ietf.org/doc/html/rfc6234
[RFC4648]: https://datatracker.ietf.org/doc/html/rfc4648
[RFC7468]: https://datatracker.ietf.org/doc/html/rfc7468
[RFC6749 Section 2.1]: https://datatracker.ietf.org/doc/html/rfc6749#section-2.1
[PKCE]: https://datatracker.ietf.org/doc/html/rfc7636
[Authorization Code Flow]: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
[Subject Identifier Type]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[Pairwise Identifier Algorithm]: https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
[Pushed Authorization Requests]: https://datatracker.ietf.org/doc/html/rfc9126

View File

@ -16,7 +16,7 @@ Environment variables are applied after the configuration file meaning anything
overrides the configuration files.
*__Please Note:__ It is not possible to configure several sections at this time, these include but may not be
limited to the rules section in access control, the clients section in the OpenID Connect 1.0 Provider, the cookies
limited to the rules section in access control, the clients section in the OpenID Connect identity provider, the cookies
section of in session, and the authz section in the server endpoints.*
## Prefix

View File

@ -63,9 +63,9 @@ authelia --config configuration.yml,config-acl.yml,config-other.yml
Authelia's configuration files use the YAML format. A template with all possible options can be found at the root of the
repository {{< github-link name="here" path="config.template.yml" >}}.
*__Important Note:__ You should not have configuration sections such as Access Control Rules or OpenID Connect 1.0
clients configured in multiple files. If you wish to split these into their own files that is fine, but if you have two
files that specify these sections and expect them to merge properly you are asking for trouble.*
*__Important Note:__ You should not have configuration sections such as Access Control Rules or OpenID Connect clients
configured in multiple files. If you wish to split these into their own files that is fine, but if you have two files that
specify these sections and expect them to merge properly you are asking for trouble.*
### Container

View File

@ -77,9 +77,9 @@ other configuration using the environment but instead of loading a file the valu
[authentication_backend.ldap.password]: ../first-factor/ldap.md#password
[authentication_backend.ldap.tls.certificate_chain]: ../first-factor/ldap.md#tls
[authentication_backend.ldap.tls.private_key]: ../first-factor/ldap.md#tls
[identity_providers.oidc.issuer_certificate_chain]: ../identity-providers/openid-connect.md#issuercertificatechain
[identity_providers.oidc.issuer_private_key]: ../identity-providers/openid-connect.md#issuerprivatekey
[identity_providers.oidc.hmac_secret]: ../identity-providers/openid-connect.md#hmacsecret
[identity_providers.oidc.issuer_certificate_chain]: ../identity-providers/open-id-connect.md#issuercertificatechain
[identity_providers.oidc.issuer_private_key]: ../identity-providers/open-id-connect.md#issuerprivatekey
[identity_providers.oidc.hmac_secret]: ../identity-providers/open-id-connect.md#hmacsecret
## Secrets in configuration file

View File

@ -44,7 +44,7 @@ accepted is recorded and checked in the browser
If the user has not accepted the policy they should not be able to interact with the Authelia UI via normal means.
Administrators who are required to abide by the [GDPR] or other privacy laws should be advised that
[OpenID Connect 1.0](../identity-providers/openid-connect.md) clients configured with the `implicit` consent mode are
[OpenID Connect 1.0](../identity-providers/open-id-connect.md) clients configured with the `implicit` consent mode are
unlikely to trigger the display of the Authelia UI if the user is already authenticated.
We wont be adding checks like this to the `implicit` consent mode when that mode in particular is unlikely to be

View File

@ -24,24 +24,16 @@ server:
authz:
forward-auth:
implementation: 'ForwardAuth'
authn_strategies:
- name: 'HeaderProxyAuthorization'
- name: 'CookieSession'
authn_strategies: []
ext-authz:
implementation: 'ExtAuthz'
authn_strategies:
- name: 'HeaderProxyAuthorization'
- name: 'CookieSession'
authn_strategies: []
auth-request:
implementation: 'AuthRequest'
authn_strategies:
- name: 'HeaderAuthRequestProxyAuthorization'
- name: 'CookieSession'
authn_strategies: []
legacy:
implementation: 'Legacy'
authn_strategies:
- name: 'HeaderLegacy'
- name: 'CookieSession'
authn_strategies: []
```
## Name

View File

@ -21,7 +21,8 @@ aliases:
```yaml
server:
address: 'tcp://:9091/'
address: 'tcp://:9091'
path: ''
disable_healthcheck: false
tls:
key: ''
@ -58,25 +59,19 @@ server:
### address
{{< confkey type="address" default="tcp://:9091/" required="no" >}}
{{< confkey type="address" default="tcp://:9091" required="no" >}}
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
Configures the listener address for the Main HTTP Server. The address itself is a listener and the scheme must either be
the `unix` scheme or one of the `tcp` schemes. It can configure the host, port, and path the listener responds to. If
the path is configured to anything other than `/` Authelia will handle requests for both `/` and the configured path.
the `unix` scheme or one of the `tcp` schemes.
__Examples:__
__Example:__
```yaml
server:
address: tcp://127.0.0.1:9091/
```
```yaml
server:
address: tcp://127.0.0.1:9091/subpath
address: tcp://127.0.0.1:9091
```
```yaml
@ -84,6 +79,41 @@ server:
address: unix:///var/run/authelia.sock
```
### umask
{{< confkey type="int" required="no" >}}
If set temporarily changes the Umask during the creation of the unix domain socket if configured as such in the
[address](#address).
### path
{{< confkey type="string " required="no" >}}
Authelia by default is served from the root `/` location, either via its own domain or subdomain.
Modifying this setting will allow you to serve Authelia out from a specified base path. Please note
that currently only a single level path is supported meaning slashes are not allowed, and only
alphanumeric characters are supported.
__Example:__
```yaml
server:
path: ""
```
*Works for https://auth.example.com/, https://example.com/, etc*.
__Example:__
```yaml
server:
path: authelia
```
*Works for https://auth.example.com/authelia/, https://example.com/authelia/, etc*.
### asset_path
{{< confkey type="string " required="no" >}}
@ -152,19 +182,13 @@ research about how browsers utilize and understand this header before attempting
### buffers
*__Reference Note:__ This configuration option uses the
[Server buffers common structure](../prologue/common.md#server-buffers). Please see the
[documentation](../prologue/common.md#server-buffers) on this structure for more information.*
Configures the server buffers.
Configures the server buffers. See the [Server Buffers](../prologue/common.md#server-buffers) documentation for more
information.
### timeouts
*__Reference Note:__ This configuration option uses the
[Server timeouts common structure](../prologue/common.md#server-timeouts). Please see the
[documentation](../prologue/common.md#server-timeouts) on this structure for more information.*
Configures the server timeouts.
Configures the server timeouts. See the [Server Timeouts](../prologue/common.md#server-timeouts) documentation for more
information.
### endpoints
@ -179,11 +203,11 @@ Enables the go [pprof](https://pkg.go.dev/net/http/pprof) endpoints.
#### enable_expvars
{{< confkey type="boolean" default="false" required="no" >}}
*__Security Note:__ This is a developer endpoint. __DO NOT__ enable it unless you know why you're enabling it.
__DO NOT__ enable this in production.*
{{< confkey type="boolean" default="false" required="no" >}}
Enables the go [expvar](https://pkg.go.dev/expvar) endpoints.
#### authz

View File

@ -232,11 +232,8 @@ mixed emails which contain both HTML and text so this option is rarely necessary
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
Controls the TLS connection validation parameters for either StartTLS or the TLS socket.
Controls the TLS connection validation process. You can see how to configure the tls section
[here](../prologue/common.md#tls-configuration).
## Using Gmail

View File

@ -24,42 +24,69 @@ guide on configuring any particular instance.
The base type for this syntax is a string, and it also handles integers however this is discouraged.
If you supply an integer, it is considered a representation of seconds. If you supply a string, it parses the string in
blocks of quantities and units (number followed by a unit letter). For example `5h` indicates a quantity of 5 units
of `h`.
We have implemented a string/integer based syntax for configuration options that take a duration of time. This section
describes the implementation of this. You can use this implementation in various areas of configuration such as:
The following is ignored or stripped from the input:
* session:
* expiration
* inactivity
* remember_me
* regulation:
* ban_time
* find_time
* ntp:
* max_desync
* webauthn:
* timeout
The way this format works is you can either configure an integer or a string in the specific configuration areas. If you
supply an integer, it is considered a representation of seconds. If you supply a string, it parses the string in blocks
of quantities and units (number followed by a unit letter). For example `5h` indicates a quantity of 5 units of `h`.
The following is ignored:
- all spaces
- leading zeros
- the word `and`
While you can use multiple of these blocks in combination, we suggest keeping it simple and use a single value. In
addition it's important to note that the format while somewhat human readable still requires you closely follow the
expected formats.
While you can use multiple of these blocks in combination, we suggest keeping it simple and use a single value.
#### Unit Legend
The following is a legend for the unit formats available in this syntax. The long form units are only available from
v4.38.0 or newer.
##### Short Units
| Unit | Short Unit | Human Readable Long Unit |
|:------------:|:----------:|:-----------------------------:|
| Years | `y` | `year`, `years` |
| Months | `M` | `month`, `months` |
| Weeks | `w` | `week`, `weeks` |
| Days | `d` | `day`, `days` |
| Hours | `h` | `hour`, `hours` |
| Minutes | `m` | `minute`, `minutes` |
| Seconds | `s` | `second`, `seconds` |
| Milliseconds | `ms` | `millisecond`, `milliseconds` |
These values have been available for a long time.
| Unit | Associated Letter |
|:-------:|:-----------------:|
| Years | y |
| Months | M |
| Weeks | w |
| Days | d |
| Hours | h |
| Minutes | m |
| Seconds | s |
##### Long Units
These values are more human readable but have only been available since v4.38.0.
| Unit | Human Readable Long Unit |
|:------------:|:-----------------------------:|
| Years | `year`, `years` |
| Months | `month`, `months` |
| Weeks | `week`, `weeks` |
| Days | `day`, `days` |
| Hours | `hour`, `hours` |
| Minutes | `minute`, `minutes` |
| Seconds | `second`, `seconds` |
| Milliseconds | `millisecond`, `milliseconds` |
#### Examples
| Desired Value | Configuration Examples (Short) | Configuration Examples (Long) |
|:---------------------:|:-------------------------------------:|:--------------------------------------:|
| 1 hour and 30 minutes | `90m` or `1h30m` or `5400` or `5400s` | `1 hour and 30 minutes` |
| 1 day | `1d` or `24h` or `86400` or `86400s` | `1 day` |
| 10 hours | `10h` or `600m` or `9h60m` or `36000` | `10 hours` |
| Desired Value | Configuration Examples |
|:---------------------:|:-------------------------------------:|
| 1 hour and 30 minutes | `90m` or `1h30m` or `5400` or `5400s` |
| 1 day | `1d` or `24h` or `86400` or `86400s` |
| 10 hours | `10h` or `600m` or `9h60m` or `36000` |
### Address
@ -77,65 +104,26 @@ portions. Required portions may exist within optional portions, in which case th
format specific text which indicates if the accompanying text exists then it is actually required, otherwise it's
entirely optional.
The square brackets indicate optional sections, and the angled brackets indicate required sections. The following
sections elaborate on this. Sections may only be optional for the purposes of parsing, there may be a configuration
requirement that one of these is provided.
##### Hostname
The following format represents the hostname format. It's valid for both a listener and connector in most instances.
Refer to the individual documentation for an option for clarity. In this format as per the notation the scheme and port
are optional. The default for these when not provided varies.
```text
[<scheme>://]<hostname>[:<port>][/<path>]
```
##### Port
The following format represents the port format. It's valid only for a listener in most instances.
Refer to the individual documentation for an option for clarity. In this format as per the notation the scheme and
hostname are optional. The default for the scheme when not provided varies, and the default for the hostname is all
available addresses when not provided.
```text
[<scheme>://][hostname]:<port>[/<path>]
```
##### Unix Domain Socket
The following format represents the unix domain socket format. It's valid for both a listener and connector in most
instances. Refer to the individual documentation for an option for clarity. In this format as per the notation there
are no optional portions.
The Unix Domain Socket format also accepts a query string. The following query parameters control certain behaviour of
this address type.
| Parameter | Listeners | Connectors | Purpose |
|:---------:|:---------:|:----------:|:------------------------------------------------------------------------------------------------------------------------------------:|
| `umask` | Yes | No | Sets the umask prior to creating the socket and restores it after creating it. The value must be an octal number with 3 or 4 digits. |
The connector address values take the following formats:
```text
[<scheme>://]<hostname>[:<port>]
unix://<path>
```
The listener address values take the following additional formats:
```text
unix://<path>?umask=0022
[<scheme>://]:<port>
```
##### Examples
Various examples for these formats.
Examples:
```text
0.0.0.0
tcp://0.0.0.0
tcp://0.0.0.0/subpath
tcp://0.0.0.0:9091
tcp://0.0.0.0:9091/subpath
tcp://:9091
tcp://:9091/subpath
0.0.0.0:9091
udp://0.0.0.0:123
@ -143,6 +131,9 @@ udp://:123
unix:///var/lib/authelia.sock
```
The square brackets indicate optional sections, and the angled brackets indicate required sections. The following
sections elaborate on this. Sections may only be optional for the purposes of parsing, there may be a configuration
requirement that one of these is provided.
#### scheme
@ -220,11 +211,6 @@ guide on configuring any particular instance.
Various sections of the configuration use a uniform configuration section called TLS. Notably LDAP and SMTP.
This section documents the usage.
Various sections of the configuration use a uniform configuration section called `tls` which configure TLS socket and
TLS verification parameters. Notably the [LDAP](../first-factor/ldap.md#tls), [SMTP](../notifications/smtp.md#tls),
[PostgreSQL](../storage/postgres.md#tls), [MySQL](../storage/mysql.md#tls), and [Redis](../session/redis.md#tls)
sections. This section documents the common parts of this structure.
#### server_name
{{< confkey type="string" required="no" >}}
@ -283,11 +269,6 @@ is provided, in top down order, each certificate must be signed by the next cert
### Server Buffers
Various sections of the configuration use a uniform configuration section called `buffers` which configure HTTP server
buffers. Notably the [server](../miscellaneous/server.md#buffers) and
[metrics telemetry](../telemetry/metrics.md#buffers) sections. This section documents the common parts of this
structure.
#### read
{{< confkey type="integer" default="4096" required="no" >}}
@ -302,11 +283,6 @@ Configures the maximum response size. The default of 4096 is generally sufficien
### Server Timeouts
Various sections of the configuration use a uniform configuration section called `timeouts` which configure HTTP server
timeouts. Notably the [server](../miscellaneous/server.md#timeouts) and
[metrics telemetry](../telemetry/metrics.md#timeouts) sections. This section documents the common parts of this
structure.
#### read
{{< confkey type="duration" default="6s" required="no" >}}

View File

@ -65,8 +65,9 @@ by Authelia from others.
*__Important Note:__ Many TOTP applications do not support this option. It is strongly advised you find out which
applications your users use and test them before changing this option. It is insufficient to test that the application
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. See the
[Reference Guide](../../reference/integrations/time-based-one-time-password-apps.md) for tested applications.*
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. [Bitwarden]
is the only one that has been tested at this time. If you'd like to contribute to documenting support for this option
please see [Issue 2650](https://github.com/authelia/authelia/issues/2650).*
[Bitwarden]: https://bitwarden.com/
@ -87,8 +88,9 @@ information.
*__Important Note:__ Some TOTP applications do not support this option. It is strongly advised you find out which
applications your users use and test them before changing this option. It is insufficient to test that the application
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. See the
[Reference Guide](../../reference/integrations/time-based-one-time-password-apps.md) for tested applications.*
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. [Bitwarden]
is the only one that has been tested at this time. If you'd like to contribute to documenting support for this option
please see [Issue 2650](https://github.com/authelia/authelia/issues/2650).*
The number of digits a user needs to input to perform authentication. It's generally not recommended for this to be
altered as many TOTP applications do not support anything other than 6. What's worse is some TOTP applications allow

View File

@ -89,6 +89,6 @@ Please see the [documentation](../prologue/common.md#duration) on this format fo
This adjusts the requested timeout for a WebAuthn interaction.
## Frequently Asked Questions
## FAQ
See the [Security Key FAQ](../../overview/authentication/security-key/index.md#frequently-asked-questions) for the FAQ.
See the [Security Key FAQ](../../overview/authentication/security-key/index.md#faq) for the FAQ.

View File

@ -15,11 +15,6 @@ aliases:
- /docs/configuration/access-control.html
---
*__Important Note:__ This section does not apply to OpenID Connect 1.0. See the [Frequently Asked Questions] for more
information.*
[Frequently Asked Questions]: ../../integration/openid-connect/frequently-asked-questions.md#why-doesnt-the-access-control-configuration-work-with-openid-connect-10
## Configuration
{{< config-alert-example >}}

View File

@ -182,12 +182,8 @@ is useful if there are long delays in establishing connections.
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
If defined enables connecting to [redis] over a TLS socket, and additionally controls the TLS connection
validation parameters.
If defined enables [redis] over TLS, and additionally controls the TLS connection validation process. You can see how to
configure the tls section [here](../prologue/common.md#tls-configuration).
### high_availability

View File

@ -32,9 +32,9 @@ this instance if you wanted to downgrade to pre1 you would need to use an Authel
| 1 | 4.33.0 | Initial migration managed version |
| 2 | 4.34.0 | WebAuthn - added webauthn_devices table, altered totp_config to include device created/used dates |
| 3 | 4.34.2 | WebAuthn - fix V2 migration kid column length and provide migration path for anyone on V2 |
| 4 | 4.35.0 | Added OpenID Connect 1.0 storage tables and opaque user identifier tables |
| 4 | 4.35.0 | Added OpenID Connect storage tables and opaque user identifier tables |
| 5 | 4.35.1 | Fixed the oauth2_consent_session table to accept NULL subjects for users who are not yet signed in |
| 6 | 4.37.0 | Adjusted the OpenID Connect 1.0 tables to allow pre-configured consent improvements |
| 6 | 4.37.0 | Adjusted the OpenID Connect tables to allow pre-configured consent improvements |
| 7 | 4.37.3 | Fixed some schema inconsistencies most notably the MySQL/MariaDB Engine and Collation |
| 8 | 4.38.0 | OpenID Connect 1.0 Pushed Authorization Requests |
| 9 | 4.38.0 | Fix a PostgreSQL NOT NULL constraint issue on the `aaguid` column of the `webauthn_devices` table |

View File

@ -182,12 +182,8 @@ The SQL connection timeout.
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
If defined enables connecting to [MySQL] or [MariaDB] over a TLS socket, and additionally controls the TLS connection
validation parameters.
validation process. You can see how to configure the tls section [here](../prologue/common.md#tls-configuration).
[MySQL]: https://www.mysql.com/
[MariaDB]: https://mariadb.org/

View File

@ -32,7 +32,6 @@ storage:
schema: 'public'
username: 'authelia'
password: 'mypassword'
timeout: '5s'
tls:
server_name: 'postgres.example.com'
skip_verify: false
@ -189,11 +188,7 @@ The SQL connection timeout.
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
If defined enables connecting to [PostgreSQL] over a TLS socket, and additionally controls the TLS connection
validation parameters.
validation process. You can see how to configure the tls section [here](../prologue/common.md#tls-configuration).
[PostgreSQL]: https://www.postgresql.org/

View File

@ -22,7 +22,7 @@ toc: true
telemetry:
metrics:
enabled: false
address: 'tcp://:9959/'
address: 'tcp://:9959'
buffers:
read: 4096
write: 4096
@ -44,7 +44,7 @@ Determines if the [Prometheus] HTTP Metrics Exporter is enabled.
### address
{{< confkey type="address" default="tcp://:9959/" required="no" >}}
{{< confkey type="address" default="tcp://:9959" required="no" >}}
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
@ -52,21 +52,22 @@ see the [documentation](../prologue/common.md#address) on this format for more i
Configures the listener address for the [Prometheus] Metrics Exporter HTTP Server. The address itself is a listener and
the scheme must either be the `unix` scheme or one of the `tcp` schemes.
### umask
{{< confkey type="int" required="no" >}}
If set temporarily changes the Umask during the creation of the unix domain socket if configured as such in the
[address](#address).
### buffers
*__Reference Note:__ This configuration option uses the
[Server buffers common structure](../prologue/common.md#server-buffers). Please see the
[documentation](../prologue/common.md#server-buffers) on this structure for more information.*
Configures the server buffers.
Configures the server buffers. See the [Server Buffers](../prologue/common.md#server-buffers) documentation for more
information.
### timeouts
*__Reference Note:__ This configuration option uses the
[Server timeouts common structure](../prologue/common.md#server-timeouts). Please see the
[documentation](../prologue/common.md#server-timeouts) on this structure for more information.*
Configures the server timeouts.
Configures the server timeouts. See the [Server Timeouts](../prologue/common.md#server-timeouts) documentation for more
information.
## See More

View File

@ -62,7 +62,7 @@ There is a scripting context provided with __Authelia__ which can easily be conf
[suites] and various other tasks. Read more about it in the [authelia-scripts](reference-authelia-scripts.md) reference
guide.
## Frequently Asked Questions
## FAQ
### Do you support development under Windows or OSX?

View File

@ -18,44 +18,6 @@ The [Docker] container is deployed with the following image names:
* [docker.io/authelia/authelia](https://hub.docker.com/r/authelia/authelia)
* [ghcr.io/authelia/authelia](https://github.com/authelia/authelia/pkgs/container/authelia)
## Get Started
It's __*strongly recommended*__ that users setting up *Authelia* for the first time take a look at our
[Get Started](../prologue/get-started.md) guide. This takes you through various steps which are essential to
bootstrapping *Authelia*.
## Container
### Environment Variables
Several environment variables apply specifically to the official container. This table documents them. It is important
to note these environment variables are specific to the container and have no effect on the *Authelia* daemon itself and
this section is not meant to document the daemon environment variables.
| Name | Default | Usage |
|:-----:|:-------:|:---------------------------------------------------------------------------------------------:|
| PUID | 0 | If the container is running as UID 0, it will drop privileges to this UID via the entrypoint |
| PGID | 0 | If the container is running as UID 0, it will drop privileges to this GID via the entrypoint |
| UMASK | N/A | If set the container will run with the provided UMASK by running the `umask ${UMASK}` command |
### Permission Context
By default the container runs as the configured [Docker] daemon user. Users can control this behaviour in several ways.
The first and recommended way is instructing the [Docker] daemon to run the *Authelia* container as another user. See
the [docker run] or [Docker Compose file reference documentation](https://docs.docker.com/compose/compose-file/05-services/#user)
for more information. The best part of this method is the process will never have privileged access, and the only
negative is the user must manually configure the filesystem permissions correctly.
The second method is by using the environment variables listed above. The downside to this method is that the entrypoint
itself will run as UID 0 (root). The advantage is the container will automatically set owner and permissions on the
filesystem correctly.
The last method which is beyond our documentation or support is using the
[user namespace](https://docs.docker.com/engine/security/userns-remap/) facility [Docker] provides.
[docker run]: https://docs.docker.com/engine/reference/commandline/run/
## Docker Compose
We provide two main [Docker Compose] examples which can be utilized to help test *Authelia* or can be adapted into your
@ -65,6 +27,12 @@ existing [Docker Compose].
* [Bundle: lite](#lite)
* [Bundle: local](#local)
### Get Started
It's __*strongly recommended*__ that users setting up *Authelia* for the first time take a look at our
[Get Started](../prologue/get-started.md) guide. This takes you through various steps which are essential to
bootstrapping *Authelia*.
### Standalone Example
The following examples are [Docker Compose] deployments with just *Authelia* and no bundled applications or
@ -92,35 +60,35 @@ Use this [Standalone Example](#standalone-example) if you want to use
version: "3.8"
secrets:
JWT_SECRET:
file: '${PWD}/data/authelia/secrets/JWT_SECRET'
file: ${PWD}/data/authelia/secrets/JWT_SECRET
SESSION_SECRET:
file: '${PWD}/data/authelia/secrets/SESSION_SECRET'
file: ${PWD}/data/authelia/secrets/SESSION_SECRET
STORAGE_PASSWORD:
file: '${PWD}/data/authelia/secrets/STORAGE_PASSWORD'
file: ${PWD}/data/authelia/secrets/STORAGE_PASSWORD
STORAGE_ENCRYPTION_KEY:
file: '${PWD}/data/authelia/secrets/STORAGE_ENCRYPTION_KEY'
file: ${PWD}/data/authelia/secrets/STORAGE_ENCRYPTION_KEY
services:
authelia:
container_name: 'authelia'
image: 'docker.io/authelia/authelia:latest'
restart: 'unless-stopped'
container_name: authelia
image: docker.io/authelia/authelia:latest
restart: unless-stopped
networks:
net:
aliases: []
expose:
- 9091
secrets: ['JWT_SECRET', 'SESSION_SECRET', 'STORAGE_PASSWORD', 'STORAGE_ENCRYPTION_KEY']
secrets: [JWT_SECRET, SESSION_SECRET, STORAGE_PASSWORD, STORAGE_ENCRYPTION_KEY]
environment:
AUTHELIA_JWT_SECRET_FILE: '/run/secrets/JWT_SECRET'
AUTHELIA_SESSION_SECRET_FILE: '/run/secrets/SESSION_SECRET'
AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE: '/run/secrets/STORAGE_PASSWORD'
AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE: '/run/secrets/STORAGE_ENCRYPTION_KEY'
AUTHELIA_JWT_SECRET_FILE: /run/secrets/JWT_SECRET
AUTHELIA_SESSION_SECRET_FILE: /run/secrets/SESSION_SECRET
AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE: /run/secrets/STORAGE_PASSWORD
AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE: /run/secrets/STORAGE_ENCRYPTION_KEY
volumes:
- '${PWD}/data/authelia/config:/config'
- ${PWD}/data/authelia/config:/config
networks:
net:
external: true
name: 'net'
name: net
...
```
{{< /details >}}
@ -136,26 +104,26 @@ Use this [Standalone Example](#standalone-example) if you want to use a standard
version: "3.8"
services:
authelia:
container_name: 'authelia'
image: 'docker.io/authelia/authelia:latest'
restart: 'unless-stopped'
container_name: authelia
image: docker.io/authelia/authelia:latest
restart: unless-stopped
networks:
net:
aliases: []
expose:
- 9091
environment:
AUTHELIA_JWT_SECRET_FILE: '/secrets/JWT_SECRET'
AUTHELIA_SESSION_SECRET_FILE: '/secrets/SESSION_SECRET'
AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE: '/secrets/STORAGE_PASSWORD'
AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE: '/secrets/STORAGE_ENCRYPTION_KEY'
AUTHELIA_JWT_SECRET_FILE: /secrets/JWT_SECRET
AUTHELIA_SESSION_SECRET_FILE: /secrets/SESSION_SECRET
AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE: /secrets/STORAGE_PASSWORD
AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE: /secrets/STORAGE_ENCRYPTION_KEY
volumes:
- '${PWD}/data/authelia/config:/config'
- '${PWD}/data/authelia/secrets:/secrets'
- ${PWD}/data/authelia/config:/config
- ${PWD}/data/authelia/secrets:/secrets
networks:
net:
external: true
name: 'net'
name: net
```
...
{{< /details >}}
@ -210,7 +178,7 @@ running the following command:
grep -Eo '"https://.*" ' ./authelia/notification.txt.
```
## Frequently Asked Questions
## FAQ
#### Running the Proxy on the Host Instead of in a Container

View File

@ -63,7 +63,7 @@ spec:
...
```
## Frequently Asked Questions
## FAQ
### RAM usage

View File

@ -55,16 +55,14 @@ In your Authelia configuration you will need to enter and update the following v
base_dn: DC=example,DC=com
additional_users_dn: OU=users
users_filter: (&(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person))
username_attribute: uid
mail_attribute: mail
display_name_attribute: displayName
additional_groups_dn: OU=groups
groups_filter: (&(member=UID={input},OU=users,DC=example,DC=com)(objectClass=groupOfNames))
group_name_attribute: cn
user: UID=authelia,OU=service accounts,DC=example,DC=com
password: "SUPER_COMPLEX_PASSWORD"
attributes:
distinguished_name: 'distinguishedName'
username: 'uid'
mail: 'mail'
member_of: 'memberOf'
group_name: 'cn'
```
Following this, restart Authelia, and you should be able to begin using LDAP integration for your user logins, with
Authelia taking the email attribute for users straight from the 'mail' attribute within the LDAP object.
@ -102,18 +100,16 @@ In your Authelia configuration you will need to enter and update the following v
skip_verify: true
minimum_version: TLS1.2
base_dn: dc=example,DC=com
username_attribute: uid
additional_users_dn: CN=users,CN=accounts
users_filter: (&(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person))
additional_groups_dn: OU=groups
groups_filter: (&(member=UID={input},CN=users,CN=accounts,DC=example,DC=com)(objectClass=groupOfNames))
group_name_attribute: cn
mail_attribute: mail
display_name_attribute: displayName
user: UID=authelia,CN=users,CN=accounts,DC=example,DC=com
password: "SUPER_COMPLEX_PASSWORD"
attributes:
distinguished_name: 'distinguishedName'
username: 'uid'
mail: 'mail'
member_of: 'memberOf'
group_name: 'cn'
```
Following this, restart Authelia, and you should be able to begin using LDAP integration for your user logins, with
Authelia taking the email attribute for users straight from the 'mail' attribute within the LDAP object.
@ -143,21 +139,19 @@ ldap:
timeout: 5s
start_tls: false
base_dn: dc=example,DC=com
username_attribute: uid
additional_users_dn: OU=people
# To allow sign in both with username and email, one can use a filter like
# (&(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person))
users_filter: (&({username_attribute}={input})(objectClass=person))
additional_groups_dn: OU=groups
groups_filter: (member={dn})
group_name_attribute: cn
mail_attribute: mail
display_name_attribute: displayName
# The username and password of the admin or service user.
user: UID=authelia,OU=people,DC=example,DC=com
password: "SUPER_COMPLEX_PASSWORD"
attributes:
distinguished_name: 'distinguishedName'
username: 'uid'
mail: 'mail'
member_of: 'memberOf'
group_name: 'cn'
```
Following this, restart Authelia, and you should be able to begin using lldap integration for your user logins, with
Authelia taking the email attribute for users straight from the 'mail' attribute within the LDAP object.

View File

@ -1,6 +1,6 @@
---
title: "OpenID Connect 1.0"
description: "OpenID Connect 1.0 Integration"
title: "OpenID Connect"
description: "OpenID Connect Integration"
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false

View File

@ -1,6 +1,6 @@
---
title: "Apache Guacamole"
description: "Integrating Apache Guacamole with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Apache Guacamole with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-07-31T13:09:05+10:00
draft: false
@ -53,7 +53,7 @@ openid-groups-claim-type: groups
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with
[Apache Guacamole] which will operate with the above example:
```yaml
@ -78,7 +78,7 @@ identity_providers:
- 'id_token'
grant_types:
- 'implicit'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Argo CD"
description: "Integrating Argo CD with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Argo CD with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-07-13T04:27:30+10:00
draft: false
@ -56,7 +56,7 @@ requestedScopes:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Argo CD]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Argo CD]
which will operate with the above example:
```yaml
@ -77,7 +77,7 @@ identity_providers:
- 'groups'
- 'email'
- 'profile'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
- id: 'argocd-cli'
description: 'Argo CD (CLI)'
public: true
@ -90,7 +90,7 @@ identity_providers:
- 'email'
- 'profile'
- 'offline_access'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "BookStack"
description: "Integrating BookStack with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating BookStack with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -58,7 +58,7 @@ To configure [BookStack] to utilize Authelia as an [OpenID Connect 1.0] Provider
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [BookStack]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [BookStack]
which will operate with the above example:
```yaml
@ -78,7 +78,7 @@ identity_providers:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Cloudflare Zero Trust"
description: "Integrating Cloudflare Zero Trust with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Cloudflare Zero Trust with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -66,7 +66,7 @@ To configure [Cloudflare Zero Trust] to utilize Authelia as an [OpenID Connect 1
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Cloudflare]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Cloudflare]
which will operate with the above example:
```yaml
@ -86,7 +86,7 @@ identity_providers:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Firezone"
description: "Integrating Firezone with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Firezone with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-03-28T20:29:13+11:00
draft: false
@ -67,7 +67,7 @@ descriptions.
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Firezone] which
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Firezone] which
will operate with the above example:
```yaml
@ -89,7 +89,7 @@ identity_providers:
- 'openid'
- 'email'
- 'profile'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,7 +1,7 @@
---
title: "Frequently Asked Questions"
description: "Frequently Asked Questions regarding integrating the Authelia OpenID Connect 1.0 Provider with an OpenID Connect 1.0 Relying Party"
lead: "Frequently Asked Questions regarding integrating the Authelia OpenID Connect 1.0 Provider with an OpenID Connect 1.0 Relying Party."
description: "Frequently Asked Questions regarding integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party"
lead: "Frequently Asked Questions regarding integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party."
date: 2022-10-20T15:27:09+11:00
draft: false
images: []
@ -88,26 +88,6 @@ If you've configured Authelia alongside a proxy and are making a request directl
request via the proxy. If you're avoiding the proxy due to a DNS limitation see
[Solution: Configure DNS Appropriately](#configure-dns-appropriately) section.
### Why doesn't the access control configuration work with OpenID Connect 1.0?
The [access control](../../configuration/security/access-control.md) configuration contains several elements which are
not very compatible with OpenID Connect 1.0. They were designed with per-request authorizations in mind. In particular
the [resources](../../configuration/security/access-control.md#resources),
[query](../../configuration/security/access-control.md#query),
[methods](../../configuration/security/access-control.md#methods), and
[networks](../../configuration/security/access-control.md#networks) criteria are very specific to each request and to
some degree so are the [domain](../../configuration/security/access-control.md#domain) and
[domain regex](../../configuration/security/access-control.md#domainregex) criteria as the token is issued to the client
not a specific domain.
For these reasons we implemented the
[authorization policy](../../configuration/identity-providers/openid-connect/clients.md#authorizationpolicy) as a direct
option in the client. It's likely in the future that we'll expand this option to encompass the features that work well
with OpenID Connect 1.0 such as the [subject](../../configuration/security/access-control.md#subject) criteria which
reasonably be matched to an individual authorization policy. Because the other criteria are mostly geared towards
per-request authorization these criteria types are fairly unlikely to become part of OpenID Connect 1.0 as there are no
ways to apply these criteria except during the initial authorization request.
## Solutions
The following section details solutions for multiple of the questions above.

View File

@ -1,6 +1,6 @@
---
title: "Gitea"
description: "Integrating Gitea with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Gitea with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-07-01T13:07:02+10:00
draft: false
@ -77,7 +77,7 @@ descriptions.
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Gitea] which
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Gitea] which
will operate with the above example:
```yaml
@ -97,7 +97,7 @@ identity_providers:
- 'openid'
- 'email'
- 'profile'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "GitLab"
description: "Integrating GitLab with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating GitLab with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -69,7 +69,7 @@ gitlab_rails['omniauth_providers'] = [
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [GitLab]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [GitLab]
which will operate with the above example:
```yaml
@ -90,7 +90,7 @@ identity_providers:
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Grafana"
description: "Integrating Grafana with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Grafana with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -87,7 +87,7 @@ Configure the following environment variables:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Grafana]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Grafana]
which will operate with the above example:
```yaml
@ -108,7 +108,7 @@ identity_providers:
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Harbor"
description: "Integrating Harbor with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Harbor with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -60,7 +60,7 @@ To configure [Harbor] to utilize Authelia as an [OpenID Connect 1.0] Provider:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Harbor]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Harbor]
which will operate with the above example:
```yaml
@ -81,7 +81,7 @@ identity_providers:
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "HashiCorp Vault"
description: "Integrating HashiCorp Vault with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating HashiCorp Vault with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -43,7 +43,7 @@ To configure [HashiCorp Vault] to utilize Authelia as an [OpenID Connect 1.0] Pr
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [HashiCorp Vault]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [HashiCorp Vault]
which will operate with the above example:
```yaml
@ -65,7 +65,7 @@ identity_providers:
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,7 +1,7 @@
---
title: "OpenID Connect"
description: "An introduction into integrating the Authelia OpenID Connect 1.0 Provider with an OpenID Connect 1.0 Relying Party"
lead: "An introduction into integrating the Authelia OpenID Connect 1.0 Provider with an OpenID Connect 1.0 Relying Party."
description: "An introduction into integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party"
lead: "An introduction into integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party."
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
@ -18,10 +18,8 @@ Authelia can act as an [OpenID Connect 1.0] Provider as part of an open beta. Th
specifics that can be used for integrating Authelia with an [OpenID Connect 1.0] Relying Party, as well as specific
documentation for some [OpenID Connect 1.0] Relying Party implementations.
See the [OpenID Connect 1.0 Provider](../../configuration/identity-providers/openid-connect/provider.md) and
[OpenID Connect 1.0 Clients](../../configuration/identity-providers/openid-connect/clients.md) configuration guides for
information on how to configure the Authelia [OpenID Connect 1.0] Provider (note the clients guide is for configuring
the registered clients in the provider).
See the [configuration documentation](../../configuration/identity-providers/open-id-connect.md) for information on how
to configure the Authelia [OpenID Connect 1.0] Provider.
This page is intended as an integration reference point for any implementers who wish to integrate an
[OpenID Connect 1.0] Relying Party (client application) either as a developer or user of the third party Reyling Party.
@ -103,49 +101,6 @@ This scope includes the profile information the authentication backend reports a
| preferred_username | string | username | The username the user used to login with |
| name | string | display_name | The users display name |
## Signing and Encryption Algorithms
[OpenID Connect 1.0] and OAuth 2.0 support a wide variety of signature and encryption algorithms. Authelia supports
a subset of these.
### Response Object
Authelia's response objects can have the following signature algorithms:
| Algorithm | Key Type | Hashing Algorithm | Use | JWK Default Conditions | Notes |
|:---------:|:-----------:|:-----------------:|:---------:|:--------------------------------------------:|:----------------------------------------------------:|
| RS256 | RSA | SHA-256 | Signature | RSA Private Key without a specific algorithm | Requires an RSA Private Key with 2048 bits or more |
| RS384 | RSA | SHA-384 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
| RS512 | RSA | SHA-512 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
| ES256 | ECDSA P-256 | SHA-256 | Signature | ECDSA Private Key with the P-256 curve | |
| ES384 | ECDSA P-384 | SHA-384 | Signature | ECDSA Private Key with the P-384 curve | |
| ES512 | ECDSA P-521 | SHA-512 | Signature | ECDSA Private Key with the P-521 curve | Requires an ECDSA Private Key with 2048 bits or more |
| PS256 | RSA (MGF1) | SHA-256 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
| PS384 | RSA (MGF1) | SHA-384 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
| PS512 | RSA (MGF1) | SHA-512 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
### Request Object
Authelia accepts a wide variety of request object types.
| Algorithm | Key Type | Hashing Algorithm | Use | Notes |
|:---------:|:------------------:|:-----------------:|:---------:|:--------------------------------------------------:|
| none | None | None | N/A | N/A |
| HS256 | HMAC Shared Secret | SHA-256 | Signature | [Client Authentication Method] `client_secret_jwt` |
| HS384 | HMAC Shared Secret | SHA-384 | Signature | [Client Authentication Method] `client_secret_jwt` |
| HS512 | HMAC Shared Secret | SHA-512 | Signature | [Client Authentication Method] `client_secret_jwt` |
| RS256 | RSA | SHA-256 | Signature | [Client Authentication Method] `private_key_jwt` |
| RS384 | RSA | SHA-384 | Signature | [Client Authentication Method] `private_key_jwt` |
| RS512 | RSA | SHA-512 | Signature | [Client Authentication Method] `private_key_jwt` |
| ES256 | ECDSA P-256 | SHA-256 | Signature | [Client Authentication Method] `private_key_jwt` |
| ES384 | ECDSA P-384 | SHA-384 | Signature | [Client Authentication Method] `private_key_jwt` |
| ES512 | ECDSA P-521 | SHA-512 | Signature | [Client Authentication Method] `private_key_jwt` |
| PS256 | RSA (MFG1) | SHA-256 | Signature | [Client Authentication Method] `private_key_jwt` |
| PS384 | RSA (MFG1) | SHA-384 | Signature | [Client Authentication Method] `private_key_jwt` |
| PS512 | RSA (MFG1) | SHA-512 | Signature | [Client Authentication Method] `private_key_jwt` |
[Client Authentication Method]: #client-authentication-method
## Parameters
The following section describes advanced parameters which can be used in various endpoints as well as their related
@ -219,8 +174,8 @@ specification and the [OAuth 2.0 - Client Types] specification for more informat
|:------------------------------------:|:-----------------------------:|:----------------------:|:-----------------------:|:--------------------------------------------------------:|
| Secret via HTTP Basic Auth Scheme | `client_secret_basic` | `confidential` | N/A | N/A |
| Secret via HTTP POST Body | `client_secret_post` | `confidential` | N/A | N/A |
| JWT (signed by secret) | `client_secret_jwt` | `confidential` | N/A | `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| JWT (signed by private key) | `private_key_jwt` | `confidential` | N/A | `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| JWT (signed by secret) | `client_secret_jwt` | Not Supported | N/A | `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| JWT (signed by private key) | `private_key_jwt` | Not Supported | N/A | `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| [OAuth 2.0 Mutual-TLS] | `tls_client_auth` | Not Supported | N/A | N/A |
| [OAuth 2.0 Mutual-TLS] (Self Signed) | `self_signed_tls_client_auth` | Not Supported | N/A | N/A |
| No Authentication | `none` | `public` | `public` | N/A |
@ -255,7 +210,7 @@ Below is a list of the potential values we place in the [Claim] and their meanin
## User Information Signing Algorithm
The following table describes the response from the [UserInfo] endpoint depending on the
[userinfo_signing_alg](../../configuration/identity-providers/openid-connect/clients.md#userinfosigningalg).
[userinfo_signing_algorithm](../../configuration/identity-providers/open-id-connect.md#userinfosigningalgorithm).
| Signing Algorithm | Encoding | Content Type |
|:-----------------:|:------------:|:-----------------------------------:|
@ -265,7 +220,7 @@ The following table describes the response from the [UserInfo] endpoint dependin
## Endpoint Implementations
The following section documents the endpoints we implement and their respective paths. This information can
traditionally be discovered by relying parties that utilize [OpenID Connect Discovery 1.0], however this information may be
traditionally be discovered by relying parties that utilize [OpenID Connect Discovery], however this information may be
useful for clients which do not implement this.
The endpoints can be discovered easily by visiting the Discovery and Metadata endpoints. It is recommended regardless
@ -275,7 +230,7 @@ below.
These tables document the endpoints we currently support and their paths in the most recent version of Authelia. The
paths are appended to the end of the primary URL used to access Authelia. The tables use the url
https://auth.example.com as an example of the Authelia root URL which is also the OpenID Connect 1.0 Issuer.
https://auth.example.com as an example of the Authelia root URL which is also the OpenID Connect issuer.
### Well Known Discovery Endpoints
@ -283,12 +238,12 @@ These endpoints can be utilized to discover other endpoints and metadata about t
| Endpoint | Path |
|:-----------------------------------------:|:---------------------------------------------------------------:|
| [OpenID Connect Discovery 1.0] | https://auth.example.com/.well-known/openid-configuration |
| [OpenID Connect Discovery] | https://auth.example.com/.well-known/openid-configuration |
| [OAuth 2.0 Authorization Server Metadata] | https://auth.example.com/.well-known/oauth-authorization-server |
### Discoverable Endpoints
These endpoints implement OpenID Connect 1.0 Provider specifications.
These endpoints implement OpenID Connect elements.
| Endpoint | Path | Discovery Attribute |
|:-------------------------------:|:--------------------------------------------------------------:|:-------------------------------------:|
@ -365,7 +320,7 @@ The advantages of this approach are as follows:
[OpenID Connect 1.0]: https://openid.net/connect/
[OpenID Connect Discovery 1.0]: https://openid.net/specs/openid-connect-discovery-1_0.html
[OpenID Connect Discovery]: https://openid.net/specs/openid-connect-discovery-1_0.html
[OAuth 2.0 Authorization Server Metadata]: https://datatracker.ietf.org/doc/html/rfc8414
[JSON Web Key Set]: https://datatracker.ietf.org/doc/html/rfc7517#section-5

View File

@ -1,6 +1,6 @@
---
title: "Kasm Workspaces"
description: "Integrating Kasm Workspaces with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Kasm Workspaces with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-04-27T18:40:06+10:00
draft: false
@ -80,7 +80,7 @@ identity_providers:
- 'groups'
- 'email'
consent_mode: 'implicit'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Komga"
description: "Integrating Komga with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Komga with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-08-26T11:39:00+10:00
draft: false
@ -65,7 +65,7 @@ spring:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Komga]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Komga]
which will operate with the above example:
```yaml
@ -87,7 +87,7 @@ identity_providers:
- 'email'
grant_types:
- 'authorization_code'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "MinIO"
description: "Integrating MinIO with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating MinIO with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-03-21T11:21:23+11:00
draft: false
@ -63,7 +63,7 @@ To configure [MinIO] to utilize Authelia as an [OpenID Connect 1.0] Provider:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [MinIO]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [MinIO]
which will operate with the above example:
```yaml
@ -84,7 +84,7 @@ identity_providers:
- 'profile'
- 'email'
- 'groups'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Misago"
description: "Integrating Misago with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Misago with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-03-14T08:51:13+11:00
draft: false
@ -79,7 +79,7 @@ To configure [Misago] to utilize Authelia as an [OpenID Connect 1.0](https://www
### Authelia
The following YAML configuration is an example **Authelia** [client configuration](https://www.authelia.com/configuration/identity-providers/openid-connect/#clients) for use with [Misago] which will operate with the above example:
The following YAML configuration is an example **Authelia** [client configuration](https://www.authelia.com/configuration/identity-providers/open-id-connect/#clients) for use with [Misago] which will operate with the above example:
```yaml
identity_providers:
@ -104,7 +104,7 @@ identity_providers:
- 'code'
response_modes:
- 'query'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
---

View File

@ -1,6 +1,6 @@
---
title: "Nextcloud"
description: "Integrating Nextcloud with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Nextcloud with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -86,7 +86,7 @@ $CONFIG = array (
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Nextcloud]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Nextcloud]
which will operate with the above example:
```yaml
@ -107,7 +107,7 @@ identity_providers:
- 'profile'
- 'email'
- 'groups'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Outline"
description: "Integrating Outline with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Outline with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-08-12T09:11:42+10:00
draft: false
@ -60,7 +60,7 @@ OIDC_SCOPES="openid offline_access profile email"
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Outline]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Outline]
which will operate with the above example:
```yaml
@ -81,7 +81,7 @@ identity_providers:
- 'offline_access'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Portainer"
description: "Integrating Portainer with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Portainer with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -61,7 +61,7 @@ To configure [Portainer] to utilize Authelia as an [OpenID Connect 1.0] Provider
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Portainer]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Portainer]
which will operate with the above example:
```yaml
@ -82,7 +82,7 @@ identity_providers:
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Proxmox"
description: "Integrating Proxmox with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Proxmox with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -65,7 +65,7 @@ To configure [Proxmox] to utilize Authelia as an [OpenID Connect 1.0] Provider:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Proxmox]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Proxmox]
which will operate with the above example:
```yaml
@ -85,7 +85,7 @@ identity_providers:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Seafile"
description: "Integrating Seafile with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Seafile with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -69,7 +69,7 @@ OAUTH_ATTRIBUTE_MAP = {
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Seafile]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Seafile]
which will operate with the above example:
```yaml
@ -89,7 +89,7 @@ identity_providers:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Synapse"
description: "Integrating Synapse with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Synapse with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -63,7 +63,7 @@ oidc_providers:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Synapse]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Synapse]
which will operate with the above example:
```yaml
@ -83,7 +83,7 @@ identity_providers:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Synology DSM"
description: "Integrating Synology DSM with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Synology DSM with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-10-18T21:22:13+11:00
draft: false
@ -65,7 +65,7 @@ To configure [Synology DSM] to utilize Authelia as an [OpenID Connect 1.0] Provi
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Synology DSM]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Synology DSM]
which will operate with the above example:
```yaml
@ -86,7 +86,7 @@ identity_providers:
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
userinfo_signing_algorithm: 'none'
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Tailscale"
description: "Integrating Tailscale with the Authelia OpenID Connect 1.0 Provider."
description: "Using Authelia as the Tailscale OpenID Connect Provider."
lead: ""
date: 2023-04-23T10:06:28+10:00
draft: false

View File

@ -36,7 +36,7 @@ In addition to the `https` scheme requirement for Authelia itself:
1. Due to the fact a cookie is used, it's an intentional design decision that *__ALL__* applications/domains protected via
this method *__MUST__* use secure schemes (`https` and `wss`) for all of their communication.
### OpenID Connect 1.0
### OpenID Connect
No additional requirements other than the use of the `https` scheme for Authelia itself exist excluding those mandated
by the relevant specifications.
@ -93,11 +93,6 @@ recommended that you read the relevant [Proxy Integration Documentation](../prox
recommend viewing the dedicated [Kubernetes Documentation](../kubernetes/introduction.md) prior to viewing the
[Proxy Integration Documentation](../proxies/introduction.md).*
## Additional Useful Links
See the [Frequently Asked Questions](../../reference/guides/frequently-asked-questions.md) for helpful sections of the
documentation which may answer specific questions.
## Moving to Production
We consider it important to do several things in moving to a production environment.

View File

@ -466,6 +466,14 @@ and is paired with [authelia-location.conf](#authelia-locationconf).*
## Send a subrequest to Authelia to verify if the user is authenticated and has permission to access the resource.
auth_request /internal/authelia/authz;
## Save the upstream authorization response headers from Authelia to variables.
auth_request_set $authorization $upstream_http_authorization;
auth_request_set $proxy_authorization $upstream_http_proxy_authorization;
## Inject the authorization response headers from the variables into the request made to the backend.
proxy_set_header Authorization $authorization;
proxy_set_header Proxy-Authorization $proxy_authorization;
## Save the upstream metadata response headers from Authelia to variables.
auth_request_set $user $upstream_http_remote_user;
auth_request_set $groups $upstream_http_remote_groups;
@ -478,6 +486,10 @@ proxy_set_header Remote-Groups $groups;
proxy_set_header Remote-Email $email;
proxy_set_header Remote-Name $name;
## Include the Set-Cookie header if present.
auth_request_set $cookie $upstream_http_set_cookie;
add_header Set-Cookie $cookie;
## Configure the redirection when the authz failure occurs. Lines starting with 'Modern Method' and 'Legacy Method'
## should be commented / uncommented as pairs. The modern method uses the session cookies configuration's authelia_url
## value to determine the redirection URL here. It's much simpler and compatible with the mutli-cookie domain easily.

View File

@ -58,7 +58,7 @@ In addition this represents a bad user experience in some instances such as:
* Users sometimes visit the `https://app.example.com/authelia` URL which doesn't automatically redirect the user to
`https://app.example.com` (if they visit `https://app.example.com` then they'll be redirected to authenticate then
redirected back to their original URL)
* Administrators may wish to setup [OpenID Connect 1.0](../../configuration/identity-providers/openid-connect/provider.md) in
* Administrators may wish to setup [OpenID Connect 1.0](../../configuration/identity-providers/open-id-connect.md) in
which case it also doesn't represent a good user experience as the `issuer` will be
`https://app.example.com/authelia` for example
* Using the [SWAG] default configurations are more difficult to support as our specific familiarity is with our own

View File

@ -517,7 +517,7 @@ http:
```
{{< /details >}}
## Frequently Asked Questions
## FAQ
### Basic Authentication

View File

@ -39,7 +39,7 @@ Now that Authelia is configured, pass the first factor and select the Push notif
You should now receive a notification on your mobile phone with all the details about the authentication request. In
case you have multiple devices available, you will be asked to select your preferred device.
## Frequently Asked Questions
## FAQ
### Why don't I have access to the *Push Notification* option?

View File

@ -43,7 +43,7 @@ requested:
Easy, right?!
## Frequently Asked Questions
## FAQ
### Can I register multiple FIDO2 WebAuthn devices?

View File

@ -16,6 +16,6 @@ configure your applications to use Authelia as an [OpenID Connect 1.0 Provider](
currently operate as an [OpenID Connect 1.0 Relying Party](https://openid.net/connect/). This like all single-sign on
technologies requires support by the protected application.
See the [OpenID Connect 1.0 Provider Configuration Guide](../../configuration/identity-providers/openid-connect/provider.md), and the
See the [OpenID Connect 1.0 Configuration Guide](../../configuration/identity-providers/open-id-connect.md) and the
[OpenID Connect 1.0 Integration Guide](../../integration/openid-connect/introduction.md) for more information.

View File

@ -86,5 +86,5 @@ It's important to note that Authelia is considered running in a trusted environm
transmitted unsigned to the backends, meaning a malicious user within the network could pretend to be
Authelia and send those headers to bypass authentication and gain access to the service. This could be mitigated by
transmitting those headers with a digital signature which could be verified by the backend however, many backends
just won't support it. It has therefore been decided to invest in OpenID Connect 1.0 instead to solve that
authentication delegation problem.
just won't support it. It has therefore been decided to invest in OpenID Connect instead to solve that authentication
delegation problem.

View File

@ -12,24 +12,6 @@ weight: 220
toc: true
---
## Miscellaneous
- [Docker](../../integration/deployment/docker.md#frequently-asked-questions)
- [Development](../../contributing/development/environment.md#frequently-asked-questions)
## Authentication
- [WebAuthn](../../overview/authentication/security-key/index.md#frequently-asked-questions)
- [Duo](../../overview/authentication/push-notification/index.md#frequently-asked-questions)
## Proxies
- [Traefik](../../integration/proxies/traefik.md#frequently-asked-questions)
## Kubernetes
- [General](../../integration/kubernetes/introduction.md#frequently-asked-questions)
## Identity Providers
- [OpenID Connect 1.0 Integration](../../integration/openid-connect/frequently-asked-questions.md)

View File

@ -75,32 +75,6 @@ The following implementations exist:
[GLAuth]: https://glauth.github.io/
[RFC2307bis]: https://datatracker.ietf.org/doc/html/draft-howard-rfc2307bis-02
### Group Search Modes
There are currently two group search modes that exist.
#### Search Mode: filter
The `filter` search mode is the default search mode. Generally this is recommended.
#### Search Mode: memberof
The `memberof` search mode is a special search mode. Generally this is discouraged and is currently experimental.
Some systems provide a `memberOf` attribute which may include additional groups that the user is a member of. This
search mode allows using this attribute as a method to determine their groups. How it works is the search is performed
against the base with the subtree scope and the groups filter must include one of the `{memberof:*}` replacements, and
the distinguished names of the results from the search are compared (case-insensitive) against the users `memberOf`
attribute to determine if they are members.
This means:
1. The groups still must be in the search base that you have configured.
2. The `memberOf` attribute *__MUST__* include the distinguished name of the group.
3. If the `{memberof:dn}` replacement is used:
1. The distinguished name *__MUST__* be searchable by your directory server.
3. The first relative distinguished name of the distinguished name *__MUST__* be search
### Filter replacements
Various replacements occur in the user and groups filter. The replacements either occur at startup or upon an LDAP
@ -111,21 +85,14 @@ is ever established. In addition to this, during the startup phase we purposeful
phase replacements exist so we only have to check if the replacement is necessary once, and we don't needlessly perform
every possible replacement on every search regardless of if it's needed or not.
#### General filter replacements
| Placeholder | Phase | Replacement |
|:------------------------------:|:-------:|:-------------------------------------------:|
| {distinguished_name_attribute} | startup | The configured distinguished name attribute |
| {username_attribute} | startup | The configured username attribute |
| {mail_attribute} | startup | The configured mail attribute |
| {display_name_attribute} | startup | The configured display name attribute |
| {member_of_attribute} | startup | The configured member of attribute |
| {input} | search | The input into the username field |
#### Users filter replacements
| Placeholder | Phase | Replacement |
|:------------------------------:|:-------:|:----------------------------------------------------------------------------------------------------------------:|
|:------------------------:|:-------:|:----------------------------------------------------------------------------------------------------------------:|
| {username_attribute} | startup | The configured username attribute |
| {mail_attribute} | startup | The configured mail attribute |
| {display_name_attribute} | startup | The configured display name attribute |
| {input} | search | The input into the username field |
| {date-time:generalized} | search | The current UTC time formatted as a LDAP generalized time in the format of `20060102150405.0Z` |
| {date-time:unix} | search | The current time formatted as a Unix epoch |
| {date-time:microsoft-nt} | search | The current time formatted as a Microsoft NT epoch which is used by some Microsoft [Active Directory] attributes |
@ -133,43 +100,10 @@ every possible replacement on every search regardless of if it's needed or not.
#### Groups filter replacements
| Placeholder | Phase | Replacement |
|:--------------:|:------:|:----------------------------------------------------------------------------------------------------------------------------------------------------:|
|:-----------:|:------:|:-------------------------------------------------------------------------:|
| {input} | search | The input into the username field |
| {username} | search | The username from the profile lookup obtained from the username attribute |
| {dn} | search | The distinguished name from the profile lookup |
| {memberof:dn} | search | See the detailed section below |
| {memberof:rdn} | search | Only allowed with the `memberof` search method and contains the first relative distinguished name of every `memberOf` entry a use has in parenthesis |
##### memberof:dn
Requirements:
1. Must be using the `memberof` search mode.
2. Must have the distinguished name attribute configured in Authelia.
3. Directory server must support searching by the distinguished name attribute (many directory services *__DO NOT__*
have a distinguished name attribute).
##### memberof:rdn
Requirements:
1. Must be using the `memberof` search mode.
2. Directory server must support searching by the first relative distinguished name as an attribute.
Splits every `memberOf` value to obtain th e first relative distinguished name and joins all of those after surrounding
them in parenthesis. This makes the general suggested filter pattern for this particular replacement
`(|{memberof:rdn})`. The format of this value is as follows:
```text
(<RDN>)
```
For example if the user has the following distinguished names in their object:
- CN=abc,OU=groups,DC=example,DC=com
- CN=xyz,OU=groups,DC=example,DC=com
The value will be replaced with `(CN=abc)(CN=xyz)` which using the suggested pattern for the filter becomes
`(|(CN=abc)(CN=xyz))` which will then return any user that as a `CN` of `abc` or `xyz`.
### Defaults
@ -188,14 +122,14 @@ The following set defaults for the `additional_users_dn` and `additional_groups_
This table describes the attribute defaults for each implementation. i.e. the username_attribute is described by the
Username column.
| Implementation | Username | Display Name | Mail | Group Name | Distinguished Name | Member Of |
|:---------------:|:--------------:|:------------:|:----:|:----------:|:------------------:|:---------:|
| custom | N/A | displayName | mail | cn | N/A | N/A |
| activedirectory | sAMAccountName | displayName | mail | cn | distinguishedName | memberOf |
| rfc2307bis | uid | displayName | mail | cn | N/A | memberOf |
| freeipa | uid | displayName | mail | cn | N/A | memberOf |
| lldap | uid | cn | mail | cn | N/A | memberOf |
| glauth | cn | description | mail | cn | N/A | memberOf |
| Implementation | Username | Display Name | Mail | Group Name |
|:---------------:|:--------------:|:------------:|:----:|:----------:|
| custom | N/A | displayName | mail | cn |
| activedirectory | sAMAccountName | displayName | mail | cn |
| rfc2307bis | uid | displayName | mail | cn |
| freeipa | uid | displayName | mail | cn |
| lldap | uid | cn | mail | cn |
| glauth | cn | description | mail | cn |
#### Filter defaults
@ -212,8 +146,8 @@ the following conditions:
- Their password is expired:
- The [Active Directory] implementation achieves this via the `(!(pwdLastSet=0))` filter.
- The [FreeIPA] implementation achieves this via the `(krbPasswordExpiration>={date-time:generalized})` filter.
- The [RFC2307bis] implementation achieves this via the `(!(pwdReset=TRUE))` filter.
- The following implementations have no suitable attribute for this as far as we're aware:
- [RFC2307bis]
- [GLAuth]
- [lldap]
- Their account is expired:
@ -228,7 +162,7 @@ the following conditions:
|:---------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------:|
| custom | N/A | N/A |
| activedirectory | (&(&#124;({username_attribute}={input})({mail_attribute}={input}))(sAMAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(pwdLastSet=0))(&#124;(!(accountExpires=*))(accountExpires=0)(accountExpires>={date-time:microsoft-nt}))) | (&(member={dn})(&#124;(sAMAccountType=268435456)(sAMAccountType=536870912))) |
| rfc2307bis | (&(&#124;({username_attribute}={input})({mail_attribute}={input}))(&#124;(objectClass=inetOrgPerson)(objectClass=organizationalPerson))(!(pwdReset=TRUE))) | (&(&#124;(member={dn})(uniqueMember={dn}))(&#124;(objectClass=groupOfNames)(objectClass=groupOfUniqueNames)(objectClass=groupOfMembers))) |
| rfc2307bis | (&(&#124;({username_attribute}={input})({mail_attribute}={input}))(&#124;(objectClass=inetOrgPerson)(objectClass=organizationalPerson))) | (&(&#124;(member={dn})(uniqueMember={dn}))(&#124;(objectClass=groupOfNames)(objectClass=groupOfUniqueNames)(objectClass=groupOfMembers))) |
| freeipa | (&(&#124;({username_attribute}={input})({mail_attribute}={input}))(objectClass=person)(!(nsAccountLock=TRUE))(krbPasswordExpiration>={date-time:generalized})(&#124;(!(krbPrincipalExpiration=*))(krbPrincipalExpiration>={date-time:generalized}))) | (&(member={dn})(objectClass=groupOfNames)) |
| lldap | (&(&#124;({username_attribute}={input})({mail_attribute}={input}))(objectClass=person)) | (&(member={dn})(objectClass=groupOfNames)) |
| glauth | (&(&#124;({username_attribute}={input})({mail_attribute}={input}))(objectClass=posixAccount)(!(accountStatus=inactive))) | (&(uniqueMember={dn})(objectClass=posixGroup)) |

View File

@ -1,25 +0,0 @@
---
title: "Time-based OTP Applications"
description: "A Time-based OTP Application integration reference guide"
lead: "This section contains a Time-based OTP Application integration reference guide for Authelia."
date: 2023-05-07T17:52:47+10:00
draft: false
images: []
menu:
reference:
parent: "integrations"
weight: 320
toc: true
---
## Settings
Authelia allows for a wide variety of time-based OTP settings. There are several applications which can support these
algorithms and this matrix is a guide on applications that have been tested that work. It should not be assumed if an
application is on this list that the information is correct for the current version of a product and it's likely they
may now support some that were not previously supported, or in rare cases they may support less than they previously
did.
{{< table-totp-support >}}

View File

@ -14,8 +14,8 @@ aliases:
- /r/dashboard
---
This feature has several major impacts on other roadmap items. For example several OpenID Connect 1.0 features would
greatly benefit from a dashboard. It would also be important when we implement WebAuthn features like passwordless
This feature has several major impacts on other roadmap items. For example several OpenID Connect features would greatly
benefit from a dashboard. It would also be important when we implement WebAuthn features like passwordless
authentication allowing users to intentionally register a passwordless credential.
## Stages

View File

@ -1,7 +1,7 @@
---
title: "OpenID Connect 1.0"
description: "Authelia OpenID Connect 1.0 Provider Implementation"
lead: "The OpenID Connect 1.0 Provider role is a very useful but complex feature to enhance interoperability of Authelia with other products. "
title: "OpenID Connect"
description: "Authelia OpenID Connect Implementation"
lead: "The OpenID Connect Provider role is a very useful but complex feature to enhance interoperability of Authelia with other products. "
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
@ -15,15 +15,14 @@ aliases:
- /docs/roadmap/oidc.html
---
We have decided to implement [OpenID Connect 1.0] as a beta feature, it's suggested you only utilize it for testing and
providing feedback, and should take caution in relying on it in production as of now. [OpenID Connect 1.0] and it's
related endpoints are not enabled by default unless you specifically configure the [OpenID Connect 1.0] section.
We have decided to implement [OpenID Connect] as a beta feature, it's suggested you only utilize it for testing and
providing feedback, and should take caution in relying on it in production as of now. [OpenID Connect] and it's related
endpoints are not enabled by default unless you specifically configure the [OpenID Connect] section.
As [OpenID Connect 1.0] is fairly complex (the [OpenID Connect 1.0] Provider role especially so) it's intentional that
it is both a beta and that the implemented features are part of a thoughtful roadmap. Items that are not immediately
obvious as required (i.e. bug fixes or spec features), will likely be discussed in team meetings or on GitHub issues
before being added to the list. We want to implement this feature in a very thoughtful way in order to avoid security
issues.
As [OpenID Connect] is fairly complex (the [OpenID Connect] Provider role especially so) it's intentional that it is
both a beta and that the implemented features are part of a thoughtful roadmap. Items that are not immediately obvious
as required (i.e. bug fixes or spec features), will likely be discussed in team meetings or on GitHub issues before
being added to the list. We want to implement this feature in a very thoughtful way in order to avoid security issues.
## Stages
@ -39,7 +38,7 @@ Feature List:
* [User Consent](https://openid.net/specs/openid-connect-core-1_0.html#Consent)
* [Authorization Code Flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps)
* [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)
* [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html)
* [RS256 Signature Strategy](https://datatracker.ietf.org/doc/html/rfc7518#section-3.1)
* Per Client Scope/Grant Type/Response Type Restriction
* Per Client Authorization Policy (1FA/2FA)
@ -65,7 +64,7 @@ Feature List:
Feature List:
* [RFC7636: Proof Key for Code Exchange (PKCE)] for Authorization Code Flow
* [Proof Key Code Exchange (PKCE)] for Authorization Code Flow
* Claims:
* `preferred_username` - sending the username in this claim instead of the `sub` claim.
@ -80,12 +79,12 @@ Feature List:
* Auditable Information
* Subject to User Mapping
* Opaque [RFC4122] UUID v4's for subject identifiers
* Support for Pairwise and Plain subject identifier types as per [OpenID Connect Core 1.0 (Subject Identifier Types)]
* Utilize the pairwise example method 3 as per [OpenID Connect Core 1.0 (Pairwise Identifier Algorithm)]
* Support for Pairwise and Plain subject identifier types as per [OpenID Connect Core (Subject Identifier Types)]
* Utilize the pairwise example method 3 as per [OpenID Connect Core (Pairwise Identifier Algorithm)]
* Claims:
* `sub` - replace username with opaque random [RFC4122] UUID v4
* `amr` - authentication method references as per [RFC8176]
* `azp` - authorized party as per [OpenID Connect Core 1.0 (ID Token)]
* `azp` - authorized party as per [OpenID Connect Core (ID Token)]
* `client_id` - the Client ID as per [RFC8693 Section 4.3]
* [Cross Origin Resource Sharing] (CORS):
* Automatically allow all cross-origin requests to the discovery endpoints
@ -107,7 +106,7 @@ Feature List:
* Implicit:
* Not expressly standards compliant
* Never asks for end-user consent
* Not compatible with the `consent` prompt type
* Not compatible with the consent prompt type
* Pre-Configured:
* Allows users to save consent sessions for a duration configured by the administrator
* Operates nearly identically to the explicit consent mode
@ -116,15 +115,8 @@ Feature List:
{{< roadmap-status stage="in-progress" version="v4.38.0" >}}
* [RFC9126: OAuth 2.0 Pushed Authorization Requests]
* [RFC7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants]:
* Client Auth Method `client_secret_jwt`
* Client Auth Method `private_key_jwt`
* Per-Client [RFC7636: Proof Key for Code Exchange (PKCE)] Policy
* Multiple Issuer JWKs:
* `RS256`, `RS384`, `RS512`
* `PS256`, `PS384`, `PS512`
* `ES256`, `ES384`, `ES512`
* [OAuth 2.0 Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126)
* Per-Client [Proof Key Code Exchange (PKCE)] Policy
### Beta 7
@ -135,7 +127,7 @@ Feature List:
* Prompt Handling
* Display Handling
See [OpenID Connect Core 1.0 (Mandatory to Implement Features for All OpenID Providers)].
See [OpenID Connect Core (Mandatory to Implement Features for All OpenID Providers)].
### Beta 8
@ -145,15 +137,6 @@ Feature List:
* Revoke Tokens on User Logout or Expiration
* [JSON Web Key Rotation](https://openid.net/specs/openid-connect-messages-1_0-20.html#rotate.sig.keys)
* In-Storage Configuration:
* Multi-Issuer Configuration (require one per Issuer URL)
* Dynamically Configured via CLI
* Import from YAML:
* Manual method
* Bootstrap method:
* Defaults to one time only
* Can optionally override the database configuration
* Salt (random) and/or Peppered (storage encryption) Client Credentials
### General Availability
@ -161,7 +144,7 @@ Feature List:
Feature List:
* ~~Enable by Default~~
* Enable by Default
* Only after all previous stages are checked for bugs
### Miscellaneous
@ -172,13 +155,13 @@ This stage lists features which individually do not fit into a specific stage an
{{< roadmap-status >}}
See the [OpenID Connect 1.0] website for the [OpenID Connect Dynamic Client Registration 1.0] specification.
See the [OpenID Connect] website for the [OpenID Connect Dynamic Client Registration] specification.
#### OpenID Connect Back-Channel Logout
{{< roadmap-status >}}
See the [OpenID Connect 1.0] website for the [OpenID Connect Back-Channel Logout 1.0] specification.
See the [OpenID Connect] website for the [OpenID Connect Back-Channel Logout] specification.
Should be implemented alongside [Dynamic Client Registration](#openid-connect-dynamic-client-registration).
@ -186,7 +169,7 @@ Should be implemented alongside [Dynamic Client Registration](#openid-connect-dy
{{< roadmap-status >}}
See the [OpenID Connect 1.0] website for the [OpenID Connect Front-Channel Logout 1.0] specification.
See the [OpenID Connect] website for the [OpenID Connect Front-Channel Logout] specification.
Should be implemented alongside [Dynamic Client Registration](#openid-connect-dynamic-client-registration).
@ -200,7 +183,7 @@ See the [IETF Specification RFC8414](https://datatracker.ietf.org/doc/html/rfc84
{{< roadmap-status >}}
See the [OpenID Connect 1.0] website for the [OpenID Connect Session Management 1.0] specification.
See the [OpenID Connect] website for the [OpenID Connect Session Management] specification.
#### End-User Scope Grants
@ -226,17 +209,14 @@ The `preferred_username` claim was missing and was fixed.
[RFC8693 Section 4.3]: https://datatracker.ietf.org/doc/html/rfc8693/#section-4.3
[RFC4122]: https://datatracker.ietf.org/doc/html/rfc4122
[OpenID Connect 1.0]: https://openid.net/connect/
[OpenID Connect Front-Channel Logout 1.0]: https://openid.net/specs/openid-connect-frontchannel-1_0.html
[OpenID Connect Back-Channel Logout 1.0]: https://openid.net/specs/openid-connect-backchannel-1_0.html
[OpenID Connect Session Management 1.0]: https://openid.net/specs/openid-connect-session-1_0.html
[OpenID Connect Dynamic Client Registration 1.0]: https://openid.net/specs/openid-connect-registration-1_0.html
[OpenID Connect]: https://openid.net/connect/
[OpenID Connect Front-Channel Logout]: https://openid.net/specs/openid-connect-frontchannel-1_0.html
[OpenID Connect Back-Channel Logout]: https://openid.net/specs/openid-connect-backchannel-1_0.html
[OpenID Connect Session Management]: https://openid.net/specs/openid-connect-session-1_0.html
[OpenID Connect Dynamic Client Registration]: https://openid.net/specs/openid-connect-registration-1_0.html
[OpenID Connect Core 1.0 (ID Token)]: https://openid.net/specs/openid-connect-core-1_0.html#IDToken
[OpenID Connect Core 1.0 (Subject Identifier Types)]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[OpenID Connect Core 1.0 (Pairwise Identifier Algorithm)]: https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
[OpenID Connect Core 1.0 (Mandatory to Implement Features for All OpenID Providers)]: https://openid.net/specs/openid-connect-core-1_0.html#ServerMTI
[RFC7636: Proof Key for Code Exchange (PKCE)]: https://datatracker.ietf.org/doc/html/rfc7636
[RFC7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants]: https://datatracker.ietf.org/doc/html/rfc7523
[RFC9126: OAuth 2.0 Pushed Authorization Requests]: https://datatracker.ietf.org/doc/html/rfc9126
[OpenID Connect Core (ID Token)]: https://openid.net/specs/openid-connect-core-1_0.html#IDToken
[OpenID Connect Core (Subject Identifier Types)]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[OpenID Connect Core (Pairwise Identifier Algorithm)]: https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
[OpenID Connect Core (Mandatory to Implement Features for All OpenID Providers)]: https://openid.net/specs/openid-connect-core-1_0.html#ServerMTI
[Proof Key Code Exchange (PKCE)]: https://datatracker.ietf.org/doc/html/rfc7636

View File

@ -25,7 +25,7 @@ be glad to share ideas and plans with you.
This is a summary of the features which are currently on the roadmap with links to further details:
1. [WebAuthn](../active/webauthn.md)
2. [OpenID Connect 1.0 Provider](../active/openid-connect.md)
2. [OpenID Connect Provider](../active/openid-connect.md)
3. [Internationalization or Multilingual Support](../active/internationalization.md)
4. [Multiple Domain Protection](../active/multi-domain-protection.md)
5. [Control Panel / Dashboard for User / Administration Settings](../active/dashboard-control-panel.md)

File diff suppressed because one or more lines are too long

View File

@ -1,12 +0,0 @@
{
"totp": [
{"name": "Google Authenticator", "clear": false, "algorithms": {"SHA1": true, "SHA256": false, "SHA512": false}, "digits": {"six": true, "eight": false}, "url": "https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en&gl=US&pli=1"},
{"name": "Bitwarden", "clear": true, "algorithms": {"SHA1": true, "SHA256": true, "SHA512": true}, "digits": {"six": true, "eight": true}, "url": "https://bitwarden.com/"},
{"name": "Yubico Authenticator", "clear": true, "algorithms": {"SHA1": true, "SHA256": false, "SHA512": false}, "digits": {"six": true, "eight": true}, "url": "https://www.yubico.com/products/yubico-authenticator/"},
{"name": "Authenticator Plus", "clear": false, "algorithms": {"SHA1": true, "SHA256": false, "SHA512": false}, "digits": {"six": true, "eight": false}, "url": "https://www.authenticatorplus.com/"},
{"name": "1Password", "clear": false, "algorithms": {"SHA1": true, "SHA256": true, "SHA512": false}, "digits": {"six": true, "eight": false}, "url": "https://1password.com/"},
{"name": "Ravio", "clear": false, "algorithms": {"SHA1": true, "SHA256": true, "SHA512": false}, "digits": {"six": true, "eight": false}, "url": "https://raivo-otp.com/"},
{"name": "Authy", "clear": false, "algorithms": {"SHA1": true, "SHA256": false, "SHA512": false}, "digits": {"six": false, "eight": true}, "url": "https://authy.com/"},
{"name": "Aegis", "clear": false, "algorithms": {"SHA1": true, "SHA256": false, "SHA512": true}, "digits": {"six": true, "eight": true}, "url": "https://getaegis.app/"}
]
}

View File

@ -1,4 +1,4 @@
{{ $faq := "../frequently-asked-questions/" }}{{ $config := "../../../configuration/identity-providers/openid-connect/" }}
{{ $faq := "../frequently-asked-questions/" }}{{ $config := "../../../configuration/identity-providers/open-id-connect.md" }}
{{- with .Get "faq" }}{{ $faq = . }}{{ end }}
{{- with .Get "config" }}{{ $config = . }}{{ end }}
### Common Notes
@ -15,6 +15,4 @@
guaranteed to be supported in the future. See the [Plaintext]({{ $faq }}#plaintext) guide for more
information.
3. The Configuration example for Authelia is only a portion of the required configuration and it should be used as a
guide in conjunction with the standard
[OpenID Connect 1.0 Provider Configuration]({{ printf "%s/provider.md" $config }}) and
[OpenID Connect 1.0 Clients Configuration]({{ printf "%s/clients.md" $config }}) guides.
guide in conjunction with the standard [OpenID Connect 1.0 Configuration]({{ $config }}) guide.

View File

@ -1,28 +0,0 @@
<table class="table table-hover">
<thead>
<tr>
<th style="text-align: center;" rowspan="2">Application</th>
<th style="text-align: center;" colspan="3" class="border-end">Algorithm</th>
<th style="text-align: center;" colspan="2">Digits</th>
</tr>
<tr>
<th style="text-align: center;">SHA1</th>
<th style="text-align: center;">SHA256</th>
<th style="text-align: center;" class="border-end">SHA512</th>
<th style="text-align: center;">6</th>
<th style="text-align: center;">8</th>
</tr>
</thead>
<tbody>
{{- range $.Site.Data.support.totp }}
<tr>
<td style="text-align: center;"><a href="{{ .url }}" target="_blank">{{ .name }}</a></td>
<td style="text-align: center;"><i class="{{ cond .algorithms.SHA1 "icon-support-full" "icon-support-none" }}" data-toggle="tooltip" data-placement="top" title="{{ cond .algorithms.SHA1 "" "Not " }}Supported"></i></td>
<td style="text-align: center;"><i class="{{ cond .algorithms.SHA256 "icon-support-full" "icon-support-none" }}" data-toggle="tooltip" data-placement="top" title="{{ cond .algorithms.SHA256 "" "Not " }}Supported"></i></td>
<td style="text-align: center;" class="border-end"><i class="{{ cond .algorithms.SHA512 "icon-support-full" "icon-support-none" }}" data-toggle="tooltip" data-placement="top" title="{{ cond .algorithms.SHA512 "" "Not " }}Supported"></i></td>
<td style="text-align: center;"><i class="{{ cond .digits.six "icon-support-full" "icon-support-none" }}" data-toggle="tooltip" data-placement="top" title="{{ cond .digits.six "" "Not " }}Supported"></i></td>
<td style="text-align: center;"><i class="{{ cond .digits.eight "icon-support-full" "icon-support-none" }}" data-toggle="tooltip" data-placement="top" title="{{ cond .digits.eight "" "Not " }}Supported"></i></td>
</tr>
{{- end }}
</tbody>
</table>

View File

@ -1,7 +1,5 @@
#!/bin/sh
[[ ! -z ${UMASK} ]] && umask ${UMASK}
if [[ ! -z ${1} ]] && [[ ${1} != "--config" ]]; then
exec "$@"
elif [[ $(id -u) != 0 ]] || [[ $(id -g) != 0 ]]; then

View File

@ -1,144 +0,0 @@
syntax = "proto3";
package envoy.service.auth.v3;
import "envoy/config/core/v3/base.proto";
import "envoy/service/auth/v3/attribute_context.proto";
import "envoy/type/v3/http_status.proto";
import "google/protobuf/struct.proto";
import "google/rpc/status.proto";
import "envoy/annotations/deprecation.proto";
import "udpa/annotations/status.proto";
import "udpa/annotations/versioning.proto";
option java_package = "io.envoyproxy.envoy.service.auth.v3";
option java_outer_classname = "ExternalAuthProto";
option java_multiple_files = true;
option go_package = "github.com/envoyproxy/go-control-plane/envoy/service/auth/v3;authv3";
option (udpa.annotations.file_status).package_version_status = ACTIVE;
// [#protodoc-title: Authorization service]
// The authorization service request messages used by external authorization :ref:`network filter
// <config_network_filters_ext_authz>` and :ref:`HTTP filter <config_http_filters_ext_authz>`.
// A generic interface for performing authorization check on incoming
// requests to a networked service.
service Authorization {
// Performs authorization check based on the attributes associated with the
// incoming request, and returns status `OK` or not `OK`.
rpc Check(CheckRequest) returns (CheckResponse) {
}
}
message CheckRequest {
option (udpa.annotations.versioning).previous_message_type = "envoy.service.auth.v2.CheckRequest";
// The request attributes.
AttributeContext attributes = 1;
}
// HTTP attributes for a denied response.
message DeniedHttpResponse {
option (udpa.annotations.versioning).previous_message_type =
"envoy.service.auth.v2.DeniedHttpResponse";
// This field allows the authorization service to send an HTTP response status code to the
// downstream client. If not set, Envoy sends ``403 Forbidden`` HTTP status code by default.
type.v3.HttpStatus status = 1;
// This field allows the authorization service to send HTTP response headers
// to the downstream client. Note that the :ref:`append field in HeaderValueOption <envoy_v3_api_field_config.core.v3.HeaderValueOption.append>` defaults to
// false when used in this message.
repeated config.core.v3.HeaderValueOption headers = 2;
// This field allows the authorization service to send a response body data
// to the downstream client.
string body = 3;
}
// HTTP attributes for an OK response.
// [#next-free-field: 9]
message OkHttpResponse {
option (udpa.annotations.versioning).previous_message_type =
"envoy.service.auth.v2.OkHttpResponse";
// HTTP entity headers in addition to the original request headers. This allows the authorization
// service to append, to add or to override headers from the original request before
// dispatching it to the upstream. Note that the :ref:`append field in HeaderValueOption <envoy_v3_api_field_config.core.v3.HeaderValueOption.append>` defaults to
// false when used in this message. By setting the ``append`` field to ``true``,
// the filter will append the correspondent header value to the matched request header.
// By leaving ``append`` as false, the filter will either add a new header, or override an existing
// one if there is a match.
repeated config.core.v3.HeaderValueOption headers = 2;
// HTTP entity headers to remove from the original request before dispatching
// it to the upstream. This allows the authorization service to act on auth
// related headers (like ``Authorization``), process them, and consume them.
// Under this model, the upstream will either receive the request (if it's
// authorized) or not receive it (if it's not), but will not see headers
// containing authorization credentials.
//
// Pseudo headers (such as ``:authority``, ``:method``, ``:path`` etc), as well as
// the header ``Host``, may not be removed as that would make the request
// malformed. If mentioned in ``headers_to_remove`` these special headers will
// be ignored.
//
// When using the HTTP service this must instead be set by the HTTP
// authorization service as a comma separated list like so:
// ``x-envoy-auth-headers-to-remove: one-auth-header, another-auth-header``.
repeated string headers_to_remove = 5;
// This field has been deprecated in favor of :ref:`CheckResponse.dynamic_metadata
// <envoy_v3_api_field_service.auth.v3.CheckResponse.dynamic_metadata>`. Until it is removed,
// setting this field overrides :ref:`CheckResponse.dynamic_metadata
// <envoy_v3_api_field_service.auth.v3.CheckResponse.dynamic_metadata>`.
google.protobuf.Struct dynamic_metadata = 3
[deprecated = true, (envoy.annotations.deprecated_at_minor_version) = "3.0"];
// This field allows the authorization service to send HTTP response headers
// to the downstream client on success. Note that the :ref:`append field in HeaderValueOption <envoy_v3_api_field_config.core.v3.HeaderValueOption.append>`
// defaults to false when used in this message.
repeated config.core.v3.HeaderValueOption response_headers_to_add = 6;
// This field allows the authorization service to set (and overwrite) query
// string parameters on the original request before it is sent upstream.
repeated config.core.v3.QueryParameter query_parameters_to_set = 7;
// This field allows the authorization service to specify which query parameters
// should be removed from the original request before it is sent upstream. Each
// element in this list is a case-sensitive query parameter name to be removed.
repeated string query_parameters_to_remove = 8;
}
// Intended for gRPC and Network Authorization servers ``only``.
message CheckResponse {
option (udpa.annotations.versioning).previous_message_type =
"envoy.service.auth.v2.CheckResponse";
// Status ``OK`` allows the request. Any other status indicates the request should be denied, and
// for HTTP filter, if not overridden by :ref:`denied HTTP response status <envoy_v3_api_field_service.auth.v3.DeniedHttpResponse.status>`
// Envoy sends ``403 Forbidden`` HTTP status code by default.
google.rpc.Status status = 1;
// An message that contains HTTP response attributes. This message is
// used when the authorization service needs to send custom responses to the
// downstream client or, to modify/add request headers being dispatched to the upstream.
oneof http_response {
// Supplies http attributes for a denied response.
DeniedHttpResponse denied_response = 2;
// Supplies http attributes for an ok response.
OkHttpResponse ok_response = 3;
}
// Optional response metadata that will be emitted as dynamic metadata to be consumed by the next
// filter. This metadata lives in a namespace specified by the canonical name of extension filter
// that requires it:
//
// - :ref:`envoy.filters.http.ext_authz <config_http_filters_ext_authz_dynamic_metadata>` for HTTP filter.
// - :ref:`envoy.filters.network.ext_authz <config_network_filters_ext_authz_dynamic_metadata>` for network filter.
google.protobuf.Struct dynamic_metadata = 4;
}

View File

@ -4,71 +4,70 @@
###############################################################
# This secret can also be set using the env variables AUTHELIA_JWT_SECRET_FILE
jwt_secret: a_very_important_secret
default_redirection_url: https://public.example.com
jwt_secret: 'a_very_important_secret'
default_redirection_url: 'https://public.example.com'
server:
address: 'tcp://:9091'
log:
level: debug
level: 'debug'
totp:
issuer: authelia.com
issuer: 'authelia.com'
# duo_api:
# hostname: api-123456789.example.com
# integration_key: ABCDEF
# hostname: 'api-123456789.example.com'
# integration_key: 'ABCDEF'
# # This secret can also be set using the env variables AUTHELIA_DUO_API_SECRET_KEY_FILE
# secret_key: 1234567890abcdefghifjkl
authentication_backend:
file:
path: /config/users_database.yml
path: '/config/users_database.yml'
access_control:
default_policy: deny
default_policy: 'deny'
rules:
# Rules applied to everyone
- domain: public.example.com
policy: bypass
- domain: traefik.example.com
policy: one_factor
- domain: secure.example.com
policy: two_factor
- domain: 'public.example.com'
policy: 'bypass'
- domain: 'traefik.example.com'
policy: 'one_factor'
- domain: 'secure.example.com'
policy: 'two_factor'
session:
# This secret can also be set using the env variables AUTHELIA_SESSION_SECRET_FILE
secret: unsecure_session_secret
secret: 'unsecure_session_secret'
cookies:
- name: authelia_session
domain: example.com # Should match whatever your root protected domain is
expiration: 3600 # 1 hour
inactivity: 300 # 5 minutes
- name: 'authelia_session'
domain: 'example.com' # Should match whatever your root protected domain is
expiration: '1h' # 1 hour
inactivity: '5m' # 5 minutes
redis:
host: redis
host: 'redis'
port: 6379
# This secret can also be set using the env variables AUTHELIA_SESSION_REDIS_PASSWORD_FILE
# password: authelia
# password: 'authelia'
regulation:
max_retries: 3
find_time: 120
ban_time: 300
find_time: '2m'
ban_time: '5m'
storage:
encryption_key: you_must_generate_a_random_string_of_more_than_twenty_chars_and_configure_this
encryption_key: 'you_must_generate_a_random_string_of_more_than_twenty_chars_and_configure_this'
local:
path: /config/db.sqlite3
path: '/config/db.sqlite3'
notifier:
smtp:
username: test
address: 'smtp://mail.example.com:25'
username: 'test'
# This secret can also be set using the env variables AUTHELIA_NOTIFIER_SMTP_PASSWORD_FILE
password: password
host: mail.example.com
port: 25
sender: admin@example.com
password: 'password'
sender: 'admin@example.com'
...

View File

@ -9,11 +9,11 @@
users:
authelia:
disabled: false
displayname: "Authelia User"
displayname: 'Authelia User'
# Password is authelia
password: "$6$rounds=50000$BpLnfgDsc2WD8F2q$Zis.ixdg9s/UOJYrs56b5QEZFiZECu0qZVNsIYxBaNJ7ucIL.nlxVCT5tqh8KHG8X4tlwCFm5r6NTOZZ5qRFN/" # yamllint disable-line rule:line-length
email: authelia@authelia.com
password: '$6$rounds=50000$BpLnfgDsc2WD8F2q$Zis.ixdg9s/UOJYrs56b5QEZFiZECu0qZVNsIYxBaNJ7ucIL.nlxVCT5tqh8KHG8X4tlwCFm5r6NTOZZ5qRFN/' # yamllint disable-line rule:line-length
email: 'authelia@authelia.com'
groups:
- admins
- dev
- 'admins'
- 'dev'
...

View File

@ -1,18 +1,18 @@
---
version: '3.3'
version: '3.8'
networks:
net:
driver: bridge
driver: 'bridge'
services:
authelia:
image: authelia/authelia
container_name: authelia
image: 'authelia/authelia'
container_name: 'authelia'
volumes:
- ./authelia:/config
- './authelia:/config'
networks:
- net
- 'net'
labels:
- 'traefik.enable=true'
- 'traefik.http.routers.authelia.rule=Host(`authelia.example.com`)'
@ -24,34 +24,34 @@ services:
- 'traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,Remote-Groups,Remote-Name,Remote-Email' # yamllint disable-line rule:line-length
expose:
- 9091
restart: unless-stopped
restart: 'unless-stopped'
healthcheck:
## In production the healthcheck section should be commented.
disable: true
environment:
- TZ=Australia/Melbourne
TZ: 'Australia/Melbourne'
redis:
image: redis:alpine
container_name: redis
image: 'redis:alpine'
container_name: 'redis'
volumes:
- ./redis:/data
- './redis:/data'
networks:
- net
- 'net'
expose:
- 6379
restart: unless-stopped
restart: 'unless-stopped'
environment:
- TZ=Australia/Melbourne
TZ: 'Australia/Melbourne'
traefik:
image: traefik:v2.10.3
container_name: traefik
image: 'traefik:v2.10.1'
container_name: 'traefik'
volumes:
- ./traefik:/etc/traefik
- /var/run/docker.sock:/var/run/docker.sock
- './traefik:/etc/traefik'
- '/var/run/docker.sock:/var/run/docker.sock'
networks:
- net
- 'net'
labels:
- 'traefik.enable=true'
- 'traefik.http.routers.api.rule=Host(`traefik.example.com`)'
@ -80,10 +80,10 @@ services:
- '--log.level=DEBUG'
secure:
image: traefik/whoami
container_name: secure
image: 'traefik/whoami'
container_name: 'secure'
networks:
- net
- 'net'
labels:
- 'traefik.enable=true'
- 'traefik.http.routers.secure.rule=Host(`secure.example.com`)'
@ -93,13 +93,13 @@ services:
- 'traefik.http.routers.secure.middlewares=authelia@docker'
expose:
- 80
restart: unless-stopped
restart: 'unless-stopped'
public:
image: traefik/whoami
container_name: public
image: 'traefik/whoami'
container_name: 'public'
networks:
- net
- 'net'
labels:
- 'traefik.enable=true'
- 'traefik.http.routers.public.rule=Host(`public.example.com`)'
@ -109,5 +109,5 @@ services:
- 'traefik.http.routers.public.middlewares=authelia@docker'
expose:
- 80
restart: unless-stopped
restart: 'unless-stopped'
...

View File

@ -3,52 +3,52 @@
# Authelia configuration #
###############################################################
jwt_secret: a_very_important_secret
default_redirection_url: https://public.example.com
jwt_secret: 'a_very_important_secret'
default_redirection_url: 'https://public.example.com'
server:
address: 'tcp://:9091'
log:
level: debug
level: 'debug'
totp:
issuer: authelia.com
issuer: 'authelia.com'
authentication_backend:
file:
path: /config/users_database.yml
path: '/config/users_database.yml'
access_control:
default_policy: deny
default_policy: 'deny'
rules:
- domain: public.example.com
policy: bypass
- domain: traefik.example.com
policy: one_factor
- domain: secure.example.com
policy: two_factor
- domain: 'public.example.com'
policy: 'bypass'
- domain: 'traefik.example.com'
policy: 'one_factor'
- domain: 'secure.example.com'
policy: 'two_factor'
session:
secret: unsecure_session_secret
secret: 'unsecure_session_secret'
cookies:
- name: authelia_session
domain: example.com # Should match whatever your root protected domain is
expiration: 3600 # 1 hour
inactivity: 300 # 5 minutes
- name: 'authelia_session'
domain: 'example.com' # Should match whatever your root protected domain is
expiration: '1h' # 1 hour
inactivity: '5m' # 5 minutes
regulation:
max_retries: 3
find_time: 120
ban_time: 300
find_time: '2m'
ban_time: '5m'
storage:
encryption_key: you_must_generate_a_random_string_of_more_than_twenty_chars_and_configure_this
encryption_key: 'you_must_generate_a_random_string_of_more_than_twenty_chars_and_configure_this'
local:
path: /config/db.sqlite3
path: '/config/db.sqlite3'
notifier:
filesystem:
filename: /config/notification.txt
filename: '/config/notification.txt'
...

View File

@ -9,10 +9,10 @@
users:
<USERNAME>:
disabled: false
displayname: "<DISPLAYNAME>"
password: "<PASSWORD>"
email: <USERNAME>@example.com
displayname: '<DISPLAYNAME>'
password: '<PASSWORD>'
email: '<USERNAME>@example.com'
groups:
- admins
- dev
- 'admins'
- 'dev'
...

View File

@ -3,16 +3,16 @@ version: '3.3'
networks:
net:
driver: bridge
driver: 'bridge'
services:
authelia:
image: authelia/authelia
container_name: authelia
image: 'authelia/authelia'
container_name: 'authelia'
volumes:
- ./authelia:/config
- './authelia:/config'
networks:
- net
- 'net'
labels:
- 'traefik.enable=true'
- 'traefik.http.routers.authelia.rule=Host(`authelia.example.com`)'
@ -24,21 +24,21 @@ services:
- 'traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,Remote-Groups,Remote-Name,Remote-Email' # yamllint disable-line rule:line-length
expose:
- 9091
restart: unless-stopped
restart: 'unless-stopped'
healthcheck:
## In production the healthcheck section should be commented.
disable: true
environment:
- TZ=Australia/Melbourne
TZ: 'Australia/Melbourne'
traefik:
image: traefik:v2.10.3
container_name: traefik
image: 'traefik:v2.10.1'
container_name: 'traefik'
volumes:
- ./traefik:/etc/traefik
- /var/run/docker.sock:/var/run/docker.sock
- './traefik:/etc/traefik'
- '/var/run/docker.sock:/var/run/docker.sock'
networks:
- net
- 'net'
labels:
- 'traefik.enable=true'
- 'traefik.http.routers.api.rule=Host(`traefik.example.com`)'
@ -65,10 +65,10 @@ services:
- '--log.level=DEBUG'
secure:
image: traefik/whoami
container_name: secure
image: 'traefik/whoami'
container_name: 'secure'
networks:
- net
- 'net'
labels:
- 'traefik.enable=true'
- 'traefik.http.routers.secure.rule=Host(`secure.example.com`)'
@ -78,13 +78,13 @@ services:
- 'traefik.http.routers.secure.middlewares=authelia@docker'
expose:
- 80
restart: unless-stopped
restart: 'unless-stopped'
public:
image: traefik/whoami
container_name: public
image: 'traefik/whoami'
container_name: 'public'
networks:
- net
- 'net'
labels:
- 'traefik.enable=true'
- 'traefik.http.routers.public.rule=Host(`public.example.com`)'
@ -94,5 +94,5 @@ services:
- 'traefik.http.routers.public.middlewares=authelia@docker'
expose:
- 80
restart: unless-stopped
restart: 'unless-stopped'
...

View File

@ -1,6 +1,6 @@
---
tls:
certificates:
- certFile: /etc/traefik/certs/cert.pem
keyFile: /etc/traefik/certs/key.pem
- certFile: '/etc/traefik/certs/cert.pem'
keyFile: '/etc/traefik/certs/key.pem'
...

Some files were not shown because too many files have changed in this diff Show More