IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

Oauth logo

Oauth és un protocol que permet l'autorització segura d'una forma simple i estandard per a aplicacions web, mòbils o d'escritori.

An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.
https://aaronparecki.com/2012/07/29/2/oauth2-simplified

Introducció

OAuth és un estàndard obert per autorització. OAuth proporciona a les aplicacions client un accés segur delegat a recursos d'un servidor en nom/amb el permís del propietari dels recursos (en anglès on its behalf) . Especifica un procés per tal que els propietaris d'un recurs puguin autoritzar a tercers l'accés a recursos del servidor sense compartir les seves credencials d'accés.

Oauth està dissenyat per treballar esencialment amb el protocol Hypertext Transfer Protocol (HTTP). Oauth esencialment permet la creació per part de servidors d'autorització de tokens d'accés que poden ser utilitzats per clients de tercers amb l'aprovació del propietari dels recursos.

L'ús més habitual de Oauth és el que permet als usuaris d'Internet entrar en pàgines web utilitzant Google, Facebook, Twitter o altres comptes sense preocupar-se de compartir aquestes credencials

OAuth és un servei complementari i per tant diferent a OpenID.

Comparació amb valet keys

TODO

Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone. Regardless of the restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.

As the web grows, more and more sites rely on distributed services and cloud computing: a photo lab printing your Flickr photos, a social network using your Google address book to look for friends, or a third-party application utilizing APIs from multiple services.

The problem is, in order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else – often the same passwords used for online banking and other sites – it also provides these application unlimited access to do as they wish. They can do anything, including changing the passwords and lock users out.

OAuth provides a method for users to grant third-party access to their resources without sharing their passwords. It also provides a way to grant limited access (in scope, duration, etc.).

For example, a web user (resource owner) can grant a printing service (client) access to her private photos stored at a photo sharing service (server), without sharing her username and password with the printing service. Instead, she authenticates directly with the photo sharing service which issues the printing service delegation-specific credentials.

Protocol Flow

Terminologia i arquitectura

La idea principal és proporcionar una alternativa a "Traditional client-server authentication model":

Traditional client server authentication model.jpg

Amb aquest sistema no és fàcil proporcionar accés limitat a tercers als recursos de comptes d'usuari com Facebook o Google. Vegem els nous conceptes i el model proposat per resoldre aquest problema:

Client, Server, i Resource Owner (propietari dels recursos)

Afegim un tercer rol al model client servidor i redefinim cada rol:

Oaut-terminology2.png
  • Client (consumer): El client és qui vol utilitzar els recursos del servidor en nom d'un tercer (el propietari dels recursos). Un exemple de client pot ser una aplicació web com per exemple Wordpress. En la especificació original aka consumer
  • Servidor (service provider): És qui manté els recursos. Un exemple de servidor pot ser Google que vol proporcionar accés a les dades del propietari dels recursos per part de Wordpress. . En la especificació original aka service provider
  • Propietari dels recursos/resource owner (user): en broma tmabé se l'anomena OAuth Love Triangle. . En la especificació original aka user
Més info a: http://es.slideshare.net/alvarosanchezmariscal/authentication-for-microservices

Aquest tres rols estan presents en qualsevol transacció OAuth tot i que en alguns casos client i propietari dels recursos són el mateix. Aquest format és diferent a:

Oaut-terminology3.png

