How Our OAuth2 Tokens Are Created

Now that we have installed FOSOAuthServer Bundle and given it a basic configuration, we will take a look at the Controller action that generates the Access Tokens.

One of the reassuring parts of the Bundle system that Symfony uses is that the third party bundles (such as FOSOAuthServer) all follow the same layout. This makes navigation around new bundles much easier.

The one difference that jumps out is that many third party Bundles, especially the [FOS Bundles], often use XML for configuration. This can make things a little trickier to follow if new to Symfony, as likely you are much more used to YAML files.

During our setup we were asked to add in two new entries to our Symfony Routing setup:

# app/config/routing.yml
fos_oauth_server_token:
    resource: "@FOSOAuthServerBundle/Resources/config/routing/token.xml"

fos_oauth_server_authorize:
    resource: "@FOSOAuthServerBundle/Resources/config/routing/authorize.xml"

If we go ahead and take a look at the routing file for fos_oauth_server_token, it looks like this:

<!-- vendor/friendsofsymfony/oauth-server-bundle/FOS/OAuthServerBundle/Resources/config/routing/token.xml -->
<?xml version="1.0" encoding="UTF-8" ?>

<routes xmlns="http://symfony.com/schema/routing"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/routing http://symfony.com/schema/routing/routing-1.0.xsd">

    <route id="fos_oauth_server_token" pattern="/oauth/v2/token">
        <default key="_controller">fos_oauth_server.controller.token:tokenAction</default>
        <requirement key="_method">GET|POST</requirement>
    </route>

</routes>

If you are using the Symfony2 plugins for PHPStorm then following this service definition is a little easier - you should be able to Ctrl+click and be taken to the right path.

Otherwise, the trickiest part here is figuring out what fos_oauth_server.controller.token is referencing.

<!-- vendor/friendsofsymfony/oauth-server-bundle/FOS/OAuthServerBundle/Resources/config/oauth.xml -->
* snip *
        <service id="fos_oauth_server.controller.token" class="FOS\OAuthServerBundle\Controller\TokenController">
            <argument type="service" id="fos_oauth_server.server" />
        </service>

So we can see, the fos_oauth_server.controller.token is really a dynamic / user-overridable way of specifying a standard PHP class - FOS\OAuthServerBundle\Controller\TokenController.

The Auth endpoint follows a very similar pattern.

Debug Helper

Throughout the video I use a debug mechanism that has served me very well over my years with Symfony2.

exit(\Doctrine\Common\Util\Debug::dump($yourVariableHere));

The VarDumper Component is certainly nicer and a little easier to use (less typing at least), but this little helper will work with Symfony without needing any further dependencies.

Don't worry about the fact it spits out your debug info twice - this is a recent 'issue', but regardless, it won't affect its usefulness.

Dumping The Token

Perhaps the most important part of this whole step-by-step approach to visualising the flow is that 95% of the important code isn't actually being run from inside the OAuthServerBundle at all.

Huh?

Yeah, the Bundle is a wrapper around another component.

Huh?

Ok, so again, another confusing thing here if you are new to Symfony.

The Bundle itself is really just a layer on top of the OAuth Server implementation.

Now, in the case of FOSOAuthServerBundle, the actual OAuth Server implementation is also code by the Friends of Symfony / FOS, and that's the OAuth2 Server.

Symfony talks to the FOSOAuthServerBundle which talks to the OAuth2 Server.

A little confusing. But also very important to understand, especially when trying to debug.

This becomes important when we are stepping through and dumping out the contents of the various variables throughout our application's run time.

We aren't putting the debugs inside the Bundle code, but rather inside the OAuth2 Server code.

As mentioned in the video, it's quite a complex method to follow, and one that calls other quite complicated methods also.

Understanding this flow is key to being able to effectively implement the FOSOAuthServerBundle.