Learn Authelia - Consent Management

#Introduction

In episode 19 you successfully integrated Grafana, Gitea or Forgejo, Nextcloud, and Portainer. On the first login, there's always a screen asking for permission: which application is requesting access, and what scopes it's asking for. That's the consent screen, and episode 20 covers how to manage it.

Consent is a user's approval of an application's request to read their identity data. This concept is similar to phone app permissions: the camera app isn't automatically allowed to read contacts just because you installed it. In the identity world, consent becomes the bridge between SSO convenience and user control over their own data.

#What the Consent Screen Shows

When a client redirects a user to Authelia for the first time, Authelia shows a consent screen containing:

• The name and description of the client requesting access.
• The list of requested scopes, translated into human-readable permissions.
• An option to remember the approval (pre-configured consent) if the client mode supports it.

The user isn't asked "give all your data" — they're asked specifically, for example "the app wants to see your name and email address". This transparency lets users reject applications that ask for too much.

#Consent Mode per Client

Consent policy is configured per client via consent_mode. Its four values:

#Configuring the Consent Mode

An example client with pre-configured consent for three months:

identity_providers:
  oidc:
    clients:
      - id: client-b
        description: Internal application
        secret: '$plaintext$client-secret'
        consent_mode: pre-configured
        pre_configured_consent_duration: 3 months
        redirect_uris:
          - https://b.example.com/callback
        post_logout_redirect_uris:
          - https://b.example.com/logout

pre_configured_consent_duration determines how long the "remember approval" choice lasts. Pre-configured consent only applies if the subject, client, scopes, and audience requested are exactly the same as what was already approved. Change the scope even slightly, and the consent screen appears again.

#Forcing the Consent Screen: prompt=consent

A client can force the consent screen to always appear by sending the prompt=consent parameter on the authorization request. Conversely, prompt=none forbids all interaction — useful for background session checks. Keep in mind:

• prompt=none is invalid when paired with explicit consent.
• prompt=consent is invalid on a client with implicit consent.

#post_logout_redirect_uris

When a user logs out of an application, the application can redirect them back to Authelia to terminate the SSO session, then back to a safe page. The list of allowed destinations is declared in post_logout_redirect_uris. Authelia only forwards to registered URIs — preventing open redirects that could be abused for phishing.

#Per-Client Authorization Policy

Besides consent, Authelia has a per-client authorization_policy to determine the authentication method before the OIDC flow runs. For complex policies, define authorization_policies then reference them by name:

identity_providers:
  oidc:
    authorization_policies:
      two-factor:
        default_policy: two_factor
        rules:
          - policy: deny
            subject: 'group:blocked'
    clients:
      - id: client-c
        description: Internal dashboard
        secret: '$plaintext$client-secret'
        authorization_policy: two-factor
        redirect_uris:
          - https://c.example.com/callback

This means the client-c client requires two factors for everyone except members of the blocked group, who are denied outright. Consent and authorization work in layers — consent answers "may this application read the data?" while the authorization policy answers "does this user deserve to get this far?".

#Revoking Consent

Already-granted consent isn't permanent. Users can view and revoke their permissions via the Authelia portal, in the activity and sessions section. After revocation, the next authorization will show the consent screen again, and the application must ask anew.

Note: revoking consent doesn't immediately destroy tokens that have already been issued. Tokens remain valid until they expire. If you need to cut access instantly — for example because of a lost device — terminate the session in Authelia and revoke the consent at the same time.

#Closing

In this episode you understood:

• The consent screen transparently shows the client and the scopes it requests.
• consent_mode controls consent behavior per client: auto, explicit, pre-configured, and implicit.
• prompt=consent and prompt=none control when the consent screen appears.
• post_logout_redirect_uris restricts the destination after logout.
• authorization_policy separates the authorization policy from consent.
• Users can revoke consent via the portal.

Now we're ready to face the real enemy. In episode 21, we discuss Brute Force Protection (Regulation) — how Authelia blocks repeated login attempts and how to tune it without trapping legitimate users. See you there!