আইডেন্টিটি প্রোভাইডার সাইডে FedCM এর সাথে একটি আইডেন্টিটি সল্যুশন বাস্তবায়ন করুন

FedCM বাস্তবায়নে Identity Provider (IdP) এবং Relying Party (RP) উভয়ের জন্যই বেশ কয়েকটি মূল ধাপ অন্তর্ভুক্ত রয়েছে। RP- এর পক্ষ থেকে FedCM কীভাবে বাস্তবায়ন করবেন তা জানতে ডকুমেন্টেশনটি দেখুন।

FedCM বাস্তবায়নের জন্য IdP গুলিকে নিম্নলিখিত পদক্ষেপগুলি সম্পন্ন করতে হবে:

1. একটি সুপরিচিত ফাইল তৈরি করুন।
2. একটি কনফিগারেশন ফাইল তৈরি করুন।
3. নিম্নলিখিত এন্ডপয়েন্টগুলি তৈরি করুন:
   • অ্যাকাউন্টের শেষ বিন্দু
   • আইডি অ্যাসারশন এন্ডপয়েন্ট
   • [ঐচ্ছিক] এন্ডপয়েন্ট সংযোগ বিচ্ছিন্ন করুন
   • [ঐচ্ছিক] ক্লায়েন্ট মেটাডেটা এন্ডপয়েন্ট
   • লগইন এন্ডপয়েন্ট
4. ব্যবহারকারীর লগইন অবস্থা সম্পর্কে ব্রাউজারকে অবহিত করুন।

একটি সুপরিচিত ফাইল তৈরি করুন

ট্র্যাকারদের API অপব্যবহার থেকে বিরত রাখতে, IdP-এর eTLD+1 এর /.well-known/web-identity থেকে একটি সুপরিচিত ফাইল পরিবেশন করতে হবে।

সুপরিচিত ফাইলটিতে নিম্নলিখিত বৈশিষ্ট্যগুলি অন্তর্ভুক্ত থাকতে পারে:

উদাহরণস্বরূপ, যদি IdP এন্ডপয়েন্টগুলি https://accounts.idp.example/ এর অধীনে পরিবেশিত হয়, তাহলে তাদের https://idp.example/.well-known/web-identity এ একটি সুপরিচিত ফাইলের পাশাপাশি একটি IdP কনফিগারেশন ফাইল পরিবেশন করতে হবে। এখানে সুপরিচিত ফাইলের একটি উদাহরণ দেওয়া হল:

  {
    "provider_urls": ["https://accounts.idp.example/config.json"]
  }

IdP গুলি একটি IdP এর জন্য একাধিক কনফিগারেশন ফাইল সমন্বিত করতে পারে, সুপরিচিত ফাইলে accounts_endpoint এবং login_url উল্লেখ করে। এই বৈশিষ্ট্যটি এই ক্ষেত্রে কার্যকর হতে পারে:

• একটি আইডিপি-কে একাধিক ভিন্ন পরীক্ষা এবং উৎপাদন কনফিগারেশন সমর্থন করতে হবে।
• একটি IdP-কে প্রতিটি অঞ্চলের জন্য বিভিন্ন কনফিগারেশন সমর্থন করতে হবে (উদাহরণস্বরূপ, eu-idp.example এবং us-idp.example )।

একাধিক কনফিগারেশন সমর্থন করার জন্য (উদাহরণস্বরূপ, পরীক্ষা এবং উৎপাদন পরিবেশের মধ্যে পার্থক্য করার জন্য), IdP-কে অবশ্যই accounts_endpoint এবং login_url উল্লেখ করতে হবে:

  {
    // This property is required, but will be ignored when IdP supports
    // multiple configs (when `accounts_endpoint` and `login_url` are
    // specified), as long as `accounts_endpoint` and `login_url` in
    // that config file match those in the well-known file.
    "provider_urls": [ "https://idp.example/fedcm.json" ],

    // Specify accounts_endpoint and login_url properties to support
    // multiple config files.
    // Note: The accounts_endpoint and login_url must be identical
    // across all config files. Otherwise,
    // the configurations won't be supported.
    "accounts_endpoint": "https://idp.example/accounts",
    "login_url": "https://idp.example/login"
  }

একটি আইডিপি কনফিগারেশন ফাইল এবং এন্ডপয়েন্ট তৈরি করুন

IdP কনফিগ ফাইলটি ব্রাউজারের জন্য প্রয়োজনীয় এন্ডপয়েন্টগুলির একটি তালিকা প্রদান করে। IdP গুলিতে অবশ্যই এক বা একাধিক কনফিগ ফাইল এবং প্রয়োজনীয় এন্ডপয়েন্ট এবং URL হোস্ট করতে হবে। সমস্ত JSON প্রতিক্রিয়া অবশ্যই application/json content-type এর সাথে পরিবেশিত হতে হবে।

