标签: auth0

在调用auth0lock的回调中调用router.navigate后,我遇到了渲染模板的问题

loginComponent.ts

import {Component, Inject} from 'angular2/core';
import {Router, ComponentInstruction} from 'angular2/router';

import {Auth} from '../auth';

declare var Auth0Lock;

@Component({
    selector: 'login',
    templateUrl: '/tpls/login/login.html'
})

export class LoginComponent {

    private lock = new Auth0Lock('xxx', 'xxx.auth0.com');

    constructor(@Inject(Router) private router: Router, @Inject(Auth) private auth: Auth) { }

    logError = (err) => {
        console.log(err);
    }

    loginSuccess = (data) => {
        if(this.router.parent.lastNavigationAttempt !== undefined && this.router.parent.lastNavigationAttempt !== '/Login') {
            this.router.navigateByUrl(this.router.parent.lastNavigationAttempt);
        } else if(data.user.req_update) {
            this.router.navigate(['Profile']);
        } else {
            this.router.navigate(['Home']);
        }
    }

    ngOnInit() {

        this.lock.show((err: …

我正在尝试将auth0与我的angular2应用程序集成,但我得到一个错误说:

    EXCEPTION: Error in ./AppComponent class AppComponent_Host - inline template:0:0BrowserDomAdapter.logError @ platform-browser.umd.js:937BrowserDomAdapter.logGroup @ platform-browser.umd.js:947ExceptionHandler.call @ core.umd.js:4389(anonymous function) @ core.umd.js:9890ZoneDelegate.invoke @ zone.js:332onInvoke @ core.umd.js:9245ZoneDelegate.invoke @ zone.js:331Zone.run @ zone.js:225(anonymous function) @ zone.js:591ZoneDelegate.invokeTask @ zone.js:365onInvokeTask @ core.umd.js:9236ZoneDelegate.invokeTask @ zone.js:364Zone.runTask @ zone.js:265drainMicroTaskQueue @ zone.js:497ZoneTask.invoke @ zone.js:437
    platform-browser.umd.js:937
    platform-browser.umd.js:937 Error: DI Exception
        at NoProviderError.BaseException [as constructor] (core.umd.js:4472)
        at NoProviderError.AbstractProviderError [as constructor] (core.umd.js:4602)
        at new NoProviderError (core.umd.js:4638)
        at ReflectiveInjector_._throwOrNull (core.umd.js:6532)
        at ReflectiveInjector_._getByKeyDefault (core.umd.js:6560)
        at ReflectiveInjector_._getByKey (core.umd.js:6523)
        at ReflectiveInjector_.get (core.umd.js:6332)
        at NgModuleInjector.get (core.umd.js:10386)
        at DebugAppView._View_AppComponent_Host0.createInternal (AppComponent.ngfactory.js:20)
        at …

对于身份验证,我使用的是Auth0 AuthenticationApi.在Account Controller中,我需要获取user_metadata但它已丢失.获取user_metadata的任何替代方法？

AuthenticationApiClient client = new AuthenticationApiClient(new Uri($"https://{_auth0Options.Domain}/"));

               var authenticateResponse = await client.GetTokenAsync(new ResourceOwnerTokenRequest
                {
                    ClientId = _auth0Options.ClientId,
                    ClientSecret = _auth0Options.ClientSecret,
                    Scope = "openid",
                    Realm = _auth0Options.Connection,
                    Username = vm.EmailAddress,
                    Password = vm.Password
                });
                var user = await client.GetUserInfoAsync(authenticateResponse.AccessToken);
                if (user.UserMetadata != null)
                {
        // Giving error...any alternative to access the userMetaData ?
                }

我正在ASP.NET Core 2.1中开发一个应用程序，并在Kubernetes群集上运行它。我已经使用Auth0作为提供者，使用OpenIDConnect实现了身份验证。

这一切都很好。标有该[Authorize]属性的操作或控制器将匿名用户重定向到身份提供者，他们登录，重定向回来，而Bob是您的叔叔。

当我将部署扩展到2个或更多容器时，就会开始出现问题。当用户访问应用程序时，他们将登录，并根据回调过程中为它们提供服务的容器，身份验证是成功还是失败。即使在身份验证成功的情况下，当用户点击未授权的容器时，反复进行F5-ing操作也会最终重定向到身份提供者。

我对此的思路是，使用cookie身份验证，用户将cookie存储在浏览器中，并随每个请求一起传递，应用程序对其进行解码并获取JWT，然后从中获取声明，然后用户已认证。这使整个事情变得无状态，因此，不管为请求提供服务的容器如何，它都应该工作。但是，如上所述，它似乎并没有以这种方式实际工作。

我的配置Startup.cs如下所示：

services.AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    })
    .AddCookie()
    .AddOpenIdConnect("Auth0", options =>
    {
        options.Authority = $"https://{Configuration["Auth0:Domain"]}";

        options.ClientId = Configuration["Auth0:ClientId"];
        options.ClientSecret = Configuration["Auth0:ClientSecret"];

        options.ResponseType = "code";

        options.Scope.Clear();
        options.Scope.Add("openid");
        options.Scope.Add("profile");
        options.Scope.Add("email");

        options.TokenValidationParameters = new TokenValidationParameters
        {
            NameClaimType = "name"
        };

        options.SaveTokens = true;

        options.CallbackPath = new PathString("/signin-auth0");

        options.ClaimsIssuer = "Auth0";

        options.Events = new OpenIdConnectEvents
        {
            OnRedirectToIdentityProviderForSignOut = context =>
            {
                var logoutUri =
                    $"https://{Configuration["Auth0:Domain"]}/v2/logout?client_id={Configuration["Auth0:ClientId"]}";

                var postLogoutUri …

Auth0 提供了大量资源列表，描述了身份验证的最佳实践。其中有一连串建议不要localStorage用作存储 (JWT) 令牌的手段。

• https://auth0.com/docs/security/store-tokens#don-t-store-tokens-in-local-storage
• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#local-storage
• https://github.com/auth0/docs/issues?utf8=%E2%9C%93&q=localstorage

我发现这些点有几个问题：

• 强烈假设 JWT 令牌是攻击者不得访问的敏感信息（通过 XSS）
  • 从我的角度来看，访问令牌本身并没有扩大攻击范围。如果攻击者可以控制受害者的浏览器，他们可以使用令牌从受影响的浏览器本身执行调用。
  • 访问令牌通常具有相当短的到期时间，并且它们可以被浏览器固定，从而减少在 XSS 上下文之外使用它们的机会。
• Auth0 建议使用auth0.getTokenSilently()他们的 SDK 来获取令牌，但据我所知，攻击者没有任何理由不能自己调用​​这个方法（即注入另一个 sdk 脚本，使用现有的客户端密钥，并且只是调用getToken 从那里），从而以几乎相同的方式获取令牌，就好像它存储在localStorage
• 我知道 XSS 无法访问令牌的唯一方法基本上是使用 httpOnly cookie，但这本身会创建新的向量 (CSRF)，并且仍然无法阻止攻击者从受影响的浏览器中调用 api。

所以我完全同意 OWASP 的建议，不要将敏感数据localStorage存储在 . 但这只是因为这些东西会允许攻击者扩大攻击范围（访问银行帐户，尝试在其他应用程序中重复使用用户的密码等）。但我很难看出 accessTokens 是如何受此影响的。

我有一个隐藏在 Auth0 锁后面的单页应用程序，使用@auth0/auth0-spa-js。我想使用 Cypress 对其进行测试，因此我决定关注Auth0官方博客文章以及 Johnny Reilly博客文章。

我能够使用建议的请求从 auth0 成功检索有效的 JWT 令牌。我不知道该怎么办:(

我面临的问题是，上述两种方法都依赖于应用程序在本地存储 JWT 令牌（在 cookie 或 localstorage 中）。然而，@auth0/auth0-spa-js使用不同的方法，我假设所有相关的 cookie/localstorage 都存储在 auth0 域中。

你有什么想法，如果有办法绕过它吗？

2018 年 7 月这里报告了一个类似的问题，没有真正提供任何解决方案

我正在使用 React（react-create-app 和 TypeScript）。使用 Auth0 进行登录。

我想用 Jest 编写测试，我发现这个资源基本上是唯一关于模拟 Auth0 对象的内容。

所以我的代码看起来像这样：

import React from "react";
import ReactDOM from "react-dom";
import TopBar from "./index";
import {
  useAuth0
} from "react-auth0-spa";

const user = {
  email: "johndoe@me.com",
  email_verified: true,
  sub: "google-oauth2|12345678901234"
};

// intercept the useAuth0 function and mock it
jest.mock("react-auth0-spa");

describe("First test", () => {
  beforeEach(() => {
    // Mock the Auth0 hook and make it return a logged in state
    useAuth0.mockReturnValue({
      isAuthenticated: true,
      user,
      logout: jest.fn(),
      loginWithRedirect: jest.fn()
    }); …

我有一个基于 Auth0 的快速入门应用程序之一的 Vue SPA（https://github.com/auth0-samples/auth0-vue-samples）。开箱即用，一切正常，但是一旦我尝试在组件代码中使用 Auth0 客户端，我就会遇到问题。我遵循了“调用 API”教程（https://auth0.com/docs/quickstart/spa/vuejs/02-calling-an-api），它无助地只展示了如何使用按钮调用 API。我想要做的是在初始页面加载时触发对我的 API 的经过身份验证的调用，以便我可以确保某些数据存在于我自己的 API 中（如果没有，则创建它）。这看起来应该很简单。我只是将这段代码扔到我创建的 Vue 组件钩子中：

await this.$auth.getTokenSilently().then((authToken) => {
    // reach out to my API using authToken
});

如果应用程序从我的 npm 开发服务器热重新加载，这实际上可以正常工作，它会访问我的 API，该 API 使用令牌授权请求，并发回正确的数据。问题是当我手动重新加载页面时，这会导致：

Uncaught (in promise) TypeError: Cannot read property 'getTokenSilently' of null
    at Vue.getTokenSilently (authWrapper.js?de49:65)
    at _callee$ (App.vue?234e:49)

在 authWrapper.js 文件（Auth0 客户端所在的位置）中，函数调用如下：

getTokenSilently(o) {
    return this.auth0Client.getTokenSilently(o);
}

当我调试调用时，“auth0Client”不存在，这就是它失败的原因。我无法理解的是在我尝试拨打电话之前确保它确实存在的正确方法。样本中没有任何内容表明执行此操作的正确方法。我尝试将我的组件代码放在不同的组件和不同的 Vue 生命周期钩子（created、beforeMount、mounted 等）中，所有结果都相同。客户端成为后800毫秒左右可用，但不是这个代码执行时。

这显然是一个时间问题，但我不清楚如何告诉我的组件代码坐下来等待 this.auth0Client 为非空而不做一些像 setInterval 那样可怕和骇人听闻的事情。

使用 express-openid-connect 时出现此错误

TypeError: "secret" is required
    at module.exports.get (/home/mathkr/persodev/node_modules/express-openid-connect/lib/config.js:166:11)
    at module.exports (/home/mathkr/persodev/node_modules/express-openid-connect/middleware/auth.js:27:18)
    at Object.<anonymous> (/home/mathkr/persodev/server.js:26:9)

我的server.js代码是

const express = require('express');
const app = express();
const port = process.env.PORT || 4200;
const {auth, requiresAuth} = require('express-openid-connect');
const dotenv = require('dotenv');
const session = require('express-session');

const sess = {
  secret: 'somethingsecret',
  cookie: {},
  resave: false,
  saveUninitialized: true
};
if (app.get('env') === 'production') {
  sess.cookie.secure = true;
  app.set('trust proxy', 1);
}
app.use(session(sess));

const config = {
  ...(dotenv.config()).parsed,
  authRequired: false,
  auth0Logout: …

由于目前没有适用于 SvelteKit 的 Auth0 SDK，因此当我打算将 Auth0 合并到我的 SvelteKit 应用程序中（包括服务器端身份验证）时，我正在学习（或至少尝试学习）有关身份验证的知识，这比我最初的意图要多得多。该文档有点令人困惑（或者可能它只是很大，或者可能我只是不那么聪明），所以我希望在这里描述我的身份验证流程以供批评（希望这对将来的其他人有帮助） ）。

我已经阅读了这篇关于 SPA auth以及Auth0 教育产品的精彩文章。但我仍然不确定我是否正确地将这些点连接起来。这是我的流程。所有这一切仅通过 SSL 发生。

\n
1. 我使用他们的客户端 SDK ( @auth0/auth0-spa-js )在客户端创建一个 Auth0 客户端。该客户端通过 Auth0 弹出窗口执行身份验证。
\n
2. 一旦通过身份验证，一切都会在客户端按预期运行。但如果我想在服务器端控制对路由的访问，我需要将信息返回到服务器。所以...
\n
3. 身份验证后，Auth0 创建一个 ID 令牌（签名的 JWT），该令牌存储在浏览器的本地存储中。我将其保存为会话 cookie（SameSite=strict; HTTPOnly; Secure;设置了选项），以便它通过路由授权请求传递回服务器。
\n

所以让我在这里暂停一下...我明白（至少根据一些内容，包括上面链接的 Auth0 教育视频）ID 令牌不应该用于身份验证，并且永远不应该被传递。这就是访问令牌的用途。然而，在这种情况下，交换都是第一方（我的客户端，我的服务器），我的理解是“可以”。

然而，Auth0 SDK 本身并没有设置 cookie，这确实让我感到紧张。这让我怀疑我是否做错了\xe2\x84\xa2。

\n

4. 在服务器上，我使用公钥验证 id_token，然后可以根据需要在后端保存用户详细信息等，并允许访问适当的路由（hooks.server.js在我的 SvelteKit 应用程序中通过）。

   \n
\n

5. 当用户注销或令牌过期时，cookie 将被删除。

   \n
\n

（顺便说一句，我还没有弄清楚如何在 ID 令牌过期时刷新它，因为 Auth0 客户端 SDK 似乎永远不会更新浏览器存储中的 ID 令牌，即使它已过期。）