> ## Documentation Index > Fetch the complete documentation index at: https://help.lobyco.com/llms.txt > Use this file to discover all available pages before exploring further. # API authentication > The two ways your systems authenticate against the Lobyco APIs, an OAuth 2.0 token or an API key, and which tenant setup to choose. Every call from your systems to the Lobyco APIs carries a credential. There are two schemes: an OAuth 2.0 access token from the client credentials flow, or an API key. This page says what each is for, and how to choose the Azure AD setup behind the token. The setups themselves are two guides, linked below. ## OAuth 2.0 client credentials flow This is the scheme for server-to-server calls. Lobyco implements the OAuth 2.0 [client credentials flow](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow) on the Microsoft identity platform. Your service authenticates with an app id and a secret, gets an access token, and sends it with every request. The Lobyco API validates the token's issuer, audience and roles before it runs the request. Sequence diagram: the client service gets an access token from the Microsoft identity platform with its app id and secret, sends it with the request, and the Lobyco API validates the issuer, audience and roles before running the application logic *Your service gets a token from the Microsoft identity platform and sends it with each request; the Lobyco API validates it before it does anything* ### Choose a tenant setup The app registration your service authenticates as lives in one of two tenants. Which one decides who creates it and who holds its secret. | Setup | Where the app registration is | Who holds the secret | Choose it when | | - | - | - | - | | [Lobyco tenant](/integration/get-started/api-authentication/lobyco-tenant-authentication-using-client-credentials-flow) | Lobyco's Azure AD tenant. Lobyco creates it and shares the credentials with you | Lobyco, shared with you | Your organisation does not run its own Azure AD tenant | | [Multi-tenant](/integration/get-started/api-authentication/multi-tenant-authentication-using-client-credentials-flow) | Your own Azure AD tenant. You import the Lobyco multi-tenant app and register your own client app against it | You | Your organisation runs its own Azure AD tenant and wants full control of the secrets | Both setups end in the same token request, and the Lobyco APIs treat the tokens alike. ## API key An API key is weaker than a token: it is a fixed string, and it does not expire on its own. It still has a place. A POS, for example, may not be able to cache a token and renew it before it expires. For that case Lobyco can issue an API key instead. Ask Lobyco for one, and say which IP addresses will use it. Lobyco can limit the key to those addresses, which is the extra measure that makes a key acceptable. ## Related * [Lobyco tenant authentication using client credentials flow](/integration/get-started/api-authentication/lobyco-tenant-authentication-using-client-credentials-flow) — the token request, with the app registration Lobyco created for you. * [Multi-tenant authentication using client credentials flow](/integration/get-started/api-authentication/multi-tenant-authentication-using-client-credentials-flow) — importing the Lobyco app into your own Azure AD and registering your client app. * [API integration](/integration/get-started/api-integration) — the Front Door address ranges your firewall must allow. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.