项目地址

https://github.com/userwanyong/auth-service

项目背景

我为什么要开发这个认证授权服务呢？以及为什么我不直接使用现成的开源项目，而要动手自己实现？

1. 因为我近期写了两个项目，恰好这俩都是倾向于核心功能（对于抽奖，直接跳转到抽奖界面；对于AI服务，直接进行对话），对于用户登录，鉴权之类的一点都没做。考虑到要将两个小项目部署上线，不管站在项目完成度和防止恶意攻击等方面，用户登录与鉴权肯定是要做的，但是吧……你要同时给两个项目分别编写同一套类似逻辑的功能，属于重复工作了，于是突发奇想，为什么我不做一个统一的服务供它俩使用呢？还可以对接我以后的其他项目，岂不美哉，话不多说，直接开干！

关于我为什么不用已有的开源项目，有以下几方面原因：

1. 首先，市面上已有的开源项目比如sa-token确实做的很好，功能丰富，但有一个问题就是它是面向多功能场景的，而我现在的两个项目只需要认证和授权，其他功能暂时用不到。于是就有了自己实现一个轻量、可控、按我的需求定制化的服务开发的想法
2. 其次，作为一个正在准备秋招的我来说，多做几个项目肯定是有利的，万一火了呢（哈哈，梦想很美好……）。并且，据我了解，很多企业都是根据自己的业务定制化开发服务，毕竟自己开发的可以灵活拓展新功能，安全性强啊
3. 最后，顺便试试glm这匹黑马从零到一实现一个项目的可行性，看看是否真的有网传的效果，看看是否对得起仅次于claude的超高评分

项目定位

这是一个轻量级项目，主要功能是提供认证授权的rpc接口供其他服务调用以及统一管理，支持多租户；采用Java开发后端，对于前端的管理界面保持http接口通信，不引入vue/react等框架，使用原生的html/css/js，确保足够轻量，减轻部署压力

开发环境

1. glm-4.7+claude code 开发认证授权服务
2. glm-5-turbo+cc 用于对接两个线上项目

AI辅助确认需求

按部就班的规矩肯定要有调研，可行性分析等，既然我已经有该项目详细的定位，有了详细的需求，就直接开始吧，至于提示词就写的简单广泛一点，让AI自由发挥（其实是我偷点懒）

我要做一个有关登录、权限校验的微服务，请你检索市面上的相关服务（顶级开源项目等），列出我还需要支持哪些功能

然后经过一系列网页搜索、开源项目搜索/读取等操作，给出了一份详细的开发计划，审核AI给出的方案后，执行编码

等待了十几分钟后，已经完成了编码工作，我内心狂喜，点击小绿三角启动！

结果迎接我的是报错，默认使用的是JPA，这…… （咳咳，可能是我看方案的时候漏看了😣）

这里我让他改为主流的Mybatis框架

现在你需要将数据操作层换为mybatis，并遵循mapper包的形式

第二次成功启动✅️ 进入紧张的测试环节

测试验收

• 测试注册功能：成功注册用户并为他分配默认角色，注册功能验收通过！（节省点空间，后面的测试结果就不截图了）

• 失败：登录、刷新访问令牌
• 成功：登出、修改密码、删除用户、搜索用户、分配角色、更新用户状态、创建角色、更新角色、删除角色、根据编码获取角色、为角色分配权限、获取所有权限、创建权限、获取权限详情
• 部分成功：获取当前用户信息、获取所有角色、获取角色详情
• 漏写：删除权限

接下来就要修复bug了，别贪！别贪！先提交一下代码到git，然后开新窗口进行专项修复，保证现有代码可用，保证AI具有充足的上下文（我可是踩过坑😭…… 有一次cc给我代码回滚了一半，所有代码直接废）

这时候有人就问了，之前开发的记忆怎么办，我的答案是，在AI进行方案设计的时候保存一份设计文档、以及后续每次变更优化都要保存一份，用于开新会话时提供充足的上下文信息给AI，保证它了解当前项目的进展

大部分功能是成功的，将自己测试的结果告诉AI（就是成功/失败/部分成功/漏写的这些总结信息），进行修复即可，最终所有功能正常使用✅️

优化

1. 因为jwt是无状态的，用户退出登录后再次使用原令牌（accessToken有效期内），依然有权限访问。用户登出同时将此令牌放入redis中，令牌校验时先判断一次是否在黑名单
2. 对于token是在过滤器校验的，校验失败直接返回了，客户端什么消息都没收到。需要在校验失败时将具体信息返回给用户（是令牌失效啊还是令牌过期等等）

提供rpc接口

对于后台管理，使用http是足够的，但是服务间通信呢？这时候就轮到rpc登场了

为什么我不用http进行服务间调用的原因主要有以下几点：

1. rpc面向方法，直接进行函数调用，开发体验就像调用本地方法一样简单
2. 对于性能与传输来讲，rpc使用Protobuf进行序列化，比传统的json更加轻量化，解析快
3. 强类型约束，更安全！

给出简洁明了的提示词：

请你在保留 REST API的同时，提供rpc接口并注册到nacos中。你需要先检索顶级开源项目的实现策略，编写一份开发文档，待我审核后再进行编码操作

这里AI给出的方案还是挺完整的，为了节省空间，这里就不列出来了，直接同意方案开始编写代码

展示一下最终结果吧，AI生成的yml文件中，有2个文件报错

