mod_authn_socache - Apache HTTP Server Version 2.4









Modules | Directives | FAQ | Glossary | Sitemap
Apache HTTP Server Version 2.4



Apache > HTTP Server > Documentation > Version 2.4 > Modules

Apache Module mod_authn_socache

Available Languages:  en  |
 fr 

Description:Manages a cache of authentication credentials to relieve
the load on backends
Status:Base
Module Identifier:authn_socache_module
Source File:mod_authn_socache.c
Compatibility:Version 2.3 and later
Summary

    Maintains a cache of authentication credentials, so that a new backend
    lookup is not required for every authenticated request.

Topics

 Authentication Caching
 Usage
 Caching with custom modules
Directives

 AuthnCacheContext
 AuthnCacheEnable
 AuthnCacheProvideFor
 AuthnCacheSOCache
 AuthnCacheTimeout

Bugfix checklisthttpd changelogKnown issuesReport a bugSee also

Comments


Authentication Caching
    Some users of more heavyweight authentication such as SQL database
    lookups (mod_authn_dbd) have reported it putting an
    unacceptable load on their authentication provider.  A typical case
    in point is where an HTML page contains hundreds of objects
    (images, scripts, stylesheets, media, etc), and a request to the page
    generates hundreds of effectively-immediate requests for authenticated
    additional contents.
    mod_authn_socache provides a solution to this problem by
    maintaining a cache of authentication credentials.


Usage
    The authentication cache should be used where authentication
    lookups impose a significant load on the server, or a backend or
    network.  Authentication by file (mod_authn_file)
    or dbm (mod_authn_dbm) are unlikely to benefit,
    as these are fast and lightweight in their own right (though in some
    cases, such as a network-mounted file, caching may be worthwhile).
    Other providers such as SQL or LDAP based authentication are more
    likely to benefit, particularly where there is an observed
    performance issue.  Amongst the standard modules, mod_authnz_ldap manages its own cache, so only
    mod_authn_dbd will usually benefit from this cache.
    The basic rules to cache for a provider are:
    Include the provider you're caching for in an
            AuthnCacheProvideFor directive.
        List socache ahead of the provider you're
            caching for in your AuthBasicProvider or AuthDigestProvider directive.
    
    A simple usage example to accelerate mod_authn_dbd
    using dbm as a cache engine:
    #AuthnCacheSOCache is optional.  If specified, it is server-wide
AuthnCacheSOCache dbm
<Directory "/usr/www/myhost/private">
    AuthType Basic
    AuthName "Cached Authentication Example"
    AuthBasicProvider socache dbd
    AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
    AuthnCacheProvideFor dbd
    Require valid-user
    #Optional
    AuthnCacheContext dbd-authn-example
</Directory>



Caching with custom modules
    Module developers should note that their modules must be enabled
    for caching with mod_authn_socache.  A single optional API function
    ap_authn_cache_store is provided to cache credentials
    a provider has just looked up or generated.  Usage examples are
    available in r957072, in which three authn providers are enabled for caching.


AuthnCacheContext Directive

Description:Specify a context string for use in the cache key
Syntax:AuthnCacheContext directory|server|custom-string
Default:AuthnCacheContext directory
Context:directory
Status:Base
Module:mod_authn_socache

    This directive specifies a string to be used along with the supplied
    username (and realm in the case of Digest Authentication) in constructing
    a cache key.  This serves to disambiguate identical usernames serving
    different authentication areas on the server.
    Two special values for this are directory, which uses
    the directory context of the request as a string, and server
    which uses the virtual host name.
    The default is directory, which is also the most
    conservative setting.  This is likely to be less than optimal, as it
    (for example) causes $app-base, $app-base/images,
    $app-base/scripts and $app-base/media each to
    have its own separate cache key.  A better policy is to name the
    AuthnCacheContext for the password
    provider: for example a htpasswd file or database table.
    Contexts can be shared across different areas of a server, where
    credentials are shared.  However, this has potential to become a vector
    for cross-site or cross-application security breaches, so this directive
    is not permitted in .htaccess contexts.



AuthnCacheEnable Directive

Description:Enable Authn caching configured anywhere
Syntax:AuthnCacheEnable
Context:server config
Status:Base
Module:mod_authn_socache

    This directive is not normally necessary: it is implied if
    authentication caching is enabled anywhere in httpd.conf.
    However, if it is not enabled anywhere in httpd.conf
    it will by default not be initialised, and is therefore not
    available in a .htaccess context.  This directive
    ensures it is initialised so it can be used in .htaccess.



AuthnCacheProvideFor Directive

Description:Specify which authn provider(s) to cache for
Syntax:AuthnCacheProvideFor authn-provider [...]
Default:None
Context:directory, .htaccess
Override:AuthConfig
Status:Base
Module:mod_authn_socache

    This directive specifies an authentication provider or providers
    to cache for.  Credentials found by a provider not listed in an
    AuthnCacheProvideFor directive will not be cached.

    For example, to cache credentials found by mod_authn_dbd
    or by a custom provider myprovider, but leave those looked
    up by lightweight providers like file or dbm lookup alone:
    AuthnCacheProvideFor dbd myprovider




AuthnCacheSOCache Directive

Description:Select socache backend provider to use
Syntax:AuthnCacheSOCache provider-name[:provider-args]
Context:server config
Status:Base
Module:mod_authn_socache
Compatibility:Optional provider arguments are available in
Apache HTTP Server 2.4.7 and later

    This is a server-wide setting to select a provider for the
    shared object cache, followed by
    optional arguments for that provider.
    Some possible values for provider-name are "dbm", "dc",
    "memcache", or "shmcb", each subject to the appropriate module
    being loaded.  If not set, your platform's default will be used.



AuthnCacheTimeout Directive

Description:Set a timeout for cache entries
Syntax:AuthnCacheTimeout timeout (seconds)
Default:AuthnCacheTimeout 300 (5 minutes)
Context:directory, .htaccess
Override:AuthConfig
Status:Base
Module:mod_authn_socache

    Caching authentication data can be a security issue, though short-term
    caching is unlikely to be a problem.  Typically a good solution is to
    cache credentials for as long as it takes to relieve the load on a
    backend, but no longer, though if changes to your users and passwords
    are infrequent then a longer timeout may suit you.  The default 300
    seconds (5 minutes) is both cautious and ample to keep the load
    on a backend such as dbd (SQL database queries) down.
    This should not be confused with session timeout, which is an
    entirely separate issue.  However, you may wish to check your
    session-management software for whether cached credentials can
    "accidentally" extend a session, and bear it in mind when setting
    your timeout.




Available Languages:  en  |
 fr 

Copyright 2026 The Apache Software Foundation.Licensed under the Apache License, Version 2.0.
Modules | Directives | FAQ | Glossary | Sitemap