I am not joking. There is absolutely no reason to put an admin interface in an app.
Here is an example applicaion, let's call it Foo. It's a blogging tool:
* FooCore: This is an API exposing the data Foo that works with, and the ways to change that data. It has a Blog model, a Posting model and an Author model. It has endpoints like "GET /api/blogs", "PUT /api/blogs/:id/postings" and "GET /api/authors/:id" to create blogs and postings. It has no UI.
* FooApp: This is the user-facing frontend application. It serves the main site in HTML, JS, CSS and whatever other. It renders blogs from FooCore by calling is API. It has no logic other than presenting the UI and acting as an MVC controller and view (the M being the API). It calls the API both from its server app, as well from the browser via XMLHttpRequest.
* FooAdmin: This is the user-facing admin frontend app. It serves the "back office" admin UI for managing blogs and posts and users.
We now have a very elegant app where the division between the parts is crystal clear. The admin UI's requirements do not affect the public UI's requirements or vice versa. The underlying data model can't build up weird UI cruft because there is no UI to let sloppy devs screw it up with their laziness.
(Need a new UI -- say, you want to accept blog postings via email? Create a new app, FooEmailApp that handles only this interaction using the same API. Want to accept blog postings by fax? Create a new app, FooFaxApp. Neither frontends will have code that bogs down the other UIs. If you decide fax is dead, just delete the entire app.)
(And you can extend your own ecosystem of services organically. Need role-based permissions? Create an app for it, and wrap every HTTP verb with a check against the permission app.)
Anyway, the above app is not complete; you want login via Twitter, so we add Checkpoint into the mix. This happens:
1. When FooCore wants needs a user, it looks in its session cookie and determines which user it is.
2. If there is no user, we create a redirect to Checkpoint's /login/twitter. Checkpoint does the necessary OAuth interaction behind the scenes, stores the credentials in its store, update its own cookie, and redirects back to FooCore. (Remember, Checkpoint has no UI. It just redirects to Twitter, which displays the usual OAuth login/authorization dialog.)
3. FooCore can now use Checkpoint's cookie to determine who the logged-in user is, and it can ask Checkpoint for data such as the user's name and email. It can also create an internal User object that represents FooCore's own data about the user, such as blogs and postings.
The upshot: The app knows nothing about authentication. It outsources everything. It can focus on the important stuff.
This modular separation of concerns into separate apps sharpens your focus as a developer, and forces you to think about the data and the interactions that are necessary. Because of HTTP/REST's relative poverty, everything becomes a verb, and every verb must be designed separately.
Two other benefits: It forces you to think of reuse, since every feature becomes an opportunity to reuse a modular component. Secondly, it forces you to think of "presentation" and the divison between ugly internal state and public state, because every interface becomes much more exposed to the world; when an app becomes an API, you are subject to more scrutiny than if you were tucking the stuff away in some class somewhere in your app.
No, I'm not kidding. Back in 2006 we tried the old model of putting everything and kitchen sink (login/auth, normal UI, admin UI, promo site, email notifications, role-based permissions, statistics, visualizations, image upload etc.) into our apps. The model does not scale. The benefits of a "many small apps" model have been obvious even for relatively small applications.
I'm not defending anything. If anything I'm attacking? :-)