Introducing 3 Architecture Patterns for Linking In-house Service User IDs with LINE User IDs.
The original of this article is available from the link below.
Introduction
Connecting the user IDs of organization's own services with LINE user IDs will allow company to conduct more effective marketing solutions and improve application UX.
For example, in the case of a retail company, by linking a LINE user ID to a user ID that exists in POS data (e.g., membership card ID), it is possible to send LINE push notifications based on the user's purchase information. Unlike email, LINE push notifications have a high open rate, making it possible to effectively deliver information to the users your organization wish to reach. The only requirements for receiving these notifications are that the user has LINE App installed on their device and is friends with the organization's official LINE account. Using LINE Official Account(LINE OAM) makes it a low hurdle for companies to overcome to reach these notifications to their targeted customers.
In order to implement the above measures, it is necessary to link the user ID of the company's service with the user ID of LINE. In this article, we would like to introduce three ways to achieve this. We will assume that the application used for linking is the LINE Mini-App/LIFF application (hereafter referred to as "LINE Mini-App" for convenience).
If you have a better method other than the ones introduced in this article, we would be happy to hear about it in the comments (we always check Twitter for reader's feedbacks).
Method 1: Use OAuth 2.0/OpenID Connect
This method uses OAuth 2.0/OpenID Connect to link IDs obtained through OAuth 2.0/OpenID Connect. In this method, the ID/PW of the company's ID infrastructure is not sent to the back-end system of the LINE Mini-App, but the AccessToken/IDToken will be sent, allowing the company's ID to be securely acquired/verified and linked to the LINE user ID.
In request 2 in the diagram, in addition to the Token obtained from the company's ID infrastructure, LINE's Token information obtained by liff.init() is also sent. The request’s Authorization header contains LINE's Token information, and the Body contains Token information obtained from the company's own ID infrastructure.
If your organization's ID infrastructure has OAuth 2.0/OpenID Connect endpoints, this method will be a good choice. However, since this method is dependent on the LIFF SDK (which we believe is highly unlikely to happen) However, since this method depends on the LIFF SDK, there is a possibility that it may not work properly due to version upgrades of the LIFF SDK.
Method 2: Calling the API of your Own Identity Infrastructure from the Backend of the LINE Mini-App
This method calls the company's ID infrastructure API from the LINE Mini App back-end system to verify IDs. This method requires the user to enter information for ID verification in the LINE Mini App.
In this method, the following two points need to be considered.
- How to connect the APIs
- Routing options (via the Internet or leased line?)
- How to authorize the requests? (Client Credentials Flow, API Key, etc.)
- What constitutes OK authentication?
Especially the latter should be deeply considered. Select the user input items after considering the possibility of being able to link with someone else's information and the risks involved if this were to happen.
Method 3: Inject your Company's ID Infrastructure Information into the LINE Mini-App Backend System in Advance
By feeding information on the company's ID infrastructure into the back-end system of the LINE Mini-App in advance, the ID can be verified only within the back-end system.
This method also requires consideration of "what constitutes OK for authentication".
In the case of this method, the company's ID infrastructure only needs to export the key information to CSV, etc. and link it to the back-end system. Therefore, the cost of creating an ID link from scratch is often the lowest. However, there is a time lag in the reflection of data, which may cause inconvenience to users. In addition, if the ID infrastructure is not able to capture the data with updated differences, it will be necessary to rewrite the table each time, so it is necessary to be aware of the cost of capturing the data into the DB.
Conclusion
| Method | Recommendation | Comments |
|---|---|---|
| Method 1: Use OAuth 2.0/OpenID Connect | ★★★ | This is the most simple and recommended option among those 3 methods if your identity infrastructure supports OAuth 2.0/OpenID Connect |
| Method 2: Calling the API of your Own Identity Infrastructure from the Backend of the LINE Mini-App | ★★ | This method can be painful if your organization's system requires dedicated line to connect APIs. |
| Method 3: Inject your Company's ID Infrastructure Information into the LINE Mini-App Backend System in Advance | ★ | It is easy to implement as a system. On the other hand, it is most likely to cause inconvenience to users. Depends on what kind of application to be provided. |
Most of the case, we recommend method 1. However, it seems like there are not many cases where the existing identity infrastructure supports OAuth 2.0/OpenID Connect. In such cases, we would like you to choose the most appropriate method considering the impact on users, development cost, system complexity, etc.
If you feel that it is too difficult to build your own system by yourself, or you would like more advice on your own system, please feel free to contact us at LINE Service General Support.
