1
00:00:03,620 --> 00:00:09,015
Tenho certeza que você tem uma ou mais contas de mídia social.

2
00:00:09,015 --> 00:00:13,920
Seja Facebook, Twitter, YouTube, Google, GitHub,

3
00:00:13,920 --> 00:00:19,760
ou muitos outros provedores de serviços, onde você registrou telefone e conta.

4
00:00:19,760 --> 00:00:22,545
Agora, esses provedores de serviços, por sua vez,

5
00:00:22,545 --> 00:00:27,480
estão dispostos a fornecer serviços de autenticação em seu nome.

6
00:00:27,480 --> 00:00:32,880
Assim, por exemplo, você vê a proliferação de uma série de sites

7
00:00:32,880 --> 00:00:37,440
e aplicativos móveis onde você tem permissão para fazer login

8
00:00:37,440 --> 00:00:40,260
usando suas contas de mídia social.

9
00:00:40,260 --> 00:00:42,805
Agora, como isso realmente funciona?

10
00:00:42,805 --> 00:00:47,270
Muitos desses provedores de conta de mídia social atuam

11
00:00:47,270 --> 00:00:53,945
como provedores de serviços de autenticação usando um protocolo chamado como OAuth.

12
00:00:53,945 --> 00:01:00,660
Analisaremos o OAuth e como ele permite que esses provedores de autenticação terceirizados

13
00:01:00,660 --> 00:01:04,995
forneçam autenticação em seu nome

14
00:01:04,995 --> 00:01:14,183
e permitem que você faça login em outros serviços usando suas contas de mídia social.

15
00:01:14,183 --> 00:01:18,510
Tenho certeza que você pode ter ouvido falar sobre OAuth 1 e OAuth 2,

16
00:01:18,510 --> 00:01:21,370
e pode ter ouvido pessoas dizendo

17
00:01:21,370 --> 00:01:24,669
que o Facebook fornece autenticação baseada em OAuth 2,

18
00:01:24,669 --> 00:01:28,450
ou Google fornece autenticação baseada em OAuth 2 e assim por diante.

19
00:01:28,450 --> 00:01:29,800
Tenho certeza que você deve estar se perguntando,

20
00:01:29,800 --> 00:01:35,240
o que exatamente esses OAuth1 e OAuth 2 devem ser?

21
00:01:35,240 --> 00:01:40,090
Agora, OAuth1 e OAuth 2 são estruturas de autorização

22
00:01:40,090 --> 00:01:42,920
baseadas em padrões abertos.

23
00:01:42,920 --> 00:01:46,110
E eles podem ser usados pela Internet para autenticar

24
00:01:46,110 --> 00:01:50,375
sua identidade em muitos sites ou aplicativos móveis.

25
00:01:50,375 --> 00:01:52,475
Agora, quando você usa esses serviços,

26
00:01:52,475 --> 00:01:56,470
você está dependendo de uma das contas de mídia social, como Facebook,

27
00:01:56,470 --> 00:01:58,525
Google, Twitter, Microsoft, Instagram,

28
00:01:58,525 --> 00:02:02,380
GitHub, DigitalOcean e muitos mais,

29
00:02:02,380 --> 00:02:06,915
que fornecem esses serviços de autenticação para outros fazerem uso.

30
00:02:06,915 --> 00:02:10,465
Esses provedores de serviços

31
00:02:10,465 --> 00:02:15,310
de autenticação prometem aos usuários desse serviço de autenticação que eles autenticarão a identidade

32
00:02:15,310 --> 00:02:18,535
do usuário com base em seu envio de

33
00:02:18,535 --> 00:02:24,100
suas credenciais para esses serviços de mídia social.

34
00:02:24,100 --> 00:02:28,630
Agora, há um serviço complementar OpenID.

35
00:02:28,630 --> 00:02:34,220
Mas, é claro, não relacionado ao OAuth, mas fornece tipo semelhante de serviço.

36
00:02:34,220 --> 00:02:38,005
Mas a maioria dos provedores de serviços de mídia social padrão,

37
00:02:38,005 --> 00:02:39,835
como você verá listado aqui,

38
00:02:39,835 --> 00:02:44,290
fornece serviços baseados no OAuth 2 atualmente.

39
00:02:44,290 --> 00:02:48,760
Agora, como mencionei, OAuth1 e OAuth 2 são protocolos de autenticação,

40
00:02:48,760 --> 00:02:53,010
e OAuth 1 foi o primeiro protocolo que surgiu.

41
00:02:53,010 --> 00:02:55,165
Isso foi evoluído a partir do Twitter,

42
00:02:55,165 --> 00:02:58,725
Blaine Cook sendo a pessoa por trás dele,

43
00:02:58,725 --> 00:03:04,330
e isso está documentado na Internet Engineering Task Force, RFC 5849.

44
00:03:04,330 --> 00:03:08,235
Então, se você quiser ler os detalhes sangrentos de como esses protocolos funcionam,

45
00:03:08,235 --> 00:03:11,350
esse é o lugar para encontrar isso. O

46
00:03:11,350 --> 00:03:18,430
protocolo OAuth 2 evoluiu de OAuth 1 para torná-lo mais simples

47
00:03:18,430 --> 00:03:23,420
e para fornecer uma maneira mais simples para o desenvolvimento do cliente.