Aquest tipus de model acaba provocant que per exemple una aplicació web client com Wordpress tingui dos parts o front-ends un executant-se al propi Wordpress i un altre al servidor (Google). The resource owner is interacting with one part of the client application while the server is receiving requests from another part. However, no matter what internal architecture the client uses, it is still acting as a single entity and on behalf of the resource owner:

  • Protected Resources: A protected resource is a resource stored on (or provided by) the server which requires authentication in order to access it. Protected resources are owned or controlled by the resource owner. Anyone requesting access to a protected resource must be authorized to do so by the resource owner (enforced by the server). A protected resource can be data (photos, documents, contacts), services (posting blog item, transferring funds), or any resource requiring access restrictions. While OAuth can be used with other transport protocols, it is only defined for HTTP(S) resources.
  • 2-Legged, 3-Legged, n-Legged: el nombre de potes fa referència al nombre de participants. Quan tenim un client, un server i un resource owner parlem de 3-legged. Quan el client també és el resource owner (acuant en nom d'ell mateix) parlem de 2-legged. n-legged fa referència a clients delegant permisos a altres clients (re-delegation).
  • Credentials i Tokens: OAuth utilitza tres tipus de credencials:
  • Client credentials: Les credencials de client s'utilitzen per autenticar el client. This allows the server to collect information about the clients using its services, offer some clients special treatment such as throttling-free access, or provide the resource owner with more information about the clients seeking to access its protected resources. En alguns casos aquestes credencials no són de confiança i només es poden utilitzar com a simple informació. aka consumer key and secret
  • Temporary credentials: The OAuth authorization process also uses a set of temporary credentials which are used to identify the authorization request. In order to accommodate different kind of clients (web-based, desktop, mobile, etc.), the temporary credentials offer additional flexibility and security. aka request token and secret
  • Token credentials: Inclouen:
  • Token identifier:normalment (però no sempre) un random string of letters and numbers that is unique, hard to guess,
  • secret: protegeix en token de ser utilitzat per usuaris no autoritzats. Les Token credentials normalment estan limitades en la seva duració i àmbit d'aplicació (scope) i poden ser revocades en qualsevol moment pel propietari dels recursos. Un propietari pot tenir múltiples token credentials per a múltiples clients i aquest han de ser independents entre elles (si es revoca un token no afecta a la resta). Les Token credentials s'utilitzen com a reemplaçament de l'usuari i paraula de pas del propietari dels recursos. En comptes de tenir que compartir les credencials del propietari dels recursos amb el client, el propietari autoritza al servidor a utilitzar una classe especial de credencials to the client which represent the access grant given to the client by the resource owner. The client uses the token credentials to access the protected resource without having to know the resource owner’s password. aka access token and secret

NOTA: Fixeu-vos que cada credencial té un part a la que anomenem secret. El secret utilitza criptografia simètrica (symmetric shared secret). Això vol dit que tant el client com el servidor han de tenir accés a aquest secret compartit


Recursos:

Oauth versus OpenId

Oauth NO és un authentication framework (framework d'autenticació) i si que ho són en canvi OpenID i OpenID Connect

OpenID està relacionat amb l'autenticació ( authentication i en canvi OAuth està relacionat amb l'autorització (authorisation) without having to deal with the original authentication.

OAuth roles

overview-roles.png

  • Resource Owner: és la entitat amb capacitat per a concedir accés a un recurs protegit al ser com diu el seu nom el propietari del recurs. Quan es tracta d'una persona també se l'anomena end-user o simplement usuari. L'accés de l'aplicació als recursos de l'usuari estaran limitats per l'scope indicat (per exemple read o write access però els scopes es poden personalitzar).
  • Resource Server: el servidor on s'hostatgen els recursos protegits i que té la capacitat de servir aquests recursos mitjançant l'ús de Access tokens
  • Client Application: aplicació que realitza peticions d'accés a recursos compartits en nom del propietari del recurs (resource owner) i amb la seva autorització. Atenció amb el terme client per que no vol dir que l'aplicació hagi de ser client-side pot ser aplicació de qualsevol tipus la paraula client fa referència a que és client del servidor de recursos.
  • Authorization Server: el servidor que proporciona tokens d'accés a l'aplicació client després d'autenticar al propietari del recurs i obtenir la seva autorització.

Qüestions a tenir en compte:

  • OAuth no especifica (com es diu en anglès " is beyond the scope of this specification") la interacció entre el resource server i l'authorization server. Sovint solen ser la mateixa màquina però poden ser màquines separades i de fet un sol servidor d'autorizació pot donar servei a múltiples servidors de recursos

Resources:

Registre de l'aplicació client

Abans de poder utilitzar Oauth en aplicacions clients s'ha de registrar prèviament l'aplicació al servidor d'autenticació (la majoria de APIs tenen al profile de l'aplicació un apartat per a developers on podeu registrar el client). LEs dades demanades són:

Un cop registrar us proporcionaran les següents dades anomenades client credentials:

  • Client identifier: es tracta d'un string que identifica al client i que és públic (es pot compartir la informació sense problemes de seguretat)
  • Client secret: s'utilitza per autenticar l'aplicació client i s'ha de mantenir com a informació privada/confidencial (només han de compartir l'API i l'aplicació)

Abstract Protocol Flow

El diagrama general és:

abstract_flow.png

  • L'aplicació demana a l'usuari autorització per tal d'accedir als recursos (Authorization Request)
  • Si l'usuari permet l'accés aleshores es proporciona a l'usuari un authorization grant
  • L'aplicació demana un access token al servidor d'autorització utilitzant l'authorization grant proporcionat pel propietari del recurs.
  • Si la identitat de l'aplicació és autenticada i el grant és vàlid es proporciona un access token a l'aplicació. L'autorizació s'ha completat en aquest punt
  • Ara l'aplicació ja pot demanar l'accés a recursos protegits utilitzant l'access token

Aquesta és la idea general, als següents apartat veurem les modificacions i detalls segons el tipus de grant

Redirect URI vs Callback URL

Tot i que sovint al registrar el client utilitzem indistintament les dos paraules, és a dir Redirect URI o Callback URL cal tenir en compte que hi ha diferències subtils:

  • Callback URL: és tracta d'una URL que serà cridada mitjançant una petició HTTP Request des del servidor d'autenticació a l'aplicació client (vegeu OAuth Roles). Per tant es tracta d'una petició HTTP completa i cal que l'aplicació client implementi l'escolta d'aquesta petició (i per tant funcionarà com a servidor HTTP). S'utilitza per tant en aplicacions client Ouath que s'executen en servidors web (atenció a l'ús de la terminologia client en OAuth!). Els access tokens en aquest tipus de URLs es passen a l'aplicació client utilitzant query string. Exemple:
