معرفی یک سیستم ثبت نام امن اندروید : 5 بخش اصلی


در این مقاله یک سیستم ثبت نام امن را معرفی و بررسی میکنیم . . .
« داشتن یه نقشه کلی از یک مسئله ، به ما کمک میکنه ، که راحت تر موضوع رو درک کنیم ، و بهتر بتونیم مشکلات رو بررسی و حل کنیم » ،
در ارتباط میان کاربر و سرور، توکنها نقش مهمی در تایید هویت و کنترل سطح دسترسی ایفا میکنند و همچنین در درست کردن یک سیستم ثبت نام نقش بسزایی دارند . به طور معمول، ما
را از سرویسهایی مثل گوگل دریافت کرده و بخشی از آن را به سمت سرور خود ارسال میکنیم تا کاربر تایید شود و بتوانیم سطح دسترسی مناسب را به او اختصاص دهیم.هنگامی که کاربر اقدام به ثبت نام در اپلیکیشن میکند، ID Token به سمت دیتابیس یا سرور ارسال میشود. این توکن از طرف گوگل صادر شده و برای تایید هویت کاربر و ارائه سطح دسترسی استفاده میشود( همان طور که در شکل زیر مشاهده میکنید ، البته idToken به صورت TokenId نوشته شده است ) . ID Token بر پایه استاندارد OpenID Connect طراحی شده است که یک استاندارد جهانی محسوب میشود و در بسیاری از سرویسها مانند گوگل، توییتر و فیسبوک مورد استفاده قرار میگیرد. میتوان گفت شالوده ایجاد یک سیستم ثبت نام امن همین ID Token هست .
در تصویر زیر، نحوه تایید کاربر و ارتباط با سرور بر اساس OpenID Provider نمایش داده شده است:
در مقدمه بالا به همراه عکس ، مفاهیمی مانند ، ID Token , authentication , Session , cookie و مورادی دیگر که در توضیحات این ، مفاهیم آورده شد مانند Authoriztoin , oAuth , open id connect , jwt ، که مقداری متن گنگ بود ، برای این منظور تمامی این مفاهیم و اصطلاحات رو توضیح میدیم تا این متن بسیار واضح و قابل درک باشد .
بخش اول : مفهوم ID Token و Access Token -شالوده اصلی سیستم ثبت نام
مفهوم ID Token
ID Token یک فایل یا توکن دیجیتال است که معمولاً در فرآیند احراز هویت (Authentication) استفاده میشود. این توکن به کاربر اجازه میدهد که شناسایی شود و به منابع و برنامههای خاصی دسترسی پیدا کند.
- تعریف ID Token: ID Token یک نوع توکن است « میتونیم فعلا توکن رو یه فایل در نظر بگیریم » که اطلاعات مربوط به هویت کاربر را در بر دارد. این توکن معمولاً به عنوان بخشی از پروتکلهای احراز هویت مانند OAuth 2.0 و OpenID Connect صادر میشود.
- محتوای ID Token: ID Token معمولاً شامل اطلاعاتی از جمله شناسه کاربر (User ID)، زمان صدور توکن، زمان انقضا، و سایر اطلاعات مرتبط با هویت کاربر است. این اطلاعات به صورت JSON Web Token (JWT) رمزگذاری شده است.
به عنوان مثال، یک فایل JSON Web Token (JWT) به شکل زیر است:
{ "header": { "alg": "RS256", "typ": "JWT" }, "payload": { "iss": "accounts.google.com", "aud": "my-app-id", "sub": "1234567890", "exp": 1623367200, "iat": 1623363600 }, "signature": "abcdef1234567890" }
رمزگشایی JWT
برای خواندن محتوای این توکنها، باید آنها را
کنیم. این توکنها رمزگذاری نشدهاند، بلکه بر اساس استاندارد کدگذاری شدهاند. پس از رمزگشایی، محتوای آنها قابل مشاهده خواهد بود.درون توکن، دادههایی(که اصطلاحاً به آنها Claims می گویند ) قرار دارد که اطلاعات مهمی را در بر دارد. برخی از این اطلاعات شامل موارد زیر است:
- aud: مخفف Audience – نشان میدهد که گیرنده توکن چه کسی است.
- iss: مخفف Issuer – نشان میدهد که توکن توسط چه کسی صادر شده است.
Issuer اهمیت بالایی دارد، چرا که از طریق کلید اختصاصی (Private Key) مشخص میکند که توکن دستکاری نشده باشد. به عنوان مثال، اگر ما درخواست یک ID Token از گوگل کنیم، گوگل یک کلید اختصاصی برای ما ثبت میکند. سپس، با دریافت توکن، ما از طریق کلید عمومی (Public Key) میتوانیم تایید کنیم که این توکن واقعاً از سمت گوگل صادر شده است.
کاربردهای ID Token
- تایید هویت کاربر: نشان میدهد که کاربر با اطلاعات و ورودیهای قابل اعتماد شناسایی شده است. همچنین مشخص میکند که این شناسایی توسط سرویس معتبر (مانند گوگل یا یک OpenID Provider) انجام شده است.
- شخصیسازی برنامه: بر اساس اطلاعات موجود در ID Token، میتوان برنامه را شخصیسازی کرد. به عنوان مثال، نمایش اطلاعات کاربر در صفحه اصلی اپلیکیشن.
مفهوم Access Token
Access Token برای تعیین سطح دسترسی کاربر و اعطای مجوز استفاده میشود. این Access Token در تعاریف ظاهری نشان داده نمی شود ، اما یک اصطلاحی است که بعد از این که کاربر موفق به وارد شدن به برنامه شد ،با این توکن به اپلیکیشن اجازه میدهد تا به منابع خاصی از سرور دسترسی پیدا کند. به عنوان مثال، شما میتوانید تعیین کنید که اپلیکیشن کاربر بتواند عکسها را در گوگل درایو آپلود کند، اما اجازه حذف فایلها را نداشته باشد.
در این میان، مفهوم Scope تعریف میشود که لیستی از دسترسیها و مجوزها را مشخص میکند.یا به عبارتی ، محدودی این مجوز ها رو بررسی میکند ، این لیست تعیین میکند که کدام اپلیکیشن به کدام منابع سرور دسترسی دارد.
امنیت Access Token
Access Token باید به صورت محرمانه نگهداری شود، همانند ID Token. تنها سه بخش مجاز به مشاهده آن هستند:
- Client App: اپلیکیشن کاربر
- Authorization Server: سرور تایید هویت
- Resource Server: سروری که منابع در آن ذخیره شدهاند ( منظور از منابع ،داده ها و فایل های است که برای کاربران استفاده میشود ) .
برای اطمینان از امنیت این توکنها، اپلیکیشنها باید مطمئن شوند که دیگر برنامههایی که از منابع مشترک سرور استفاده میکنند، به این اطلاعات دسترسی ندارند. یکی از راههای حفظ امنیت توکنها استفاده از HTTPS است که ارتباطات را به صورت رمزنگاری شده ارائه میدهد.
نتیجهگیری
توکنها در برنامهنویسی اندروید به عنوان یک روش استاندارد برای تایید هویت و کنترل سطح دسترسی کاربران استفاده میشوند. ID Token برای تایید هویت و شخصیسازی اپلیکیشن کاربرد دارد، در حالی که Access Token برای تعیین سطح دسترسی به منابع سرور استفاده میشود. رعایت اصول امنیتی در استفاده از این توکنها اهمیت بالایی دارد و باید به دقت پیادهسازی شود.
توکن | نقش اصلی | مرتبط با مفهوم | فرمت معمول | قابلیت مشاهده محتوا |
ID Token | اثبات احراز هویت موفق کاربر | Authentication | JWT | بله، قابل دیکود |
Access Token | اجازه انجام عملیات خاص از طرف کاربر | Authorization | JWT یا سایر فرمتها | خیر، باید محرمانه بماند |
بخش دوم : تفاوت بین Authentication و Authorization
در بخش اول با مفاهیم ID Token , Access Token آشنا شدین ، اما دو عبارت ، Authentication و Aythorization معرفی شد که در این بخش میخوام در این باره صحبت کنم :
✅ تفاوت بین Authentication و Authorization
در این قسمت ، میخواهیم تفاوت بین دو مفهوم بسیار مهم و گاهی اشتباهگرفتهشده در توسعهی نرمافزار را بررسی کنیم: Authentication و Authorization.
این دو واژه اغلب در فرآیند ثبتنام و ورود کاربران استفاده میشوند و شناخت دقیق آنها میتواند در طراحی سیستمهای کاربری امن، به شما کمک زیادی بکند.
🔐 Authentication (احراز هویت)
وقتی کاربر میخواهد وارد حساب خود شود یا ثبتنام کند، سیستم باید مطمئن شود او همان کسیست که ادعا میکند. این کار معمولاً با اطلاعاتی مثل:- نام کاربری و رمز عبور
- ایمیل
- شماره تلفن
- کد تایید (OTP)
و… انجام میشود.
در این مرحله، هدف فقط شناسایی فرد است، نه تعیین سطح دسترسی او.
🎫 Authorization (اعطای دسترسی)
پس از اینکه هویت کاربر تأیید شد (مرحله Authentication)، سیستم بررسی میکند که کاربر به چه بخشهایی از برنامه مجاز است دسترسی داشته باشد.مثلاً یک کاربر عادی نمیتواند به بخش مدیریت یا تنظیمات پیشرفته دسترسی داشته باشد. اینجاست که Authorization وارد عمل میشود.
👔 یک مثال ساده برای درک بهتر:
فرض کنید شما کارمند یک شرکت هستید.
- وقتی صبح وارد شرکت میشوید و کارت ورود خود را به دستگاه میزنید تا هویتتان تأیید شود، در حال انجام مرحلهی Authentication هستید.
- حالا فرض کنید شرکت سه طبقه دارد و فقط طبقهی دوم مخصوص بخش IT است که شما در آن کار میکنید. اینکه فقط به طبقه دوم دسترسی دارید، یعنی مرحلهی Authorization.
📱 این مفاهیم در اندروید کجا کاربرد دارند؟
در برنامههای اندرویدی، معمولاً ابتدا کاربران با وارد کردن ایمیل یا رمز عبور، وارد سیستم میشوند (Authentication).
سپس بر اساس نقش آنها (مثلاً: کاربر عادی، مدیر، مهمان)، سطوح مختلفی از دسترسی برایشان تعریف میشود (Authorization).
درک این تفاوت به شما کمک میکند تا ساختار بهتری برای مدیریت کاربران طراحی کنید، مخصوصاً در پروژههای بزرگتر با چند سطح کاربری.
بسیار خب ، تا به این جای کار ، شما ارتباط بین ID Token و Authentication و همچنین Access Token و Authorization را متوجه شدید ، که در جدول بالا در یک ردیف قرار گرفته بودند .
بخش سوم : JWT (JSON Web Token)
در ادامه می خوایم ، JWT (JSON Web Token) رو بررسی کنیم که توکن ها از این استاندارد در سیستم ثبت نام استفاده میکنند .
JWT چیست؟
JWT مخفف JSON Web Token است و یک استاندارد باز برای انتقال اطلاعات بین دو طرف به صورت امن، فشرده، و خودمحتوا است.
ویژگیهای کلیدی JWT:
- اطلاعات به صورت شیء JSON نگهداری میشود.
- توکن توسط فرستنده امضا (Sign) میشود (با الگوریتمهایی مانند HMAC یا RSA) تا گیرنده بتواند:
- از درستی دادهها مطمئن شود (Data Integrity).
- از اصالت فرستنده اطمینان حاصل کند (Authenticity).
چرا JWT مهم است؟
در دنیای وب مدرن، برنامهها بهصورت توزیعشده و اغلب بدون وضعیت (Stateless) هستند. JWT امکان میدهد تا دادههای مهم مثل وضعیت ورود کاربر، نقشها، و مجوزها بدون نیاز به ذخیرهسازی در سرور، همراه با هر درخواست ارسال شود.
🔹 موارد استفادهی اصلی JWT
۱. تبادل اطلاعات (Information Exchange)
- JWT راهی مطمئن برای انتقال اطلاعات بین کلاینت و سرور است.
- چون اطلاعات امضا شدهاند، گیرنده میتواند مطمئن باشد که:
- دادهها در مسیر دستکاری نشدهاند.
- فرستنده همان کسی است که باید باشد.
۲. احراز هویت (Authentication / Authorization)
- پس از ورود موفق کاربر، سرور یک توکن JWT برای او تولید و ارسال میکند.
- این توکن در سمت کلاینت ذخیره میشود (مثلاً در localStorage یا cookie).
- در هر درخواست بعدی، کلاینت این توکن را ارسال میکند و سرور با بررسی آن:
- هویت کاربر را تشخیص میدهد.
- مجوز دسترسی به منابع خاص را بررسی میکند.
📌 توجه:
- در برخی سرویسها مانند APIهای گوگل، از JWT استفاده میشود.
- اما در برخی معماریهای خاص (مثلاً backend اختصاصی)، به جای JWT ممکن است از Session Cookie استفاده شود.
- هدف آشنایی با هر دو روش و درک تفاوتهاست.
🔹 ساختار JWT
یک توکن JWT از سه بخش اصلی تشکیل شده است که با نقطه (.) از هم جدا میشوند:
HEADER . PAYLOAD . SIGNATURE
۱. Header (سربرگ)
حاوی اطلاعاتی درباره:
- نوع توکن (معمولاً JWT)
- الگوریتم امضا (مثلاً HS256 یا RS256)
ساختار به صورت JSON است:
{ "alg": "HS256", "typ": "JWT" }
سپس به صورت Base64URL رمزگذاری میشود.
۲. Payload (محتوا)
- شامل دادهها یا claims است (اطلاعاتی درباره کاربر یا توکن).
- سه نوع claims داریم:
- Registered claims: کلیدهای استاندارد از پیش تعریفشده مانند:
- iss (صادرکننده)، exp (زمان انقضا)، sub (موضوع)، aud (گیرنده)
- Public claims: کلیدهایی که عموم میتوانند تعریف کنند.
- Private claims: کلیدهای سفارشی بین دو طرف قرارداد.
- Registered claims: کلیدهای استاندارد از پیش تعریفشده مانند:
📌 مهم:
Payload قابل رمزگشایی توسط هر کسی است که توکن را دارد. بنابراین نباید اطلاعات حساس (مثل رمز عبور یا شماره کارت) در آن قرار گیرد مگر اینکه کل توکن رمزگذاری شده باشد.
۳. Signature (امضا)
- برای بررسی اصالت و یکپارچگی توکن استفاده میشود.
- ساختار امضا به صورت زیر است:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
- Signature تضمین میکند که:
- کسی نتوانسته محتویات توکن را دستکاری کند.
- توکن توسط موجودی که کلید را دارد تولید شده است.
🔹 نمونه عملی از JWT
برای دیدن ساختار و تست کردن توکنها میتوانید از سایت زیر استفاده کنید:
🔗 https://jwt.io
در این سایت:
- میتوانید یک JWT را در قسمت “Encoded” وارد کنید.
- و بلافاصله بخشهای Header، Payload، Signature را مشاهده و بررسی کنید.
- حتی میتوانید با وارد کردن کلید (Secret)، امضا را تأیید کنید.
📌 توجه مهم:
- توکن JWT به صورت رمزگذاری نشده ارسال میشود (فقط Base64 کدگذاری شده).
- پس هر کسی که توکن را داشته باشد، میتواند محتویات Payload را بخواند.
- در نتیجه ارسال توکن باید از طریق HTTPS انجام شود تا امنیت حفظ شود.
✅ خلاصه آموختهها تا به این جا میشه :
- JWT یک روش امن برای انتقال داده بین کلاینت و سرور است.
- توکن شامل سه بخش است: Header, Payload, و Signature.
- اطلاعات به صورت JSON هستند و با الگوریتمهایی مانند HMAC یا RSA امضا میشوند.
- JWT امکان احراز هویت بدون نیاز به نگهداری Session در سرور را فراهم میکند.
- چون محتویات توکن قابل مشاهدهاند، نباید اطلاعات حساس در آن قرار گیرد.
- استفاده از HTTPS الزامی است تا از شنود اطلاعات جلوگیری شود.
- Authentication یعنی تایید کاربر چه کسی است
- Authorization یعنی تعیین سطح دسترسی کاربر
- ID Token برای شناسایی کاربر استفاده میشود
- Access Token برای تعیین سطح دسترسی کاربر استفاده میشود .
بخش چهارم : بررسی مفهوم Session و Cookie
در بخش قبل jwt ما با دوتا اصطلاح آشنا شدیم : Session , Cookie در این قسمت میخوام این هارو توضیح بدم این مفاهیم برای مدیریت هویت کاربران و کنترل دسترسی به منابع سرور بسیار مهم هستند.
چرا به Session نیاز داریم؟
در ارتباط بین کلاینت (کاربر) و سرور، پس از دریافت ID Token از سرویسهایی مانند گوگل، این توکن به سرور ارسال میشود. سرور وظیفه دارد این توکن را بررسی کند تا مطمئن شود:
- توکن از صادرکننده معتبر (Issuer) آمده است.
- این توکن برای اپلیکیشن یا مخاطب (Audience) موردنظر صادر شده است.
مراحل ایجاد Session:
- ارسال توکن به سرور: ابتدا کاربر توکن خود را به سرور ارسال میکند.
- بررسی توکن توسط سرور: سرور اطلاعات کاربر را استخراج کرده و پس از تایید صحت توکن، این اطلاعات را در دیتابیس ذخیره میکند.
- ایجاد Session ID: پس از تایید موفقیتآمیز توکن، سرور یک Session ID ایجاد کرده و به کاربر ارسال میکند.
- استفاده از Session ID: کاربر از این Session ID برای درخواستهای بعدی به سرور استفاده میکند. این شناسه به سرور اجازه میدهد تا کاربر را بدون نیاز به تایید مجدد توکن شناسایی کند.
نکته مهم درباره ID Token
توکنهایی که توسط گوگل ایجاد میشوند، دارای زمان انقضا هستند. معمولاً زمان اعتبار این توکنها یک ساعت است. پس از انقضای توکن، کاربر باید دوباره مراحل تایید هویت را انجام دهد. اما اگر کاربر قبل از انقضای توکن، آن را به سرور ارسال کند، سرور یک Session ID ایجاد میکند که مدت زمان بیشتری نسبت به توکن معتبر است.
زمان اعتبار Session
- در بسیاری از موارد، Session هنگام بسته شدن مرورگر وب به پایان میرسد.
- اما میتوان زمان انقضای Session را به صورت دستی تنظیم کرد.
تفاوت Session و Cookie
تعریف کلی:
- Session: اطلاعات کاربر را در سمت سرور ذخیره میکند.
- Cookie: اطلاعات کاربر را در سمت کلاینت (مرورگر یا دستگاه کاربر) ذخیره میکند.
تفاوتهای اصلی:
- محل ذخیرهسازی:
- Session: در سمت سرور ذخیره میشود.
- Cookie: در مرورگر یا دستگاه کاربر ذخیره میشود.
- میزان داده قابل ذخیرهسازی:
- Session: امکان ذخیرهسازی نامحدود دادهها وجود دارد (تا سقف حافظه سرور، معمولاً 128 مگابایت).
- Cookie: حداکثر 4 کیلوبایت داده قابل ذخیرهسازی است.
- امنیت:
- Session: امنتر است؛ زیرا دادهها در سرور به صورت رمزنگاریشده ذخیره میشوند.
- Cookie: کمتر امن است؛ دادهها به صورت متن ذخیره میشوند و امکان دستکاری توسط کاربران غیرمجاز وجود دارد.
در پروژه ما:
- Cookie فقط برای ارسال Session ID به سرور استفاده میشود تا در هر درخواست، سرور بتواند کاربر را شناسایی کند.
نحوه عملکرد Session
مراحل:
- ارسال درخواست به سرور: کاربر یک درخواست HTTP به سرور ارسال میکند.
- ایجاد Session ID: سرور یک Session ID ایجاد کرده و به کاربر ارسال میکند.
- ذخیرهسازی Session ID در دیتابیس: سرور این Session ID را در دیتابیس ذخیره میکند.
- ارسال Session ID در درخواستهای بعدی: کاربر در هر درخواست بعدی، Session ID را به سرور ارسال میکند.
- بررسی Session ID توسط سرور: سرور Session ID را با اطلاعات موجود در دیتابیس مقایسه کرده و در صورت اعتبار، پاسخ مناسب را به کاربر ارسال میکند.
تفاوتهای امنیتی Session و Cookie
- Session به دلیل ذخیرهسازی دادهها در سمت سرور و استفاده از رمزنگاری، امنیت بیشتری دارد.
- Cookie به دلیل ذخیره شدن در دستگاه کاربر و امکان دسترسی توسط افراد غیرمجاز، امنیت کمتری دارد.
نتیجهگیری
Session و Cookie ابزارهای مهمی برای مدیریت کاربران و حفظ ارتباط بین کلاینت و سرور هستند. در اپلیکیشنهای اندروید، Session ID برای تایید هویت کاربر و دسترسی به منابع خاص سرور استفاده میشود. Cookie نیز برای ارسال این Session ID به سرور مورد استفاده قرار میگیرد.
نکات کلیدی:
- Session برای ذخیرهسازی دادههای کاربر در سمت سرور استفاده میشود و امنتر است.
- Cookie برای ذخیره دادهها در سمت کلاینت استفاده میشود و کمتر امن است.
- در پروژه ما، Cookie فقط وظیفه ارسال Session ID به سرور را دارد.
یک مثال عملی :
✅ سناریو: ورود حامد به سایت Microsoft با JWT
🧍♂️ (کاربر):
- اسم: حامد
- رمز عبور: 1234
- هدف: ورود به حساب کاربریت در سایت Microsoft
➊ مرحله اول: ارسال درخواست ورود (Login Request)
تو فرم ورود، اسم و رمزت رو وارد میکنی:
{ "username": "hamed", "password": "1234" }
مرورگر این اطلاعات رو میفرسته به سرور Microsoft.
➋ مرحله دوم: بررسی اطلاعات در سرور
سرور Microsoft بررسی میکنه:
- آیا کاربری به اسم hamed وجود داره؟
- آیا رمز عبورش درسته؟
✅ اگر درست بود، حالا نوبت JWT میرسه!
➌ مرحله سوم: ساختن توکن JWT
سرور یک توکن JWT برای تو تولید میکنه، مثلاً با این محتوا در بخش payload:
{ "sub": "hamed", "role": "user", "exp": 1712345678 }
این یعنی:
- این توکن مربوط به کاربر حامد هست (sub)
- نقش کاربر عادی داره (role)
- و این توکن تا یه زمان خاصی اعتبار داره (exp)
این payload + header توسط سرور امضا (sign) میشه با کلید مخفی خودش.
➍ مرحله چهارم: ارسال JWT به تو
حالا سرور توکن JWT رو به مرورگر تو میفرسته و مثلاً در localStorage یا cookie ذخیره میشه.
➎ مرحله پنجم: درخواستهای بعدی با توکن
حالا هر وقت میخوای بری به یه صفحه خاص (مثلاً mysite.com/dashboard) مرورگر توکن JWT رو میفرسته همراه درخواست.
مثلاً در هدر درخواست:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6…
➏ مرحله ششم: بررسی توکن توسط سرور
سرور JWT رو بررسی میکنه:
- امضاش درسته؟ (یعنی دستکاری نشده)
- تاریخ انقضاش نگذشته؟
- توکن مربوط به کاربر معتبره؟
اگر همه چیز درست بود، دسترسی به صفحه مورد نظر داده میشه.
🎯 نتیجه:
- تو فقط یه بار رمزت رو میفرستی.
- بعدش توکن JWT رو میگیری و تا وقتی اعتبار داره، باهاش درخواست میفرستی.
- سرور دیگه لازم نیست هر بار اطلاعات تو رو از دیتابیس چک کنه؛ فقط کافیه توکن رو تأیید کنه.
- سریعتره، سادهتره، و نیازی به نگه داشتن session در سرور نیست.
بخش پنجم : آموزش OAuth 2.0 و OpenID Connect
تا به این جای کار ، تمام مفاهیمی که به صورتی عیان بودند و ما مستیقیم با آن ها سرو کار داشتیم ، بیان کردیم و در ادامه به دو مورد مفهوم پایهای OAuth 2.0 و OpenID Connect بررسی میکنیم
🔐 OAuth 2.0 چیست؟
OAuth 2.0 یک فریمورک صدور مجوز (authorization
) است که اجازه میدهد یک سرویسدهنده (مثل گوگل یا فیسبوک) وظیفه احراز هویت کاربران را برعهده بگیرد و به اپلیکیشنهای شخص ثالث اجازه دسترسی به حساب کاربر را بدهد، بدون اینکه رمز عبور او را افشا کند.📌 اپلیکیشنهای شخص ثالث یعنی چی؟
منظور از اپلیکیشن شخص ثالث یا Third-party application، برنامههایی هستند که مستقیماً متعلق به سرویسدهنده (مثل Google یا Facebook) نیستند، اما میخواهند با اجازه کاربر به اطلاعات آن کاربر که در آن سرویس نگهداری میشود دسترسی پیدا کنند.
مثلاً:
- یک اپلیکیشن مدیریت کارهای روزانه که میخواهد از تقویم گوگل شما استفاده کند.
- یا اپلیکیشنی که میخواهد به فایلهای Google Drive شما دسترسی پیدا کند.
📌 اجزای اصلی در OAuth 2.0:
- Resource Owner (مالک منبع)
کاربری است که اجازه دسترسی به اطلاعات یا منابع خود را صادر میکند. - Client (کلاینت یا اپلیکیشن شخص ثالث)
اپلیکیشنی است که میخواهد به اطلاعات کاربر دسترسی داشته باشد. قبل از دسترسی باید مجوز کاربر را کسب کند و این مجوز باید توسط API اعتبارسنجی شود. - Resource Server (سرور منبع)
منبع حفاظتشده (مثلاً اطلاعات پروفایل کاربر) روی این سرور قرار دارد. - Authorization Server (سرور احراز مجوز)
وظیفه این سرور احراز هویت کاربر و صدور «Access Token» برای کلاینت است.
🔄 نحوه کارکرد OAuth 2.0 به صورت مرحلهای:
- درخواست دسترسی: Authorization Request
اپلیکیشن از کاربر درخواست دسترسی به اطلاعاتش میکند. کاربر باید انتخاب کند که اجازه دسترسی بدهد یا نه. - موافقت کاربر و دریافت Authorization Grant:
اگر کاربر اجازه دهد، اپلیکیشن یک Authorization Grant دریافت میکند.
🔸 این grant در واقع یک مجوز موقت و رمزنگاریشده است که نشان میدهد کاربر اجازه دسترسی داده.
اپلیکیشن نمیتواند مستقیماً از آن برای دسترسی استفاده کند، بلکه باید از آن برای گرفتن Access Token استفاده کند. - درخواست Access Token:
اپلیکیشن با استفاده از Authorization Grant و اطلاعات شناسایی خودش (مثل client ID و client secret) از سرور احراز مجوز درخواست توکن میکند. - صدور Access Token:
اگر همهچیز معتبر باشد، سرور یک Access Token صادر میکند. - درخواست منبع از Resource Server:
اپلیکیشن با ارائهی Access Token به Resource Server، به اطلاعات مورد نظر کاربر دسترسی پیدا میکند.
🔸 مثلاً اگر مجوز فقط برای خواندن ایمیلها باشد، اپلیکیشن نمیتواند به مخاطبین دسترسی بگیرد.
✅ این مرحله خیلی مهمه چون اطلاعات حساس کاربر فقط در صورتی ارائه میشن که توکن معتبر باشه و دسترسیها دقیقاً مطابق مجوز قبلی باشن.
📝 ثبت اپلیکیشن در سرویسدهنده
پیش از استفاده از OAuth، اپلیکیشن شما باید در سرویسدهندهای مثل Google، Facebook یا GitHub ثبت شود تا بتواند از مجوزهای مربوطه استفاده کند. در فرآیند ثبت، اطلاعاتی مثل redirect URI و client ID ساخته میشوند.
ما در این اموزش به بیان مفاهیم کلی پرداختیم ، اما به صورت عملی آموزشی برای این مطلب تهیه شده است : احراز هویت در اپلیکیشن اندروید
🧾 OpenID Connect چیست؟
OpenID Connect یک لایهی احراز هویت (Authentication Layer) است که بر روی OAuth 2.0 ساخته شده.
به عبارت ساده:
- OAuth 2.0 بیشتر دربارهی “دسترسی” به منابع کاربر است.
- اما OpenID Connect دربارهی “شناختن هویت کاربر” است.
🔍 یعنی چی که روی OAuth ساخته شده؟
OpenID Connect از زیرساخت و مراحل OAuth استفاده میکند (مثل توکن و تأیید کاربر) اما هدفش اینه که به جای دسترسی به منابع، هویت کاربر رو به اپلیکیشن اطلاع بده.
بهطور معمول وقتی از طریق Google وارد یک اپلیکیشن میشوید، این احراز هویت توسط OpenID Connect انجام شده و اطلاعاتی مثل:
- نام
- ایمیل
- شناسهی کاربر
در قالب یک ID Token (معمولاً از نوع JWT) به اپلیکیشن برمیگرده.
🎫 تفاوت Access Token و ID Token:
نوع توکن | کاربرد | استفاده در |
Access Token | مجوز دسترسی به APIها یا منابع | OAuth 2.0 |
ID Token | اطلاعات هویتی کاربر | OpenID Connect |
🆚 تفاوتهای کلیدی بین OAuth 2.0 و OpenID Connect
ویژگی | OAuth 2.0 | OpenID Connect |
هدف | دسترسی به منابع | احراز هویت کاربر |
توکن مورد استفاده | Access Token | ID Token |
اطلاعات دریافتی | مجوز دسترسی | اطلاعات هویتی (مثلاً نام و ایمیل) |
🗣 نتیجهگیری
- اگر هدف شما صدور مجوز دسترسی به منابع است → از OAuth 2.0 استفاده کنید.
- اگر هدف شما احراز هویت و ورود با حسابهای دیگر است → از OpenID Connect استفاده کنید.
بخش پایانی : نتیجه گیری
اگر دوباره این متن ای که در مقدمه بیان شد رو بخونیم :
در ارتباط میان کاربر و سرور، توکنها نقش مهمی در تایید هویت و کنترل سطح دسترسی ایفا میکنند. به طور معمول، ما ID Token را از سرویسهایی مثل گوگل دریافت کرده و بخشی از آن را به سمت سرور خود ارسال میکنیم تا کاربر تایید شود و بتوانیم سطح دسترسی مناسب را به او اختصاص دهیم.
هنگامی که کاربر اقدام به ثبت نام در اپلیکیشن میکند، ID Token به سمت دیتابیس یا سرور ارسال میشود. این توکن از طرف گوگل صادر شده و برای تایید هویت کاربر و ارائه سطح دسترسی استفاده میشود. ID Token بر پایه استاندارد OpenID Connect طراحی شده است که یک استاندارد جهانی محسوب میشود و در بسیاری از سرویسها مانند گوگل، توییتر و فیسبوک مورد استفاده قرار میگیرد.
الان تمامی مفاهیم ای که داخل این متن نوشته شده است رو میتونیم متوجه بشیم که هدف ما از این اموزش این بود که یه اطلاعات نسبی نسبت به سیستم ثبت نام امن که امروزه در بیشتر دستگاها استفاده میشه کسب کنیم
امیدوارم این آموزش مورد توجه شما قرار گرفته باشه ، از کد زدن لذت ببرید ، پایان . 🍉