なぜウェブアプリでトークンを設定して認証する必要があるの？Django RestとDjangoでの話 （分かりやすく説明）

普通のDJANGO：
フロントエンドのページは全部バックエンドでレンダリングされるので、バックエンドはフロントエンドのページを自分で作ってるっていうのを知っている。だから、ユーザーオブジェクトをテンプレートページに簡単に渡すことができるんだ。テンプレート言語を使ったら、フロントエンド（HTMLの中）で'user.is_authenticated'を使ってログイン状態をテストすることができる。まるでバックエンドの一部が、特別なテンプレート言語、例えばJinja2を通してフロントエンドに送られるようなもんで、一般的なJSON形式ではなく（注意してね）ユーザーのブラウザ上でレンダリングされる。

バックエンドの一部がフロントエンドと共に送られるという事実が、すでにあるレベルのセキュリティを確立している。なぜなら、'is_authenticated'をTrueに変えるのをちょっと難しくしているから。フロントエンドはここでは「甘やかされている」感じだね！

DJANGO REST：
あ～、こっちでは甘やかし無し！フロントエンドはバックエンドから切り離されているよ！切り離されているってことは、レンダリングの仕事はフロントエンド（ReactみたいなJavascriptのフレームワークでよくある'state'の概念があるけれども、それについてはいつか話そう）が担っているって意味だ。フロントエンドのページはReactが作り出している。バックエンドはただ生のデータを持ってくるんだ。

フロントエンドは、「うん、そこに置いといて、レンダリングは自分でやるから。もう十分に大人だし！」と言うんだ。この態度がバックエンドがフロントエンドに同じ'is_authenticated'属性を簡単に渡せない理由なんだ。駄目だね！代わりにトークンを渡すんだよ。これは非常に長い英数字のセットで、簡単には偽造できない。このトークンがフロントエンドにバックエンドのデータへのアクセスを許可するんだ。バックエンドはトークンでユーザーを識別でき、有効期限の情報も埋め込まれている。フロントエンドの態度がバックエンドの厳しい振る舞いを受け入れるに値しないかもしれないけど、でも、ページはもうバックエンドから提供されなくなったんだよ。

もし'is_authenticated'属性が使われたとしたら、普通のDjangoの特別な形式とは対照的にJSON形式で来ることになる。JSONは多くのプログラミング言語が会合点として認識している形式だ。だから、単純に{is_authenticated : true}を想像してみて。フロントエンドの人が簡単なAPIツールを使ってJSONで{is_authenticated : true}を属性としてバックエンドに送り返して、バックエンドがそれをパスとして扉を大きく開けてくれるなんてことは、考えられないんだ。

こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/frankezenwanne/why-you-need-to-set-tokens-in-web-apps-for-authentication-in-django-rest-and-not-django--2iem