| Allow grouping API keys together. Grouping per se does nothing. This feature is supposed to be used by other modules to limit access to services or records based on groups of keys.
[auth_api_key_server_env](auth_api_key_server_env/) | 18.0.1.0.0 | | Configure api keys via server env. This can be very useful to avoid mixing your keys between your various environments when restoring databases. All you have to do is to add a new section to your configuration file according to the following convention:
+[auth_jwt](auth_jwt/) | 18.0.1.0.0 | 
| JWT bearer token authentication.
[auth_oauth_filter_by_domain](auth_oauth_filter_by_domain/) | 18.0.1.0.0 | 
| Filter OAuth providers by domain
[auth_oauth_multi_token](auth_oauth_multi_token/) | 18.0.2.0.0 | | Allow multiple connection with the same OAuth account
[auth_oidc](auth_oidc/) | 18.0.1.0.0 | | Allow users to login through OpenID Connect Provider
diff --git a/auth_jwt/README.rst b/auth_jwt/README.rst
new file mode 100644
index 0000000000..c63b8c4476
--- /dev/null
+++ b/auth_jwt/README.rst
@@ -0,0 +1,168 @@
+.. image:: https://odoo-community.org/readme-banner-image
+ :target: https://odoo-community.org/get-involved?utm_source=readme
+ :alt: Odoo Community Association
+
+========
+Auth JWT
+========
+
+..
+ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+ !! This file is generated by oca-gen-addon-readme !!
+ !! changes will be overwritten. !!
+ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+ !! source digest: sha256:0257cb75b9a02ab9b3f1aeebe8e0c5aee0b983f8b5ac1692132897dfb1986d02
+ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+.. |badge1| image:: https://img.shields.io/badge/maturity-Beta-yellow.png
+ :target: https://odoo-community.org/page/development-status
+ :alt: Beta
+.. |badge2| image:: https://img.shields.io/badge/license-LGPL--3-blue.png
+ :target: http://www.gnu.org/licenses/lgpl-3.0-standalone.html
+ :alt: License: LGPL-3
+.. |badge3| image:: https://img.shields.io/badge/github-OCA%2Fserver--auth-lightgray.png?logo=github
+ :target: https://github.com/OCA/server-auth/tree/18.0/auth_jwt
+ :alt: OCA/server-auth
+.. |badge4| image:: https://img.shields.io/badge/weblate-Translate%20me-F47D42.png
+ :target: https://translation.odoo-community.org/projects/server-auth-18-0/server-auth-18-0-auth_jwt
+ :alt: Translate me on Weblate
+.. |badge5| image:: https://img.shields.io/badge/runboat-Try%20me-875A7B.png
+ :target: https://runboat.odoo-community.org/builds?repo=OCA/server-auth&target_branch=18.0
+ :alt: Try me on Runboat
+
+|badge1| |badge2| |badge3| |badge4| |badge5|
+
+JWT bearer token authentication.
+
+**Table of contents**
+
+.. contents::
+ :local:
+
+Installation
+============
+
+This module requires the ``pyjwt`` library to be installed.
+
+Usage
+=====
+
+This module lets developpers add a new ``jwt`` authentication method on
+Odoo controller routes.
+
+To use it, you must:
+
+- Create an ``auth.jwt.validator`` record to configure how the JWT token
+ will be validated.
+- Add an ``auth="jwt_{validator-name}"`` or
+ ``auth="public_or_jwt_{validator-name}"`` attribute to the routes you
+ want to protect where ``{validator-name}`` corresponds to the name
+ attribute of the JWT validator record.
+
+The ``auth_jwt_demo`` module provides examples.
+
+The JWT validator can be configured with the following properties:
+
+- ``name``: the validator name, to match the
+ ``auth="jwt_{validator-name}"`` route property.
+- ``audience``: a comma-separated list of allowed audiences, used to
+ validate the ``aud`` claim.
+- ``issuer``: used to validate the ``iss`` claim.
+- Signature type (secret or public key), algorithm, secret and JWK URI
+ are used to validate the token signature.
+
+In addition, the ``exp`` claim is validated to reject expired tokens.
+
+If the ``Authorization`` HTTP header is missing, malformed, or contains
+an invalid token, the request is rejected with a 401 (Unauthorized)
+code, unless the cookie mode is enabled (see below).
+
+If the token is valid, the request executes with the configured user id.
+By default the user id selection strategy is ``static`` (i.e. the same
+for all requests) and the selected user is configured on the JWT
+validator. Additional strategies can be provided by overriding the
+``_get_uid()`` method and extending the ``user_id_strategy`` selection
+field.
+
+The selected user is *not* stored in the session. It is only available
+in ``request.uid`` (and thus it is the one used in ``request.env``). To
+avoid any confusion and mismatches between the bearer token and the
+session, this module rejects requests made with an authenticated user
+session.
+
+Additionally, if a ``partner_id_strategy`` is configured, a partner is
+searched and if found, its id is stored in the
+``request.jwt_partner_id`` attribute. If ``partner_id_required`` is set,
+a 401 (Unauthorized) is returned if no partner was found. Otherwise
+``request.jwt_partner_id`` is left falsy. Additional strategies can be
+provided by overriding the ``_get_partner_id()`` method and extending
+the ``partner_id_strategy`` selection field.
+
+The decoded JWT payload is stored in ``request.jwt_payload``.
+
+The ``public_auth_jwt`` method delegates authentication to the standard
+Odoo ``public`` method when the Authorization header is not set. If it
+is set, the regular JWT authentication is performed as described above.
+This method is useful for public endpoints that need to work for
+anonymous users, but can be enhanced when an authenticated user is know.
+A typical use case is a "add to cart" endpoint that can work for
+anonymous users, but can be enhanced by binding the cart to a known
+customer when the authenticated user is known.
+
+You can enable a cookie mode on JWT validators. In this case, the JWT
+payload obtained from the ``Authorization`` header is returned as a
+Http-Only cookie. This mode is sometimes simpler for front-end
+applications which do not then need to store and protect the JWT token
+across requests and can simply rely on the cookie management mechanisms
+of browsers. When both the ``Authorization`` header and a cookie are
+provided, the cookie is ignored in order to let clients authenticate
+with a different user by providing a new JWT token.
+
+Bug Tracker
+===========
+
+Bugs are tracked on `GitHub Issues 
JWT bearer token authentication.
+Table of contents
+This module requires the pyjwt library to be installed.
+This module lets developpers add a new jwt authentication method on +Odoo controller routes.
+To use it, you must:
+The auth_jwt_demo module provides examples.
+The JWT validator can be configured with the following properties:
+In addition, the exp claim is validated to reject expired tokens.
+If the Authorization HTTP header is missing, malformed, or contains +an invalid token, the request is rejected with a 401 (Unauthorized) +code, unless the cookie mode is enabled (see below).
+If the token is valid, the request executes with the configured user id. +By default the user id selection strategy is static (i.e. the same +for all requests) and the selected user is configured on the JWT +validator. Additional strategies can be provided by overriding the +_get_uid() method and extending the user_id_strategy selection +field.
+The selected user is not stored in the session. It is only available +in request.uid (and thus it is the one used in request.env). To +avoid any confusion and mismatches between the bearer token and the +session, this module rejects requests made with an authenticated user +session.
+Additionally, if a partner_id_strategy is configured, a partner is +searched and if found, its id is stored in the +request.jwt_partner_id attribute. If partner_id_required is set, +a 401 (Unauthorized) is returned if no partner was found. Otherwise +request.jwt_partner_id is left falsy. Additional strategies can be +provided by overriding the _get_partner_id() method and extending +the partner_id_strategy selection field.
+The decoded JWT payload is stored in request.jwt_payload.
+The public_auth_jwt method delegates authentication to the standard +Odoo public method when the Authorization header is not set. If it +is set, the regular JWT authentication is performed as described above. +This method is useful for public endpoints that need to work for +anonymous users, but can be enhanced when an authenticated user is know. +A typical use case is a “add to cart” endpoint that can work for +anonymous users, but can be enhanced by binding the cart to a known +customer when the authenticated user is known.
+You can enable a cookie mode on JWT validators. In this case, the JWT +payload obtained from the Authorization header is returned as a +Http-Only cookie. This mode is sometimes simpler for front-end +applications which do not then need to store and protect the JWT token +across requests and can simply rely on the cookie management mechanisms +of browsers. When both the Authorization header and a cookie are +provided, the cookie is ignored in order to let clients authenticate +with a different user by providing a new JWT token.
+Bugs are tracked on GitHub Issues. +In case of trouble, please check there if your issue has already been reported. +If you spotted it first, help us to smash it by providing a detailed and welcomed +feedback.
+Do not contact contributors directly about support or help with technical issues.
+This module is maintained by the OCA.
+ +
+
+OCA, or the Odoo Community Association, is a nonprofit organization whose +mission is to support the collaborative development of Odoo features and +promote its widespread use.
+Current maintainer:
+
This module is part of the OCA/server-auth project on GitHub.
+You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.
+