OpenID Connect: یہ کیا ہے، تصدیق اور اجازت نامہ پروٹوکول

OpenID Connect کیا ہے؟

OpenID Connect (OIDC) ایک کھلا تصدیقی پروٹوکول ہے جو OAuth 2.0 کے اوپر ایک توسیع کے طور پر بنایا گیا ہے۔ یہ اس چیز کو معیاری بناتا ہے جو OAuth 2.0 میں غائب تھی: صارف کی شناخت کی تصدیق۔ اگر OAuth 2.0 سوال کا جواب دیتا ہے “کس ایپلیکیشن تک رسائی ہے؟”، تو OIDC جواب دیتا ہے “یہ صارف اصل میں کون ہے؟”

پروٹوکول ایک ID Token — ایک JSON Web Token (JWT) جس میں دعوؤں کا ایک سیٹ ہوتا ہے: ایک منفرد موضوع شناخت کنندہ، ای میل، نام، اوتار، اجراء اور میعاد ختم ہونے کے ٹائم اسٹیمپ — استعمال کرتا ہے۔ کلائنٹ ایپلیکیشن ID Token کو خفیہ نگاری سے تصدیق کر سکتی ہے — سرور RS256 یا ES256 کا استعمال کرتے ہوئے ٹوکن پر دستخط کرتا ہے، اور کلائنٹ JWKS اینڈ پوائنٹ کے ذریعے حاصل کردہ عوامی کلید کے خلاف دستخط کی جانچ کرتا ہے۔

Auth0, 2025 کے مطابق، تیسرے فریق کی تصدیق استعمال کرنے والی 78% سے زیادہ موبائل ایپلیکیشنز Google Sign-In یا Sign in with Apple کے ذریعے OIDC استعمال کرتی ہیں۔ یہ پروٹوکول کو سماجی لاگ ان اور کاروباری تصدیق کے لیے حقیقی معیار بناتا ہے۔

OpenID Connect کیسے کام کرتا ہے

OpenID Connect کلائنٹ کی قسم کے لحاظ سے کئی بہاؤ (flows) کی وضاحت کرتا ہے۔ موبائل ایپلیکیشنز کے لیے، معیار Proof Key for Code Exchange (PKCE) کے ساتھ Authorization Code Flow ہے — یہ ڈیوائس پر client secret کے بغیر بھی تحفظ فراہم کرتا ہے۔

شناخت فراہم کنندہ اور اس کا کردار

شناخت فراہم کنندہ (IdP) ایک سرور ہے جو صارفین کی تصدیق کرتا ہے اور ٹوکن جاری کرتا ہے۔ OIDC ماحولیاتی نظام میں، IdP دو اہم اینڈ پوائنٹ فراہم کرتا ہے: صارف لاگ ان کے لیے Authorization Endpoint اور کوڈ کو ٹوکن سے تبدیل کرنے کے لیے Token Endpoint۔ کلائنٹ Discovery URL — معیاری راستہ /.well-known/openid-configuration — کے ذریعے ان اینڈ پوائنٹس کے پتے دریافت کرتا ہے، جو مکمل فراہم کنندہ ترتیب کے ساتھ JSON دستاویز واپس کرتا ہے۔

ہر IdP اپنا JWKS (JSON Web Key Set) شائع کرتا ہے — ID Token کے دستخط کی تصدیق کے لیے عوامی کلیدوں کا ایک سیٹ۔ کلائنٹ ان کلیدوں کو کیش کرتا ہے اور سرور سے رابطہ کیے بغیر موصول ہونے والے ہر ٹوکن کی تصدیق کے لیے استعمال کرتا ہے۔

PKCE کے ساتھ Authorization Code Flow

Authorization Code Flow تین مراحل پر مشتمل عمل ہے۔ پہلے، موبائل ایپلیکیشن ایک code verifier (43–128 حروف کی بے ترتیب سٹرنگ) اور اس کا ہیش — code challenge — پیدا کرتی ہے۔ ایپلیکیشن ایک براؤزر یا WebView کھولتی ہے جس میں client_id، redirect_uri، scope (openid profile email) اور code challenge پر مشتمل URL ہوتا ہے۔ صارف IdP صفحہ پر اسناد درج کرتا ہے اور رضامندی کی تصدیق کرتا ہے۔ IdP براؤزر کو authorization code کے ساتھ ایپلیکیشن پر واپس بھیج دیتا ہے۔

دوسرے مرحلے میں، ایپلیکیشن authorization code، code verifier اور client_id کو سرور کے Token Endpoint پر بھیجتی ہے۔ سرور code verifier کو ذخیرہ شدہ code challenge کے خلاف تصدیق کرتا ہے اور ID Token، Access Token اور اختیاری طور پر Refresh Token واپس کرتا ہے۔ تیسرے مرحلے میں، ایپلیکیشن ID Token کی تصدیق کرتی ہے: JWKS کے خلاف دستخط کی توثیق کرتی ہے، issuer (iss)، audience (aud) اور میعاد ختم ہونے کا وقت (exp) چیک کرتی ہے۔ اگر تصدیق کامیاب ہو جاتی ہے، تو صارف کو تصدیق شدہ سمجھا جاتا ہے۔

PKCE (Proof Key for Code Exchange) عوامی کلائنٹس میں معیاری Authorization Code Flow میں موجود کمزوری کو ختم کرتا ہے۔ چونکہ موبائل ایپلیکیشن client secret کو محفوظ طریقے سے ذخیرہ نہیں کر سکتی، authorization code کو روکنے والا حملہ آور اسے ٹوکن سے تبدیل کر سکتا ہے۔ Code verifier اس مسئلے کو حل کرتا ہے: چاہے کوڈ روک لیا جائے، اصل code verifier کے بغیر تبادلہ ناممکن ہے۔ OAuth Security Best Practices (RFC 9700) موبائل ایپلیکیشنز سمیت تمام عوامی کلائنٹس کے لیے PKCE کی ضرورت ہے۔