http://myserver.app/auth/callback?access_token=ACESS_TOKEN_HERE
  • Redirect URI: es tracta d'una URL a la que el servidor d'autenticació reenviarà al client i per tant s'utilitza una HTTP redirection i per tant és l'aplicació client la que fa una petició al servidor d'autenticació a partir de la redirecció. S'utilitza (observeu que no podem utilitzar Callback URL) en aplicacions client que s'executen als navegadors com aplicacions híbrides o apps web. Els access tokens en aquest tipus de URLs es passen a l'aplicació client utilitzant fragments de la URL. Exemple:
http://localhost/auth/callback#access_token=ACESS_TOKEN_HERE

Grants

Si heu llegit l'apartat anterior Abstract Protocol Flow hauren viste que els 4 primers passos fan referència a com obtenir l'autorizació de l'usuari i el token d'accés això ho anomenem grant. Segons com fem aquests passos amb Oauth parlarem de diferents grant types. Els grants de OAuth són:

  • Authorization Code: és possiblement el flow més conegut de OAuth i s'utilitza quan volem permetre a desenvolupadors d'aplicacions de tercers accedir a informació protegida de la nostra aplicació. L'aplicació client ha d'obtenir l'autorització de l'usuari de la nostra aplicació per tal d'accedir a les dades. Moltes APIs populars com Facebook o Gmail utilitzen aquest tipus de grant. Aquest procés també se'l sol anomenar 3-Legged OAuth i s'utilitzen tant Authorization Tokens com Access tokens.
  • Implicit Grant: és similar al grant authorization code excepte que no s'utilitza l'authorization token sinó que directament es retorna l'acess token de forma que ens evitem el tercer pas del grant Authorization Code. A priori sembla més útil/segur el Authorization Code grant però aquest sistema és útil en aplicacions de Frontend com aplicacions javascript que s'executen al navegador.
  • Resource Owner Password Credentials Grant: This grant is suitable when dealing with the client that we trust, like a mobile app for our own website. In this case, the client sends the user's login credentials to the authorization server and the server directly issues the access token.
  • Client Credentials Grant: This grant is useful when the Client/App is the resource owner and no user interaction is required (machine to machine communication). For example, if the app wants to show a catalog to the user or store some data related to the app on the server.
  • Refresh token grant: When the server issues an access token, it also sets an expiry for the access token. Refresh token grant is used when we want to refresh the access token once it is expired. In this case, authorization server will send a refresh token while issuing the access token, which can be used to request a new access token. Note that this flow is not available when using Implicit Grant.
Laravel Passport supports all of the above grants except implicit grant.

