我在Heroku上構建了一個Rails應用程序。在哪些情況下你需要在devise上實現這些複雜的令牌認證（Rails 3.2）
我安裝了設備來管理用戶身份驗證，我想添加「token authenticatable」。
我基本上是用this tutorial和它的偉大工程
不過，我跑過更復雜的教程的令牌可鑑別這樣的兩個1：
我不明白他們爲什麼比我實現的複雜得多？他們似乎提到了「移動」的東西，這是否意味着它是一種使用「令牌可認證」的更復雜的方式，因爲它允許在更多的使用情況下進行認證，例如在移動設備上進行認證？
真的在黑暗中，所以我很感激任何幫助。
在大多數情況下，在（本機）手機應用程序身份驗證的工作幾乎相同的方式，認證通過瀏覽器：用戶給他的證書，這些都通過線路服務器/應用程序發送的，並且應用程序通過給用戶一個表示認證會話的「令牌」做出響應。
的主要區別：基於瀏覽器的客戶一般會提出說使用HTML表單的HTTP POST憑證，使用application/x-www-form-urlencoded。返回的標記通常以會話cookie的形式給出，瀏覽器在隨後的每個HTTP請求中都會顯示該cookie。
本地移動客戶端，另一方面，雖然作爲瀏覽器不是限制爲HTML的做事方式，並且大多數不使用cookie。
典型的移動客戶端使用Web服務API 。儘可能將大多數API設計爲無狀態（與瀏覽器/基於cookie的會話不同）。
大多數Web服務API還需要/希望能夠發送儘可能多的層次化複雜數據，儘可能使用盡可能少的帶寬。因此，他們贊成結構化數據的更簡潔的表示，例如JSON（或在某些情況下，BSON）。
在大多數情況下，爲好，不希望將目前的認證令牌的網址查詢參數（或者，如果你發送過JSON有效載荷，你還不如把憑證在那裏）。
出於這個原因，股票設計會話控制器和令牌認證機制是不充分的，以及如何提供延伸設計替代方案中，REST-FUL或基於JSON的認證，因此許多實例。
實際上，在最近的兩篇文章中，作者只是通過devise＆token_authenticatable模塊給出了關於構建API的更多解釋。事實上，使用桌面和移動客戶端的令牌認證沒有區別 – railscard