GitHub OAuth 第三方登录示例教程

作者: 阮一峰

日期: 2019年4月21日

这组 OAuth 系列教程,第一篇介绍了基本概念,第二篇介绍了获取令牌的四种方式,今天演示一个实例,如何通过 OAuth 获取 API 数据。

很多网站登录时,允许使用第三方网站的身份,这称为"第三方登录"。

下面就以 GitHub 为例,写一个最简单的应用,演示第三方登录。

一、第三方登录的原理

所谓第三方登录,实质就是 OAuth 授权。用户想要登录 A 网站,A 网站让用户提供第三方网站的数据,证明自己的身份。获取第三方网站的身份数据,就需要 OAuth 授权。

举例来说,A 网站允许 GitHub 登录,背后就是下面的流程。

  1. A 网站让用户跳转到 GitHub。
  2. GitHub 要求用户登录,然后询问"A 网站要求获得 xx 权限,你是否同意?"
  3. 用户同意,GitHub 就会重定向回 A 网站,同时发回一个授权码。
  4. A 网站使用授权码,向 GitHub 请求令牌。
  5. GitHub 返回令牌.
  6. 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

两个配置项要改一下,写入上一步的身份识别码。

然后,安装依赖。


$ 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参数)。

六、后端实现

示例的后端采用 Koa 框架编写,具体语法请看教程

