diff options
Diffstat (limited to 'docs/content/en')
11 files changed, 383 insertions, 81 deletions
diff --git a/docs/content/en/configuration/identity-providers/openid-connect/clients.md b/docs/content/en/configuration/identity-providers/openid-connect/clients.md index 76e6ba165..841e5dd13 100644 --- a/docs/content/en/configuration/identity-providers/openid-connect/clients.md +++ b/docs/content/en/configuration/identity-providers/openid-connect/clients.md @@ -211,17 +211,18 @@ This value does not affect the issued ID Tokens as they are always issued with t ### scopes -{{< confkey type="list(string)" default="openid, groups, profile, email" required="no" >}} +{{< 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. -The scope values must be one of those documented in the -[scope definitions](../../../integration/openid-connect/introduction.md#scope-definitions) with the exception of when -the configured [grant_types](#grant_types) includes the `client_credentials` grant in which case arbitrary scopes are -also allowed, +The scope values should generally be one of those documented in the +[scope definitions](../../../integration/openid-connect/introduction.md#scope-definitions) with the exception of when a client requires a specific scope we do not define. Users should +expect to see a warning in the logs if they configure a scope not in our definitions with the exception of a client +where the configured [grant_types](#grant_types) includes the `client_credentials` grant in which case arbitrary scopes are +expected, ### grant_types diff --git a/docs/content/en/configuration/identity-providers/openid-connect/provider.md b/docs/content/en/configuration/identity-providers/openid-connect/provider.md index 197c65504..9a12c8bec 100644 --- a/docs/content/en/configuration/identity-providers/openid-connect/provider.md +++ b/docs/content/en/configuration/identity-providers/openid-connect/provider.md @@ -116,15 +116,54 @@ with 64 or more characters. ### issuer_private_keys -{{< confkey type="list(object" required="no" >}} +{{< confkey type="list(object)" required="yes" >}} -The list of JWKS instead of or in addition to the [issuer_private_key](#issuer_private_key) and -[issuer_certificate_chain](#issuer_certificate_chain). Can also accept ECDSA Private Key's and Certificates. +The list of issuer JSON Web Keys. At least one of these must be an RSA Private key and be configured with the RS256 +algorithm. Can also be used to configure many types of JSON Web Keys for the issuer such as the other RSA based JSON Web +Key formats and ECDSA JSON Web Key formats. -The default key for each algorithm is is decided based on the order of this list. The first key for each algorithm is +The default key for each algorithm 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_signed_response_alg](clients.md#id_token_signed_response_alg) `ES256` and [id_token_signed_response_key_id](clients.md#id_token_signed_response_key_id) is -not specified then the first `ES256` key in this list is used. +[id_token_signed_response_alg](clients.md#id_token_signed_response_alg) `ES256` and +[id_token_signed_response_key_id](clients.md#id_token_signed_response_key_id) is not specified then the first `ES256` +key in this list is used. + +The following is a contextual example (see below for information regarding each option): + +```yaml +identity_providers: + oidc: + 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----- +``` The following is a contextual example (see below for information regarding each option): @@ -248,48 +287,6 @@ The first certificate in the chain must have the public key for the [key](#key), 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](#issuer_private_keys) 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 a RSA private key: - * Encoded in conformance to the [PKCS#8] or [PKCS#1] specifications. - * Have a key size of at least 2048 bits. - -[PKCS#8]: https://datatracker.ietf.org/doc/html/rfc5208 -[PKCS#1]: https://datatracker.ietf.org/doc/html/rfc8017 - -If the [issuer_certificate_chain](#issuer_certificate_chain) 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](#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](#issuer_private_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. - ### enable_client_debug_messages {{< confkey type="boolean" default="false" required="no" >}} diff --git a/docs/content/en/configuration/methods/secrets.md b/docs/content/en/configuration/methods/secrets.md index eeaa18151..a32826fc3 100644 --- a/docs/content/en/configuration/methods/secrets.md +++ b/docs/content/en/configuration/methods/secrets.md @@ -105,8 +105,6 @@ 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/provider.md#issuer_certificate_chain -[identity_providers.oidc.issuer_private_key]: ../identity-providers/openid-connect/provider.md#issuer_private_key [identity_providers.oidc.hmac_secret]: ../identity-providers/openid-connect/provider.md#hmac_secret [identity_validation.reset_password.jwt_secret]: ../identity-validation/reset-password.md#jwt_secret diff --git a/docs/content/en/configuration/miscellaneous/server-endpoints-authz.md b/docs/content/en/configuration/miscellaneous/server-endpoints-authz.md index daa4864dc..973bb2cd3 100644 --- a/docs/content/en/configuration/miscellaneous/server-endpoints-authz.md +++ b/docs/content/en/configuration/miscellaneous/server-endpoints-authz.md @@ -1,7 +1,7 @@ --- title: "Server Authz Endpoints" description: "Configuring the Server Authz Endpoint Settings." -lead: "Authelia supports several authorization endpoints on the internal webserver. This section describes how to configure and tune them." +lead: "Authelia supports several authorization endpoints on the internal web server. This section describes how to configure and tune them." date: 2023-01-25T20:36:40+11:00 draft: false images: [] @@ -26,16 +26,22 @@ server: implementation: 'ForwardAuth' authn_strategies: - name: 'HeaderProxyAuthorization' + schemes: + - 'Basic' - name: 'CookieSession' ext-authz: implementation: 'ExtAuthz' authn_strategies: - name: 'HeaderProxyAuthorization' + schemes: + - 'Basic' - name: 'CookieSession' auth-request: implementation: 'AuthRequest' authn_strategies: - name: 'HeaderAuthRequestProxyAuthorization' + schemes: + - 'Basic' - name: 'CookieSession' legacy: implementation: 'Legacy' @@ -80,3 +86,11 @@ immediately short-circuit the authentication, otherwise the next strategy in the The name of the strategy. Valid case-sensitive values are `CookieSession`, `HeaderAuthorization`, `HeaderProxyAuthorization`, `HeaderAuthRequestProxyAuthorization`, and `HeaderLegacy`. Read more about the strategies in the [reference guide](../../reference/guides/proxy-authorization.md#authn-strategies). + +#### schemes + +{{< confkey type="list(string)" default="Basic" required="no" >}} + +The list of schemes allowed on this endpoint. Options are `Basic`, and `Bearer`. This option is only applicable to the +`HeaderAuthorization`, `HeaderProxyAuthorization`, and `HeaderAuthRequestProxyAuthorization` strategies and unavailable +with the `legacy` endpoint which only uses `Basic`. diff --git a/docs/content/en/configuration/miscellaneous/server.md b/docs/content/en/configuration/miscellaneous/server.md index 84954d552..0b46d1d00 100644 --- a/docs/content/en/configuration/miscellaneous/server.md +++ b/docs/content/en/configuration/miscellaneous/server.md @@ -1,7 +1,7 @@ --- title: "Server" description: "Configuring the Server Settings." -lead: "Authelia runs an internal webserver. This section describes how to configure and tune this." +lead: "Authelia runs an internal web server. This section describes how to configure and tune this." date: 2022-06-15T17:51:47+10:00 draft: false images: [] @@ -39,19 +39,7 @@ server: endpoints: enable_pprof: false enable_expvars: false - authz: - forward-auth: - implementation: 'ForwardAuth' - authn_strategies: [] - ext-authz: - implementation: 'ExtAuthz' - authn_strategies: [] - auth-request: - implementation: 'AuthRequest' - authn_strategies: [] - legacy: - implementation: 'Legacy' - authn_strategies: [] + authz: {} ## See the dedicated "Server Authz Endpoints" configuration guide. ``` ## Options @@ -83,9 +71,9 @@ server: ### asset_path -{{< confkey type="string " required="no" >}} +{{< confkey type="string" required="no" >}} -Authelia by default serves all static assets from an embedded filesystem in the Go binary. +Authelia by default serves all static assets from an embedded file system in the Go binary. Modifying this setting will allow you to override and serve specific assets for Authelia from a specified path. All assets that can be overridden must be placed in the `asset_path`. The structure of this directory and the assets which @@ -98,7 +86,7 @@ can be overridden is documented in the On startup Authelia checks for the existence of /app/healthcheck.sh and /app/.healthcheck.env and if both of these exist it writes the configuration vars for the healthcheck to the /app/.healthcheck.env file. In instances where this is not -desirable it's possible to disable these interactions entirely. +desirable, it's possible to disable these interactions entirely. An example situation where this is the case is in Kubernetes when set security policies that prevent writing to the ephemeral storage of a container or just don't want to enable the internal health check. @@ -147,8 +135,8 @@ or intermediate certificates. If no item is provided mutual TLS is disabled. {{< confkey type="string" required="no" >}} This customizes the value of the Content-Security-Policy header. It will replace all instances of the below placeholder -with the nonce value of the Authelia react bundle. This is an advanced option to customize and you should do sufficient -research about how browsers utilize and understand this header before attempting to customize it. +with the nonce value of the Authelia react bundle. This is an advanced option to customize, and you should do +sufficient research about how browsers utilize and understand this header before attempting to customize it. {{< csp >}} @@ -195,10 +183,10 @@ Generally this does not need to be configured for most use cases. See the ### Buffer Sizes The read and write buffer sizes generally should be the same. This is because when Authelia verifies -if the user is authorized to visit a URL, it also sends back nearly the same size response as the request. However +if the user is authorized to visit a URL, it also sends back nearly the same size response as the request. However, you're able to tune these individually depending on your needs. ### Asset Overrides -If replacing the Logo for your Authelia portal it is recommended to upload a transparent PNG of your desired logo. +If replacing the Logo for your Authelia portal, it is recommended to upload a transparent PNG of your desired logo. Authelia will automatically resize the logo to an appropriate size to present in the frontend. diff --git a/docs/content/en/configuration/security/access-control.md b/docs/content/en/configuration/security/access-control.md index 6057820e4..6988af4aa 100644 --- a/docs/content/en/configuration/security/access-control.md +++ b/docs/content/en/configuration/security/access-control.md @@ -254,8 +254,14 @@ identify the subject is [one_factor]. See [Rule Matching Concept 2] for more inf This criteria matches identifying characteristics about the subject. Currently this is either user or groups the user belongs to. This allows you to effectively control exactly what each user is authorized to access or to specifically -require two-factor authentication to specific users. Subjects are prefixed with either `user:` or `group:` to identify -which part of the identity to check. +require two-factor authentication to specific users. Subjects must be prefixed with the following prefixes to +specifically match a specific part of a subject. + +| Subject Type | Prefix | Description | +|:----------------:|:----------------:|:----------------------------------------------------------------------------------------------------------------------------------------------:| +| User | `user:` | Matches the username of a user. | +| Group | `group:` | Matches if the user has a group with this name. | +| OAuth 2.0 Client | `oauth2:client:` | Matches if the request has been authorized via a token issued by a client with the specified id utilizing the `client_credentials` grant type. | The format of this rule is unique in as much as it is a list of lists. The logic behind this format is to allow for both `OR` and `AND` logic. The first level of the list defines the `OR` logic, and the second level defines the `AND` logic. diff --git a/docs/content/en/contributing/development/build-and-test.md b/docs/content/en/contributing/development/build-and-test.md index 60db46330..708fac320 100644 --- a/docs/content/en/contributing/development/build-and-test.md +++ b/docs/content/en/contributing/development/build-and-test.md @@ -14,7 +14,7 @@ aliases: - /docs/contributing/build-and-dev.html --- -__Authelia__ is built a [React] frontend user portal bundled in a [Go] application which acts as a basic webserver for +__Authelia__ is built a [React] frontend user portal bundled in a [Go] application which acts as a basic web server for the [React] assets and a dedicated API. The GitHub repository comes with a CLI dedicated to developers called diff --git a/docs/content/en/integration/openid-connect/introduction.md b/docs/content/en/integration/openid-connect/introduction.md index 21c3144df..06f30d35d 100644 --- a/docs/content/en/integration/openid-connect/introduction.md +++ b/docs/content/en/integration/openid-connect/introduction.md @@ -127,6 +127,19 @@ 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 | +### Special Scopes + +The following scopes represent special permissions granted to a specific token. + +#### authelia.bearer.authz + +This scope allows the granted access token to be utilized with the bearer authorization scheme on endpoints protected +via Authelia. + +The specifics about this scope are discussed in the +[OAuth 2.0 Bearer Token Usage for Authorization Endpoints](oauth-2.0-bearer-token-usage.md#authorization-endpoints) +guide. + ## Signing and Encryption Algorithms [OpenID Connect 1.0] and OAuth 2.0 support a wide variety of signature and encryption algorithms. Authelia supports diff --git a/docs/content/en/integration/openid-connect/oauth-2.0-bearer-token-usage.md b/docs/content/en/integration/openid-connect/oauth-2.0-bearer-token-usage.md new file mode 100644 index 000000000..994fd3da2 --- /dev/null +++ b/docs/content/en/integration/openid-connect/oauth-2.0-bearer-token-usage.md @@ -0,0 +1,281 @@ +--- +title: "OAuth 2.0 Bearer Token Usage" +description: "An introduction into utilizing the Authelia OAuth 2.0 Provider as an authorization method" +lead: "An introduction into utilizing the Authelia OAuth 2.0 Provider as an authorization method." +date: 2024-01-01T13:17:53+11:00 +draft: false +images: [] +menu: + integration: + parent: "openid-connect" +weight: 611 +toc: true +--- + +Access Tokens can be granted which can be leveraged as bearer tokens for the purpose of authorization in place of the +Session Cookie Forwarded Authorization Flow. This is performed leveraging the +[RFC6750: OAuth 2.0 Bearer Token Usage] specification. + +## Authorization Endpoints + +A [registered OAuth 2.0 client](../../configuration/identity-providers/openid-connect/provider.md#clients) which is +permitted to grant the `authelia.bearer.authz` scope is able to request users grant access to a token which can be used +for the forwarded authentication flow integrated into a proxy (i.e. `access_control` rules) in place of the standard +session cookie based authorization flow (which redirects unauthorized users) by utilizing +[RFC6750: OAuth 2.0 Bearer Token Usage] authorization scheme norms (i.e. using the bearer scheme). + +_**Note:** these tokens are not intended for usage with the Authelia API, a separate exclusive scope (or scopes) and +specific audiences will likely be implemented at a later date for this._ + +### General Protections + +The following protections have been taken into account: + +- There are several safeguards to ensure this Authorization Flow cannot operate accidentally. It must be explicitly + configured: + - The authorization endpoint must be explicitly configured to allow the `bearer` scheme. See + [Authorization Endpoint Configuration](#authorization-endpoint-configuration). + - Must be utilizing the new session configuration. See [Session Configuration](#session-configuration). + - The [OpenID Connect 1.0 Provider](../../configuration/identity-providers/openid-connect/provider.md) must be + configured. + - One or more [OpenID Connect 1.0 Clients](../../configuration/identity-providers/openid-connect/clients.md) must be + registered with the `authelia.bearer.authz` scope and relevant required parameters. + - Additional policy requirements are enforced for the client registrations to ensure as much reasonable protection + as possible. +- The token must: + - Be granted the `authelia.bearer.authz` scope. + - Be presented via the `bearer` scheme in the header matching your server Authorization Endpoints configuration. See + [Authorization Endpoint Configuration](#authorization-endpoint-configuration). + - Not be expired, revoked, or otherwise invalid. + - Actually be an Access Token (tokens with the prefix `authelia_at_`, not tokens with the prefixes `authelia_rt_` + or `authelia_ac_`). +- Authorizations using this method have special specific processing rules when considering the access control rules: + - If the token was granted via the `authorization_code` grant then the user who granted the consent for the requested + scope and audience and their effective authentication level (1FA or 2FA) will be used to match the configured + access control rules. + - If the token was granted via the `client_credentials` grant then the token will always be considered as having an + authentication level of 1FA and when it comes to matching a subject rule a special subject type `oauth2:client:<id>` + will match the token instead of a user or groups (where `<id>` is the registered client id). See + [Access Control Configuration](#access-control-configuration). + - The audience of the token is also considered and if the token does not have an audience which is an exact match or + the prefix of the URL being requested the authorization will automatically be denied. +- At this time each request using this scheme will cause a lookup to be performed on the authentication backend. +- Specific changes to the client registration will result in the authorization being denied such as: + - The client is no longer registered. + - The `authelia.bearer.authz` scope is removed from the registration. + - The audience which matches the request is removed from the registration. +- The audience of the token must explicitly be requested. Omission of the `audience` parameter may be denied and will + not grant any audience (thus making it useless) even if the client has been whitelisted for the particular audience. + +For example if `john` consents to grant the token and it includes the audience `https://app1.example.com` but the user +`john` is not normally authorized to visit `https://app1.example.com` the token will not grant access to this resource. +In addition if `john` has his access updated via the access control rules, their groups, etc. then this access is +automatically applied to these tokens. + +These rules effectively give both administrators and end-users fine-grained control over which endpoints can utilize +this authorization scheme as administrators will be required to allow each individual URL prefix which can be requested +and end users will be able to request individual audiences from the allowed list (effectively narrowing the audience +of the token). + +The following recommendations should be considered by users who use this authorization method: + +- Using the JWT Profile for Access Tokens effectively makes the introspection stateless and is discouraged for this + purpose unless you have specific performance issues. We would rather find the cause of the performance issues and + improve them in an instance where they are noticed. + +### Audience Request + +While not explicitly part of the specifications the `audience` parameter can be used during the Authorization Request +phase of the Authorization Code Grant Flow or the Access Token Request phase of the Client Credentials Grant Flow. The +specification leaves it up to Authorization Server policy specifically how audiences are granted and this seems like a +common practice. + +### Authorization Endpoint Configuration + +This authorization scheme is not available by default and must be explicitly enabled. The following examples demonstrate +how to enable this scheme (along with the basic scheme). See the +[Server Authz Endpoints](../../configuration/miscellaneous/server-endpoints-authz.md) configuration guide for more +information. + +```yaml +server: + endpoints: + authz: + forward-auth: + implementation: 'ForwardAuth' + authn_strategies: + - name: 'HeaderAuthorization' + schemes: + - 'Basic' + - 'Bearer' + - name: 'CookieSession' + ext-authz: + implementation: 'ExtAuthz' + authn_strategies: + - name: 'HeaderAuthorization' + schemes: + - 'Basic' + - 'Bearer' + - name: 'CookieSession' + auth-request: + implementation: 'AuthRequest' + authn_strategies: + - name: 'HeaderAuthRequestAuthorization' + schemes: + - 'Basic' + - 'Bearer' + - name: 'CookieSession' + legacy: + implementation: 'Legacy' + authn_strategies: + - name: 'HeaderLegacy' + - name: 'CookieSession' +``` + +### Session Configuration + +This feature is only intended to be supported while using the new session configuration syntax. See the example below. + +```yaml +session: + secret: 'insecure_session_secret' + cookies: + - domain: 'example.com' + authelia_url: 'https://auth.example.com' + default_redirection_url: 'https://www.example.com' +``` + +### Access Control Configuration + +In addition to the restriction of the token audience having to match the target location you must also grant access +in the Access Control section of of the configuration either to the user or in the instance of the `client_credentials` +grant the client itself. + +It is important to note that the `client_credentials` grant is **always** treated as 1FA thus only the `one_factor` +policy is useful for this grant type. + +```yaml +access_control: + rules: + ## The 'app1.example.com' domain for the user 'john' regardless if they're using OAuth 2.0 or session based flows. + - domain: app1.example.com + policy: one_factor + subject: 'user:john' + + ## The 'app2.example.com' domain for the 'example-three' client when using the 'client_credentials' grant. + - domain: app2.example.com + policy: one_factor + subject: 'oauth2:client:example-three' +``` +### Client Restrictions + +In addition to the above protections, this scope **_MUST_** only be configured on clients with strict security rules +which must be explicitly set: + +1. Are not configured with any additional scope with the following exceptions: + - The `offline_access` scope. +2. Have both PAR and PKCE with the `S256` challenge enforced. +3. Have a list of audiences which represent the resources permitted to be allowed by generated tokens. +4. Have the `explicit` consent mode. +5. Only allows the `client_credentials`, or the `authorization_code` and `refresh_token` grant types. +6. Only allows the `code` response type. + - This is not relevant for the `client_credentials` grant type. +7. Only allows the `form_post` or `form_post.jwt` response modes. + - This is not relevant for the `client_credentials` grant type. +8. Must either: + - Be a public client with the Token Endpoint authentication method `none`. See configuration option + `token_endpoint_auth_method`. + - Be a confidential client with the Token Endpoint authentication method `client_secret_post`, `client_secret_jwt`, or + `private_key_jwt` configured. See configuration option `token_endpoint_auth_method`. + +#### Examples + +The following examples illustrate how the [Client Restrictions](#client-restrictions) should be applied to a client. + +##### Public Client Example + +```yaml +identity_providers: + oidc: + clients: + - id: 'example-one' + public: true + redirect_uris: + - 'http://localhost/callback' + scopes: + - 'offline_access' + - 'authelia.bearer.authz' + audience: + - 'https://app1.example.com' + - 'https://app2.example.com' + grant_types: + - 'authorization_code' + - 'refresh_token' + response_types: + - 'code' + response_modes: + - 'form_post' + consent_mode: 'explicit' + enforce_par: true + enforce_pkce: true + pkce_challenge_method: 'S256' + token_endpoint_auth_method: 'none' +``` + +##### Confidential Client Example: Authorization Code Flow + +This is likely the most common configuration for most users. + +```yaml +identity_providers: + oidc: + clients: + - id: 'example-two' + secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'. + public: false + redirect_uris: + - 'http://localhost/callback' + scopes: + - 'offline_access' + - 'authelia.bearer.authz' + audience: + - 'https://app1.example.com' + - 'https://app2.example.com' + grant_types: + - 'authorization_code' + - 'refresh_token' + response_types: + - 'code' + response_modes: + - 'form_post' + consent_mode: 'explicit' + enforce_par: true + enforce_pkce: true + pkce_challenge_method: 'S256' + token_endpoint_auth_method: 'client_secret_post' +``` + +##### Confidential Client Example: Client Credentials Flow + +This example illustrates a method to configure a Client Credential flow for this purpose. This flow is useful for +automations. It's important to note that for access control evaluation purposes this token will match a subject of +`oauth2:client:example-two` i.e. the `oauth2:client:` prefix followed by the client id. + +```yaml +identity_providers: + oidc: + clients: + - id: 'example-three' + secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'. + public: false + scopes: + - 'authelia.bearer.authz' + audience: + - 'https://app1.example.com' + - 'https://app2.example.com' + grant_types: + - 'client_credentials' + token_endpoint_auth_method: 'client_secret_post' +``` + +[RFC6750: OAuth 2.0 Bearer Token Usage]: https://datatracker.ietf.org/doc/html/rfc6750 diff --git a/docs/content/en/integration/openid-connect/tailscale/index.md b/docs/content/en/integration/openid-connect/tailscale/index.md index e29d9a3fd..547e91258 100644 --- a/docs/content/en/integration/openid-connect/tailscale/index.md +++ b/docs/content/en/integration/openid-connect/tailscale/index.md @@ -64,7 +64,7 @@ identity_providers: To configure [Tailscale] to utilize Authelia as a [OpenID Connect 1.0] Provider, you will need a public WebFinger reply for your domain (see [RFC7033 Section 3.1]) and point it to Authelia. The steps necessary are outlined in the Tailscale documentation on [Custom OIDC providers KB article]. This WebFinger reply is not generated by Authelia, so your external -webserver hosted at the root of your domain will need to generate the response (Check [See also](#see-also) for example +web server hosted at the root of your domain will need to generate the response (Check [See also](#see-also) for example implementations). The following steps are necessary to get Tailscale working with Authelia: 1. Your domain will need to reply to a WebFinger request for your Authelia account diff --git a/docs/content/en/reference/guides/templating.md b/docs/content/en/reference/guides/templating.md index f4069b1b7..52efd5452 100644 --- a/docs/content/en/reference/guides/templating.md +++ b/docs/content/en/reference/guides/templating.md @@ -99,6 +99,10 @@ The following is a list of special functions and their syntax. This template function takes a single input and is a positive integer. Returns a slice of uints from 0 to the provided input. +#### mustEnv + +Same as [env](#env) except if the environment variable is not set it returns an error. + #### fileContent This template function takes a single input and is a string which should be a path. Returns the content of a file. |