Kategorija: OAuth Tutorial

Objavljeno

PKCE, ili zašto vam ne treba Implicit

Ne koristite Implicit grant, jer – ne morate više. I jer tako preporučuje IETF i Oauth 2.0 Security Best Current Practice dokument.
Implicit grant je prvobitno zamišljen kao zaobilazno rješenje tj. kompromis, kako bi se omogućilo browser baziranim klijentima korištenje OAuth protokola. Sa novim preporukama IETF-a početkom 2019, umjesto Implicit sugerira se korištenje Authorization Code grant ili Authorization Code with PKCE. To ne znači da je Implicit grant postao manje siguran (jer nikad i nije bio siguran kao Authorization Code, već samo prihvatljiv) i da treba automatski switchati stare aplikacije na novo rješenje. Ali preporuka je da se nove aplikacije više ne zasnivaju na ovom toku, a vrlo vjerovatno će u dogledno vrijeme biti izbačen iz OAuth standarda.

Nastavi čitati “PKCE, ili zašto vam ne treba Implicit”
Objavljeno

OAuth Implicit Grant

Prije nego što napišem članak kojim ću pojasniti zašto više ne treba koristiti Implicit Grant u novim aplikacijama, potrebno je ipak da ukratko opišem sam ovaj flow. Što se tiče odluke koristiti ili ne, za sada neću ulaziti u detalje – ono što je ključno napomenuti je da je sam grant nastao kao kompromisno rješenje, kako bi i Client Side Java Script aplikacije mogle koristiti Oauth.
Razlozi za korištenje ovog kompromisa su sada prestali i za nove aplikacije se preporučuje Authorization Code Flow sa PKCE proširenjem, a Implicit ostaje kao “obsolete” – i dalje funkcionira isto i ne mijenja se ništa po pitanju sigurnosti, ali nove aplikacije ne treba graditi na ovom grantu.

Nastavi čitati “OAuth Implicit Grant”
Objavljeno

Authorization Code Grant

Izvor Sanice

Code Authorization Grant je jedan od najsigurnijih u OAuth-u, ali nije praktičan za sve primjene. Njegova orijentiranost na server-side web aplikacije je ujedno njegova najveća prednost, ali i najveće ograničenje.

Prednost se ogleda u tome što token nikada ne ide do korisnika (browser) – već se čuva na strani client aplikacije koja se nalazi hostana na serveru. Ova terminologija može biti zbunjujuća na prvi pogled – jer govorimo o server side klijentskoj aplikaciji.

Nastavi čitati “Authorization Code Grant”
Objavljeno

Resource Owner Password Credentials Grant

Ovaj flow je veoma jednostavan, ali vrlo ograničen i namijenjen za specifične slučajeve korištenja.
Njegove odlike su:

  • Username i password šalju se kao dio requesta
  • To znači da Client (aplikacija) ima pristup istima, tj. prije pravljenja requesta, korisnik (Resource Owner) daje Client aplikaciji iste (za razliku od ostalih scenarija gdje se korisnik autenticira na Authorization (OAuth) Serveru.
  • Ovaj flow je jako nesiguran i može se koristiti samo u slučajevima kada se potpuno vjeruje Client aplikaciji i ni jedan drugi flow nije moguć. Npr. kompanija koja razvija API za Resource Server, ujedno razvija i klijenstsku aplikaciju koja konzumira taj API.
Nastavi čitati “Resource Owner Password Credentials Grant”
Objavljeno

OAuth sažeto

Nekoliko OAuth činjenica

  • OAuth je otvoreni standard za autorizaciju / delegiranje ovlasti između aplikacija i servisa na internetu.
  • OAuth standard održava Internet Engineering Task Force (IETF).
  • Trenutna verzija je 2.0, a oficijelna specifikacija data je u RFC 6749.

Problem koji OAuth rješava ogleda se u tome da omogući internet korisnicima da odobre pristup aplikacijama i web stranicama pristup njihovim podacima na drugim sajtovima i servisima, ali na način da tim aplikacijama ne ustupe svoje kredencijale (password).

Zašto je potreban Oauth?

Kao što se može zaključiti iz gore navedenog, bez Oauth-a korisnici bi, u slučaju da trebaju omogućiti pristup nekoj “third-party” aplikaciji ili web stranici, pristup njihovim podacima/informacijama/accountu na nekom servisu (Facebook, Google ili bilo šta drugo) – morali toj aplikaciji ustupiti password kako bi ista operirala u njihovo ime i imala pune ovlasti nad servisom.

Nastavi čitati “OAuth sažeto”