They're not really tests; they're scenarios or examples of how to use your code. If you avoid the word "test" you'll have an easier time, and it will become obvious that 2 is the way forward because you'll be able to discuss your scenarios with the business.
The business have no interest in tests phrased in the way you've described in 1. Business people would generally much rather talk through an example of how to use the code, which will lead inevitably to 2.
Additionally, the fact that you're asking suggests you're not talking to the business yet. Please go have the conversations. It's the most important bit of BDD - far more important than the automation - and will save you a lot of rework and pain, as well as helping to keep the scenarios interesting and maintainable in the event that you do automate them.
That first scenario doesn't describe the behavior any differently to the second one - it just describes the mechanics of the behavior, which will make it harder to change those mechanics later, as well as introducing unnecessary detail. The only time you'd need a scenario phrased in the same way as 1 is if you're really fascinated by logging in. I would prefer to see a scenario focused on the business-valuable activity you're logging in for.