# How to authenticate

{% hint style="info" %}
This section covers what kind of authentication method you can use when you are making an **incoming request** to to your Bubble application from an external app.

\
If you are looking for how to authenticate **outgoing requests** sent via the API Connector, check out [this article](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/the-api-connector/authentication).
{% endhint %}

## Bubble's authentication method

There are many different ways to authenticate[^1] an API request. Bubble uses the method known as  ***bearer token***.

{% hint style="info" %}
You can set the access level for an **API workflow** using the **Authentication** setting. This determines whether the workflow can be accessible to everyone, to authenticated users and admins, or to admins only.

Article section: [API workflow access level](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/the-workflow-api#access-level)
{% endhint %}

### What is a bearer token?

The bearer token is a string that identifies **who** the client is. It serves as both username and password and is included in the *header* of the API request. Tokens are generated by Bubble by creating an [admin API key](#user-content-fn-2)[^2] or by [signing a User in through an API call](#user-content-fn-3)[^3].&#x20;

Since every [RESTful API ](#user-content-fn-4)[^4]request is made independently of any previous or later requests, the token needs to be included with every API request coming into your app that requires authentication.

## Authenticate with a bearer token in Postman

The bearer token needs to be included in the Authorization header of an HTTP request, in the following format:

```
Authorization: Bearer <token>
```

In the example above, \<token> represents the actual token string. Do not include "<" and ">" in the final string.

In an application like Postman[^5], the authorization should look like this:

<figure><img src="https://34394582-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M5sbzwG7CljeZdkntrL%2Fuploads%2FmBOFnFHFtwsstC9BdIpL%2Fbearer-token-postman.png?alt=media&#x26;token=2d65c39a-3dfd-4c15-9834-8233b822e661" alt=""><figcaption><p>The top row in the request header carries the bearer token. It is greyed out because it has been added in the <em>Authorization</em> tab (left of the <em>Headers</em> tab) and Postman automatically adds it to the header.</p></figcaption></figure>

When included like in the above illustration, Bubble will recognize the token and respond to the call according to the privileges (if any) of the User that the token represents.

<details>

<summary>How secure are API bearer tokens?</summary>

Bearer tokens are considered more secure than sending a username and password in each request because they can be easily revoked, have a limited lifetime and can be connected to one of your app's Users which allows you to limit the scope of their database and workflow access by use of [Privacy Rules](#user-content-fn-6)[^6] and Conditions[^7].

Additionally, bearer tokens can be easily revoked if the user's device is lost or stolen, whereas revoking a password would require the user to reset it on all devices. Additionally, tokens are sent in the headers, which are less prone to being intercepted than cookies or URL parameters.\
\
Tokens generated by Bubble are considered [cryptographically secure](#user-content-fn-8)[^8], meaning they cannot be easily reconstructed and have a length of 32 bytes.\
\
Article: [Revoking a User token](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/the-bubble-api/as-a-user#revoking-a-token)\
Article: [Revoking an admin token](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/the-bubble-api/as-an-admin#revoking-an-admin-authentication-token)

</details>

[^1]: Authentication is the process of identifying **who** a client is in order to determine what resources they should be given access to.\
    \
    Article: [Authentication](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/the-bubble-api/authentication)

[^2]: Ad admin API key is an API token that you can create in the Bubble editor. This token gives the broadest API access level available.\
    \
    Article: [Authenticating as an admin](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/the-bubble-api/authentication/as-an-admin)

[^3]: A User token is a way for an API client to sign in as a registered User in your app and be constrained by the same Privacy Rules and Conditions that would apply if the User used your app directly via a browser.\
    \
    Article: [Authenticating as a User](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/the-bubble-api/authentication/as-a-user)

[^4]: A RESTful API is a way to describe that an API follows a certain kind of structure that ensures it is compatible with other services that share the same structure.\
    \
    Bubble's API is built around these principles to offer the broadest level of compatability.\
    \
    Article: [What is a RESTful API?](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/introduction-to-apis/what-is-a-restful-api)

[^5]: Postman is a freemium software used to set up and test API calls.\
    \
    External link: [Postman](https://www.postman.com)\
    Article section: [What is Postman?](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/the-data-api/data-api-requests#what-is-postman)

[^6]: Privacy Rules are server-side rules that govern **who** has access to **what** in your database. For example, a logged-in User may have access to specific Data Types while a non-logged-in User does not.\
    \
    In the context of API requests, Privacy Rules apply to **clients** that have authenticated using a **User token**.

    Article: [Privacy Rules](https://manual.bubble.io/~/changes/1188/help-guides/integrations/api/the-bubble-api/authentication/broken-reference)

[^7]: Conditions on a Workflow let you specify under which condition the Workflow should run.\
    \
    For example, a logged-in User may be able to run a workflow, but a non-logged-in User may not.\
    \
    In the context of APIs, Conditions can be applied depending on who the **client** is.&#x20;

[^8]: The field of encryption is called *cryptography.* Cryptographically secure means that the token is generated in a way that the industry considers highly secure.\
    \
    This is done using complex algorithms that ensure a level of randomness that is extremely difficult to recreate.\
    \
    In the case of Bubble's tokens, their length of 32 bytes also dramatically increases the computational power that would be required to crack it.