কনফিগ ফাইলের URL নির্ধারিত হয় RP-তে সম্পাদিত navigator.credentials.get() কলে প্রদত্ত মান দ্বারা। RP প্রতিটি পরিচয় প্রদানকারীর জন্য কনফিগ ফাইলের URL পাস করবে:

  // Executed on RP's side:
  try {
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // To allow users to sign in with the IdP1 using FedCM, RP specifies the IdP's config file URL:
            configUrl: 'https://idp1.example/foo.json', // first IdP
            clientId: '123',
          },
          // To allow users to sign in with the IdP2 using FedCM, RP specifies the IdP's config file URL.
          // Note that multiple IdPs in a single get() are supported from Chrome 136.
          {
            configUrl: 'https://idp2.example/bar.json', // second IdP
            clientId: '456',
          },
        ],
      },
    });

    const token = credential.token;
    // Get the current IdP's configURL to identify which provider the user is signed in with
    const currentIdpConfigUrl = credential.configURL;
    if (currentIdpConfigUrl === 'https://idp1.example/foo.json') {
      // handle the case where the user signed in with idp1
    } else if (currentIdpConfigUrl === 'https://idp2.example/bar.json') {
      // handle the case where the user signed in with idp2
    }
  } catch (error) {
    // handle error
  }

ব্রাউজারটি GET অনুরোধের সাথে কনফিগ ফাইলটি আনবে, যার মধ্যে Origin হেডার বা Referer হেডার থাকবে না। অনুরোধটিতে কুকিজ নেই এবং পুনঃনির্দেশনা অনুসরণ করে না। এটি কার্যকরভাবে IdP কে জানতে বাধা দেয় যে অনুরোধটি কে করেছে এবং কোন RP সংযোগ করার চেষ্টা করছে। উদাহরণস্বরূপ:

  GET /config.json HTTP/1.1
  Host: accounts.idp.example
  Accept: application/json
  Sec-Fetch-Dest: webidentity

IdP-কে অবশ্যই একটি কনফিগ এন্ডপয়েন্ট বাস্তবায়ন করতে হবে যা JSON-এর সাথে সাড়া দেয়। JSON-এ নিম্নলিখিত বৈশিষ্ট্যগুলি অন্তর্ভুক্ত থাকে:

এখানে IdP থেকে একটি উদাহরণ প্রতিক্রিয়া অংশ দেওয়া হল:

  {
    "accounts_endpoint": "/accounts.example",
    "client_metadata_endpoint": "/client_metadata.example",
    "id_assertion_endpoint": "/assertion.example",
    "disconnect_endpoint": "/disconnect.example",
    "login_url": "/login",
    // When RPs use this config file, only those accounts will be
    //returned that include `developer` label in the accounts endpoint.
    "account_label": "developer",
    "supports_use_other_account": true,
    "branding": {
      "background_color": "green",
      "color": "#FFEEAA",
      "icons": [{
        "url": "https://idp.example/icon.ico",
        "size": 25
      }]
    }
  }

ব্রাউজারটি একবার কনফিগ ফাইলটি আনলে, এটি পরবর্তী অনুরোধগুলি IdP এন্ডপয়েন্টগুলিতে পাঠায়:

অন্য অ্যাকাউন্ট ব্যবহার করুন

যদি আইডিপি একাধিক অ্যাকাউন্ট সমর্থন করে অথবা বিদ্যমান অ্যাকাউন্টটি প্রতিস্থাপন করে, তাহলে ব্যবহারকারীরা তাদের লগ ইন করা অ্যাকাউন্ট থেকে ভিন্ন একটি অ্যাকাউন্টে স্যুইচ করতে পারবেন।

ব্যবহারকারীকে অন্যান্য অ্যাকাউন্ট বেছে নিতে সক্ষম করার জন্য, আইডিপিকে কনফিগ ফাইলে এই বৈশিষ্ট্যটি নির্দিষ্ট করতে হবে:

  {
    "accounts_endpoint" : "/accounts.example",
    "supports_use_other_account": true
  }

অ্যাকাউন্টের শেষ বিন্দু

আইডিপির অ্যাকাউন্টস এন্ডপয়েন্ট ব্যবহারকারীর আইডিপিতে সাইন ইন করা অ্যাকাউন্টগুলির একটি তালিকা প্রদান করে। যদি আইডিপি একাধিক অ্যাকাউন্ট সমর্থন করে, তাহলে এই এন্ডপয়েন্টটি সমস্ত সাইন ইন করা অ্যাকাউন্টগুলি প্রদান করবে।

ব্রাউজারটি SameSite=None দিয়ে কুকিজ সহ একটি GET অনুরোধ পাঠায়, কিন্তু client_id প্যারামিটার ছাড়াই, Origin হেডার বা Referer হেডার। এটি কার্যকরভাবে IdP কে ব্যবহারকারী কোন RP তে সাইন ইন করার চেষ্টা করছে তা জানতে বাধা দেয়। উদাহরণস্বরূপ:

  GET /accounts.example HTTP/1.1
  Host: accounts.idp.example
  Accept: application/json
  Cookie: 0x23223
  Sec-Fetch-Dest: webidentity

অনুরোধ পাওয়ার পর, সার্ভারের উচিত:

1. অনুরোধটিতে একটি Sec-Fetch-Dest: webidentity HTTP হেডার আছে কিনা তা যাচাই করুন।
2. ইতিমধ্যেই সাইন-ইন করা অ্যাকাউন্টগুলির আইডির সাথে সেশন কুকিজ মেলান।
3. অ্যাকাউন্টের তালিকা সহ উত্তর দিন।