48
00:03:23,420 --> 00:03:29,050
E isso é documentado no IETF RFC 6749 e, posteriormente,

49
00:03:29,050 --> 00:03:35,975
outro uso de token portador surgiu no IETF RFC 6750.

50
00:03:35,975 --> 00:03:38,155
Agora, do nosso ponto de vista,

51
00:03:38,155 --> 00:03:42,926
nós realmente não queremos entrar em detalhes de como esses protocolos realmente funcionam.

52
00:03:42,926 --> 00:03:45,640
Em vez disso, tudo o que estamos interessados em que é,

53
00:03:45,640 --> 00:03:51,505
como aproveitá-los para autenticação de usuário dentro de

54
00:03:51,505 --> 00:03:53,460
nosso aplicativo web, ou dentro de nosso aplicativo móvel,

55
00:03:53,460 --> 00:03:56,215
quando precisamos autenticar o usuário para

56
00:03:56,215 --> 00:03:59,965
o servidor Express que temos vindo a construir até agora?

57
00:03:59,965 --> 00:04:04,330
Agora, vamos nos concentrar principalmente no OAuth 2,

58
00:04:04,330 --> 00:04:05,710
porque no exercício,

59
00:04:05,710 --> 00:04:10,960
vamos olhar para o uso do Facebook como um provedor de serviços de autenticação OAuth 2

60
00:04:10,960 --> 00:04:13,870
, e aqui, precisamos entender

61
00:04:13,870 --> 00:04:19,810
alguns termos para ver como exatamente esse protocolo OAuth 2 funciona.

62
00:04:19,810 --> 00:04:25,065
Pelo menos, os detalhes de como o próprio protocolo funciona.

63
00:04:25,065 --> 00:04:26,995
Agora, no caso de OAuth 2,

64
00:04:26,995 --> 00:04:30,440
sempre falamos sobre a propriedade de um recurso.

65
00:04:30,440 --> 00:04:32,200
Agora, nesse caso,

66
00:04:32,200 --> 00:04:34,810
o recurso ao qual estou me referindo não

67
00:04:34,810 --> 00:04:37,870
é o recurso armazenado no servidor Express.

68
00:04:37,870 --> 00:04:39,655
Em vez disso, o recurso a que estamos nos referindo aqui,

69
00:04:39,655 --> 00:04:42,055
é a identidade do usuário.

70
00:04:42,055 --> 00:04:45,760
Agora, qualquer servidor, como o servidor Express que temos vindo a construir,

71
00:04:45,760 --> 00:04:48,310
quer ter acesso a este recurso,

72
00:04:48,310 --> 00:04:50,000
que é a sua identidade.

73
00:04:50,000 --> 00:04:51,760
Agora, onde está a sua identidade?

74
00:04:51,760 --> 00:04:54,160
Sua identidade é armazenada em um

75
00:04:54,160 --> 00:04:58,457
desses provedores de serviços de autenticação de mídia social, como o Facebook e assim por diante,

76
00:04:58,457 --> 00:05:03,140
porque você já criou uma conta nesses sites de mídia social.

77
00:05:03,140 --> 00:05:06,920
Assim, suas informações ou suas informações de identidade ou

78
00:05:06,920 --> 00:05:11,020
suas informações de perfil são armazenadas no Facebook, por exemplo.

79
00:05:11,020 --> 00:05:15,550
Agora, seu servidor Express deseja obter acesso à sua identidade e

80
00:05:15,550 --> 00:05:20,650
verificar se é realmente você que está tentando acessar o servidor Express.

81
00:05:20,650 --> 00:05:22,000
Então, neste caso,

82
00:05:22,000 --> 00:05:24,690
o servidor Express que desenvolvemos,

83
00:05:24,690 --> 00:05:27,390
atua como o aplicativo cliente.

84
00:05:27,390 --> 00:05:29,170
Então, é aqui que o aplicativo cliente,

85
00:05:29,170 --> 00:05:33,265
que é o site ou o aplicativo móvel que

86
00:05:33,265 --> 00:05:38,905
deseja acessar o servidor de recursos para obter as informações sobre você.

87
00:05:38,905 --> 00:05:41,530
O que é um servidor de recursos que estamos falando?

88
00:05:41,530 --> 00:05:45,730
Este é o servidor de autenticação OAuth do Facebook,

89
00:05:45,730 --> 00:05:49,870
que também fornece suas informações de perfil mediante solicitação.

90
00:05:49,870 --> 00:05:54,490
Agora, é claro, você não vai continuar distribuindo suas informações de perfil aleatoriamente.

91
00:05:54,490 --> 00:06:00,370
Em vez disso, você deseja ser capaz de verificar se você está fornecendo acesso às

92
00:06:00,370 --> 00:06:08,250
informações do seu perfil para um provedor de serviços autenticado ou um servidor autenticado.

93
00:06:08,250 --> 00:06:12,610
Agora, é aqui que seu aplicativo cliente ou o servidor Express aqui,

94
00:06:12,610 --> 00:06:18,535
por exemplo, vai se registrar no Facebook com uma conta dizendo que eu estou operando um aplicativo,

95
00:06:18,535 --> 00:06:25,780
e eu quero me registrar como uma fonte potencial que pode se

