您的位置: 首页  >  技术问答  >  使用OAuth2进行身份验证并与google.appengine.api.users服务兼容

使用OAuth2进行身份验证并与google.appengine.api.users服务兼容

分类: 技术问答 • 2022-03-30 00:20:44

使用OAuth2进行身份验证并与google.appengine.api.users服务兼容

问题描述：

我们正在尝试将我们的应用程序放到Google Marketplace上，其中一项要求是使用OAuth2进行身份验证.不幸的是(奇怪的是)，AppEngine对此没有选择.

We're trying to put our app on Google Marketplace, and one of the requirements was to use OAuth2 for authentication. Unfortunately (and strangely), AppEngine doesn't have an option for this.

现在，我们正在使用OpenID进行身份验证.我一直在尝试在线查找资源，但未能找到有关如何正确执行此操作的权威指南.

Right now, we are using OpenID for authentication. I've been trying to find resources online, but have failed in finding a definitive guide on how to do this properly.

我担心的是:

  1. 我应该使用什么范围?
  2. 应如何管理会话? (用户服务处理得很好)
  3. 当地的发展过程如何?我需要连接互联网才能使用dev_appserver.py吗?
  4. 我们严重依赖提供的 user_id 属性通过用户服务.切换到OAuth2时可以依靠它具有相同的值吗?
  5. 其他AppEngine服务(依赖于Users服务的服务)是否可能发生冲突?
  6. app.yaml中的login: required标志在迁移后是否仍能按预期工作?
  1. What scope should I use?
  2. How should sessions be managed? (the Users service handled this very well)
  3. What would the local development process be like? Would I need to have an internet connection to be able to use dev_appserver.py?
  4. We rely heavily on the user_id property provided by the Users service. Can I rely on it having the same value when switching to OAuth2?
  5. Any possible conflicts in other AppEngine services (ones that rely on Users service)?
  6. Would the login: required flag in app.yaml still work as expected after migrating?

此外，如果我们继续使用Users服务，那就太好了.

Also, it would be great if we could keep on using the Users service.

编辑:稍微偏离主题，但我认为AppEngine .仍然说支持OpenID是将您的应用程序与Google App Marketplace集成的强大方法"，情况不再如此.

Slightly off-topic, but I think the AppEngine docs for the Users service needs to be updated. It still says "supporting OpenID is a powerful way to integrate your app with Google App Marketplace", which isn't the case anymore.

答

您提出了很多问题，因此(在将我们自己的应用程序从OAuth1迁移到OAuth2之后)，我将只解决我所知道的问题.

You have lots of questions asked, so I'll address only the ones I know the answers to (after migrating our own app from OAuth1 to OAuth2).

注意:对于这个问题，我最想强调的就是我的Aha Moment: 在用户安装了GAM应用后，访问您可以访问的API可能会与最终用户对您的应用的访问权限完全分开. IE.在您的应用获得域管理员的许可后(安装后)，您可以使用App Engine服务帐户从服务器端访问所有API.仅当用户访问您的应用时，才使用users API.这样就完全分离了.话虽如此，这是我的见解.

Note: The thing I want to stress most about this issue, and which was the Aha Moment for me is: Accessing the APIs to which you got access from user after he installed your GAM app could be completely separated from the end user access to your app. I.E. After you got permissions from the domain admin for your app (after he installed it) you can use your App Engine service account to access all the APIs, from the server side. You use the users API only when users access your app. Thus, complete separation. With that said, here are my insights.

  1. 要使用的范围取决于所需的服务.我找不到从旧范围到新范围的明确映射-您必须使用 https://developers.google.com/oauthplayground/ 我还建议设置一个测试应用程序，仅用于OAuth测试.

  1. The scopes you're going to use depend on the services you require. I couldn't find a definite mapping from old scopes to new ones - you'll have to test stuff with https://developers.google.com/oauthplayground/ I also recommend setting up a test app, for OAuth testing only.

就我们的应用而言，会话将照常进行管理，您拥有常规的User对象并可以按预期使用它.与Google API的交互是通过App Engine服务帐户完成的.简而言之，您可以使用用户api管理用户对应用的访问和权限，而Google可以使用服务帐户和管理员电子邮件生成的令牌来管理对API的访问. (此问题是一个帖子)

As far as our app is concerned, sessions are managed as usual, you have the usual User object and work with it as you'd expect. The interaction with Google APIs is done via an App Engine service account. Which in simpler word means, you manage user access and permissions to your app using the users api, and Google manages access to it's APIs using the tokens generated with the service account and the admin's emails. (This issue is a post on it's own)

我不确定你的意思是什么.

I'm not sure what you mean by that one.

用户API应该可以按预期运行.

The users API should work as expected.

我们还没有任何(令人惊讶！)，但是我想这取决于您的实现方式

We haven't had any (surprisingly!), but I guess that depends on your implementation

login: required应该可以按预期方式工作，因为它的工作方式与用户api相同

login: required should work as expected as it works in the same manner as the users api

相关推荐