یک راه حل هویت با FedCM در سمت ارائه دهنده هویت پیاده سازی کنید

با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

پیاده سازی FedCM شامل چندین مرحله اصلی برای هر دو Identity Provider (IdP) و Relying Party (RP) است. برای یادگیری نحوه پیاده سازی FedCM در سمت RP به مستندات مراجعه کنید.

IdP ها برای پیاده سازی FedCM باید مراحل زیر را انجام دهند:

• یک فایل شناخته شده ایجاد کنید.
• یک فایل کانفیگ ایجاد کنید.
• نقاط پایانی زیر را ایجاد کنید:
  • نقطه پایانی حساب
  • نقطه پایان ادعای شناسه
  • [اختیاری] نقطه پایانی را قطع کنید
  • [اختیاری] نقطه پایانی فراداده مشتری
  • نقطه پایانی ورود به سیستم
• مرورگر را از وضعیت ورود کاربر مطلع کنید.

یک فایل شناخته شده ایجاد کنید

برای جلوگیری از سوء استفاده ردیاب‌ها از API ، یک فایل شناخته شده باید از /.well-known/web-identity eTLD+1 IdP ارائه شود.

فایل شناخته شده می تواند شامل ویژگی های زیر باشد:

به عنوان مثال، اگر نقاط پایانی 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 باید از چندین پیکربندی مختلف تست و تولید پشتیبانی کند.
• یک 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 لیستی از نقاط پایانی مورد نیاز برای مرورگر را ارائه می دهد. IdP ها باید یک یا چند فایل پیکربندی، و نقاط پایانی و URL های مورد نیاز را میزبانی کنند. همه پاسخ‌های JSON باید با نوع محتوای application/json ارائه شوند.

URL فایل پیکربندی با مقادیر ارائه شده به فراخوانی navigator.credentials.get() اجرا شده در RP تعیین می شود. 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.
    "accounts": {"include": "developer"},
    "modes": {
        "active": {
          "supports_use_other_account": true,
        }
    },
    "branding": {
      "background_color": "green",
      "color": "#FFEEAA",
      "icons": [{
        "url": "https://idp.example/icon.ico",
        "size": 25
      }]
    }
  }

هنگامی که مرورگر فایل پیکربندی را واکشی می کند، درخواست های بعدی را به نقاط پایانی IdP ارسال می کند:

از حساب دیگر استفاده کنید

اگر IdP از چندین حساب پشتیبانی می کند یا حساب موجود را جایگزین می کند، کاربران می توانند به حسابی تغییر کنند که با حسابی که در حال حاضر با آن وارد شده اند متفاوت است.

برای اینکه کاربر بتواند حساب های دیگر را انتخاب کند، IdP باید این ویژگی را در فایل پیکربندی مشخص کند:

  {
    "accounts_endpoint" : "/accounts.example",
    "modes": {
      "active": {
        // Allow the user to choose other account (false by default)
        "supports_use_other_account": true
      }
      // "passive" mode can be configured separately
    }
  }

نقطه پایانی حساب ها

نقطه پایانی حساب‌های IdP فهرستی از حساب‌هایی را که کاربر در IdP وارد شده است، برمی‌گرداند. اگر IdP از چندین حساب پشتیبانی کند، این نقطه پایانی همه حساب‌های وارد شده را برمی‌گرداند.

