Binance Login with your web application | Binance Open …
Binance Developer Center, sign up for a Binance entity account, and from there, navigate to your console to create an OAuth application and get your own client ID and …
Last updated
Binance Developer Center, sign up for a Binance entity account, and from there, navigate to your console to create an OAuth application and get your own client ID and …
Last updated
Binance APIs utilize the OAuth 2.0 protocol for authentication and authorization. Binance supports common OAuth 2.0 scenarios such as those for web server, single page (browser based), mobile and native applications. This document will guide you through how your application communicates with Binance's OAuth 2.0 server to secure a user's consent for performing an API request on his behalf.
To begin, your application must identify the necessary permissions, or scopes
. Visit the Binance Developer Center, sign up for a Binance entity account, and from there, navigate to your console to create an OAuth application and get your own client ID and client secret. For now, Binance Login (Oauth2.0), is exclusively offered to close ecosystem partners. Please reach to our business team for further information.
Depending on your specific application type, you can select one of the two different authorization flows listed here:
For web applications, please refer to the ‘Authorization Code Flow’ section;
For browser-based applications as well as mobile and native applications, please refer to the ‘PCKE Flow’ section.
Copy
⚠️ The carriage returns of the above example are only for readability and should be removed in real world, as well as the following examples
When redirecting a user to Binance to authorize access to your application, your first step is to create the authorization request.
Here is an Example of an authorization URL:
Copy
In this step, the user decides whether to grant your application the requested access. At this stage, Binance displays a consent window that shows the name of your application and the Binance API services that it is requesting permission to access with the user's authorization credentials. The user can then consent or refuse to grant access to your application.
Your application doesn't need to do anything at this stage as it waits for Binance's OAuth 2.0 server to redirect back.
If the user approves your application, Binance's OAuth server will redirect back to your redirect_uri
with a temporary authorization code
parameter.
If you specified a state
parameter in step 1, the parameter will be included as well. If you generate a random string or encode the hash of a cookie or another value that captures the client's state
, you can validate the response to additionally ensure that the request and response originated in the same browser, providing protection against attacks such as cross-site request forgery.
Example of the redirection:
Copy
state
is the same as the one in step 1
After your application receives the authorization code
, it can exchange the authorization code
for an access token, which can be done by make a POST call:
Copy
Example POST call:
Copy
After a successful request, a valid access_token
will be returned in the response and it will be invalid if it exceeds the expires_in
time in the response, which is in seconds.
Here is an example response:
Copy
If your access token is expired, you can use refresh_token
to get a new access token, which can be done by make a POST call:
Copy
Example POST call:
Copy
After a successful request, a valid access_token
will be returned in the response and it will be invalid if it exceeds the expires_in
time in the response, which is in seconds.
Here is an example response:
Copy
After you have a valid access_token
, you can make your first API call:
Copy
⚠️ Please use the query string or Bearer token to pass the access_token.
Response:
Copy
The PKCE extension prevents an attack where the authorization code is intercepted and exchanged for an access token by a malicious client, by providing the authorization server with a way to verify the same client instance that exchanges the authorization code is the same one that initiated the flow. For more details, refer to
Copy
⚠️ The carriage returns of the above example are only for readability and should be removed in real world, as well as the following examples
When redirecting a user to Binance to authorize access to your application, your first step is to create the authorization request. You need create and store a new PKCE code_verifier, also will be used in STEP4
Here is an Example of javascript generate code_verifier
Copy
Here is an Example of javascript generate code_challenge
Copy
Here is an Example of an authorization URL:
Copy
In this step, the user decides whether to grant your application the requested access. At this stage, Binance displays a consent window that shows the name of your application and the Binance API services that it is requesting permission to access with the user's authorization credentials. The user can then consent or refuse to grant access to your application.
Your application doesn't need to do anything at this stage as it waits for Binance's OAuth 2.0 server to redirect back.
If the user approves your application, Binance's OAuth server will redirect back to your redirect_uri
with a temporary authorization code
parameter.
If you specified a state
parameter in step 1, the parameter will be included as well. If you generate a random string or encode the hash of a cookie or another value that captures the client's state
, you can validate the response to additionally ensure that the request and response originated in the same browser, providing protection against attacks such as cross-site request forgery.
Example of the redirection:
Copy
state
is the same as the one in step 1
After your application receives the authorization code
, it can exchange the authorization code
for an access token, which can be done by make a POST call:
Copy
Example POST call:
Copy
After a successful request, a valid access_token
will be returned in the response and it will be invalid if it exceeds the expires_in
time in the response, which is in seconds.
Here is an example response:
Copy
If your access token is expired, you can use refresh_token
to get a new access token, which can be done by make a POST call:
Copy
Example POST call:
Copy
After a successful request, a valid access_token
will be returned in the response and it will be invalid if it exceeds the expires_in
time in the response, which is in seconds.
Parameters | Description |
---|---|
Parameter | Description |
---|---|
Parameter | Description |
---|---|
Parameters | Description |
---|---|
Parameter | Description |
---|---|
Parameter | Description |
---|---|
response_type
Required Value code
client_id
Required The client ID of your application.
redirect_uri
required The URL in your web application where users will be redirected after authorization. This value needs to be URL encoded.
state
Optional The CSRF token to protect against CSRF (cross-site request forgery) attacks.
scope
required List of scopes enum your application requests access to, with comma (,
) seperated.
grant_type
required Value authorization_code
code
required Step3 return code
client_id
required The client ID of your application.
client_secret
required The client secret of your application.
redirect_uri
required The URL in your web application where users will be redirected after authorization. This value needs to be URL encoded.
grant_type
required Value refresh_token
refresh_token
required Step4 refresh token
client_id
required The client ID of your application.
client_secret
required The client secret of your application.
response_type
Required Value code
client_id
Required The client ID of your application.
redirect_uri
required The URL in your web application where users will be redirected after authorization. This value needs to be URL encoded.
state
Optional The CSRF token to protect against CSRF (cross-site request forgery) attacks.
scope
required List of scopes enum your application requests access to, with comma (,
) seperated.
code_challenge
required Hash and base64-urlencode of code_verifier
grant_type
required Value authorization_code
code
required Step3 return code
client_id
required The client ID of your application.
code_verifier
required The random secret code created and stored in STEP1
redirect_uri
required The URL in your web application where users will be redirected after authorization. This value needs to be URL encoded.
grant_type
required Value refresh_token
refresh_token
required Step4 refresh token
client_id
required The client ID of your application.
client_secret
required The client secret of your application.