Google認証だけ実装したら「ログインできない」と言われた!アプリ内ブラウザのOAuthブロック問題と対策まとめ

目次

「ログインできないんですが…」個人開発でやりがちな落とし穴

個人開発でWebアプリを作り、ログイン機能に Google 認証だけを実装した。設定も完了、動作確認もバッチリ。いざ X(Twitter)でシェアして広めてみたら……

「ログインできないんですが?」

実はこれ、個人開発者がやりがちな落とし穴です。X・LINE・Instagram などのアプリ内ブラウザから Google OAuth を使おうとすると、Google のポリシーによってブロックされてしまいます。

X からの流入がメインの個人開発アプリにとってはほぼ致命的な問題です。7万インプレッションを超えた X の投稿でも話題になっていたこの問題、仕組みと対策をまとめます。

なぜアプリ内ブラウザでGoogle OAuthがブロックされるのか

X や LINE でリンクをタップすると、多くの場合はアプリ内部に組み込まれたブラウザ(WebView)でページが開きます。このWebView 上で Google の OAuth 認証を試みると、以下のようなエラーが表示されてログインに進めません。

これは Google が意図的にブロックしています。理由はセキュリティです。

WebView はアプリが完全にコントロールできる組み込みブラウザです。悪意のあるアプリが WebView を使えば、ユーザーが Google アカウントに入力したメールアドレスやパスワードをアプリ側で傍受・盗み取ることが技術的に可能です。これを防ぐため、Google は 2021 年ごろから WebView 上での OAuth 認証を段階的にブロックするようになりました。

公式ドキュメントでも「埋め込みブラウザフレームワーク(WebView)での OAuth は非推奨」と明記されています。

なぜたまに通るアプリがあるのか

「でも、たまに X アプリ内からログインできるサービスもあるよ?」という疑問を持つ方もいるはずです。これには理由があります。

Chrome Custom Tabs(Android)

Android アプリが通常の WebView ではなく Chrome Custom Tabs を使ってリンクを開いている場合、Google の OAuth が通過できます。Chrome Custom Tabs はアプリに組み込まれていますが、実態は Chrome ブラウザそのものであり、アプリがコンテンツを傍受できない設計になっています。

SafariViewController(iOS)

iOS アプリが SafariViewController を使ってリンクを開いている場合も同様です。Safari のエンジンを使いつつ、アプリからは通信内容にアクセスできないため、Google に安全と判断されます。

つまり「アプリ内ブラウザでもログインできるケース」は、そのアプリが WebView ではなく安全な実装を選んでいるケース。自分のWebアプリ側では制御できない部分です。

対策①:URLパラメータで外部ブラウザを開かせる

根本的な解決策として、アプリ内ブラウザではなく外部ブラウザ(Safari や Chrome)でリンクを開かせる方法があります。各プラットフォームで使えるパラメータが用意されています。

LINEの場合:openExternalBrowser=1

LINE でシェアする URL に openExternalBrowser=1 パラメータを付けると、LINE アプリ内ブラウザではなく外部ブラウザで開かれます。

# 通常のURL
https://your-app.com/login

# LINE用:外部ブラウザで開かせるURL
https://your-app.com/login?openExternalBrowser=1

LINE でシェアするリンクにこのパラメータを付けておくだけで、LINE ユーザーへの対応ができます。

X(Twitter)の場合

X アプリ内ブラウザを外部ブラウザに誘導する公式パラメータは現時点では存在しません。後述の「警告表示」での対応が現実的です。

対策②:User-Agentを検出して警告を表示する

すべてのアプリ内ブラウザを外部に誘導するパラメータは存在しないため、User-Agent を見てアプリ内ブラウザからのアクセスを検出し、外部ブラウザで開くよう促す警告を表示する方法が現実的な落としどころです。

X でも話題になったこの問題への対応として、多くの開発者がこの方法を採用しています。

実装例(JavaScript)

// アプリ内ブラウザの検出
function isInAppBrowser() {
  const ua = navigator.userAgent;
  return (
    // LINE
    /Line\//.test(ua) ||
    // X(Twitter)
    /Twitter\//.test(ua) ||
    // Instagram
    /Instagram/.test(ua) ||
    // Facebook
    /FBAN|FBAV/.test(ua) ||
    // TikTok
    /musical_ly/.test(ua)
  );
}

// ログインボタンのクリック時に判定
document.getElementById('login-btn').addEventListener('click', (e) => {
  if (isInAppBrowser()) {
    e.preventDefault();
    document.getElementById('inapp-warning').style.display = 'block';
  }
});

警告メッセージの表示例(HTML)

警告文はできるだけ具体的に「右上のメニューから〜」と操作手順を示すと、ユーザーが迷わずに済みます。ただし User-Agent は偽装可能なため、これは完全な解決策ではなくあくまでユーザーへのガイドとして機能させるものです。

対策③:Google以外の認証手段を追加する

根本的な解決策として、Google 認証に依存しない認証手段を追加する方法もあります。

メールアドレス+パスワード認証

最もシンプルな追加手段です。アプリ内ブラウザでも問題なく動作します。Firebase Authentication や Auth.js(NextAuth)を使えば、Google 認証と並行して比較的簡単に追加できます。

マジックリンク(メール認証)

パスワードなしでメールアドレスだけで認証できるマジックリンク方式も有効です。ユーザーがメールアドレスを入力するとログインリンクが届き、そのリンクをタップするだけでログインできます。アプリ内ブラウザの制約を受けません。

認証方式の組み合わせ戦略

認証方式 アプリ内ブラウザ 実装コスト UX
Google OAuth ❌ ブロックされる ◎ ワンタップ
メール+パスワード ✅ 問題なし ○ 入力が必要
マジックリンク ✅ 問題なし ◎ パスワード不要
GitHub OAuth △ 環境による ○ 開発者向け

X からの流入がメインのアプリであれば、Google 認証 + メール認証(またはマジックリンク) の組み合わせが現実的な選択肢です。ユーザーが状況に応じて選べるようにしておくことで、ログインできない問題を大幅に減らせます。

まとめ:個人開発のOAuth設計で最初から考えておくべきこと

今回の問題をまとめます。

  • X・LINE・Instagram などのアプリ内ブラウザ(WebView)では、Google OAuth がセキュリティポリシーによりブロックされる
  • Chrome Custom Tabs(Android)や SafariViewController(iOS)を使うアプリは例外的に通過できる
  • LINE へのシェアには openExternalBrowser=1 パラメータが有効
  • X からの流入には User-Agent 検出 + 外部ブラウザへの誘導メッセージ が現実的な対応
  • 根本解決には Google 認証以外の認証手段を追加 することが重要

「Google 認証だけ用意すれば十分」は個人開発でよくある思い込みです。特に SNS でシェアして広めることを想定しているなら、最初から複数の認証手段を用意しておくか、アプリ内ブラウザ対応を設計に組み込んでおくことをおすすめします。

個人開発をさらに磨く関連記事

認証まわりを整えたら、個人開発の品質・セキュリティ・運用もあわせて強化しましょう:

セキュリティ・認証まわり

個人開発の立ち上げ・運用

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次