APIがhttp基本認証を使用する方法

APIがクライアントの認証を必要とする場合、2つの異なるシナリオが使用されているのを見て、状況に応じてどのケースを使用すべきか疑問に思っています。

例1.サードパーティがHTTP Basicを使用してトークンとシークレットで認証できるようにするために、会社がAPIを提供しています。

例2. APIは、エンドユーザーを認証するためにHTTP Basicを介してユーザー名とパスワードを受け入れます。通常、彼らは将来のリクエストのためにトークンを受け取ります。

私のセットアップ：モバイルアプリおよびWebアプリのバックエンドとして使用するJSON APIを用意します。モバイルアプリとウェブアプリの両方がトークンとシークレットを一緒に送信することをお勧めするので、これら2つのアプリのみが他のサードパーティをブロックするAPIにアクセスできます。

ただし、モバイルアプリとWebアプリでは、ユーザーがログインして投稿を送信したり、データを表示したりすることができます。したがって、各リクエストでHTTP Basicを介してログインすることもできます。

これらの両方の方法を何らかの方法で組み合わせて使用​​するのですか、それとも各要求でエンドユーザーの資格情報（ユーザー名とトークン）のみを送信するのですか？エンドユーザー資格情報のみを送信する場合、クライアントのCookieに保存しますか？

HTTP基本認証では、すべてのリソース要求でユーザー名とパスワードを送信する必要があります。username：passwordは、「Authorization」リクエストヘッダーに渡され、「Basic」というプレフィックスが付いたbase64エンコード文字列です。すべてのhttp通信が（sslを介して）暗号化されている場合、Authorizationヘッダーの情報は攻撃者が簡単に使用できないはずです。

基本認証を使用したSSL暗号化httpで十分です。

OAuth / OpenIDはトークン/シークレットと共に機能しますか？

私は最近、次のシナリオを考えました：

• Webアプリケーションのフロントエンド
• 基礎となるREST API
• モバイルデバイスアプリケーション、REST APIへのアクセス

簡単なテストとして、次のことができました。

• OAuthを使用してWebアプリケーション経由でユーザーを認証する
• OAuthを介して認証されたREST API。その結果、シークレットが生成され、クライアントに返されます。
• その後、モバイルデバイスはOAuthを介して認証され、その後、秘密を介してREST APIによって承認されます。

これにより、モバイルデバイスアプリケーションは、Webフロントエンド（同じアカウント）経由と同じ資格情報で認証でき、APIへのアクセスを承認することもできます。