What is the difference between Concurrent Login and Concurrent Session?

Background information

Working on a Spring application with Hikari Connection Pooling that is connecting to Business Critical Azure SQL Server Instance.

The limitations on Azure's side of the DB instance are:

1. 200 Workers
2. 200 Logins
3. 30k Sessions

We have 3 application servers deployed with a Hikari CP.

As far as I know:

1. The application's Hikari connection pool is opening new TCP connections as they are needed and pooling them for spring data / hibernate / etc.
2. An SQLConnection from the application's POV is using the Connectionstring to build a TCP connection to the server through which the protocol data (incl. authentication) and sql queries will be transmitted
3. According to the limitations listed above the number of TCP connections is not limited
4. In my understanding workers are processes/threads that actually execute SQL queries against the database and retrieve results.
5. One query/statement might use multiple workers, if it can be parallelized
6. (although haven't find the documentation) It is easy to see that the Logins are capped by the workers because whoever logs in, and wants to interact with the DB will need a worker that is executing the statements that is provided with the security context of the logged in user
7. According to this: "Sessions refers to the number of concurrent connections allowed to a SQL database at a time. Workers can be thought of as the processes in the SQL database that are processing queries. The maximum number of sessions and workers allowed depends on your databases’s service tier."

Questions

1. Can the spring applications make a total of ~30k connections or ~200 connections (assuming no other application connects to the database) with the same username and password?
2. How shall Azure SQL Login / Azure SQL Session be interpreted in this context?

Note: I am aware that I can test this by launching N applications to connect and monitor the behavior, what I am frustrated about is how I cannot find the relevant documentation that could help me answer the question for myself.

Your understanding of workers is correct.

Logins are users actively authenticating with the server. It's pretty rare to run into this issue, but it can happen if your architecture involves a lot of disconnect/reconnect type actions. Username/Password doesn't matter in this context. You just don't want to try to spin up 200 instances of your application at the same time.

While it's pretty rare to run into the login limit, running into the session limit is something you need to keep an eye on. Each connection that Hikari creates in the pool counts as a session on the Azure SQL side. That being said, with only 3 servers, you could open 10k connections in each pool and be fine. Probably not an issue for you right now unless you do something that prevents Hikari from properly closing connections when it needs to. I'm not too familiar with Hikari, so I can't give you a specific example of what would cause this.