Azure App Service内置Google认证后如何获取Token并关联用户账号

1. Token获取相关说明 #

你用的是App Service内置认证（Easy Auth），完全不需要自己实现OAuth授权码换Token、Token校验的整套流程，App Service已经在网关层完成了和Google的全部认证交互，你直接从请求上下文里拿已经校验完成的身份信息和Token即可。
具体获取方式：

• 服务端（Express侧）：所有转发到你Node服务的请求，App Service会自动注入两类专用请求头：
  • X-MS-CLIENT-PRINCIPAL：Base64编码的JSON串，解码后就是当前登录用户的完整身份信息，包含登录提供商、Google侧用户唯一ID、邮箱、姓名、头像等授权字段
  • X-MS-TOKEN-GOOGLE-ACCESS-TOKEN、X-MS-TOKEN-GOOGLE-REFRESH-TOKEN：如果你需要调用Google的开放API（比如读Google Drive、日历数据），直接读这两个头拿对应Token即可，不需要自己走刷新流程，App Service会自动帮你维护Token有效期
• 前端侧：直接发GET请求到站点根路径下的/.auth/me端点，就能拿到当前登录用户的身份信息和可用Token列表，不需要额外传鉴权参数，App Service会自动识别当前会话的登录态返回对应内容。

Express端解析身份信息的最小实现代码：

const express = require('express');
const app = express();
app.use(express.json());

// 登录态校验中间件，直接挂在需要鉴权的路由前面
function authMiddleware(req, res, next) {
  const principalHeader = req.headers['x-ms-client-principal'];
  if (!principalHeader) {
    return res.status(401).send('请先登录');
  }
  // 解码身份数据，这部分数据是App Service校验过的，可直接信任
  const principal = JSON.parse(Buffer.from(principalHeader, 'base64').toString('utf8'));
  req.authInfo = {
    provider: principal.provider, // 这里值固定为google
    providerUserId: principal.user_id, // Google侧用户唯一ID，永久不变
    email: principal.claims.find(item => item.typ === 'email')?.val,
    displayName: principal.claims.find(item => item.typ === 'name')?.val,
    accessToken: req.headers['x-ms-token-google-access-token']
  };
  next();
}

// 测试接口：获取当前登录用户信息
app.get('/api/me', authMiddleware, (req, res) => {
  res.json(req.authInfo);
});

app.listen(process.env.PORT || 3000);

2. 登录身份绑定自定义用户名的数据库落地方案 #

你完全不需要担心数据库配置和Token逻辑不兼容——内置认证层和你的业务数据库是完全解耦的，按下面步骤实现不会有兼容问题：

• 第一步：确定关联键。不要用邮箱作为用户唯一标识，用「登录提供商名称 + 提供商侧用户ID」的组合作为关联本地用户数据的唯一键，也就是上面代码里拿到的provider和providerUserId字段，这个值不会因为用户修改Google邮箱、修改昵称发生变化，是最稳定的关联依据。
• 第二步：设计最小化用户表，初期不用搞复杂字段，核心字段如下：
  • id：主键，用自增ID或者UUID都可以
  • auth_provider：字符串类型，存登录提供商，比如当前场景存google
  • auth_provider_user_id：字符串类型，存Google返回的用户唯一ID
  • custom_username：字符串类型，存用户自定义的用户名，初始值为空
  • created_at、updated_at：时间戳字段，记录用户创建和信息更新时间
    记得给auth_provider和auth_provider_user_id加联合唯一索引，避免重复创建用户。
• 第三步：补全自动登录/注册逻辑。在刚才写的authMiddleware里加一段数据库查询逻辑：解析完req.authInfo之后，拿auth_provider和auth_provider_user_id去用户表里查匹配记录：
  • 查到记录：把本地数据库里的用户信息（包括自定义用户名）挂到req.currentUser上，直接放行
  • 查不到记录：自动在用户表里插入一条新记录，custom_username留空，把新生成的用户数据挂到req.currentUser上放行
• 第四步：实现用户名绑定接口。写一个POST接口，路由挂在authMiddleware后面，接收用户提交的用户名参数，先做长度、字符规则校验，再查库确认用户名没有被其他用户占用，校验通过后直接更新当前登录用户对应数据库记录的custom_username字段即可。整个过程不需要操作任何认证相关的Token，身份校验已经在网关层和中间件里完成了。

注意：不要在业务代码里自己实现Google OAuth回调、不要自己手动校验Google Token的签名和有效性，App Service的内置认证层已经拦截了所有未授权、Token伪造、Token过期的请求，只要请求能到达你的Express服务，对应的身份信息就是可信的。

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