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 (সার্ভার উপাদান সহ মোবাইল এবং ওয়েব অ্যাপ্লিকেশনের জন্য সবচেয়ে নিরাপদ), Authorization Code with PKCE (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) জন্য। ব্যবহারকারী অন্য ডিভাইসে একটি লিঙ্ক অনুসরণ করে এবং একটি কোড প্রবেশ করে। উদাহরণস্বরূপ, স্মার্টফোনের মাধ্যমে টিভিতে 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 চুরি এবং ইন্টেন্ট আটকানোর মাধ্যমে ক্লায়েন্ট প্রতিরূপণ।

এই আক্রমণগুলির বিরুদ্ধে সুরক্ষায় বাধ্যতামূলক ব্যবস্থা অন্তর্ভুক্ত: (1) S256 code_challenge সহ PKCE: URI স্কিম আটকানো হলেও authorization code আটকানো প্রতিরোধ করে; (2) CSRF প্রতিরোধ করতে nonce বা state প্যারামিটার ব্যবহার: সার্ভার যাচাই করে যে authorization code মূল অনুরোধের সাথে মেলে; (3) শুধুমাত্র KeyStore (Android) বা Keychain (iOS)-এ Refresh Token সংরক্ষণ: 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 endpoint) স্বয়ংক্রিয়ভাবে অনুমোদন সার্ভারের সঠিক এন্ডপয়েন্ট নির্ধারণ করতে এবং ফিশিং পৃষ্ঠাগুলিতে রিডাইরেক্ট এড়াতে সাহায্য করে।