OAuth隐式流访问令牌每小时过期一次 [英] OAuth Implicit flow Access Token expires every hour

查看:87
本文介绍了OAuth隐式流访问令牌每小时过期一次的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在使用Google Assistant的OAuth隐式流程时遇到了问题。
我设法建立了一个OAuth服务器并使其正常工作。流程如下:

I'm having a problem with the OAuth Implicit flow for the Google Assistant. I managed to set up a OAuth server and got it to work. Here's the flow:

用户被重定向到我的端点,使用Google帐户进行身份验证,并使用Acces令牌和结果代码= SUCCES发送回Assistant。

The user Is redirected to my endpoint, authenticates with a Google account, and gets send back to the Assistant with an Acces Token and result code=SUCCES.

在我的个人资料中,我通过执行https请求来获取用户的电子邮件地址: https://www.googleapis.com/plus/v1 / people / me?access_token = access_token

In my fullfilment I get the users email address by doing a https request to: https://www.googleapis.com/plus/v1/people/me?access_token=access_token.

然后我在数据库中找到匹配的用户,并为此将acces令牌添加到数据库中

I then find the matching user in my database and add the acces token to the database for this user.

下次用户登录时,我检查acces令牌并按用户名打招呼。

The next time the user logs in I check the acces token and greet the user by their name.

现在的问题是,这是隐式流,根据文档,该流应该具有永不过期的访问令牌:

Now the problem is that this is the Implict flow which according to the documentation should have an access token that never expires:


注意: Google要求使用隐式
流发行的访问令牌必须永不过期,因此您无需像其他OAuth 2.0流程那样记录
访问令牌的授予时间。

Note: Google requires that access tokens issued using the implicit flow never expire, so you don't need to record the grant time of an access token, as you would with other OAuth 2.0 flows.

但是助手强迫我每小时重新进行身份验证,这意味着访问令牌确实过期了。

But the Assistant forces me to re-authenticate every hour, meaning the access token did expire.

我的问题是:这个流程正确还是我想念东西吗?我的OAuth端点有做错什么吗?

My question is: Is this flow correct or am I missing something? Is there something I've done wrong in my OAuth endpoint?

我的端点基于 https://developers.google.com/identity/protocols/OAuth2UserAgent

<html>

  <head>
    <script src="https://apis.google.com/js/platform.js" async defer></script>
    <meta name="google-signin-client_id" content="CLIENT_ID">
  </head>

  <body>
    <script>
      var YOUR_CLIENT_ID = 'CLIENT_ID';

    function oauth2SignIn() {
        // Google's OAuth 2.0 endpoint for requesting an access token
        var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';

        // Create element to open OAuth 2.0 endpoint in new window.
        var form = document.createElement('form');
        form.setAttribute('method', 'GET'); // Send as a GET request.
        form.setAttribute('action', oauth2Endpoint);

        //Get the state and redirect_uri parameters from the request
        var searchParams = new URLSearchParams(window.location.search);
        var state = searchParams.get("state");
        var redirect_uri = searchParams.get("redirect_uri");
        //var client_id = searchParams.get("client_id");

        // Parameters to pass to OAuth 2.0 endpoint.
        var params = {
          'client_id': YOUR_CLIENT_ID,
          'redirect_uri': redirect_uri,
          'scope': 'email',
          'state': state,
          'response_type': 'token',
          'include_granted_scopes': 'true'
        };

        // Add form parameters as hidden input values.
        for (var p in params) {
          var input = document.createElement('input');
          input.setAttribute('type', 'hidden');
          input.setAttribute('name', p);
          input.setAttribute('value', params[p]);
          form.appendChild(input);
        }

        // Add form to page and submit it to open the OAuth 2.0 endpoint.
        document.body.appendChild(form);
        form.submit();
      }
  oauth2SignIn();
    </script>
  </body>

  </html>


推荐答案

听起来您正在做的事情就是吸引用户登录到您的页面,并使用它从Google服务获取身份验证令牌。然后,您需要将其转回并将其传递回助手,并称为身份流。

It sounds like what you are doing is having the user log into your page, and using this to get an auth token from a Google service. You're then turning this around and passing this back to the Assistant and calling this the Identity Flow.

