Somethingこの広告は、90日以上更新していないブログに表示しています。自社アプリのような信頼できるモバイルアプリケーションからAPIを利用したいモバイルアプリからAPIを利用する際のセキュリティ脆弱性は必ず排除する必要がある。前提APIは既に存在し自社webアプリケーションから利用されている。credentials認証フローを採用している。APIAPIリクエスト時には、アクセストークンを必須としている。アクセストークン未発行の場合アクセストークンの発行を行う必要がある。第3者へのAPI公開はまだ考えていないため、サードパーティーアプリからの認証は考えなくて良い。API認証フローとして今回の要件をみたす形で利用できる判断し実装した。組み合わせが有効だった場合、有効なリクエストだと判断しアクセストークンを発行する。passwordを入力する。このusernameとpasswordはアプリケーションのユーザログイン時に使うものと同じ。それをもとにモバイルアプリがAPIトークン発行リクエストをAPIへ送信する。組み合わせをDBと照合し、正しければアクセストークンを発行する。以後そのアクセストークンでモバイルアプリはAPIリクエストを送信する。ユーザによるリソースへのアクセス制限モバイルアプリからリクエストパラメータを改ざんして送信されることは起こり得る。ユーザ情報変更APIをモバイルアプリから利用するとする。ユーザIDによるリソースのアクセス制限を設定してない場合のリクエストパラメータを他人のIDに書き換えてリクエストを送信されると他人のリソースが変更できてしまうという重大な脆弱性になる。ユーザIDを発行したアクセストークンと紐付けて保存する個人情報を扱うAPIリソースへのアクセス時には、そのアクセストークンを発行したユーザIDとAPIで参照しようとしているユーザIDが一致しているかチェックする。一致している場合はアクセスを許可、一致していない場合はアクセスを拒否しエラーを返す。passwordを知る必要がある。ログイン情報を知っても問題ないアプリケーションから利用する場合に限られる。自社製アプリなど信頼できるアプリケーションにこの認証フローは使えない。