Web authentication micro-service provides the "Mercari Login" feature for web products.
It includes a web frontend service providing authentication screens like sign-in, sign-up, and related features. The frontend service has a web server that is implemented by Go and a SPA that is implemented by React and Typescript.
It also includes a backend service that is implemented by Go and provides reCAPTCHA functionality and API access token handling on top of Mercari’s monolith API service for the web.
To be independent
In the beginning, the authentication-related screens are implemented within the new Mercari web application, but finally we decided to create an independent service for the following the consideration:
The new Mercari web is decided to use JAMStack architecture without a dynamic web server, but for authentication-related screens sometimes a dynamic web server will be needed, such as handling the callback of social sign-in.
We would like to provide a Single Sign-On service within the Mercari group. Creating an independent service can make it easier to be maintained and it also follows the mercari camp structure.
Migration to OpenID Connect
The existing auth token was designed a few years ago, and it does suit the current situation of Mercari. It has few problems:
- It is a stateful token and not designed for micro-service architecture. Every API calls need to access a centralized database to authenticate the token, so it makes it difficult to scale out.
- The authorization scope is not able to be handled with it, so it is difficult to delegate privileges for 3rd party applications.
- It requires using refresh_token to get a new valid access_token. But for the web scenario, it is hard to handle the token refresh because it is not secure to store refresh_token in the browser.
For solving all of the above problems, we decided to use a new token that follows the OpenID Connect spec to replace the existing auth token.
What is OpenID Connect (OIDC) and why do we use it?
OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It is an open standard and decentralized authentication protocol (for knowing more about OIDC you can check on auth0). By following this standard, we will get the benefit of:
- Developers can focus on business value instead of security and it will make the transition to new standards smoother in the future if needed.
- Since it uses JWT, the token is stateless and could be verified without the centralized database. It makes our system more scalable.
- It has the spec of scope, which makes it possible to delegate to 3rd party applications.
- IDP service is able to refresh the token by validate the cookie so it is safer and easier for web to use. Also it makes it possible to achieve SSO (Single Sign-On).