In my Spring Authorization Server, I have a customized form login page and endpoint. (GET /login and POST /login respectively). My application is a combined authorization server and resource server, using OpenID Connect. The majority of the application uses JWT access tokens for authorization/authentication, but regular Spring Security HttpSessions are used in the initial login flow.

When the user issues an /oauth2/authorize request without a valid JSESSIONID cookie they are redirected to the /login page to authenticate themselves with the auth server (and given a session ID as a cookie). The user types in their credentials and submits the form as a POST /login request. If this succeeds, their session is authenticated on the server-side and associated with their account. Then, the user can call /oauth2/authorize again with the session ID cookie and get an authorization code.

The JESSIONID cookie can be persisted and useful for a long time period (like several days or a week), to reduce user friction when authenticating across multiple client applications. The cookie is not used in any other requests, besides GET /oauth2/authorize and POST /login. I have read online that if you use cookies with session IDs, you should always have CSRF protection enabled. However in my case, the cookie is only useful during the login flow, and can't be used to authenticate/authorize any other requests, like resource server requests (e.g. /change-password, /delete-account, etc).

In Spring Security, POST method requests have CSRF protection enabled by default. Is CSRF protection necessary on POST /login in my case? I can't think of any benefit an attacker could have by performing a CSRF attack on a victim with the POST /login endpoint, since the victim would be required to type in their own credentials willingly anyways.