جریان کاربر احراز هویت

بررسی اجمالی

هدف از جریان احراز هویت شناسایی و احراز هویت کاربر به ادغام کننده پرداخت (ادغام کننده) است.

احراز هویت ورودی به روش های دیگر است. به خصوص برای associateAccount و capture . این بدان معنی است که اثبات احراز هویت به عنوان ورودی (پارامتر) برای آن دو روش استفاده می شود.

Google همچنین می‌تواند از جریان احراز هویت در حالت مستقل برای تأیید یک کاربر استفاده کند. در این مورد به عنوان ورودی برای هیچ جریان دیگری استفاده نمی شود، بلکه فقط برای تأیید اینکه کاربر قادر به تأیید هویت است.

به خاطر داشته باشید که وقتی در حال سوار شدن هستید، Google با شما همکاری می کند تا مکانیزم احراز هویت را انتخاب کنید که به بهترین وجه متناسب با محصول شما باشد.

جریان چگونه کار می کند

دو راه برای احراز هویت یک کاربر وجود دارد که هر کدام جریان خاص خود را دارند. در زمان ادغام، یکپارچه ساز باید تعیین کند که از کدام یک استفاده کند.

1. تغییر مسیر احراز هویت
2. احراز هویت SMS-MT OTP

تغییر مسیر احراز هویت

یک کاربر Google که نیاز به احراز هویت دارد، ممکن است به برنامه ادغام‌کننده یا وب‌سایت خود هدایت شود تا هویتش تأیید شود. در اینجا مروری کوتاه بر مراحل این جریان است:

1. Google کاربر را به وب ادغام‌کننده یا برنامه اندروید هدایت می‌کند تا بتواند احراز هویت شود.
2. برای احراز هویت، requestId احراز هویت (از AuthenticationRequest ) به عنوان مدرک احراز هویت استفاده می شود.
3. این منجر به یک پاسخ امضا شده به نام AuthenticationResponse می شود.
4. پس از آن، برنامه یا وب سایت کاربر را به Google هدایت می کند.

توجه: در حالت مستقل، پاسخ امضا شده (مرحله 3) و gspResult تعیین می کنند که آیا احراز هویت موفقیت آمیز بوده است یا خیر.

احراز هویت ریدایرکت از یک روش HTTP GET استفاده می کند که پارامترهای آن در URL برای یک برنامه وب کدگذاری شده است. از یک Android Intent برای احراز هویت برنامه اندروید استفاده می کند. برای جزئیات بیشتر در مورد رمزگذاری، به احراز هویت وب و برای پارامترهای هدف Android، احراز هویت Android را ببینید.

نتیجه هر یک از این مکانیسم های احراز هویت یک پاسخ امضا شده به نام AuthenticationResponse است. این هدف باید شامل پاسخ احراز هویت استاندارد پرداخت‌های Google رمزگذاری‌شده و رمزگذاری‌شده ( gspAuthenticationResponse ) برای برقراری ارتباط با یک احراز هویت موفق باشد. اگر در حالت مستقل استفاده شود، از gspResult و امضا برای تعیین احراز هویت موفق استفاده می شود.

توجه: ادغام کننده باید هم نسخه وب سازگار با موبایل و هم نسخه دسکتاپ برنامه وب خود را ارائه دهد.

نمودار توالی زیر تعامل بین مرورگر کاربر، گوگل و برنامه وب ادغام کننده را نشان می دهد:

تغییر مسیر- جریان احراز هویت وب

در اینجا لیستی از اشیاء و آنچه که آنها نشان می دهند آمده است:

• کاربر : این شخصی است که می خواهد یک روش پرداخت را به حساب Google خود اضافه کند.
• Google UI : در این مورد، رابط وب در Google، جایی که مشتری شروع به تنظیم یک روش پرداخت می کند.
• Google Server : سرور پشتیبان در Google که بررسی احراز هویت را همراه با سایر کارهای احراز هویت انجام می دهد.
• Payment Integrator Web : وب سایت یکپارچه ساز که در آن کاربر یک حساب کاربری دارد.

