本当はいろいろ突っついて調べてみるのが良いんだと思うけど、もはや外部連携はできないのと、最近の「犯罪じゃないはずの行為で警察が来る」問題が楽観視できないので、一般論の範疇で。
まず、ここで書かれていることをどこまで本当と考えてよいのかがわからないんだけど、仮にこのとおりだとしたら、「ナンバーキーで施錠してます。ボタン？１個だけですよ？」ってレベルのセキュリティー（つまり、０と等価である）であり、脆弱性診断もクソもないはずなので、流石に信じがたい。信じがたいことをやってのけた実績があるので信じたほうが良いのかもしれないけど。
とりあえず、本当だと仮定して話を進めますが、とはいえ、ソーシャルログインって何やってるの、を正確に理解している人はそんなに居ないと思うんですよね。僕もちょっと細かいところには自信ない。
今回はomni7の既存のIDに対してソーシャルログインで紐付けをしたIDがある、という前提だと思うんですが（じゃないと攻撃にならない）
この｢id｣という項目に注目。モザイクを入れた部分は数字の文字列がある。この文字列には、外部ID事業者とのOAuth認証時に得られる｢ユーザー毎に一意なユーザーID｣を単純に利用していた。
つまり、このidとomni7のIDを紐付けている、ということ。と、ここで、ん？と思う。そもそも、このリクエストを投げるAPIってなんなのか。ソーシャルログインの成功後のリダイレクト先ってことかな？でもこのidって値、誰が設定するんだ？
普通は
ソーシャルログイン完了
→アクセストークン付きのレスポンスをブラウザに返すのでブラウザがサーバーにリダイレクト
→サーバーからそのアクセストークンを使って認証プロバイダ（ソーシャルログイン先）に問い合わせ
→その結果のユーザー情報を元にこっち側で確認し、ユーザーと紐付いたAPIトークンを発行して返す
じゃないのかな？loginExternalAppMe...とは一体…
ともあれ、このような標準的なフローを使わず、謎認証を実装しているように見えるので、相当なアレなんじゃないかと思えますが、実際のところどうなんでしょうか…
そもそも今回の件って、本来、フロントエンド側のアプリサーバーとして7Payのサーバーがいて、それとomni7のサーバーが連携するはずのところを7Payのアプリから直接叩いているのでは？と思い始めてきたんですが（これは今でも確認しようと思えばできるかな？）、実は外部ID連携自体は7Pay側ではちゃんと実装されていたりして…。トークンもパスワードも無しにID送ったらトークン返ってくるって、公開されるAPIを想定している実装には見えないですよね。
