トークンベースの認証について読み、一般IDを取得します。私が理解していないのは、フロントエンド（私の場合は残り火）で、すべての通信があなた自身の安らかなAPIバックエンド（私の場合はレール）と行われる場合、なぜそのようなトークンが必要になるのかということです。自分のバックエンドと厳密に通信し、そのバックエンドに認証を残す場合、なぜemberアプリにトークンが必要なのですか？
バックエンドがプロキシとして機能することもありますが、それは悪いことですか？可能であれば、残り火アプリから直接行う方が良いですか？私は（主に）Twitterに質問をします。
あなたのアイデアを共有してくれてありがとう。
私はこのトピックに少し慣れていませんが、あなたの質問も少し不明確です。oAuth システムで使用されるコンシューマ キー トークンを意味する場合、これらは、API を使用するサードパーティが実際にそれを使用するためのアクセスを許可されていることを確認するために必要です。コンシューマ キーを持たない人は API を使用できません。
または、認証トークンを使用して認証されているユーザーについて言及している場合... 認証を行う Rails アプリを作成すると (たとえば、devise gem を使用して)、セッション コントローラーも作成/使用されます。セッション（/Cookie）は基本的に、ユーザーがログインしたことを「記憶」する方法です。これにより、ユーザーがそのアクションに対して認証するために実行するすべてのアクションでユーザー名/パスワードを再送信する必要がなくなります。
すべてのブラウザーが Cookie をサポートしているため、このアプローチは Web アプリに関しては問題なく機能します。しかし、モバイルアプリに関してはそうではありません。ネイティブ アプリを使用しているときにセッション/Cookie を保持することはできません (技術的には可能ですが、私が読んだ限りでは、正しく動作させるにはかなりの手作業とコードの魔法が必要なようです) ）。
ここで、アプリの API を作成するときは、その API がモバイル アプリの作成に使用される可能性があることに注意する必要があります (将来、または公開する場合)。これは、セッションを使用することはおそらく良い考えではないことを意味します。認証が必要なリクエストごとに、リクエストされたアクションを実行するためのアクセス権がユーザーにあることを確認するために、ユーザー名/パスワードを送信する必要があります。ただし、リクエストごとにユーザー名/パスワードを送信することは、間違いなく悪い考えです。そこでトークン認証の出番です。devise を使用したことがある場合は、トークン認証を有効にするオプションがあることに気付くでしょう。これにより、基本的に、サードパーティがユーザー名/パスワードではなくトークンを送信できるようになり、まったく同じように機能します。
（私はこのトピックにかなり慣れていません。これまでに収集したものからすると、それがどのように機能するかのようです。説明/理解に間違いがあった場合は、人々が正しい私に飛び込んでくれることを願っています。）