OAuth2 Explained: Part 3 – Using OAuth2 With Your Bare Hands

• Part 1 – Principles and Terminology
• Part 2 – Setting up OAuth2 with Symfony2 using FOSOAuthServerBundle
• Part 3 – Using OAuth2 with your bare hands
• Part 4 – Implementing Custom Grant Type
• Part 5 – Implementing OAuth2 Client with Symfony2

Preparations

We’ll need a controller that mimics a dummy API behavior for us.

<?php namespace Acme\DemoBundle\Controller; use Symfony\Bundle\FrameworkBundle\Controller\Controller; use Symfony\Component\HttpFoundation\JsonResponse; class ApiController extends Controller { public function articlesAction() { $articles = array('article1', 'article2', 'article3'); return new JsonResponse($articles); } public function userAction() { $user = $this->container->get('security.context')->getToken()->getUser(); if($user) { return new JsonResponse(array( 'id' => $user->getId(), 'username' => $user->getUsername() )); } return new JsonResponse(array( 'message' => 'User is not identified' )); } }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

<?php   namespace Acme\DemoBundle\Controller;   use Symfony\Bundle\FrameworkBundle\Controller\Controller; use Symfony\Component\HttpFoundation\JsonResponse;   class ApiController extends Controller {     public function articlesAction()     {         $articles = array('article1', 'article2', 'article3');         return new JsonResponse($articles);     }       public function userAction()     {         $user = $this->container->get('security.context')->getToken()->getUser();         if($user) {             return new JsonResponse(array(                 'id' => $user->getId(),                 'username' => $user->getUsername()             ));         }           return new JsonResponse(array(             'message' => 'User is not identified'         ));       } }

Let’s Fail!

Please keep in mind, that the point is to obtain access_token.

Why? Request

What?

Right. That’s why. Our API is protected, we don’t let everybody in. Let’s try to do this again once we have the access_token at the end of the chapter.

Registering OAuth Client

First we need to create a Client and allow all possible grant types for it. Here’s how to do that. Navigate to the project root of the provider (the one we created in previous part) and then execute the following command. Client host represents a URL, where your client application is deployed. You will get redirected here if everything went as planned.

command should respond with something like

Please keep those values somewhere in an easy accessible place, we will need those during this tutorial. To keep URLs short and readable I’ll refer to those as CLIENT_ID and CLIENT_SECRET in the future.

Let’s start from the more complicated grant types and move on to the simpler ones.

Authorization Code

That’s the most commonly used one, recommended to authorize end customers. A good example is the Facebook Login for websites. Here’s how it works.

Request this url in the browser:

note: redirect_uri should be identical to the one provided on client creation, otherwise you will get a corresponding error message.

The page you are requesting will offer you a login, then authorization of the client permissions, once you confirm everything it will redirect you back to the url you provided in redirect_url. In our case, redirect will look like

I’ll refer to this long code parameter as CODE in the future. This code is stored on the Provider side, and once you request for the token, it can uniquely identify the client which made request and the user.

It’s time to request the token

Most probably this request will fail. That’s because CODE expires rather quickly. Fear not, just request first URL, repeat the process, prepare the second url in the text editor of your choice, copy in the code rather quickly, and you will get the desired result.

It’s a JSON which contains access_token and looks like this

this suggests that access_token expires in 3600 seconds, and to refresh it you have the refresh token. We will discuss how to handle that later on this chapter.

Implicit Grant

It’s similar to Authorization Code grant, it’s just a bit simpler. You just need to make only one request, and you will get the access_token as a part of redirect URL, there’s no need for second response. That’s for the situations where you trust the user and the client, but you still want the user to identify himself in the browser.

then you will get redirected to

Password flow

Let’s say you have no luxury of redirecting user to some website, then handle redirect call, all you have is just an application which is able to send HTTP requests. And you still want to somehow authenticate user on the server side, and all you have is username and password.

Request:

Response:

 

Client Credentials

This one is the most simplistic flow of them all. You just need to provide CLIENT_ID and CLIENT_SECRET.

Response will be

Refresh flow

Before I mentioned that access_tokens have a lifetime of one hour, after which they will expire. With every access_token you were provided a refresh_token. You can exchange refresh token and get a new pair of access_token and refresh_token

response

 

Let’s not fail or using the access_token

Remember our failed attempt to request an API at the beginning of the article? Let’s try again.

Request

Response

Seems like a proper response, does it?

Let’s try the other request, which is supposed to maintain user session with the access_token.

Request

If you obtained your access_token through Authorization Code, Implicit Grant or Password, you should see a JSON representation of the user object.

If that was the Client Credentials, ACCESS_TOKEN doesn’t contain any user information association with it, therefore there can’t be any user information retrieved, as the response suggests

In the next part we will define a custom Grant type which allows us to retrieve access_token based on API Key.