【实例图文详解】OAuth 2.0 for Web Server Applications

        OAuth 2.0 for Web Server Applications, verifying a user's Android in-app subscription

       

        在写本文之前先说些题外话。

        前段时间游戏急于在GoolePlay上线,明知道如果不加Auth2.0的校验是不安全的还是暂时略过了这一步,果然没几天就发现后台记录与玩家实际付费不太一致,怀疑有玩家盗刷游戏元宝等,并且真实的走过了GooglePlay的所有支付流程完成道具兑换,时间一长严重性可想而知。经过查阅大量google官方文档后把代码补上,并在这里记录下OAuth 2.0 的使用,Google提供了OAuth2.0的好几种使用用途,每种使用方法都有些不同,具体可以看下 这篇博客。在这里只写OAuth 2.0 for Web Server Applications的使用,涉及refresh_token, access_token等的获取和使用,以及如何向google发送GET和POST请求等,最终完成用户在安卓应用内支付购买信息的校验。

        先贴下关于Using OAuth 2.0 for Web Server Applications的解释的谷歌官方原文

        The authorization sequence begins when your application redirects a browser to a Google URL; the URL includes query parameters that indicate the type of access being requested. As in other scenarios, Google handles user authentication, session selection, and user consent. The result is an authorization code, which Google returns to your application in a query string.
        After receiving the authorization code, your application can exchange the code (along with a client ID and client secret) for an access token and, in some cases, a refresh token.
        The application can then use the access token to access a Google API.
        If a refresh token is present in the authorization code exchange, then it can be used to obtain new access tokens at any time. This is called offline access, because the user does not have to be present at the browser when the application obtains a new access token.

通过原文和图解我们可以知道这样一个流程(下文会详细说明):

        一. 在Google Developer Console中创建一个 Web Application账户,得到client_id,client_secret 和 redirect_uri,这3个参数后边步骤常用到(此为前提)

        二. 获取Authorization code 

        三. 利用code 获取access_token,refresh_token

        四. 进一步可利用refresh_token获取新的access_token

        五. 使用access_token 调用Google API 达到最终目的(如果access_token过时,回到第四步)

        需注意的是:在第三步操作,当我们第一次利用code获取access_token时,谷歌会同时返回给你一个refresh_token,以后再次用code获取access_token操作将不会再看到refresh_token,所以一定要保存下来。这个refresh_token是长期有效的,如果没有明确的被应用管理者撤销是不会过期的,而access_token则只有3600秒的时效,即1个小时,那么问题来了,access_token和refresh_token是什么关系?很明显的,我们最终是要使用access_token 去调用Google API,而access_token又有时效限制,所以当access_token过期后,我们可以用长效的refresh_token去再次获取access_token,并且可以可以在任何时间多次获取,没有次数限制。其实当我们得到refresh_token后,就是一个转折点。  

        下面详细分解步骤:

一、在Google Developer Console中创建一个Web application账户

    (这里使用的是新版的Google Developer Console页面,其实可在Account settings中设置为中文显示~)

        

        其中4.可以随意填写。创建完成后可以看下下图所示:



        在这里我们拿到3个关键参数: client_idclient_secret,redirect_uris,,于下边步骤。

可能会有人有疑问,怎么就能确定在google develope

  • 5
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 43
    评论
OAuth2.0是一种用于授权的开放标准,允许用户提供给第三方应用程序有限访问他们在某一特定服务上的资源的能力。OAuth2.0的实现涉及到三个主要参与方:用户、客户应用程序和授权服务器。 举个例子来说明OAuth2.0的实现过程。假设用户使用某个社交媒体平台(如微信)登录某个第三方应用程序(如新闻阅读应用)。在这个过程中,有一个客户应用程序正在请求访问平台上的某个特定资源,比如用户的公开个人信息或者朋友列表。 首先,用户在第三方应用程序中点击使用微信登录的按钮。然后,第三方应用程序将跳转到微信的授权服务器上。 在授权服务器上,用户会被要求提供对应用程序的访问权限。用户可以查看应用程序请求的具体权限范围,并选择授权或拒绝。如果用户同意,授权服务器将颁发访问令牌给第三方应用程序。 此时,第三方应用程序可以使用颁发的访问令牌来访问用户的资源。例如,如果该应用程序请求访问用户的朋友列表,它可以使用访问令牌来向微信平台发出请求,并获取用户的朋友列表。 OAuth2.0的实现提供了更安全和更灵活的授权方法,保护用户的隐私和资源。它允许用户对访问权限进行细粒度的控制,并提供了一种可靠的方式,让用户无需共享他们的用户名和密码就可以与第三方应用程序进行交互。 总之,OAuth2.0实例是在用户和第三方应用程序之间建立授权连接,使得第三方应用程序能够通过用户的访问令牌来访问用户在特定服务上的资源。这个实现过程中,授权服务器和访问令牌起到了关键的作用。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 43
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值