Pros and Cons: Hybrid Auth

Now let’s take a look at the more extensive implementation—the OpenID OAuth hybrid approach—to see how it compares to the straight OpenID integration that we just discussed.

Pros:

  • Since you are using OAuth for your authorization model, you will have access to a much wider array of information from user profiles. In addition to the extensive data comprising the profile systems, OAuth providers usually supply several social APIs that allow you to get, set, and delete a significant quantity of the user’s profiles, connections, and activities.

  • By storing the access token provided from the OAuth process, applications and services may generally run headless requests[3] to process user data for the duration that the access token is valid.

  • Since you are already leveraging the OpenID process, you also gain all of its pros, with the exception of its lightweight implementation.

Cons:

  • When you integrate the OAuth libraries, you incur quite a large overhead in your implementation code base. Instead of the process completing when the user authenticates the application (like in OpenID), once the user signs in to authorize your application, you still need to perform all of the token exchange steps required to obtain a valid OAuth access token.

  • To integrate OAuth in the hybrid auth approach, you have to set up an application with the provider in order to obtain the consumer key and secret needed for the OAuth process. This means that you will also need to implement a mechanism to manage the keys for the application.

When we put all of these factors together, we can see how having an OpenID OAuth hybrid approach can be especially beneficial. Even though integrating the OAuth libraries makes for a more heavyweight implementation, having the user’s authorization for your application or website to fetch, update, and delete information on her behalf can be very powerful. The only limits to our hybrid auth approach depend on the number of social APIs that the provider makes available for accessing and modifying user data.


[3] Within the OAuth process, when an application stores a valid access token for a user once he authorizes the application, and then at a later date makes calls to modify his data without involving him again (such as through a cron job), this is referred to as a headless request.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.189.180.43