OAuth

OAuth és un estàndard obert per a l'autorització, que s'utilitza normalment com una forma perquè els usuaris d'Internet autoritzin llocs web o aplicacions per accedir a la seva informació en altres llocs web, però sense donar-los les contrasenyes.

Aquest mecanisme és utilitzat per empreses com Google, Facebook, Microsoft i Twitter per permetre als usuaris compartir informació sobre seus comptes amb aplicacions de tercers o llocs web.

Proporciona als clients un accés segur delegat als recursos del servidor en nom del propietari d'un recurs. En ell s'especifica un procés per als propietaris de recursos per autoritzar l'accés de tercers als seus recursos de servidor sense compartir les seves credencials. Dissenyat específicament per treballar amb el protocol de transferència d'hipertext (HTTP).

OAuth permet essencialment tokens d'accés que s'emetran a clients de tercers mitjançant un servidor d'autorització, amb l'aprovació del propietari del recurs. El tercer utilitza el token d'accés per accedir als recursos protegits allotjats al servidor de recursos.

OAuth és un servei que és complementari i diferent d'OpenID. OAuth és també diferent de OATH, que és una arquitectura de referència per a l'autenticació, no és un estàndard per a l'autorització. No obstant això, OAuth està directament relacionada amb OpenID Connect (OIDC) des OIDC és una capa d'autenticació incorporada sobre la de OAuth 2.0. OAuth és també diferent de XACML, que és un estàndard de la política d'autorització. OAuth pot ser emprat amb XACML on s'utilitza OAuth per al consentiment de propietat i delegació d'accés mentre XACML s'utilitza per definir les polítiques d'autorització.

Història

OAuth va començar al novembre de 2006,amb la implementació de OpenID per Twitter per part de Blaine Cook. Mentrestant l'empresa Dt.gnolia, amb un servei de marcadors socials, necessitava una solució que permetés als seus membres amb OpenID autoritzar widgets en el dashboard per accedir al seu servei. És llavors quan Blaine Cook, Chris Messina i Larry Halff de Dt.gnolia (ara Gnolia) es van reunir amb David Recordon per discutir l'ús de OpenID amb les API de Twitter i Dt..gnolia per delegar l'autenticació. Van arribar a la conclusió que no existia cap estàndard obert per delegar accés a les API.

A l'abril de 2007 es va crear el grup de discussió de OAuth, perquè el petit grup de desenvolupadors escrivís un esborrany de proposta per a un protocol obert. DeWitt Clinton de Google es va assabentar del projecte OAuth i es va mostrar interessat a recolzar l'esforç. L'equip va acabar l'esborrany inicial de l'especificació al juliol de 2007. Eren Hammer-Lahav es va unir i va coordinar les diverses contribucions a OAuth, creant una especificació més formal. L'esborrany definitiu OAuth Core 1.0 es va publicar el 3 d'octubre de 2007.

OAuth 2.0

OAuth 2.0 no és compatible amb OAuth 1.0. La versió 2.0 proporciona fluxos d'autorització específica per a aplicacions web, aplicacions d'escriptori, telèfons mòbils i altres dispositius personals. La memòria descriptiva i RFCs associats són desenvolupats per l'IETF OAuth WG el marc principal va ser publicat a l'octubre de 2012.

OAuth 2.0 és utilitzat per APIs com Graph de Facebook, Google i Microsoft o altres APIs de tercers.

El 2.0 Marc de OAuth i Bearer Token Usage es van publicar a l'octubre de 2012.

Rols

1.Propietari del recurs: és l'usuari que autoritza una aplicació per accedir al seu compte. L'accés de l'aplicació al compte de l'usuari es limita a l'acció de l'autorització concedida (per exemple, lectura o escriptura).

2.Client: és l'aplicació que vol tenir accés al compte de l'usuari. Abans que pugui fer-ho, ha de ser autoritzada per l'usuari, així com l'autorització ha de ser validat per l'API.

3.Servidor de recursos: el servidor de recursos acull els comptes d'usuari protegides.

4.Servidor d'autorització: el servidor d'autorització verifica la identitat de l'usuari que emet tokens d'accés a l'aplicació

Protocol

Diagrama del protocol OAuth 2.0

Aquí està una explicació més detallada dels passos en el diagrama:

L'autorització de les sol·licituds d'aplicació per accedir als recursos del servei per part de l'usuari.
Si l'usuari autoritza la sol·licitud, l'aplicació rep una concessió d'autorització
L'aplicació sol·licita un símbol d'accés del servidor d'autorització (API) mitjançant la presentació d'autenticació de la seva pròpia identitat, i la concessió d'autorització
Si la identitat de l'aplicació s'autentica i la concessió d'autorització és vàlida, el servidor d'autorització (API) emet un senyal d'accés a l'aplicació. L'autorització és completa.
L'aplicació sol·licita el recurs des del servidor de recursos (API) i presenta el testimoni d'accés per a l'autenticació
Si el token d'accés és vàlid, el servidor de recursos (API) serveix el recurs a l'aplicació

Registre d'Aplicació

Abans d'utilitzar OAuth amb l'aplicació, s'ha de registrar l'aplicació amb el servei. Això es fa a través d'un formulari d'inscripció en el developer o API de la pàgina web del servei, on va a proporcionar la següent informació (i probablement detalls sobre la seva sol·licitud):

