My impression: Oh! Thanks a lots Mr.Wei Wang. I won’t do like this again :D
If you reach here unintentionally, you can refer to the session in LINE DEVELOPER DAY holding on 25–27 November 2020 to learn more.
This session is break into 3 mention parts:
1. Introduction to LINE SDK
What is LINE SDK?
LINE SDK is the software development kit that providing a modern way of implementing LINE Login and LINE APIs on mobile platforms.
It composes by three main parts including:
- LINE Login: provide easy way to login. LINE Login is the core function and functionality of LINE SDK helping to get the trusted user information and access token to use other LINE APIs
- LINE APIs: provide the interface for application to talk to LINE service
- Built-in UI: provide a lot of built-in UI for developer to simplify their application
How about the versioning so far?
2. What’s New with LINE SDK
There are about five new mention things in LINE SDK this year:
— 1) One-Time Sharing — sending message from our app to LINE
How it’s workflow?
Follow the following step:
1. Create a message in any type such as
2. Choose destination —LINE SDK has already built-in UI for friends/group picker, so it is not necessary to create our own UI for use to pick who or where to send the message to. We can use the built-in UI everything will handle for us.
3. Send message — if using built-in UI then just follow UI, but if using own customized UI we need to call message API to send the message to the destination
But in order to complete the flow there are few requisites for permission:
— 2) LINE OpenChat — can be created and joined via LINE SDK
Note: Open Chat is a talk room for common interest and topic make a group without the friend relationship.
How it’s workflow?
→First, user puts room information to LINE SDK
→LINE SDK collection room information and send to LINE Sever
→LINE Server create and send back Room ID and URL to LINE SDK
→LINE SDK delivery Room ID and URL to user
→finally user can use URL to open OpenChat Room
But in order to complete the flow there are two requisites:
— 3) Localization for Web Login
Support localization language
—4) Better OAuth Compatibility — using PKCE
The previous technique is using One Time Password (OTP). But now using another standard called Proof Key for Code Exchange (PKCE) for identify user when exchanging access token when login. The PKCE is same security level but it is full OAuth 2.0 compatibility.
— 5) New Refresh Token Model in LINE SDK — Refreshable Model
There are two tokens using in SDK including access and refresh token. Access token is used to access resource while refresh token is used to get new access token if access token is expired. The access token for LINE SDK is valid for 30 days after issuing,refresh token for previous model is valid for 90 days, and refresh token for new model is valid for 40 days after issuing.
The new opt-in refresh model is Refresh-able Model. Let’s see what different between default model and the new one:
- Default Model — refresh token is valid for 90 days after issuing. During 90 days if access token is expired, the new access token is issued by using this refresh token, so we no need to login to app again. But after that 90 days refresh token cannot be use any more so if access token is expired, new authorization is required that mean we need to login again.
- Refreshable Model — refresh token valid for 40 days. It is same default model, if access token is expired, the valid refresh token is used to issue new access token. But it is different from default model, when issuing new access token this model also issue new refresh token as well. That’s mean we will have new both refresh and access token. Thus if we using app and using this model we will never logout. But in order to use this model let see below note.
Note about both models:
- Default model is set to be default for all channels — for general use cases — existing implementation not affected
- Refreshable model is require special feature license — for frequency users and situations — LINE SDK upgrade is not needed
3. Best Practices with LINE SDK
- Do not send user profile from client to server, but send “access token” to sever and let server get those information from LINE server directly — Doing this way to ensure that the user profile is exactly correct because it is authorized information from LINE by using access token to get it. But if we get information in our client and send to server, our app can be malformed and anyone can send these kind of request to our server that why those information from our client cannot be trusted.
- “ID Token” is also a choice if we only need to identify user instead of using other LINE APIs— ID Token is JWT that have payload user identity information inside. So we can trust and use that information after verify via any of these two ways:
- Use Universal Link — this can prevents URL scheme hijacking. Anyways, I never use this, better refer to mentioned documentation to learn more: https://developers.line.biz/en/docs/ios-sdk/swift/universal-links-support/
- Do Not Refresh Token on Your Server — it sounds like, it works don’t touch it. :) Even we also can refresh LINE access token on our server but it is not recommended. Just leave it to LINE SDK auto refreshing.
- Verify the Login — Keep in mind to read and understand documents while using them:
Creating a secure login process between your app and server
Use ID Token in LINE SDK
Verify Access Token (the URL showing in presentation is not found)
Verify ID Token (the URL showing in presentation is not found)
Conclusion
This session is quite interesting not only for whom having experience with LINE development but also for any newbie to grab some ideas to use in their work. Even I could not catch all parts of the session but it gives me some idea for improving my next application with LINE.
Session Reference
https://www.youtube.com/watch?v=exXCQiOKv9k&list=PLI2S-k0Fa59u6PxOtXkEtkkH9QLNaidys&index=28
