Nota. transl.: Aquest gran article d'Okta explica com funcionen OAuth i OIDC (OpenID Connect) d'una manera senzilla i clara. Aquest coneixement serà útil per als desenvolupadors, administradors de sistemes i fins i tot "usuaris habituals" d'aplicacions web populars, que molt probablement també intercanvien dades confidencials amb altres serveis.
A l'edat de pedra d'Internet, compartir informació entre serveis era fàcil. Només heu donat el vostre inici de sessió i contrasenya d'un servei a un altre, de manera que ell entrés al vostre compte i rebé tota la informació que necessitava.
"Dóna'm el teu compte bancari". "Prometem que tot anirà bé amb la contrasenya i els diners. Això és honest, honest!" *hee hee*
Horror! Ningú hauria de demanar mai a un usuari que comparteixi un nom d'usuari i una contrasenya, credencials, amb un altre servei. No hi ha cap garantia que l'organització que hi ha darrere d'aquest servei mantindrà les dades segures i no recopilarà més informació personal de la necessària. Pot semblar una bogeria, però algunes aplicacions encara fan servir aquesta pràctica!
Avui dia hi ha un únic estàndard que permet que un servei utilitzi de manera segura les dades d'un altre. Malauradament, aquests estàndards utilitzen una gran quantitat d'argot i termes, cosa que complica la seva comprensió. L'objectiu d'aquest material és explicar com funcionen amb il·lustracions senzilles (Creus que els meus dibuixos s'assemblen a l'embassament dels nens? Vaja!).
Per cert, aquesta guia també està disponible en format de vídeo:
Senyores i senyors, benvinguts: OAuth 2.0
és un estàndard de seguretat que permet a una aplicació obtenir permís per accedir a la informació d'una altra aplicació. Seqüència de passos per a l'expedició d'un permís [permís] (O consentiment [consentiment]) truca sovint autorització [autorització] o autorització delegada [autorització delegada]. Amb aquest estàndard, permeteu que una aplicació llegeixi dades o utilitzi les funcions d'una altra aplicació en nom vostre sense donar-li la vostra contrasenya. Classe!
Com a exemple, suposem que descobreixes un lloc anomenat "El joc desafortunat del dia" [Terrible joc de paraules del dia] i va decidir registrar-s'hi per rebre jocs de paraules diaris en forma de missatges de text al telèfon. T'ha agradat molt el lloc i has decidit compartir-lo amb tots els teus amics. Després de tot, a tothom li agraden els jocs de paraules esgarrifosos, oi?
"Lamentablement joc de paraules del dia: has sentit parlar de l'home que va perdre la meitat esquerra del seu cos? Ara sempre té raó!" (traducció aproximada, perquè l'original té el seu propi joc de paraules - trad. aprox.)
Està clar que escriure a cada persona de la llista de contactes no és una opció. I, si encara ets una mica com jo, faràs tot el possible per evitar treballs innecessaris. Afortunadament, Terrible Pun of the Day pot convidar tots els teus amics tot sol! Per fer-ho, només heu d'obrir l'accés al correu electrònic dels vostres contactes: el lloc mateix els enviarà invitacions (regles OAuth)!
"A tothom li agraden els jocs de paraules! - Ja has iniciat sessió? "Vols permetre que el lloc web Terrible Pun of the Day accedeixi a la teva llista de contactes? - Gràcies! A partir d'ara, enviarem recordatoris cada dia a tothom que coneixeu, fins al final dels temps! Ets el millor amic!"
- Trieu el vostre servei de correu electrònic.
- Si cal, aneu al lloc de correu i inicieu la sessió al vostre compte.
- Doneu permís a Terrible Pun of the Day per accedir als vostres contactes.
- Torna al lloc Terrible Pun of the Day.
En cas que canvieu d'opinió, les aplicacions que utilitzen OAuth també proporcionen una manera de revocar l'accés. Un cop decidiu que ja no voleu compartir contactes amb Terrible Pun of the Day, podeu anar al lloc de correu i eliminar el lloc de joc de paraules de la llista d'aplicacions autoritzades.
Flux OAuth
Acabem de passar pel que se sol dir fluir [flux] OAuth. En el nostre exemple, aquest flux consta de passos visibles, així com diversos passos invisibles, en què dos serveis acorden un intercanvi segur d'informació. L'exemple anterior de Terrible Pun of the Day utilitza el flux OAuth 2.0 més comú, conegut com a flux de "codi d'autorització". [flux "codi d'autorització"].
Abans d'aprofundir en els detalls de com funciona OAuth, parlem del significat d'alguns termes:
- Propietari del recurs:
Ets tu! Sou el propietari de les vostres credencials, les vostres dades i controleu totes les activitats que es puguin dur a terme als vostres comptes. - client:
Una aplicació (per exemple, el servei Terrible Pun of the Day) que vol accedir o realitzar determinades accions en nom de Propietari del recurs'а. - Servidor d'autoritzacions:
L'aplicació que sap Propietari del recurs'a i en què u Propietari del recurs'ja tens un compte. - servidor de recursos:
Interfície de programació d'aplicacions (API) o servei que client vol utilitzar en nom Propietari del recurs'а. - URI de redirecció:
L'enllaç que Servidor d'autoritzacions redirigirà Propietari del recurs'i després de concedir el permís client'a les. De vegades s'anomena "URL de devolució de trucada". - tipus de resposta:
El tipus d'informació que s'espera rebre client. Els més comuns tipus de resposta'Ohm és el codi, és a dir client espera rebre codi d'autorització. - abast:
Aquesta és una descripció detallada dels permisos necessaris client'y, com ara accedir a dades o realitzar determinades accions. - Consentiment:
Servidor d'autoritzacions pren Scopesdemanat client'om, i pregunta Propietari del recurs'a, està disposat a proporcionar client'tingui els permisos adequats. - Identificador de client:
Aquest identificador s'utilitza per identificar client'a on Servidor d'autoritzacions'e. - Secret del client:
Aquesta és la contrasenya que només es coneix client'tu i Servidor d'autoritzacions'a les. Els permet compartir informació de manera privada. - codi d'autorització:
Codi temporal amb un curt període de validesa, que client proporciona Servidor d'autoritzacions'y a canvi de Fitxa d'accés. - Fitxa d'accés:
La clau que utilitzarà el client per comunicar-se servidor de recursos'om. Una mena de distintiu o targeta clau que proporciona client'tenen permís per sol·licitar dades o realitzar accions servidor de recursos'E en nom teu.
Nota: De vegades, el servidor d'autorització i el servidor de recursos són el mateix servidor. Tanmateix, en alguns casos, aquests poden ser servidors diferents, encara que no pertanyin a la mateixa organització. Per exemple, el servidor d'autoritzacions pot ser un servei de tercers en què confia el servidor de recursos.
Ara que hem cobert els conceptes bàsics d'OAuth 2.0, tornem al nostre exemple i mirem més de prop què passa al flux d'OAuth.
- Vostè, Propietari del recurs, voleu oferir el servei Terrible Pun of the Day (clienty) accedir als teus contactes perquè puguin enviar invitacions a tots els teus amics.
- client redirigeix el navegador a la pàgina Servidor d'autoritzacions'a i inclou a la consulta Identificador de client, URI de redirecció, tipus de resposta i un o més Scopes (permisos) que necessita.
- Servidor d'autoritzacions et verifica, demanant un nom d'usuari i una contrasenya si cal.
- Servidor d'autoritzacions mostra un formulari Consentiment (confirmacions) amb una llista de tots Scopesdemanat client'om. Estàs d'acord o negues.
- Servidor d'autoritzacions et redirigeix al lloc client'a, utilitzant URI de redirecció amb codi d'autorització (codi d'autorització).
- client es comunica directament amb Servidor d'autoritzacions'ohm (obviant el navegador Propietari del recurs'a) i envia amb seguretat Identificador de client, Secret del client и codi d'autorització.
- Servidor d'autoritzacions comprova les dades i respon amb Fitxa d'accés'om (token d'accés).
- Ara client pot utilitzar Fitxa d'accés per enviar una sol·licitud a servidor de recursos per obtenir una llista de contactes.
ID de client i secret
Molt abans de permetre que Terrible Pun of the Day accedeixi als vostres contactes, el client i el servidor d'autoritzacions havien establert una relació de treball. El servidor d'autoritzacions va generar l'identificador de client i el secret del client (de vegades anomenat Identificador de l'aplicació и Secret de l'aplicació) i els va enviar al client per a una interacció posterior dins d'OAuth.
"- Hola! M'agradaria treballar amb tu! - És clar, no hi ha cap problema! Aquí teniu el vostre ID de client i secret!
El nom indica que el secret del client s'ha de mantenir en secret perquè només el coneguin el client i el servidor d'autoritzacions. Després de tot, és amb la seva ajuda que el servidor d'autorització confirma la veritat del client.
Però això no és tot... Benvingut a OpenID Connect!
OAuth 2.0 només està dissenyat per a autorització - Per proporcionar accés a dades i funcions d'una aplicació a una altra. (OIDC) és una capa fina a la part superior d'OAuth 2.0 que afegeix les dades d'inici de sessió i de perfil de l'usuari que ha iniciat la sessió al compte. Sovint es coneix com a organització d'una sessió d'inici de sessió autenticació [autenticació], i informació sobre l'usuari que ha iniciat sessió al sistema (és a dir, sobre Propietari del recurs'e), - dades personals [identitat]. Si el servidor d'autoritzacions admet OIDC, de vegades es coneix com a proveïdor de dades personals [proveïdor d'identitat]perquè proporciona client'tenen informació sobre Propietari del recurs'e.
OpenID Connect us permet implementar escenaris en què es pot utilitzar un únic inici de sessió en diverses aplicacions; aquest enfocament també es coneix com inici de sessió únic (SSO). Per exemple, una aplicació pot admetre la integració d'SSO amb xarxes socials com Facebook o Twitter, permetent als usuaris utilitzar un compte que ja tenen i prefereixen utilitzar.
El flux (flux) OpenID Connect té el mateix aspecte que en el cas d'OAuth. L'única diferència és que a la sol·licitud principal, l'àmbit específic utilitzat és openid,-A client al final s'agrada Fitxa d'accésI Token d'identificació.
Igual que en el flux OAuth, Fitxa d'accés a OpenID Connect, aquest és un valor que no està clar client'a les. Des del punt de vista client'a Fitxa d'accés representa una cadena de caràcters que es passa juntament amb cada sol·licitud a servidor de recursos'y, que determina si el testimoni és vàlid. Token d'identificació representa una cosa completament diferent.
ID Token és un JWT
Token d'identificació és una cadena de caràcters amb un format especial coneguda com JSON Web Token o JWT (de vegades les fitxes JWT es pronuncien com "jots"). Per als observadors externs, JWT pot semblar un galimat incomprensible, però client pot extreure informació diversa del JWT, com ara ID, nom d'usuari, hora d'inici de sessió, data de caducitat Token d'identificació'a, la presència d'intents d'interferir amb el JWT. Dades dins Token d'identificació'a es diuen aplicacions [reclamacions].
En el cas de l'OIDC, també hi ha una manera estàndard client pot sol·licitar informació addicional sobre la persona [identitat] d' Servidor d'autoritzacions'a, per exemple, una adreça de correu electrònic utilitzant Fitxa d'accés.
Més informació sobre OAuth i OIDC
Per tant, vam revisar breument com funcionen OAuth i OIDC. Preparat per aprofundir? Aquí teniu recursos addicionals per ajudar-vos a obtenir més informació sobre OAuth 2.0 i OpenID Connect:
Com sempre, no dubteu a comentar. Per estar al dia de les nostres últimes notícies, subscriu-te a и Okta per a desenvolupadors!
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com