مرورگر یک درخواست GET را با کوکی‌هایی با SameSite=None ارسال می‌کند، اما بدون پارامتر 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. بررسی کنید که درخواست حاوی سرصفحه HTTP Sec-Fetch-Dest: webidentity .
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.
      "labels": ["hr", "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 یک ادعا را برای کاربر واردشده به سیستم باز می‌گرداند. هنگامی که کاربر با استفاده از فراخوان navigator.credentials.get() وارد یک وب سایت RP می شود، مرورگر یک درخواست POST با کوکی هایی با SameSite=None و یک نوع محتوا از 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&disclosure_text_shown=true&fields=email,picture&disclosure_shown_for=email,picture

پس از دریافت درخواست، سرور باید:

1. با CORS (اشتراک گذاری منابع متقابل) به درخواست پاسخ دهید.
2. بررسی کنید که درخواست حاوی سرصفحه HTTP Sec-Fetch-Dest: webidentity .
3. سرصفحه Origin را با مبدا RP تعیین شده توسط client_id مطابقت دهید. اگر مطابقت نداشتند رد کنید.
4. account_id با شناسه حسابی که قبلاً وارد سیستم شده‌اید مطابقت دهید. اگر مطابقت نداشتند رد کنید.
5. با یک نشانه پاسخ دهید. اگر درخواست رد شد، با یک پاسخ خطا پاسخ دهید.

IdP می تواند تصمیم بگیرد که چگونه توکن را صادر کند. به طور کلی، با اطلاعاتی مانند شناسه حساب، شناسه مشتری، مبدأ صادرکننده و nonce امضا شده است تا RP بتواند اصل بودن توکن را تأیید کند.

مرورگر انتظار پاسخ JSON را دارد که شامل ویژگی زیر است:

توکن برگشتی توسط مرورگر به RP ارسال می شود تا RP بتواند احراز هویت را تأیید کند.

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

ادامه روی ویژگی

IdP می‌تواند یک URL تغییر مسیر در پاسخ نقطه پایانی ادعای ID برای فعال کردن یک جریان ورود چند مرحله‌ای ارائه کند. این زمانی مفید است که IdP نیاز به درخواست اطلاعات یا مجوزهای اضافی داشته باشد، به عنوان مثال:

• اجازه دسترسی به منابع سمت سرور کاربر.
• تأیید اینکه اطلاعات تماس به روز هستند.
• کنترل های والدین

نقطه پایانی ادعای ID می‌تواند یک ویژگی continue_on برگرداند که شامل یک مسیر مطلق یا نسبی به نقطه پایانی ادعای ID است.

  {
    // In the id_assertion_endpoint, instead of returning a typical
    // "token" response, the IdP decides that it needs the user to
    // continue on a popup 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 برمی گرداند. فراخوانی یکباره IdentityProvider.resolve() تنها راه ارتباط بین پنجره والد (RP) و پنجره بازشو (IdP) است.
اگر کاربر درخواست را رد کند، IdP می‌تواند با فراخوانی IdentityProvider.close() پنجره را ببندد.

  IdentityProvider.close();

Continuation API برای عملکرد به تعامل صریح کاربر (کلیک‌ها) نیاز دارد. در اینجا نحوه عملکرد Continuation API با حالت‌های مختلف میانجی‌گری آمده است:

• در حالت غیرفعال :
  • mediation: 'optional' (پیش‌فرض): Continuation API فقط با اشاره کاربر کار می‌کند، مانند کلیک کردن روی دکمه‌ای در صفحه یا روی رابط کاربری FedCM. هنگامی که احراز هویت مجدد خودکار بدون اشاره کاربر راه اندازی می شود، هیچ پنجره بازشوی باز نمی شود و وعده رد می شود.
  • mediation: 'required' : همیشه از کاربر می‌خواهد تعامل داشته باشد، بنابراین Continuation API همیشه کار می‌کند.
• در حالت فعال :
  • فعال سازی کاربر همیشه مورد نیاز است. Continuation API سازگار است.

اگر به دلایلی کاربر حساب خود را در پنجره بازشو تغییر داده باشد (به عنوان مثال، IdP یک تابع "استفاده از حساب دیگر" یا در موارد تفویض اختیار را ارائه می دهد)، فراخوانی حل یک آرگومان دوم اختیاری را می گیرد که اجازه می دهد چیزی شبیه به:

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

پاسخ خطا را برگردانید

id_assertion_endpoint همچنین می تواند یک پاسخ "خطا" را برگرداند که دارای دو فیلد اختیاری است:

• code : IdP می تواند یکی از خطاهای شناخته شده را از لیست خطاهای مشخص شده OAuth 2.0 ( invalid_request ، unauthorized_client ، access_denied ، server_error و temporarily_unavailable ) انتخاب کند یا از هر رشته دلخواه استفاده کند. اگر مورد دوم باشد، Chrome رابط کاربری خطا را با یک پیام خطای عمومی ارائه می‌کند و کد را به RP ارسال می‌کند.
• url : یک صفحه وب قابل خواندن توسط انسان را با اطلاعات مربوط به خطا شناسایی می کند تا اطلاعات بیشتری در مورد خطا به کاربران ارائه دهد. این فیلد برای کاربران مفید است زیرا مرورگرها نمی توانند پیام های خطای غنی را در یک رابط کاربری داخلی ارائه دهند. به عنوان مثال: پیوندهایی برای مراحل بعدی، یا اطلاعات تماس خدمات مشتری. اگر کاربر می‌خواهد درباره جزئیات خطا و نحوه رفع آن اطلاعات بیشتری کسب کند، می‌تواند برای جزئیات بیشتر به صفحه ارائه شده از رابط کاربری مرورگر مراجعه کند. URL باید همان سایتی باشد که IdP configURL .

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

برچسب های حساب سفارشی

با برچسب‌های حساب سفارشی ، IdP می‌تواند حساب‌های کاربری را با برچسب‌ها حاشیه‌نویسی کند، و RP می‌تواند تنها با تعیین configURL برای آن برچسب خاص، حساب‌هایی را با برچسب‌های خاص واکشی کند. این می تواند زمانی مفید باشد که یک RP نیاز به فیلتر کردن حساب ها با معیارهای خاص داشته باشد، به عنوان مثال، فقط برای نمایش حساب های خاص نقش مانند "developer" یا "hr" .

فیلتر مشابهی با استفاده از ویژگی Domain Hint و Login Hint ، با مشخص کردن آنها در فراخوانی navigator.credentials.get() امکان پذیر است. با این حال، برچسب‌های حساب سفارشی می‌توانند با مشخص کردن فایل پیکربندی، کاربران را فیلتر کنند، که مخصوصاً وقتی از چندین configURL استفاده می‌شود، مفید است. برچسب‌های حساب سفارشی نیز از این جهت متفاوت هستند که از سرور IdP ارائه می‌شوند، برخلاف RP، مانند نکات ورود به سیستم یا دامنه.

یک IdP را در نظر بگیرید که می‌خواهد بین حساب‌های "developer" و "hr" تفاوت قائل شود. برای دستیابی به این هدف، IdP نیاز به پشتیبانی از دو configURL برای "developer" و "hr" دارد:

• فایل پیکربندی برنامه‌نویس 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",
    "accounts": {
      // Account label
      "include": "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",
    "accounts": {
      // Account label
      "include": "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 ) فهرستی از حساب‌ها را برمی‌گرداند که شامل یک ویژگی labels با برچسب‌های اختصاص داده شده در یک آرایه برای هر حساب است:

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

هنگامی که یک RP می خواهد به کاربران "hr" اجازه ورود به سیستم را بدهد، می توانند configURL https://idp.example/hr/fedcm.json را در فراخوانی navigator.credentials.get() مشخص کنند:

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

در نتیجه، فقط شناسه حساب 4567 برای ورود کاربر در دسترس است. شناسه حساب 123 به‌طور بی‌صدا توسط مرورگر پنهان می‌شود تا حسابی به کاربر ارائه نشود که توسط IdP در این سایت پشتیبانی نمی‌شود.

• برچسب ها رشته هستند. اگر آرایه labels یا فیلد include چیزی باشد که رشته نیست، نادیده گرفته می‌شود.
• اگر هیچ برچسبی در configURL مشخص نشده باشد، همه حساب ها در انتخابگر حساب FedCM نمایش داده می شوند.
• اگر هیچ برچسبی برای یک حساب مشخص نشده باشد، تنها در صورتی در انتخابگر حساب نمایش داده می شود که configURL نیز برچسبی را مشخص نکرده باشد.
• اگر هیچ حسابی با برچسب درخواستی در حالت غیرفعال مطابقت نداشته باشد (شبیه به ویژگی Domain Hint)، کادر گفتگوی FedCM یک اعلان ورود به سیستم را نشان می دهد که به کاربر اجازه می دهد به یک حساب IdP وارد شود. برای حالت فعال، پنجره بازشوی ورود مستقیماً باز می شود.

نقطه پایانی را قطع کنید

با فراخوانی IdentityCredential.disconnect() ، مرورگر یک درخواست POST متقاطع را با کوکی هایی با SameSite=None و یک نوع محتوا از 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. بررسی کنید که درخواست حاوی سرصفحه HTTP Sec-Fetch-Dest: webidentity .
3. سرصفحه Origin را با مبدا RP تعیین شده توسط client_id مطابقت دهید. اگر مطابقت نداشتند رد کنید.
4. account_hint با شناسه‌های حساب‌هایی که قبلاً وارد سیستم شده‌اند مطابقت دهید.
5. حساب کاربری را از RP جدا کنید.
6. با اطلاعات حساب کاربری شناسایی شده در قالب JSON به مرورگر پاسخ دهید.

یک نمونه پاسخ JSON payload به این صورت است:

  {
    "account_id": "account456"
  }

در عوض، اگر IdP بخواهد مرورگر همه حساب‌های مرتبط با RP را قطع کند، رشته‌ای را ارسال کنید که با هیچ شناسه حسابی مطابقت ندارد، به عنوان مثال "*" .

نقطه پایانی فراداده مشتری

نقطه پایانی فراداده مشتری IdP، فراداده طرف متکی را مانند خط‌مشی رازداری RP، شرایط خدمات، و نمادهای نشان‌واره را برمی‌گرداند. RP ها باید پیوندهایی به خط مشی رازداری و شرایط خدمات خود را از قبل در اختیار IdP قرار دهند. زمانی که کاربر هنوز در RP با IdP ثبت نام نکرده باشد، این پیوندها در گفتگوی ورود به سیستم نمایش داده می شوند.

مرورگر یک درخواست GET را با استفاده از client_id navigator.credentials.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. RP را برای client_id تعیین کنید.
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 در دسترس نخواهد بود.

URL ورود

این نقطه پایانی برای اجازه ورود کاربر به IdP استفاده می شود.

با Login Status API ، IdP باید وضعیت ورود کاربر را به مرورگر اطلاع دهد. با این حال، وضعیت ممکن است هماهنگ نباشد، مانند زمانی که جلسه منقضی شود . در چنین سناریویی، مرورگر می تواند به صورت پویا به کاربر اجازه دهد از طریق URL صفحه ورود مشخص شده با login_url فایل پیکربندی idp وارد IdP شود.

همانطور که در تصویر زیر نشان داده شده است، کادر گفتگوی FedCM پیامی را نشان می دهد که ورود به سیستم را پیشنهاد می کند.

هنگامی که کاربر روی دکمه Continue کلیک می کند، مرورگر یک پنجره بازشو برای صفحه ورود IdP باز می کند.

گفتگو یک پنجره معمولی مرورگر است که کوکی های شخص اول دارد. هر آنچه در گفتگو اتفاق می افتد به IdP بستگی دارد و هیچ دسته پنجره ای برای درخواست ارتباط متقابل به صفحه RP در دسترس نیست. پس از ورود کاربر به سیستم، IdP باید:

• هدر Set-Login: logged-in ارسال کنید یا با navigator.login.setStatus("logged-in") API تماس بگیرید تا به مرورگر اطلاع دهید که کاربر وارد سیستم شده است.
• برای بستن دیالوگ، IdentityProvider.close() را فراخوانی کنید.

وضعیت ورود کاربر را به مرورگر اطلاع دهید

Login Status API مکانیزمی است که در آن یک وب سایت، به ویژه یک IdP، وضعیت ورود کاربر را در IdP به مرورگر اطلاع می دهد. با استفاده از این API، مرورگر می‌تواند درخواست‌های غیرضروری را به IdP کاهش دهد و حملات احتمالی زمان‌بندی را کاهش دهد .

IdP ها می توانند با ارسال یک هدر HTTP یا با فراخوانی یک API جاوا اسکریپت هنگام ورود کاربر به سیستم IdP یا زمانی که کاربر از تمام حساب های IdP خود خارج شده است، وضعیت ورود به سیستم کاربر را به مرورگر سیگنال دهند. برای هر IdP (که توسط URL پیکربندی آن مشخص می شود) مرورگر یک متغیر سه حالته را نگه می دارد که نشان دهنده وضعیت ورود به سیستم با مقادیر ممکن است:

• logged-in
• logged-out
• unknown (پیش فرض)

برای نشان دادن اینکه کاربر وارد سیستم شده است، یک سرصفحه HTTP Set-Login: logged-in در یک ناوبری سطح بالا یا یک درخواست منبع فرعی همان سایت در مبدا IdP ارسال کنید:

  Set-Login: logged-in

روش دیگر، روش جاوا اسکریپت navigator.login.setStatus('logged-in') از مبدا IdP در یک ناوبری سطح بالا فراخوانی کنید:

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

وضعیت ورود به سیستم کاربر به عنوان logged-in تنظیم می شود.

برای نشان دادن اینکه کاربر از همه حساب‌های خود خارج شده است، یک سرصفحه HTTP Set-Login: logged-out در یک ناوبری سطح بالا یا یک درخواست منبع فرعی همان سایت در مبدا IdP ارسال کنید:

  Set-Login: logged-out

همچنین، JavaScript API navigator.login.setStatus('logged-out') از مبدا IdP در یک ناوبری سطح بالا فراخوانی کنید:

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

وضعیت ورود به سیستم کاربر به عنوان logged-out تنظیم می شود.

وضعیت unknown قبل از ارسال سیگنال توسط IdP با استفاده از Login Status API تنظیم می شود. مرورگر به نقطه پایانی حساب‌های IdP درخواست می‌کند و وضعیت را براساس پاسخ نقطه پایانی حساب‌ها به‌روزرسانی می‌کند:

• اگر نقطه پایانی فهرستی از حساب‌های فعال را برمی‌گرداند، وضعیت را به logged-in به‌روزرسانی کنید و کادر گفتگوی FedCM را برای نمایش آن حساب‌ها باز کنید.
• اگر نقطه پایانی هیچ حسابی برگرداند، وضعیت را به logged-out به‌روزرسانی کنید و تماس FedCM ناموفق باشد.

به کاربر اجازه دهید از طریق یک جریان ورود پویا وارد سیستم شود

حتی اگر IdP وضعیت ورود کاربر به مرورگر را به اطلاع می‌رساند، ممکن است مانند زمانی که جلسه منقضی می‌شود، هماهنگ نباشد. هنگامی که وضعیت ورود به سیستم logged-in است، مرورگر سعی می‌کند یک درخواست اعتبارسنجی را به نقطه پایانی حساب‌ها ارسال کند، اما سرور هیچ حسابی برمی‌گرداند زیرا جلسه دیگر در دسترس نیست. در چنین سناریویی، مرورگر می‌تواند به صورت پویا به کاربر اجازه دهد از طریق یک پنجره بازشو به IdP وارد شود .

مراحل بعدی