这里的关键是针对/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:客户端的 ID
  • client_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}`);

(完)

留言(73条)

感觉你的blog也可以加一个OAuth呀。。。
web前端后端什么的看着头痛,框架太多了,不过思想倒是简洁

Authorization: `token ${accessToken}`
Authorization: `Bearer ${accessToken}`
上面哪一种更标准?

既然oauth可以使用access_token获取到用户信息,何必出现openid connect?

引用liuzhelei的发言:

既然oauth可以使用access_token获取到用户信息,何必出现openid connect?

openid connect 就是把获取用户信息的方式标准化了

简单明了,偶像~

const name = result.data.name;
应该是result.data.login,name取不到值,是null

"A 网站使用令牌,向 GitHub 请求用户数据"

刚测试了下CSDN的授权登录,这里拿到github的用户数据之后应该是会在CSDN注册一个类似临时账号(因为发现CSDN不支持GITHUB来注册账号)

用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?
每次登录A网站时都会向GitHub发送token获取用户信息吗?
保存在前端网站的cookie是什么呢?

上周一花了5分钟做好了git登录

阮老师,能否更深入一步再开一个系列就是 “OAuth2.0" 作为服务提供方的一些实现和流程。

我有一件事不明白,就是github申请的应用homepage地址和回跳地址,为什么使用localhost都行?

当用户同意授权, GitHub 跳转到redirect_uri指定的跳转网址,此时 github能知道localhost是谁吗?

我只知道一个ip或者域名可以,但不明白为何github知道localhost是谁?

引用路过看看的发言:

Authorization: `token ${accessToken}`
Authorization: `Bearer ${accessToken}`
上面哪一种更标准?

好像一般都是 Bearer

引用一个大白的发言:

我有一件事不明白,就是github申请的应用homepage地址和回跳地址,为什么使用localhost都行?

当用户同意授权, GitHub 跳转到redirect_uri指定的跳转网址,此时 github能知道localhost是谁吗?

我只知道一个ip或者域名可以,但不明白为何github知道localhost是谁?

那个地址是客户端浏览器用的,浏览器直接跳转的,所以你自己本机起了就能跳转过去访问

能不能写篇文章介绍一下OpenID Connect技术。

nice! 更多的了解OAuth的使用,对以后项目使用有很大帮助。

test

建议写流程的时候关于“A网站”注明是A网站的前端还是后端,看晕了

请教一下,文中开头部分提到流程问题。如下:

用户同意,GitHub 就会重定向回 A 网站,同时发回一个授权码。
A 网站使用授权码,向 GitHub 请求令牌。
GitHub 返回令牌.
A 网站使用令牌,向 GitHub 请求用户数据。

为什么Github不直接发令牌给A网站,而是先发一个验证码呢

如果我的网站有两种登录方式:A、账号密码登录;B、第三方git登录。

那我分别使用了2中方式登录了账号,而实际上我们确实同一个人,

怎么让这两种方式关联起来呢,使得两种方式登录进去看到的东西是一致的

大佬能说下为什么要带上前缀Bearer或者token呢?发现不带也可以啊?

将index.js里的const name = result.data.name;改为const name = result.data.login;后,可以正常运行,最后的地址栏:http://localhost:8080/welcome.html?name=xxxx,页面显示:Welcome, xxxx

引用Info的发言:

请教一下,文中开头部分提到流程问题。如下:

用户同意,GitHub 就会重定向回 A 网站,同时发回一个授权码。
A 网站使用授权码,向 GitHub 请求令牌。
GitHub 返回令牌.
A 网站使用令牌,向 GitHub 请求用户数据。

为什么Github不直接发令牌给A网站,而是先发一个验证码呢

令牌不能暴露于A的前端,但初始请求又一定是前端发起的(响应自然只能回到前端),这个初始请求就是用户先要在界面上输入B的账号口令,所以B先把一个临时的验证码(而不是最终的令牌)给回到A前端,然后A前端把这个验证码给自己的后端,由A后端带着这个验证码向B请求令牌,令牌给回到A后端,并且只保存在A的后端。

javax.net.ssl.SSLException: Received fatal alert: protocol_version

RestTemplate https请求的问题

@linzhu:

登陆后后端生成session来保存相关数据,并将session_id保存在浏览器的cookie中,下次访问时,服务端通过cookie中的session_id来找到session,并获取其中的用户数据

引用linzhu的发言:

用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?
每次登录A网站时都会向GitHub发送token获取用户信息吗?
保存在前端网站的cookie是什么呢?

同样想问这个问题,用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?在这个例子中,是由nodejs这个框架自动实现的吗?
如果是生产级别的,是不是不需要每次请求都会重新申请auth code,第一次成功之后,后续只需要带着access code就可以了?

引用一个大白的发言:

我有一件事不明白,就是github申请的应用homepage地址和回跳地址,为什么使用localhost都行?

当用户同意授权, GitHub 跳转到redirect_uri指定的跳转网址,此时 github能知道localhost是谁吗?

我只知道一个ip或者域名可以,但不明白为何github知道localhost是谁?

github不用知道localhost是谁,就像他不用知道baidu.com是谁一样,只需要重定向这个地址即可(即使这个地址参数是错的,github也不关心),到浏览器时,浏览器会知道localhost是谁,或者baidu.com是谁。以java为例,response的重定向方法参数,也不会关心你的地址是否可达,仅仅是浏览器访问这个地址的时候才会知道这个地址是否可达。

另:以我做过的企业微信的OAuth认证经验来说,企业微信是要先认证回调域名的(安全起见,一个企业一般一个回调域名),认证成功后才会成功跳转。所以这里github是不关心你回调到哪里了。

~/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

@etc:

更新一下node吧,6.3.0不支持async

写的很通俗易懂,非常感谢

引用ken的发言:

同样想问这个问题,用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?在这个例子中,是由nodejs这个框架自动实现的吗?
如果是生产级别的,是不是不需要每次请求都会重新申请auth code,第一次成功之后,后续只需要带着access code就可以了?


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即加密过的).

@ken @


引用ken的发言:

同样想问这个问题,用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?在这个例子中,是由nodejs这个框架自动实现的吗?
如果是生产级别的,是不是不需要每次请求都会重新申请auth code,第一次成功之后,后续只需要带着access code就可以了?

1. 当你第一次登陆授权之后,第三方会把通过你的githubtoken获取的用户唯一标示和自己的用户系统关联,然后生成自己系统的用户对应的登陆token。
2. 第三方会在浏览器里面保存自己的登陆系统对应的token。
3. 下次进来第三方网站,第三方网站是取浏览器保存的token,如果有效就直接是登陆状态了,这里的默认登陆和github再次授权没关系了。除非第三方保存在前端的token再次失效了 才会要求用户到登陆页面进行登陆。

引用一个大白的发言:

我有一件事不明白,就是github申请的应用homepage地址和回跳地址,为什么使用localhost都行?

当用户同意授权, GitHub 跳转到redirect_uri指定的跳转网址,此时 github能知道localhost是谁吗?

我只知道一个ip或者域名可以,但不明白为何github知道localhost是谁?

因为 GitHub 做的是对 redirect_uri 地址做重定向请求而不是转发,重定向请求的特点是浏览器重新请求这个地址,而不是 GitHub 服务器直接请求这个地址。 建议你了解下这两种请求的区别。

没有返回refresh_token ,是因为 github 的原因吗

@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。

为什么需要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给客户端。

Koa 框架??

Koa 框架??

引用一个大白的发言:

我有一件事不明白,就是github申请的应用homepage地址和回跳地址,为什么使用localhost都行?

当用户同意授权, GitHub 跳转到redirect_uri指定的跳转网址,此时 github能知道localhost是谁吗?

我只知道一个ip或者域名可以,但不明白为何github知道localhost是谁?


这个域名是 github 用于告诉浏览器执行重定向的,也就是浏览器会访问 http://localhost:8080/oauth/redirect?code=859310e7cecc9196f4af。你自己的服务器在这个 url 的路径下写一个方法,把 code 提取出来就可以了。

读完阮一峰老师的文章,并且跟着操作一遍,犹如醍醐灌顶,这种感觉太棒了

/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

您好,运行之后报这个错,怎么回事呢?

请问获得的access_token的有效性?是不是后续的请求通过这个access_token都可以以登录态的权限来获取,每一次请求都不用重新获取code来获得新的access_token再请求?

引用Info的发言:

请教一下,文中开头部分提到流程问题。如下:

用户同意,GitHub 就会重定向回 A 网站,同时发回一个授权码。
A 网站使用授权码,向 GitHub 请求令牌。
GitHub 返回令牌.
A 网站使用令牌,向 GitHub 请求用户数据。

为什么Github不直接发令牌给A网站,而是先发一个验证码呢

直接发令牌给A网站,在前端就能拿到这个令牌,这样用户的数据不是泄露了。比如你在A网站用Github登陆,登陆成功后,你的Github账户名是userABC,然后被别人监听到了你这波操作的令牌,别人就可以用这个令牌去拿到你的用户名userABC。

實際跑一次
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

很有收获,感谢阮老师。github老报错,我试了下语雀的,成功了。

最后一步,

const name = result.data.name;
ctx.response.redirect(`/welcome.html?name=${name}`);

返回的这个页面,url里包含了用户信息,
假设这个页面包含用户隐私信息,
那么这个url被转发,隐私信息就泄露了?

我想问下,退出操作要怎么做呢???

引用whatable的发言:

令牌不能暴露于A的前端,但初始请求又一定是前端发起的(响应自然只能回到前端),这个初始请求就是用户先要在界面上输入B的账号口令,所以B先把一个临时的验证码(而不是最终的令牌)给回到A前端,然后A前端把这个验证码给自己的后端,由A后端带着这个验证码向B请求令牌,令牌给回到A后端,并且只保存在A的后端。

有个问题想请教您,前端请求的授权码传给后端,后端去请求token。感觉会存在一个问题,前后端如果部署在不同的ip,那ip1请求的授权码传给ip2,ip2可以去请求token吗?

您好:
根据系列文章中的第二篇内容,这个示例应该是采用第一种授权码方式;
授权码方式中由这么几个步骤,
1:A请求授权码、2:A接收B回调获取授权码、3:A请求令牌、4:A接收B回调获取令牌;
当时这个示例中,为啥没有第4步,直接在第3步B直接返回了令牌给A;
是我对Oath2规范的理解有误?
是我对这个的示例有误?
或者只是在实践中对规范的简化?

ps:可能问题描述语气生硬,主要是为了避免描述歧义,忘见谅,这里确实有点疑惑

A接入B的第三方登录,为什么需要A请求B发送授权码,A得到请求码后使用请求码向B获取令牌

不能:B直接向A发送令牌,A的后端收到令牌后,自己跳转到相应界面

其实我想知道github那一端的原理和代码示例。

看了好几个关于OAuth 2.0的介绍,还是您这个最清晰,谢过了!

终于整明白了,前端按钮上只需配置一个去获取code的链接,所有操作都在服务端完成

用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)

有个问题想不明白,如果确保跳转的页面是真实第三方,会不会出现钓鱼网站获取你的用户名密码

Python实现版:https://github.com/mouday/github-oauth-demo

引用linzhu的发言:

用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?
每次登录A网站时都会向GitHub发送token获取用户信息吗?
保存在前端网站的cookie是什么呢?

1.用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?

用户第一次在A网站通过GitHub成功登陆后,那么A网站中就会存储有用户信息,相当于用户在A网站上拿着从GitHub中获取的数据做了一次注册,只不过这个注册过程是A网站来帮助用户完成的(正因为这样我们才体验到了使用第三方登陆的便捷)。当用户后面再登录时,会再次从GitHub获取用户数据(相当于普通登陆中的填写用户名密码的过程),这次就会和已有的用户数据做对比,如果用户存在,则直接登陆成功。

2.每次登录A网站时都会向GitHub发送token获取用户信息吗?

肯定会,要不然A网站拿什么数据来判断该用户呢,就相当于普通登陆方式中每次登陆你总得输用户名和密码吧,要不然怎么判断你能否登录呢?

3.保存在前端网站的cookie是什么呢?

应该是你和A网站的sessionid。登录成功后,A网站的session中会保持这个token

为什么我尝试用code去获取token的时候会返回如下错误,我该如何解决次问题?

Failed to connect to github.com port 443: Timed out

谢谢阮大神,向您的开源精神致敬

引用小透明的发言:

为什么我尝试用code去获取token的时候会返回如下错误,我该如何解决次问题?

Failed to connect to github.com port 443: Timed out

很明显是请求超时了,现在想访问github是要靠运气的。

一直有关注微信公众号,之前也看过一遍这个,今天又来回顾以下,感谢!

redirect的地址是后端接口吧,后端拿到code获取完token,用户信息后怎么给到前端的啊,或者说前端怎么知道授权成功还是失败了

@Info:

应该通过授权码去请求令牌 还有一个参数client_secret 这个一般是在后端保存,为了安全。

你说的直接返回令牌 其实就是第二种隐藏式

@一个大白:


你要先理解上述方式是才用 OAth2.0 的授权方式为 授权码. 即在浏览器环境下 前端网页 A 跳转到 B网页,这个场景下 B 可以拿到 origin,referer 等相关字段(浏览器自带,当然也可以服务端请求伪造),用于 B的服务端来识别生成对应回调地址(redirect_uri) 完成本次 code 的下发。

@leezeehowe:

楼主讲的很好了还有一点在说明一下就好了,我理解的client_secret是客户端后端自己定义的,所以在浏览器中是获取不了的,第二次请求是客户端后端发送的所以保证了安全性

引用一个大白的发言:

我有一件事不明白,就是github申请的应用homepage地址和回跳地址,为什么使用localhost都行?

当用户同意授权, GitHub 跳转到redirect_uri指定的跳转网址,此时 github能知道localhost是谁吗?

我只知道一个ip或者域名可以,但不明白为何github知道localhost是谁?

第三步的关键词:重定向。之前看了很多文章都不太懂,直到发现了阮老师这篇文章。偶像牛逼。

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网站??。。哪位老兄能指点我一下,我不知道哪里没想明白啊。。

@飞飞飞:

通过 OAuth 拿到 token 是为了获取你 github 的账号信息,比如账号、昵称等,如果是新用户,A 网站可以根据这些信息为你创建一个账号,账号信息与你的 github 账号一致,至于密码,这里有很多种处理方式,比如可以给你随机生成一个,然后你自己去修改。

引用linzhu的发言:

用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?
每次登录A网站时都会向GitHub发送token获取用户信息吗?
保存在前端网站的cookie是什么呢?

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

java springboot session 实现简单完整登录流程。
https://pan.baidu.com/s/1mVGcE5tObaXf2jBuXEHW8A?pwd=ga1u

引用nightmoonwalker的发言:

@leezeehowe:

楼主讲的很好了还有一点在说明一下就好了,我理解的client_secret是客户端后端自己定义的,所以在浏览器中是获取不了的,第二次请求是客户端后端发送的所以保证了安全性

你看 二、应用登记 章节,已经说明了:client_secret 是在用户登记应用的时候,资源提供方返回给用户的。这个client_secret 在资源提供方中是和应用的id绑定了。

好文,读来所获颇多!

为什么我修改成8081端口,node-oauth-demo无法启动

引用linzhu的发言:

用户在A网站通过GitHub成功登录后,再次访问A网站时如何做到自动登录?
每次登录A网站时都会向GitHub发送token获取用户信息吗?
保存在前端网站的cookie是什么呢?

先回答第3个问题,A网站前端的cookie保存的,可以是sessionid,也可以是jwt,以此作为用户是否已经在A网站登录的标记。但无论哪个都只能是A网站后台自己生成的票据,不应该把B网站返回的access_token返回到A网站的前端。
第1个问题,我想你说的场景是重新打开浏览器,输入A网站网址的情况。如果A网站的sessionid或者jwt没过期,A网站的后台就会认为已经登录,反之则需要重新登录。
第2个问题,接着第1个问题时说的,如果需要重新登录,才需要再次访问B网站,拿到用户身份。

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接