ব্রাউজারটি একটি JSON প্রতিক্রিয়া আশা করে যার মধ্যে একটি accounts সম্পত্তি থাকবে যার মধ্যে নিম্নলিখিত বৈশিষ্ট্য সহ অ্যাকাউন্ট তথ্যের একটি অ্যারে থাকবে:

উদাহরণ প্রতিক্রিয়া মূল অংশ:

  {
    "accounts": [{
      "id": "1234",
      "given_name": "John",
      "name": "John Doe",
      "email": "john_doe@idp.example",
      "picture": "https://idp.example/profile/123",
      // Ids of those RPs where this account can be used
      "approved_clients": ["123", "456", "789"],
      // This account has 'login_hints`. When an RP calls `navigator.credentials.get()`
      // with a `loginHint` value specified, for example, `exampleHint`, only those
      // accounts will be shown to the user whose 'login_hints' array contains the `exampleHint`.
      "login_hints": ["demo1", "exampleHint"],
      // This account is labelled. IdP can implement a specific config file for a
      // label, for example, `https://idp.example/developer-config.json`. Like that
      // RPs can filter out accounts by calling `navigator.credentials.get()` with
      // `https://idp.example/developer-config.json` config file.
      "label_hints": ["enterprise", "developer"]
    }, {
      "id": "5678",
      "given_name": "Johnny",
      "name": "Johnny",
      "email": "johnny@idp.example",
      "picture": "https://idp.example/profile/456",
      "approved_clients": ["abc", "def", "ghi"],
      "login_hints": ["demo2"],
      "domain_hints": ["@domain.example"]
    }]
  }

যদি ব্যবহারকারী সাইন ইন না করে থাকেন, HTTP 401 (অননুমোদিত) দিয়ে উত্তর দিন।

ফিরে আসা অ্যাকাউন্ট তালিকাটি ব্রাউজার দ্বারা গ্রাস করা হয় এবং RP-এর কাছে উপলব্ধ হবে না।

আইডি অ্যাসারশন এন্ডপয়েন্ট

IdP এর ID অ্যাসারশন এন্ডপয়েন্ট তাদের সাইন-ইন করা ব্যবহারকারীর জন্য একটি অ্যাসারশন ফেরত দেয়। যখন ব্যবহারকারী navigator.credentials.get() call ব্যবহার করে একটি RP ওয়েবসাইটে সাইন ইন করেন, তখন ব্রাউজারটি SameSite=None সহ কুকিজ সহ একটি POST অনুরোধ এবং নিম্নলিখিত তথ্য সহ এই এন্ডপয়েন্টে application/x-www-form-urlencoded পাঠায়:

HTTP হেডারের উদাহরণ:

  POST /assertion.example HTTP/1.1
  Host: accounts.idp.example
  Origin: https://rp.example/
  Content-Type: application/x-www-form-urlencoded
  Cookie: 0x23223
  Sec-Fetch-Dest: webidentity

  // disclosure_text_shown is set to 'false', as the 'name' field value is missing in 'fields' array
  // params value is serialized to JSON and then percent-encoded.
  account_id=123&client_id=client1234&disclosure_text_shown=false&is_auto_selected=true&params=%22%7B%5C%22nonce%5C%22%3A%5C%22nonce-value%5C%22%7D%22.%0D%0A4&fields=email,picture&disclosure_shown_for=email,picture

অনুরোধ পাওয়ার পর, সার্ভারের উচিত:

1. CORS (ক্রস-অরিজিন রিসোর্স শেয়ারিং) ব্যবহার করে অনুরোধের জবাব দিন।
2. অনুরোধটিতে একটি Sec-Fetch-Dest: webidentity HTTP হেডার আছে কিনা তা যাচাই করুন।
3. client_id দ্বারা নির্ধারিত RP origin-এর সাথে Origin হেডারটি মেলান। যদি না মেলে তাহলে প্রত্যাখ্যান করুন।
4. ইতিমধ্যেই সাইন-ইন করা অ্যাকাউন্টের আইডির সাথে account_id মিলান। যদি না মেলে তাহলে প্রত্যাখ্যান করুন।
5. একটি টোকেন দিয়ে সাড়া দিন। যদি অনুরোধটি প্রত্যাখ্যান করা হয়, তাহলে একটি ত্রুটির প্রতিক্রিয়া দিয়ে সাড়া দিন।

আইডিপি সিদ্ধান্ত নিতে পারে যে তারা কীভাবে টোকেন ইস্যু করবে। সাধারণভাবে, এটি অ্যাকাউন্ট আইডি, ক্লায়েন্ট আইডি, ইস্যুকারীর উৎপত্তি এবং ননসের মতো তথ্য দিয়ে স্বাক্ষরিত হয়, যাতে আরপি টোকেনটি আসল কিনা তা যাচাই করতে পারে।

ব্রাউজারটি একটি JSON প্রতিক্রিয়া আশা করে যার মধ্যে নিম্নলিখিত বৈশিষ্ট্যগুলি অন্তর্ভুক্ত থাকবে:

ফিরে আসা টোকেনটি ব্রাউজার দ্বারা RP-তে পাঠানো হয়, যাতে RP প্রমাণীকরণটি যাচাই করতে পারে।

  {
    // IdP can respond with a token to authenticate the user
    "token": "***********"
  }

