# As a User
Help us improve this article This article is part of a significant update to the Bubble manual and your feedback is critical to our efforts to continuously enhance our written documentation.\ \ We would greatly appreciate if you could take a moment to let us know your thoughts on the quality of it. Thank you for your support!\ \ [Give feedback on this article](https://docs.google.com/forms/d/e/1FAIpQLSfe7eaYVxkqTa_nn3QE6VObCxWB1hgh6sHUQGQ0Eit8JlAS7g/viewform?usp=pp_url\&entry.619913899=https://manual.bubble.io/help-guides/apis-connect-to-other-apps/the-bubble-api/authentication/as-a-user\&entry.80834677=As+a+User)
## What is User authentication? **User authentication** means that the client[^1] making the request is authenticating as a User, which means that we can determine what they are authorized to access using [Privacy Rules](#user-content-fn-2)[^2], just like our regular app Users. This is the method that offers the highest level of security and flexibility since it allows you to provide different Privacy Rules based on who the client is. ## How to set up User authentication In principle, logging a client in as a User happens in the same way that you log in a regular User in your app, except that the action needs to happens in an [API Workflow](#user-content-fn-3)[^3]. When you log in a User, Bubble can return a token that can be used to authenticate in subsequent calls. 1. Create an API Workflow with a fitting name such as *generate-api-token* 2. Use the *Log the User in* action or *Sign the user up* action to log in or create a new User. For the *Log the User in* action you will need to provide an email and a password. 3. If successful, Bubble will automatically respond with a token that can be used as a Bearer token in subsequent call.

If you log a user in with an action in an API Workflow, Bubble will respond with a token that can be used to authenticate the client in subsequent requests. In the example above we are accepting the email and password as parameters in the API Workflow.

## How long is the token valid? The token has to different validities depending on your settings. ### Without 2-factor authentication * If you set *Keep the user logged in* to "yes", the token has a validity of **12 months** * If you set *Keep the user logged in* to "no", the token has a validity of **24 hours** ### **With 2-factor authentication** * If you set *Keep the user logged in* to "yes", the token has a validity of **1 month** * If you set *Keep the user logged in* to "no", the token has a validity of **24 hours** ### Revoking a token There are two ways to revoke a token after it has been generated: * You can call a *Log the User out* action from the client that uses the relevant token * You can use the *Log out other user's sessions* to sign a User out from every session except for the one they are running the workflow from ## Restricting a client's privileges There are two ways to restrict the access level and privileges of a client that's using a user token: * **Privacy Rules:** your main level of protection is setting up privacy rules that match the User that is signed in and control their access to find, read, create, edit and delete data through the API. Read our full article on that [here](broken://pages/-MTk0Eu9ofTFsTqbQRbb). * **Conditions**: on API Workflows you can set up Conditions that restrict the triggering of the workflow based on fields saved on the User. This will apply to clients who are sending a request with a user authentication token. [^1]: The *client* is the one that is making a request in an API call, as opposed to the *server* who is the one to respond.\ \ In the case of the Bubble API, the external system is the *client* and your Bubble app is the *server*.
Article: [The client/server relationship](/~/changes/KJh7wUmvooVFeg4izJFB/help-guides/integrations/api/introduction-to-apis.md#client-and-server) [^2]: Privacy Rules are server-side rules that govern **who** has access to **what** in your database.\ \ In the context of APIs, Privacy Rules are applied to API requests depending on how the client has authenticated.\ \ Article: [Data API Privacy Rules](/~/changes/KJh7wUmvooVFeg4izJFB/help-guides/integrations/api/the-bubble-api/the-data-api/data-api-privacy-rules.md)\ Article: [Workflow API Privacy Rules](/~/changes/KJh7wUmvooVFeg4izJFB/help-guides/integrations/api/the-bubble-api/the-workflow-api/workflow-api-privacy-rules.md) [^3]: An API Workflow is a server-side Workflow that can be exposed to be triggered from an external app through an API call.\ \ Article: [The Workflow API](/~/changes/KJh7wUmvooVFeg4izJFB/help-guides/integrations/api/the-bubble-api/the-workflow-api.md)\ Article [API Workflows](/~/changes/KJh7wUmvooVFeg4izJFB/help-guides/integrations/api/the-bubble-api/the-workflow-api/api-workflows.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://manual.bubble.io/~/changes/KJh7wUmvooVFeg4izJFB/help-guides/integrations/api/the-bubble-api/authentication/as-a-user.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.