大家是怎么对自用的服务做鉴权的

[Inzufu]

比如网站的后台，图床的上传页和一些小 API 接口。
最常用的应该是密码，但是一个服务一个密码感觉体验很不好，管理起来也麻烦。
用过钉钉、飞书、slack 等服务的 oauth 登录接口，实现起来挺简单，但感觉还不算是最佳实践。

我能想到的：
1：邮箱验证码登录，实现起来可能稍微有点麻烦。
2：webauthn 用手机或者安全密钥登录，但我还没研究明白。
3：TOTP （基于时间的验证码），但是如果单用一个六位数的数字做鉴权是否不太安全。
问题是这三种只是单次认证的方法，要做持久化会话就得几乎从头写一个鉴权系统，有点为了醋包饺子的感觉。

各位有什么思路吗。

[bluedawn]

passkey

[bluedawn]

你本来就有 authelia/authetik/keyclock 搭建的话接入它们也行

[busier]

就自己用的业务，我用 TLS/SSL 双向证书验证

如果在其它设备临时用下，就发个短期证书。

[nealot]

一个安全性差一点，但是简单一点的办法：

生成一个 uuid ，配置在 nginx 里面，作为 url 的 prefix 。当然全站要强制启用 HTTPS

[lymanbernadette6]

Nginx 密码最简单

[9A0DIP9kgH1O4wjR]

用 nginx 加密码？

[Inzufu]

@busier 这是个思路。拓展一下：如果业务里接触不到 Nginx 这一层或者设备不方便安装证书的话，可以把证书放在浏览器的 localstorage 里，鉴权时服务器发送 challenge 由客户端签名后再返回给服务端校验，有点像 webauthn 。

[Inzufu]

@nealot 这个本质上还是密码校验，就是是在 Nginx 这一层实现的。
但还是谢谢你的思路，确实比在应用中实现方便一点儿。

[xcsoft]

用浏览器的 passkey 就很方便

[Inzufu]

@lymanbernadette6 @hanierming 有些业务接触不到 Nginx 这层，而且这个不太好做限流，密码有被爆破的风险？
还是谢谢思路。

[Inzufu]

@bluedawn @xcsoft passkey 确实是安全方便，唯一的问题就是兼容性，不过其实自己用也没必要考虑那么多。
但问题是 passkey 只是单次鉴权的方式，没办法持久化认证。

[estk]

自用就 ssl + nginx 密码

[xcsoft]

基本现代化浏览器都已经对 passkey 兼容了吧
持久化认证，只能自己实现业务逻辑，比如身份验证后使用 jwt ，或者使用 一些类似 webvpn 之类的（大学的校内资源访问） 那种？
或者直接使用 wireguard ，业务不放公网也可以

[Wh0amis]

搞个 ip 白名单，然后裸奔，啥鉴权都不需要

[wxyrrcj]

nginx 配置个密码

[wu67]

echo 账户名:$(openssl passwd -1 你的密码)>>/etc/nginx/webdavpasswd
nginx auth_basic_user_file /etc/nginx/webdavpasswd;

接口服务等无法每次调用都输密码的, 可以加自定义一个 http header. 注意不要自定义 ua 的内容, chrome 无法自定义 ua, 纯纯浪费时间

[potatowish]

1. vpn ，ip 白名单
2. 服务端企业微信接口下发动态验证码
3. 服务端 bark 推送动态验证码到 iphone

[isSamle]

如果是自己的服务调用的话，就是内网调用不开防火墙，如果是外部调用，就配秘钥

[securityCoding]

套个 cf 认证了

[BH1SMB]

IP 白名单或者 key 验证

[zpfhbyx]

加 key 最简单了

[libook]

用密码管理器，一个服务一个密码也无所谓。

主要是并不是所有服务都支持一样的统一单点登录技术。

[Puteulanus]

感觉你想要的可能是 Auth0

类似你说的 oauth 登录接口，不过它整合了常见登录方式和一些第三方登陆

登陆跳回来的 callback 是 jwt ，你自己这边简单做一下 jwt 的验证就行了。我是用的 Nginx 的 ngx_http_auth_jwt_module 模块在中间做一个验证网关，对需要控制访问的 web 服务转接一下 https://github.com/puteulanus/nal ，服务那边就基本上无感了

我一般会开 GitHub 登陆和 email 登陆，email 我记得是邮件验证码吧，太久了印象不深了，magic link 那种不知道它有没有。Auth0 还是挺有名的服务的，OpenAI 的登陆就是用的它

[henix]

https （自签证书） + http basic auth

[opengps]

密码我都懒得用，我就是一个自己才知道的 url ，带上自己定制规律的入参才能打开，越是这种自定义的规则，黑客越猜不到

