OpenID Connect: এটি কী, প্রমাণীকরণ এবং অনুমোদন প্রোটোকল

OpenID Connect কী?

OpenID Connect (OIDC) হল একটি উন্মুক্ত প্রমাণীকরণ প্রোটোকল যা OAuth 2.0-এর উপরে একটি এক্সটেনশন হিসাবে নির্মিত। এটি OAuth 2.0-এ যা অনুপস্থিত ছিল তা প্রমিত করে: ব্যবহারকারী পরিচয় যাচাই। যদি OAuth 2.0 প্রশ্নের উত্তর দেয় “কোন অ্যাপ্লিকেশনের অ্যাক্সেস আছে?”, তাহলে OIDC উত্তর দেয় “এই ব্যবহারকারী আসলে কে?”

প্রোটোকলটি একটি ID Token — একটি JSON Web Token (JWT) যা claims-এর একটি সেট ধারণ করে: একটি অনন্য বিষয় শনাক্তকারী, ইমেল, নাম, অবতার, ইস্যু এবং মেয়াদ শেষ হওয়ার টাইমস্ট্যাম্প — ব্যবহার করে। ক্লায়েন্ট অ্যাপ্লিকেশন ক্রিপ্টোগ্রাফিকভাবে 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 ছাড়াও সুরক্ষা প্রদান করে।

Identity Provider এবং এর ভূমিকা

Identity Provider (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 পৃষ্ঠায় credentials প্রবেশ করান এবং সম্মতি নিশ্চিত করেন। IdP ব্রাউজারটিকে একটি authorization code-সহ অ্যাপ্লিকেশনে ফিরিয়ে redirect করে।

দ্বিতীয় ধাপে, অ্যাপ্লিকেশনটি 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-এ বাধ্যতামূলক claims অন্তর্ভুক্ত: iss (issuer), sub (subject — অনন্য ব্যবহারকারী ID), aud (audience — ক্লায়েন্ট শনাক্তকারী), exp (expiration), iat (issued at)। ঐচ্ছিক claims-এর মধ্যে 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-এর জন্য, credential manager (AndroidX Credentials) বা AppAuth লাইব্রেরি ব্যবহার করুন। iOS-এর জন্য, ASWebAuthenticationSession-সহ AuthenticationServices ফ্রেমওয়ার্ক ব্যবহার করুন।

Kotlin কোড উদাহরণ (Android)

নীচে AppAuth-Android লাইব্রেরি ব্যবহার করে Authorization Code Flow শুরু করার একটি উদাহরণ দেওয়া হল। অ্যাপ্লিকেশনটি একটি অনুমোদন অনুরোধ তৈরি করে, ব্যবহারকারী লগইনের জন্য একটি ব্রাউজার খোলে এবং টোকেন-সহ callback প্রক্রিয়া করে।

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-এর সাথে শুরু হয় এবং callback একটি 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()