Vlad's blog

In programming veritas

OAuth 2 flows: introduction

leave a comment »

This post starts series of posts dedicated to OAuth2 flows. But before we begin I would like to provide some background. First I want to say some words why we need OAuth2 and which problems it is supposed to solve.
OAuth 2.0 is open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.
Let’s start from the traditional example of using web forms authentication. In form authentication there are two roles: Browser and Server. Browser starts conversation by sending user name and password entered by user. Server authorizes this request and responds with authentication ticket representing user credentials. Browser saves the ticket in the users cookie collection and then sends this cookie in every request.
This approach works fine for browser based application but what about mobile application? Usually mobile applications don’t maintain collections of cookies. And described approach assumes that application is responsible for authentication and authorization. The scenario when user needs to create new password for every mobile application is not realistic. Today users prefer to use their Facebook or Google credentials to identify them-self. But this approach raises a question. Will user trust newly downloaded application to let it use his Facebook user name and password? The answer is obvious, no. So we came to the conclusion that authentication and authorization should be separated from application. And that is where federated security comes into play.

OAuth 2 roles

OAuth2 defines the following roles.

  • Resource Owner is a human that owns a resource on the Resource Server
  • Resource Server is the server hosting the protected resource
  • Client is an application making protected resource requests on the behalf of the resource owner
  • Authorization Server is the server that issues access tokens to the Client

The term Client does not refer to any particular implementation characteristics. For example Client can be mobile application or desktop application or server side application making requests to Web API.

OAuth roles

OAuth 2 flows


Written by vsukhachev

November 15, 2015 at 3:28 am

Posted in Development

Tagged with

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: