1

オンラインで見つけたいくつかの例に基づいて、Asp.net Core REST サービス用の JWT ミドルウェアをいくつか作成しました。応答は次のようになります。

{
   "access_token":"...",
   "expires_in":3600,
   "refresh_token":"???",
   "token_type": "Bearer",
}

access_token の作成方法を理解しました:

Claim[] claims = new Claim[]
{
    new Claim(JwtRegisteredClaimNames.Sub, strUsername),
    new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
    new Claim(JwtRegisteredClaimNames.Iat, dtNow.ToUnixTimeSeconds().ToString(), ClaimValueTypes.Integer64)
};

JwtSecurityToken jwtAccess = new JwtSecurityToken(_options.Issuer, _options.Audience, claims, dtNow.DateTime,
                                                  dtNow.DateTime.Add(_options.AccessTokenExpiration), _options.SigningCredentials);

問題は、refresh_token をどのように作成するかです。高低を検索しましたが、それに関する多くのドキュメントが見つかりません。基本的に、すべてのリファレンスは、「新しい access_token を作成できる、より長い TTL を持つデータベースに保存されたトークン」と言っています。

では、refresh_token は access_token とまったく同じもので、TTL が長く、データベースに対して検証される追加の手順があるだけですか?

私が見た JWT 応答の例のいくつかは、refresh_token がはるかに短いように見えます。私の access_token は RSA515 を使用した証明書で署名されているため、文字列はちょっと長いです...

4

1 に答える 1

1

個人的には、私のリフレッシュ トークンは、TTL が長く、リソース所有者を確認するのに役立つ情報が少し多い JWT です。

Auth0 の次の記事を見てください。リンクがサポートされています

https://auth0.com/docs/tokens/refresh_token

ユーザー/クライアントをトークンにマップするために使用される単純な GUID であり、有効期限もトークンと共にデータベースに格納されます。

次の例は、更新トークンに Guid のように見えるものを使用する上記のリンクからのものです。

したがって、たとえば、パスワード「test」を持つユーザー「test」とクライアント シークレット「secret」を持つクライアント「testclient」があると仮定すると、次のように新しいアクセス トークン/リフレッシュ トークンのペアを要求できます。

$ curl -X POST -H 'Authorization: Basic dGVzdGNsaWVudDpzZWNyZXQ=' -d 'grant_type=password&username=test&password=test' localhost:3000/oauth/token

{
    "token_type":"bearer",
    "access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiVlx1MDAxNcKbwoNUwoonbFPCu8KhwrYiLCJpYXQiOjE0NDQyNjI1NDMsImV4cCI6MTQ0NDI2MjU2M30.MldruS1PvZaRZIJR4legQaauQ3_DYKxxP2rFnD37Ip4",
    "expires_in":20,
    "refresh_token":"fdb8fdbecf1d03ce5e6125c067733c0d51de209c"
}

トークンの有効期限が切れると、更新トークンを渡して呼び出しを行い、新しいアクセス トークンを取得します。

これで、次のようにトークン エンドポイントをヒットすることで、更新トークンを使用して新しいアクセス トークンを取得できます。

curl -X POST -H 'Authorization: Basic dGVzdGNsaWVudDpzZWNyZXQ=' -d 'refresh_token=fdb8fdbecf1d03ce5e6125c067733c0d51de209c&grant_type=refresh_token' localhost:3000/oauth/token

{
    "token_type":"bearer",
    "access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiVlx1MDAxNcKbwoNUwoonbFPCu8KhwrYiLCJpYXQiOjE0NDQyNjI4NjYsImV4cCI6MTQ0NDI2Mjg4Nn0.Dww7TC-d0teDAgsmKHw7bhF2THNichsE6rVJq9xu_2s",
    "expires_in":20,
    "refresh_token":"7fd15938c823cf58e78019bea2af142f9449696a"
}

セキュリティに関する考慮事項

リフレッシュ トークンは長期間有効です。これは、クライアントがサーバーからトークンを取得するときに、潜在的な攻撃者に使用されないように、このトークンを安全に保存する必要があることを意味します。このため、トークンをブラウザーに保存するのは安全ではありません。リフレッシュ トークンが漏洩すると、ブラックリストに登録されるか期限切れになるまで (長い時間がかかる場合があります)、新しいアクセス トークンを取得する (および保護されたリソースにアクセスする) ために使用される可能性があります。更新トークンは、漏洩したトークンが他の関係者によって使用されるのを防ぐために、単一の認証済みクライアントに発行する必要があります。アクセストークンも秘密にしておく必要がありますが、寿命が短いため、セキュリティの考慮事項はそれほど重要ではありません.

于 2016-09-16T03:59:09.540 に答える