2

私はこの権利があることを確認する必要があります。 Actions-SDKを使ってGoogleにアクションを構築する認証については、Googleログインを使用して、エンドユーザーにとってすべてのことを比較的単純にしたいと考えています。私のフルフィルメントはFirebaseの機能の上にあります。私のOAUTHサーバーはFirebaseの外にあります。Googleでのアクション - UIDのログイントークンとスワップアクセストークン

私が注意する最初のことは、フロントエンドのログインの多くがJavaScriptで行われることです。

var provider = new firebase.auth.GoogleAuthProvider();ここから

、ユーザがログインする場合は、私たちが使用することができます。

firebase.auth().getRedirectResult().then(function(result) { }と私たちはここに

私の最初の質問はセキュリティですresult.user.uidへのアクセス権を持っている - API KeyDatabaseURLauthDomain理由クライアントサイドのJavaScriptで公開され、Chromeでデベロッパーコンソールを使用すると、エンドユーザーはIDとトークンにアクセスできます。私は何かの理由でresult.user.Deの下でuidまたはidトークンを使用するかどうか疑問に思っていましたが、インターネット上のJWTデコーダを使用してすべての情報を簡単に抽出して、ここでuidを取るかもしれません。

Node.jsとPHPでデータベースの接続やトークンの検証やユーザーの作成ができるが、ログインできないような管理者側があるようだ。だからJavaScriptはやり方だと思う。

私が集めた次のステップは、oauthサーバーに自分のuidをポストバックして、誰がログインしているのかを知り、oauthアクセストークン/リフレッシュトークン/認証コードをuidに結びつけることです。 FirebaseやOauthサーバのMySQLデータベースにリンクを保存するかどうかは問題ではありません。

はその後Firebase機能で履行のために、我々はその後介して1人のuserIdを持っている:

let ActionsSdkApp = require('actions-on-google').ActionsSdkApp; 
const app = new ActionsSdkApp({request: request, response: response}); 
app.getUser().userId); 

しかし、これは、我々は結果から取得したUIDと一致していません...しかし、我々は、我々は上に生成AccessTokenへのアクセスを持っていますOauthサーバであるため、正しいUIDを得るためにアクセストークンを交換する必要があります.FirebaseやOAuth MySQLサーバを検索するかどうかは関係ありません。

これをまとめて、このフローはすべて正しいと思いますか?それとももっとうまくやれるの?私は、Firebaseの機能でユーザを識別する良い方法があることを期待していました。しかし、それは可能ではないようです。

答えて

2

私はあなたはそれがほとんど正しい(私はすべてに従うと仮定して)持っていると思いますが、注意すべきいくつかのポイント:

  1. あなたはないは、あなたのクライアントからサーバにだけユーザIDを送信する必要があります。

    あなたが気づいたように、その情報は簡単に利用できます。これは、慎重でない限り、誰かがあなたのサーバーに他の場所から取得したUserIDを送信し、あなたのようにふりをすることができることを意味します。

    JWTトークンを使用すると、セキュリティが少し向上します。それにはUserIDが含まれていますが、その情報の署名付きハッシュも含まれているため、情報が有効であることを確認できます。有効期限も含まれているため、有効範囲外の場合は拒否できます。これにより、誰かがUserIDを偽造したり、取得したものを再利用したりするのがずっと難しくなります。

    これらの行には他にも注意が必要です。私たちはブラウザを本当に信頼することはできませんが、問題の機会を絞り込むことができます。

  2. 正しいですが、アシスタントによって送信されたユーザーIDは、他のユーザーIDとはまったく関係ありません。これは匿名のクッキーのような参照として機能することを意図しているので、同じUserIDを2回取得するかどうかを知ることができます。反対側の人物は同じである可能性があります。ほとんどの場合、単純な使用であり、実際の認証ではありません。

  3. 認証と認可を行うには、アカウント接続手順、OAuthサーバー、および認証トークンを渡すことが重要です。あなたはこの部分を正確にしています - トークンが有効であることを確認する必要があります(誰かがアシスタントであると思わない可能性を減らすのに役立ちます)。

    データベース内を検索することもできますが、独自のJWTとしてトークンを発行することもできます。あなたが説明したようなセットアップがあれば、それをある種のデータストアで管理するのが最も理にかなっています。

+0

ありがとうございました!それは私の頭の周りを包むために長い時間がかかりましたが、私はゆっくりとそこに着いています。したがって、user_idを使用する代わりに、私は代わりに、Postを使ってバックエンドのPHPスクリプトにidTokenを渡すことができます。このスクリプトは、JWT検証を行い、生成されたトークンとデコードされたユーザーIDを格納できます。 – Simon

関連する問題