我一直试图让我的刷新令牌工作一段时间,我希望我很接近.我的令牌刷新并触发后续200调用导致401的任何调用,但我的页面上的数据不刷新.
访问令牌到期时,会发生以下情况:
在401之后,GetListofCompanyNames使用正确更新的访问令牌返回200,其中包含名称列表.但是,我的下拉列表不会刷新.
我的拦截器:
app.factory('authInterceptorService',['$q', '$location', 'localStorageService', '$injector', function($q, $location, localStorageService, $injector) {
return {
request: function(config) {
config.headers = config.headers || {};
var authData = localStorageService.get('authorizationData');
if (authData) {
config.headers.Authorization = 'Bearer ' + authData.token;
}
return config;
},
responseError: function(rejection) {
//var promise = $q.reject(rejection);
var authService = $injector.get('authService');
if (rejection.status === 401) {
// refresh the token
authService.refreshToken().then(function() {
// retry the request
var $http = $injector.get('$http');
return $http(rejection.config);
});
}
if (rejection.status === 400) {
authService.logOut(); …Run Code Online (Sandbox Code Playgroud) 我对 MEAN 堆栈和 Google 的 OAuth2.0 开发很陌生,所以请原谅我的无知。
我的网络应用程序要求用户使用 Google 的 Oauth2.0 进行注册,以提供对 Google API 之一的应用程序访问权限。
我正在寻找一种在本地或数据库上存储多个令牌的方法。
根据此处的文档,Google 建议将访问令牌和刷新令牌存储在“可在应用程序的不同调用之间访问的安全、长期存在的位置”。
另一方面,本地运行的快速入门只是将令牌存储在用户的设备上(在 TOKEN_PATH 的 TOKEN_DIR 中)。将应用程序部署到在线环境时,如何为多个用户存储令牌?
是否有关于大规模存储和检索访问令牌的最佳实践?例如,将令牌与我的应用程序数据的其余部分一起存储在 mongodb 集合中是否是一个好的做法?在这种情况下,我如何在身份验证过程中访问用户的电子邮件 ID,以将其映射到我的集合中的令牌?
先感谢您!
local-storage access-token google-oauth firebase-authentication refresh-token
我正在阅读Auth0网站上有关刷新令牌和SPA的文档,它们指出SPA不应使用刷新令牌,因为它们不能安全地存储在浏览器中,而应使用静默身份验证来检索新的访问令牌。
单页应用程序(通常实现隐式授予)在任何情况下都不应获得刷新令牌。这样做的原因是该信息的敏感性。您可以将其视为用户凭据,因为“刷新令牌”使用户可以永远保持身份验证。因此,您不能在浏览器中拥有此信息,必须将其安全地存储。
我糊涂了。据我了解,检索新访问令牌的唯一方法是将新请求以及某种形式的Auth0会话cookie提交给Auth服务器,以对登录的用户进行身份验证。收到会话cookie时,Auth0然后,服务器将能够发出新的访问令牌。
但是,与在浏览器或本地存储中具有刷新令牌有什么不同?是什么使会话Cookie比刷新令牌更安全?为什么在SPA中使用刷新令牌是一件坏事?
我正在使用reactjs,mbox和axios并遇到问题。我有一个提供访问令牌和刷新令牌的api。访问令牌每20分钟消失一次,当服务器发回401消息时,我的代码将自动发送刷新令牌以获取新的访问令牌。
授予新的访问令牌后,将再次发送相同的拒绝请求。现在,我的代码运行良好,直到我抛出多个拒绝,这几乎可以同时触发所有拒绝。
因此,第一个请求关闭,发送回一个401,它获得了一个新的刷新令牌,其他所有请求都将尝试执行相同的操作,但是其他请求现在将失败,因为将使用刷新令牌和一个新的令牌将发出第一个请求。
这将启动我的代码以将用户重定向到登录页面。
所以从本质上讲,我一次只能收到1个请求。
export const axiosInstance = axios.create({
baseURL: getBaseUrl(),
timeout: 5000,
contentType: "application/json",
Authorization: getAuthToken()
});
export function updateAuthInstant() {
axiosInstance.defaults.headers.common["Authorization"] = getAuthToken();
}
function getAuthToken() {
if (localStorage.getItem("authentication")) {
const auth = JSON.parse(localStorage.getItem("authentication"));
return `Bearer ${auth.accessToken}`;
}
}
axiosInstance.interceptors.response.use(
function(response) {
return response;
},
function(error) {
const originalRequest = error.config;
if (error.code != "ECONNABORTED" && error.response.status === 401) {
if (!originalRequest._retry) {
originalRequest._retry = true;
return axiosInstance
.post("/tokens/auth", {
refreshToken: getRefreshToken(),
grantType: "refresh_token",
clientId : "myclient" …Run Code Online (Sandbox Code Playgroud) 我在 Azure API 管理中创建了一个 API,用于从后端 API 获取数据。后端 API 使用 oAuth2 以及 10 分钟后过期的访问令牌。通过返回的刷新令牌,您可以获得新的访问令牌,该令牌在另外 10 分钟内再次有效。等等。
在Azure APIM的开发门户中,可以进行授权,授予10分钟的访问权限。10 分钟后,您必须再次手动授权,才能获得另外 10 分钟的访问权限。
Azure APIM 中有没有办法使用刷新令牌自动获取新的访问令牌?
我的目标是用户在开发门户中手动进行一次授权,之后访问令牌必须自动刷新。
我通过 SignalR 从客户端(角度 9)和服务器(asp.net core 3.1)创建实时连接,并通过 JWT 令牌授权集线器,如下代码:
private createConnection() {
this.hubConnection = new HubConnectionBuilder().withUrl(`${this.appConfig.hubEndpoint}/Hubs`,
{ accessTokenFactory: () => jwtToken })
.withAutomaticReconnect()
.build();
}
private startConnection(): void {
this.hubConnection
.start()
.then(() => {
this.connectionIsEstablished = true;
this.connectionEstablished.emit(true);
})
.catch(err => {
console.log('Error while establishing connection, retrying...');
});
}
Run Code Online (Sandbox Code Playgroud)
在令牌过期之前,这一切正常。根据我的研究,在收到带有刷新令牌的新令牌后,应停止先前的连接,并使用新令牌创建新连接。现在我想知道我该怎么做?我必须经常检查令牌吗?或者应该通过向服务器发送每个请求来解决这个问题?
我正在绞尽脑汁地思考如何从中获取刷新令牌,FirebaseAuth但似乎找不到如何获取刷新令牌。
在 iOS 上,相当于Auth.auth().currentUser?.refreshToken. 非常感谢任何帮助。
如果我正确理解了刷新令牌轮换,这意味着每次我们请求新的访问令牌时,我们也会获得一个新的刷新令牌。如果多次使用刷新令牌 - 我们会使某个用户之前使用的所有刷新令牌失效,并且用户必须再次执行身份验证过程。
这是否意味着我们需要将所有刷新令牌(所有旧的)存储在数据库中?
难道我们不能简单地存储最后一个刷新令牌(尚未使用),并且对于每个获取新访问令牌的请求,我们将检查请求中发送的刷新令牌是否在数据库中,如果那么,我们将创建一个新的访问和刷新令牌并覆盖数据库中的旧刷新令牌,以便旧的刷新令牌不能用于获取新令牌?
这样的刷新令牌应该存在多久?
我在博客(此处)中看到有关使用 JWT 在 React 中进行身份验证的内容,此设置:访问令牌到期时间为 15 分钟,刷新令牌到期时间为 1 个月;每 10 分钟客户端调用/refreshToken端点一次,检查刷新令牌是否仍然有效(否则用户将看到登录屏幕)。
在服务器上,/refreshToken端点正确检查刷新令牌是否未过期,刷新令牌有效负载中具有 ID 的用户仍然存在且有效(即:传递的刷新令牌存在于其刷新令牌数组中)。如果一切正常,则会生成一个新的访问令牌,并与响应一起发回。
到目前为止,一切都很好。但是,在返回响应之前,也会生成一个新的刷新令牌,并将旧的刷新令牌替换到用户的刷新令牌数组中...我认为这种策略是有缺陷的,因为这样用户就永远不会看到他的登录过期,即使在之后刷新令牌(本例中为一个月)将过期...
我确实做了一些测试(将 1 个月值降低到 30 分钟),并且实际上用户授权永远不会过期...强制注销用户删除其刷新令牌数组显然效果很好,但我希望刷新时会注销令牌按年龄过期。
我询问我的理解是否正确(服务器上的refreshToken端点不应刷新刷新令牌,而应仅刷新访问令牌),或者我是否错过了某些内容。
@Ghero 评论后更新:我明白你的观点...但是如果不更新令牌的过期时间,为什么要刷新令牌呢?
然而,博客的代码用于更新刷新令牌:
const jwt = require("jsonwebtoken");
exports.getRefreshToken = (user) => {
const refreshToken = jwt.sign(user, process.env.REFRESH_TOKEN_SECRET, {
expiresIn: eval(process.env.REFRESH_TOKEN_EXPIRY),
});
return refreshToken;
};
// REFRESH_TOKEN_EXPIRY is set to 30 days
Run Code Online (Sandbox Code Playgroud)
看起来总是把到期日期推迟到未来30天。这样就永远不会过期了...
email我有一组纯粹用于我自己的应用程序的 API,因此当用户提供和时,我只有一个简单的 API 来创建访问令牌password
/api/access_tokenaccess_token(当email和匹配时返回password)
已access_token保存并与数据库sessions表中的expiry字段进行匹配,目前有效期为one week,因此用户需要在一周后重新登录。
到目前为止,它运行良好,但如果我想要拥有remember meFacebook / Twitter 应用程序的功能,这意味着用户不需要经常重新登录,我认为他们正在使用类似的方法OAuth refresh access tokens。
由于我没有使用这些 OAuth 东西,鉴于我当前的设计和设置,实现相同功能的最简单且安全的方法是什么?
refresh-token ×10
access-token ×5
jwt ×5
oauth-2.0 ×3
reactjs ×2
android ×1
angular ×1
angularjs ×1
asp.net ×1
asp.net-core ×1
axios ×1
google-oauth ×1
javascript ×1
kotlin ×1
mbox ×1
node.js ×1
security ×1
signalr ×1