خواندن ۸ دقیقه·۵ سال پیش

احراز هویت و دسترسی ها در میکروسرویس (Microservice)

معماری میکروسرویس مزایای بسیاری را برای اپلیکیشن از جمله تبدیل تیم های بزرگ به تیم های کوچک توسعه ، چرخه های توسعه کوتاه تر، انعطاف پذیری در انتخاب زبان و قابلیت مقیاس پذیری بیشتر را فراهم می کند.

از طرفی با بسیاری از مشکلات پیچیده سیستم های توزیع شده نیز مواجه می شویم. یكی از این چالش ها نحوه پیاده سازی احراز هویت (authentication) و دسترسی ها (authorization) به صورت ایمن و كارآمد در معماری میکروسرویس است. در این مطلب سعی می کنیم در مورد این موضوع صحبت کنیم.

تفاوت بین احراز هویت و دسترسی ها

احراز هویت (authentication) مشخص می کند شما چه کسی هستید و شما می توانید با نام کاربری و رمز عبور از اپلیکیشن استفاده کنید.

دسترسی ها (authorization) مشخص می کند که کاربر چه کاری می تواند انجام دهد به طور مثال آیا دسترسی ویرایش پست ها را دارد یا ندارد.

احراز هویت و دسترسی ها در مونولیتیک

در معماری مونولیتیک تمام اپلیکیشن در داخل یک پروسه کار ها را انجام می دهند که وظیفه احراز هویت و مدیریت دسترسی ها به عهده ماژول اعتبار سنجی هست.

بعد از لاگین کاربر ماژول اعتبارسنجی اطلاعات کاربر را بررسی می کند و پس از تایید شدن هویت کاربر یک session به همراه یک شناسه یکتا برای کاربر ساخته می شود. و در داخل session اطلاعات مربوط به کاربر را مانند نام کاربر ، نقش و دسترسی را وارد می کند. سرور شناسه session را به سمت کلاینت بر می گرداند. کلاینت شناسه را در داخل یک کوکی ذخیره می کند و در درخواست های بعدی آن را به برنامه ارسال می کند. سپس اپلیکیشن می تواند از شناسه session برای تأیید هویت کاربر استفاده کند ، بدون نیاز به وارد کردن نام کاربری و رمز عبور برای تأیید اعتبار در هر بار.

مشکلات احراز هویت و دسترسی در میکروسرویس

در معماری میکروسرویس، یک اپلیکیشن به چندین میکروسرویس مجزا تقسیم می شود و هر میکروسرویس منطق یک ماژول در اپلیکیشن مونولیتیک پیاده سازی می کند. پس از تقسیم شدن کار ها ما نیاز به احراز هویت در میکروسرویس هایی که کاملا از هم جداگانه کار می کنند داریم. اگر از معماری مونولیتیک به میکروسرویس مهاجرت کنیم با مشکلات زیر در زمینه احراز هویت مواجه می شویم.

منطق احراز هویت و دسترسی باید در هر میکروسرویس انجام شود و این بخش از منطق کلی باید در هر میکروسرویس به طور مکرر پیاده سازی شود.
میکروسرویس باید بر محوریت یک منطق کسب و کار باشد به طور مثال میکروسرویس سفارشات فقط وظیفه حوزه سفارشات را به عهده دارد پس منطق احراز هویت و دسترسی نباید در میکروسرویس ها موجود باشد.
در پروتکل HTTP سرور می تواند درخواست های مشتری را به هر node در cluster در صورت لزوم ارسال کند. stateless بودن HTTP مزیت حفظ تعادل بار را به ما می دهد. می توان درخواست های کاربر را در هر سرور توزیع کرد. برای سرویس هایی که نیازی به تأیید اعتبار ندارند ، مانند مرور صفحات خبر ، مشکلی وجود ندارد. با این حال ، بسیاری از خدمات ، از جمله خرید آنلاین و سیستم های مدیریت شرکت ، نیاز به تأیید هویت کاربر دارند. بنابراین ، لازم است که وضعیت ورود کاربر را به روشی بر اساس پروتکل HTTP ذخیره کنید تا از نیاز کاربر برای انجام تأیید برای هر درخواست ، جلوگیری شود. روش سنتی استفاده از یک session در سمت سرور برای مشخص شدن وضعیت کاربر است اما این مسئله بر گسترش افقی (horizontal expansion) سرور تأثیر می گذارد.
احراز هویت و دسترسی در معماری میکروسرویس پیچیده تر است، از جمله دسترسی کاربران به میکروسرویس ها، دسترسی شخص ثالث (third-party) میکروسرویس ها و دسترسی میکروسرویس ها به یک دیگر.