برای این جریان احراز هویت، ما قبلاً فرض می‌کنیم که کاربر در وب‌سایت Google (Google UI) است و سعی می‌کند یک روش پرداخت اضافه کند. اینجاست که همه چیز شروع می شود.

1. رابط کاربری Google یک URL احراز هویت ایجاد می کند که به سرور Google (پشتیبان) ارسال می شود. این همان چیزی است که فرآیند احراز هویت را آغاز می کند.
2. سرور Google یک درخواست احراز هویت ( AuthenticationRequest ) ایجاد می کند.
3. درخواست احراز هویت به رابط کاربری Google ارسال شد.
4. کاربر این پیام را دریافت می کند که باید شناسه خود را با ادغام کننده احراز هویت کند.
5. کاربر پاسخ می دهد که می خواهد احراز هویت کند، که این پیام را به وب سایت ادغام کننده ارسال می کند.
6. وب‌سایت Payment Integrator تأیید هویت کاربر را می‌خواهد.
7. کاربر مدرک هویت خود را ارائه می دهد که به وب سایت Payment Integrator ارسال می شود.
8. ادغام کننده یک پاسخ ( authenticationResponse ) به شواهدی که به آنها داده شده است (با authenticationResponse کدگذاری شده در پیام) ایجاد می کند.
9. این آدرس پاسخ برای کاربر ارسال می شود.
10. URL پاسخ بلافاصله از کاربر به رابط کاربری Google ارسال می شود.
11. رابط کاربری Google پاسخ را به سرور Google ارسال می کند.
12. سرور Google پاسخ را به عنوان تأیید شده تفسیر می کند.

نمودار دنباله بعدی تعامل بین تلفن کاربر، گوگل و برنامه اندروید یکپارچه ساز را نشان می دهد:

تغییر مسیر- جریان احراز هویت برنامه اندروید

توجه: هیچ یک از دو نمودار بالا استفاده از authenticationId را به عنوان ورودی برای جریان دیگر نشان نمی‌دهد، اما اغلب از آن استفاده می‌شود.

در اینجا اشیاء و آنچه نشان می دهند آمده است:

• کاربر : این شخصی است که می خواهد یک روش پرداخت را به حساب Google خود اضافه کند.
• رابط کاربری Google : در این مورد، رابط برنامه، جایی که مشتری شروع به تنظیم یک روش پرداخت می‌کند.
• Google Server : سرور پشتیبان در Google که بررسی احراز هویت را همراه با سایر کارهای احراز هویت انجام می دهد.
• Payment Integrator APK : برنامه یکپارچه‌ساز که در آن کاربر به حساب یکپارچه‌ساز خود دسترسی دارد.
• Payment Integrator Server : سرور پشتیبان یکپارچه ساز که اطلاعات کاربر در آن ذخیره می شود.

از آنجایی که این یک جریان احراز هویت است، ما قبلاً فرض می‌کنیم که کاربر از یک برنامه (Google UI) استفاده می‌کند و سعی می‌کند یک روش پرداخت اضافه کند. اینجاست که مقداردهی اولیه آغاز می شود.

1. رابط کاربری Google یک تماس احراز هویت ایجاد می کند که به سرور Google (پشتیبان) ارسال می شود.
2. سرور Google یک درخواست احراز هویت ایجاد می کند ( AuthenticationRequest ).
3. سرور Google یک APK تماس را به UI (برنامه) Google ارسال می کند و درخواست احراز هویت می کند.
4. رابط کاربری Google اطلاعات کاربر را به Payment Integrator APK ( AUTHENTICATE_V1(authReq) ) ارسال می کند.
5. Payment Integrator APK درخواست ( authReq ) را به سرور Payment Integrator ارسال می کند.
6. سرور Payment Integrator یک چالش را به Payment Integrator APK ارسال می کند.
7. Payment Integrator APK چالش را برای کاربر ارسال می کند.
8. کاربر مدرکی مبنی بر هویت خود ارائه می دهد که به APK یکپارچه کننده پرداخت ارسال می شود.
9. سپس این مدرک به سرور Payment Integrator ارسال می شود.
10. سرور یک authenticationResponse امضا شده ایجاد می کند.
11. پاسخ احراز هویت با موفقیت انجام شد و یک پیام authResp به Payment Integrator APK ارسال می‌شود.
12. پیام موفقیت آمیز ( authResp ) از Payment Integrator APK به رابط کاربری Google ارسال می شود.
13. رابط کاربری گوگل پاسخ را به سرور گوگل ارسال می کند.
14. سرور گوگل پاسخ موفقیت آمیز را تفسیر می کند.