96
00:06:25,780 --> 00:06:29,680
aproximar de você para autenticar usuários quando eles fornecem

97
00:06:29,680 --> 00:06:33,859
acesso a seu perfil que está armazenado em seu site.

98
00:06:33,859 --> 00:06:35,335
Assim, o servidor Express,

99
00:06:35,335 --> 00:06:37,645
neste caso, atuando como o aplicativo cliente,

100
00:06:37,645 --> 00:06:45,790
irá se registrar no Facebook e obter um ClientID e um segredo de cliente do Facebook.

101
00:06:45,790 --> 00:06:48,955
Agora, quando o servidor Express se registrar no Facebook,

102
00:06:48,955 --> 00:06:52,240
você precisa ter uma conta no Facebook,

103
00:06:52,240 --> 00:06:53,950
uma conta autenticada no Facebook,

104
00:06:53,950 --> 00:06:59,030
que você usará para configurar este aplicativo no Facebook.

105
00:06:59,030 --> 00:07:01,450
Então, uma vez que você se registrar,

106
00:07:01,450 --> 00:07:06,680
então você terá acesso a um ClientID e a um segredo de cliente.

107
00:07:06,680 --> 00:07:08,650
Agora, o servidor de recursos,

108
00:07:08,650 --> 00:07:12,310
como eu mencionei, é o servidor que está hospedando os dados protegidos.

109
00:07:12,310 --> 00:07:18,665
Dados protegidos que significam o perfil do usuário que deseja acessar o servidor Express.

110
00:07:18,665 --> 00:07:22,300
Então, o servidor Express deseja acessar esse servidor de recursos

111
00:07:22,300 --> 00:07:28,415
e obter os dados de perfil do usuário que deseja acessar o servidor Express.

112
00:07:28,415 --> 00:07:31,265
Então, você vê o relacionamento aqui.

113
00:07:31,265 --> 00:07:33,355
Então, quando eu falo sobre um aplicativo cliente,

114
00:07:33,355 --> 00:07:36,535
eu não me refiro a sua aplicação front-end,

115
00:07:36,535 --> 00:07:40,000
mas seu servidor Express que está tentando fornecer

116
00:07:40,000 --> 00:07:44,190
acesso a recursos que ele tem em seu site.

117
00:07:44,190 --> 00:07:45,635
Mas o servidor Express,

118
00:07:45,635 --> 00:07:48,940
a fim de permitir que você acesse,

119
00:07:48,940 --> 00:07:53,200
precisará acessar seu servidor de recursos do Facebook, que

120
00:07:53,200 --> 00:07:58,655
irá autenticá-lo e fornecer suas informações de perfil para o servidor Express.

121
00:07:58,655 --> 00:08:01,375
Então, o servidor de recursos que estou falando aqui,

122
00:08:01,375 --> 00:08:06,190
é o servidor de autenticação OAuth 2 do Facebook

123
00:08:06,190 --> 00:08:11,681
mais o servidor de recursos que lhe dá acesso às informações de perfil do usuário.

124
00:08:11,681 --> 00:08:16,180
E o servidor de autorização é o servidor que

125
00:08:16,180 --> 00:08:19,210
autorizará alguém a acessar

126
00:08:19,210 --> 00:08:22,825
o servidor de recursos para recuperar as informações do perfil.

127
00:08:22,825 --> 00:08:27,375
Agora, o usuário é aquele que tem as informações de perfil no servidor de recursos.

128
00:08:27,375 --> 00:08:30,610
O usuário deve autorizar o servidor Express a ir

129
00:08:30,610 --> 00:08:34,035
para este servidor de recursos para buscar as informações do perfil.

130
00:08:34,035 --> 00:08:37,000
Mas se o usuário precisa autorizar o servidor Express,

131
00:08:37,000 --> 00:08:40,045
o usuário precisa fazer login na conta do Facebook

132
00:08:40,045 --> 00:08:45,115
e, em seguida, obter informações do Facebook chamado como um token de acesso,

133
00:08:45,115 --> 00:08:48,995
que o usuário então passará para o servidor Express.

134
00:08:48,995 --> 00:08:54,750
Agora, quando o token de acesso é obtido do Facebook através do protocolo OAuth 2,

135
00:08:54,750 --> 00:08:58,090
o token de acesso será emitido em termos

136
00:08:58,090 --> 00:09:01,675
de permitir este aplicativo cliente ou o servidor Express,

137
00:09:01,675 --> 00:09:04,885
que já está registrado no Facebook dizendo que

138
00:09:04,885 --> 00:09:08,020
este servidor cliente eu autorizarei a

139
00:09:08,020 --> 00:09:15,265
acessar suas informações de perfil de seu provedor de serviços OAuth do Facebook.

140
00:09:15,265 --> 00:09:18,290
Então, novamente, isso é um pouco confuso.

141
00:09:18,290 --> 00:09:20,940
Veremos um diagrama onde esse fluxo de

142
00:09:20,940 --> 00:09:24,360
informações é explicado um pouco mais claramente para você.

143
00:09:24,360 --> 00:09:32,380
Um ponto que acabei de mencionar é sobre um token OAuth ou o token de acesso.

144
00:09:32,380 --> 00:09:34,090
O que é esse token de acesso?

