oauth

个性化token 背景 上一篇文章 《Spring Security OAuth 个性化token（一）》 有提到，oauth2.0 接口默认返回的报文格式如下： { "access_token": "e6669cdf-b6cd-43fe-af5c-f91a65041382", "token_type": "bearer", "refresh_token": "da91294d-446c-4a89-bdcf-88aee15a75e8", "expires_in": 43199, "scope": "server" } 通过上篇文章我们已经可以扩展增加部分业务字段。 { "access_token":"a6f3b6d6-93e6-4eb8-a97d-3ae72240a7b0", "token_type":"bearer", "refresh_token":"710ab162-a482-41cd-8bad-26456af38e4f", "expires_in":42396, "scope":"server", "tenant_id":1, "license":"made by pigx", "dept_id":1, "user_id":1, "username":"admin" } 「在一些场景下我们需要自定义一下返回报文的格式,例如pig 使用R 对象返回，全部包含code业务码信息

这篇文章主要介绍了关于PHP实现微信网页登陆授权开发，有着一定的参考价值，现在分享给大家，有需要的朋友可以参考一下 更多PHP相关知识请关注我的专栏 PHP ​zhuanlan.zhihu.com 微信开放平台和公众平台的区别 1.公众平台面向的时普通的用户，比如自媒体和媒体，企业官方微信公众账号运营人员使用，当然你所在的团队或者公司有实力去开发一些内容，也可以调用公众平台里面的接口，比如自定义菜单，自动回复，查询功能。目前大多数微信通过认证之后，都在做这个事情。 2.开放平台面向的开发者和第三方独立软件开发商。我觉得开发平台最大的开放就是微信登录。当年腾讯没有花大力气去做统一登录这个事情，导致目前各个网站都要弄一套登录机制。好在他们现在认清了局势。开发者或软件开发商，通过微信开放提供的平台和接口，可以开发适合企业的电子商务网站，扫描二维码进去一个游戏界面，然后去购买商品等。当然后续开放平台要开放支付接口，那么类似口袋通这种软件开发厂商，就可以为大型，中小企业提供微信小店这种服务和软件了。 公众平台就是服务号订阅号的管理开发后台。 开发平台说得通俗一点就是实现手机里边安装软件的内容一键分享朋友圈； 下面的第三方登陆就是依托于开放平台（ http:// open.weixin.qq.com ）的功能 准备工作 网站应用微信登录是基于OAuth2.0协议标准构建的微信OAuth2

在微信开放平台 【管理中心/应用详情】 设置的 【开发信息】 【授权回调域】 只要填定域名，不带https://，不带具体的页面，就可以了，不需要填完整的请求路径， 如图： 在https://open.weixin.qq.com/connect/qrconnect?appid=你的APPID&redirect_uri=回调的具体地址&response_type=code&scope=snsapi_login 中的可以在前面加上https://头，后面加上具体的回调页面， 还有一点提醒：本地调试域名可设置为本地IP 127.0.0.1是合法的． 在redirect_uri中要填http://127.0.0.1/oauth是可以的 效果： 来源： oschina 链接： https://my.oschina.net/u/4343285/blog/3274966

在微信开放平台 【管理中心/应用详情】 设置的 【开发信息】 【授权回调域】 只要填定域名，不带https://，不带具体的页面，就可以了，不需要填完整的请求路径， 如图： 在https://open.weixin.qq.com/connect/qrconnect?appid=你的APPID&redirect_uri=回调的具体地址&response_type=code&scope=snsapi_login 中的可以在前面加上https://头，后面加上具体的回调页面， 还有一点提醒：本地调试域名可设置为本地IP 127.0.0.1是合法的． 在redirect_uri中要填http://127.0.0.1/oauth是可以的 效果： 来源： oschina 链接： https://my.oschina.net/u/4346166/blog/3274971

OAuth 2.1是整合和简化OAuth 2.0的一项正在进行中的工作。 自2012年OAuth 2.0（RF​​C 6749）首次发布以来，已经发布了一些新的RFC，它们在核心规范中添加或删除了功能 包括用于原生APP的OAuth 2.0（RF​​C 8252） 用于代码交换的证明密钥（RFC 7636）。 ）， 用于基于浏览器的应用程序的OAuth OAuth 2.0安全性最佳实践。 OAuth 2.1合并了这些规范的更改，以简化核心文档 与OAuth 2.0的主要区别如下: 授权代码授予使用PKCE中的功能进行了扩展，因此，根据本规范使用授权代码授予的唯一方法需要添加PKCE机制。 重定向URI必须使用完全匹配的字符串进行比较 该规范中省略了隐式授予（response_type = token） 此规范中省略了“资源所有者密码凭证”授予 承载令牌用法忽略了URI查询字符串中承载令牌的使用 刷新令牌必须受发送者限制或一次性使用 来源： oschina 链接： https://my.oschina.net/u/4350184/blog/3274348

oauth2.0中的隐式模式是下面这样的 , 直接通过前端页面访问授权服务获取token , 授权服务直接重定向回去 , 在浏览器//域名/回调url#access_token 把token以url哈希的形式 , 在#后面带回去了 这种方式非常不安全 , token容易泄露 一般的流程是在申请应用的地方 , 会自动生成client_id , 并且让填一个回调地址 , 那这俩参数来获取token 1. 获取code https://b.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read 比如qq的第三方登陆 , 就可以以这种方式 ,直接在自己页面上放个这个链接 , 就可以调到qq授权页 , 授权成功的会跳回自己的网站 , 在回调地址后面带着token 来源： oschina 链接： https://my.oschina.net/u/4386991/blog/3274083

oauth2.0中的隐式模式是下面这样的 , 直接通过前端页面访问授权服务获取token , 授权服务直接重定向回去 , 在浏览器//域名/回调url#access_token 把token以url哈希的形式 , 在#后面带回去了 这种方式非常不安全 , token容易泄露 一般的流程是在申请应用的地方 , 会自动生成client_id , 并且让填一个回调地址 , 那这俩参数来获取token 1. 获取code https://b.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read 比如qq的第三方登陆 , 就可以以这种方式 ,直接在自己页面上放个这个链接 , 就可以调到qq授权页 , 授权成功的会跳回自己的网站 , 在回调地址后面带着token 来源： oschina 链接： https://my.oschina.net/u/4345306/blog/3273980