[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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

4. 4
   Introduction
   Account and Authentication
   

   View Slide

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
   

   View Slide

6. 6
   Registration
   

   View Slide

7. 7
   Registration Process
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

10. 10
    Authentication
    

    View Slide

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
    

    View Slide

12. 12
    Login Process
    ● Usable method
    ○ Password + SMS
    ○ SNS Auth + SMS
    ○
    ● Not Supported
    ○ Only password / only
    sms / passcode
    ○ Because of security
    reason.
    

    View Slide

13. 13
    Additional Authentication Process
    ● Usable method
    ○ SMS
    ○ Passcode
    ○ FIDO (coming soon)
    ○
    ● Not Supported
    ○ password / SNS
    ○ Because of UX reason.
    

    View Slide

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)
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

17. 17
    Introduction
    Authorization and Token
    

    View Slide

18. 18
    Overview - service structure
    

    View Slide

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
    

    View Slide

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
    

    View Slide

21. 21
    AuthN/AuthZ in
    Monolithic Architecture
    

    View Slide

22. 22
    Old Mercari situation ( ~ 2018)
    A few Client applications
    Limited number of backend components
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

28. 28
    AuthN/AuthZ in
    Microservices
    

    View Slide

29. 29
    Recent Mercari situation (2019 - 2022)
    Go to Microservices !
    Move business logic from Mercari API to
    Microservices
    

    View Slide

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?
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

36. 36
    AuthN/AuthZ for
    other type/party clients
    

    View Slide

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
    

    View Slide

38. 38
    Future Mercari situation (2022 - )
    Mercoin
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

44. 44
    Summary
    

    View Slide

45. 45
    Current Mercari Situation (2023/4)
    Mercoin
    

    View Slide

46. 46
    Thank you!
    

    View Slide