145
00:09:34,090 --> 00:09:38,675
O token de acesso é algo que o servidor de autorização emite para você.

146
00:09:38,675 --> 00:09:40,620
Qual servidor de autorização?

147
00:09:40,620 --> 00:09:44,100
Este é o servidor de autorização OAuth 2 de terceiros,

148
00:09:44,100 --> 00:09:46,668
servidor do Facebook, neste exemplo.

149
00:09:46,668 --> 00:09:51,130
Então eles são aplicativos de servidor Express.

150
00:09:51,130 --> 00:09:54,485
Agora, você, como seu usuário front-end,

151
00:09:54,485 --> 00:09:58,070
quer acessar algo do aplicativo Express Server.

152
00:09:58,070 --> 00:10:02,150
O aplicativo de servidor Express irá dizer-lhe que você

153
00:10:02,150 --> 00:10:06,666
autenticar-se do Facebook e, em seguida, obter token de acesso do Facebook.

154
00:10:06,666 --> 00:10:09,770
Este token de acesso é emitido para

155
00:10:09,770 --> 00:10:16,330
o usuário front-end do Facebook quando o usuário faz login em sua conta do Facebook.

156
00:10:16,330 --> 00:10:21,155
Agora, este token de acesso é emitido em nome do aplicativo cliente, o

157
00:10:21,155 --> 00:10:25,060
servidor Express, que já se registrou no Facebook.

158
00:10:25,060 --> 00:10:30,485
Assim, para que o usuário acesse o Facebook para obter seu token de acesso,

159
00:10:30,485 --> 00:10:36,580
o usuário requer o ID do cliente do aplicativo cliente ou do aplicativo Express.

160
00:10:36,580 --> 00:10:39,755
Portanto, esse ID de cliente é incorporado

161
00:10:39,755 --> 00:10:44,460
no aplicativo front-end que este servidor Express servirá para você.

162
00:10:44,460 --> 00:10:47,915
Então, o servidor Express está servindo um site que você está acessando,

163
00:10:47,915 --> 00:10:50,820
então esse site irá conter código onde

164
00:10:50,820 --> 00:10:56,597
o ID do cliente desse servidor Express já está incorporado lá.

165
00:10:56,597 --> 00:11:00,110
Mais uma informação que mencionei é um segredo de cliente.

166
00:11:00,110 --> 00:11:03,855
Agora, no fluxo de autenticação que vou falar,

167
00:11:03,855 --> 00:11:07,640
o segredo do cliente nunca será revelado a ninguém.

168
00:11:07,640 --> 00:11:11,700
O segredo do cliente será apenas no lado do servidor Express.

169
00:11:11,700 --> 00:11:15,335
Quando o servidor Express tenta autenticar e

170
00:11:15,335 --> 00:11:20,600
obter acesso ao perfil do usuário do Facebook,

171
00:11:20,600 --> 00:11:23,795
o aplicativo cliente, o servidor Express

172
00:11:23,795 --> 00:11:27,490
enviará o ID do cliente e o segredo do cliente,

173
00:11:27,490 --> 00:11:32,555
juntamente com o token de acesso que o usuário fornece para o Facebook.

174
00:11:32,555 --> 00:11:34,988
E o Facebook, por sua vez,

175
00:11:34,988 --> 00:11:38,945
autoriza seu aplicativo cliente a acessar

176
00:11:38,945 --> 00:11:43,935
o servidor de recursos para obter os dados do perfil do usuário.

177
00:11:43,935 --> 00:11:50,390
E uma vez que os dados do perfil do usuário são obtidos do servidor de recursos do Facebook,

178
00:11:50,390 --> 00:11:54,530
então meu servidor Express vai criar uma conta

179
00:11:54,530 --> 00:11:59,383
para esse usuário específico que os registrou com sua conta do Facebook.

180
00:11:59,383 --> 00:12:05,995
E, posteriormente, forneça um token da Web JSON

181
00:12:05,995 --> 00:12:09,190
ao usuário, que o usuário pode usar para acessar

182
00:12:09,190 --> 00:12:12,530
os recursos armazenados no servidor Express.

183
00:12:12,530 --> 00:12:15,040
Então, novamente, para resumir isso,

184
00:12:15,040 --> 00:12:20,387
eu tenho um diagrama aqui para explicar isso para vocês em um pouco mais de detalhes.

185
00:12:20,387 --> 00:12:22,000
Além disso,

186
00:12:22,000 --> 00:12:24,225
há também um token de atualização.

187
00:12:24,225 --> 00:12:29,910
Quando um token de acesso é emitido pelo servidor OAuth 2 do Facebook,

188
00:12:29,910 --> 00:12:31,875
o token de acesso tem uma vida útil limitada.

189
00:12:31,875 --> 00:12:34,750
Depois disso, o token de acesso se tornará inválido.

190
00:12:34,750 --> 00:12:39,203
Então o token de acesso tem que ser mantido confidencial.

191
00:12:39,203 --> 00:12:43,285
Então, toda essa troca de tokens entre os diferentes sites

192
00:12:43,285 --> 00:12:48,040
será feita em uma matéria criptografada usando o protocolo HTTPS.

