3

OAuth2 トークン交換の最後には、[通常] ユーザー データの JSON 配列が残ります。これは、必要なフィールドを含む構造体 (GoogleUser など) に非整列化されています。

そのデータをDBに記録する賢明な方法は何ですか? CreateUserユーザーがDBにまだ存在しないことを確認した後、コールバックハンドラーから関数を呼び出し、構造体を渡して保存するだけです(私には明らかな方法です)。

次に、コールバック ハンドラーでセッション トークン (つまり ) を作成し、それを(妥当な有効期限で) Cookie に保存し、ログイン ユーザーを期待するハンドラー関数をsession.Values["authenticated"] == trueチェックするだけでよいと思いますか? if authenticated == trueまたは、管理ハンドラーの場合: if admin_user == true. 私がHTTPS 経由で話し、安全な Cookie を使用していると仮定すると、ここにどのようなリスクがありますか (もしあれば) 。

基本的な質問に対するお詫び: OAuth を使用してユーザーをログインさせる「ベスト プラクティス」の方法を把握しようとしているだけです。

4

2 に答える 2

1

標準では有効期限がありAccess Tokenます。OAuth通常、認可サーバーによって決定されます。あなたの場合、認可サーバー側にいると思います。

たとえば、RFC 6750を読んでください。

通常、ベアラー トークンは、OAuth 2.0 [RFC6749] アクセス トークン応答の一部としてクライアントに返されます。このような応答の例は次のとおりです。

 HTTP/1.1 200 OK
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache

 {
   "access_token":"mF_9.B5f-4.1JqM",
   "token_type":"Bearer",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
 }

RFC 6749の概念も参照Access Tokenしてください。

アクセス トークンは抽象化レイヤーを提供し、さまざまな承認構造 (ユーザー名とパスワードなど) を、リソース サーバーが理解する単一のトークンに置き換えます。この抽象化により、アクセス トークンを取得するために使用される承認付与よりも制限的なアクセス トークンを発行できるようになり、リソース サーバーがさまざまな認証方法を理解する必要がなくなります。

したがって、あなたの場合、「Cookie」または「管理ハンドラー」は必要ないと思います。仕様にあるように、ログインしているユーザーごとにAccess Token&を生成し、その有効期限も保存するだけです。合法的な要求であることを確認するために、関連するハッシュ メソッドを提供することもできます。たとえば、ユーザーはアクセストークンを使用してハッシュとソルト方式で署名を生成し、アクセストークンと署名をサーバーに送信して検証します。詳細については、公開鍵暗号化を参照してください。Refresh TokenOAuthAccess Token

さらに、これらのトークンはすべて一時的なリソースであるため、DB に保存する必要はありません。また、すべてのユーザー情報をメモリに保存し、キャッシュ レイヤーを実装してこれらの情報を DB に定期的に保存し (現在使用しています)、DB の負荷を下げることもできます。

于 2013-05-21T03:45:39.700 に答える
1

最初の質問に関しては、通常、単一のトランザクションでチェックと挿入を行うことをお勧めします。使用している DB によって異なりますが、これらは通常UPSERTステートメントと呼ばれます。PLSQL では、次のようになります (好みに合わせて変更してください)。

CREATE FUNCTION upsert_user(emailv character varying, saltv character varying, hashv character varying, date_createdv timestamp without time zone) RETURNS void
    LANGUAGE plpgsql
AS $$;
BEGIN
    LOOP
        -- first try to update the key
        UPDATE users SET (salt, hash) = (saltv, hashv) WHERE email = emailv;
        IF found THEN
            RETURN;
        END IF;
        -- not there, so try to insert the key
        -- if someone else inserts the same key concurrently,
        -- we could get a unique-key failure
        BEGIN
            INSERT INTO users(email, salt, hash, date_created) VALUES (emailv, saltv, hashv, date_createdv);
            RETURN;
        EXCEPTION WHEN unique_violation THEN
            -- do nothing, and loop to try the UPDATE again
        END;
    END LOOP;
END;
$$;

2 番目の質問に関しては、通常 Secureは HTTPS 経由の Cookie で十分です。私はHttpOnlyオプションを設定しますが、通常はPathオプションも設定します。

HttpOnlyは、Cookie が JS (HTTP または HTTPS のみ) によってアクセスできないことを意味し、このPathオプションを使用して、Cookie が有効なパス (URL 内) を指定できます。

于 2013-05-21T14:55:14.443 に答える