در بخش اول به بررسی مفاهیم
identity management, federated identity, authorization delegation
و مسیری که طی شده تا به این solutionها برسیم، پرداختیم. در این بخش به بررسی جزئیات بیشتری از authorization delegation می پردازیم.
همانطور که اشاره شد، در یک سناریو از authorization delegation، به کسی که صاحب یک resource است resource owner گفته می شود. همچنین یک resource server نیز وجود دارد که resourceها بصورت حفاظت شده در آن قرار دارند و این قابلیت را دارد تا به کسانی که دسترسی مناسب دارند، resourceها را برگرداند. client، اپلیکیشن استفاده کننده از resourceها می باشد که از طرف owner به resourceها دسترسی پیدا می کند. و authorization server عملیات delegation را با صدور access token انجام می دهد.
در این تصویر، یک abstract از جریان پروتکل OAuth ملاحظه می کنید.
در گام اول، client از resource owner درخواست دسترسی می کند. این درخواست در flowهای متفاوتی می تواند پیاده سازی شود. client بسته به پیاده سازی، گاهی credential را خودش از resource owner می گیرد و به authorization server ارسال می کند و گاهی شما را به authorization server هدایت می کند و در آنجا از شما می خواهد که credential خود را وارد کنید و access token را دریافت می کند.
راه حل پیشنهادی پروتکل این است که client مستقیما پسورد را دریافت نکند و از طریق authorization server اطلاعات دریافت شود. به این عملیات authorization grant گفته می شود.
در ادامه مراحل، client به هر نحوی با ارائه authorization grant، به یک access token دسترسی پیدا می کند و از آن برای دسترسی به resourceها استفاده می کند.
در OAuth، چهار Grant Types برای ارائه credential به client وجود دارد.
Grant Types:
در OAuth، موضوع Client Registration از اهمیت بالایی برخوردار است. clientها باید در authorization server معرفی شده باشند. این جریان از OAuth specification خارج می باشد و client به یک طریقی باید register شود. برای این موضوع، باید انواع clientها را بشناسیم.
بسته به این موضوع که clientها چطور می توانند داده ای را امن نگهداری کنند، به دو نوع confidential و public تقسیم می شوند. اگر id و secret را برای یک client در نظر بگیریم، یک client که دارای backend می باشد، می تواند این اطلاعات را به صورت امن در خود نگهداری کند و confidential می باشد. اما client که با javascript نوشته شده است در دسته public قرار می گیرد.
انتخاب flowهای مختلف در OAuth بسته به نوع client می تواند تاثیر گذار باشد.
در تعریف clientها در OAuth، نوع client جزو موارد اجباری می باشد که باید مشخص شود. redirection urlها نیز از مواردی هستند که باید مقدار دهی شوند.
در بعضی از flowها، نیاز است که client authentication اتفاق بیافتد. بنابراین برای confidential clientها، id و secret در نظر می گیرم. برای clientهای public این موضوع اهمیتی ندارد.
در پروتکل OAuth، هر جایی که نیاز به درخواستی باشد که در آن client باید authenticate شود، از Authorization header استفاده می کنیم که اصطلاحا به آن basic authentication گفته می شود.
Authorization: Basic base64(client_id:client_secret)
جریان authorization code، به عنوان امن ترین flow در OAuth معرفی می شود که در آن client برای عملیات login شما را به همراه پارامتر های مشخصی به authorization server هدایت می کند. زمانی که کاربر credential را در authorization server وارد می کند و اجازه را صادر می کند، کاربر به همراه یک code مجددا به سمت client برگردانده می شود. client کد را دریافت می کند و این بار از طریق سرور، code را به همراه client id و client secret به سمت authorization server ارسال می کند و token را به عنوان response دریافت می کند.
نکته مثبت اول این flow این است که credential را به authorization server می دهیم که به آن اطمینان داریم. و نکته مثبت دوم این است که token بر روی مرورگر قرار نمی گیرد و به صورت backchannel بین client و authorization server منتقل می شود.
یکی از پارامترهایی که در زمان authorization request توسط client مقدار دهی می شود، پارامتر response_type است که برای نشان دادن این flow، با مقدار code پر می شود. زمانی که authorization اتفاق می افتد، authorization server در زمان redirection دو پارامتر code و state را به client برمی گرداند.
در مرحله access token request، پارامتر grant_type با مقدار authorization_code پر می شود. همچنین پارامترهای redirect_uri ،code و client_id نیز از پارامترهایی هستند که در این مرحله به authorization server ارسال می شوند.
در implicit flow، جریان ساده تر تعریف می شود. این flow برای public clientها طراحی شده است که دارای back end نیستند بنابراین این عمل با redirection اتفاق می افتد.
در implicit flow، کاربر از طریق client به authorization server هدایت می شود. در پارامترهای ارسالی، response_type با مقدار token پر می شود.
پس از وارد کردن credential، کاربر به همراه token به سمت client بر می گردد. در این روش token از طریق url و query string به client ارائه می شود که می تواند دارای ریسک امنیتی باشد.
جریان resource owner password credentials (ROPC)، صرفا برای Trusted Clientها کاربرد دارد. برخی از clientها هستند که برای ما کاملا امن هستند. برای مثال، api و client هر دو برای یک شخص یا سازمان می باشد. در این جریان، resource owner عملیات credential را بر روی trusted client انجام می دهد. client آن را برای authorization server ارسال می کند و access token را دریافت می کند. در authorization request پارامتر grant_type با مقدار password پر می شود و به همراه username و password کاربر به authorization server ارسال می شود.
در client credentials flow، برای مثال یک background service را به عنوان client در نظر بگیرید که در یک job مشخص api را صدا می زند. در این جریان، هویت کاربران اهمیتی ندارد و client عملیات authorization را از سمت خودش انجام می دهد. در token request پارامتر grant_type با مقدار client_credentials پر می شود.
در بخش بعدی، Bearer Token و Refresh Token را بررسی خواهیم کرد.