Authorization Code: used with server-side Applications Implicit: used with Mobile Apps or Web Applications (applications that run on the user's device) Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself Client Credentials: used with Applications API access

Resources:


La variable:

response_type

Se sol utilitzar per identificar el tipus de grant que volem utilitzar

Authorization Code grant

Diagrama:

auth_code_flow.png

Pas 1. L'aplicació client utilitza un Authorization Code link:

Un exemple URL amb digital ocean cloud API:

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

On:

  • client_id: Obtingut al registre previ de l'aplicació.
  • redirect_uri: URL que hem indicat nosaltres prèviament durant el registre de l'aplicació
  • scope: Scope de Oauth que limita l'accés al recurs protegit. Vegeu OAuth scopes

IMPORTANT: Observeu que al redirect_uri passem una URL de Callback. La terminologia no és gratuita ja que es tracta d'una URL que haurem d'implementar a la nostra aplicació serve side (per exemple amb una URL i ruta dedicada a la nostra app Laravel). Serà el servidor el que executarà aquesta URL i els desenvolupadors els responsables d'executar el codi que correspongui quan el servidor cridi aquesta URL. En el cas de l'implicit grant la cosa no funcionarà d'aquesta manera ja que tindrem en canvi una redirecció HTTP a una URI per que de fet la nostra aplicació client serà una aplicació de frontend és a dir s'executarà al navegador i no pas al client

Pas 2. Usuari autoritza l'aplicació

El servidor Oauth mostra un formulari demanant permís a l'usuari per accedir a les dades. Es mostrarà la informació de l'aplicació client a la que es vol donar permís, els scopes/permisos que demana i normalment la URL/pàgina web de l'aplicació client. El resource-owner pot denegar o permetre la petició. Si denega s'acaba el procés. Si pemet passem al pas 3.

El pas 2 és comú/idèntic a implicit grant i code grant

authcode.png

Pas 3. L'aplicació rep el codi d'autorització

Vegem una exemple d'URL de callback (aplicació exemple anomenada dropletbook):

https://dropletbook.com/callback?code=AUTHORIZATION_CODE

Qüestions a tenir en compte:

  • Observeu la recomanació d'ús https per assegurar confidencialitat de les dades transportades
  • Es tracta d'una petició HTTP de tipus request (HTTP Request) creada pel servidor d'autorització cap a la URL de la nostra aplicació. Observeu com això no és aplicable a aplicacions purament javascript
  • El codi d'autorització (authorization token) forma part de la HTTP_REQUEST ja que forma part de la URI,vegeu petició amb httpie:
$ http -v http://localhost:8000/callback?code=AUTHORIZATION_CODE 
GET /callback?code=AUTHORIZATION_CODE HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: localhost:8000
User-Agent: HTTPie/0.9.2

Step 4: Application Requests Access Token

L'aplicació client demana un Access Token

https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

On:

  • client_id: Obtingut al registre previ de l'aplicació.
  • client_secret: Obtingut al registre previ de l'aplicació. Observeu que al ser una aplicació server_side podem assegurar que aquesta dada sigui confidencial.
  • grant_type: Indiquem el tipus de grant per al cas estem veient el valor vàlid és grant_type=authorization_code
  • code: el authorization token obtingut al pas previ
  • redirect_uri: un altre cop s'envia la URL de la nostra aplicació servidor.

IMPORTANT: La resposta del servidor no serà executar cap URL nostra sinó una HTTP Response amb les dades que ens interessen com l'access token i si s'escau un refresh token

Per que s'envia un altre copa aquesta informació ([1]) al pas previ ok la necessitem per a constestar i a més el servidor pot comprovar que la URL a la que reenviem és la mateixa amb la que ens hem registrat

Step 5: Application Receives Access Token:

Exemple de reposta rebuda en format JSON:

{ 
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{"name":"Mark E. Mark",
"email":"mark@thefunkybunch.com"}}


Si el pas anterior és vàlid (l'autorització ha finalitzat correctament) l'API (observeu l'ús de la paraula API, normalment fa referència al codi que implementa tant el servidor d'autorizació com el servidor de recursos és a dir dos rols OAuth al mateix temps)

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}} Now the application is authorized! It may use the token to access the user's account via the service API, limited to the scope of access, until the token expires or is revoked. If a refresh token was issued, it may be used to request new access tokens if the original token has expired.

Implicit Grant

