Nota. transl.: Este gran artigo de Okta explica como funcionan OAuth e OIDC (OpenID Connect) dunha forma sinxela e clara. Este coñecemento será útil para desenvolvedores, administradores de sistemas e mesmo para "usuarios habituais" de aplicacións web populares, que moi probablemente tamén intercambian datos confidenciais con outros servizos.
Na Idade de Pedra de Internet, compartir información entre servizos era doado. Simplemente deu o seu inicio de sesión e contrasinal dun servizo a outro, para que ingresase na súa conta e recibise toda a información que necesitaba.
"Dáme a túa conta bancaria". "Prometemos que todo estará ben co contrasinal e co diñeiro. É honesto, honesto!" *hee hee*
Horror! Ninguén debería esixir a un usuario que comparta un nome de usuario e un contrasinal, credenciais, con outro servizo. Non hai garantía de que a organización detrás deste servizo manterá os datos seguros e non recompilará máis información persoal da necesaria. Pode parecer tolo, pero algunhas aplicacións aínda usan esta práctica.
Hoxe hai un único estándar que permite que un servizo utilice de forma segura os datos doutro. Desafortunadamente, tales estándares usan moita xerga e termos, o que complica a súa comprensión. A finalidade deste material é explicar o seu funcionamento mediante ilustracións sinxelas (¿Cres que os meus debuxos semellan os debuxos infantís? Vaia!).
Por certo, esta guía tamén está dispoñible en formato de vídeo:
Señoras e señores, benvidos: OAuth 2.0
é un estándar de seguridade que permite que unha aplicación obteña permiso para acceder a información noutra aplicación. Secuencia de pasos para a expedición da autorización [permiso] (Ou consentimento [consentimento]) adoita chamar autorización [autorización] ou mesmo autorización delegada [autorización delegada]. Con este estándar, permite que unha aplicación lea datos ou utilice as funcións doutra aplicación no seu nome sen darlle o seu contrasinal. Clase!
Como exemplo, digamos que descobres un sitio chamado "Unlucky Pun of the Day" [Terrible xogo do día] e decidiu rexistrarse nel para recibir diariamente xogos de palabras en forma de mensaxes de texto no teléfono. Gustouche moito o sitio e decidiches compartilo con todos os teus amigos. Despois de todo, a todo o mundo lle gustan os xogos de palabras espeluznantes, non?
"Lamentable xogo de palabras do día: escoitou falar do tipo que perdeu a metade esquerda do seu corpo? Agora sempre ten razón!" (tradución aproximada, porque o orixinal ten o seu propio xogo de palabras - aprox. traduc.)
Está claro que escribir a cada persoa da lista de contactos non é unha opción. E, se es aínda un pouco coma min, fará todo o posible para evitar traballos innecesarios. Afortunadamente, Terrible Pun of the Day pode invitar a todos os teus amigos só! Para iso, só tes que abrir o acceso ao correo electrónico dos teus contactos: o propio sitio enviaralles invitacións (regras OAuth).
"Todo o mundo adora os xogos de palabras! - Xa iniciaches sesión? "Queres permitir que o sitio web de Terrible Pun of the Day acceda á túa lista de contactos? - Grazas! A partir de agora, enviaremos recordatorios todos os días a todos os que coñecedes, ata o final dos tempos! Ti es o mellor amigo!"
- Escolla o seu servizo de correo electrónico.
- Se é necesario, vai ao sitio de correo electrónico e inicia sesión na túa conta.
- Dá permiso a Terrible Pun of the Day para acceder aos teus contactos.
- Volve ao sitio Terrible Pun of the Day.
No caso de cambiar de opinión, as aplicacións que usan OAuth tamén ofrecen un xeito de revogar o acceso. Unha vez que decidas que xa non queres compartir contactos con Terrible Pun of the Day, podes ir ao sitio de correo e eliminar o sitio de xogos de palabras da lista de aplicacións autorizadas.
Fluxo OAuth
Acabamos de pasar polo que se adoita chamar fluxo [fluir] OAuth. No noso exemplo, este fluxo consta de pasos visibles, así como de varios pasos invisibles, nos que dous servizos acordan un intercambio seguro de información. O exemplo anterior de Terrible Pun of the Day usa o fluxo de OAuth 2.0 máis común, coñecido como fluxo de "código de autorización". [fluxo de "código de autorización"].
Antes de mergullarnos nos detalles de como funciona OAuth, imos falar do significado dalgúns termos:
- Propietario do recurso:
Es ti! Vostede é o propietario das súas credenciais, dos seus datos e controla todas as actividades que se poidan realizar nas súas contas. - Cliente:
Unha aplicación (por exemplo, o servizo Terrible Pun of the Day) que quere acceder ou realizar determinadas accións en nome de Propietario do recurso'á. - Servidor de autorización:
A aplicación que sabe Propietario do recurso'a e no que u Propietario do recurso'Xa tes unha conta. - servidor de recursos:
Interface de programación de aplicacións (API) ou servizo que Cliente quere usar en nome Propietario do recurso'á. - URI de redirección:
A ligazón que Servidor de autorización redirixirá Propietario do recurso'e despois de conceder o permiso Cliente'ás. Ás veces denomínase "URL de devolución de chamada". - Tipo de resposta:
O tipo de información que se espera recibir Cliente. O máis común Tipo de resposta'Ohm é o código, é dicir Cliente espera recibir Código de autorización. - Alcance:
Esta é unha descrición detallada dos permisos que son necesarios Cliente'y, como acceder a datos ou realizar determinadas accións. - Consentimento:
Servidor de autorización leva Alcancesolicitado Cliente'om, e pregunta Propietario do recurso'a, está preparado para proporcionar Cliente'ter os permisos adecuados. - ID de cliente:
Este ID úsase para identificar Cliente'a on Servidor de autorización'e. - Secreto do cliente:
Este é o contrasinal que só se coñece Cliente'u e Servidor de autorización'ás. Permítelles compartir información de forma privada. - Código de autorización:
Código temporal cun período breve de vixencia, que Cliente fornece Servidor de autorización'y a cambio de Token de acceso. - Token de acceso:
A clave coa que utilizará o cliente para comunicarse servidor de recursos'om. Unha especie de distintivo ou tarxeta clave que proporciona Cliente'ter permiso para solicitar datos ou realizar accións sobre servidor de recursos'e no teu nome.
Nota: Ás veces o servidor de autorización e o servidor de recursos son o mesmo servidor. Non obstante, nalgúns casos, estes poden ser servidores diferentes, aínda que non pertenzan á mesma organización. Por exemplo, o servidor de autorización pode ser un servizo de terceiros no que o servidor de recursos confía.
Agora que cubrimos os conceptos fundamentais de OAuth 2.0, volvamos ao noso exemplo e vexamos máis de cerca o que ocorre no fluxo de OAuth.
- ti, Propietario do recurso, queres ofrecer o servizo Terrible Pun of the Day (Clientey) acceder aos teus contactos para que poidan enviar invitacións a todos os teus amigos.
- Cliente redirixe o navegador á páxina Servidor de autorización'a e incluír na consulta ID de cliente, URI de redirección, Tipo de resposta e unha ou máis Alcance (permisos) que precisa.
- Servidor de autorización verifica-lo, pedindo un nome de usuario e contrasinal se é necesario.
- Servidor de autorización mostra un formulario Consentimento (confirmacións) cunha lista de todos Alcancesolicitado Cliente'om. Vostede acepta ou rexeita.
- Servidor de autorización redirixe ao sitio Cliente'a, usando URI de redirección xunto con Código de autorización (código de autorización).
- Cliente comunica directamente con Servidor de autorización'ohm (omitir o navegador Propietario do recurso'a) e envía con seguridade ID de cliente, Secreto do cliente и Código de autorización.
- Servidor de autorización comproba os datos e responde con Token de acceso'om (token de acceso).
- Agora Cliente pode usar Token de acceso para enviar unha solicitude a servidor de recursos para obter unha lista de contactos.
ID do cliente e segredo
Moito antes de que permitise a Terrible Pun of the Day acceder aos seus contactos, o cliente e o servidor de autorización estableceran unha relación de traballo. O servidor de autorización xerou o ID de cliente e o segredo do cliente (ás veces chamado ID de aplicación и Segredo da aplicación) e enviounos ao Cliente para unha maior interacción dentro de OAuth.
"- Ola! Gustaríame traballar contigo! -Claro, non hai problema! Aquí tes o teu ID de cliente e o teu segredo!"
O nome implica que o segredo do cliente debe manterse en segredo para que só o coñezan o cliente e o servidor de autorización. Despois de todo, é coa súa axuda que o servidor de autorización confirma a verdade do cliente.
Pero iso non é todo... Benvido a OpenID Connect!
OAuth 2.0 só está deseñado para autorización - para proporcionar acceso a datos e funcións dunha aplicación a outra. (OIDC) é unha capa delgada enriba de OAuth 2.0 que engade os detalles de inicio de sesión e perfil do usuario que inicia sesión na conta. A organización dunha sesión de inicio de sesión denomínase a miúdo como autenticación [autenticación], e información sobre o usuario que iniciou sesión no sistema (é dicir, sobre Propietario do recurso'e), - datos persoais [identidade]. Se o servidor de autorización admite OIDC, ás veces denomínase como provedor de datos persoais [proveedor de identidade]porque proporciona Cliente'ter información sobre Propietario do recurso'e.
OpenID Connect permítelle implementar escenarios nos que se pode usar un único inicio de sesión en varias aplicacións; este enfoque tamén se coñece como inicio de sesión único (SSO). Por exemplo, unha aplicación pode admitir a integración SSO con redes sociais como Facebook ou Twitter, permitindo aos usuarios utilizar unha conta que xa teñen e que prefiren usar.
O fluxo (fluxo) OpenID Connect ten o mesmo aspecto que no caso de OAuth. A única diferenza é que na solicitude principal, o ámbito específico utilizado é openid, - A Cliente ao final queda como Token de accesoE Token de identificación.
Igual que no fluxo de OAuth, Token de acceso en OpenID Connect, este é un valor que non está claro Cliente'ás. Dende o punto de vista Cliente'á Token de acceso representa unha cadea de caracteres que se pasa xunto con cada solicitude a servidor de recursos'y, que determina se o token é válido. Token de identificación representa unha cousa completamente diferente.
ID Token é un JWT
Token de identificación é unha cadea de caracteres con formato especial coñecida como JSON Web Token ou JWT (Ás veces os tokens JWT pronúncianse como "jots"). Para os observadores externos, JWT pode parecer un galimatías incomprensible, pero Cliente pode extraer varias informacións do JWT, como ID, nome de usuario, hora de inicio de sesión, data de caducidade Token de identificación'a, a presenza de intentos de interferir co JWT. Datos dentro Token de identificación'a chámanse aplicacións [reclamacións].
No caso de OIDC, tamén existe unha vía estándar Cliente pode solicitar información adicional sobre o individuo [identidade] de Servidor de autorización'a, por exemplo, un enderezo de correo electrónico usando Token de acceso.
Obtén máis información sobre OAuth e OIDC
Entón, repasamos brevemente como funcionan OAuth e OIDC. Listo para afondar? Aquí tes recursos adicionais para axudarche a obter máis información sobre OAuth 2.0 e OpenID Connect:
Coma sempre, non dubides en comentar. Para estar ao día das nosas últimas novidades, subscríbete a и Okta para desenvolvedores!
PS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com
