# Authentication The Rhythm REST API uses Auth0, the OpenID Connect (OIDC) Protocol, and the OAuth 2.0 Authorization Framework for authentication. Auth0 supports a wide variety of authentication use-cases including Multi-Factor Authentication (MFA), Social Login, Federated Identity, Single Sign-On, etc. To authenticate you will need a `Client ID`, `Secret`, and the `Auth0 domain` for the tenant you will be accessing. You can access all of this information yourself within Rhythm console under **Security & Settings > API Keys**. For further assistance with credentials, you can create a new support ticket in [ZenDesk](https://support.rhythmsoftware.com). Flows You will use this information to complete one of the **authentication flows** described below. You must choose the flow that best fits your API use-case. Before you start, please be sure to review **all** the information in the [concepts](/tutorials/concepts) section. ## Authorization Header Once you complete one of the authentication flows below, you will receive an **access token** which you can send to the Rhythm API to authorize each request. Access tokens are Base64 encoded JSON Web Tokens (JWTs) that automatically expire, and are specific to the user who has authenticated. Isolation Tokens generated using the Client Credentials flow are not related to a specific person. Therefore, they may be securely cached and reused globally. Tokens generated by an interactive user should be restricted to the authenticated user's session. To authorize each API request, pass the access token in the **Authorization** HTTP header with a value in the format: > "Authorization": "Bearer `access_token`" ## Authorization Code Flow This is the most common method of authentication for standard server rendered websites when: 1. There is an interactive user whose actions initiate API calls 2. The website source code is not publicly exposed (server rendering) The flow starts with a redirect to Auth0, which includes your client ID and your return URL. After authentication, users will be redirected back to your return URL with a code you can use to retrieve their **access token**. To learn more about the authorization code flow, see: [https://auth0.com/docs/flows/authorization-code-flow](https://auth0.com/docs/flows/authorization-code-flow) For detailed instructions on generating an **access token** using the Authorization Code Flow, you can download the [Rhythm Single Sign On Quick Start](https://assets.cdn.rhythmsoftware.com/docs/Rhythm%20Single%20Sign-On%20Quick%20Start.pdf) document. ## Authorization Code with PKCE For mobile/native apps or single page apps (SPAs) you will use the Authorization Code Flow with Proof Key for Code Exchange (PKCE). This flow is different from server rendered websites because the authentication starts on the user's device. In this case, the user device access to your source code, and you cannot securely store a secret on their device. To learn more about the authorization code flow with PKCE, see: [https://auth0.com/docs/authorization/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce](https://auth0.com/docs/authorization/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce) ## Client Credentials Flow Also called Machine to Machine (M2M), this flow is typically used by scripts and other automated server-side processes that periodically execute API calls. These programs may use Query APIs to retrieve and cache data before delivering it to your users through your APIs. There is a monthly limit on the number of access tokens you may retrieve using this flow. Tokens are valid for 24 hours, so they should be securely cached and reused during this period. This limit does not apply to the other authorization flows. **Caching requirement** A well-designed integration requests one token per day and reuses it, consuming roughly 31 tokens per month. If the monthly cap is reached, all additional M2M token requests fail until the next monthly reset — even if your credentials and endpoints are otherwise correct. Common mistakes that exhaust the token limit: - Requesting a new token on every API call - Requesting a new token every time a scheduled job runs - Requesting a new token per end user Recommended approach: 1. Request an M2M token 2. Store it securely in memory or a server-side cache 3. Reuse it for all API calls until it is near expiration 4. Refresh it only when expired or close to expiring 5. If a token request fails, log the error and retry with reasonable backoff — do not retry aggressively To learn more about the Client Credentials flow see: [https://auth0.com/docs/authorization/flows/client-credentials-flow](https://auth0.com/docs/authorization/flows/client-credentials-flow) Obtaining an **access token** using the Client Credentials flow only requires one **x-www-form-urlencoded** POST to: > https:// `auth0 domain`/oauth/token Your POST should include the following information in the body: ``` grant_type=“client_credentials” &client_id=[your client id] &client_secret=[your client secret] &audience=“https://api.rhythmsoftware.com” ``` This endpoint is described further here: [https://auth0.com/docs/api/authentication?http#authenticate-user](https://auth0.com/docs/api/authentication?http#authenticate-user) ## Auth0 SDKs Auth0 publishes SDKs for several popular frameworks which you can use instead of manually executing an authorization flow. For a full list, see [https://auth0.com/docs/libraries](https://auth0.com/docs/libraries) ## What's Next Consider checking out our [Guides](/guides) for specific use-cases or dive into the [API References](/apis) and execute your first API call.