OAuth 2.0: یہ کیا ہے اور اجازت پروٹوکول کیسے کام کرتا ہے

OAuth 2.0 کیا ہے؟

OAuth 2.0 ایک اجازت پروٹوکول ہے جو IETF RFC 6749 میں بیان کیا گیا ہے، جو فریق ثالث ایپلیکیشنز کو صارف کا صارف نام اور پاس ورڈ ظاہر کیے بغیر اس کے وسائل تک محدود رسائی حاصل کرنے کی اجازت دیتا ہے۔ یہ پروٹوکول پاس ورڈ ماڈل کے ایک بنیادی مسئلے کو حل کرتا ہے: ایک ایپلیکیشن جسے آپ اپنا پاس ورڈ سونپتے ہیں، اسے تمام اکاؤنٹ ڈیٹا تک لامحدود رسائی مل جاتی ہے۔ OAuth 2.0 واضح طور پر محدود رسائی کے دائرہ کار کے ساتھ ایک عارضی ٹوکن جاری کرکے اس نقطہ نظر کو بدل دیتا ہے۔

OAuth 2.0 کا فن تعمیر وفد کردہ اجازت ہے۔ صارف (Resource Owner) ایک درمیانی: اجازت سرور (Authorization Server) کے ذریعے وسائل سرور (Resource Server) پر محفوظ اپنے ڈیٹا تک رسائی کے لیے ایک ایپلیکیشن (Client) کو اجازت دیتا ہے۔ اجازت سرور ایک Access Token جاری کرتا ہے: ایک خفیہ نگاری کا سٹرنگ جسے ایپلیکیشن ڈیٹا تک رسائی کے لیے وسائل سرور کو پیش کرتی ہے۔ OAuth 2.0 اور SAML یا OpenID Connect کے درمیان ایک اہم فرق: OAuth 2.0 اجازت کے کام (کیا اجازت ہے) کو حل کرتا ہے، تصدیق (صارف کون ہے) کو نہیں۔ تصدیق کے لیے OAuth 2.0 کے اوپر OpenID Connect (OIDC) پروٹوکول بنایا گیا ہے۔

یہ پروٹوکول تمام بڑے پلیٹ فارمز کے ذریعے تعاون یافتہ ہے۔ Google Google APIs (Gmail، Drive، Calendar) تک رسائی کے لیے OAuth 2.0 استعمال کرتا ہے، Facebook Graph API کے لیے، Apple Sign in with Apple (ASAuthorizationAppleIDProvider) کے لیے، اور GitHub ذخیروں تک رسائی کے لیے۔ موبائل ڈیولپمنٹ کے سیاق و سباق میں، OAuth 2.0 فریق ثالث خدمات کو ضم کرنے کا معیاری طریقہ کار ہے: سوشل نیٹ ورکس کے ذریعے لاگ ان، کلاؤڈ اسٹوریج تک رسائی، اور صارف کی جانب سے مواد شائع کرنا۔

OAuth 2.0 کے کردار اور اجزاء

OAuth 2.0 پروٹوکول چار کرداروں کی وضاحت کرتا ہے جن کا تعامل مکمل اجازت کا چکر تشکیل دیتا ہے۔ موبائل ایپلیکیشن میں پروٹوکول کو صحیح طریقے سے لاگو کرنے کے لیے ہر کردار کو سمجھنا ضروری ہے۔

پروٹوکول کے چار کردار

پروٹوکول کی کلیدی ہستیاں Access Token، Refresh Token اور Authorization Code ہیں۔ Access Token ایک قلیل المدت ٹوکن ہے (عام طور پر 15–60 منٹ) جو ہر ڈیٹا کی درخواست کے ساتھ وسائل سرور کو پیش کیا جاتا ہے۔ Refresh Token ایک طویل المدت ٹوکن ہے (دن یا ہفتے) جو صارف کے دوبارہ لاگ ان کیے بغیر نیا Access Token حاصل کرنے کے لیے استعمال ہوتا ہے۔ Authorization Code ایک عارضی کوڈ ہے جو صارف کی اجازت کے بعد جاری کیا جاتا ہے اور Access Token اور Refresh Token کے لیے تبدیل کیا جاتا ہے۔

Grant Types: اجازت کے منظرنامے

OAuth 2.0 کئی Grant Types کی وضاحت کرتا ہے: ٹوکن حاصل کرنے کے منظرنامے، ہر ایک ایک مخصوص کلائنٹ کی قسم اور سیکیورٹی سیاق و سباق کے لیے ڈیزائن کیا گیا ہے۔ موبائل ایپلیکیشن میں اجازت ڈیزائن کرتے وقت صحیح Grant Type کا انتخاب ایک اہم معماری فیصلہ ہے۔

