1
APIコンシューマーは、特定のAPIポータルでAPIにサブスクライブします。 彼はクライアントIDと臨床検査の秘密を受け取ります。 サブスクリプションに特定のクォータセットがあります。OAuth2ネイティブアプリ - クライアントの秘密
[ハッピーデイシナリオ]
- 彼はその後、Webアプリケーションを作成することを決定し、サーバ上で安全にクライアントシークレットを配置します。
- 彼はAuthコードの許可を得ようと決めます。
- auth_codeを受け取った後にacces_tokenを取得するための呼び出しは、クライアントシークレットを使用したサーバー間要求です。
- したがって、目的は安全に保存され、使用されるclient_secretで解決されます。彼は以前に加入し、同じAPIを使用しています -
[未幸せな一日のシナリオ]
- その後、彼はネイティブアプリ（アンドロイド/ iOSアプリパブリッククライアント）を作成することを決定します。
- ネイティブアプリがAPIにアクセスするには、access_tokenが必要です。
- ユーザーはIDサーバーに対して認証し、許可を提供します。
- auth_codeを受信し、アプリにリダイレクトされます。
- これで、このauth_code +クライアントID + client_secretがaccess_tokenを取得する必要があります。
- この場合、client_secretは安全に保存されません。アプリをデコンパイルすることができ、APIの購入/ APIの購読を犠牲にして、client_secretを誤用する可能性があります。
暗黙のフローオプションが除外されています。
可能な回避策：
- のclient_idとclient_secretが格納されており、ネイティブアプリがアクセストークンを得るためにauth_codeでこのプロキシを呼び出すプロキシを作成します。
- client_secretを暗号化してください。 アドバイスが必要です。