In September 2019, we 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. We built a unique third-party authorization flow for this product specifically, but this design can be used for any future third-party partners.
Our main objective for the integration with Binance was to have a simple, seamless user experience. By doing so, we could also offer safety and stability. To improve user flows surrounding BUSD creation and redemption, we developed a suite of APIs specifically for Binance. Binance uses them to shape its front-end experience for creating and redeeming BUSD in a way that is consistent with the Binance platform. But how can you create a high-security solution that is also convenient?
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 and 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 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. We require information like application name, possible scopes and redirect URI or callback URL. We implemented our 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 flow is most common and best used for third-party authorization. It 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 we designed for Binance.
As shown in the graph above, the user has been redirected multiple times between the Paxos web app and the Binance web app through the web browser. The glue that binds two apps together is actually the authorization code. It allows the user to give consent to Binance to access his/her information on Paxos. It also allows Binance to request the access token and refresh token from Hydra so 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 us, 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 external 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!