বৈশিষ্ট্যটিতে চালিয়ে যান

একাধিক ধাপে সাইন-ইন প্রবাহ সক্ষম করার জন্য আইডিপি আইডি অ্যাসারশন এন্ডপয়েন্ট প্রতিক্রিয়ায় একটি রিডাইরেক্ট URL প্রদান করতে পারে। এটি তখন কার্যকর যখন আইডিপিকে অতিরিক্ত তথ্য বা অনুমতির অনুরোধ করতে হয়, উদাহরণস্বরূপ:

• ব্যবহারকারীর সার্ভার-সাইড রিসোর্স অ্যাক্সেস করার অনুমতি।
• যোগাযোগের তথ্য হালনাগাদ আছে কিনা তা যাচাই করা।
• অভিভাবকীয় নিয়ন্ত্রণ।

আইডি অ্যাসারশন এন্ডপয়েন্ট একটি continue_on প্রোপার্টি রিটার্ন করতে পারে যার মধ্যে আইডি অ্যাসারশন এন্ডপয়েন্টের একটি পরম বা আপেক্ষিক পাথ অন্তর্ভুক্ত থাকে।

  {
    // In the id_assertion_endpoint, instead of returning a typical
    // "token" response, the IdP decides that it needs the user to
    // continue on a dialog window:
    "continue_on": "https://idp.example/continue_on_url"
  }

যদি প্রতিক্রিয়াটিতে continue_on প্যারামিটার থাকে, তাহলে একটি নতুন ডায়ালগ উইন্ডো খোলা হবে এবং ব্যবহারকারীকে নির্দিষ্ট পথে নিয়ে যাবে। continue_on পৃষ্ঠার সাথে ব্যবহারকারীর ইন্টারঅ্যাকশনের পরে, IdP-এর উচিত IdentityProvider.resolve() কল করা এবং টোকেনটি একটি আর্গুমেন্ট হিসেবে পাস করা উচিত যাতে মূল navigator.credentials.get() কলের প্রতিশ্রুতি সমাধান করা যায়:

  document.getElementById('example-button').addEventListener('click', async () => {
    let accessToken = await fetch('/generate_access_token.cgi');
    // Closes the window and resolves the promise (that is still hanging
    // in the relying party's renderer) with the value that is passed.
    IdentityProvider.resolve(accessToken);
  });

ব্রাউজারটি তখন স্বয়ংক্রিয়ভাবে ডায়ালগটি বন্ধ করে দেবে এবং API কলারে টোকেনটি ফেরত দেবে। প্যারেন্ট উইন্ডো (RP) এবং ডায়ালগ উইন্ডো (IdP) এর মধ্যে যোগাযোগের একমাত্র উপায় হল এককালীন IdentityProvider.resolve() কল।
যদি ব্যবহারকারী অনুরোধটি প্রত্যাখ্যান করে, তাহলে IdP IdentityProvider.close() কল করে উইন্ডোটি বন্ধ করতে পারে।

  IdentityProvider.close();

কন্টিনিউয়েশন এপিআই কার্যকরী করার জন্য স্পষ্ট ব্যবহারকারীর ইন্টারঅ্যাকশন (ক্লিক) প্রয়োজন। কন্টিনিউয়েশন এপিআই বিভিন্ন মেডিয়েশন মোডের সাথে কীভাবে কাজ করে তা এখানে দেওয়া হল:

• passive মোডে :
  • mediation: 'optional' (ডিফল্ট): কন্টিনিউয়েশন API শুধুমাত্র ব্যবহারকারীর অঙ্গভঙ্গির সাথে কাজ করবে, যেমন পৃষ্ঠার একটি বোতামে ক্লিক করা অথবা FedCM UI-তে। যখন ব্যবহারকারীর অঙ্গভঙ্গি ছাড়াই স্বয়ংক্রিয় পুনঃপ্রমাণীকরণ ট্রিগার করা হয়, তখন কোনও ডায়ালগ উইন্ডো খোলা হয় না এবং প্রতিশ্রুতি প্রত্যাখ্যান করা হয়।
  • mediation: 'required' : সর্বদা ব্যবহারকারীকে ইন্টারঅ্যাক্ট করতে বলে, তাই Continuation API সর্বদা কাজ করে।
• সক্রিয় মোডে :
  • ব্যবহারকারীর সক্রিয়করণ সর্বদা প্রয়োজন। কন্টিনিউয়েশন API সর্বদা সামঞ্জস্যপূর্ণ।