193
00:12:48,040 --> 00:12:50,980
Portanto, certifique-se de que quando você estiver enviando seu token de acesso de

194
00:12:50,980 --> 00:12:56,838
seu aplicativo front-end de usuário para o servidor Express,

195
00:12:56,838 --> 00:13:02,146
você só enviará o token de acesso por HTTPS, não HTTP.

196
00:13:02,146 --> 00:13:04,930
Isso é muito importante porque você não

197
00:13:04,930 --> 00:13:08,110
quer que seu token de acesso seja revelado a ninguém, porque qualquer pessoa

198
00:13:08,110 --> 00:13:10,960
que pode obter um de seu token de acesso pode fingir ser

199
00:13:10,960 --> 00:13:15,130
seu aplicativo cliente e, em seguida, obter acesso ao seu perfil de usuário.

200
00:13:15,130 --> 00:13:16,820
Portanto, isso é muito importante.

201
00:13:16,820 --> 00:13:20,005
Agora, como o token de acesso tem uma vida útil limitada,

202
00:13:20,005 --> 00:13:22,495
há também um token de atualização correspondente,

203
00:13:22,495 --> 00:13:27,550
que pode ser usado para atualizar um token de acesso expirado.

204
00:13:27,550 --> 00:13:30,790
Agora, no tipo de fluxo que vamos

205
00:13:30,790 --> 00:13:35,500
usar com nosso aplicativo no exercício,

206
00:13:35,500 --> 00:13:38,285
não seremos capazes de usar o token de atualização.

207
00:13:38,285 --> 00:13:41,620
Sempre que o usuário quiser autorizar

208
00:13:41,620 --> 00:13:46,070
o servidor Express para ir buscar as informações do perfil do Facebook,

209
00:13:46,070 --> 00:13:48,470
o usuário terá

210
00:13:48,470 --> 00:13:52,736
que fornecer explicitamente um novo token de acesso obtido do Facebook.

211
00:13:52,736 --> 00:13:56,665
A única parte que acabei de mencionar brevemente,

212
00:13:56,665 --> 00:13:58,221
mas não elaborei,

213
00:13:58,221 --> 00:14:01,920
é como o aplicativo cliente, o servidor Express,

214
00:14:01,920 --> 00:14:07,260
as escalas, como ele se registra no provedor de serviços OAuth 2?

215
00:14:07,260 --> 00:14:11,440
Agora, é aqui que muitos dos provedores de serviços OAuth 2

216
00:14:11,440 --> 00:14:16,705
fornecem uma maneira de registrar um aplicativo em seu site.

217
00:14:16,705 --> 00:14:18,050
Assim, um aplicativo cliente,

218
00:14:18,050 --> 00:14:20,485
os servidores Express em nosso exemplo,

219
00:14:20,485 --> 00:14:25,875
irá se registrar como um aplicativo cliente no provedor de serviços OAuth.

220
00:14:25,875 --> 00:14:27,460
Então, como você verá no exercício,

221
00:14:27,460 --> 00:14:31,795
o primeiro passo que faremos é entrar no Facebook com

222
00:14:31,795 --> 00:14:37,795
nossa conta e, em seguida, criar um aplicativo no site do Facebook.

223
00:14:37,795 --> 00:14:44,020
Quando você fizer isso, o Facebook emitirá um ID de aplicativo cliente e um segredo de cliente.

224
00:14:44,020 --> 00:14:47,830
Esse procedimento se aplica a muitos outros provedores de serviços OAuth porque

225
00:14:47,830 --> 00:14:51,960
esse é o fluxo geral que o protocolo OAuth 2 fala sobre.

226
00:14:51,960 --> 00:14:57,130
Assim, o ID do aplicativo cliente e o segredo do cliente são úteis para que possamos

227
00:14:57,130 --> 00:15:02,320
provar nossa identidade para

228
00:15:02,320 --> 00:15:08,960
o servidor OAuth quando estamos passando um token de acesso que obtemos do usuário.

229
00:15:08,960 --> 00:15:11,500
Agora, há também um URL de redirecionamento que você precisa

230
00:15:11,500 --> 00:15:14,650
registrar quando você está registrando o aplicativo cliente,

231
00:15:14,650 --> 00:15:18,520
e você vai me ver realizando isso nas etapas que eu registrar

232
00:15:18,520 --> 00:15:23,410
o aplicativo no site do Facebook.

233
00:15:23,410 --> 00:15:26,380
Agora, para resumir o fluxo de informações sobre o

234
00:15:26,380 --> 00:15:29,765
qual acabamos de falar brevemente no caso anterior,

235
00:15:29,765 --> 00:15:31,855
deixe-me começar neste ponto.

236
00:15:31,855 --> 00:15:35,295
O primeiro ponto a observar é o proprietário do recurso.

237
00:15:35,295 --> 00:15:39,355
Então, o proprietário do recurso aqui

238
00:15:39,355 --> 00:15:43,660
é o usuário que vai usar sua conta de mídia social.

239
00:15:43,660 --> 00:15:45,625
O Facebook, neste exemplo,

240
00:15:45,625 --> 00:15:49,490
tem a autenticação para o usuário.

241
00:15:49,490 --> 00:15:54,515
Portanto, o proprietário do recurso é aquele que tem o perfil sobre o recurso.

