Golang Web应用身份验证方案探讨

Golang Web应用身份验证方案探讨 它有一些限制，但可能满足我的需求。这个想法相当简单，不需要任何外部服务。

目标

  • 避免在客户端设备上存储“长期有效”的令牌，以防止安全漏洞
  • 允许多个单页应用（同一域名）自动进行身份验证
  • 对用户和开发者来说都很简单

可能不太适合面向大众的应用程序。

关键思想是令牌在正常处理过程中会不断变化。

基本流程步骤

  • 用户在应用程序所有者的系统中完成设置，并通过电子邮件收到令牌
  • 用户打开应用门户页面并输入令牌值（仅首次）
  • 门户网页将令牌保存到设备的本地存储中
  • 应用程序请求使用此令牌进行身份验证和识别
  • 数据（非代码）请求通过URL查询字符串值来标识
  • 这些数据请求会在响应中收到一个新令牌
  • 客户端代码替换本地存储中的令牌（最佳处理方式？）
  • 在服务器端，之前的令牌会在短时间内过期
  • 仍需找出处理同一用户多设备、错误等的最佳方式

欢迎提出任何想法、批评或建议。


更多关于Golang Web应用身份验证方案探讨的实战教程也可以访问 https://www.itying.com/category-94-b0.html

2 回复

txjmp:

用户在应用所有者的系统中设置并通过电子邮件发送令牌

我对安全方面了解不多，但我们会对令牌进行加密，然后故意将其混淆成一组独特的字符集。 服务器接收到令牌后，会将其解密回原始的通用编码。 听起来没什么用，哈哈。

更多关于Golang Web应用身份验证方案探讨的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


这是一个非常有趣的自研身份验证方案，核心是令牌滚动刷新机制。它本质上是一种自定义的、基于查询参数的单次有效令牌（One-Time Token）系统。下面我将从Go Web应用的角度，分析其实现要点、潜在问题并提供示例代码。

核心分析与关键点

  1. 安全性：通过令牌的频繁变更（滚动刷新）和短期有效期，确实能减少令牌泄露后的风险窗口。但查询字符串（URL）记录在浏览器历史、服务器日志中，敏感数据请求（如POST修改操作）绝对不应使用此方式，应仅用于GET数据请求。
  2. 实现核心：服务器端需要一个安全的令牌生成、验证和刷新机制。每个令牌应关联用户ID、过期时间，并确保旧令牌在刷新后立即或短时间后失效。
  3. 多设备处理：方案中“同一用户多设备”是可行的，但需要将令牌与设备（或会话）而非全局用户绑定。每个设备独立进行令牌滚动。

Go语言实现示例

以下是一个高度简化的示例，展示服务器端令牌管理的关键逻辑。注意：此示例未包含生产环境所需的加密签名、安全随机数生成、持久化存储等完整细节。

package main

import (
    "crypto/rand"
    "encoding/hex"
    "net/http"
    "sync"
    "time"
)

// TokenInfo 存储在服务器端的令牌信息
type TokenInfo struct {
    UserID     string
    DeviceID   string // 用于区分同一用户的不同设备
    ExpiresAt  time.Time
    NextToken  string // 可存储即将刷新的下一个令牌，用于平滑过渡
}

// 内存存储示例，生产环境应使用Redis或数据库
var (
    tokenStore = make(map[string]TokenInfo) // key: current token
    storeMutex sync.RWMutex
)

// generateToken 生成一个安全的随机令牌
func generateToken() (string, error) {
    bytes := make([]byte, 32) // 256位
    if _, err := rand.Read(bytes); err != nil {
        return "", err
    }
    return hex.EncodeToString(bytes), nil
}

// createTokenForUser 为用户创建初始令牌
func createTokenForUser(userID, deviceID string) (string, error) {
    token, err := generateToken()
    if err != nil {
        return "", err
    }
    
    storeMutex.Lock()
    defer storeMutex.Unlock()
    
    tokenStore[token] = TokenInfo{
        UserID:    userID,
        DeviceID:  deviceID,
        ExpiresAt: time.Now().Add(5 * time.Minute), // 短期有效期，例如5分钟
    }
    return token, nil
}

