1. This tightly couples the service to the view. Changes in the view and/or service will potentially result in nasty surprises and spaghetti code. For instance, what happens if the business processes change one day and "login" needs to return "logged in but email address unconfirmed"? You want the rules to deal with that scenario confined to a LoginController, not scattered around through each view (consider: an omnipresent login box view vs. a login/signup form view used when a user performs an action that potentially requires login, e.g. "Checkout")
2. In reality, this simple sample obscures what happens in the real world when you add an input for the user key & password:
a. you will need to pass the parameters to the auth service. At that point hopefully you will won't do anything crazy and will simply e.g. bind the user key & password to $scope properties, and pass the scope properties through to the auth service.
b. As stated in (1), your login & logout controller functions need to consider the result of their auth calls and map that result back to a meaningful state for the view -- in the simplest case, it'll just be "logged in" or "logged out", but it can also be e.g. "logged in but email address unconfirmed", which could require a message to be displayed to the user. The best place for this state is again a $scope property.
So, in practice you would just use a $scope.loggedIn or $scope.user property maintained by the controller login() and logout() functions to resolve this issue.
Is it not ok to have all of that state you're talking about down in the service? In my experience any state you have in the controllers can be problematic in bigger apps. When I started out I used to proxy everything through the controller but I've found that you end up with a lot of duplication that doesn't ever seem to pay off.
When you're talking about the various auth states you might have - they could be changed by more than just this view. That state could also be exposed in different controllers / views in different ways. Sort of seems like the state that each of those would use is the same (that in the service) - so is it ok for the views to just reference that state in the service directly?
Interested in hearing where that falls down. I'm fairly new to developing rich interfaces and I've struggled to find completely deinitive information on how best to architect these patterns. Lots of examples out there bind the views to the services but that may be shortsighted.
I'm mostly a back-end developer and I don't have much experience with rich front-end interfaces other than my own little side projects and a WPF project from about a year back - however, I do believe the same principles apply to both front- and back-end design.
Specifically, you should be following the SRP - duplicated code is a symptom that you are not. Without seeing your code that you feel doesn't pay off, it's difficult to answer your question more directly.
I will say there's no reason you can't design your server-side services to be consumed directly by the view, in which case I wouldn't see a problem referencing the service directly from the view (e.g. the UserService exposed by the server implements (a) normal login, (b) login as part of checkout and (c) registration).
Alternatively, you could build a client-side service to wrap the server-side service and reference that directly from your views (e.g. a UserController that wraps the UserService and is consumed by (a) the omnipresent login view, (b) a login/signup view, and (c) the registration view).
Over and above this, there is some middle-ground where you reuse structures. For example, a User structure (with IsAuthenticated, UserName, FullName etc.) would be assigned to a $scope.CurrentUser property for the views. Consequently you don't reimplement the User object the service implements, and you don't vaguely depend on the entire UserService, but the data contract the view does depend on from the controller is still explicit by looking at the $scope definition in the controller. Similarly, the operation contract is defined by the controller functions. This improves maintainability and readability IMO.
It's a problem I have in Angular since I've started using it. You put your data/model in a service, but you need some GUI elements to display the various states of these data, so you put html in the view, some helpers in the controller, maybe you create some custom filters too. At that point you start to think a directive would be better.
Maybe the solution is to make separate modules ?
I'm not good enough in Angular or Javascript to have figured out the best solution yet.
2. In reality, this simple sample obscures what happens in the real world when you add an input for the user key & password:
a. you will need to pass the parameters to the auth service. At that point hopefully you will won't do anything crazy and will simply e.g. bind the user key & password to $scope properties, and pass the scope properties through to the auth service.
b. As stated in (1), your login & logout controller functions need to consider the result of their auth calls and map that result back to a meaningful state for the view -- in the simplest case, it'll just be "logged in" or "logged out", but it can also be e.g. "logged in but email address unconfirmed", which could require a message to be displayed to the user. The best place for this state is again a $scope property.
So, in practice you would just use a $scope.loggedIn or $scope.user property maintained by the controller login() and logout() functions to resolve this issue.