242
00:15:54,515 --> 00:15:57,760
E essas informações de perfil para cada conta do Facebook,

243
00:15:57,760 --> 00:16:00,535
elas foram armazenadas no servidor do Facebook.

244
00:16:00,535 --> 00:16:05,067
E assim o servidor do Facebook fornece o servidor de recursos aqui.

245
00:16:05,067 --> 00:16:08,410
Então esse é o provedor de serviços OAuth que você vê

246
00:16:08,410 --> 00:16:12,691
no lado direito desta imagem aqui.

247
00:16:12,691 --> 00:16:17,320
Então imagine o servidor do Facebook no lado direito, esse aplicativo cliente,

248
00:16:17,320 --> 00:16:18,928
que tem o servidor de API restante,

249
00:16:18,928 --> 00:16:20,477
o servidor Express que implementamos,

250
00:16:20,477 --> 00:16:22,270
é um aplicativo cliente neste caso,

251
00:16:22,270 --> 00:16:24,700
e o proprietário do recurso é o usuário.

252
00:16:24,700 --> 00:16:28,780
URL usuário front-end, que vai

253
00:16:28,780 --> 00:16:33,510
autorizar você a ir para o Facebook para verificar a credencial do usuário.

254
00:16:33,510 --> 00:16:39,245
Então, quando você quiser acessar informações no lado do cliente,

255
00:16:39,245 --> 00:16:44,355
você terá que primeiro ir e

256
00:16:44,355 --> 00:16:47,730
autorizar este aplicativo cliente para ser capaz de

257
00:16:47,730 --> 00:16:51,673
obter acesso a suas informações de perfil.

258
00:16:51,673 --> 00:16:52,855
Assim, o aplicativo cliente,

259
00:16:52,855 --> 00:16:55,120
se ele está atuando como um aplicativo web,

260
00:16:55,120 --> 00:17:00,095
ele irá fornecer um botão apropriado lá dizendo login usando Facebook.

261
00:17:00,095 --> 00:17:01,740
E assim, quando você clica no botão,

262
00:17:01,740 --> 00:17:04,780
essencialmente, o primeiro passo é iniciado.

263
00:17:04,780 --> 00:17:07,375
A solicitação de autorização do usuário é iniciada.

264
00:17:07,375 --> 00:17:09,270
Então seu aplicativo cliente,

265
00:17:09,270 --> 00:17:10,910
através do agente do usuário,

266
00:17:10,910 --> 00:17:17,409
o agente do usuário é basicamente o aplicativo cliente, o aplicativo front-end.

267
00:17:17,409 --> 00:17:22,725
Pode ser o aplicativo Angular que desenvolvemos ou aquele aplicativo móvel,

268
00:17:22,725 --> 00:17:25,950
seja Ionic ou se é

269
00:17:25,950 --> 00:17:30,120
um aplicativo NativeScript que desenvolvemos nos cursos mais cedo

270
00:17:30,120 --> 00:17:37,807
na especialização ou até mesmo um aplicativo nativo como um aplicativo iOS ou um aplicativo Android.

271
00:17:37,807 --> 00:17:39,060
Todos eles atuam como o agente do usuário.

272
00:17:39,060 --> 00:17:42,360
Então, o agente do usuário,

273
00:17:42,360 --> 00:17:45,420
eles usam um processo de solicitação de autorização através

274
00:17:45,420 --> 00:17:48,360
do agente do usuário para o servidor de autorização,

275
00:17:48,360 --> 00:17:50,500
que é o servidor do Facebook.

276
00:17:50,500 --> 00:17:52,235
Agora, quando isso for passado,

277
00:17:52,235 --> 00:17:55,796
então o proprietário do recurso ou o usuário,

278
00:17:55,796 --> 00:18:01,065
que está tentando dar acesso ao seu perfil para este aplicativo cliente,

279
00:18:01,065 --> 00:18:03,690
terá que autorizar o Facebook

280
00:18:03,690 --> 00:18:06,600
para poder compartilhar essas informações com o aplicativo cliente.

281
00:18:06,600 --> 00:18:11,250
Na abordagem de concessão de fluxo implícito que estamos usando em

282
00:18:11,250 --> 00:18:16,025
nosso exemplo aqui e também no exercício que se segue,

283
00:18:16,025 --> 00:18:18,390
a abordagem de concessão de fluxo implícito é

284
00:18:18,390 --> 00:18:22,875
a abordagem mais adequada quando você está implementando um aplicativo web usando

285
00:18:22,875 --> 00:18:26,563
um framework como Angular ou o aplicativo móvel híbrido

286
00:18:26,563 --> 00:18:30,925
com Ionic ou um NativeScript ou até mesmo um aplicativo nativo.

287
00:18:30,925 --> 00:18:34,320
A abordagem de concessão de fluxo implícito é muito mais simples maneira de

288
00:18:34,320 --> 00:18:39,170
operar o OAuth 2 para esse tipo de aplicações.

289
00:18:39,170 --> 00:18:43,930
Então, o proprietário do recurso clica no botão de login,

290
00:18:43,930 --> 00:18:49,710
então o servidor de autorização solicitará ao proprietário do recurso as informações dizendo:

291
00:18:49,710 --> 00:18:54,330
“Este aplicativo cliente deseja acessar suas informações de perfil.