起初我以为是idea缓存问题，因为代码中实际使用jakarta，但他一直报javax的问题，但经过我一顿操作，清理缓存、重启项目、重新编译…… 后发现，一点没生效😭，算了，还是让AI给我打工吧

通过使用 webSearchPrime 和 webReader 两个mcp，定位真正原因：是maven包版本不匹配的锅

接着让他提供Protobuf的形式来适用不同的编程语言，为后续对接各种语言的项目做准备

测试验收

一如既往啊，让我来测试测试，最终结果如下，感觉还可以

• authenticate、getUserById、hasRole、getUserRoles、generateToken、parseToken、revokeAllTokens 成功通过测试

支持多租户

OK呀，现在提交到git，开一个新会话，开始下一关：“支持多租户功能”

属实我对多租户的实现原理不太理解，算鸟算鸟，交给AI来吧，就是可惜了我的mcp调用额度了

现在这个微服务只能是单应用认证，如果我想对接多个平台，应该怎么办（参考顶级开源项目的实现方案）

这次使用的是 webSearchPrime 、 webReader 、开源仓库搜索 三个mcp进行资料的搜索以及开源项目结构功能的分析，然后审核AI给出的方案，输入“按计划执行”，就可以去喝茶去了

什么？你问我咋没测试？那肯定要测啊，只是写一些接口名挺累的，就不放啦~ 反正新增接口全部通过 ✅️

至此，http的28个接口+rpc的10个接口就告一段落了

优化拓展

1. 现在租户管理与各租户用的是相同的权限，个体租户也可以进行租户管理了，这很不合理，所以对于租户管理应该有单独的一套租户平台权限，用于控制该认证授权微服务对租户的控制（CRUD等）
2. 对于现有的个体租户权限等体系保持不变，只需要新添加一套平台管理权限即可

添加前端页面

初始提示词

充分分析整个项目，确保你完全理解。我需要你写一个前端界面来对接已有的http接口，要求这个管理界面随此后端程序启动时一起启动，注意区分权限问题哦

最终效果如下，感觉还可以吧（未使用任何skill，使用原生html和css作为静态资源随后端一起启动，因为我的最终目的是实用性和轻量级）：

1. 登录页

2. 仪表盘

3. 租户平台管理方

4. 普通租户管理方

部署文件

version: '3.8'

services:
  auth-service:
    image: registry.cn-wulanchabu.aliyuncs.com/wanyj/auth-service:4.0
    container_name: auth-service-app
    restart: unless-stopped
    environment:
      TZ: Asia/Shanghai
      # Database Configuration
      SPRING_DATASOURCE_URL: jdbc:mysql://127.0.0.1:3306/auth_service?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
      SPRING_DATASOURCE_USERNAME: root
      SPRING_DATASOURCE_PASSWORD: 12123
      # Redis Configuration
      SPRING_DATA_REDIS_HOST: 127.0.0.1
      SPRING_DATA_REDIS_PORT: 6379
      SPRING_DATA_REDIS_PASSWORD: 12123
      # Nacos Configuration
      dubbo.registry.address: nacos://127.0.0.1:8848
      dubbo.registry.username: nacos
      dubbo.registry.password: nacos
      dubbo.metadata-report.address: nacos://127.0.0.1:8848
      dubbo.metadata-report.username: nacos
      dubbo.metadata-report.password: nacos
      # JVM Configuration
      JAVA_OPTS: >-
        -XX:+UseContainerSupport
        -XX:MaxRAMPercentage=75.0
        -XX:+PrintGCDetails
        -XX:+PrintGCTimeStamps
        -Xlog:gc*:file=/logs/gc.log:time,tags:filecount=10,filesize=100M
    ports:
      - "8123:8123"   # REST API
      - "20880:20880" # Dubbo RPC
    volumes:
      - app-logs:/app/logs
    networks:
      - auth-network

# Named volumes for data persistence
volumes:
  app-logs:
    driver: local

# Network for service communication
networks:
  auth-network:
    driver: bridge

最后一步！提交、推送到github，docker镜像打包并推送到阿里云镜像仓库，完美收工，后续根据自己的需求再进行拓展吧

对接我的两个其他服务

认证授权服务已部署到服务器，接下来进行最后一关“对接项目”

后端部分

在两个项目中分别开一个会话，提示词如下

1. 请你分析整个项目，确保充分理解，特别是登录授权部分
2. 现在你需要参考 https://github.com/userwanyong/auth-service 这个开源项目，完善当前项目的认证授权功能（开源项目环境我已搭建好，你只需要写代码即可） 

期间有一个报错，以为是AI搞错了，直接丢给它了，结果一针定位，是我auth-server部署的问题

需要在auth-service部署文件中添加

DUBBO_IP_TO_REGISTRY: 你的ip

完美启动，无报错

修改36文件，新增1文件，所有与之有关的地方都进行了更改

前端部分

然后让AI修改认证授权服务所要对接的两个项目的前端UI即可

最终本次开发的认证授权服务成功对接我的两个线上项目：

https://xybjz.wanyj.cn/ 和 https://lxzs.wanyj.cn/login 非常省心，这就是Vibe Coding的时代吗，全程没动手敲代码

最后借用了第三方框架的三方校验能力，使用自己部署的认证授权服务作核心部分，完美实现两个项目的认证授权功能

最后，不得不感叹一句，AI太强大了，硬生生的把之前一周的工作量压缩到一天

最后的最后，给大家一个优惠链接，有需要的小伙伴可以来看看🌹：点击领95折优惠链接