Hooking up OAuth to DPS

Hooking up OAuth to DPS

One goal of pairing OAuth with an Adobe DPS app is to create a smooth transition between a 3rd party login (such as Salesforce, Twitter, or Facebook) and the private or subscriber-only folios in your DPS app. The reality is that the developer is often on the hook for a lot of work to make this happen. 6D's Entitlement Server for DPS provides normal login and registration functionality directly through DPS apps, but now it also supports OAuth login and registration. To make it easier on developers and clients, I've created an open source Javascript library to simplify the use of Adobe's OAuthRedirectService which drives OAuth functionality in DPS apps.

First, some background on what Adobe gives us to handle OAuth requests from a DPS App. The OAuthRedirectService object's purpose is to start and stop listening for any requests to a custom URI assigned to the app. This is set up at build time by enabling an "Optional Url Scheme” which makes URLs like com.test.app://some/sort/of/request redirect to your app. Specifically, com.test.app://oauth triggers the authorization callback in OAuthRedirectService once it has started listening.

So how does that request fire? It's done at the very end of every OAuth process—when a provider is ready to give us our treasured OAuth token, it'll redirect to a URI we provide them. From the app's point of view, its OAuth provider is the 6D Entitlement Server, and we instruct it to do the final redirect to com.test.app://oauth by passing redirect_uri as a parameter to the initial login/with request. But where does that login/with request come from? It's made by an in-app browser we open with Adobe's dialogService. The Entitlement Server handles the in-between heavy lifting: communicating with the OAuth Providers, setting up user accounts, verifying user credentials, etc.

A sample of code from dps-oauth-login that shows the relevant code for the login/with request.

Let's hook this up to DPS Entitlement. In order for entitlement requests to work, the DPS app needs an authentication token and a service URL (the URL is provided at build time). The 6D Entitlement Server provides com.test.app://oauth with an auth_token parameter that can be used for entitlement! It can be assigned to the DPS AuthenticationService through the login() function. Once that's done, signals in the AuthenticationService object fire, as if you had just logged in! This separation of responsibility for OAuth redirection and entitlement logins, as well as the abstraction of how an entitlement auth_tokenis obtained, makes implementing OAuth as an entitlement login method a relatively straightforward task. And again, since the 6D Entitlement Server is handling all the heavy lifting of dealing with OAuth Providers, all we have to worry about on the app side is opening a dialog and getting an auth token.

A 3-step diagram for OAuth that abstracts away many details into a big cloud.

Finally, let's get tie this all up in the dps-oauth-login Javascript library. There are three steps to setting up OAuth with the 6D Entitlement Server. First, the developer has to create an "app” or "consumer” at an OAuth provider, and get some credentials from it (usually an id and a secret). 6D provides guides and support on how to do this for each supported OAuth provider. Then, the developer sets up the authentication method on the 6D Entitlement Server, simply copying over the credentials they got from the first step. Finally, (and this is where the new library comes in) they include dps-oauth-login.js and the following script into their DPS app.

new OAuthLogin({
  redirectURI: "APPURL://oauth", // Replace APPURL with the custom URL handler 
  clientId: "com.app.test", // The Adobe app id for your DPS app
  selector: "#loginButton", // The id of the button you want to trigger onClick
  service: "salesforce" // The oauth provider to use
});

That's it! It adds a click event to #loginButton, handles all the OAuth redirect events, and assigns the final auth_token to the app's AuthenticationService. The only dependency is the Adobe DPS storefront library, which you should be using anyway. No dealing with OAuthRedirectService or AuthenticationService on your own! No looking up docs—just a single file, with a single function call.

If you aren't using the 6D Entitlement Server, or you just aren't using entitlement at all, the library is still a great reference for how Adobe's OAuth redirect service works, and provides some simple code to get you started on your own implementation. However, if you have a DPS app with entitlement, including our OAuth solution can increase uptake amongst your users by making it fast and simple to login.

Share this post

0 Comments

comments powered by Disqus