用 YouTeacher 登录商店：SSO 中转与 WooCommerce 用户建档

商店（一个 WooCommerce 站点）自己不保留登录。它是中心化 YouTeacher 账号服务的一个第一方客户端，任何一次登录最终都归结到同一个 YouTeacher 身份。正是这一点，让在商店里完成的购买，能变成桌面 Authenticator 和网页版之后可以读回的权益（entitlement）：订单绑定的是 YouTeacher 账号，而不是某个商店本地密码。

商店作为受信客户端

因为商店是第一方、而非匿名浏览器，账号服务把它当作受信客户端，不让它走访客要面对的人机校验那一步。商店用一份只存在于其部署环境、且短时效的凭据向账号服务证明"我就是商店"。这就是那道信任缝：账号服务信任商店，商店替终端用户作保。

两条入口

重定向式 SSO（首选）。"用 YouTeacher 登录"把访客送到主 app 去那边认证，然后带着一个一次性授权 code 回到商店。商店经由 games BFF 拿这个 code 去换回 YouTeacher 身份。关键性质是：商店从不经手密码——认证发生在 YouTeacher 自己的界面上。

直接登录（兑底）。一条次要路径让商店代用户把凭据转发给账号服务。因为这条路在传输中确实碰到了密码，所以重定向流程才是默认，登录页上 WooCommerce 自带的用户名/密码表单被整个隐藏掉。

建档本地用户

无论哪条流程完成认证，商店接下来都会以 YouTeacher 邮箱为键，查找或创建一个本地 WooCommerce 用户。已存在该邮箱的账户就复用；否则新建一个 customer 角色的账户。本地没有可用密码，因为本地密码登录根本不存在。以邮箱为键——而不是某个商店内部 id——是刻意的：权益查询和"My Games"列表用的是同一个键，因此也能对上用该邮箱下的访客订单（guest order）。

静默自动登录

仅在账户页和结账页，一个已登录 YouTeacher、却还没登录商店的访客，会无需点击地被登进来：商店做一次静默授权尝试，走完同样的身份交接。这个设计唯一的隐患是——当上游根本没有会话可找时会出现重定向死循环，所以一个每浏览器会话一次的守卫保证这次尝试每会话至多一次；若没找到会话，商店就正常渲染。一次显式的商店登出会触发同一个守卫，于是登出对本会话是粘住的，不会被自动登录抵消。机器人和爬虫被整套流程排除在外。

为什么长这样

一个身份，多个界面。商店、桌面 Authenticator、网页版都要回答"这是谁、他拥有什么？"。把商店做成一个薄薄的认证客户端、而非认证权威，YouTeacher 账号就始终是身份的唯一来源；商店本地唯一的活，就是把这个身份镜像成一个 WooCommerce 用户，好让 WooCommerce 自己那套订单与权益机制挂靠上去。