aka user agent flow

Implicit Grant vs Authorization Code grant

NOTA: és important entendre i conèixer els rols/entitats que participen en una comunicació OAuth. Vegeu OAuth roles

La majoria de implicacions i comparacions entre un sistema i l'altre són de seguretat. Alguns links interessants a tenir en compte són:

https://tools.ietf.org/html/rfc6749#section-10.3
https://tools.ietf.org/html/rfc6749#section-10.16

Tinguem en compte algunes suposicions prèvies:

  • L'ús de de SSL/HTTPS s'ha de considerar obligatori si volem tenir un nivell de seguretat acceptable pel que fa a la confidencialitat de les dades i és l'única forma d'evitar intercepcions per part de tercers (atacs Man in the Middle). De fet no només cal utilitzar SSL sinó que a més cal utilitzar-lo correctament (no utilitzar certificats autosignats, sincronització de l'hora als servidors, etc)
  • SSL/HTTPS: només garanteix confidencialitat versus tercers. Cal tenir en compte uns participants especials amb Oauth que són l'usuari i l'aplicació client (rols resource owner i client application). Per qüestions de seguretat hi ha certa informació que no s'ha de compartir amb aquests rols. Veiem quina i en quina casos:
  • En general el criteri és no compartir informació confidencial referent a un rol amb altres rols. Exemples:
  • Informació confidencial de l'aplicació client com el client secret (paraula de pas per autenticar el client). Aquesta informació només ha de ser coneguda per l'aplicació client i pel servidor d'autenticació i per tant mai ha de ser compartida amb els usuaris/resource owners ni tampoc hi ha cap raó per compartir-la amb el resource-server (tot i que en el cas de que el resource server i l'authorization server siguin el mateix servidor pel cas és el mateix ja que els propietaris del servidor podran accedir a les dades de tots "dos servidors")
  • Cal tenir en compte dos tipus d'aplicacions clients:
  • Aplicacions server side: el client no té accés al codi font
  • Aplicacions client side: l'usuari de l'aplicació i altres aplicacions executant-se al mateix client tenen accés al codi del servidor i per tant no es pot considerar les dades guardades al codi com a dades confidencials (excepte que estiguin xifrades com passa amb JWT). Fins i tot en el cas que estiguin xifrades no podem evitar que un tercer les utilitzi per suplantar identitat. Per exemple un access token xifrat és segur a nivell de confidencialitat (no compartim el token) però no és segur pel que fa a una possible suplantació d'identitat). Com podeu observar doncs en aquests casos és molt complicat l'ús 100% segur d'access tokens. Aquesta és la raó per la que el grant type implicit grant no proporciona refresh tokens i es recomana limitar en aquest cas la validesa/el temps de vida dels access tokens per exemple limitant-los a un sol ús (un sol token) per sessió i per tant l'usuari s'ha de tornar a autenticar per tal d'obtenir un nou token a la propera sessió.
  • Tot i ser altament recomanable utilitzar SSL hi haurà casos en que no serà possible utilitzar-lo per la dificultat d'implementar un servidor SSL segur. Un exemple és quan utilitzem una aplicació client en navegador i estem utilitzant implicit grant. En el cas de tenir una aplicació client de front-end pur en Javascript mirem de veure el problema que ens trobaríem al intentar implementar Authorization Code grant. Amb grant de tipus code (Authorization Code) hi ha un moment que el servidor d'autenticació envia una petició a l'aplicació client amb el codi d'autorització i tindrem diversos problemes:
  • Al tractar-se d'una aplicació client en navegador estes aplicacions són elles les que realitzen peticions (PULL) i no pas les que les reben, de fet ja ho diu el seu nom són aplicacions client i no pas servidors. Aquesta és una raó per no utilitzar authorization code grant en aquests casos. Fixeu-vos que implicit grant el que fa és en canvi fer una redirecció del client cap a una URL pròpia del client i no pas una connexió directa servidor autorització - aplicació client. També si us fixeu implicit grant posa l'access token a la URL però en un fragment (vegeu article sobre URLs) i no pas a la Query String ja que es considerà el fragment una part utilitzada només pels clients
  • Cal tenir en compte que el problema anterior podria tenir una solució que és utilitzar websockets o similar per implementar model Push al client. Però aleshores tindrem un altre problema: com fem que la connexió sigui SSL? També podem solucionar utilitzant WSS (Web sockets segurs). En tot cas fitxeu-vos que introduïm un nivell de complexitat important.
  • Oauth proporciona algunes ajudes per millorar la confidencialitat en aquests casos i evitar la intercepció de dades per part de tercers (Man in the middle)