Nom de l'aplicació.
Lloc de l'aplicació web.
URL de redirecció o URL de devolució de trucada.

L'URL de redirecció és on el servei redirigirà l'usuari després que s'autoritzi (o negui l'accés) l'aplicació, i per tant la part de l'aplicació que s'encarregarà dels codis d'autorització o tokens d'accés.

ID de client i clau secreta de client

Una vegada que s'ha registrat l'aplicació, el servei emetrà credencials del client en la forma d'un identificador de client i un secret de client.

L'identificador de client és una cadena exposada públicament que és utilitzat per l'API del servei per identificar l'aplicació, i també s'utilitza per a generar les adreces URL d'autorització que es presenten als usuaris.

El secret de client s'utilitza per autenticar la identitat de l'aplicació de l'API de servei quan les peticions d'aplicacions per accedir al compte d'un usuari, i s'ha de mantenir privada entre l'aplicació i l'API.

Concessió d'autorització

En el flux de Protocol extracte anterior, els quatre primers passos cobreixen l'obtenció d'un token de concessió d'autorització i accés. El tipus de concessió d'autorització depèn del mètode utilitzat per l'aplicació per a sol·licitar l'autorització, i els tipus de concessions suportats per l'API. OAuth 2 defineix quatre tipus de concessions, cada un dels quals és útil en diferents casos:

Codi d'autorització: s'utilitza amb aplicacions de servidor
Implícit: s'utilitza amb aplicacions mòbils o aplicacions web (aplicacions que s'executen en el dispositiu de l'usuari).
Credencials de passwords dels recursos del propietari: usats amb aplicacions de confiança, com ara els de propietat del servei en si
Credencials del client: s'utilitza amb accés a aplicacions API

Ara anem a descriure els tipus de subvenció amb més detall, els seus casos i els fluxos d'ús, en les següents seccions.

Tipus de concessió: Codi d'autorització

Seqüència codi autorització

El tipus de concessió codi d'autorització és el més comunament utilitzat, ja que està optimitzat per a aplicacions de servidor, on el codi font no està exposat públicament, i la confidencialitat del client secret pot ser mantingut. Aquest és un flux basat en la redirecció, el que significa que l'aplicació ha de ser capaç d'interaccionar amb l'agent d'usuari (és a dir, el navegador web de l'usuari) i rebre els codis d'autorització d'API que són enrutats a través de l'agent d'usuari.

Tipus de concessió: Implícit

El tipus de concessió implícita s'utilitza per a aplicacions mòbils i aplicacions web (aplicacions és a dir, que s'executen en un navegador web), on no es garanteix la confidencialitat del client secret. El tipus de subvenció implícita és també un flux basat en la redirecció, però se li dona el testimoni d'accés a l'usuari-agent per reenviar a l'aplicació, de manera que es pot exposar a l'usuari i altres aplicacions al dispositiu de l'usuari. A més, aquest flux no autentica la identitat de l'aplicació, i es basa en l'URI de redirecció (que es va registrar amb el servei) per servir a aquest propòsit.

El tipus de concessió implícita no admet tokens d'actualització.

El flux de concessió implícita bàsicament funciona de la següent manera: es demana a l'usuari que autoritzi l'aplicació, a continuació, el servidor d'autorització passa el testimoni d'accés de nou a l'agent d'usuari, que el passa a l'aplicació.

Seqüència concessió implícita.

Tipus de concessió: Credencials de passwords dels recursos del propietari

Amb aquest tipus de concessió, l'usuari proporciona les seves credencials de servei (nom d'usuari i contrasenya) directament a l'aplicació, que utilitza les credencials per obtenir un testimoni d'accés del servei. Aquest tipus de concessió només ha d'estar habilitat al servidor d'autorització si altres fluxos no són viables. A més, només s'ha d'utilitzar si l'aplicació és de confiança per part de l'usuari (per exemple, que és propietat del servei, o el sistema operatiu d'escriptori de l'usuari).

Flux de credencials de password:

Després que l'usuari presta els seus credencials a l'aplicació, l'aplicació sol·licitarà llavors un símbol d'accés des del servidor d'autorització. La sol·licitud POST podria ser alguna cosa com això:

https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

Si les credencials d'usuari són correctes, el servidor d'autorització retorna un testimoni d'accés a l'aplicació. Ara l'aplicació està autoritzada!

Tipus de concessió:Credencials de client

Aquest tipus de concessió proporciona a una aplicació una forma d'accedir al seu propi compte de servei. Els exemples dels casos que poden ser útils inclouen si una aplicació vol actualitzar la seva descripció registrada o redirigir URI, o accedir a altres dades emmagatzemades en el seu compte de servei a través de l'API.

Flux de Credencials de client:

L'aplicació sol·licita un testimoni d'accés mitjançant l'enviament de les seves credencials, el seu ID de client i el secret de client all servidor d'autorització. Un exemple de petició de missatge pot ser similar al següent:

{{format ref}} https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Si les credencials de l'aplicació són correctes, i el servidor d'autorització retorna un testimoni d'accés a l'aplicació. Ara l'aplicació està autoritzada a utilitzar el seu propi compte!

Bibliografia addicional

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2