虽然很聪明-这不是身份流。

While clever - this isn't the Identity Flow.

这是您使用Auth Code Flow向Google验证用户身份,然后将该令牌返回给Google并假装这是Identity Flow令牌。但是,由于您使用的是Auth Code Flow,因此您获得的auth令牌将在一个小时后过期。 (您可以在从Google那里获得的信息中查看生命周期。)

This is you using the Auth Code Flow to authenticate the user with Google, and then returning this token to Google and pretending this is an Identity Flow token. However, since you're using the Auth Code Flow, the auth tokens that you get back expire after an hour. (You can check out the lifetime in the information you get back from Google.)

如果您尝试进行帐户关联而不自己进行任何管理,则需要实现一个OAuth服务器,该服务器代理从助手到Google的身份验证代码流请求,以及从谷歌到助手的回复。虽然可行,但这可能是违反其政策

If you are trying to do Account Linking and not manage anything yourself, you need to actually implement an OAuth server that proxies the Auth Code Flow requests from the Assistant to Google and the replies from Google back to the Assistant. While doable, this may be in violation of their policy, and isn't generally advised anyway.

更新以解决您评论中的某些问题/问题。

Update to address some questions/issues in your comment.


使用Google Auth端点也不会存储会话,因此您仍然必须每小时重新进行验证

using the Google Auth endpoints doesn't store the session either, so you'd still have to re-authenticate every hour

由于Google Auth端点使用Auth Code Flow,因此您可以使用 offline 模式请求刷新令牌。然后,当身份验证令牌过期时,您可以使用刷新令牌来获取新的身份验证令牌。因此,您仍然具有访问的长期授权,并且可以获取短期令牌来完成所需的工作。

Since the Google Auth endpoints use the Auth Code Flow, you can use the offline mode to request a refresh token. Then, when an auth token expires, you can use the refresh token to get a new auth token. So you still have a long-term authorization for access and can get the short-term token to do the work you need.

试图将其引入身份流,但是,不起作用。 (即使这样做,也是一个非常糟糕的主意。)

Trying to shoehorn this into the Identity Flow, however, doesn't work. (And would be a really bad idea, even if it did.)


您能否提供一些关于如何为该端点创建端点的说明?隐式流?

Can you provide some clarification on how to create an endpoint for the implicit flow?

除了您的OAuth服务器代码可以在助手文档中进行分步说明,我不确定您需要什么说明。您的OAuth服务器从根本上只需要:

Beyond the step-by-step description of what your OAuth server code can do in the Assistant documentation, I'm not sure what clarification you need. Your OAuth server fundamentally just needs to:


  • 能够拥有一个用户:


    • 连接到HTTPS URL

    • 进行身份验证

    • 授权Assistant代表他们联系您的服务

    Action Webhook必须能够:

    And the Action webhook needs to be able to:


    • 接受此代码作为助手请求的一部分,并且

    • 从此代码中找出用户是谁。 (即-将代码映射到系统中的用户帐户。)

    您可以通过多种方式来完成所有操作。 OAuth服务器和Action可以在同一台服务器上,也可以在单独的服务器上,但是它们至少需要就该代码是什么以及如何映射到您的用户帐户达成一些协议。

    There are a variety of ways you can do all of that. The OAuth server and Action could be on the same server or separate, but they at least need to have some agreement about what that code is and how that maps to your user accounts.

    如果您的主要需求是代表您的用户访问Google API,那么您拥有的用户帐户可能会存储用于访问Google服务器的OAuth令牌。但是您应该在逻辑上将其与助手用于访问您的服务器的代码分开。

    If your primary need is to access Google APIs on behalf of your user - then the user account that you have will likely store the OAuth tokens that you use to access Google's server. But you should logically think of that as separate from the code that the Assistant uses to access your server.

    (顺便说一下,这些步骤是用于身份流的。验证码流还有更多步骤,但是基本原理是相似的。尤其是在操作方面。)

    (As an aside - those steps are for the Identity Flow. The Auth Code Flow has a few more steps, but the fundamentals are similar. Especially on the Action side.)

    这篇关于OAuth隐式流访问令牌每小时过期一次的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