元に翻訳・加筆したものです。詳しくは元記事をご覧ください。エクスペリエンスを改善し、サーバーの認証と認可がより簡単になりました。シンプルで、エラーも発生しにくいとの声が寄せられています。使われており、認証と認可のベストプラクティスに従っていないことがわかりました。ベストプラクティスに従わないと、アプリは攻撃に対して簡単に脆弱になってしまう可能性があります。認証を使うと認証ライフサイクル全体を管理することができます。アプリを確実に保護するデベロッパーは、自分のアプリに以下の脆弱性がないかを確認する必要があります。サーバーに送信するアプリがあります。推測してリクエストを偽造し、ユーザーのアカウントに簡単にアクセスできてしまいます。使ってこのアンチパターンを実装しています。サーバーにアイデンティティアサーションとして送信します。サーバーはトークンが自身に対して発行されたかどうかを簡単には確認できません。トークンを使ってバックエンドへのリクエストを偽造することができてしまいます。トークンを取得してこれをサーバーに送信して認証を行っています。G+(www.googleapis.com/plus/v1/people/me)エンドポイントを呼び出しています。フロー(このブログ記事で説明)を実装する必要があります。移行ガイドを確認して、安全で効率的なパターンに移行してください。サービスへのアクセスが必要な場合、サーバー認証コードフローを使用する必要があります。このブログ記事も参考になります。トークンも取得できます。移行ガイドを参照してください。使っているアプリが多く存在します。エクスペリエンスを使う機会を失い、一方デベロッパーは、複雑な実装をメンテナンスし続ける必要があります。パーミッションをリクエストし、独自のピッカーにすべてのメールアドレスを表示します。エクスペリエンスが表示されます。以降では、このパーミッションは「連絡先」としてユーザーに表示されます。多くのユーザーは、この実行時パーミッションにアクセス権を与えたくありません。インターフェースにすることで、合理的にユーザーとの同意形成を実現し、アプリにユーザーの名前、メールアドレス、およびプロフィール画像を取得できるようになります。認可を受け取り、ユーザーは他のデバイスに簡単にサインインできるようになります。トークンを取得する方法が推奨されていました。エクスペリエンスの原因となります。ユーザーのプロファイル情報は、サーバーに保存する貴重な情報です。トークンにはプロファイル情報が含まれ、サーバーではこれらの取得するための追加のネットワーク呼び出しが不要となります。エクスペリエンスを実現します。詳細については、このブログ記事と移行ガイドも参考になります。ストリング」を介してサーバー認証コードを取得することを推奨していました。エクスペリエンスの可能性があるのに加え、ユーザーが過去アプリにサインインしたことがある場合に新しいデバイスに切り替えると、次のような紛らわしいダイアログが表示されるという問題があります。使用しているサーバー認証コードフローに切り替える必要があります。以前サインインしたユーザーに対しては、ダイアログを表示せずに認証コードが発行されます。詳細については、このブログ記事と移行ガイドも参考になります。使うべきではありません。呼び出しを行っている場合を除きます。