যদি কোনও কারণে ব্যবহারকারী ডায়ালগে তাদের অ্যাকাউন্ট পরিবর্তন করে (উদাহরণস্বরূপ, IdP "অন্য অ্যাকাউন্ট ব্যবহার করুন" ফাংশন অফার করে, অথবা ডেলিগেশান ক্ষেত্রে), তাহলে resolve কলটি একটি ঐচ্ছিক দ্বিতীয় যুক্তি গ্রহণ করে যা নিম্নলিখিতগুলির মতো কিছু অনুমোদন করে:

  IdentityProvider.resolve(token, {accountId: '1234');

একটি ত্রুটির প্রতিক্রিয়া জানান

id_assertion_endpoint একটি "error" প্রতিক্রিয়াও দিতে পারে, যার দুটি ঐচ্ছিক ক্ষেত্র রয়েছে:

• code : আইডিপি OAuth 2.0 নির্দিষ্ট ত্রুটি তালিকা থেকে পরিচিত ত্রুটিগুলির মধ্যে একটি বেছে নিতে পারে ( invalid_request , unauthorized_client , access_denied , server_error এবং temporarily_unavailable ) অথবা যেকোনো ইচ্ছামত স্ট্রিং ব্যবহার করতে পারে। যদি পরবর্তীটি হয়, তাহলে Chrome একটি জেনেরিক ত্রুটি বার্তা সহ ত্রুটি UI রেন্ডার করে এবং কোডটি RP-তে প্রেরণ করে।
• url : এটি ব্যবহারকারীদের ত্রুটি সম্পর্কে অতিরিক্ত তথ্য প্রদানের জন্য ত্রুটি সম্পর্কে তথ্য সহ একটি মানব-পঠনযোগ্য ওয়েব পৃষ্ঠা সনাক্ত করে। এই ক্ষেত্রটি ব্যবহারকারীদের জন্য কার্যকর কারণ ব্রাউজারগুলি একটি অন্তর্নির্মিত UI-তে সমৃদ্ধ ত্রুটি বার্তা সরবরাহ করতে পারে না। উদাহরণস্বরূপ: পরবর্তী পদক্ষেপের জন্য লিঙ্ক, অথবা গ্রাহক পরিষেবা যোগাযোগের তথ্য। যদি কোনও ব্যবহারকারী ত্রুটির বিবরণ এবং এটি কীভাবে ঠিক করবেন সে সম্পর্কে আরও জানতে চান, তাহলে তারা আরও বিশদের জন্য ব্রাউজার UI থেকে প্রদত্ত পৃষ্ঠাটি দেখতে পারেন। URLটি অবশ্যই IdP configURL এর মতো একই সাইটের হতে হবে।

  // id_assertion_endpoint response
  {
    "error" : {
      "code": "access_denied",
      "url" : "https://idp.example/error?type=access_denied"
    }
  }

কাস্টম অ্যাকাউন্ট লেবেল

কাস্টম অ্যাকাউন্ট লেবেল ব্যবহার করে, আইডিপি ব্যবহারকারীর অ্যাকাউন্টগুলিকে লেবেল সহ টীকা করতে পারে এবং RP সেই নির্দিষ্ট লেবেলের জন্য configURL নির্দিষ্ট করে শুধুমাত্র নির্দিষ্ট লেবেল সহ অ্যাকাউন্টগুলি আনতে বেছে নিতে পারে। এটি কার্যকর হতে পারে যখন কোনও RP-কে নির্দিষ্ট মানদণ্ড অনুসারে অ্যাকাউন্টগুলি ফিল্টার করতে হয়, উদাহরণস্বরূপ, শুধুমাত্র "developer" বা "hr" এর মতো ভূমিকা-নির্দিষ্ট অ্যাকাউন্টগুলি প্রদর্শন করতে।

ডোমেইন হিন্ট এবং লগইন হিন্ট বৈশিষ্ট্যগুলি ব্যবহার করে navigator.credentials.get() কলে নির্দিষ্ট করে একই রকম ফিল্টারিং সম্ভব। তবে, কাস্টম অ্যাকাউন্ট লেবেলগুলি কনফিগ ফাইল নির্দিষ্ট করে ব্যবহারকারীদের ফিল্টার করতে পারে, যা বিশেষ করে যখন একাধিক configURL ব্যবহার করা হয় তখন কার্যকর। কাস্টম অ্যাকাউন্ট লেবেলগুলিও আলাদা কারণ এগুলি IdP সার্ভার থেকে সরবরাহ করা হয়, যেমন RP থেকে, যেমন লগইন বা ডোমেন ইঙ্গিত।

"developer" এবং "hr" অ্যাকাউন্টের মধ্যে পার্থক্য করতে চায় এমন একটি IdP বিবেচনা করুন। এটি অর্জনের জন্য, IdP-কে যথাক্রমে "developer" এবং "hr" এর জন্য দুটি configURL সমর্থন করতে হবে:

• ডেভেলপার কনফিগারেশন ফাইল https://idp.example/developer/fedcm.json একটি "developer" লেবেল রয়েছে এবং এন্টারপ্রাইজ কনফিগারেশন ফাইল https://idp.example/hr/fedcm.json এ একটি "hr" লেবেল রয়েছে যা নিম্নরূপ:

  // The developer config file at `https://idp.example/developer/fedcm.json`
  {
    "accounts_endpoint": "https://idp.example/accounts",
    "client_metadata_endpoint": "/client_metadata",
    "login_url": "https://idp.example/login",
    "id_assertion_endpoint": "/assertion",
    "account_label": "developer"
  }

  // The hr config file at `https://idp.example/hr/fedcm.json`
  {
    "accounts_endpoint": "https://idp.example/accounts",
    "client_metadata_endpoint": "/client_metadata",
    "login_url": "https://idp.example/login",
    "id_assertion_endpoint": "/assertion",
    "account_label": "hr"
  }

• এই ধরনের সেটআপের মাধ্যমে, সুপরিচিত ফাইলটিতে accounts_endpoint এবং login_url অন্তর্ভুক্ত থাকা উচিত যাতে একাধিক configURL অনুমোদিত হয়:

  {
    "provider_urls": [ "https://idp.example/fedcm.json" ],
    "accounts_endpoint": "https://idp.example/accounts",
    "login_url": "https://idp.example/login"
  }

• সাধারণ IdP অ্যাকাউন্টের শেষ বিন্দু (এই উদাহরণে https://idp.example/accounts ) অ্যাকাউন্টগুলির একটি তালিকা প্রদান করে যার মধ্যে প্রতিটি অ্যাকাউন্টের জন্য একটি অ্যারেতে নির্ধারিত লেবেল সহ একটি label_hints সম্পত্তি অন্তর্ভুক্ত থাকে:

  {
  "accounts": [{
    "id": "123",
    "given_name": "John",
    "name": "John Doe",
    "email": "john_doe@idp.example",
    "picture": "https://idp.example/profile/123",
    "label_hints": ["developer"]
    }], [{
    "id": "4567",
    "given_name": "Jane",
    "name": "Jane Doe",
    "email": "jane_doe@idp.example",
    "picture": "https://idp.example/profile/4567",
    "label_hints": ["hr"]
    }]
  }

যখন কোনও RP "hr" ব্যবহারকারীদের সাইন ইন করার অনুমতি দিতে চায়, তখন তারা navigator.credentials.get() কলে configURL https://idp.example/hr/fedcm.json নির্দিষ্ট করতে পারে:

  let { token } = await navigator.credentials.get({
    identity: {
      providers: [{
        clientId: '1234',
        nonce: '234234',
        configURL: 'https://idp.example/hr/fedcm.json',
      },
    }
  });

ফলস্বরূপ, ব্যবহারকারীর সাইন ইন করার জন্য শুধুমাত্র 4567 এর অ্যাকাউন্ট আইডি উপলব্ধ থাকে। 123 এর অ্যাকাউন্ট আইডি ব্রাউজার দ্বারা নীরবে লুকানো থাকে যাতে ব্যবহারকারীকে এমন কোনও অ্যাকাউন্ট সরবরাহ না করা হয় যা এই সাইটের আইডিপি দ্বারা সমর্থিত নয়।

অতিরিক্ত বিবেচ্য বিষয়:

• লেবেলগুলি হল স্ট্রিং। যদি label_hints অ্যারে বা account_label ফিল্ড এমন একটি মান ব্যবহার করে যা স্ট্রিং নয়, তাহলে মানটি উপেক্ষা করা হয়।
• যদি configURL এ কোনও লেবেল নির্দিষ্ট না করা থাকে, তাহলে সমস্ত অ্যাকাউন্ট FedCM অ্যাকাউন্ট চয়নকারীতে প্রদর্শিত হবে।
• যদি কোনও অ্যাকাউন্টের জন্য কোনও লেবেল নির্দিষ্ট না করা থাকে, তাহলে এই অ্যাকাউন্টটি কেবল তখনই অ্যাকাউন্ট চয়নকারীতে প্রদর্শিত হবে যদি configURL কোনও লেবেল নির্দিষ্ট না করে।
• যদি প্যাসিভ মোডে (ডোমেন ইঙ্গিত বৈশিষ্ট্যের অনুরূপ) কোনও অ্যাকাউন্ট অনুরোধকৃত লেবেলের সাথে মেলে না, তাহলে FedCM ডায়ালগটি একটি লগইন প্রম্পট দেখায়, যা ব্যবহারকারীকে একটি IdP অ্যাকাউন্টে সাইন ইন করতে দেয়। সক্রিয় মোডের জন্য, লগইন ডায়ালগ উইন্ডোটি সরাসরি খোলা হয়।

এন্ডপয়েন্ট ডিসকানেক্ট করুন

IdentityCredential.disconnect() ব্যবহার করে, ব্রাউজারটি SameSite=None সহ কুকিজ সহ একটি ক্রস-অরিজিন POST অনুরোধ এবং নিম্নলিখিত তথ্য সহ এই ডিসকানেক্ট এন্ডপয়েন্টে application/x-www-form-urlencoded পাঠায়:

  POST /disconnect.example HTTP/1.1
  Host: idp.example
  Origin: rp.example
  Content-Type: application/x-www-form-urlencoded
  Cookie: 0x123
  Sec-Fetch-Dest: webidentity

  account_hint=account456&client_id=rp123

অনুরোধ পাওয়ার পর, সার্ভারের উচিত:

1. CORS (ক্রস-অরিজিন রিসোর্স শেয়ারিং) ব্যবহার করে অনুরোধের জবাব দিন।
2. অনুরোধটিতে একটি Sec-Fetch-Dest: webidentity HTTP হেডার আছে কিনা তা যাচাই করুন।
3. client_id দ্বারা নির্ধারিত RP origin-এর সাথে Origin হেডারটি মেলান। যদি না মেলে তাহলে প্রত্যাখ্যান করুন।
4. ইতিমধ্যেই সাইন-ইন করা অ্যাকাউন্টগুলির আইডির সাথে account_hint মিলান।
5. RP থেকে ব্যবহারকারীর অ্যাকাউন্ট সংযোগ বিচ্ছিন্ন করুন।
6. JSON ফর্ম্যাটে চিহ্নিত ব্যবহারকারীর অ্যাকাউন্টের তথ্য দিয়ে ব্রাউজারে সাড়া দিন।

একটি উদাহরণ প্রতিক্রিয়া JSON পেলোড এইরকম দেখাচ্ছে:

  {
    "account_id": "account456"
  }

পরিবর্তে, যদি IdP চায় যে ব্রাউজারটি RP-এর সাথে সম্পর্কিত সমস্ত অ্যাকাউন্ট সংযোগ বিচ্ছিন্ন করুক, তাহলে এমন একটি স্ট্রিং পাস করুন যা কোনও অ্যাকাউন্ট আইডির সাথে মেলে না, উদাহরণস্বরূপ "*" ।

ক্লায়েন্ট মেটাডেটা এন্ডপয়েন্ট

IdP-এর ক্লায়েন্ট মেটাডেটা এন্ডপয়েন্ট নির্ভরশীল পক্ষের মেটাডেটা যেমন RP-এর গোপনীয়তা নীতি, পরিষেবার শর্তাবলী এবং লোগো আইকনগুলি ফেরত দেয়। RP-দের তাদের গোপনীয়তা নীতি এবং পরিষেবার শর্তাবলীর লিঙ্কগুলি IdP-কে আগে থেকেই প্রদান করা উচিত। ব্যবহারকারী যখন এখনও IdP-এর সাথে RP-তে নিবন্ধিত না হন তখন এই লিঙ্কগুলি সাইন-ইন ডায়ালগে প্রদর্শিত হয়।

ব্রাউজারটি কুকি ছাড়াই client_id navigator.credentials.get ব্যবহার করে একটি GET অনুরোধ পাঠায়। উদাহরণস্বরূপ:

  GET /client_metadata.example?client_id=1234 HTTP/1.1
  Host: accounts.idp.example
  Origin: https://rp.example/
  Accept: application/json
  Sec-Fetch-Dest: webidentity

অনুরোধ পাওয়ার পর, সার্ভারের উচিত:

1. client_id এর জন্য RP নির্ধারণ করুন।
2. ক্লায়েন্ট মেটাডেটা দিয়ে সাড়া দিন।

ক্লায়েন্ট মেটাডেটা এন্ডপয়েন্টের বৈশিষ্ট্যগুলির মধ্যে রয়েছে:

ব্রাউজারটি এন্ডপয়েন্ট থেকে একটি JSON প্রতিক্রিয়া আশা করে:

  {
    "privacy_policy_url": "https://rp.example/privacy_policy.html",
    "terms_of_service_url": "https://rp.example/terms_of_service.html",
    "icons": [{
          "url": "https://rp.example/rp-icon.ico",
          "size": 40
      }]
  }

ফিরে আসা ক্লায়েন্ট মেটাডেটা ব্রাউজার দ্বারা ব্যবহৃত হয় এবং RP-তে উপলব্ধ হবে না।

লগইন ইউআরএল

এই এন্ডপয়েন্টটি ব্যবহারকারীকে আইডিপিতে সাইন ইন করতে দেওয়ার জন্য ব্যবহৃত হয়।

লগইন স্ট্যাটাস API ব্যবহার করে, IdP ব্যবহারকারীর লগইন স্ট্যাটাস ব্রাউজারে জানাতে হবে। তবে, স্ট্যাটাসটি সিঙ্কের বাইরে থাকতে পারে, যেমন সেশনের মেয়াদ শেষ হয়ে গেলে । এই ধরনের পরিস্থিতিতে, ব্রাউজারটি idp কনফিগ ফাইলের login_url দিয়ে নির্দিষ্ট লগইন পৃষ্ঠার URL এর মাধ্যমে ব্যবহারকারীকে IdP-তে সাইন ইন করতে দিতে পারে।

FedCM ডায়ালগটি সাইন ইন করার পরামর্শ দিয়ে একটি বার্তা প্রদর্শন করে, যেমনটি নিম্নলিখিত ছবিতে দেখানো হয়েছে।

যখন ব্যবহারকারী Continue বাটনে ক্লিক করেন, তখন ব্রাউজারটি IdP এর লগইন পৃষ্ঠার জন্য একটি ডায়ালগ উইন্ডো খোলে।

ডায়ালগটি একটি নিয়মিত ব্রাউজার উইন্ডো যার প্রথম পক্ষের কুকিজ থাকে। ডায়ালগের মধ্যে যা কিছু ঘটবে তা IdP-এর উপর নির্ভর করে এবং RP পৃষ্ঠায় ক্রস-অরিজিন যোগাযোগের অনুরোধ করার জন্য কোনও উইন্ডো হ্যান্ডেল উপলব্ধ থাকে না। ব্যবহারকারী সাইন ইন করার পরে, IdP-এর উচিত:

• ব্যবহারকারী সাইন ইন করেছেন কিনা তা জানাতে Set-Login: logged-in হেডারটি পাঠান অথবা navigator.login.setStatus("logged-in") API-তে কল করুন।
• ডায়ালগটি বন্ধ করতে IdentityProvider.close() এ কল করুন।

ব্যবহারকারীর লগইন অবস্থা সম্পর্কে ব্রাউজারকে অবহিত করুন

লগইন স্ট্যাটাস এপিআই হলো এমন একটি প্রক্রিয়া যেখানে একটি ওয়েবসাইট, বিশেষ করে একটি আইডিপি, ব্রাউজারকে আইডিপিতে ব্যবহারকারীর লগইন স্ট্যাটাস সম্পর্কে অবহিত করে। এই এপিআই ব্যবহার করে, ব্রাউজার আইডিপিতে অপ্রয়োজনীয় অনুরোধ কমাতে পারে এবং সম্ভাব্য টাইমিং আক্রমণ কমাতে পারে ।

আইডিপিগুলি ব্যবহারকারীর লগইন স্ট্যাটাস ব্রাউজারে HTTP হেডার পাঠিয়ে অথবা ব্যবহারকারী যখন আইডিপিতে সাইন ইন করেন অথবা ব্যবহারকারী যখন তাদের সমস্ত আইডিপি অ্যাকাউন্ট থেকে সাইন আউট করেন তখন জাভাস্ক্রিপ্ট এপিআই কল করে সিগন্যাল করতে পারে। প্রতিটি আইডিপির জন্য (এর কনফিগারেশন ইউআরএল দ্বারা চিহ্নিত) ব্রাউজারটি সম্ভাব্য মান সহ লগইন স্ট্যাটাস প্রতিনিধিত্ব করে একটি ট্রাই-স্টেট ভেরিয়েবল রাখে:

• logged-in
• logged-out
• unknown (ডিফল্ট)

ব্যবহারকারী সাইন ইন করেছেন তা বোঝাতে, একটি শীর্ষ-স্তরের নেভিগেশনে একটি Set-Login: logged-in HTTP হেডার পাঠান অথবা IdP অরিজিনে একটি একই-সাইট সাবরিসোর্স অনুরোধ পাঠান:

  Set-Login: logged-in

বিকল্পভাবে, একটি শীর্ষ-স্তরের নেভিগেশনে IdP origin থেকে JavaScript পদ্ধতি navigator.login.setStatus('logged-in') কল করুন:

  navigator.login.setStatus('logged-in')

ব্যবহারকারীর লগইন স্ট্যাটাস logged-in হিসেবে সেট করা হবে।

ব্যবহারকারী তাদের সমস্ত অ্যাকাউন্ট থেকে সাইন আউট হয়ে গেছেন তা বোঝাতে, শীর্ষ-স্তরের নেভিগেশনে একটি Set-Login: logged-out HTTP হেডার পাঠান অথবা IdP অরিজিনে একই-সাইট সাবরিসোর্স অনুরোধ পাঠান:

  Set-Login: logged-out

বিকল্পভাবে, একটি শীর্ষ-স্তরের নেভিগেশনে IdP অরিজিন থেকে JavaScript API navigator.login.setStatus('logged-out') কল করুন:

  navigator.login.setStatus('logged-out')

ব্যবহারকারীর লগইন স্ট্যাটাস logged-out হিসেবে সেট করা হবে।

লগইন স্ট্যাটাস API ব্যবহার করে আইডিপি একটি সংকেত পাঠানোর আগে unknown অবস্থা সেট করা হয়। ব্রাউজারটি আইডিপির অ্যাকাউন্ট এন্ডপয়েন্টে একটি অনুরোধ করে এবং অ্যাকাউন্ট এন্ডপয়েন্ট থেকে প্রাপ্ত প্রতিক্রিয়ার উপর ভিত্তি করে অবস্থা আপডেট করে:

• যদি এন্ডপয়েন্টটি সক্রিয় অ্যাকাউন্টগুলির একটি তালিকা প্রদান করে, তাহলে স্থিতিটি logged-in এ আপডেট করুন এবং সেই অ্যাকাউন্টগুলি দেখানোর জন্য FedCM ডায়ালগ খুলুন।
• যদি এন্ডপয়েন্টটি কোনও অ্যাকাউন্ট না ফেরায়, তাহলে স্থিতিটি logged-out আপডেট করুন এবং FedCM কলটি ব্যর্থ করুন।

ব্যবহারকারীকে একটি গতিশীল লগইন প্রবাহের মাধ্যমে সাইন ইন করতে দিন

যদিও আইডিপি ব্যবহারকারীর লগইন স্ট্যাটাস ব্রাউজারে বারবার জানাতে থাকে, তবুও এটি সিঙ্কের বাইরে থাকতে পারে, যেমন সেশনের মেয়াদ শেষ হয়ে গেলে। লগইন স্ট্যাটাস logged-in সময় ব্রাউজার অ্যাকাউন্টের শেষ বিন্দুতে একটি শংসাপত্রের অনুরোধ পাঠানোর চেষ্টা করে, কিন্তু সার্ভার কোনও অ্যাকাউন্ট ফেরত দেয় না কারণ সেশনটি আর উপলব্ধ থাকে না। এই পরিস্থিতিতে, ব্রাউজারটি ডায়নামিকভাবে ব্যবহারকারীকে একটি ডায়ালগ উইন্ডোর মাধ্যমে আইডিপিতে সাইন ইন করতে দিতে পারে ।