SMS-MT OTP Authentication

یکی دیگر از روش های احراز هویت، سرویس پیام کوتاه، تلفن همراه پایان یافته، رمز عبور یک بار مصرف (SMS-MT OTP) است. این مکانیسم از شماره تلفن کاربر برای ارسال یک رمز عبور یکبار مصرف برای احراز هویت استفاده می کند. Google از یکپارچه‌ساز می‌خواهد تا یک OTP را به شماره تلفن کاربر ارسال کند و پس از دریافت آن توسط کاربر و سپس وارد کردن آن به رابط Google، کاربر تأیید می‌شود.

این شامل مراحل زیر است:

1. رابط کاربری گوگل (UI) از کاربر می خواهد شماره تلفنی را وارد کند که قبلاً در ادغام کننده ثبت شده است.
2. کاربر شماره تلفنی را در رابط کاربری Google وارد می کند.
3. گوگل یکپارچه ساز را فعال می کند (روش sendOtp را فراخوانی می کند) تا رمز عبور یک بار مصرف (OTP) را برای کاربر ارسال کند.
4. کاربر پیامک را با OTP دریافت می کند.
5. سپس کاربر OTP (که به عنوان ورودی برای capture ، associateAccount و verifyOtp استفاده می شود) را که دریافت کرده است را در رابط Google وارد کرده و کاربر را احراز هویت می کند. این اثبات احراز هویت است.

در حالت مستقل، فقط متد verifyOtp برای تایید مقدار OTP فراخوانی می شود.

نمودار توالی زیر تعامل بین تلفن کاربر، Google و ادغام کننده هنگام ارسال OTP را نشان می دهد:

جریان احراز هویت تلفن (ارسال OTP).

توجه: نمودار بالا استفاده از OTP را به عنوان ورودی برای تماس دیگر نشان نمی دهد. با این حال، این به عنوان ورودی برای انواع تماس‌ها، مانند verifyOtp و associateAccount استفاده می‌شود.

در اینجا لیستی از اشیاء در نمودار و آنچه نشان می دهند آمده است:

• کاربر : این شخصی است که می خواهد یک روش پرداخت را به حساب Google خود اضافه کند.
• Google UI : در این مورد، یک وب‌سایت یا برنامه تلفن Google است که در آن مشتری شروع به تنظیم روش پرداخت می‌کند. توجه: اگر رابط کاربری Google یک برنامه تلفن باشد، چند مرحله اول نادیده گرفته می‌شود زیرا تلفن از قبل شماره تلفن کاربر را می‌داند.
• Google Server : سرور پشتیبان در Google که بررسی احراز هویت را همراه با سایر کارهای احراز هویت انجام می دهد.
• Payment Integrator Server : سرور پشتیبان یکپارچه ساز که اطلاعات کاربر در آن ذخیره می شود.

از آنجایی که این یک جریان تأیید اعتبار OTP است، ما قبلاً فرض می‌کنیم که کاربر در یک برنامه یا وب‌سایت تلفن Google (Google UI) است و سعی می‌کند یک روش پرداخت اضافه کند. اینجاست که مقداردهی اولیه آغاز می شود.

