Commit 561fea469014cd8c02cc506cf9cb094a0af16b60

Authored by Matti Virkkunen
1 parent 0d9b75a0

Proper path for login request. More details about account verification.

Showing 1 changed file with 21 additions and 16 deletions
line-protocol.md
... ... @@ -90,7 +90,9 @@ It serves files over both HTTP and HTTPS with the same authentication protocol a
90 90 Login procedure
91 91 ---------------
92 92  
93   -This Thrift method issues a new authToken for an e-mail address and password combination:
  93 +This Thrift method issues a new authToken for an e-mail address and password combination. The
  94 +request should be sent to the path /api/v4/TalkService.do to avoid having to specify an auth token
  95 +when none exists yet (/S4 always requires an auth token).
94 96  
95 97 loginWithIdentityCredentialForCertificate(
96 98 IdentityProvider.LINE, // identityProvider
... ... @@ -99,21 +101,20 @@ This Thrift method issues a new authToken for an e-mail address and password com
99 101 true, // keepLoggedIn
100 102 "127.0.0.1", // accesslocation (presumably local IP?)
101 103 "hostname", // systemName (will show up in "Devices")
102   - "") // certificate
  104 + "") // certificate (empty on first login - see login verification procedure below)
103 105  
104   -For the login request, the X-Line-Access header must be specified but the value can be anything. The
105   -result structure is as follows:
  106 +The result structure is as follows:
106 107  
107 108 struct LoginResult {
108 109 1: string authToken;
109   - 2: certificate;
110   - 3: verifier;
111   - 4: pinCode;
112   - 5: i32 type;
  110 + 2: string certificate;
  111 + 3: string verifier;
  112 + 4: string pinCode;
  113 + 5: LoginResultType type;
113 114 }
114 115  
115   -After a successful login, the type is equal to 1 and the authToken field contains the X-Line-Access
116   -value to use in subsequent requests.
  116 +After a successful login, the type is equal to SUCCESS (1) and the authToken field contains the
  117 +X-Line-Access value to use in subsequent requests.
117 118  
118 119 The official desktop client sends an encrypted e-mail/password involving RSA and no X-Line-Access
119 120 header, but it works just as fine in plain text. (TODO: Include description of RSA login procedure)
... ... @@ -122,12 +123,14 @@ Login verification procedure
122 123 ----------------------------
123 124  
124 125 In current versions, LINE now requires you to verify your identity using a PIN code when logging in
125   -to a desktop client for the first time from a "new location" based on geo-IP. This is obviously also
126   -required when logging in with the desktop client for the very first time.
  126 +to a desktop client for the first time. It seems this is partially based on geo-IP, as clients that
  127 +had logged in before the verification procedure was added do not need to verify themselves. New
  128 +logins will all likely need to be verified.
127 129  
128   -When PIN verification is required, the login method returns a type of 3 instead of 1. The pinCode
129   -field contains a PIN code to display to the user and the verifier field is set to a random token
130   -that is used to identify this verification session. The token stays the same for the whole process.
  130 +When PIN verification is required, the login method returns a type of REQUIRE_DEVICE_CONFIRM (3)
  131 +instead of SUCCESS (1). The pinCode field contains a PIN code to display to the user and the
  132 +verifier field is set to a random token that is used to identify this verification session. The
  133 +token stays the same for the whole process.
131 134  
132 135 The client then issues an empty request to the HTTP path /Q with the X-Line-Access header set to the
133 136 verifier token. This request blocks until the user enters the correct PIN code on their mobile
... ... @@ -149,7 +152,9 @@ A success response from /Q is JSON containing the following:
149 152  
150 153 After this response is received the client issues a loginWithVerifierForCertificate() call with the
151 154 verifier token as the parameter. The server then returns a normal LoginReply message with the usual
152   -authToken.
  155 +authToken. The LoginReply message also contains a certificate value (random hex string) which should
  156 +be stored and used in future calls to loginWithIdentityCredentialForCertificate() to skip the
  157 +validation step. If the certificate is not used, every login will prompt for PIN verification.
153 158  
154 159 If the token has already expired the response from /Q looks like the following:
155 160  
... ...