اہم Grant Types یہ ہیں: Authorization Code (سرور کے جزو کے ساتھ موبائل اور ویب ایپلیکیشنز کے لیے سب سے محفوظ)، PKCE کے ساتھ Authorization Code (Proof Key for Code Exchange: سرور بیک اینڈ کے بغیر موبائل اور SPA ایپلیکیشنز کے لیے)، Client Credentials (صارف کی شرکت کے بغیر سرور سے سرور کی تصدیق کے لیے)، Resource Owner Password Credentials (متروک: براہ راست پاس ورڈ منتقل کرتا ہے)۔ OAuth Security BCP (RFC 9700) کی سفارشات کے مطابق PKCE عوامی کلائنٹس (موبائل ایپلیکیشنز، SPA) کے لیے لازمی توسیع ہے۔

اہم Grant Types

• Authorization Code + PKCE مقامی موبائل ایپلیکیشنز کے لیے تجویز کردہ Grant Type ہے۔ کلائنٹ ایک خفیہ نگاری کا code_verifier تیار کرتا ہے، code_challenge (SHA-256 ہیش) کا حساب لگاتا ہے، اور سرور ٹوکن کے لیے کوڈ کے تبادلے پر مماثلت کی تصدیق کرتا ہے۔ یہ ایپلیکیشن اور سرور کے درمیان authorization code کی روک تھام کو روکتا ہے
• Client Credentials مشین سے مشین کی اجازت کے لیے استعمال ہوتا ہے جہاں کلائنٹ معروف اور تصدیق شدہ ہے۔ ایپلیکیشن اپنے client_id اور client_secret کا استعمال کرتے ہوئے ٹوکن حاصل کرتی ہے۔ صارف کی شرکت کی ضرورت نہیں۔ عام منظر نامہ: ایک سرور ایپلیکیشن بیچ ڈیٹا پروسیسنگ کے لیے API کو کال کرتی ہے
• Device Authorization Grant براؤزر کے بغیر آلات (Smart TV، IoT) کے لیے ہے۔ صارف کسی دوسرے آلے پر ایک لنک کی پیروی کرتا ہے اور کوڈ درج کرتا ہے۔ مثال کے طور پر، اسمارٹ فون کے ذریعے TV پر Netflix کو اجازت دیتے وقت استعمال ہوتا ہے
• Resource Owner Password Credentials ایک متروک Grant Type ہے جو OAuth Security BCP کے ذریعے ممنوع ہے۔ پاس ورڈ براہ راست کلائنٹ کو منتقل کیا جاتا ہے، جو صفر علمی تصدیق کے اصول کی خلاف ورزی کرتا ہے۔ صرف میراثی نظاموں سے منتقلی کے لیے استعمال ہوتا ہے

موبائل ایپلیکیشنز کے لیے PKCE کے ساتھ Authorization Code Flow

PKCE کے ساتھ Authorization Code Flow مقامی موبائل ایپلیکیشنز کے لیے تجویز کردہ OAuth 2.0 ترتیب ہے۔ PKCE (Proof Key for Code Exchange) تحفظ کی ایک اضافی تہہ شامل کرتا ہے جو authorization code کی روک تھام کے حملوں کو روکتا ہے۔ پروٹوکول IETF RFC 7636 میں بیان کیا گیا ہے۔

PKCE قدم بہ قدم ترتیب

قدموں کی ترتیب: (1) کلائنٹ ایک بے ترتیب code_verifier تیار کرتا ہے (صرف غیر محفوظ کردہ حروف استعمال کرنے والی 43–128 حروف کی ایک سٹرنگ)، (2) کلائنٹ code_challenge = SHA-256(code_verifier) کا حساب لگاتا ہے، (3) کلائنٹ Authorization Server پر صارف کی اجازت کے لیے ایک براؤزر کھولتا ہے، code_challenge منتقل کرتا ہے، (4) کامیاب اجازت کے بعد، سرور ایک حسب ضرورت URI اسکیم (ایپ ڈیپ لنک) کے ذریعے ایپلیکیشن کو authorization code واپس کرتا ہے، (5) کلائنٹ authorization code + code_verifier سرور کو بھیجتا ہے، (6) سرور SHA-256(code_verifier) === code_challenge کی تصدیق کرتا ہے اور Access Token + Refresh Token جاری کرتا ہے۔

PKCE کا فائدہ: یہاں تک کہ اگر حملہ آور URI اسکیم میں authorization code کو روک لے، وہ code_verifier کے بغیر اسے ٹوکن کے لیے تبدیل نہیں کر سکتا، جو صرف جائز کلائنٹ کو معلوم ہے۔ موبائل ایپلیکیشنز میں، براؤزر کھولنے کے لیے Chrome Custom Tabs (Android) یا ASWebAuthenticationSession (iOS) استعمال کرنا چاہیے؛ یہ یقینی بناتا ہے کہ سسٹم براؤزر ایپلیکیشن کی میموری سے code_verifier تک رسائی حاصل نہیں کر سکتا۔

AppAuth کے ذریعے Android پر OAuth 2.0 کا نفاذ

AppAuth IETF کی تجویز کردہ، مقامی ایپلیکیشنز کے لیے OAuth 2.0 اور OpenID Connect کا حوالہ نفاذ ہے۔ لائبریری PKCE، Chrome Custom Tabs، authorization code واپس کرنے کے لیے حسب ضرورت URI اسکیمیں اور خودکار ٹوکن ریفریش کو سپورٹ کرتی ہے۔ Android کے لیے AppAuth `net.openid:appauth:0.11.1` انحصار کے ذریعے دستیاب ہے۔

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// اجازت کے لیے Chrome Custom Tab شروع کریں
startActivityForResult(intent, REQUEST_CODE_AUTH)

