AWS API Gateway JWT Authorizer با zitadel

دروازه API AWS در 2-3 سال اخیر ادغام مبتنی بر نقاط پایانی API HTTP را معرفی کرده است و آنها با نقطه پایانی REST API قدیمی متفاوت هستند.

با این AWS همچنین مجوز مبتنی بر مجوز JWT را برای نقاط پایانی معرفی کرد و زندگی را برای همه معماران و توسعه دهندگان که قبلاً مجبور به استفاده از یک مجوز سفارشی بودند آسان کرد.

در این پست وبلاگ که در حال خواندن آن هستید، تمرکز اصلی بر روی آن است AWS API Gateway JWT Authorizer – با Pulumi به عنوان ارائه دهنده IAC و Zitadel برای ارائه دهنده هویت / احراز هویت.

ارجاع به تنظیمات zitadel برای client_credentials در اینجا

پیش نیازها

• حساب AWS.
• دانش متوسط ​​در مورد AWS، AWS API Gateway، AWS Lambda Functions.
• AWS CLI، Pulumi CLI در دستگاه محلی.
• NodeJS 16 در ماشین محلی.
• حساب ابری Zitadel (راه اندازی zitacloud خارج از محدوده این پست وبلاگ است) – برای راه اندازی حساب ابری zitadel به پست وبلاگ دیگر من در اینجا مراجعه کنید
• همچنین می توانید از هر ارائه دهنده هویت دیگری استفاده کنید. (مانند AWS cognito و غیره)
• داشتن دانش JWT عالی است.

نمودار جریان سناریوی مثبت

1. کلاینت رمز دسترسی مورد نیاز نقطه پایانی API را قبل از رسیدن به نقطه پایانی واقعی واکشی می کند.
2. مشتری درخواست را همراه با JWT به عنوان بخشی از یک ارسال می کند مجوز هدر با پیشوند حامل یا می تواند بدون حامل، به دروازه API باشد.
3. دروازه API AWS مجوز را به Autorizer خود مدیریت می‌کند (مطمئن نیستم چطور ممکن است این کار را انجام دهد – آیا می‌تواند به صورت داخلی لامبدا مدیریت شود؟!).
4. jwks را بر اساس ویژگی صادرکننده واکشی می کند و امضای JWT را بر اساس بچه در ورودی JWT تأیید می کند.
5. مجوز داخلی JWT به درستی/موفقیت باز خواهد گشت.
6. دروازه API درخواست اصلی را به تابع AWS lambda ارسال می کند.
7. تابع Lambda به پاسخ پاسخ خواهد داد.
8. پاسخ دریافت شده از تابع lambda به مشتری ارسال می شود.

نمودار جریان سناریوی منفی

1. کلاینت رمز دسترسی مورد نیاز نقطه پایانی API را قبل از رسیدن به نقطه پایانی واقعی واکشی می کند. (یا اگر برای هدف آزمایش از آن صرفنظر کنید)
2. کلاینت توکن نادرست یا خالی یا منقضی شده یا پیکربندی اشتباهی ارسال می کند.
3. دروازه API AWS مجوز را به Autorizer خود مدیریت می‌کند (مطمئن نیستم چطور ممکن است این کار را انجام دهد – آیا می‌تواند به صورت داخلی لامبدا مدیریت شود؟!). فقط در صورتی که سرصفحه وجود داشته باشد تفویض می شود.
4. jwks را بر اساس ویژگی صادرکننده واکشی می کند و امضای JWT را بر اساس بچه در ورودی JWT تأیید می کند.
5. پاسخ دهنده با false پاسخ خواهد داد.
6. دروازه API پاسخ را به عنوان 401 (غیر مجاز) یا 403 (ممنوع) ارسال می کند.

کد و پیکربندی

مخزن کد ارجاع شده از پست قبلی وبلاگ است

• پیکربندی را در فایل های yml پشته تغییر دهید
• دامنه، گواهی، صادرکننده zitacloud و غیره طبق تنظیمات شما

پیوند مخزن اینجاست و شعبه مجوز دهنده است

تنظیمات مربوط به مجوز JWT در فایل موجود است:

config:
  aws:profile: <AWS_PROFILE>
  aws:region: <AWS_REGION>
  non-mtls-apis:API_DOMAIN: <API_DOMAIN>
  non-mtls-apis:API_DOMAIN_MTLS: <MTLS_API_DOMAIN>
  non-mtls-apis:HOSTED_ZONE_NAME: <HOSTED_ZONE>
  non-mtls-apis:JWT:
    audiences:
      - test
      - aws_client
    issuer: https://instance_code.zitadel.cloud/
  non-mtls-apis:SUB_DOMAIN: <SUB_DOMAIN>
  non-mtls-apis:SUB_DOMAIN_MTLS: mtls.<SUB_DOMAIN>

طبق تنظیمات، تغییراتی در مخاطبان و صادرکننده ایجاد کنید.

• مخاطبان بخشی از توکن دسترسی JWT خواهد بود aud مطالبه.
• صادر کننده همچنین بخشی از JWT به عنوان iss مطالبه.

اگر این تنظیمات درست نباشند – درگاه API هنگام دسترسی به نقاط پایانی خطا می دهد.

خطا می تواند باشد 401 غیر مجاز و مربوط به موارد زیر:

• صادر کننده نادرست
• آدرس اینترنتی jwks در دسترس نیست
• کلیدها قابل حل نیستند، عدم تطابق بچه
• JWT’s – exp nbf، درست نیست

لطفاً برای سؤالات، تردیدها یا پیشنهادات بیشتر از طریق Linkedin در اینجا با من تماس بگیرید.