对于那些在Go中构建RESTful api和JS前端应用程序的人，你们是如何管理身份验证的?您是否使用了特定的库或技术?
我惊讶地发现关于这方面的讨论如此之少。我一直牢记以下答案，并试图避免开发自己的实现:
ASP中的认证表单。网
每个人都单独编写自己的解决方案吗?
当前回答
您将使用中间件进行身份验证。
您可以尝试go-http-auth进行基本和摘要身份验证，尝试gnomauth进行OAuth2身份验证。
但如何进行身份验证实际上取决于你的应用程序。
身份验证将状态/上下文引入http。最近有一些关于这个问题的讨论。
上下文问题的著名解决方案是这里描述的gorilla/context和谷歌context。
我做了一个更通用的解决方案，在go-on/wrap中不需要全局状态，可以一起使用，也可以不需要其他两个，并且很好地与上下文无关的中间件集成。
Wraphttpauth提供了go-http-auth与go-on/wrap的集成。
其他回答
另一个可能的解决方案是Authboss，最近在邮件列表中宣布。
(我还没有试过使用这个库。)
另见最好的方法使一个web应用程序与用户认证?
这个问题获得了大量的评论——并且有一个热门问题徽章——所以我知道这个话题有很多潜在的兴趣，很多人都在问同样的问题，而不是在互联网上找到答案。
大多数可用信息的结果都是类似于挥手的文本，作为“读者的练习”。；）
然而，我终于找到了一个具体的例子，(慷慨地)由golang-nuts邮件列表的成员提供:
https://groups.google.com/forum/ !味精/ golang-nuts GE7a_5C5kbA / fdSnH41pOPYJ
这提供了一个建议的模式和服务器端实现，作为自定义身份验证的基础。客户端代码仍然取决于您。
(我希望这篇文章的作者能看到:谢谢!)
节选(并重新格式化):
“我建议这样设计:
create table User (
ID int primary key identity(1,1),
Username text,
FullName text,
PasswordHash text,
PasswordSalt text,
IsDisabled bool
)
create table UserSession (
SessionKey text primary key,
UserID int not null, -- Could have a hard "references User"
LoginTime <time type> not null,
LastSeenTime <time type> not null
)
当用户通过TLS下的POST登录到您的站点时，请确定密码是否有效。 然后发出一个随机的会话密钥，比如50个或更多的加密字符和在一个安全的Cookie中的东西。 将该会话键添加到UserSession表中。 然后，当您再次看到该用户时，首先点击UserSession表，查看SessionKey是否在其中，并具有有效的LoginTime和LastSeenTime, user未被删除。你可以设计一个定时器自动清除UserSession中的旧行。”
看看Labstack Echo——它将RESTful API和前端应用程序的身份验证包装到中间件中，您可以使用它来保护特定的API路由。
例如，设置基本的身份验证就像为/admin路由创建一个新的子外部一样简单:
e.Group("/admin").Use(middleware.BasicAuth(func(username, password string, c echo.Context) (bool, error) {
if username == "joe" && password == "secret" {
return true, nil
}
return false, nil
}))
点击这里查看Labstack的所有中间件身份验证选项。
您将使用中间件进行身份验证。
您可以尝试go-http-auth进行基本和摘要身份验证，尝试gnomauth进行OAuth2身份验证。
但如何进行身份验证实际上取决于你的应用程序。
身份验证将状态/上下文引入http。最近有一些关于这个问题的讨论。
上下文问题的著名解决方案是这里描述的gorilla/context和谷歌context。
我做了一个更通用的解决方案，在go-on/wrap中不需要全局状态，可以一起使用，也可以不需要其他两个，并且很好地与上下文无关的中间件集成。
Wraphttpauth提供了go-http-auth与go-on/wrap的集成。
2018年回答这个问题。我建议使用JWT(JSON Web Token)。你标记解决的答案有缺点，这是它做了前(用户)和后(服务器/db)的旅行。更糟糕的是，如果用户频繁请求需要认证，将导致从/到服务器和数据库的请求膨胀。为了解决这个问题，使用JWT将令牌存储在用户端，用户可以在任何需要访问/请求的时候使用它。不需要访问数据库和服务器处理来检查令牌有效性，只需很短的时间。
