是什么阻止其他应用窃取我的Google OAuth客户端ID? [英] What prevents another app from stealing my Google OAuth client ID?

查看:59
本文介绍了是什么阻止其他应用窃取我的Google OAuth客户端ID?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我创建了一个使用AppAuth进行Google OAuth身份验证的Android应用.在Google Cloud Platform Console中,我为我的应用程序创建了Android OAuth 2.0客户端ID,并提供了应用程序包名称和签名证书指纹.一切正常.

I created an Android app that uses AppAuth to authenticate with Google OAuth. In the Google Cloud Platform Console, I created an Android OAuth 2.0 client ID for my app and provided the app package name and signing-certificate fingerprint. Everything is working fine.

我想确认只有我的应用可以使用该客户端ID.因此,我创建了另一个具有不同程序包名称的应用程序,并使用了不同的签名证书对其进行了签名.使用相同的客户端ID,我仍然可以通过Google进行身份验证并访问API.我认为情况并非如此.我正在查看AppAuth的源代码,看起来好像它在身份验证流程中从未使用过应用程序签名或程序包名称.它当然使用PKCE,但我希望还会有更多事情发生.

I wanted to verify that only my app can use that client ID. So I created a second app with a different package name and signed it with a different signing certificate. Using that same client ID, I'm still able to authenticate with Google and access APIs. I didn't think this should be the case. I was looking at the source code for AppAuth and it doesn't look like it ever uses the app signing or package name during the authentication flow. It uses PKCE of course, but I expected more to be happening.

因此,如果我可以毫不费力地窃取自己的客户端ID,该如何阻止其他人从我的APK中提取客户端ID并将其用于身份验证?根据我的软件包名称,很容易确定我用于重定向URI的自定义方案.因此,胭脂应用程序可以将AppAuth配置为使用类似的重定向URI并捕获授权结果.而且由于PKCE仅用于验证授权请求和代码交换来自同一位置,因此rouge应用程序会同时执行这两种操作,因此那里也没有真正的保护.

So if I can steal my own client ID with little effort, what's to stop someone else from extracting my client ID from my APK and using it for authentication? The custom scheme I'm using for redirect URI is easy to figure out based on my package name. So the rouge app could configure AppAuth to use a similar redirect URI and capture the authorization result. And since PKCE is only used to verify the authorization request and code exchange come from the same place, a rouge app would be doing both so there's no real protection there either.

我可以将客户端ID类型切换为Web或其他",但这将要求我使用客户端密码,如果将其嵌入到应用程序中,这也是不安全的.

I could switch the client ID type to Web or Other, but that will require me to use a client secret, which is just as insecure if you embed it in an app.

我丢失了某些东西吗?还是Google OAuth能够按预期工作?

Am I missing something or is Google OAuth working exactly as it was intended?

推荐答案

对于客户端Google OAuth 2,您的客户端ID并不重要.客户端执行OAuth流,并且客户端接收OAuth令牌.魔术在于客户必须授权Google.任何人都可以窃取您的客户ID,但不能对其进行任何操作.作为OAuth生命周期的一部分,您应该验证OAuth令牌.您的后端不应盲目接受客户的任何东西-或不受您绝对控制的任何地方.

For client side Google OAuth 2, your Client ID does not really matter. The client performs the OAuth flow and the client receives the OAuth token. The magic is that the client must authorize Google. Anyone can steal your Client ID but they cannot do anything with it. As part of the OAuth lifecyle you should be validating OAuth tokens. Your backends should NOT be blindly accepting anything from a client - or anywhere not under your absolute control.

您的客户ID并非机密信息,您可以在代码中将其明示.

必须保留的客户端机密.客户端身份验证中不涉及客户端机密.客户端机密用于您的后端服务器上.

It is the Client Secret which must remain secret. The Client Secret is not involved in client side authentication. The Client Secret is used on your backend servers.

我认为您在混淆该过程.当客户端应用程序(您的应用程序,网络浏览器等)通过Google帐户进行身份验证时,您的应用程序未获得授权.客户端被授权.客户应正确判断他们访问的网站(或应用程序)并使用其Google登录信息.客户端可以使用其令牌执行的唯一操作是访问其自己的数据(Google云端硬盘,Gmail等).如果您的后端服务器正在接受客户端的OAuth令牌来管理访问,则您有责任验证该令牌及其在系统上的预期用法以及该令牌的授权人.

I think that you are confusing the process. When the client application (your app, a web browser, etc.) authenticates with Google Accounts, your app is not being authorized. The client is being authorized. The client should use good judgement on which websites they visit (or apps) and use their Google logins with. The only thing that a client can do with their token is access their own data (Google Drive, Gmail, etc.). If your backend servers are accepting the client's OAuth token to manage access, then you are responsible for validating that token and its desired usage on your systems and who that token is authorized from.

一个更好的选择是在后端(例如,您的Web服务器)上执行身份验证和授权.然后,您可以实施Google OAuth重定向,以将OAuth令牌发送到您的服务器.您受到保护,因为仅授权来源(例如您的域名)和授权重定向URI(Web服务器上的端点)可以参与身份验证过程.然后,您将令牌存储在客户端会话中,在必要时进行续订,根据需要添加授权范围,等等.

A better choice is to perform authentication and authorization on the backend (your web server for example). Then you can implement the Google OAuth redirect to send the OAuth token to your servers. You are protected in that only authorized origins (your domain name for example) and authorized redirect URIs (an endpoint on your web server) can be involved in the authentication process. You then store the token in your client session, renew when necessary, add authorization scopes as required, etc.

我经常使用这两种方法(客户端,服务器端),并且都很好用.

I frequently use both methods (client side, server side) and both work well.

这篇关于是什么阻止其他应用窃取我的Google OAuth客户端ID?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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