Search code examples
python-3.xangularelasticsearchweb-applicationsoauth-2.0

Which layer to put authentication / session management for a web app with ElasticSearch

We are building a ticketing web application the components of which are

datastore - PostgreSQL for relational data, ElasticSearch for ticket logs' text (to enable search capability)

backend - Python FastAPI

frontend - Nginx reverse proxy with Angular/HMTL as UI

Once a user successfully logs in with their username and password (which is stored in the database), that user can view his/her own team's ticket plus an ability to keyword search the logs of all tickets (history of comments logged by user who handled that ticket), and the associated tickets themselves, of course.

As I am quite new with building web applications, this is more of an application design question (which includes authentication part). My questions are:

  1. Using OAuth2 authentication, which layer handles session management, the frontend or the backend?

  2. Should we use ElasticSearch's own Authentication API (OAuth2 also) in addition to the one in frontend/backend?

  3. If the answer to (2) is yes, can you suggest on how to integrate these two authentication mechanisms?

  4. Should the frontend or backend call the ElasticSearch's API to pull data?

  5. If the answer to (2) is no and to (4) is backend, is it sufficient to put ElasticSearch in a private network that can only be accessed by the backend server?

Solution

    1. The session should be represented by a secure cookie or token that identifies the user. In most cases this ID maps to database storage and I would aim to avoid separate session storage unless there is a good reason.

    2. Probably not - over time your apps are likely to need many security features - this set of Curity Concepts articles may give you an idea of common requirements.

    3. Your APIs should consider Elastic Search to be one of many possible data sources. See if you can use Elastic's Client Credentials Grant to get data. The API may then need to check access or filter based on User IDs, and this could be a tricky part of the data setup.

    4. Back end

    5. Elastic Search should not be exposed to the internet - nor should any other component that connects to sensitive data sources. The usual solution is to put a reverse proxy in front of it - such as NGINX / Kong or a cloud API Gateway.