292
00:18:54,330 --> 00:18:55,725
Você autoriza?”

293
00:18:55,725 --> 00:18:58,965
E então isso será exibido pelo Facebook,

294
00:18:58,965 --> 00:19:01,860
e então você clicará em um botão dizendo: “

295
00:19:01,860 --> 00:19:05,278
Sim, autorizo este aplicativo cliente a acessar em meu nome.”

296
00:19:05,278 --> 00:19:06,645
Então, nesse ponto,

297
00:19:06,645 --> 00:19:08,680
o servidor de autorização no Facebook,

298
00:19:08,680 --> 00:19:11,190
o servidor de autorização OAuth 2 no Facebook,

299
00:19:11,190 --> 00:19:13,380
gerará um token de acesso.

300
00:19:13,380 --> 00:19:15,105
Para gerar esse token de acesso,

301
00:19:15,105 --> 00:19:20,405
ele fará uso do ID do cliente para este aplicativo cliente,

302
00:19:20,405 --> 00:19:22,535
o aplicativo de servidor Express que registramos.

303
00:19:22,535 --> 00:19:28,165
Portanto, o ID do cliente deve ser parte do agente de usuário que este usuário usa.

304
00:19:28,165 --> 00:19:33,093
Portanto, este ID de cliente será incorporado no aplicativo Angular,

305
00:19:33,093 --> 00:19:38,585
o Ionic ou o aplicativo NativeScript ou até mesmo um iOS ou um aplicativo Android.

306
00:19:38,585 --> 00:19:40,560
Então, o ID do cliente será usado pelo

307
00:19:40,560 --> 00:19:43,410
agente do usuário para transformar o servidor de autorização dizendo:

308
00:19:43,410 --> 00:19:48,108
“Este aplicativo de cliente quer acesso ao meu perfil,

309
00:19:48,108 --> 00:19:52,704
e estou disposto a autorizá-lo a permitir o acesso ao perfil.”

310
00:19:52,704 --> 00:19:53,760
Então, nesse ponto,

311
00:19:53,760 --> 00:19:59,290
o servidor de autorização enviará um token de acesso para o agente do usuário neste caso.

312
00:19:59,290 --> 00:20:02,670
Então, lembre-se, este token de acesso entra no agente do usuário,

313
00:20:02,670 --> 00:20:09,180
que é o aplicativo móvel ou seu aplicativo Angular que é implementado por nós.

314
00:20:09,180 --> 00:20:12,870
Em seguida, este agente de usuário tomará este token de acesso e

315
00:20:12,870 --> 00:20:18,479
, em seguida, passar este token de acesso para esse aplicativo cliente.

316
00:20:18,479 --> 00:20:20,310
Portanto, o OAuth para fazer login,

317
00:20:20,310 --> 00:20:23,305
mas o token de acesso será passado para o aplicativo cliente,

318
00:20:23,305 --> 00:20:25,200
o servidor Express neste caso,

319
00:20:25,200 --> 00:20:32,340
em uma rota específica no roteador do usuário,

320
00:20:32,340 --> 00:20:37,465
a rota de autenticação no site do aplicativo cliente.

321
00:20:37,465 --> 00:20:41,000
Agora, anteriormente, vimos o uso de autenticação local,

322
00:20:41,000 --> 00:20:45,985
onde enviamos uma solicitação para cortar usuário barra login.

323
00:20:45,985 --> 00:20:48,250
Agora, para que isso funcione em nosso aplicativo,

324
00:20:48,250 --> 00:20:50,580
vamos configurar outro em usuários de barra,

325
00:20:50,580 --> 00:20:54,095
barra Facebook, barra token, e assim por diante.

326
00:20:54,095 --> 00:21:02,500
Então, outra URL em que fornecemos este token de acesso ao servidor Express.

327
00:21:02,500 --> 00:21:06,280
Agora, quando esse token de acesso é obtido pelo servidor Express,

328
00:21:06,280 --> 00:21:09,630
o servidor Express tomará esse token de acesso

329
00:21:09,630 --> 00:21:14,240
e, em seguida, juntamente com seu ID de cliente e o segredo do cliente,

330
00:21:14,240 --> 00:21:20,200
ele enviará essas informações para o servidor de autorização.

331
00:21:20,200 --> 00:21:25,140
E o servidor de autorização permitirá que seu aplicativo cliente

332
00:21:25,140 --> 00:21:30,565
acesse o servidor de recursos para obter as informações do perfil.

333
00:21:30,565 --> 00:21:35,060
E assim, as informações do perfil serão enviadas de volta na etapa número seis, de

334
00:21:35,060 --> 00:21:37,890
volta para o aplicativo cliente neste caso.

335
00:21:37,890 --> 00:21:42,015
Assim, quando o aplicativo cliente obtém as informações de perfil para o usuário,

336
00:21:42,015 --> 00:21:46,380
então o aplicativo cliente criará uma nova conta para

337
00:21:46,380 --> 00:21:51,785
o usuário em cada site se uma conta não existir.

338
00:21:51,785 --> 00:21:56,090
Se esse usuário já tiver feito login anteriormente usando seu ID do Facebook,

339
00:21:56,090 --> 00:22:00,045
uma conta já existirá para que o aplicativo cliente e o servidor da API

