As mentioned in a comment, I'd need more details what makes this so difficult - this would give us ideas where to split. But apart from that, there is one way: separate the presentation from the backend operation. I.e., if you cannot complete this task in a sprint, then implement the backend first - so a user could, in theory, log in using a simple POST request; don't implement any GUI, no detailed error messages, etc.
Concentrate on making that API call secure as it should be, with features like enforcing HTTPS, storing/checking passwords in a safe manner (i.e., using a good hash, not plaintext), delivering your cookies in a good way, and so on. Decide what kind of session management you want to do (server-side in a DB, or just client-side in a sufficiently encrypted cookie). If you cannot manage the more complicated version in your sprint, then decide to do the easier one instead, and come back to it later.
Do not ship a version that misses essential security features. If you cannot even do that in one sprint, then it will be hard to find anything to improve, and you will have to take a good, hard look at your sprint length...
In the next sprint, add the GUI part; from that point onward you can more easily deliver only small increments. For example, in the first login GUI release, you may only implement the "positive" path, and skip all fluff regarding error feedback. There might only be generic error messages in case of trouble (or, even, no error messages, just a redirect to the empty form if you so wish).