LINEログインで同意をキャンセルされたら｜ACCESS_DENIEDと不具合を分ける

LINEログインの同意画面でキャンセルされた場合は、ログイン成功とは別の結果として受け取り、元の案内へ戻れるようにします。ACCESS_DENIEDをすべてシステム障害として表示したり、戻った瞬間に自動で同意画面へ送り直したりすると、使う人は自分の判断が受け付けられていないと感じます。

この記事は、ウェブアプリにLINEログインを組み込む担当者向けです。LINEログインの成功が、予約や問い合わせの受付完了までを意味するわけではない点も分けて確認します。

認可コードを受け取った場合と、拒否された場合を分ける

LINEログインの公式ガイドでは、ユーザーがアクセス権を付与すると認可コードを含むレスポンスが返り、拒否するとエラーレスポンスが返ります。ACCESS_DENIEDは、同意画面でキャンセルし、アクセス権の付与を拒否したことを表すエラーコードです。

戻り先へ着いた、という事実だけでログイン成功を判定しないようにします。見るべき項目は次のように分かれます。

エラーレスポンスではstateが任意項目とされているため、必ず返ると決めつけない実装も必要です。成功側ではstateの検証が必要です。実際の認可コード、トークン、コールバックURL全体を、公開する調査資料へ載せる必要はありません。

LINEログインの結果を分ける判断図。認可コードを受け取った場合はstate照合など成功側の処理を検証し、ACCESS_DENIEDは同意のキャンセルとして成功へ進めない。別のエラーは原因を確認し、相手が選ぶまで自動再ログインを繰り返さない。ログインと予約・問い合わせの受付完了は別。

図はウェブアプリ側の結果の扱い方です。認可コードを受け取っただけでログイン確認や業務の受付がすべて完了するわけではありません。

架空の案内例なら「LINEログインは完了していません。内容を確認して続ける場合は、もう一度ログインを選んでください」と表示し、説明ページへ戻る操作も用意します。実際に別の受付手段があるサービスなら、その入口も示せます。

ここで「予約が完了しました」や「問い合わせを受け付けました」と表示するのは避けます。ログイン前に入力した内容が残るか、再入力が必要かも、自社の実装に合わせて説明します。入力を保存していないのに「内容は保存されています」と案内しないことが大切です。

受付方法がLINEログインに限られるなら、その条件は操作前に説明します。提供していない電話・有人対応・別ログインを、逃げ道として架空に用意するのではなく、実在する選択肢で判断できるようにします。

同意画面で今回の操作をキャンセルすることと、以前に許可したアプリの連動を解除することは、確認する場面が異なります。

連動アプリの管理についての公式説明では、同意を取り消すとアクセストークンとリフレッシュトークンが無効になり、再びログインする際に同意画面が表示されるとされています。過去に取得した情報があるからといって、現在も同意が有効だと推測しないようにします。

友だちのブロックやサービスの退会とも区別が必要です。関連する判断はLINEのアカウント連携解除を参照できます。メールアドレスの取得条件を見直す場合は権限と同意の確認で、必要な目的と取得範囲を確認します。

公開前のテストでは、承認されたテストアカウントで、同意して続ける、キャンセルする、戻り先から説明へ戻る、本人の操作で再試行する、という流れを確認します。キャンセル後に同意画面へ戻り続ける、不正な戻りを成功扱いする、ログインしただけで業務の受付完了にする、といった結果がないかを見ます。

担当へ渡す確認メモは、開始した画面、返った結果の種類、戻った画面、表示された案内、次に選べる操作に絞れます。顧客の個票や秘密値を共有しなくても、相手が止まった場面を調べることはできます。