Vlad's blog

In programming veritas

Posts Tagged ‘OAuth 2

OAuth 2 flows: Client flow

leave a comment »

Client flow is used solely for machine to machine communication, i.e. no Resource Owner involved. Client sends client_id and secret to Authorization Server and then receives access_token and refresh_token.

Client.png

This type of flow is usually used when Web application needs to access Web API.

Advertisements

Written by vsukhachev

December 3, 2015 at 2:51 am

Posted in Development

Tagged with

OAuth 2 flows: Resource Owner Credentials flow

leave a comment »

This type of flow is used when Resource Owner trusts the Client. Client might be mobile application, desktop application or browser application communicating with Web server. Device where Client is installed is trusted as well so user name and password can be stored on this device. In this flow Resource Owner enters user name and password in the UI provided by Client. Then Client sends POST request to Authorization server. The request contains entered user name and password.

Resource Owner Credentials Flow-1

Authorization Server responds with access_token and refresh_token.

Resource Owner Credentials Flow-2

access_token is included in each request that Client sends to Resource Server.

Resource Owner Credentials Flow-3

When access_token is expired Client can repeat this procedure, i.e. send user name and password and collect new access token or it can use refresh_token. Ideally Client should not store user credentials. Instead it should ask for user credentials once, collect refresh_token and then use it forever to obtain new refresh_token. access_token and refresh_token might be stored on a device.

Written by vsukhachev

December 3, 2015 at 2:51 am

Posted in Development

Tagged with

OAuth 2 flows: Implicit flow

leave a comment »

Implicit flow is probably the most common scenario. It is used when Client is mobile application (IOS, Android, Windows Phone) or native application or browser mobile application which wants to access resource on the behalf of Resource Owner.

Implicit Flow-1

Resource Server redirects application to Authorization Server. client_id identifies application, redirect_uri specifies Uri where Client will be redirected after authorization completed.

Implicit Flow-2

Then Authorization Server asks user to authorize. Depending on particular implementation (Google, Twitter, Facebook) the login screen might look different.

Google Login Screen

The next step is Consent screen where Resource Owner will be prompted to allow application to perform certain actions.

Google consent screen

When authorization is complete the Authorization Server executes redirect_uri passing access token and expiration interval.

Implicit Flow-3

Notice that access_token and expires_in are specified after pound character which assumes that they never passed to the Resource Server. So Client can extract access_token and include it in the next requests.

Implicit Flow-4

This flow does not use refresh token since this implies that user name and password must be stored on a device which can not be considered as secured. So user should periodically repeat the authorization procedure.

Written by vsukhachev

December 3, 2015 at 2:50 am

Posted in Development

Tagged with

OAuth2 flows: Authorization flow

leave a comment »

Authorization flow is usually used when Resourse Owner communicates with Web server which accesses another RESTful web service on behalf of the Resource Owner.
Authorization Flow-1
Client redirects Resource Owner to Authorization Server. In the url Client specifies client_id which is how Authorization Server identifies the Client. Assumed that Client was previously registered on the Authorization server. Also Client specifies redirect_uri which Authorization Server will use when Resource Owner authorization is complete.
Authorization Flow-2
Then Authorization Server asks user to authorize. Depending on particular implementation (Google, Twitter, Facebook) the login screen might look different.
Google Login Screen
The next step is Consent screen where Resource Owner will be prompted to allow application to perform certain actions.
Google consent screen
When authorization is complete the Authorization Server redirects Resource Owner back to the Client.
Authorization Flow-3
It passes code parameter but this is not a token yet. This code will be used by Client which will send a request to Authorization Server.
Authorization Flow-4
Authorization Server responds with access token, refresh token and expiration time in seconds.
Authorization Flow-5
So now Client can access Resource Server by using access token.
Authorization Flow-6
As you can see access token time life is very short. So when it is expired there are two options. Client can start this procedure over or use refresh token to request new access token.
So Authorization flow has the following features.

  • Used for server side applications
  • Resource owner never gets access token so it can not leak
  • If access token is expired it can be requested again using refresh token

Written by vsukhachev

November 15, 2015 at 3:28 am

Posted in Development

Tagged with

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