LINE登录原生应用SDK为何推荐OAuth2.0隐式流而非授权码流？

接入背景 #

• 近期我在iOS原生应用中基于OAuth 2.0协议接入LINE登录、Sign In With Apple能力，实现便捷的注册/登录功能。
• 给不熟悉LINE的开发者补充背景：LINE是同名即时通讯产品的运营厂商，旗下Messenger产品月活跃用户规模超2亿。

OAuth 2.0原生接入的通用规范 #

OAuth 2.0协议中，从授权服务器获取访问令牌的流程主要分为两类：

• 授权码许可流程（Authorization Code grant flow）
• 隐式流（implicit flow）

苹果及绝大多数OAuth 2.0服务提供商均优先支持授权码许可流程，核心原因是该模式安全性优于隐式流，且支持获取刷新令牌（refresh token），而非仅能获取访问令牌（access token）。授权码流是OAuth 2.0规范中更受推荐的访问令牌获取方式。

RFC 8252第8.2节明确说明：由于隐式流无法通过PKCE [RFC7636]（该规范第8.1节要求原生应用必须使用PKCE）提供安全防护，不推荐原生应用使用隐式流。

LINE原生登录的实现差异 #

根据LINE开发者文档说明，其并不面向原生应用推荐适用于Web端的授权码流程：

若您的开发环境有对应可用的LINE SDK，我们强烈建议通过LINE SDK集成LINE登录功能，不推荐原生应用使用本页描述的（Web端授权码）集成流程，SDK集成方式请参考原生应用集成相关文档。

通过LINE SDK实现登录的交互逻辑为：用户点击登录按钮后直接唤起LINE客户端的授权页面，授权完成后通过通用链接（universal link）跳转回第三方应用，回调参数中直接返回访问令牌，而非授权码。

LINE官方提供的iOS Swift SDK登录示例代码如下：

// LoginViewController.swift

import LineSDK

class LoginViewController: UIViewController {    
    func login() {
        LoginManager.shared.login(permissions: [.profile], in: self) {
            result in
            switch result {
            case .success(let loginResult):
                print(loginResult.accessToken.value) // 可从loginResult中直接获取accessToken
            case .failure(let error):
                print(error)
            }
        }
    }
}

LINE官方同时给出了原生端LINE登录的OAuth 2.0、OIDC流程示意图：

• OAuth 2.0流程图：
• OIDC流程图：

待解答的疑问 #

• 按照OAuth 2.0相关规范，隐式流不推荐在原生应用场景使用，LINE为何在OAuth 2.0登录SDK实现中采用直接返回令牌的类隐式流设计？
• 是否是因为LINE要求开发者在使用令牌前必须调用访问令牌/ID令牌校验API，因此判定该方案具备足够安全性？
• 作为拥有大量资深技术工程师的大型科技企业，LINE不太可能推荐存在明显安全缺陷的方案，是否存在我遗漏的设计层面考量？
• 我个人的初步猜测：LINE是刻意为原生端设计了这套流程——其本身也知晓Web端使用的授权码流的存在，可能认为只要业务服务端始终调用ID令牌校验API获取用户信息、或在使用访问令牌前先调用对应校验接口，而非直接解析ID令牌中携带的数据，这套流程就满足安全要求？该猜测是否成立？

内容的提问来源于stack exchange，提问作者Sean Hwang