[tool2dx]

我是自己套用 RPC 协议加密，因为可以远程执行命令，我怕被别人抓包，只能加密。

加密相当于鉴权了。

[iLtc]

我目前是 用户名 + TOTP + reCAPTCHA ，应该能防止暴力破解。

最近在考虑要不要换成 Passkey 。

[nosmile]

IP 白名单，后面准备写个脚本，在新的地点一键放通

[bobryjosin]

cloudflare zero trust ，tunnel 绑个域名走 github 认证，点一下就能过了，自用的服务都 wireguard 组网，直接用内网 ip 访问。

[totoro625]

直接就是 IP 鉴权
访问一个特定服务器的 URL 记录访问 IP ，通过 ddns 传递 IP 到域名，其他服务器定时拉取 IP 解析并放行，隔一段时间删除该 IP

[echoless]

https://dexidp.io/

[totoro625]

@nosmile #28 期待一下，特别需要
我自用的方案有延迟，不太行

[zsh2517]

目前公网统一的入口，走 nginx + Basic Auth 转发到内网里面的一个 Nginx Proxy Manager ，它再分发到具体服务上。
内网里面基本没有鉴权（有通常也是弱密码）。只有极个别服务是强密码验证（比如 pve 的 web UI ）

---
目前个别服务（支持 OAuth2/OpenID 登录的），接入了 GitLab 作为第三方登录。
后面计划改成每个服务均绑定 127.0.0.1 ，然后前面套一个轻量的鉴权网关（可能支持 oauth/passkey/password 三种验证）。但是懒得写又没找到合适的开源项目（ 天天在 V2EX 打广告的 casdoor 似乎可能满足需求，但是之前部署过一次文档质量有点差），就一直咕咕咕了

[zsh2517]

@zsh2517 都是 web 服务（ http, https, ws, wss ）。对于 tcp/udp 类的我没太考虑过

[WashFreshFresh]

@zsh2517 sa-token 到还可以，你说的都支持。

[wbrobot]

直接前端生成个浏览器指纹当 uuid ，设置个 password 就行了。

[wbrobot]

@wbrobot 我的一个站 https://9898555.com 就是用前端浏览器指纹当 uuid ，弱绑定用户

[beyondstars]

1. 自用服务部署在内网（或者虚拟局域网），透过 wg, ssh 等加密隧道软件进行连接。
2. 自签 ssl 证书 + http basic auth;
3. Cloudflare tunnel （只是一个想法，没试过）；
4. 对接 3rd party auth api 太麻烦了（再简单的 3rd party auth 对接也远不如写几行配置，敲几行命令简单）。

[beyondstars]

补充一个：

5. 部署在自有 k8s 集群的可以用 client cert + kubectl port-forward + clusterip service 的方式安全访问。

[PerFectTime]

caddy + caddy-security 模块 + github oauth

[ZztGqk]

passkey 我就在用 passkey

[zsh2517]

@WashFreshFresh #35 看了一下，项目本身似乎挺不错的。可惜我不写 Java ，而且需求似乎对不上 😂

目前的思路大概是：选择一个可信的 OAuth2 （ OpenID Connect ） 三方平台。然后 golang （无运行时依赖）实现一个轻量、单文件（方便部署）的反向代理。未登录时强制 OIDC 登录。登录后在白名单的用户反向代理，不在白名单的用户 403 Forbidden 。这样就可以很简单地实现认证后访问。

目前已经跑通流程了，但是反代代码是 GPT 写的，能跑但是还没仔细读，不知道有没有 bug 。

后期可能（但不一定）会把 OAuth2 的提供者换成 keycloak 之类的专门的服务；以及解决配置文件分发的问题（几台虚拟机，十几个服务）

[zsh2517]

@zsh2517 #40 提到的 caddy-security 看起来能满足反向代理的要求。看具体需要吧

如果要把反向代理仅作为外网入口的鉴权，那么一台服务器跑反向代理，其他走内网访问就行。
不过我希望的是每个机器上的服务在内网也无法直接访问。这个时候可能需要每台设备跑一个反代了

[zsh2517]

@zsh2517 补充一下内网的安全性问题。一般来说 homelab 应该可以把内网看作可信的。
主要我这边跑了一个帕鲁服、一个 QQ Bot 和一些其他东西，没有做隔离而且不止我一个人能登录 VM 。
短期没心情重新调整网络，所以想直接在每个服务上授权验证（虽然 OAuth2 不至于说完全无感，但是每隔一段时间的首次访问自动跳转一下、大部分时候无感，还是能接受的）

[8355]

api 的话自用 header token 写死复杂加密值
适用于复杂路径