这组 OAuth 系列教程,第一篇介绍了基本概念,第二篇介绍了获取令牌的四种方式,今天演示一个实例,如何通过 OAuth 获取 API 数据。
很多网站登录时,允许使用第三方网站的身份,这称为"第三方登录"。
下面就以 GitHub 为例,写一个最简单的应用,演示第三方登录。
一、第三方登录的原理
所谓第三方登录,实质就是 OAuth 授权。用户想要登录 A 网站,A 网站让用户提供第三方网站的数据,证明自己的身份。获取第三方网站的身份数据,就需要 OAuth 授权。
举例来说,A 网站允许 GitHub 登录,背后就是下面的流程。
- A 网站让用户跳转到 GitHub。
- GitHub 要求用户登录,然后询问"A 网站要求获得 xx 权限,你是否同意?"
- 用户同意,GitHub 就会重定向回 A 网站,同时发回一个授权码。
- A 网站使用授权码,向 GitHub 请求令牌。
- GitHub 返回令牌.
- A 网站使用令牌,向 GitHub 请求用户数据。
下面就是这个流程的代码实现。
二、应用登记
一个应用要求 OAuth 授权,必须先到对方网站登记,让对方知道是谁在请求。
所以,你要先去 GitHub 登记一下。当然,我已经登记过了,你使用我的登记信息也可以,但为了完整走一遍流程,还是建议大家自己登记。这是免费的。
访问这个网址,填写登记表。
应用的名称随便填,主页 URL 填写http://localhost:8080
,跳转网址填写 http://localhost:8080/oauth/redirect
。
提交表单以后,GitHub 应该会返回客户端 ID(client ID)和客户端密钥(client secret),这就是应用的身份识别码。
三、示例仓库
我写了一个代码仓库,请将它克隆到本地。
$ git clone [email protected]:ruanyf/node-oauth-demo.git $ cd node-oauth-demo
两个配置项要改一下,写入上一步的身份识别码。
index.js
:改掉变量clientID
andclientSecret
public/index.html
:改掉变量client_id
然后,安装依赖。
$ npm install
启动服务。
$ node index.js
浏览器访问http://localhost:8080
,就可以看到这个示例了。
四、浏览器跳转 GitHub
示例的首页很简单,就是一个链接,让用户跳转到 GitHub。
跳转的 URL 如下。
https://github.com/login/oauth/authorize? client_id=7e015d8ce32370079895& redirect_uri=http://localhost:8080/oauth/redirect
这个 URL 指向 GitHub 的 OAuth 授权网址,带有两个参数:client_id
告诉 GitHub 谁在请求,redirect_uri
是稍后跳转回来的网址。
用户点击到了 GitHub,GitHub 会要求用户登录,确保是本人在操作。
五、授权码
登录后,GitHub 询问用户,该应用正在请求数据,你是否同意授权。
用户同意授权, GitHub 就会跳转到redirect_uri
指定的跳转网址,并且带上授权码,跳转回来的 URL 就是下面的样子。
http://localhost:8080/oauth/redirect? code=859310e7cecc9196f4af
后端收到这个请求以后,就拿到了授权码(code
参数)。
六、后端实现
这里的关键是针对/oauth/redirect
的请求,编写一个路由,完成 OAuth 认证。
const oauth = async ctx => { // ... }; app.use(route.get('/oauth/redirect', oauth));
上面代码中,oauth
函数就是路由的处理函数。下面的代码都写在这个函数里面。
路由函数的第一件事,是从 URL 取出授权码。
const requestToken = ctx.request.query.code;
七、令牌
后端使用这个授权码,向 GitHub 请求令牌。
const tokenResponse = await axios({ method: 'post', url: 'https://github.com/login/oauth/access_token?' + `client_id=${clientID}&` + `client_secret=${clientSecret}&` + `code=${requestToken}`, headers: { accept: 'application/json' } });
上面代码中,GitHub 的令牌接口https://github.com/login/oauth/access_token
需要提供三个参数。
client_id
:客户端的 IDclient_secret
:客户端的密钥code
:授权码
作为回应,GitHub 会返回一段 JSON 数据,里面包含了令牌accessToken
。
const accessToken = tokenResponse.data.access_token;
八、API 数据
有了令牌以后,就可以向 API 请求数据了。
const result = await axios({ method: 'get', url: `https://api.github.com/user`, headers: { accept: 'application/json', Authorization: `token ${accessToken}` } });
上面代码中,GitHub API 的地址是https://api.github.com/user
,请求的时候必须在 HTTP 头信息里面带上令牌Authorization: token 361507da
。
然后,就可以拿到用户数据,得到用户的身份。
const name = result.data.name; ctx.response.redirect(`/welcome.html?name=${name}`);
(完)
francis 说:
感觉你的blog也可以加一个OAuth呀。。。
web前端后端什么的看着头痛,框架太多了,不过思想倒是简洁
2019年4月22日 07:37 | # | 引用
路过看看 说:
Authorization: `token ${accessToken}`
Authorization: `Bearer ${accessToken}`
上面哪一种更标准?
2019年4月22日 12:44 | # | 引用
liuzhelei 说:
既然oauth可以使用access_token获取到用户信息,何必出现openid connect?
2019年4月22日 14:29 | # | 引用
Justin 说:
openid connect 就是把获取用户信息的方式标准化了
2019年4月22日 16:07 | # | 引用
wx0322 说:
简单明了,偶像~
2019年4月23日 14:40 | # | 引用
gyxyl 说:
const name = result.data.name;
应该是result.data.login,name取不到值,是null
2019年4月23日 18:03 | # | 引用
奥特曼 说:
"A 网站使用令牌,向 GitHub 请求用户数据"
刚测试了下CSDN的授权登录,这里拿到github的用户数据之后应该是会在CSDN注册一个类似临时账号(因为发现CSDN不支持GITHUB来注册账号)
2019年4月25日 17:46 | # | 引用
linzhu 说:
用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?
每次登录A网站时都会向GitHub发送token获取用户信息吗?
保存在前端网站的cookie是什么呢?
2019年4月26日 12:23 | # | 引用
qqq 说:
上周一花了5分钟做好了git登录
2019年4月26日 16:52 | # | 引用
疯子牛 说:
阮老师,能否更深入一步再开一个系列就是 “OAuth2.0" 作为服务提供方的一些实现和流程。
2019年5月 4日 22:26 | # | 引用
一个大白 说:
我有一件事不明白,就是github申请的应用homepage地址和回跳地址,为什么使用localhost都行?
当用户同意授权, GitHub 跳转到redirect_uri指定的跳转网址,此时 github能知道localhost是谁吗?
我只知道一个ip或者域名可以,但不明白为何github知道localhost是谁?
2019年5月 9日 09:53 | # | 引用
gansteed 说:
好像一般都是 Bearer
2019年5月10日 18:34 | # | 引用
keeley 说:
那个地址是客户端浏览器用的,浏览器直接跳转的,所以你自己本机起了就能跳转过去访问
2019年5月14日 11:08 | # | 引用
KIDD 说:
能不能写篇文章介绍一下OpenID Connect技术。
2019年5月27日 16:38 | # | 引用
成 说:
nice! 更多的了解OAuth的使用,对以后项目使用有很大帮助。
2019年5月29日 09:51 | # | 引用
test 说:
test
2019年5月31日 13:54 | # | 引用
阿凯 说:
建议写流程的时候关于“A网站”注明是A网站的前端还是后端,看晕了
2019年6月 5日 16:02 | # | 引用
Info 说:
请教一下,文中开头部分提到流程问题。如下:
用户同意,GitHub 就会重定向回 A 网站,同时发回一个授权码。
A 网站使用授权码,向 GitHub 请求令牌。
GitHub 返回令牌.
A 网站使用令牌,向 GitHub 请求用户数据。
为什么Github不直接发令牌给A网站,而是先发一个验证码呢
2019年7月 1日 08:40 | # | 引用
山色玄远 说:
如果我的网站有两种登录方式:A、账号密码登录;B、第三方git登录。
那我分别使用了2中方式登录了账号,而实际上我们确实同一个人,
怎么让这两种方式关联起来呢,使得两种方式登录进去看到的东西是一致的
2019年7月12日 11:07 | # | 引用
Xanthuim 说:
大佬能说下为什么要带上前缀Bearer或者token呢?发现不带也可以啊?
2019年7月22日 13:18 | # | 引用
火柴头 说:
将index.js里的const name = result.data.name;改为const name = result.data.login;后,可以正常运行,最后的地址栏:http://localhost:8080/welcome.html?name=xxxx,页面显示:Welcome, xxxx
2019年7月23日 14:42 | # | 引用
whatable 说:
令牌不能暴露于A的前端,但初始请求又一定是前端发起的(响应自然只能回到前端),这个初始请求就是用户先要在界面上输入B的账号口令,所以B先把一个临时的验证码(而不是最终的令牌)给回到A前端,然后A前端把这个验证码给自己的后端,由A后端带着这个验证码向B请求令牌,令牌给回到A后端,并且只保存在A的后端。
2019年8月21日 20:35 | # | 引用
rzy 说:
javax.net.ssl.SSLException: Received fatal alert: protocol_version
RestTemplate https请求的问题
2019年8月22日 20:36 | # | 引用
yua 说:
@linzhu:
登陆后后端生成session来保存相关数据,并将session_id保存在浏览器的cookie中,下次访问时,服务端通过cookie中的session_id来找到session,并获取其中的用户数据
2019年9月24日 19:51 | # | 引用
ken 说:
同样想问这个问题,用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?在这个例子中,是由nodejs这个框架自动实现的吗?
如果是生产级别的,是不是不需要每次请求都会重新申请auth code,第一次成功之后,后续只需要带着access code就可以了?
2019年9月25日 15:33 | # | 引用
hsing 说:
github不用知道localhost是谁,就像他不用知道baidu.com是谁一样,只需要重定向这个地址即可(即使这个地址参数是错的,github也不关心),到浏览器时,浏览器会知道localhost是谁,或者baidu.com是谁。以java为例,response的重定向方法参数,也不会关心你的地址是否可达,仅仅是浏览器访问这个地址的时候才会知道这个地址是否可达。
另:以我做过的企业微信的OAuth认证经验来说,企业微信是要先认证回调域名的(安全起见,一个企业一般一个回调域名),认证成功后才会成功跳转。所以这里github是不关心你回调到哪里了。
2019年10月23日 17:11 | # | 引用
etc 说:
~/work/node-oauth-demo/index.js:16
const oauth = async ctx => {
^^^
SyntaxError: Unexpected identifier
at Object.exports.runInThisContext (vm.js:76:16)
at Module._compile (module.js:513:28)
at Object.Module._extensions..js (module.js:550:10)
at Module.load (module.js:458:32)
at tryModuleLoad (module.js:417:12)
at Function.Module._load (module.js:409:3)
at Module.runMain (module.js:575:10)
at run (bootstrap_node.js:352:7)
at startup (bootstrap_node.js:144:9)
at bootstrap_node.js:467:3
发生这样的错误,怎么解?
$ node --version
v6.3.0
2019年10月23日 20:37 | # | 引用
Jyh 说:
@etc:
更新一下node吧,6.3.0不支持async
2019年10月25日 17:08 | # | 引用
xiaoyu 说:
写的很通俗易懂,非常感谢
2019年11月14日 10:52 | # | 引用
chenfw 说:
OAUTH2.0的重点是采用HTTPS协议来保证交互时不会被第三方截取解析出原信息,如何安全有效取得令牌,并有效安全使用令牌来调用/读取相关资源接口为目的。那问题就是获取令牌的安全性,如何不被第三方获取到,以及如何使用才是安全的。如第一种授权码方式,其实是用户》浏览器》第三方网站》资源服务器 四者关系,当访问第三方网站,采用需要使用资源服务器的资源时,第三方网站会给一个回调地址,如果用户同意了,则资源服务器就会返回一个302状态的报文返回,此时的重定向地址是第三方网站给的,同时带上一个CODE即授权码,截于此没有什么问题,由于是302报文就会重定向浏览器访问,此时访问的就是第三方网站给出的地址(地址已经附加上了CODE相关参数),此时发出时就有可能发生“中间者截取”,如果截取了,中间者就可以拿着这个CODE去获得TOKEN,但是第三方网站也会拿着CODE去获取TOKEN,而此时资源服务一旦发现用同个CODE获取了两次TOKEN,这个TOKEN就失效了。。保证了用户数据的安全,授权码方式是前端获取CODE+后端获取TOKEN,以及后端进行资源服务器访问的方式。 直接返回TOKEN是隐藏式授权,重点在采用锚点设置TOKEN的值,同样由资源服务器,返回302报文,但是由于采用锚点绑定TOKEN值,所以在重定向时,不会把TOKEN发给后端(OAUTH2支持第三方应用采用HTTP明文协议,而HTTPS是HTTP+TLS即加密过的).
2019年12月 6日 15:46 | # | 引用
keeleys 说:
@ken @
同样想问这个问题,用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?在这个例子中,是由nodejs这个框架自动实现的吗?
如果是生产级别的,是不是不需要每次请求都会重新申请auth code,第一次成功之后,后续只需要带着access code就可以了?
1. 当你第一次登陆授权之后,第三方会把通过你的githubtoken获取的用户唯一标示和自己的用户系统关联,然后生成自己系统的用户对应的登陆token。
2. 第三方会在浏览器里面保存自己的登陆系统对应的token。
3. 下次进来第三方网站,第三方网站是取浏览器保存的token,如果有效就直接是登陆状态了,这里的默认登陆和github再次授权没关系了。除非第三方保存在前端的token再次失效了 才会要求用户到登陆页面进行登陆。
2019年12月13日 11:34 | # | 引用
大轩 说:
因为 GitHub 做的是对 redirect_uri 地址做重定向请求而不是转发,重定向请求的特点是浏览器重新请求这个地址,而不是 GitHub 服务器直接请求这个地址。 建议你了解下这两种请求的区别。
2019年12月19日 11:24 | # | 引用
been 说:
没有返回refresh_token ,是因为 github 的原因吗
2020年1月11日 23:15 | # | 引用
leezeehowe 说:
@Info:
首先,验证码是怎么来的呢,https://github.com/login/oauth/authorize?client_id=[client_id]&redirect_uri=[redirect_uri]这个链接发起的请求来的,client_id相当于是暴露在前端,通过浏览器的开发者工具就可以看到的,所以[任何人]都可以拿着这个client_id去向github发起请求,然后[任何人]把redirect_uri换成自己的服务器的uri,那照你这样做,[任何人]都可以冒充客户端去拿到accessToken。
所以,之所以要多加验证码code这一步,就是要验证是否是client_id这个id所标识的客户端所发起的认证授权请求,通过第二次的 code + client_secret 就可以确定是client_id这个id所标识的客户端发起的请求,因为就算别人冒充了你的client_id和伪造了redirect_uri,拿到了code,但是他没有client_secret,他也没办法拿到access_token。
2020年2月14日 11:38 | # | 引用
leezeehowe 说:
为什么需要code验证码?
这就牵扯到client_secret的作用。
首先,client_id是暴露于前端浏览器的,当浏览器发起第一次请求[github.com/login/oauth/authorize?client_id="..."&redirect_uri="..."]时,github不知道是否是客户端本人发起的请求,如果省略了code这一步,直接把access_token发到redirect_uri上,那假设A知道了B的client_id,那A就可以冒充B拿到access_token(而现实情况是,client_id是公开的,任何人都互相知道)。
所以,需要加入第二次请求,通过code+client_secert让github确认是否是客户端本人所发起的登录授权请求
。
总结:
1. client_secret的作用:确认客户端的身份。用于在第二次请求中,标识是否是客户端本人所发起的登录授权请求,因为client_id是公开的,而client_secret是客户端本人才有的。
2. code的作用:确认资源拥有者允许客户端获取资源。
3. 所以完整流程
第一次请求github.com/login/oauth/authorize的语义是:登录授权服务器询问资源拥有者是否允许客户端获取资源。
当用户点击是,登录授权服务器给客户端code。
客户端携带上code+client_secret发起第二次请求,登录授权服务器看到了code知道资源拥有者已允许客户端获取资源、看到了client_secret确认是客户端本人,于是乎返回access_token给客户端。
2020年2月14日 12:04 | # | 引用
楚子同、 说:
Koa 框架??
2020年2月26日 16:17 | # | 引用
楚子同、 说:
Koa 框架??
2020年2月26日 23:36 | # | 引用
张洋 说:
这个域名是 github 用于告诉浏览器执行重定向的,也就是浏览器会访问 http://localhost:8080/oauth/redirect?code=859310e7cecc9196f4af。你自己的服务器在这个 url 的路径下写一个方法,把 code 提取出来就可以了。
2020年3月21日 09:09 | # | 引用
一枚前端工程师 说:
读完阮一峰老师的文章,并且跟着操作一遍,犹如醍醐灌顶,这种感觉太棒了
2020年3月30日 15:58 | # | 引用
Mr Yang 说:
/appl/node-oauth-demo/index.js:16
const oauth = async ctx => {
^^^
SyntaxError: Unexpected identifier
at Module._compile (module.js:439:25)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:902:3
您好,运行之后报这个错,怎么回事呢?
2020年3月31日 16:08 | # | 引用
sunshine 说:
请问获得的access_token的有效性?是不是后续的请求通过这个access_token都可以以登录态的权限来获取,每一次请求都不用重新获取code来获得新的access_token再请求?
2020年4月10日 16:49 | # | 引用
阿喵 说:
直接发令牌给A网站,在前端就能拿到这个令牌,这样用户的数据不是泄露了。比如你在A网站用Github登陆,登陆成功后,你的Github账户名是userABC,然后被别人监听到了你这波操作的令牌,别人就可以用这个令牌去拿到你的用户名userABC。
2020年4月18日 12:16 | # | 引用
He.Chun 说:
實際跑一次
1. 前端: 用 Chrome 看每個 request & response
2. 後端: 用 console 看每個 request & response
清楚很多!! 感謝
PS. Redirect 的方法如下:
1. use tag in html:
2. use location object in js: window.location.href="http://xxx.com";
3. use header in response: 3xx Location
2020年4月23日 23:58 | # | 引用
天风 说:
很有收获,感谢阮老师。github老报错,我试了下语雀的,成功了。
2020年6月 3日 15:58 | # | 引用
小白 说:
最后一步,
const name = result.data.name;
ctx.response.redirect(`/welcome.html?name=${name}`);
返回的这个页面,url里包含了用户信息,
假设这个页面包含用户隐私信息,
那么这个url被转发,隐私信息就泄露了?
2020年6月 4日 13:39 | # | 引用
小幸 说:
我想问下,退出操作要怎么做呢???
2020年6月10日 13:55 | # | 引用
wangwei 说:
有个问题想请教您,前端请求的授权码传给后端,后端去请求token。感觉会存在一个问题,前后端如果部署在不同的ip,那ip1请求的授权码传给ip2,ip2可以去请求token吗?
2020年7月 6日 12:00 | # | 引用
高永波 说:
您好:
根据系列文章中的第二篇内容,这个示例应该是采用第一种授权码方式;
授权码方式中由这么几个步骤,
1:A请求授权码、2:A接收B回调获取授权码、3:A请求令牌、4:A接收B回调获取令牌;
当时这个示例中,为啥没有第4步,直接在第3步B直接返回了令牌给A;
是我对Oath2规范的理解有误?
是我对这个的示例有误?
或者只是在实践中对规范的简化?
ps:可能问题描述语气生硬,主要是为了避免描述歧义,忘见谅,这里确实有点疑惑
2020年8月26日 11:32 | # | 引用
大名 说:
A接入B的第三方登录,为什么需要A请求B发送授权码,A得到请求码后使用请求码向B获取令牌
不能:B直接向A发送令牌,A的后端收到令牌后,自己跳转到相应界面
2020年9月10日 10:38 | # | 引用
展翼骐骥 说:
其实我想知道github那一端的原理和代码示例。
2020年10月26日 12:10 | # | 引用
csharpknife 说:
看了好几个关于OAuth 2.0的介绍,还是您这个最清晰,谢过了!
2020年11月 7日 06:17 | # | 引用
jianping 说:
终于整明白了,前端按钮上只需配置一个去获取code的链接,所有操作都在服务端完成
2020年11月13日 21:44 | # | 引用
麦康杰 说:
用demo的时候call github拿token的时候本地报这个错
Error: unable to get local issuer certificate
at TLSSocket.onConnectSecure (_tls_wrap.js:1049:34)
at TLSSocket.emit (events.js:182:13)
at TLSSocket._finishInit (_tls_wrap.js:631:8)
2020年11月25日 00:00 | # | 引用
gogo 说:
有个问题想不明白,如果确保跳转的页面是真实第三方,会不会出现钓鱼网站获取你的用户名密码
2021年1月12日 14:24 | # | 引用
mouday 说:
Python实现版:https://github.com/mouday/github-oauth-demo
2021年2月18日 17:03 | # | 引用
hanszhao 说:
1.用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?
用户第一次在A网站通过GitHub成功登陆后,那么A网站中就会存储有用户信息,相当于用户在A网站上拿着从GitHub中获取的数据做了一次注册,只不过这个注册过程是A网站来帮助用户完成的(正因为这样我们才体验到了使用第三方登陆的便捷)。当用户后面再登录时,会再次从GitHub获取用户数据(相当于普通登陆中的填写用户名密码的过程),这次就会和已有的用户数据做对比,如果用户存在,则直接登陆成功。
2.每次登录A网站时都会向GitHub发送token获取用户信息吗?
肯定会,要不然A网站拿什么数据来判断该用户呢,就相当于普通登陆方式中每次登陆你总得输用户名和密码吧,要不然怎么判断你能否登录呢?
3.保存在前端网站的cookie是什么呢?
应该是你和A网站的sessionid。登录成功后,A网站的session中会保持这个token
2021年2月26日 11:22 | # | 引用
小透明 说:
为什么我尝试用code去获取token的时候会返回如下错误,我该如何解决次问题?
Failed to connect to github.com port 443: Timed out
2021年5月12日 00:04 | # | 引用
YBFJ 说:
谢谢阮大神,向您的开源精神致敬
2021年5月25日 15:50 | # | 引用
迹忆客 说:
很明显是请求超时了,现在想访问github是要靠运气的。
2021年8月10日 14:00 | # | 引用
xuwj 说:
一直有关注微信公众号,之前也看过一遍这个,今天又来回顾以下,感谢!
2021年10月21日 11:02 | # | 引用
kkkk 说:
redirect的地址是后端接口吧,后端拿到code获取完token,用户信息后怎么给到前端的啊,或者说前端怎么知道授权成功还是失败了
2021年12月 9日 18:06 | # | 引用
wang 说:
@Info:
应该通过授权码去请求令牌 还有一个参数client_secret 这个一般是在后端保存,为了安全。
你说的直接返回令牌 其实就是第二种隐藏式
2021年12月15日 17:06 | # | 引用
他说他是个木偶 说:
@一个大白:
你要先理解上述方式是才用 OAth2.0 的授权方式为 授权码. 即在浏览器环境下 前端网页 A 跳转到 B网页,这个场景下 B 可以拿到 origin,referer 等相关字段(浏览器自带,当然也可以服务端请求伪造),用于 B的服务端来识别生成对应回调地址(redirect_uri) 完成本次 code 的下发。
2022年1月11日 11:05 | # | 引用
nightmoonwalker 说:
@leezeehowe:
楼主讲的很好了还有一点在说明一下就好了,我理解的client_secret是客户端后端自己定义的,所以在浏览器中是获取不了的,第二次请求是客户端后端发送的所以保证了安全性
2022年2月18日 15:46 | # | 引用
lk 说:
第三步的关键词:重定向。之前看了很多文章都不太懂,直到发现了阮老师这篇文章。偶像牛逼。
2022年3月12日 03:53 | # | 引用
飞飞飞 说:
1.A 网站让用户跳转到 GitHub。
2.GitHub 要求用户登录,然后询问"A 网站要求获得 xx 权限,你是否同意?"
3.用户同意,GitHub 就会重定向回 A 网站,同时发回一个授权码。
4.A 网站使用授权码,向 GitHub 请求令牌。
5.GitHub 返回令牌.
6.A 网站使用令牌,向 GitHub 请求用户数据。
这里有点晕,我的理解是现在我想用github的账号密码来访问A网站,但是到最后成了A网站拿到github的令牌去访问github了,那我直接用GitHub的账号密码访问不就行了。。。。还有我现在要怎样访问A网站??。。哪位老兄能指点我一下,我不知道哪里没想明白啊。。
2022年3月24日 23:20 | # | 引用
peacaci 说:
@飞飞飞:
通过 OAuth 拿到 token 是为了获取你 github 的账号信息,比如账号、昵称等,如果是新用户,A 网站可以根据这些信息为你创建一个账号,账号信息与你的 github 账号一致,至于密码,这里有很多种处理方式,比如可以给你随机生成一个,然后你自己去修改。
2022年4月 1日 16:22 | # | 引用
Sangriot 说:
1. OAuth 会给 A 网站发两个 token、refresh_token 一般过期时间7-30天,使用 refresh_token 可以获取新的 access_token 并为自己续期,A 网站会在服务端维护 refresh_token 只要你在期限内再次登录,会自动帮你用 refresh_token 找 github 刷新 access_token。如果超过期限,则会要求你重新登录。
2. 是的,因为要先向 github 获取 github 的用户信息,才能查到对应 A 网站的是哪个用户
3. 保存在前端 cookie 的是 access_token
2022年5月13日 10:17 | # | 引用
Heawill 说:
java springboot session 实现简单完整登录流程。
https://pan.baidu.com/s/1mVGcE5tObaXf2jBuXEHW8A?pwd=ga1u
2022年9月 3日 11:45 | # | 引用
weey 说:
你看 二、应用登记 章节,已经说明了:client_secret 是在用户登记应用的时候,资源提供方返回给用户的。这个client_secret 在资源提供方中是和应用的id绑定了。
2022年11月 8日 10:37 | # | 引用
vvu 说:
好文,读来所获颇多!
2022年12月12日 22:55 | # | 引用
伟 说:
为什么我修改成8081端口,node-oauth-demo无法启动
2023年2月 1日 16:41 | # | 引用
Fatbean 说:
先回答第3个问题,A网站前端的cookie保存的,可以是sessionid,也可以是jwt,以此作为用户是否已经在A网站登录的标记。但无论哪个都只能是A网站后台自己生成的票据,不应该把B网站返回的access_token返回到A网站的前端。
第1个问题,我想你说的场景是重新打开浏览器,输入A网站网址的情况。如果A网站的sessionid或者jwt没过期,A网站的后台就会认为已经登录,反之则需要重新登录。
第2个问题,接着第1个问题时说的,如果需要重新登录,才需要再次访问B网站,拿到用户身份。
2023年4月 3日 12:54 | # | 引用
kj 说:
照着做了一遍很有用
2024年4月24日 22:40 | # | 引用
大牛 说:
你好,想问下,能不能实现github让我们点击授权的那个页面,点击授权全部用代码实现?也就是不跳出这个页面,可以直接授权的方法?
2024年7月 6日 08:12 | # | 引用
Python斗罗 说:
规范问题,不带肯定没事。
2024年10月13日 01:01 | # | 引用