1. رابط کاربری Google (تلفن یا وب‌سایت) از کاربر شماره تلفن خود را درخواست می‌کند.
2. کاربر شماره تلفن خود را در رابط کاربری Google وارد می کند.
3. رابط کاربری Google شماره ( sendChallenge(phoneNum) ) را به سرور Google ارسال می کند.
4. سرور Google درخواستی برای ارسال یک رمز عبور یکبار مصرف به سرور ادغام کننده پرداخت ( SendOtp(phoneNum) می فرستد.
5. سرور Payment Integrator یک رمز عبور یکبار مصرف (OTP) را برای کاربر ارسال می کند.
6. سرور Payment Integrator به درخواست Google در شماره 5 پاسخ می دهد و نشان می دهد که OTP با موفقیت ارسال شده است.
7. کاربر این OTP را در رابط کاربری Google (تلفن یا وب سایت) وارد می کند.
8. رابط کاربری Google OTP را به سرور Google می فرستد و در نهایت برای تأیید به ادغام کننده پرداخت ارسال می شود. این کار هویت کاربر را تایید می کند و کاربر را احراز هویت می کند.

احراز هویت و احراز هویت مجدد

دو نقطه در زمان وجود دارد که احراز هویت ممکن است رخ دهد:

1. احراز هویت اولیه - برای شناسایی و احراز هویت یک کاربر استفاده می شود. احراز هویت اولیه به عنوان ورودی روش associateAccount استفاده می شود.
2. احراز هویت مجدد - در همه زمینه‌های دیگر، مانند مستقل یا به عنوان ورودی برای capture استفاده می‌شود.

احراز هویت مجدد با احراز هویت اولیه متفاوت است. هرگز تمایلی به شناسایی مجدد یک کاربر، صرفاً برای احراز هویت مجدد ندارد. احراز هویت مجدد توسط Google برای به چالش کشیدن کاربر برای اثبات مالکیت یک حساب خاص استفاده می شود و این به صلاحدید Google اتفاق می افتد.

در این فرآیند یک مرجع به نام associationId به انجمن اصلی (از جریان انجمن) ارائه می شود. این از طریق فراخوانی متد associateAccount در طول جریان ارتباط ارائه می‌شود. associationId حسابی را که باید با آن به چالش کشیده شود، شناسایی می کند. برای امنیت، کاربر نباید بتواند حساب مورد چالش را تغییر دهد.

برای احراز هویت مجدد SMS-MT OTP، Google شماره تلفن ارائه شده در طول تماس اصلی را برای sendOtp به عنوان یک شماره ثابت نگه می‌دارد. این را نمی توان تغییر داد، دوباره برای امنیت.

در اینجا یک جریان نمونه وجود دارد که در آن Google تصمیم می‌گیرد قبل از خرید، به چالش (احراز هویت مجدد) بپردازد:

جریان احراز هویت مجدد

لیست اشیاء و آنچه که آنها نشان می دهند به شرح زیر است:

• کاربر : این شخصی است که می خواهد خرید کند.
• Google UI : در این مورد، یک وب‌سایت یا برنامه تلفن Google است که مشتری شروع به خرید می‌کند.
• UI Payment Integrator : وب سایت یا برنامه ای که مشتری رو به رو است که در آن کاربر می تواند به اطلاعات حساب خود با یکپارچه کننده دسترسی پیدا کند.
• Google Server : سرور پشتیبان در Google که بررسی احراز هویت مجدد را همراه با سایر وظایف انجام می دهد.
• Payment Integrator Server : سرور پشتیبان یکپارچه ساز که اطلاعات کاربر در آن ذخیره می شود.

جریان احراز هویت مجدد زمانی شروع می شود که مشتری شروع به خرید کند. این یک جریان را برای احراز هویت مجدد کاربر آغاز می کند.

1. کاربر تصمیم می گیرد یک کالا یا خدمات را خریداری کند.
2. درخواست از رابط کاربری گوگل به سرور گوگل ارسال می شود.
3. سرور Google یک درخواست احراز هویت ( authenticationRequest ) را به رابط کاربری Google ارسال می کند.
4. رابط کاربری Google درخواستی را برای احراز هویت کاربر ( associationId , authenticationRequest ) به واسط Payment Integrator ارسال می کند.
5. رابط کاربری Payment Integrator کاربر را برای تأیید هویت او جستجو می‌کند ( LookupIdentity ( associationId )).
6. واسط کاربری Payment Integrator از کاربر می‌خواهد اعتبارنامه‌های موجود در رابط کاربری خود (وب‌سایت یا برنامه یکپارچه‌ساز) را دریافت کند.
7. پاسخ احراز هویت به سرور Payment Integrator ارسال می شود.
8. پاسخ احراز هویت امضا شده ( authenticationResponse ) به واسط کاربری Payment Integrator ارسال می‌شود.
9. پاسخ احراز هویت ( authenticationResponse ) از رابط کاربری Payment Integrator به رابط کاربری Google ارسال می‌شود.
10. رابط کاربری Google پاسخ را همراه با اطلاعات خرید به سرور Google ارسال می کند.
11. سرور Google یک پیام capture (برای یافتن وجوه موجود) به سرور یکپارچه‌ساز پرداخت ( authenticationRequestId ، GPT، مقدار) ارسال می‌کند.
12. سرور ادغام کننده پرداخت پیام موفقیت آمیز را به سرور Google ارسال می کند.
13. سرور Google پیام موفقیت را به رابط کاربری Google ارسال می کند.
14. رابط کاربری Google مورد(ها) را به مشتری تحویل می دهد (یا به آنها اطلاع می دهد که به زودی تحویل خواهند شد).

احراز هویت SMS-MO

سرویس پیام کوتاه، جریان احراز هویت مبدا تلفن همراه از یک پیامک حاوی یک شناسه درخواست احراز هویت که از تلفن کاربر به یکپارچه‌سازی پرداخت ارسال می‌شود برای احراز هویت کاربر استفاده می‌کند.

در اینجا لیستی از اشیاء در نمودار و آنچه نشان می دهند آمده است:

• کاربر : این شخصی است که می خواهد یک روش پرداخت را به حساب Google خود اضافه کند.
• UI/دستگاه Google : در این مورد، یک برنامه تلفن Google است که در آن مشتری شروع به تنظیم یک روش پرداخت می‌کند.
• Google Server : سرور Backend در Google که دستورالعمل های SMS را با شناسه درخواست احراز هویت (ARID) تولید می کند و نتیجه احراز هویت را از یکپارچه ساز دریافت می کند.
• سرور یکپارچه‌ساز پرداخت : سرور پشتیبان یکپارچه‌کننده که پیامک احراز هویت را دریافت می‌کند و شناسه درخواست احراز هویت را به Google برمی‌گرداند.

از آنجایی که این یک جریان احراز هویت است، ما قبلاً فرض می‌کنیم که کاربر از یک برنامه (Google UI) استفاده می‌کند و سعی می‌کند یک روش پرداخت اضافه کند. اینجاست که مقداردهی اولیه آغاز می شود.

1. کاربر یک ابزار Tokenized را برای افزودن انتخاب می کند.
2. رابط کاربری گوگل با سرور گوگل تماس می گیرد تا چالش SMS-MO را آغاز کند.
3. سرور Google دستورالعمل‌های پیامکی را برمی‌گرداند که شامل یک مقصد و یک بدنه حاوی شناسه درخواست احراز هویت است.
4. رابط کاربری Google پیامک را به Payment Integrator ارسال می کند.
5. سرور Payment Integrator با شناسه درخواست احراز هویت، نقطه پایانی authenticationResultNotification را در سرور Google فرا می خواند.
6. شناسه درخواست احراز هویت توسط سرور Google تأیید می شود که با موفقیت پاسخ می دهد.
7. رابط کاربری گوگل با سرور گوگل تماس می گیرد تا نتیجه تلاش احراز هویت را به دست آورد.
8. پاسخ سرور Google SUCCESS.

احراز هویت SMS-MO شبیه سازی شده

به منظور انجام تست‌های تشخیصی جریان تأیید اعتبار SMS-MO، Google یک نقطه پایانی پیامک شبیه‌سازی را تعریف می‌کند. این امر نیاز به ارسال و تایید یک پیامک واقعی را هنگام انجام Test Associations در محیط sandbox حذف می کند.

در اینجا لیستی از اشیاء در نمودار و آنچه نشان می دهند آمده است:

• تستر : این شخصی است که آزمایش تشخیصی ارتباط SMS-MO را آغاز می کند.
• Google UI : یک رابط کاربری Google که در آن آزمایش‌کننده شروع می‌کند و وضعیت آزمایش تشخیصی SMS-MO را نظارت می‌کند.
• Google Server : سرور Backend در Google که دستورالعمل های SMS را با شناسه درخواست احراز هویت (ARID) تولید می کند، پیام SMS شبیه سازی شده را ارسال می کند و نتیجه احراز هویت را از ادغام کننده دریافت می کند.
• Payment Integrator Server : سرور پشتیبان یکپارچه ساز که پیامک احراز هویت شبیه سازی شده را دریافت می کند و شناسه درخواست احراز هویت را به Google برمی گرداند.

مراحل این جریان عبارتند از:

1. تستر تست تشخیصی SMS-MO را با ارائه شناسه مشترک آزمایشی (SID) برای استفاده برای آزمایش آغاز می کند. این SID در تماس simulateSms با Payment Integrator گنجانده خواهد شد.
2. رابط کاربری گوگل با سرور گوگل تماس می گیرد تا چالش SMS-MO را آغاز کند.
3. سرور Google دستورالعمل‌های پیامکی را برمی‌گرداند که شامل یک مقصد و یک بدنه حاوی شناسه درخواست احراز هویت است. برای اهداف این آزمایش، مقصد توسط اتصال HTTPS جعبه ایمنی Payment Integrator لغو می‌شود.
4. رابط کاربری گوگل با سرور گوگل تماس می گیرد تا پیام اس ام اس شبیه سازی شده را ارسال کند.
5. تماس simulateSms از سرور Google به سرور Payment Integrator انجام می شود. هر دو شناسه درخواست احراز هویت و شناسه مشترک (همانطور که در مرحله 1 ارائه شده است) در تماس API گنجانده شده است.
6. سرور ادغام کننده پرداخت به تأیید پاسخ می دهد.
7. سرور Google به رابط کاربری Google SUCCESS پاسخ می دهد.
8. سرور Payment Integrator با شناسه درخواست احراز هویت، نقطه پایانی authenticationResultNotification را در سرور Google فرا می خواند.
9. سرور Google با موفقیت پاسخ می دهد.
10. رابط کاربری گوگل با سرور گوگل تماس می گیرد تا نتیجه تلاش احراز هویت را به دست آورد.
11. پاسخ سرور Google تکمیل شد.
12. رابط کاربری Google با سرور گوگل تماس می‌گیرد تا یک تلاش انجمن را اجرا کند.
13. تماس associateAccount از سرور Google به سرور Payment Integrator انجام می شود.
14. سرور ادغام کننده پرداخت با موفقیت پاسخ می دهد.
15. سرور Google با موفقیت پاسخ می دهد.
16. رابط کاربری Google به‌روزرسانی می‌شود تا به آزمایش‌کننده نشان دهد که آزمایش تشخیصی SMS-MO با موفقیت انجام شده است.

بهترین شیوه ها و ملاحظات دیگر

انتخاب پلتفرم ها

ارائه یک برنامه تلفن همراه و جریان احراز هویت وب دسکتاپ به ادغام کننده اجازه می دهد تا به بیشترین کاربران دسترسی پیدا کند. گوگل اکیداً توصیه می‌کند که یکپارچه‌سازها از برنامه اندروید پشتیبانی کنند، زیرا بهترین تجربه کاربری را ارائه می‌دهد که منجر به بالاترین نرخ تبدیل می‌شود. پارامترهای ارسال شده در API های احراز هویت برای وب و برنامه های Android یکسان است.