نوشته‌شده در

کلیدهای API را با JWT تولید کنید و در صورت لزوم همان کلید را بازسازی کنید

من اخیراً احساس نیاز خودم را برای ایجاد یک API عمومی برای برنامه خود پیدا کردم. برنامه خود را با node.js و MongoDB توسعه دادم. پس از انجام تحقیقات ، تصمیم گرفتم از jwt برای تولید کلیدهای API برای کاربران و تأیید اعتبار استفاده کنم. برای تأیید اعتبار نشانه های jwt ، آنها به این مزیت احتیاج دارند که نیازی به ذخیره آنها در یک بانک اطلاعاتی ندارند ، زیرا بدون اطلاع از نشانه دقیق تولید شده می توانند رمزگشایی و تأیید شوند.

اما من می بینم که بسیاری از برنامه ها کلیدهای API خود را در داشبورد برنامه نشان داده و به کاربران نشان دهید ، بنابراین باید این نشانه را ذخیره کنم تا بعداً آنها را به کاربران نشان دهد. من می دانم که ذخیره کردن نشانه ها ایده بدی است و در صورت نقض بانک اطلاعاتی ، این امر می تواند هکرها را با کلیدهای API جعل هویت دیگران کند.

بنابراین داستان کوتاه طولانی من در تلاش هستم راهی پیدا کنم تا نشانه های دقیق را ذخیره نکنم. ، اما فقط بار خود را در دیتابیس ذخیره کنید و هر بار که کاربران کلیدهای API خود را درخواست می کنند ، من فقط یکی را با [SECRET SECRET تولید می کنم و آن را به آنها منتقل می کنم. در حال حاضر می فهمم که اگر در مرحله توافق نامه ، هر بار که می خواهم بار مشابهی را با همان iat (صادر شده در) صادر کنم ، متن تولید شده هر بار یکسان خواهد بود. بنابراین با ذخیره کردن iat با داده بارگذاری در دیتابیس می توانم هر بار توکن دقیق تولید کنم.

اکنون سوالات من این است:

  • آیا این رویکرد خوب است یا روش بهتری وجود دارد؟
  • آیا هیچ روش خوبی برای تولید کلیدهای API بدون ذخیره آنها وجود دارد؟
  • آیا این حتی لازم است (با توجه به اینکه آیا ساحل بانک اطلاعاتی وجود دارد ، همه داده ها از قبل دزدیده شده اند)؟
  • آیا روش دیگری غیر از استفاده از jwt برای رسیدن به این هدف وجود دارد؟

نوشته‌شده در

الگوریتم های نامتقارن توصیه شده برای JWT

من تأیید JWT را برای یک سرویس وب جدید اجرا میکنم و مطمئن نیستم که کدام الگوریتم نامتقارن را انتخاب کند. من در اطراف جستجو کرده ام و هیچ توصیه و یا روشنی را پیدا نکرده ام. با توجه به اسناد PyJWT: https://pyjwt.readthedocs.io/en/latest/algorithms.html چند الگوریتم متفاوت برای انتخاب وجود دارد.

من می خواهم از یک الگوریتم که امن (البته) ، سربار کم است و اثبات آینده است. کدام الگوریتم متناسب با لایحه است؟

نوشته‌شده در

jwt – چگونه مجوز پس از احراز هویت با استفاده از شناسه open شناسایی می شود

فرض کنید که یک مشتری یک شناسه شناسایی می کند و از یک سرور Auth به عنوان یک نتیجه از تأیید صحت موفق استفاده می کند. مشتری اکنون درخواستی را به سرور برنامه می فرستد. (درخواست شامل برچسب دسترسی و شناسه) است. به نظر من، سرور برنامه در حال حاضر برای تماس با سرور auth برای تأیید این نشانه ها. اگر پرونده ها معتبر باشند، سرور برنامه با درخواست ادامه می یابد. در غیر این صورت، درخواست را رد می کند. آیا این درست است؟

مسئله اصلی من با این تنظیم نیاز به تماس با سرور auth برای هر درخواست است. آیا روش استاندارد برای جلوگیری از این وجود دارد؟ نحوه استفاده از یک کلید مخفی (شناخته شده به هر دو سرور Auth و سرور برنامه) برای تأیید امضا – شبیه به JWT. در این مورد تفاوت بین openID اتصال + OAuth2 و JWT چیست؟

نوشته‌شده در

jwt – چطور Apple Token موزیک امن است؟

محیط زیست:

  • زبان: پایتون
  • چارچوب: جانگو
  • پایگاه داده: Postgres

TL؛ DR
برنامه ما نیاز به انجام عملیات پس زمینه است که نیاز به نشانه اپل موسیقی. پس از آنکه کاربر برنامه را مجاز به دسترسی به حساب کاربری خود کردم، یک اکانت از اپل دریافت کردم. چگونه می توانم آن را به صورت امن در پایگاه داده خود ذخیره کنم؟ آیا باید آن را رمزگذاری کنم؟

برنامه در حال حاضر با استفاده از این نشانه زمانی که کاربر یک عمل را آغاز می کند اما آن را پرتاب می کند. من می خواهم راهی برای ذخیره آن در پایگاه داده را به طور ایمن.

نحوه دریافت Token

این صفحه در فایل های Apple Music API کمیاب است، اما خلاصه ای در مورد نحوه ایجاد Token می دهد /abtained.

به نظر می رسد که برای هر درخواستی که باید با داده های کاربر انجام شود، ما باید دو نشانه را ارسال کنیم: نشانگر توسعه دهنده (JWT تولید شده) و نشانگر کاربر (که فقط یک رشته طولانی است). [19659010] curl -v -H 'Music-User Token: [music user token]' -H 'اجازهنامه: Bearer [developer token]' 'https://api.music.apple.com/v1/catalog/us/songs/203709340 "

نشانه کاربر اعطا شده است که کاربر اجازه برنامه خاص به خواندن / تغییر خود کتابخانه Apple موسیقی

کد کاربر به عنوان مثال:

ApSbGT6HcRA + ABZ + b88ZNu / TQJg + MRjcEJwkA3qz8zamj3z7POEGvsDrihYVn8XqLZmQvbSQaMmsgpjjnxv0MTBpqHNFFQiuzxBjVUGgS … [turncated]

من سؤال این است: آیا فقط میتوان به عنوان یک StringField در پایگاه داده ذخیره کرد، آیا میتوان آن را تنها با نشانگر توسعه دهنده مورد استفاده قرار داد؟ یا باید آن را رمزگذاری کنم؟

نوشته‌شده در

تأیید اعتبار – آیا این یک پیاده سازی امن از نشانه های تجدید JWT است؟

من یک نشانه ی بازخوانی JWT را اجرا میکنم و روش زیر را برای تشویق نشانه ها توسعه داده ام. زیر برنامه جریان است:

  • هنگامی که سرور اطلاعات ورود را بازیابی می کند، آن را در برابر رمز عبور بررسی می کند
    پایگاه داده و ایجاد Token JWT با یک نشانه تازه کردن به عنوان یکی از آن
    ادعا می کند در محموله. (کاراکترهای تصادفی). این تازه سازی را ذخیره خواهد کرد
    نشانه در یک پایگاه داده.
  • پس از ورود، سرور ورود به سیستم: true و Token access JWT
  • از آنجا که نشانگر refresh در داخل JWT است، دو نشانه لازم نیست
    فرستاده می شود
  • اگر مشتری یک نشانه دسترسی را که تمام شده است، ارسال می کند، سرور خواهد شد
    کد زیر را در ادعا بررسی کنید و ببینید آیا در داخل db است.
    اگر این کار را کرد، یک نشانه جدید با یک نشانه تازه کردن ایجاد خواهد کرد و
  • اگر مشتری بخواهد از همه دستگاه ها بیرون برود، می توانند به راحتی تمام آنها را لغو کنند
    از نشانه های بازخوانی آنها و زمانی که همه آنها بیرون می آیند
    نشانه ها منقضی می شوند (نشانه های 15 دقیقه JWT).

مزایایی که می توانم در این پیاده سازی ببینم عبارتند از:

  • بدون نیاز به ارسال دو نشانه. تازه سازی در داخل JWT جاسازی شده است
    و نمی تواند اصلاح شود زیرا امضای آن نامعتبر است.
  • بدون نیاز به رمز نویسی مجدد در پایگاه داده را رمزگذاری می کند، زیرا اگر یک
    مهاجم نشانه ی refresh را نگه داشته است، آنها نمی توانند کاری انجام دهند
    با آن به دلیل آن است که در داخل JWT است و نمی تواند اصلاح شود. (که در
    پیاده سازی های دیگر با نشانه های جداگانه باید فرض کنیم
    مهاجم به هر حال هر دو را می گیرد)

مشکلاتی که من با آنها می بینم عبارتند از:

  • JWT ها همیشه دارای نشانگر refresh هستند، بنابراین مهاجم همیشه باید باشد
    قادر به انجام یک تازه کردن و استفاده از نشانه refresh تا زمانی که منقضی شود
    مگر اینکه مشتری آن را با ورود به سیستم (از تمام دستگاه ها) لغو می کند.
  • مشتری می تواند تماس ورود به سیستم را در حلقه اجرا کند و پایگاه داده را پر کند
    زیرا هر بار که آنها وارد سیستم می شوند، یک نشانه دسترسی جدید ایجاد می شود و یک
    کد جدید refresh در پایگاه داده ذخیره می شود.

آیا این روش امن است؟ اگر چنین است، من عمدتا با کسی که با پایگاه داده های جدید refresh و پر کردن دیسک پر می کند، نگرانم. چگونه می توانم از وقوع اجتناب کنم؟