راه حل های احراز هویت و دسترسی در میکروسرویس

۱ - استفاده session توزیع شده:

به منظور استفاده کامل از مزایای معماری میکروسرویس و دستیابی به مقیاس پذیری و انعطاف پذیری میکروسرویس ها نیاز است یکی از روش های زیر برای مدیریت سشن ها انتخاب شود.

روش اول - sticky session: در این روش اطمینان حاصل می کنیم که کلیه درخواست های یک کاربر خاص به همان سرور ارسال شده که اولین درخواست مربوط به آن کاربر را دریافت کرده است، بنابراین اطمینان حاصل می کند که داده های سشن همیشه برای کاربر خاصی صحیح است. با این حال ، این راه حل بستگی به متعادل کننده بار (load balancer) دارد وقتی متعادل کننده بار به هر دلیلی مجبور شود درخواست کاربر را به سرور دیگری ارسال کند، تمام داده های جلسه کاربر از بین می رود.

روش دوم - session replication: در این روش هر سشن که ذخیره می شود از طریق شبکه در تمام سرور ها همگام سازی می شود. همگام سازی سشن باعث اشغال شدن پهنای باند شبکه می شود. زمانی که داده های سشن تغییر می کند ، داده ها باید برای همه سرور های دیگر همگام سازی شوند. هرچه موارد بیشتر باشد ، همگام سازی پهنای باند شبکه بیشتری اشغال می شود.
روش سوم - centralized session storage: در این روش وقتی کاربر به یک میکروسرویس دسترسی پیدا می کند، می توانید داده های کاربر را از محل ذخیره سشن مشترک بدست آورد که کلیه میکروسرویس ها می توانند داده های سشن مشابه را بخوانند. نقطه ضعف این راه حل این است که ذخیره سازی جلسات مشترک به یک مکانیسم محافظت خاص نیاز دارد و بنابراین باید از طریق یک روش مطمئن به آنها دسترسی پیدا کنید.

۲ - استفاده از توکن در سمت کاربر:

روش سنتی استفاده از یک سشن در سمت سرور برای ذخیره وضعیت کاربر است. از آنجا که سرور stateful است، تأثیر آن بر گسترش افقی سرور است. توصیه می شود برای ذخیره وضعیت ورود کاربر در معماری میکروسرویس از توکن استفاده کنید.

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

توکن برای نشان هویت کاربر است. بنابراین برای جلوگیری از جعل توسط کاربر، باید محتوای توکن رمزگذاری شود. JWT یک استاندارد (RFC 7519) است که ساختار توکن و محتوی توکن را تعریف می کند ، آن را رمزگذاری می کند و برای زبان های مختلفی کتابخانه دارد. نمونه ای از jwt توکن را در قسمت زیر مشاهده میکنیم.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6MTIzLCJuYW1lIjoiTWVuYSBNZXNlaGEiLCJpc19hZG1pbiI6dHJ1ZSwiZXhwaXJlIjoxNTU4MjEzNDIwfQ.Kmy_2WCPbpg-aKQmiLaKFLxb5d3rOC71DHexncH_AcQd

با استفاده از توکن برای تأیید اعتبار کاربر، سرور وضعیت کاربر را ذخیره نمی کند. کاربر باید با هر درخواست توکن را برای تأیید اعتبار به سرور ارسال کند.

تأیید اعتبار کاربر با توکن به شرح زیر است:

۳ - روش Single sign-on:

ایده Single sign-on ساده است ، یعنی کاربران فقط باید یک بار وارد برنامه شوند ، سپس می توانند به کلیه خدمات در میکروسرویس ها دسترسی پیدا کنند. این راه حل بدین معنی است که هر میکروسوریس باید مانند میکروسرویس زیر با میکرو سرویس تأیید اعتبار ارتباط برقرار کند:

این می تواند باعث ایجاد ترافیک بسیار زیاد شبکه شود. هنگامی که ده ها میکروسرویس وجود دارد، اشکالاتی در مورد این راه حل خودشون رو نشون میدن.

۴ - استفاده از توکن در سمت کاربر به همراه API Gateway:

مراحل احراز هویت کاربر مشابه روش دوم است. تفاوت در این است که API Gateway به عنوان ورودی درخواست خارجی اضافه می شود. این یعنی که همه درخواست ها باید از API Gateway رد بشوند.