安全なRESTful Webサービスを実装する必要があります。私はすでにGoogleを使用していくつかの調査を行いましたが、行き詰まっています。
オプション：
TLS（HTTPS）+
検討すべきオプションは他にありますか？OAuthの場合、どのバージョンですか？それも重要ですか？これまで読んだことから、署名なしのベアラートークンを使用したOAuth 2.0は安全ではないようです。
RESTベースの認証に関する別の非常に興味深い記事を見つけました。
回答:
別の非常に安全な方法があります。これはクライアント証明書です。httpsでサーバーに接続するときに、サーバーがSSL証明書を提示する方法を知っていますか？サーバーはクライアントに証明書を要求できるため、クライアントが本人であることがわかります。クライアントは証明書を生成し、安全なチャネルを介してそれらをあなたに渡します（USBキー-できればトロイの木馬ではないUSBキーでオフィスに入るようなもの）。
証明書クライアント証明書の公開鍵（および必要に応じてその署名者の証明書）をWebサーバーにロードすると、Webサーバーは、証明書に対応する秘密鍵を持っている人以外の誰からの接続も受け入れませんそれは知っています。これはHTTPSレイヤーで実行されるため、OAuthなどのアプリケーションレベルの認証を完全にスキップすることもできます（要件によって異なります）。レイヤーを抽象化してローカル認証局を作成し、クライアントからの証明書リクエストに署名することで、「オフィスに持ち込む」ステップと「サーバーに証明書をロードする」ステップをスキップできます。
首の痛み？もちろんです。すべてに良いですか？いいえ。非常に安全ですか？うん。
ただし、証明書を安全に保つクライアントに依存します（プライベートキーをオンラインで投稿することはできません）。通常、クライアントにサービスを販売するときに、誰かに登録や接続を許可するのではなく、クライアントを使用します。
とにかく、それはあなたが探している解決策ではないかもしれません（それはおそらく正直ではありません）が、それは別のオプションです。
HTTP Basic + HTTPSは一般的な方法の1つです。
OAuthバージョンを選択する場合は、OAuth 2.0を使用してください。
OAuthベアラートークンは、安全なトランスポートでのみ使用する必要があります。
OAuthベアラートークンは、会話を暗号化するトランスポートと同じくらい安全または非安全です。HTTPSはリプレイアタックから保護するため、ベアラートークンがリプレイから保護する必要はありません。
誰かがベアラートークンを傍受した場合、APIを呼び出すときに偽装される可能性があることは事実ですが、そのリスクを軽減する方法はたくさんあります。トークンに長い有効期限を与え、クライアントがトークンをローカルに保存することを期待する場合、トークンに短い有効期限を与え、クライアントにセッションごとに新しいトークンを取得するよう要求する場合よりも、トークンが傍受されて誤用されるリスクが高くなります。トークンを永続化しないようにクライアントにアドバイスします。
HTTPS / SSLはグラフの1つのリンクしか暗号化しないため、複数の参加者を通過するペイロードを保護する必要がある場合は、HTTPS / SSL以外のものが必要です。これはOAuthの障害ではありません。
ベアラートークンは、クライアントが簡単に取得でき、API呼び出しに簡単に使用できます。また、HTTPSで広く使用されており、Google、Facebook、および他の多くのサービスから公開されているAPIを保護します。