authorization code (onActivityResult) حاصل کرنے کے بعد، ایپلیکیشن اسے TokenRequest کے ذریعے Access Token اور Refresh Token میں تبدیل کرتی ہے۔ ٹوکن EncryptedSharedPreferences (Android Security Crypto) کے ذریعے خفیہ کاری کے ساتھ SharedPreferences میں محفوظ کیے جاتے ہیں۔ Refresh Token کو KeyStore میں محفوظ کیا جانا چاہیے: ایک ہارڈویئر پر مبنی کلید کا ذخیرہ جو دوسری ایپلیکیشنز کے لیے ناقابل رسائی ہے۔ ہر بار Access Token کی میعاد ختم ہونے پر، ایپلیکیشن نیا حاصل کرنے کے لیے Refresh Token استعمال کرتی ہے: صارف کو دوبارہ تصدیق کرنے کی ضرورت نہیں ہے۔

// authorization code کو ٹوکن میں تبدیل کریں
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token اور Refresh Token موصول ہوئے
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // EncryptedSharedPreferences میں محفوظ کریں
        saveTokens(accessToken, refreshToken)
    }
}

مندرجہ بالا کوڈ PKCE کے ساتھ مکمل OAuth 2.0 فلو کو ظاہر کرتا ہے: OpenID Connect Discovery کے ذریعے سرور کنفیگریشن بنانا، code_verifier کے ساتھ اجازت کی درخواست تیار کرنا، Chrome Custom Tab شروع کرنا، حسب ضرورت URI اسکیم کے ذریعے authorization code حاصل کرنا، اور Token Request کے ذریعے کوڈ کو ٹوکن میں تبدیل کرنا۔ Access Token کی میعاد ختم ہونے کو ہینڈل کرنا ضروری ہے: Resource Server سے HTTP 401 جواب ملنے پر، ایپلیکیشن کو نیا Access Token حاصل کرنے کے لیے Refresh Token استعمال کرنا چاہیے اور درخواست کو دوبارہ عمل میں لانا چاہیے۔

OAuth 2.0 سیکیورٹی: عام حملے اور تحفظ

OAuth 2.0 ایک پیچیدہ پروٹوکول ہے جس میں حملے کے بہت سے ویکٹر ہیں۔ IETF Security BCP (RFC 9700) OAuth 2.0 کمزوریوں کی 20 سے زیادہ کلاسوں کی وضاحت کرتا ہے۔ موبائل ایپلیکیشنز کے لیے، سب سے اہم ہیں: حسب ضرورت URI اسکیموں کے ذریعے authorization code کی روک تھام، کال بیک اینڈ پوائنٹس پر CSRF حملے، غیر محفوظ ذخیرہ سے Refresh Token کی چوری، اور intent روک تھام کے ذریعے کلائنٹ کی نقاب پوشی۔

ان حملوں کے خلاف تحفظ میں لازمی اقدامات شامل ہیں: (1) S256 code_challenge کے ساتھ PKCE: URI اسکیم کی روک تھام ہونے پر بھی authorization code کی روک تھام کو روکتا ہے؛ (2) CSRF کو روکنے کے لیے nonce یا state پیرامیٹر کا استعمال: سرور تصدیق کرتا ہے کہ authorization code اصل درخواست سے مطابقت رکھتا ہے؛ (3) Refresh Token کو صرف KeyStore (Android) یا Keychain (iOS) میں محفوظ کرنا: SharedPreferences یا UserDefaults میں کبھی نہیں؛ (4) ٹرانسپورٹ کی سطح پر MITM سے تحفظ کے لیے Certificate Pinning کے ساتھ TLS کا استعمال؛ (5) redirect_uri کی توثیق: اجازت سرور کو رجسٹرڈ URI کے ساتھ مماثلت کی سختی سے تصدیق کرنی چاہیے۔

IETF کی اضافی سفارشات: موبائل ایپلیکیشنز کو AppAuth یا اسی طرح کی لائبریریاں استعمال کرنی چاہئیں جو سیکیورٹی آڈٹ سے گزری ہوں؛ OAuth کے لیے WebView پر انحصار نہ کریں (WebView ڈیٹا کو مرکزی ایپلیکیشن سے الگ نہیں کرتا)؛ خودکار Refresh Token گردش لاگو کریں (ہر Refresh Token صرف ایک بار استعمال کیا جا سکتا ہے)؛ Android کے لیے TrustManager اور iOS کے لیے URLSession کے ذریعے Certificate Pinning شامل کریں۔ OpenID Connect Discovery (well-known اینڈ پوائنٹ) اجازت سرور کے صحیح اینڈ پوائنٹس خود بخود تعین کرنے اور فشنگ صفحات پر ری ڈائریکٹ سے بچنے میں مدد کرتا ہے۔