OAuth спецификацията леко преведена на Български

http://tools.ietf.org/html/rfc5849

При традиционнният модел на удостоверяване, клиента използва свойте потребител/парола за да достъпи ресурс който се намира на друг сървър. С добиването на популярност на на разпределеният web и could computing-a други апликации/клиенти могат да искат достъп до тези услуги намиращи се на сървъра на потребителят.
OAuth вкарва нова роля в модела - resource owner.
При OAuth модела, потребителят разрешава на клиента/апликация да достъпва неговите ресурси без да разкрива свойте потребител/парола, като използва http препратки.
Например а web потребител (RESOURCE OWNER) може да даде права на приложение за разпечатване на снимки (CLIENT) да достъпва неговите снимки които се намират на конректен service/SERVER без да разкрива свойте потребител/парола. За да го направи това, потребителят се удостоверява директно със своето хранилище на снимките, което от своя страна издава на приложението за разпечатване специални credentials.
За да може клиента да достъпи ресурса, той първо трябва да се сдобие с разрешение от собственика на ресурса. Това разрешение се изразява под формата на tocken и съответен shared-secret. С Тoken-а отпада необходимостта поребителят (собственик на ресурса) да споделя свойте  credentials с клиента. За разлика от нормалните ресурсни credentials, токените могат да имат срок на валидност, спецификация за достъп и да отпаднат мигновенно.

Тази спецификация се състои от две части. Първата дефинира логин на потребителят със сървъра използвайки редиректи през browser-а, с цел разрешаване на достъп на клиент до ресурс.
Във втората част се разглежда начин на пращане на заявки http, в които участват два пакета от credentials, едните идентифициращи клиента който прави заявката и вторите идентифициращи resource owner/потребителят от чието име се правят заявките.

client - HTTP client който може да праща OAuth заявки за authentication.
server - HTTP server който разбира OAuth заявки.
protected resource - защитетен ресурс който може да бъде достъпен от сървъра чрез OAuth-authenticated request
resource owner - Собственик на ресурса, управлява и достъпва ресурса чрез свойте credentials
credentials -  е двойка от уникален идентификатор и съответната shared secret. OAuth дефинира 3 вида класа credentials:
  client
  temporary
  token
използвани да идентифицират и autenticate клиента/приложението който прави заявката, завката за аутентикация и разрешението за достъп.

token -  уникален идентфикатор който се издава от сървъра и се използва от клиента/приложението за да се асоцират удобрените заявки с потребителят на ресурса. Който предварително се е одобрил или му се иска разрешението. Токените имат съответни shared-secret окито се използват от клиента/приложението за да удостоверят самият токен пред server-a.

Ето и другата използвана термионология:

Consumer: client
Service Provider: server
User: Resource owner
Consumer Key and Secret:  client credentials
Request Token and Secret:  temporary credentials
Access Token and Secret:  token credentials


Пример
Жана (user/resource owner) си е качила снимки (protected resource) на нейният сайт photos.net (server). Тя иска да изплзва printer.com (client/consumer)  да изпечата една от свойте снимки. Обикновенно Жана се логва във photos.net използвайки свойте user/pass.
Жана не иска да дава свойте user/pass на printer.com който трябва да изпечта снимката. Затова предварително printer.com иска/записва се/signed up за client credentials във photos.com

  Client Identifier
         dpf43f3p2l4k3l03

   Client Shared-Secret:
         kd94hf93k423kf44

printer.com знае как да използва API-то на photos.com който използват  "HMAC-SHA1" signature method

   Temporary Credential Request
         https://photos.example.net/initiate

   Resource Owner Authorization URI:
         https://photos.example.net/authorize

   Token Request URI:
         https://photos.example.net/token

Преди printer.com да поиска Жана да разреши достъп до снимките, трябва да вземе temporary credentials с photos.net за да може се идентифицира delegation request-a (препращането). За да го направи това клиента/приложението изпраща https заявка до server-a

    POST /initiate HTTP/1.1
     Host: photos.example.net
     Authorization: OAuth realm="Photos",
        oauth_consumer_key="dpf43f3p2l4k3l03",
        oauth_signature_method="HMAC-SHA1",
        oauth_timestamp="137131200",
        oauth_nonce="wIjqoS",
        oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
        oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

Сървъра валидира зявката и отговаря с двойка temporary credentials

     HTTP/1.1 200 OK
     Content-Type: application/x-www-form-urlencoded

     oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03&
     oauth_callback_confirmed=true

Клиента/приложението препраща Жана към сървъра на адреса Resource Owner Authorization endpoint за да може жана да се представи там и даде разрешение на клиента/приложението.

     https://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola

Сървъра иска от Жана да се логне с нейните потребител/парола и ако това стане я пита дали дава достъп до приложението/клиента printer.com. Жана разрешава и нейният броузър се връща на callbackURI -то което е зададено от клиента/приложението в предишнината заявка

    http://printer.example.com/ready?
     oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884

Callback заявката информира клиента/приложението, че жана е приключила с аутентикацията си. Клиента/приложението тогава изиска token credentials използвайки свойте temporoary credentials като използва SSL

  POST /token HTTP/1.1
     Host: photos.example.net
     Authorization: OAuth realm="Photos",
        oauth_consumer_key="dpf43f3p2l4k3l03",
        oauth_token="hh5s93j4hdidpola",
        oauth_signature_method="HMAC-SHA1",
        oauth_timestamp="137131201",
        oauth_nonce="walatlh",
        oauth_verifier="hfdp7dh39dks9884",
        oauth_signature="gKgrFCywp7rO0OXSjdot%2FIHF7IU%3D"

Сървъра валидира заявката и отговаря с token credentials

     HTTP/1.1 200 OK
     Content-Type: application/x-www-form-urlencoded

     oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00

Вече с новите token credentials, client/приложението е готово да взима снимките на жана

     GET /photos?file=vacation.jpg&size=original HTTP/1.1
     Host: photos.example.net
     Authorization: OAuth realm="Photos",
        oauth_consumer_key="dpf43f3p2l4k3l03",
        oauth_token="nnch734d00sl2jdk",
        oauth_signature_method="HMAC-SHA1",
        oauth_timestamp="137131202",
        oauth_nonce="chapoH",
        oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"

Сървъра photos.net валидира заявката и дава исканият ресурс. Следващите заявки стават чрез
получените token credentials докато Жана не се откаже.

2 Redirection Based Authorization

 OAuth използва токени за да удостовери ауторизацията на клиента от съответният потребител. Обикновенно token credentials се издават от сървъра по зяавка на потребителят след негов логин на сървъра /с user/pass/
Има много начини по които сървъра може да работи с token credential-ите. Тази секдиця дефинира един от начините чрез използването на http редиректи през browser-а на потребителят. Този метод включва три стъпки.

1. Клиента взима temporary credentials от сървъра, под формата на  identifier и shared secred. Temporray credentials се използват за да идентифицират
 и така нататък....нищо интересно не се случва...