ID Token اور Access Token

OpenID Connect دو بنیادی طور پر مختلف ٹوکن واپس کرتا ہے: ID Token اور Access Token۔ ID Token ہمیشہ ایک JWT ہوتا ہے جسے کلائنٹ خود پڑھ اور تصدیق کر سکتا ہے۔ اس میں صارف کی معلومات ہوتی ہیں اور یہ API رسائی کے لیے نہیں بلکہ تصدیق کے لیے استعمال ہوتا ہے۔

ID Token کی ساخت

ID Token ایک header، payload اور signature پر مشتمل ہوتا ہے، جو Base64 میں انکوڈ اور نقطوں سے الگ ہوتے ہیں۔ Header میں alg (دستخط الگورتھم) اور kid (کلید شناخت کنندہ) ہوتا ہے۔ Payload میں لازمی دعوے شامل ہیں: iss (issuer)، sub (subject — منفرد صارف ID)، aud (audience — کلائنٹ شناخت کنندہ)، exp (expiration)، iat (issued at)۔ اختیاری دعووں میں name، email، picture، locale شامل ہیں۔

Google سے ڈی کوڈ کردہ ID Token payload کی مثال:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

Access Token ایک مبہم ٹوکن (صوابدیدی سٹرنگ) یا JWT ہے جسے کلائنٹ API درخواستوں میں بھیجتا ہے۔ ID Token کے برعکس، access token کلائنٹ کے پڑھنے کے لیے نہیں ہے — اس کی شکل اور مواد صرف وسائل سرور اور اجازت نامہ سرور کو معلوم ہوتے ہیں۔ Access Token کا ایک دائرہ کار (scope) — اجازت کی پابندی — اور ایک مختصر زندگی ہوتی ہے، عام طور پر 15–60 منٹ۔

OpenID Connect اور OAuth 2.0 کے درمیان فرق

OAuth 2.0 ایک اجازت نامہ کا فریم ورک ہے جو یہ بتاتا ہے کہ ایپلیکیشن صارف کے وسائل تک رسائی کیسے حاصل کرتی ہے۔ OpenID Connect ایک توسیع ہے جو اس عمل میں تصدیق شامل کرتی ہے۔ اہم فرق: OAuth 2.0 ٹوکن کی شکل کی وضاحت نہیں کرتا اور ایپلیکیشن کو یہ جاننے کا طریقہ نہیں دیتا کہ درخواست اصل میں کس نے کی۔

OpenID Connect کب منتخب کریں

OpenID Connect ضروری ہے جب ایپلیکیشن کو صارف کے ڈیٹا تک رسائی حاصل کرنے کے بجائے صارف کی شناخت کرنے کی ضرورت ہو۔ اگر آپ “Google سے سائن ان” یا “Apple سے سائن ان” استعمال کرتے ہیں — یہ OIDC ہے۔ اگر آپ کی ایپلیکیشن صارف کی شناخت جانے بغیر اس کی طرف سے تیسرے فریق کی API کو کال کرتی ہے — خالص OAuth 2.0 کافی ہے۔ Single Sign-On (SSO) والے کاروباری نظاموں کے لیے، انتخاب واضح ہے: صرف OpenID Connect، کیونکہ یہ معیاری لاگ آؤٹ اور سیشن مینجمنٹ فراہم کرتا ہے۔

موبائل ایپلیکیشنز میں OpenID Connect کا نفاذ

OpenID Connect کو موبائل ایپلیکیشن میں ضم کرنے کے لیے صحیح لائبریری کا انتخاب اور بہاؤ کی درست ترتیب ضروری ہے۔ Android کے لیے، اسناد مینیجر (AndroidX Credentials) یا AppAuth لائبریری استعمال کریں۔ iOS کے لیے، ASWebAuthenticationSession کے ساتھ AuthenticationServices فریم ورک استعمال کریں۔

Kotlin کوڈ کی مثال (Android)

ذیل میں AppAuth-Android لائبریری کا استعمال کرتے ہوئے Authorization Code Flow شروع کرنے کی ایک مثال ہے۔ ایپلیکیشن ایک اجازت نامہ کی درخواست بناتی ہے، صارف لاگ ان کے لیے براؤزر کھولتی ہے، اور ٹوکن کے ساتھ کال بیک پر کارروائی کرتی ہے۔

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Swift کوڈ کی مثال (iOS)

Apple کا ASWebAuthenticationSession iCloud Keychain کے ذریعے SSO تعاون کے ساتھ OIDC بہاؤ کے لیے ایک بلٹ ان براؤزر فراہم کرتا ہے۔ سیشن اجازت نامہ URL کے ساتھ شروع ہوتا ہے، اور کال بیک کو completion handler کے ذریعے سنبھالا جاتا ہے۔

OpenID Connect کے لیے لائبریری کا انتخاب کرتے وقت، بلٹ ان PKCE تعاون پر غور کریں: AppAuth-Android اور AppAuth-iOS ڈیفالٹ طور پر PKCE کو سپورٹ کرتی ہیں۔ Firebase Authentication Google Sign-In، Sign in with Apple اور Microsoft کے لیے اندرونی طور پر OIDC استعمال کرتا ہے „ ڈویلپر کو دستی طور پر بہاؤ لاگو کرنے کی ضرورت نہیں ہے۔ کسٹم IdP (مثال کے طور پر، Keycloak یا Okta) والے کاروباری نظاموں کے لیے، AppAuth ترتیب اور خرابی سے نمٹنے پر مکمل کنٹرول کے ساتھ معیاری انتخاب ہے۔

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()