[DevDojo] Introduction to Authentication Platform

The Merpay payment platform implements authentication and authorization measures to ensure secure external communication. In this course, we will explain the basic concepts of accounts and authentication (AuthN/AuthZ) and will introduce the authentication infrastructure utilized by the Mercari Group.

Transcript

1. 1 Introduction to Authentication Platform Tatsuya Karino Merpay IDP Team / Software Engineer
2. 2 What is the purpose of the IDP team? • Implement proper authentication, access control, and data protection measures in accordance with industry standards at Mercari Group. Reason to follow the industry standards. • Versatility: AuthN/AuthZ are fundamental functions utilized by all services. • Security: AuthN/AuthZ are directly related to critical incidents. About ID Platform Team
3. 3 What is the responsibility of the IDP team? Mercari Account and Authentication • How to create account and login mercari account. • What kind of authentication method is used? Basic Architecture of Authorization and Token • How to grant a privilege for client. • How to enforce the privilege on Gateway and Microservices based on Token. • What kind of token is used? how to issue and verify it? About ID Platform Team
4. 4 Introduction Account and Authentication
5. 5 • Registration ◦ Create mercari account with some authentication information. • Login ◦ Login(Create a login session) with some authentication methods. • Additional Authentication ◦ Authenticate again to do critical operation. • Change authentication information ◦ Ex. email, password, phone number …. • Password Recovery / Retirement ◦ Forget password …. ◦ Good bye mercari…. Overview - operation related Account Lifecycle
6. 6 Registration
7. 7 Registration Process
8. 8 Registration Process • Collection … collect end-user information ◦ Name, email address, password, phone number , Simple KYC • Verification … check if the information belongs to the end-user ◦ Phone number ▪ send sms code and check if the phone number is under control ▪ It is mandatory for registration. ◦ (Email address) ▪ send code and check if the email address is under control. ▪ But it is not mandatory for registration. ◦ (Simple KYC) ▪ no verification ▪ Simple KYC, ID KYC, eKYC, IC Chip KYC ◦ ID Token ▪ If the user select social login.
9. 9 Problems and future • Complicated Registration Flow / Many stakeholders ◦ A lot of information is required to input. ◦ Some team is related inside the registration flow. ▪ Auth related info(IDP), KYC(KYC) ▪ User information/Whole UI(mercari’s user team?) ◦ We want to improve these steps in the future. • Managed on Mercari API ◦ Mercari API is legacy. Hard to manage… ◦ We want to migrate to microservices when the flow is separated. • Phishing Resistance ◦ The account is based on password and SMS. So no phishing resistance. ◦ We want to create account based on strong authentication method.
10. 10 Authentication
11. 11 Authentication Methods • What kind of authentication method in mercari • The main use cases of these authentication, ◦ Login to Mercari Account ◦ Additional Authentication Authentication Method How to Verify type password Compare the password user-presents and server saved. know SMS Send a OTC by SMS. And compare the OTC user-presents and Server saved. (have) SNS Authenticate by Google / Facebook / Apple / Docomo. And verify the proof of authentication (ID Token). - passcode ※ Compare the passcode user-presents and Server saved. (know) FIDO (with user verification) ※ Local Authentication + Verify the proof of possession of priv key have + know/are NIST 800-63B Authenticator Requirement
12. 12 Login Process • Usable method ◦ Password + SMS ◦ SNS Auth + SMS ◦ • Not Supported ◦ Only password / only sms / passcode ◦ Because of security reason.
13. 13 Additional Authentication Process • Usable method ◦ SMS ◦ Passcode ◦ FIDO (coming soon) ◦ • Not Supported ◦ password / SNS ◦ Because of UX reason.
14. 14 Authentication Policy • Authentication Assurance Level ◦ Level 1 … require one type authentication method. ◦ Level 2 … require two types authentication method. ◦ Level 2+ … require two types of authentication method with phishing resistance. ◦ • Which authentication level is required for each action. Action Authn Level Authentication Method Login to Mercari Account Level2 Password + SMS Issuing PFAT Level2 Password + SMS Additional Authentication (Mercari/Merpay) Level1 Passcode SMS Level2 Passcode + SMS Mercoin (Use API, Critical Operation) Level2+ FIDO (with user verification)
15. 15 Problems and future • Some phishing attack is happening recently ◦ Introduce FIDO for mercari/merpay critical operation. ◦ It should be used also for Login in the future. ◦ • SMS Verification and SMS Authentication is confusing. ◦ Using same OTC and same input screen. ◦ But the purpose is different.
16. 16 Other operations • Change authentication information ◦ Email & Password ▪ Required Additional Authentication(SMS) for change. ▪ Email verification is also required. ◦ Phone number ▪ Required Additional Authentication(Email) for change. ▪ Phone number verification is also required. • Retirement ◦ It is possible to recover the account within 90 days. • Password recovery ◦ Send password reset link to registered email address.
17. 17 Introduction Authorization and Token
18. 18 Overview - service structure
19. 19 Overview - request flow Microservices use other microservices. Gateway proxies the request to each microservices. Gateway checks if the request is valid Client Application access to Backend API through Gateway
20. 20 • Gateway and Microservices have to restrict the request. ◦ Who is the requester (client / end user)? ◦ What privilege does the requester have? • Today’s Topics: AuthN / AuthZ based on Token ◦ What kind of token will be used? ◦ How to issue the Token based on AuthN / AuthZ? ◦ How to verify the Token on Gateway and Microservices? Overview - Topics related AuthN / AuthZ
21. 21 AuthN/AuthZ in Monolithic Architecture
22. 22 Old Mercari situation ( ~ 2018) A few Client applications Limited number of backend components
23. 23 Issue and Verify Mercari Access Token(MAT) A few Client applications Not so many backend components ② Verify MAT Client add the MAT on the Request to Mercari API. Mercari API checks if the MAT is valid or not. There is no fine-grained AuthZ. ① Issue MAT The MAT is issued on Mercari API. The MAT will be bound with user by AuthN(Password, SMS ...) on Login process.
24. 24 Situation is changing A few Client applications Change 1 Migration to the Microservice Architecture Change 2 Necessity of Variety clients Limited number of backend components
25. 25 AuthN/AuthZ in Microservices architecture • Mercari introduced Microservices architecture to meet the business speed. • How to handle the AuthN/AuthZ on the Microservices architecture? ◦ Where should the authentication and authorization be done? ◦ How to share the information between each microservices?
26. 26 • Mercari’s APIs are not only for Mercari App. Other Type of Clients and third party clients want to to use the APIs. • How to handle the variety of other type and party clients? ◦ How to issue and deliver the token securely for many type of client? ◦ How to control the Authorization finer grained. AuthN/AuthZ for other type/party clients
27. 27 Old Mercari situation • Summary ◦ Token issuing and verification Process is executed on Mercari API. ◦ The token is called Mercari Access Token(MAT). ◦ MAT don’t have the ability to control authorization.
28. 28 AuthN/AuthZ in Microservices
29. 29 Recent Mercari situation (2019 - 2022) Go to Microservices ! Move business logic from Mercari API to Microservices
30. 30 What is the problem on this situation 2. How to share the information between each microservices? 1. Where should we perform authentication? How to handle the AuthN/AuthZ on the Microservices architecture?
31. 31 How to solve the problem ② PAT Private Access Token(PAT) is used for sharing Authentication Information ③ Authority Verify MAT and Issue PAT ① Gateway MAT is checked on Gateway layer.
32. 32 Process to Access API ② Verify MAT and Issue PAT Gateway/Authority will request to Mercari API to checks if the MAT is valid or not. If it is valid, PAT will be issued. ③ Communication between microservices Each microservices check if the PAT is valid. Propagate the PAT to access other microservices ① Issue MAT The process is same with old Mercari situation.
33. 33 Access Control ② Microservices Each microservices should check if the requests are allowed by the claims of PAT, like subject. Not only check the verification. ① Gateway/Authority The situation is same with old Mercari situation. Just check MAT is valid or not.
34. 34 Other issuing process of PAT ① Service When a worker wants to access a microservice. The PAT is created based on Google ID Token of Google Service Account. ② Employee When an employee access to Mercari’s API from CS Tool an employee token is used as external token.
35. 35 How to handle the AuthN/AuthZ on Microservices? • Summary ◦ The MAT is used as External Token. ◦ Token issuing Process is same with old Mercari situation. ◦ Token verification Process is executed on Gateway/Authority Layer. ◦ Exchange external token (MAT) to Internal token (PAT). ◦ The Internal token(PAT) is propagated to microservices and be used AuthZ.
36. 36 AuthN/AuthZ for other type/party clients
37. 37 Recent Mercari situation (2019 - 2022) How to issue and deliver the token securely for many types of client? How to control the Authorization at a finer grained level? How to handle the variety of other type and party clients? Shops Mercoin
38. 38 Future Mercari situation (2022 - ) Mercoin
39. 39 AuthN/AuthZ based on OAuth/OIDC ① AuthZ Server Authentication and Token issuing Process is separated from clients ② PFAT The Platform Access Token(PFAT) is issued as External token , instead of MAT. Mercoin
40. 40 Process to Access API ② Verify PFAT and Issue PAT Gateway/Auth ority will request to AuthZ Server to checks if the PFAT is valid or not. If it is valid, PAT will be issued. ① Issue PFAT A PFAT is issued from AuthZ Server based on end user AuthN/AuthZ ③ Communication between microservices Each microservices check if a PAT is valid. Propagate a PAT to access other microservices. OAuth 2 … A protocol to delegate a privilege based on user consent Mercoin
41. 41 Access Control ① Gateway/Authority The PFAT has some claims to represent the AuthN/AuthZ, like subject, scope, audience. The request will be restricted based on the claims. ② Microservices Each microservices should check if the requests are allowed by the claims of PAT, like subject. Not only check the verification. Mercoin
42. 42 Difference between MAT and PFAT MAT PFAT Issuer Mercari API OIDC Server Authentication Mercari API Mercari API/web-auth-jp Authorization Authenticated or not Based on scope/audience Client Only Mercari App Any OAuth Client Sharing Authentication Impossible Possible Complexity Low High
43. 43 How to handle the variety of other clients? • Summary ◦ An external token(PFAT) is introduced. ◦ The PFAT allows us to apply fine-grained authorization. ◦ Token issuing Process is executed on AuthZ Server. ◦ Token verification Process is based on finer-grained AuthZ. ◦ The authentication method is the same with old Mercari situation.
44. 44 Summary
45. 45 Current Mercari Situation (2023/4) Mercoin
46. 46 Thank you!