Amb Implict Grant l'Access Token s'entrega al client com a part de la URI. TOTS els Access tokens s'han de transportar via SSL/HTTPS amb qualsevol tipus de grant per evitar intercepcions però a més cal destacar una diferència important entre Authorization Code grant i Implicit Grant

  • Authorization Code grant: la comunicació entre aplicació client i servidor d'autenticació és realitza server-to-server és a dir les dos aplicacions són aplicacions de servidor a les quals l'usuari no hi té accés ni tampoc l'user-agent (típicament el navegador) ni tampoc altres aplicacions executant-se al mateix client. En aquest cas les credencials del client (id de client i el secret) no es comparteixen amb l'usuari, ni amb el navegador ni amb altres aplicacions executan-se al navegador. Aquestes dades només es comparteixen entre el servidor d'autenticació i el servidor on s'executa l'aplicació client (i és només el desenvolupador i no pas els usuaris de l'aplicació qui coneix aquestes dades)
  • Implicit Grant: En el cas que l'aplicació client s'executi al navegador si utilitzem Authorization Code grant estarem compartint amb l'usuari, amb el navegador ( i potencialment amb altres aplicacions executant-se al mateix navegador) les credencials del client i a més l'access token que haurien de ser dades confidencials només compartides entre aplicació client (developer) i servidor autorització. En aquest cas no és recomanable guardar aquestes dades al client (ni amb cookies ni Local Storage ni de fet amb cap altre sistema) per que no les podrem considerar segures. Per aquesta raó Per tant en aplicacions de servidor no és recomanable utilitzar aquest grant millor utilitzar l'authorization code grant.

Resource Owner Password Credentials