// validateAndRefreshToken 验证令牌并返回新令牌
func validateAndRefreshToken(oldToken string) (isValid bool, userID, newToken string, err error) {
    storeMutex.Lock()
    defer storeMutex.Unlock()
    
    info, exists := tokenStore[oldToken]
    if !exists {
        return false, "", "", nil
    }
    
    // 检查令牌是否过期
    if time.Now().After(info.ExpiresAt) {
        delete(tokenStore, oldToken)
        return false, "", "", nil
    }
    
    // 生成新令牌
    newToken, err = generateToken()
    if err != nil {
        return false, "", "", err
    }
    
    // 将旧令牌信息转移到新令牌，可立即或延迟删除旧令牌
    tokenStore[newToken] = TokenInfo{
        UserID:    info.UserID,
        DeviceID:  info.DeviceID,
        ExpiresAt: time.Now().Add(5 * time.Minute),
    }
    
    // 立即让旧令牌失效（或设置更短的过期时间）
    delete(tokenStore, oldToken)
    
    return true, info.UserID, newToken, nil
}

// 示例HTTP处理函数
func dataHandler(w http.ResponseWriter, r *http.Request) {
    oldToken := r.URL.Query().Get("token")
    if oldToken == "" {
        http.Error(w, "Token required", http.StatusUnauthorized)
        return
    }
    
    isValid, userID, newToken, err := validateAndRefreshToken(oldToken)
    if err != nil {
        http.Error(w, "Internal server error", http.StatusInternalServerError)
        return
    }
    if !isValid {
        http.Error(w, "Invalid or expired token", http.StatusUnauthorized)
        return
    }
    
    // 令牌有效，处理业务逻辑...
    // responseData := fetchDataForUser(userID)
    
    // 在响应中返回新令牌，例如使用JSON
    w.Header().Set("Content-Type", "application/json")
    // 实际响应应包含业务数据和新令牌
    response := map[string]interface{}{
        "data":  "your data here",
        "token": newToken,
    }
    // json.NewEncoder(w).Encode(response)
    _ = userID
    _ = response
}

关键问题与考量

  1. 令牌传输方式：如开头所述，查询字符串不适合敏感操作。对于更安全的方案，即使使用此滚动令牌，也应将令牌放在 Authorization 请求头中，仅将滚动后的新令牌通过响应体返回。
  2. 并发请求：在令牌滚动瞬间，客户端可能有多个并发请求携带旧令牌发出。服务器端需要处理这种竞态条件，例如为旧令牌设置一个极短的宽限期（grace period），或允许使用最近1-2个旧令牌之一进行刷新。
  3. 错误处理：当令牌失效时（如多设备登录被顶替），应返回明确的错误码（如440 Login Timeout），引导客户端重新进行门户页面登录流程。
  4. 本地存储更新：客户端在收到包含新令牌的响应后，必须原子性地更新本地存储（localStorage）。对于并发请求，可能需要使用令牌队列或锁机制来避免更新冲突。

简化版流程修正建议

  • 初始登录：门户页面提交令牌到登录端点，验证后服务器创建HttpOnly、Secure的会话Cookie（仅用于维持会话，不含敏感数据）并返回初始滚动令牌至响应体，客户端将其存入内存或localStorage。
  • API请求：客户端将滚动令牌置于Authorization: Bearer <rolling_token>头中发送。
  • 服务器响应：验证滚动令牌，若有效则处理请求，并在响应JSON体中返回新的滚动令牌。客户端随后更新其存储。
  • 会话过期：当会话Cookie过期或滚动令牌刷新失败时，用户需重新登录门户。

此方案在控制内部工具、管理后台等场景下可以工作，但若面向公众，建议优先考虑OAuth 2.0/OpenID Connect等标准协议，它们已经妥善解决了令牌刷新、多设备、安全传输等问题。

回到顶部