# Authentication Install-scoped bearer tokens, how they are minted, and how to revoke one machine without signing out the rest. Source: https://docs.omazy.ai/reference/api/authentication/ Requests carry a bearer token: ```http Authorization: Bearer ``` ## Tokens are scoped to an install, not to you This is the design decision worth understanding, because everything else follows from it. A token belongs to one machine or one integration, not to a person. Sign in on your laptop and your CI runner and you have two tokens, not one shared between them. When the laptop is lost, you revoke that token and CI keeps running. One key per door beats one key for the building. ## Getting a token The CLI does the whole exchange for you: ```sh omazy auth login --email you@example.com ``` You get a one-time code by email, the CLI exchanges it, and the resulting token is scoped to that machine. There is no browser step, which is what lets this work over SSH and inside containers where opening a browser is not a thing that can happen. ## Revoking Revoke the install, not the account. Revoking one token leaves every other session working, which is what you want when a laptop goes missing and what you very much do not want to discover you cannot do at 2am. ## What a rejected token looks like An expired or revoked token comes back as a failure with a stable error code rather than a prose message. Branch on the code, never on the text. Messages get rewritten by people improving the wording; codes do not. See [Platform](/reference/platform/) for the full list. :::caution[Do not put a token in a browser] These tokens are for servers, CLIs and integrations. The widget authenticates differently and deliberately, using a public key that can safely appear in page source. If you find yourself pasting a bearer token into front-end JavaScript, stop: you are about to publish it to everyone who views source. :::