340
00:22:00,045 --> 00:22:05,485
Rest simplesmente verifiquem se essa conta de usuário já existe.

341
00:22:05,485 --> 00:22:06,865
E, nesse ponto,

342
00:22:06,865 --> 00:22:12,550
o usuário é autenticado para a funcionalidade de login de terceiros

343
00:22:12,550 --> 00:22:18,321
fornecida pelo serviço de autenticação OAuth 2 do Facebook.

344
00:22:18,321 --> 00:22:23,275
Nesse ponto, em seguida, o aplicativo cliente irá gerar um JSON Web Token,

345
00:22:23,275 --> 00:22:26,010
no exemplo que vamos implementar e exercer,

346
00:22:26,010 --> 00:22:33,040
e, em seguida, passar este JSON Web Token de volta para o agente do usuário ou o aplicativo front-end,

347
00:22:33,040 --> 00:22:35,845
ou aplicativo Angular, ou o aplicativo Ionic,

348
00:22:35,845 --> 00:22:38,590
ou o aplicativo NativeScript.

349
00:22:38,590 --> 00:22:45,160
Em seguida, o JSON Web Token será posteriormente usado pelo usuário

350
00:22:45,160 --> 00:22:48,790
para se autenticar sempre que ele ou ela quiser

351
00:22:48,790 --> 00:22:53,145
acessar quaisquer recursos armazenados no servidor Express.

352
00:22:53,145 --> 00:22:55,505
Então, uma vez que você obtém o JSON Web Token,

353
00:22:55,505 --> 00:23:00,975
todas as operações subsequentes, você já viu como fazer isso com JSON Web Token.

354
00:23:00,975 --> 00:23:03,565
Então, uma vez que você obtenha o JSON Web Token,

355
00:23:03,565 --> 00:23:05,070
seu trabalho é feito,

356
00:23:05,070 --> 00:23:10,150
e então você pode prosseguir com a operação normal a partir desse ponto em diante.

357
00:23:10,150 --> 00:23:12,940
Agora, quando o JSON Web Token expira,

358
00:23:12,940 --> 00:23:17,618
então você deve passar por todo o processo de re-autenticação e,

359
00:23:17,618 --> 00:23:22,990
posteriormente, permitir que os usuários acessem informações em seu site.

360
00:23:22,990 --> 00:23:29,710
Então, com essa compreensão rápida de como as operações OAuth 2 funcionam

361
00:23:29,710 --> 00:23:33,385
, novamente, como você vê, há muitos detalhes aqui.

362
00:23:33,385 --> 00:23:38,950
Mas, felizmente, não temos que lidar com todos esses detalhes porque vamos estar

363
00:23:38,950 --> 00:23:46,285
usando um módulo de nó que cuida de muitos desses detalhes em nosso nome.

364
00:23:46,285 --> 00:23:52,195
Uma vez que já configuramos o nosso servidor Express para usar Passport,

365
00:23:52,195 --> 00:24:00,980
agora podemos usar outro código de módulo nó como módulo Passport-Facebook-Token.

366
00:24:00,980 --> 00:24:04,595
O módulo Passport-Facebook-Token implementa essencialmente

367
00:24:04,595 --> 00:24:08,580
a abordagem de concessão implícita que eu falei anteriormente.

368
00:24:08,580 --> 00:24:11,320
E então você pode inicializar

369
00:24:11,320 --> 00:24:18,160
uma nova estratégia em sua estratégia Passport, dentro de sua aplicação.

370
00:24:18,160 --> 00:24:22,720
E para que o módulo Passport-Facebook-Token permita que você configure

371
00:24:22,720 --> 00:24:31,090
uma nova estratégia de autenticação Passport para usar a API OAuth 2 baseada no Facebook.

372
00:24:31,090 --> 00:24:36,085
E assim, para fazer uso deste módulo,

373
00:24:36,085 --> 00:24:41,615
você instala isso dizendo passado npm install passport- facebook-token,

374
00:24:41,615 --> 00:24:44,980
menos menos salvar, e então uma vez que você instalou isso,

375
00:24:44,980 --> 00:24:51,010
então você irá configurar uma estratégia do Facebook dentro do seu aplicativo, e, depois disso,

376
00:24:51,010 --> 00:24:57,810
fazer uso disso para configurar a estratégia para o seu Passport

377
00:24:57,810 --> 00:25:04,990
utilizar se estivermos a utilizar a autenticação baseada em OAuth 2 para a nossa aplicação.

378
00:25:04,990 --> 00:25:09,270
Com esta rápida compreensão de OAuth 2,

379
00:25:09,270 --> 00:25:11,770
vamos passar para o exercício,

380
00:25:11,770 --> 00:25:16,630
onde vamos configurar nosso servidor Express para realmente fazer uso

381
00:25:16,630 --> 00:25:20,920
desta abordagem de concessão implícita para nos permitir

382
00:25:20,920 --> 00:25:25,450
verificar nossa identidade para o servidor Express e,

383
00:25:25,450 --> 00:25:29,745
depois disso, obter acesso aos recursos, pratos,

384
00:25:29,745 --> 00:25:38,180
as promoções e as informações dos líderes armazenadas no nosso servidor Express.