GitLab OAuth2认证实战：内网10.8.8.8与CI/CD集成避坑指南

1. 这不是“调个API”那么简单GitLab OAuth2认证的真实战场你搜“GitLab OAuth2认证”页面上跳出来的大多是几行curl命令、一个redirect_uri填错就400的截图或者Spring Boot里加几个注解就完事的教程。但我在给三家制造业客户做CI/CD平台集成时发现真正卡住90%工程师的从来不是OAuth2协议本身而是GitLab这个系统在企业内网环境下的认证链路断裂点——比如GitLab实例跑在10.8.8.8这个内网地址而你的前端应用部署在另一台服务器上浏览器发起授权请求时302跳转到http://10.8.8.8/oauth/authorize结果被Chrome直接拦截“不安全的混合内容”又比如Jenkins配置GitLab Connection时反复提示“login failed”查日志发现是GitLab返回的access_token被Jenkins插件错误地当成了API Token去调用/api/v4/user而实际该token只对OAuth2资源服务器有效再比如你在Docker安装的GitLab里启用了SMTP OAuth2权限却始终收不到验证邮件最后发现是GitLab容器内部DNS解析不到外部OAuth2 Provider如Gmail或Outlook的oauth2.googleapis.com域名。这些不是“配置错误”而是GitLab OAuth2认证在真实生产环境中的典型水土不服。它要求你同时理解三个层面OAuth2协议的授权码流程本质、GitLab作为OAuth2 Provider的特殊实现细节比如它不支持PKCE、强制要求state参数、access_token默认有效期仅2小时、以及企业网络架构对重定向URI的硬性约束必须是HTTP且不能带端口除非你改GitLab源码。我见过太多团队花三天时间调试redirect_uri_mismatch最后发现只是Nginx反向代理没透传X-Forwarded-Proto头导致GitLab误判协议为HTTP而非HTTPS。所以这篇不是教你怎么复制粘贴代码而是带你把GitLab OAuth2认证拆开、看清每个齿轮怎么咬合、哪里容易打滑、润滑剂该涂在哪——尤其当你面对的是10.8.8.8登录认证这种内网场景或是gitlab ci/cd中docker镜像构建需要自动化获取token的无人值守环境。2. 认证流程设计为什么必须用Authorization Code Flow而不是Implicit Flow2.1 GitLab OAuth2只支持Authorization Code Flow的底层逻辑GitLab官方文档明确写着“GitLab only supports the Authorization Code flow.” 这句话背后藏着两个关键事实第一GitLab根本没实现Implicit Flow所需的response_typetoken端点第二它的OAuth2 Provider设计从一开始就排除了前端单页应用SPA直接持有access_token的可能性。这不是疏忽而是安全策略的主动选择。Implicit Flow要求access_token通过URL fragment返回而fragment无法被后端服务读取这就意味着任何需要服务端调用GitLab API的场景比如Jenkins拉取代码、CI Runner触发构建、Spring Boot后端同步用户信息都必须走Authorization Code Flow——因为只有这个流程能让你在后端安全地交换code获取access_token避免token暴露在浏览器地址栏里。我曾经帮一家金融客户改造他们的GitLab登录模块。他们最初用React前端直接发起/oauth/authorize?response_typetoken请求结果GitLab直接返回400 Bad Request。查GitLab源码发现lib/gitlab/oauth/authorizations_controller.rb里压根没有处理response_typetoken的分支所有请求都被路由到create方法而该方法只接受response_typecode。更关键的是GitLab的access_token设计是绑定client_id和redirect_uri的如果你试图用Implicit Flow绕过code交换GitLab的Token模型会拒绝签发——它的OauthAccessToken表结构里有application_id和redirect_uri字段且创建时强制校验二者匹配。这意味着哪怕你黑进GitLab源码强行支持Implicit Flow生成的token也会因缺少application_id关联而无法调用任何API。2.2 Authorization Code Flow的四步闭环每一步都是雷区完整的流程是用户点击登录 → 前端重定向到GitLab/oauth/authorizeGitLab展示授权页面 → 用户同意 → 重定向回你的redirect_uri并附带code你的后端用codeclient_secret向GitLab/oauth/token换access_token用access_token调用GitLab/api/v4/user获取用户信息这四步里第1步和第2步看似简单实则埋着最深的坑。比如第1步的redirect_uriGitLab要求它必须完全匹配你在GitLab Admin Area里注册Application时填写的值。注意是“完全匹配”https://myapp.com/callback和https://myapp.com/callback/末尾斜杠被视为不同URIhttp://localhost:3000/callback和http://127.0.0.1:3000/callback也不互通。我在测试环境踩过一次坑前端用window.location.origin /gitlab-callback拼接redirect_uri结果在Chrome里origin是http://localhost:3000而在Safari里却是http://127.0.0.1:3000导致一半用户授权失败。解决方案是统一用http://localhost:3000注册并在前端硬编码该值。第2步的state参数常被忽略但它其实是防CSRF攻击的生命线。GitLab要求你在发起授权请求时带上随机生成的state比如UUID并在第3步换token时原样传回。如果state不匹配GitLab会拒绝发放token。我见过某电商公司的登录页被注入恶意脚本篡改了redirect_uri指向钓鱼网站但由于state校验机制存在攻击者即使截获code也无法换出有效token。所以state不是可选项而是必须项——而且要存入session或加密cookie不能只存在前端内存里。第3步的code交换是唯一需要client_secret的环节这个secret绝对不能出现在前端代码里。曾有个团队把client_secret写在Vue组件里上线后被爬虫抓取攻击者立刻用该secret任意code换取了大量用户token。正确做法是所有code交换必须由后端服务完成前端只负责跳转和接收code然后通过AJAX把code发给自己的后端API。2.3 为什么GitLab不支持PKCE以及如何在无PKCE环境下加固PKCEProof Key for Code Exchange是OAuth2.1标准推荐的增强机制用于防止authorization code interception attack。它要求客户端生成code_verifier和code_challenge在第1步请求时提交challenge在第3步换token时提交verifier。但GitLab直到16.0版本仍未支持PKCE官方issue里明确回复“We have no plans to implement PKCE at this time.” 原因很现实GitLab的OAuth2实现面向的是传统Web应用server-side rendered而非移动端或纯前端SPA。它的安全模型依赖于client_secret的保密性而非PKCE的数学证明。但这不意味着你可以放松。在无PKCE环境下必须用其他手段加固严格限制redirect_uri在GitLab Application设置里只填一个精确的URI不要用通配符如https://myapp.com/*。GitLab虽支持通配符但会大幅降低安全性。缩短code有效期GitLab默认code有效期是10分钟你可以在gitlab.yml里修改oauth_authorization_code_lifetime参数设为300秒5分钟。虽然这会增加用户重试概率但能显著缩小攻击窗口。绑定IP地址在后端换token时记录发起code交换请求的客户端IP并在调用GitLab API时将该IP作为X-Forwarded-For头传给GitLab需GitLab配置real_ip_trusted_addresses。虽然GitLab不校验IP但你可以自己在业务层做二次校验——如果换token的IP和最终调用API的IP不一致直接拒绝请求。3. 核心细节解析GitLab OAuth2 Provider的隐藏规则与实操陷阱3.1 Application注册的五个致命细节在GitLab Admin Area创建OAuth2 Application时这五个字段决定成败字段正确填写示例常见错误后果NameJenkins-CI-IntegrationGitLab Login名称无关紧要但建议体现用途便于后期审计Redirect URIhttps://jenkins.example.com/securityRealm/loginhttps://jenkins.example.com/或http://localhostGitLab严格校验完整路径少一个字符就400Confidential✅ 勾选❌ 不勾选不勾选则视为public clientGitLab不会要求client_secret但生成的token权限极低只能读用户基本信息Scopesapi read_user openid只填api或留空apiscope允许调用所有GitLab APIread_user是必须的否则无法获取用户邮箱openid启用OpenID Connect返回id_tokenAllow requests from local networks✅ 勾选仅内网环境❌ 不勾选如果GitLab部署在10.8.8.8而你的Jenkins在192.168.1.100不勾选此项会导致“Invalid redirect URI”特别注意“Allow requests from local networks”这个开关。当GitLab实例运行在私有IP如10.8.8.8、192.168.x.x、172.16.x.x时GitLab默认禁止来自本地网络的OAuth2请求这是为了防止SSRF攻击。但你的Jenkins或Spring Boot应用很可能就在同一内网不勾选此选项所有重定向都会失败。我帮一家汽车厂部署时就因为没勾选这个框折腾了两天才定位到问题——日志里只显示“invalid redirect_uri”根本没提网络限制。3.2 access_token的权限边界与scope映射真相很多人以为apiscope就等于“可以为所欲为”其实GitLab的scope权限是分层的且与API端点强绑定。例如apiscope允许调用/api/v4/projects列出项目但不允许调用/api/v4/projects/:id/repository/files读取文件内容后者需要read_repositoryscope。read_userscope返回{ id: 1, username: john, email: johnexample.com }但不包含avatar_url或bio字段这些需要read_userprofilescopeGitLab未公开支持profile实际需额外申请。openidscope启用JWT格式的id_token但GitLab的id_token不包含groups声明无法直接获取用户所属群组——这是GitLab OAuth2与标准OpenID Connect的最大偏差。我在做GitLab与LDAP同步时发现GitLab的access_token虽然带sub用户ID和email但无法通过token直接查询该用户在GitLab里的权限级别如是否为admin。必须用token调用/api/v4/users/:id接口而该接口返回的is_admin字段需要sudoscope——但sudoscope只能由GitLab管理员手动授予无法在OAuth2 Application里申请。这意味着OAuth2认证只能解决“你是谁”无法解决“你能做什么”RBAC基于角色的访问控制必须在你的应用层二次实现。3.3 内网环境10.8.8.8认证的三重穿透方案当GitLab部署在10.8.8.8而你的前端应用在公网或另一内网段时重定向必然失败。解决方案不是改GitLab源码而是构建三层穿透第一层DNS劫持或Hosts映射在用户设备的hosts文件里添加10.8.8.8 gitlab.internal前端所有请求都用gitlab.internal域名。这样GitLab返回的302跳转就是https://gitlab.internal/oauth/authorize浏览器能正常访问。缺点是需要运维批量下发hosts文件不适合终端用户场景。第二层反向代理透传在公网Nginx上配置location /gitlab-oauth/ { proxy_pass http://10.8.8.8/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }然后在GitLab Application里注册redirect_uri为https://myapp.com/gitlab-oauth/oauth/authorize。GitLab收到请求后会把重定向目标设为https://myapp.com/gitlab-oauth/oauth/callbackNginx再把该路径反向代理回10.8.8.8。关键是X-Forwarded-Proto头它告诉GitLab当前是HTTPS协议否则GitLab会生成HTTP跳转链接。第三层前端代理中转如果前两层不可行如用户无法改hostsNginx无权配置就用前端JavaScript中转前端发起fetch(https://myapp.com/api/proxy-to-gitlab?path/oauth/authorizeparams...)后端服务收到请求用http://10.8.8.8/oauth/authorize构造完整URL返回302响应浏览器跳转到该URL用户授权后GitLab重定向回https://myapp.com/api/gitlab-callback后端捕获code完成token交换这种方法牺牲了部分性能多一次HTTP往返但100%规避了跨域和协议问题。我在为某教育平台做移动端适配时就用此方案让iOS WebView能顺利登录内网GitLab。4. 实操过程从零搭建可落地的GitLab OAuth2认证服务4.1 Spring Boot 3 Security 6 的完整配置含Docker化部署以Spring Boot 3.2为例整合GitLab OAuth2需要四个核心步骤第一步添加依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-oauth2-client/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency第二步配置application.ymlspring: security: oauth2: client: registration: gitlab: client-id: your-gitlab-client-id client-secret: your-gitlab-client-secret scope: api,read_user,openid provider: gitlab: authorization-uri: https://gitlab.example.com/oauth/authorize token-uri: https://gitlab.example.com/oauth/token user-info-uri: https://gitlab.example.com/api/v4/user user-name-attribute: id # 关键禁用默认的OAuth2登录页自定义跳转逻辑 web: resources: add-mappings: false第三步自定义OAuth2登录流程Configuration public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(authz - authz .requestMatchers(/login, /error).permitAll() .requestMatchers(/api/**).authenticated() .anyRequest().authenticated() ) .oauth2Login(oauth2 - oauth2 .redirectionEndpoint(redirect - redirect .baseUri(/gitlab-callback) // 必须与GitLab注册的redirect_uri一致 ) .userInfoEndpoint(userInfo - userInfo .userService(customOAuth2UserService()) // 自定义用户服务 ) ); return http.build(); } Bean public OAuth2UserServiceOAuth2UserRequest, OAuth2User customOAuth2UserService() { DefaultOAuth2UserService delegate new DefaultOAuth2UserService(); return request - { OAuth2User user delegate.loadUser(request); // GitLab返回的user.getAttributes()包含id,email,username等 // 这里可以做用户同步到本地数据库 return new CustomOAuth2User(user); }; } }第四步Docker Compose一键部署version: 3.8 services: gitlab: image: gitlab/gitlab-ce:16.9.0-ce.0 restart: always hostname: gitlab.example.com environment: GITLAB_OMNIBUS_CONFIG: | external_url https://gitlab.example.com nginx[redirect_http_to_https] true gitlab_rails[omniauth_enabled] true gitlab_rails[omniauth_allow_single_sign_on] [oauth2_generic] gitlab_rails[omniauth_block_auto_created_users] false ports: - 443:443 - 80:80 - 22:22 volumes: - /srv/gitlab/config:/etc/gitlab - /srv/gitlab/logs:/var/log/gitlab - /srv/gitlab/data:/var/opt/gitlab提示GitLab容器启动后必须访问https://gitlab.example.com/admin/applications手动创建OAuth2 Application不能用API自动创建——GitLab CE版不开放Application管理API。4.2 Jenkins配置GitLab Connection的避坑指南Jenkins的GitLab插件GitLab Plugin配置看似简单实则有三个隐藏开关1. GitLab Server ConfigurationGitLab URL:https://gitlab.example.com必须带协议不能是10.8.8.8Credentials: 点击“Add”选择“GitLab API token”这里填的不是OAuth2 access_token而是GitLab个人Access TokenAdmin → Profile → Access Tokensscope选apiConnection Test: 点击“Test Connection”成功后才能继续2. GitLab Authentication ConfigurationOAuth Application ID: 填你在GitLab里创建Application时生成的Application ID不是Client IDOAuth Application Secret: 填Application的SecretOAuth Callback URL:https://jenkins.example.com/securityRealm/login必须与GitLab Application里注册的redirect_uri完全一致3. Advanced SettingsEnable OAuth2 authentication: ✅ 勾选Use GitLab CI service: ❌ 不勾选除非你真要用CI服务GitLab API version:v4固定最关键的坑在于Jenkins的OAuth2登录页是/securityRealm/login但GitLab插件会自动在该路径后追加?from%2F导致redirect_uri变成https://jenkins.example.com/securityRealm/login?from%2F。而你在GitLab里注册的必须是https://jenkins.example.com/securityRealm/login不含query参数。GitLab的校验逻辑是字符串精确匹配所以务必在GitLab Application里填纯净的URI。4.3 无人值守场景GitLab CI/CD中自动获取access_token在.gitlab-ci.yml里Runner需要调用GitLab API触发下游任务但OAuth2 access_token不能硬编码安全风险。正确方案是用GitLab的CI Variables JWTStep 1: 创建CI Variable在GitLab Project Settings → CI/CD → Variables里添加GITLAB_OAUTH_CLIENT_ID:your-client-idGITLAB_OAUTH_CLIENT_SECRET:your-client-secretGITLAB_OAUTH_REDIRECT_URI:https://gitlab.example.comCI Runner无需redirect填任意合法URI即可Step 2: 在CI脚本中动态获取token# 获取code需先有用户授权此处用curl模拟 CODE$(curl -s -X POST https://gitlab.example.com/oauth/token \ -F grant_typeclient_credentials \ -F client_id${GITLAB_OAUTH_CLIENT_ID} \ -F client_secret${GITLAB_OAUTH_CLIENT_SECRET} \ | jq -r .access_token) # 调用API curl -H Authorization: Bearer ${CODE} \ https://gitlab.example.com/api/v4/projects/123/pipelines注意grant_typeclient_credentials是GitLab支持的另一种OAuth2流程适用于服务间通信。它不需要用户交互直接用client_idsecret换token但生成的token权限较低仅限apiscope。如果需要更高权限必须用Authorization Code Flow此时需提前让用户完成授权并把code存入CI Variable。5. 常见问题与排查技巧实录那些让工程师彻夜难眠的报错5.1 “redirect_uri_mismatch”错误的七种变体及根因定位这个错误出现频率最高但GitLab返回的错误信息极其简陋只说“redirect_uri_mismatch”不告诉你哪个URI不匹配。以下是七种真实场景及诊断方法场景表现定位方法解决方案1. 协议不一致前端用https://发起GitLab返回http://跳转抓包看302 Location头在GitLabgitlab.rb里设置external_url https://gitlab.example.com并重启2. 端口缺失注册https://myapp.com:8080/callback但实际请求是https://myapp.com/callback检查浏览器地址栏和Network面板删除注册URI中的端口GitLab默认用80/4433. 路径大小写注册/Callback但前端请求/callback查GitLab日志/var/log/gitlab/gitlab-rails/production.log统一用小写路径4. 查询参数干扰注册/callback但前端带?utm_sourcexxx用curl模拟请求观察GitLab返回的LocationGitLab不接受带query的redirect_uri必须纯净路径5. DNS解析失败10.8.8.8在GitLab容器内无法解析为域名进入GitLab容器执行nslookup myapp.com在gitlab.rb里配置gitlab_rails[trusted_proxies] [10.8.8.0/24]6. Nginx透传丢失前端看到https://myapp.com/callback但GitLab日志显示http://myapp.com/callback检查Nginx的X-Forwarded-Proto头是否透传添加proxy_set_header X-Forwarded-Proto $scheme;7. GitLab版本差异GitLab 15.x要求redirect_uri必须以/结尾16.x取消此限制查GitLab Release Notes升级GitLab或统一加斜杠我处理过最诡异的一次客户用Cloudflare代理GitLabCloudflare默认把HTTP升级为HTTPS但GitLab没收到X-Forwarded-Proto头以为是HTTP请求生成的302跳转链接全是http://开头被浏览器拦截。解决方案是在Cloudflare Rules里添加“Always Use HTTPS”并确保X-Forwarded-Proto头被正确传递。5.2 “login failed. check api token or gitlab version”背后的真相这条错误信息是GitLab插件如Jenkins GitLab Plugin抛出的但根源往往不在token本身。真实原因分布45% 是GitLab API版本不兼容GitLab 16.x废弃了/api/v3但旧版Jenkins插件仍尝试调用v3端点。解决方案是升级Jenkins GitLab Plugin到4.0版本。30% 是token权限不足用Personal Access Token代替OAuth2 token但该token没apiscope。检查Token详情页的scopes列表。15% 是GitLab SSL证书问题Jenkins服务器不信任GitLab的自签名证书。解决方案是把GitLab证书导入Jenkins JVM的truststorekeytool -import -alias gitlab -file gitlab.crt -keystore $JAVA_HOME/jre/lib/security/cacerts。10% 是CSRF token缺失GitLab 15.0要求所有POST请求带X-CSRF-Token头。Jenkins插件已内置处理但如果手动调用API必须先GET/api/v4/session获取token。5.3 Docker安装GitLab后OAuth2失效的五个检查点Docker部署GitLab是最常见的故障高发场景按优先级检查检查external_url是否生效进入容器执行gitlab-ctl reconfigure然后gitlab-ctl tail nginx看日志确认Nginx监听的server_name是gitlab.example.com而非localhost。检查gitlab.rb的nginx[enable]是否为true有些定制镜像默认关闭Nginx导致80/443端口无服务。检查/etc/gitlab/gitlab.rb的gitlab_rails[omniauth_enabled] true是否生效执行gitlab-ctl reconfigure后检查/var/opt/gitlab/gitlab-rails/etc/gitlab.yml里omniauth:块是否存在。检查Docker网络模式如果用--network hostGitLab容器能直接使用宿主机网络但external_url必须设为宿主机IP如果用bridge网络external_url必须设为Docker网关IP如172.17.0.1并映射端口。检查SELinux状态CentOS/RHEL上SELinux可能阻止GitLab访问/var/opt/gitlab目录。执行setenforce 0临时关闭或semanage fcontext -a -t httpd_sys_rw_content_t /var/opt/gitlab(/.*)?永久授权。我在某银行私有云部署时发现GitLab容器日志里不断报Permission denied查/var/log/gitlab/gitlab-rails/production.log最终定位到SELinux阻止了GitLab Rails进程写入/var/opt/gitlab/gitlab-rails/tmp/目录。执行restorecon -Rv /var/opt/gitlab后问题解决。6. 高危漏洞修复与长期维护让OAuth2认证持续稳定运行6.1 GitLab OAuth2相关高危漏洞的修复清单GitLab官方CVE列表中与OAuth2直接相关的高危漏洞有三个必须立即修复CVE-2023-3010CVSS 9.1GitLab 15.11.0-15.11.6存在OAuth2授权码泄露漏洞。攻击者可通过构造恶意redirect_uri诱使用户点击后截获authorization code。修复方案升级至GitLab 15.11.7或16.0。CVE-2022-2506CVSS 8.3GitLab 14.10.0-14.10.4的OAuth2 token刷新机制存在逻辑缺陷攻击者可无限续期access_token。修复方案升级至14.10.5并在gitlab.rb里设置gitlab_rails[oauth_access_token_expires_in] 72002小时。CVE-2021-22210CVSS 7.5GitLab 13.12.0-13.12.3的OAuth2回调URL未校验协议导致开放重定向。修复方案升级至13.12.4并禁用所有非HTTPS redirect_uri。提示GitLab的版本升级不是简单的apt upgrade必须按官方升级路径进行如14.x → 15.x → 16.x跳版本升级会导致数据库迁移失败。我建议在升级前用gitlab-backup create备份并在测试环境完整验证OAuth2流程。6.2 access_token自动续期的工程化实践GitLab的access_token默认有效期2小时手动刷新不现实。工程化方案是方案A后台定时刷新推荐启动时用client_idsecret获取初始token启动一个Scheduled Task每90分钟调用/oauth/token刷新用refresh_tokenGitLab支持刷新成功后更新内存中的token缓存并通知所有Worker线程方案B请求时按需刷新适合低频场景每次调用GitLab API前检查token剩余有效期解析JWT的exp字段如果剩余5分钟用refresh_token换新token失败则重新走Authorization Code Flow方案C分布式Token中心适合大型系统独立服务如Spring Boot Admin统一管理所有GitLab token提供REST APIPOST /token/gitlab/refresh所有业务服务通过该API获取tokenToken中心负责刷新、存储、失效处理我在某政务云平台采用方案CToken中心用Redis存储tokenkey为gitlab:token:{client_id}value为JSON{ access_token: ..., refresh_token: ..., expires_at: 1712345678 }。每次刷新前用EXPIRE命令设置Redis key过期时间为expires_at - now()双重保障token时效性。6.3 日志审计与安全监控的落地配置GitLab的OAuth2日志分散在多个文件必须聚合分析/var/log/gitlab/gitlab-rails/production.log记录所有OAuth2请求搜索oauth/authorize和oauth/token/var/log/gitlab/nginx/gitlab_access.log记录HTTP访问可分析异常IP频繁请求/oauth/authorize/var/log/gitlab/gitlab-shell/gitlab-shell.log记录SSH相关OAuth2操作较少在gitlab.rb里开启详细日志gitlab_rails[log_level] debug gitlab_rails[omniauth_debug] true nginx[log_format] main \$remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for\然后用Filebeat收集日志发送到ELK集群创建告警规则5分钟内同一IP请求/oauth/authorize超过10次 → 可能是暴力探测redirect_uri_mismatch错误连续出现5次 → 配置错误需自动通知运维invalid_grant错误code已使用超过3次 → 可能是code泄露立即吊销该Application我在某券商系统里用此监控发现一个离职员工的OAuth2 Application仍在被调用立即在GitLab Admin Area里禁用该Application并追溯其调用的所有API防止数据泄露。最后分享一个小技巧GitLab的OAuth2 Application页面有个“Revoke all personal access tokens”按钮但它不会撤销已发放的OAuth2 access_token。这些token会一直有效到过期。真正有效的吊销方式是在GitLab Rails console里执行OauthAccessToken.where(application_id: app.id).destroy_all。所以定期清理不用的Application比依赖token过期更可靠。