--- layout: default title: Single Factor parent: Features nav_order: 3 --- # Single Factor **Authelia** supports single factor authentication to let applications send authenticated requests to other applications. Single or two-factor authentication can be configured per resource of an application for flexibility. For instance, you can configure Authelia to grant access to all resources matching `app1.example.com/api/(.*)` with only a single factor and all resources matching `app1.example.com/admin` with two factors. To know more about the configuration of the feature, please visit the documentation about the [configuration](../configuration/access-control.md). ## HTTP Basic Auth Authelia supports two different methods for basic auth. ### Proxy-Authorization header Authelia reads credentials from the header `Proxy-Authorization` instead of the usual `Authorization` header. This is because in some circumstances both Authelia and the application could require authentication in order to provide specific authorizations at the level of the application. ### API argument If instead of the `Proxy-Authorization` header you want, or need, to use the more conventional `Authorization` header, you should then configure your reverse-proxy to use `/api/verify?auth=basic`. When authentication fails and `auth=basic` was set, Authelia's response will include the `WWW-Authenticate` header. This will cause browsers to prompt for authentication, and users will not land on the HTML login page. ## Session-Username header Authelia by default only verifies the cookie and the associated user with that cookie can access a protected resource. The client browser does not know the username and does not send this to Authelia, it's stored by Authelia for security reasons. The Session-Username header has been implemented as a means to use Authelia with non-web services such as PAM. Basically how it works is if the Session-Username header is sent in the request to the /api/verify endpoint it will only respond with a sucess message if the cookie username and the header username match. ### Example These examples are for demonstration purposes only, the original use case and full instructions are described [here](https://github.com/authelia/authelia/issues/1322#issuecomment-729519155). You will need to adjust the FORWARDED_HOST and VERIFY_URL vars to achieve a functional result. #### PAM Rule `auth [success=1 default=ignore] pam_exec.so expose_authtok /usr/bin/pam-authelia ` #### PAM Script ```bash #!/bin/bash # The password from stdin PAM_PASSWORD=$(cat -) # url from which authelia session key was created FORWARDED_HOST=auth.example.com # internal path to verify api VERIFY_URL=http://127.0.0.1:80/api/verify AUTH_RESULT=$(curl -b "authelia_session=${PAM_PASSWORD}" -H "Session-Username: ${PAM_USER}" -H "X-Forwarded-Host: ${FORWARDED_HOST}" -H "X-Forwarded-Proto: https" -s -o /dev/null -I -w "%{http_code}" -L "${VERIFY_URL}") if [[ "$AUTH_RESULT" == 200 ]]; then echo "Auth verify ok" exit 0 else echo "Auth verify failed $AUTH_RESULT" exit 1 fi ```