Slide 1

Slide 1 text

1 Mercari app access token: from proprietary to OAuth 2.0 / OIDC based OpenID Summit Tokyo 2024 Mercari, Inc. - Identity Platform Team Gia Nguyen

Slide 2

Slide 2 text

2 Mercari Identity Platform Agenda Issues of Mercari Access Token Access token migration Migration stories 02 03 04 01 Migration result 05

Slide 3

Slide 3 text

3 Mercari Identity Platform

Slide 4

Slide 4 text

4 Past Mercari architecture - beginning Token issuing and verification are done by Mercari API MAT: Mercari Access Token

Slide 5

Slide 5 text

5 Past Mercari architecture - microservices Token issuing and verification still be done by Mercari API MAT: Mercari Access Token PAT: Private Access Token

Slide 6

Slide 6 text

6 Issues of Mercari Access Token

Slide 7

Slide 7 text

7 Issues of Mercari Access Token The token is issued and verified based on a proprietary spec ● Hard to maintain and extend ○ E.g. apply security best practices ● Long expiration and ultimate permission ● Issued and verified by legacy monolith service. ○ This service is shared and any developer can make changes to it

Slide 8

Slide 8 text

8 Basic approach Move from proprietary spec to OAuth 2.0 / OIDC based spec ● Wide adopted specs make it easier to maintain and handle extra requirements ● More control on expiration and permission setting ● Completely owned by IDP team

Slide 9

Slide 9 text

9 Access Token Migration

Slide 10

Slide 10 text

10 About access token migration Migrated access token for web Also considered for native app but postponed 2021 Migrated access token for native app 2023 2018 Started developing authorization server Initial purpose is for 3rd parties authorization

Slide 11

Slide 11 text

11 Desired architecture Token issuing and verifying are done by authorization server PFAT: Platform Access Token

Slide 12

Slide 12 text

12 Consideration points ● Authentication and token issuing process ● Solutions for various request patterns ● Specifications ○ OAuth 2.0 for Native Apps ○ OpenID Connect Native SSO for Mobile Apps 1.0 ○ OAuth 2.0 Token Exchange ○ Implementing App-to-App Authorisation in OAuth2/OpenID Connect ○ OAuth 2.0 Security Best Current Practice ○ …

Slide 13

Slide 13 text

13 Authentication and token issuing process ● Use in-app browser as the user-agent and store authentication session into cookie ○ So users don’t need to re-login in different webs/apps

Slide 14

Slide 14 text

14 Request patterns

Slide 15

Slide 15 text

15 Migration stories

Slide 16

Slide 16 text

16 Already logged in users are able to do SSO without re-login Migration stories Support webview with better token management Authentication session should be alive if users keep using the app 02 03 01

Slide 17

Slide 17 text

17 Already logged in users are able to do SSO without re-login

Slide 18

Slide 18 text

18 Requirements ● Already logged in users should use new token ○ Directly exchanging old token to new token is one option ● Already logged in users are able to do SSO to other apps/webs ○ Need to create and store auth session to browser in Mercari app beforehand ● Asking users to re-login inside in-app browser is not acceptable ○ Users are already logged into native side ○ Need to inherit the auth session

Slide 19

Slide 19 text

19 Seamless migration Create a short-lived credential (PoA) and pass to /authorize endpoint

Slide 20

Slide 20 text

20 Support webview with better token management

Slide 21

Slide 21 text

21 Webview is unavoidable ● Session is shared to the browser, so open every web page by external browser is basically feasible ● But using webview is still preferred in some cases ○ Better UI/UX (e.g. customizable header/footer) ○ Easier for information sharing between native and web

Slide 22

Slide 22 text

22 Webview use cases

Slide 23

Slide 23 text

23 Webview that get token from native Native performs a token exchange to obtain a less privileged token and send to webview

Slide 24

Slide 24 text

24 Webview that get token from authorization server Mechanism didn’t change, but with better credential

Slide 25

Slide 25 text

25 Authentication session should be alive if users keep using the app

Slide 26

Slide 26 text

26 ● Users should be asked for re-login if don’t use the app for a period of time ○ Can be controlled by refresh token and authentication session expiry ○ Those expiry can’t be very long ● But if users keep using the app, the authentication should be kept alive ○ Be able to do SSO to other webs/apps ○ Authentication session needs to be extended Requirements

Slide 27

Slide 27 text

27 ● Control authentication session expiry in server side ○ Cookie expiry needs to be set to long value ● Extend session when native app refresh token is used Solution

Slide 28

Slide 28 text

28 Some browsers have limit of cookie lifetime ● E.g. Chrome only allow 400 days as max ● Not resolved yet Challenge

Slide 29

Slide 29 text

29 Migration result

Slide 30

Slide 30 text

30 Migration result ● The access token used in Mercari app has been migrated to new one in recent app versions ● For iOS, final milestone was released. ○ You can try Sign in with Passkeys! ● Android final milestone will be released soon.

Slide 31

Slide 31 text

31 Migration result - achievements ● Able to proceed projects that prevented by old spec ● The token issuing and verification is independent from an old monolith ● Token expiration and permission were set more properly ● Authentication sessions is shared, reduced the number of re-login failed error ● Easier to improve or extend authentication feature

Slide 32

Slide 32 text

32 Thank you for listening!