Photo by Christopher Gower on Unsplash

Convenience and Security: Paxos’ Third-Party Authorization Design for BUSD and Beyond

Qi Sun
4 min readNov 13, 2019

--

In September 2019, Paxos partnered with Binance to launch a new stablecoin called Binance USD (BUSD). BUSD is regulated by the New York Department of Financial Services, backed 1:1 by U.S. dollars, and available for trading on the Binance platform. Paxos built a unique third-party authorization flow for this product specifically, but this design can be used for any future third-party partners.

Since beginning work on this project, the Paxos team knew they had to make the Binance user experience as seamless as possible. By doing so, we could also offer safety and stability. To improve user flows surrounding BUSD creation and redemption, Paxos developed a suite of APIs for Binance. Binance uses them to shape its front-end experience for creating and redeeming BUSD in a way consistent with the Binance platform. But how can you create a high-security solution that is also convenient? We were able to achieve this through our third-party authorization flow.

Third-party Authorization

Third-party authorization allows external parties, for example Binance, to access customer information from Paxos in a secure way. To effectively support BUSD on the Binance platform, we needed to authorize access to Binance.com for Paxos customers using their Paxos credentials along with their consent. We achieved this goal by using Oauth2.

OAuth2 and Authorization Grant types

OAuth 2.0 is the industry-standard protocol for authorization. It enables external applications to obtain designated access to the user accounts. Generally it is the protocol used behind every “Log in with Google” or “Log in with Facebook” button.

Before an application can use the Paxos OAuth2 authorization service, it must be registered as a verified third-party. Paxos requires information like application name, possible scopes and redirect URI or callback URL. Paxos has implemented its own third-party on-boarding portal to facilitate easy application by third-parties.

It’s important to note that there are many grant types specified by OAuth2. We focused on Authorization Code and Refresh Token flows, but other grant types may be better for you. For reference, they are:

  • Authorization Code — Enables individuals to grant authorization to an application requesting an access token from the API.
  • Client Credentials — Empowers the client application accessing its own service account information.
  • Device Code — Provides non-web apps a better way of user authentication.
  • Implicit — Allows the access token to be granted immediately without additional effort, and can be used by public clients (although that is not recommended).
  • Password — Exchanges the access token directly from the API.
  • Refresh Token — Lets the client application request new access token when it is expired.

Paxos Third-party Authorization Design

The authorization code flow is most common and best used for third-party authorization. The whole flow is based on interacting with a user agent — a web browser in this case — and redirecting the user to different pages for each step. Below is a diagram from the user’s point of view of the authorization code flow that Paxos designed for Binance.

As shown in the graph above, the user has been redirected multiple times between Paxos web app and Binance web app through the web browser. And the glue that binds two apps together is actually the authorization code. It allows the user to give consent for Binance to access their Paxos info, it then also allows Binance to request the access token and the refresh token from Hydra so that Binance can interact with Paxos on behalf of the customer.

The refresh token flow is for the convenience of users navigating through a third-party web app, so that they don’t have to go through the whole authorization flow every time the authorization code expires. The refresh token will always last much longer than a regular access token. However, it can not be used directly to interact with Paxos, it can only be used to request a new access token.

Why Hydra

ORY Hydra is a REST service that facilitates standard OAuth2 flows. The service is built around security first. Its architecture and work flows are designed to neutralize common attack vectors including OWASP top 10. Additionally, Hydra implements the Oauth2 flow by HTTP redirection and cryptographic methods, and allows users to bring any authentication endpoint on the board. Its flexibility is definitely a key feature for Paxos, which allows the integration with the Paxos authentication service.

Conclusion

We took this path because we faced a challenge — creating a more seamless experience for users across platforms. By taking this approach, we created a strong API solution that we can then scale across future partner integrations. Ultimately, this functionality helps our customers and partners to save time and reduce risk while maintaining the highest levels of security. Take a shot at this approach yourself, and let us know if you have any insights!

--

--