Amb Resource Owner Password Credentials l'usuari o Resource owner proporciona les seves credencials (usuari i paraula de pas) directament a l'aplicació client (normalment preguntant a l'usuari mitjançant un formulari) i s'obté directament un access token. Vegem un exemple:

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

On:

  • grant_type=password indica un Resource Owner Password Credentials
  • username i password són les credencials de l'usuari
  • client_id: identifica el client

IMPORTANT: En aquest tipus de Grant l'aplicació client ha de ser de confiança per exemple una aplicació client pròpia per tal d'evitar que aplicacions de tercers puguin obtenir les credencials dels nostres usuaris. Mai s'han d'emmagatzemar les credencials de l'usuari a l'aplicació client ja que aquestes només han d'estar al servidor d'autenticació

IMPORTANT: Observeu que és crida directament a auth/token URI, és a dir ens saltem la fase d'autorització per què aquesta ja està implícita al proporcionar les credencials de l'usuari

Amb Laravel Passport aquest tipus de Grant està suportat i s'anomena Password grant tokens:

https://laravel.com/docs/5.3/passport#password-grant-tokens

Client Credentials

És un grant que permet aconseguir un access token per modificar les credencials del client (útil per aplicacions client que poden modificar dades de clients elles mateixes sense haver d'accedir al servidor d'autenticació). Exemple:

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

Grant no suportat a Laravel Passport

Refresh token grant

Exemple a Laravel Passport

https://laravel.com/docs/5.3/passport#refreshing-tokens
$http = new GuzzleHttp\Client;

$response = $http->post('http://your-app.com/oauth/token', [
    'form_params' => [
        'grant_type' => 'refresh_token',
        'refresh_token' => 'the-refresh-token',
        'client_id' => 'client-id',
        'client_secret' => 'client-secret',
        'scope' => '',
    ],
]);

return json_decode((string) $response->getBody(), true);

Vegeu també Refresh Token

Exemples

http://tutorials.jenkov.com/oauth2/index.html

Javascript

Extreure tokens

var token = new URL("http://localhost:3000/_oauth/google#access_token=ya29.5HxuYol1Io8JLeGePDznbfkkwu_PC4uodKwG8_1clFYAn9AgdOV1WGpOTNQP3s76HAsn7Y4zWw&token_type=Bearer&expires_in=3600").hash.split('&').filter(function(el) { if(el.match('access_token') !== null) return true; })[0].split('=')[1];

alert(token);
var extractToken = function(hash) {
      var match = hash.match(/access_token=([\w-]+)/);
      return !!match && match[1];
    };

s

Extract token from redirect_uri (OAUH implicit grant)

http://stackoverflow.com/questions/11440398/how-do-i-implement-secure-oauth2-consumption-in-javascript/11519124

<script type="text/javascript" charset="utf-8">
  $(function () {
    var extractToken = function(hash) {
      var match = hash.match(/access_token=([\w-]+)/);
      return !!match && match[1];
    };

    var CLIENT_ID = YOUR_CLIENT_ID;
    var AUTHORIZATION_ENDPOINT = "https://soundcloud.com/connect";
    var RESOURCE_ENDPOINT = "https://api.soundcloud.com/me";

    var token = extractToken(document.location.hash);
    if (token) {
      $('div.authenticated').show();

      $('span.token').text(token);

      $.ajax({
          url: RESOURCE_ENDPOINT
        , beforeSend: function (xhr) {
            xhr.setRequestHeader('Authorization', "OAuth " + token);
            xhr.setRequestHeader('Accept',        "application/json");
          }
        , success: function (response) {
            var container = $('span.user');
            if (response) {
              container.text(response.username);
            } else {
              container.text("An error occurred.");
            }
          }
      });
    } else {
      $('div.authenticate').show();

      var authUrl = AUTHORIZATION_ENDPOINT + 
        "?response_type=token" +
        "&client_id="    + clientId +
        "&redirect_uri=" + window.location;

      $("a.connect").attr("href", authUrl);
    }
  });
</script>

Recursos:

Aplicació PHP demo

Passos Workflow:

OAuthDiagram.png

http://www.sitepoint.com/creating-a-php-oauth-server/

Es poden veure tots els passos provant aquesta aplicació (inclús alguns passos que normalment no es veuen directament en casos reals, és a dir que és fan en segon terme sense la intervenció de l'usuari)

http://brentertainment.com/oauth2/

Llenguatjes de programació i plataformes

A la documentació oficial hi ha bones referències:

http://oauth.net/code/

PHP

Implementación per aplicacions client:

De la web de oauth.net:

  • oauth2-server: https://github.com/thephpleague/oauth2-server . Alex Bilbie has written an OAuth 2.0 server which supports the main specification grants for authorisation, and can be used to secure an API with OAuth 2.0 access tokens.
  • Extensió de PHP: Utilitza pecl. There is an extension to PHP that supports OAuth. It was written by John Jawed. An example can be found here and a walkthrough is also available. This pecl package is

considered the de facto standard by Rasmus Lerdorf (creador de PHP).

Laravel

Vegeu Laravel Passport que utilitza:

https://github.com/thephpleague/oauth2-server

Android

Oauth Android

Documentació

Proveidors oauth

Podeu veure exemples a la web de http://opauth.org/ a l'apartat Strategies:

Repositoris Github:

Veure com funciona:

http://opauth.org/auth/facebook
http://opauth.org/auth/google
http://opauth.org/auth/twitter

OAuth google

Oauth twitter

twitter : http://www.androidhive.info/2012/09/android-twitter-oauth-connect-tutorial/

https://dev.twitter.com/oauth

Oauth facebook

Facebook access Tokens:

https://developers.facebook.com/docs/facebook-login/access-tokens

Info sobre OAuth a facebook:

https://developers.facebook.com/docs/reference/dialogs/oauth/

Cal registrar-se com a desenvolupador a:

https://developers.facebook.com/apps/

I afegir una nova APP

Seguiu els passos de :

http://blog.doityourselfandroid.com/2011/02/28/30-minute-guide-integrating-facebook-android-application/

Recursos:

Desenvolupament APIs

REST API

http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

Versions

OAuth 2.0

Even though the name suggests its the next version of OAuth, the whole structure has changed radically and cannot even be considered a new version. OAuth2 is a complete new way of authentication which is easier to implement and maintain. However, OAuth2 is not officially a standard yet, although many sites and organizations are using the current drafts.


OAuth hybrid apps

Vegeu OAuth hybrid apps

Vegeu també

Enllaços externs