ログイン認証ありシステムをangularjsで実装する場合について、postでサーバにアイパスを送り、認証結果をjsonを返すことを考えています。

ログインしている状態をクライアントに持ってしまうのはまずいと思います。
ログインしている状態が真っ当なものかどうかの判定は、都度 サーバ側で行うべきです。

「アイパス」＝「アイ（ディー）（＆）パス（ワード）」なんでしょう、きっと。
ぼくも、初めて耳にしました　:-)

サーバ側からデータを取ってくるなどする時はサーバ側でクッキーなりトークンなりで認証する必要ありますが、クライアント側でのページ遷移とかフォームとかの切り替えなどはサーバ側に問い合わせなくてもクライアント側で閉じて問題ないと思いますよ。
元々クライアント側に見られて問題になる情報はないはずですから。

もし、クライアント側をいじってログイン状態を詐称しても、サーバ側にあるデータを使わない限りは元々非ログイン状態で読む事が出来る情報ですし、そうでない情報はサーバ側にあって、そっちは詐称してもエラーになってアクセスできないはずなので。

酔っぱらった状態での斜め読みでしたが、Qiita の記事ではログインフレームを通り抜けた後にユーザのインスタンスを抱えていて、それがあればログイン状態だ、と判定しているようなので。

そうでない情報はサーバ側にあって、そっちは詐称してもエラーになってアクセスできないはずなので。

この辺りのことが言及されてないと思うんですけれども。

確かにそうですね。
この質問は「サーバ側はサーバ側で認証してセッション維持するけど、クライアント側はどうするの？」って質問だと思いました。
ただ「サーバ側で認証した後、普通はサーバで持つセッション情報をクライアント側でどう持つの？」って質問にもよめますね。

大前提はサーバはサーバで認証状態を保持してそれに基いて情報をやり取りする。
Qiitaのはその辺まるっと書かず、クライアント側のみ、認証も認証になってないダミーで書いてます。

この質問は「サーバ側はサーバ側で認証してセッション維持するけど、クライアント側はどうするの？」って質問だと思いました。

ああ、そうか。
ぼくの頭の中では、「（URL を中抜きされたみたいなやつをガードするような）ログイン中という認証は、Angular.js だとどうやって実装するの？」というふうに質問を理解してました。

セッション情報をどう持つか、という話であれば、ステートレスな http だからこそ工夫しなくちゃいけないわけで、ステートフルにも書ける Angular.js なら気にしなくても良いよね、という感じでしょうか。

JSON Web Token ってのがあるんですね。
寡聞にして初耳でした。
ライブラリもいっぱいあるし、有効期限も含めて検証が javascript だけでもできるっぽい。

回答者も、教えてもらってることがいっぱいあります　:-)