## Register Machine-to-Machine Applications

To integrate the NinjaOne Public API with a machine-to-machine (M2M) application, you must first register your app within the NinjaOne web application. These apps may include non-interactive apps, such as command-line tools, daemons, IoT devices, or services running on your back-end.

1.  Go to [Configuration > Apps > API > Client App IDs](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/#/administration/apps/api/client) and click the **Add** button on the right.
2.  Select **API Services (machine-to-machine)**.

![API Services Option](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/images/articles/machine-to-machine-app-option.png)

3.  Enter information about the application settings.

![API Services Settings](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/images/articles/machine-to-machine-app-settings.png)

-   **Name**: defines the name of your application. This will display in the application list and in the consent screen.

-   **Redirect URIs**: a set of URLs to which NinjaOne is allowed to redirect users after they authenticate. This can be left empty since the flow does not have user interaction.

-   **Scopes**: a list of NinjaOne API resources.

    -   **Monitoring**: grants read-only access to monitoring data and organization structure.
    -   **Management**: allows modification of device and organization information; including creating new organizations, adding new devices, running scripts, etc.
    -   **Control**: enables remote access via API.
-   **Allowed Grant Types**: defines the authentication process for your application. They are available based on the application platform.

    -   **Client Credentials** is the appropriate grant type for the API services application platform. You can enable or disable as needed.

    If you need a **silent authentication**, after the initial authentication, select the **Refresh Token** grant type option. Refresh tokens are typically longer-lived and can be used to request new access tokens after the shorter-lived access tokens expire. To learn more visit [**Refresh Tokens**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/refresh-tokens).


Once you have registered and configured your application, please visit [**Client Credentials Flow**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/flows/client-credentials-flow) where you'll find detailed instructions for the authentication process.

## OAuth 2.0 Authorization Framework

The NinjaOne Public API uses OAuth2 to authenticate requests. OAuth 2.0 allows applications to obtain access to NinjaOne resources that are made available via the API.

## [

Roles

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#roles)

An OAuth 2.0 flow has the following roles:

-   **Resource Owner**: Entity that can grant access to a protected resource. Typically, this is the end-user.

-   **Resource Server**: Server hosting the protected resources. This is the API you want to access. In this case, this is the NinjaOne Public API.

-   **Client**: Application requesting access to a protected resource on behalf of the Resource Owner.

-   **Authorization Server**: Server that authenticates the Resource Owner and issues access tokens after getting proper authorization. In this case, NinjaOne.


## [

Grant Types

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#grant-types)

OAuth 2.0 defines several flows to get an access token. These flows are called grant types. Deciding which one is best suited for your case depends mostly on your application type.

-   [**Authorization Code Flow**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/flows/authorization-code-flow): used by Web Apps executing on a server. This is also used by mobile apps, using the [Proof Key for Code Exchange](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce) (PKCE) technique.

-   [**Implicit Flow**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/flows/implicit-flow): used by JavaScript-centric apps (Single-Page Applications) executing on the user's browser.

-   [**Client Credentials Flow**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/flows/client-credentials-flow): used for machine-to-machine communication.


To learn more about how each grant type works and when it should be used, see the Authorization Flows sections.

## [

Endpoints

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#endpoints)

OAuth 2.0 uses two endpoints: the `/oauth/authorize` endpoint and the `/oauth/token` endpoint.

### [

Authorization endpoint

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#authorization-endpoint)

The `/oauth/authorize` endpoint is used to interact with the resource owner and get the authorization to access the protected resource. To better understand this, imagine that you want to log in to a service using your Facebook account. First, the service redirects you to Facebook in order to authenticate (if you are not already logged in) and then you will get a consent screen, where you will be asked to authorize the service to access some of your data (protected resources); for example, your email address and your list of contacts.

This endpoint is used by the **Authorization Code** and the **Implicit** grant types. The authorization server needs to know which grant type the application wants to use since it affects the kind of credential it will issue:

-   For the **Authorization Code** grant, it will issue an authorization code (which can later be exchanged for an access token at the /`oauth/token` endpoint).

-   For the **Implicit** grant, it will issue an access token, which is an opaque string that denotes who has authorized which permissions (scopes) to which application.


To inform the authorization server which grant type to use, the `response_type` request parameter is used as follows:

-   For the Authorization Code grant, use `response_type=code` to include the authorization code.

-   For the Implicit grant, use `response_type=token` to include an access token.


### [

Token endpoint

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#token-endpoint)

The `/oauth/token` endpoint is used by the application to get an access token or a refresh token. It is used by all flows except for the **Implicit** Flow because in that case an access token is issued directly.

-   In the **Authorization Code** Flow, the application exchanges the authorization code it got from the authorization endpoint for an access token.

-   In the **Client Credentials** Flow, the application authenticates using a set of credentials and then gets an access token.


## [

Which Flow Should I Use?

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#which-flow-should-i-use)

When deciding which flow to use, consider whether the party that requires access to resources is a machine. In the case of machine-to-machine authorization, the Client is also the Resource Owner, so no end-user authorization is needed. An example is a cron job that uses an API to import information to a database. In this example, the cron job is the Client and the Resource Owner since it holds the Client ID and Client Secret and uses them to get an Access Token from the Authorization Server. If this case matches your needs, then please see [**Client Credentials Flow**.](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/flows/client-credentials-flow) to learn how this flow works and how to implement it.

If the Client is a regular web app executing on a server, then the Authorization Code Flow is the flow you should use. Using this the Client can retrieve an Access Token and, optionally, a Refresh Token. It's considered the safest choice since the Access Token is passed directly to the web server hosting the Client, without going through the user's web browser and risking exposure. If this case matches your needs, please see [**Authorization Code Flow**.](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/flows/authorization-code-flow) to learn how this flow works and how to implement it.

If the Client is a Single-Page App (SPA), or an application running in a browser using a scripting language like JavaScript, there are two grant options: the **Authorization Code Flow** with Proof Key for Code Exchange (PKCE) and the **Implicit Flow**. For most cases, we recommend using the Authorization Code Flow with PKCE because the Access Token is not exposed on the client side, and this flow can return Refresh Tokens. To learn more about how this flow works and how to implement it, see [**Authorization Code Flow with Proof Key for Code Exchange.**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce).

If the Client is a Native or Single-Page App (SPA), then use the **Authorization Code Flow** with Proof Key for Code Exchange (PKCE). To learn more about how this flow works and how to implement it, see [**Authorization Code Flow with Proof Key for Code Exchange.**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce)

## Authorization<small><pre>OAS 3.0</pre></small>

The NinjaRMM Public API uses OAuth2 to authenticate requests. OAuth 2.0 allows applications to obtain access to NinjaRMM resources (such as monitoring information) that are made available via the API.

To start using the OAuth protocol for your app’s authentication with NinjaRMM, you must first have an OAuth app credential from the NinjaRMM system. The OAuth app will have an **authorization grant** set up for you. OAuth 2.0 supports various grant types. However, NinjaRMM Public API supports **authorization code** and **implicit** grant types.

### [Endpoints](https://tsargent.rmmservice.com/apidocs/?links.active=authorization#/Endpoints)

The first step when authenticating a user using OAuth 2.0 is to send them through the NinjaRMM portal and request permission to act on their behalf.

To request a user’s authorization to use the NinjaRMM Public APIs on their behalf, you will need to send a user to the above URL with this format.

#### Parameters

| Name | Description |
| --- | --- |
|
response\_type \*

string($token)

(query)

 |

The type of response we'd like to receive. Use `code` for **Authorization Code Flow** and `token` for **Implicit Flow**.

_Available values_ : code, token

_Example_ : code

 |
|

client\_id \*

string

(query)

 |

The Client ID of the application that is requesting to authenticate the user.

 |
|

client\_secret

string

(query)

 |

The Client Secret of the application that is requesting to authenticate the user. This value is **required** for private client applications.

 |
|

redirect\_uri \*

string($url)

(query)

 |

The URL to which NinjaRMM redirects the browser after the user has granted or denied the application permission. This URL must match the redirect URL in the configuration of your application. It must be a valid HTTPS URL and it needs to be able to handle the redirection to complete the next step in the OAuth 2.0 flow.

_Example_ : http://localhost

 |
|

state

string

(query)

 |

A custom string of your choice. NinjaRMM will pass the same string to the redirect URL when authentication is complete. This parameter can be used to identify a user on redirect, as well as a CSRF protection mechanism if it contains a random value per request.

_Example_ : custom\_state

 |
|

scope

string

(query)

 |

A space-separated list of application scopes that you’d like to authenticate the user for. This defaults to all of the scopes configured for the application in its configuration.

_Example_ : monitoring

 |
|

code\_challenge

string

(query)

 |

A plain or hashed and encoded value generated by the client application. This value is verified before the client application is allowed to exchange an authorization code for a set of tokens. This value is required for public client applications using PKCE.

 |
|

code\_challenge\_method

string($token)

(query)

 |

The method used to generate the value of the `code_challenge` parameter.

_Available values_ : plain, S256

 |

#### Responses

| Code | Description | Links |
| --- | --- | --- |
| default |
Does not return any data, but rather should be used in the browser.

<small>Media type</small>

<small>Controls <code>Accept</code> header.</small>

```
<span>string</span>
```





 | _No links_ |

{

<table><tbody><tr><td>description:</td><td><p>A request for a new OAuth 2.0 token</p></td></tr><tr><td>grant_type<span>*</span></td><td><span><span><span><span>string</span><span>($urn)</span><span><br>example: authorization_code</span><p>The type of request being made, either using a client-side obtained authorization code or refresh token for the purpose of downscoping a token.</p><span>Enum:<br><span>[ authorization_code, client_credentials, refresh_token ]</span></span></span></span></span></td></tr><tr><td>client_id<span>*</span></td><td><span><span><span><span>string</span><p>The Client ID of the application requesting an access token.</p></span></span></span></td></tr><tr><td>client_secret</td><td><span><span><span><span>string</span><p>The client secret of the application requesting an access token. This value is <strong>required</strong> when the client application is a private client.</p></span></span></span></td></tr><tr><td>scope</td><td><span><span><span><span>string</span><span><br>example: monitoring</span><p>A space-separated list of application scopes that you’d like to authenticate the user for. This defaults to all of the scopes configured for the application in its configuration.</p></span></span></span></td></tr><tr><td>code</td><td><span><span><span><span>string</span><span>($token)</span><div><p>The client-side authorization code passed to your application by NinjaRMM in the browser redirect after the user has successfully granted your application permission to make API calls on their behalf.</p><p>Used in combination with <code>authorization_code</code> as the <code>grant_type</code>.</p></div></span></span></span></td></tr><tr><td>refresh_token</td><td><span><span><span><span>string</span><span>($token)</span><div><p>A refresh token which is used to get a new access token.</p><p>Used in combination with <code>refresh_token</code> as the <code>grant_type</code>.</p></div></span></span></span></td></tr><tr><td>redirect_uri</td><td><span><span><span><span>string</span><span>($url)</span><span><br>example: http://localhost</span><p>The redirect URL included in the initial authorization request. This value is <strong>required</strong> when exchanging the <code>code</code> for an <code>access_token</code></p></span></span></span></td></tr><tr><td>code_verifier</td><td><span><span><span><span>string</span><p>The PKCE code verifier that your app generated at the beginning of the authorization request. This value is <strong>required</strong> when using PKCE parameters during the authorize request.</p></span></span></span></td></tr></tbody></table>

}

{

<table><tbody><tr><td>description:</td><td><p>A token that can be used to make authenticated API calls.</p></td></tr><tr><td>access_token</td><td><span><span><span><span>string</span><span>($token)</span><span><br>example: Qu5h5FzU9s_Dz7n4ZwJ5bWjg3CcupFW8lO7F_rPAsU4.N24zCN5F0ix3xZAsII0QomA7HALN1grDDbeyGCG0aOj</span><p>The requested access token.</p></span></span></span></td></tr><tr><td>expires_in</td><td><span><span><span><span>integer</span><span>($int64)</span><span><br>example: 3600</span><p>The time in seconds in seconds by which this token will expire.</p></span></span></span></td></tr><tr><td>token_type</td><td><span><span><span><span>string</span><span><br>example: bearer</span><p>The type of access token returned.</p><span>Enum:<br><span>[ bearer ]</span></span></span></span></span></td></tr><tr><td>refresh_token</td><td><span><span><span><span>string</span><span>($token)</span><span><br>example: 851fe9c6-e130-4e15-f1e0-ae6d54f37ecf.kmlLuF5rTKklWJrHxGYNJ2AvbrY8v8PyryfH9JExlRk=</span><p>The refresh token for this access token, if offline access was requested, which can be used to request a new access token when the current one expires.</p></span></span></span></td></tr><tr><td>scope</td><td><span><span><span><span>string</span><span><br>example: monitoring offline_access</span><p>The requested scope associated with the <code>access_token</code>.</p></span></span></span></td></tr></tbody></table>

}

{

<table><tbody><tr><td>description:</td><td><p>An OAuth 2.0 error</p></td></tr><tr><td>error</td><td><span><span><span><span>string</span><span><br>example: invalid_client</span><p>The type of the error returned.</p></span></span></span></td></tr><tr><td>error_description</td><td><span><span><span><span>string</span><span><br>example: The client credentials are not valid</span><p>The type of the error returned.</p></span></span></span></td></tr></tbody></table>

}


## Client Credentials Flow

For applications like CLIs, daemons, lambda functions or services running on your backend, the system authenticates and authorizes the app rather than a user. Machine-to-machine (M2M) apps use the Client Credentials Flow in which they pass along their Client ID and Client Secret to authenticate themselves and get a token.

## [

How it works

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#how-it-works)

## [

How to implement it

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#how-to-implement-it)

### [

Prerequisites

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#prerequisites)

Register your app in the NinjaOne application. To learn more, read [**Register Machine-to-Machine Applications**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/create-applications/machine-to-machine-apps).

-   Select **API Services** as the Application Platform.
-   Select the **scope(s)** your application will have access to.
-   Make sure your application's Grant Types include **Client Credentials**.

### [

Request tokens

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#request-tokens)

To access the Public API, you must request an Access Token for it. To do so, you will need to POST to the `/oauth/token` URL.

**Parameters**

| Name | Description |
| --- | --- |
| `grant_type` | Set this to `client_credentials`. |
| `client_id` | Your application's Client ID. |
| `client_secret` | Your application's Client Secret. |
| `scope` | A space-separated list of application scopes that you’d like access for. This defaults to all of the scopes configured for the application in its configuration. |

**Try out POST to token**

POST

https://tsargent.rmmservice.com/ws/oauth/token

**Response**

If all goes well, you'll receive an HTTP 200 response with a payload containing `access_token`, `expires_in`, `scope` and `token_type` values:

```
<div id="code-lang-json"><p><span>  </span><span>"access_token"</span><span>:</span><span> </span><span>"Qu5h5FzU9s_Dz7n4ZwJ5bWjg3CcupFW8lO7F_rPAsU4.N24zCN5F0ix3xZAsII0QomA7HALN1grDDbeyGCG0aOj"</span><span>,</span><span></span></p></div>
```

## Authorization Code Flow

Since regular web apps are server-side apps where the source code is not publicly exposed, they can use the Authorization Code Flow, which exchanges an Authorization Code for a token. Your app must be server-side because during this exchange, you must also pass along your application's Client Secret, which must always be kept secure, and you will have to store it in your client.

## [

How it works

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#how-it-works)

## [

How to implement it

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#how-to-implement-it)

### [

Prerequisites

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#prerequisites)

Register your app in the NinjaOne application. To learn more, read [**Register Web Applications**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/create-applications/regular-web-apps).

-   Select **Web** as the Application Platform.
-   Add a **Redirect URI(s)**.
-   Select the **scope(s)** your application will have access to.
-   Make sure your application's Grant Types include **Authorization Code**.

### [

Authorize user

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#authorize-user)

To begin the flow, you'll need to get the user's authorization. This step may include one or more of the following processes:

-   Authenticating the user;
-   Redirecting the user to the NinjaOne application to handle authentication;
-   Obtaining user consent for the requested permission level, unless consent has been previously given and remembered.

### [

Authorization URL example

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#authorization-url-example)

```
<div id="code-lang-raw"><div><p><span>https://{app|eu|oc}.ninjarmm.com/ws/oauth/authorize?</span></p></div><div><p><span>    client_id=YOUR_CLIENT_ID&amp;</span></p></div><div><p><span>    client_secret=YOUR_CLIENT_SECRET&amp;</span></p></div><div><p><span>    redirect_uri=https://YOUR_APP_REDIRECT_URL&amp;</span></p></div></div>
```

**Parameters**

| Name | Description |
| --- | --- |
| `response_type` | Set this to `code`. |
| `client_id` | Your application's Client ID |
| `client_secret` | Your application's Client Secret |
| `redirect_uri` | The URL to which NinjaOne will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the code URL parameter. |
| `scope` | A space-separated list of application scopes that you’d like to authenticate the user for. This defaults to all of the scopes configured for the application in its configuration. |
| `state` | A custom string of your choice. This parameter can be used to identify a user on redirect, as well as a CSRF protection mechanism if it contains a random value per request. |

**Response**

If all goes well, you'll receive an HTTP 307 response. The authorization `code` is included in the redirect URL.

### [

Request tokens

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#request-tokens)

Now that you have an Authorization Code, you must exchange it for tokens. Using the extracted Authorization Code (`code`) from the previous step, you will need to POST to the token endpoint.

**Parameters**

| Name | Description |
| --- | --- |
| `grant_type` | Set this to `authorization_code`. |
| `client_id` | Your application's Client ID. |
| `client_secret` | Your application's Client Secret. |
| `redirect_uri` | This must exactly match the `redirect_uri` passed to the authorization URL in the previous step. |

**Try out POST to token**

POST

https://tsargent.rmmservice.com/ws/oauth/token

**Response**

If all goes well, you'll receive an HTTP 200 response with a payload containing `access_token`, `expires_in`, `scope` and `token_type` values:

```
<div id="code-lang-json"><p><span>  </span><span>"access_token"</span><span>:</span><span> </span><span>"Qu5h5FzU9s_Dz7n4ZwJ5bWjg3CcupFW8lO7F_rPAsU4.N24zCN5F0ix3xZAsII0QomA7HALN1grDDbeyGCG0aOj"</span><span>,</span><span></span></p></div>
```

## Authorization Code Flow with Proof Key for Code Exchange (PKCE)

When native and single-page applications request Access Tokens, there are some additional security concerns because they cannot securely store a Client Secret:

-   **Native apps**: decompiling the app will reveal the Client Secret, which is bound to the app and is the same for all users and devices.
-   **Single-page apps**: their entire source is available to the browser.

The Authorization Code Flow with PKCE introduces a secret created by the calling application that can be verified by the authorization server. This secret is called the **Code Verifier**. The client app creates a transform value of the **Code Verifier** called the **Code Challenge** and sends this value over HTTPS to retrieve an Authorization Code. This way, a malicious attacker can only intercept the Authorization Code, and they cannot exchange it for an access token without the **Code Verifier**.

## [

How it works

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#how-it-works)

## [

How to implement it

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#how-to-implement-it)

### [

Prerequisites

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#prerequisites)

Register your app in the NinjaOne application. To learn more, read [**Register Native Applications**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/create-applications/native-apps) or [**Register Single-Page Web Applications**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/create-applications/single-page-web-apps).

-   Select **Native** or **Single-Page App** as the Application Platform.
-   Add a **Redirect URI(s)**. Your callback URL format will vary depending on your application type and platform.
-   Select the **scope(s)** your application will have access to.
-   Make sure your application's Grant Types include **Authorization Code**.

### [

Create code verifier

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#create-code-verifier)

Create a `code_verifier`, which is a cryptographically random key that will eventually be sent to the NinjaOne Authorization Server to request tokens.

**Javascript sample**

This example depends on node.js crypto module. To learn more visit [https://nodejs.org/api/crypto.html#crypto\_crypto](https://nodejs.org/api/crypto.html#crypto_crypto)

```
<div id="code-lang-javascript"><div><p><span>function</span><span> </span><span>base64URLEncode</span><span>(</span><span>str</span><span>)</span><span> </span><span>{</span><span></span></p></div><div><p><span></span><span>var</span><span> verifier </span><span>=</span><span> </span><span>base64URLEncode</span><span>(</span><span>crypto</span><span>.</span><span>randomBytes</span><span>(</span><span>32</span><span>)</span><span>)</span></p></div></div>
```

### [

Create code challenge

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#create-code-challenge)

Generate a `code_challenge` from the `code_verifier` that will be sent to the NinjaOne Authorization Server to request an `authorization_code`.

**Javascript sample**

```
<div id="code-lang-javascript"><div><p><span>function</span><span> </span><span>sha256</span><span>(</span><span>buffer</span><span>)</span><span> </span><span>{</span><span></span></p></div><div><p><span>  </span><span>return</span><span> crypto</span><span>.</span><span>createHash</span><span>(</span><span>'sha256'</span><span>)</span><span>.</span><span>update</span><span>(</span><span>buffer</span><span>)</span><span>.</span><span>digest</span><span>(</span><span>)</span><span></span></p></div><div><p><span></span><span>var</span><span> challenge </span><span>=</span><span> </span><span>base64URLEncode</span><span>(</span><span>sha256</span><span>(</span><span>verifier</span><span>)</span><span>)</span></p></div></div>
```

### [

Authorize user

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#authorize-user)

Once you've created the `code_verifier` and the `code_challenge`, you must get the user's authorization. To authorize the user, your app must send the user to `/oauth/authorize` URL, including the `code_challenge` you generated in the previous step and the **method** you used to generate the `code_challenge`.

### [

Authorization URL example

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#authorization-url-example)

```
<div id="code-lang-raw"><div><p><span>https://{app|eu|oc}.ninjarmm.com/ws/oauth/authorize?</span></p></div><div><p><span>    client_id=YOUR_CLIENT_ID&amp;</span></p></div><div><p><span>    redirect_uri=https://YOUR_APP_REDIRECT_URL&amp;</span></p></div><div><p><span>    code_challenge=CODE_CHALLENGE&amp;</span></p></div><div><p><span>    code_challenge_method=S256&amp;</span></p></div></div>
```

**Parameters**

| Name | Description |
| --- | --- |
| `response_type` | Set this to `code`. |
| `client_id` | Your application's Client ID |
| `code_challenge` | Generated challenge from the `code_verifier`. |
| `code_challenge_method` | Method used to generate the challenge (e.g., S256). The PKCE spec defines two methods, `S256` and `plain`. The above example uses `S256`. |
| `redirect_uri` | The URL to which NinjaOne will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the code URL parameter. |
| `scope` | A space-separated list of the application scopes that you’d like to authenticate the user for. This defaults to all of the scopes configured for the application in its configuration. |
| `state` | A custom string of your choice. This parameter can be used to identify a user on redirect, as well as a CSRF protection mechanism if it contains a random value per request. |

**Response**

If all goes well, you'll receive an HTTP 307 response. The authorization `code` is included in the redirect URL.

### [

Request tokens

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#request-tokens)

Now that you have an Authorization Code, you must exchange it for tokens. Using the extracted Authorization Code (`code`) from the previous step, you will need to POST to the token endpoint, sending the `code_verifier`.

**Parameters**

| Name | Description |
| --- | --- |
| `grant_type` | Set this to `authorization_code`. |
| `client_id` | Your application's Client ID. |
| `code_verifier` | The generated cryptographically-random key. |
| `redirect_uri` | This must exactly match the `redirect_uri` passed to the authorization URL in the previous step. |

**Try out POST to token**

POST

https://tsargent.rmmservice.com/ws/oauth/token

**Response**

If all goes well, you'll receive an HTTP 200 response with a payload containing `access_token`, `expires_in`, `scope` and `token_type` values:

```
<div id="code-lang-json"><p><span>  </span><span>"access_token"</span><span>:</span><span> </span><span>"Qu5h5FzU9s_Dz7n4ZwJ5bWjg3CcupFW8lO7F_rPAsU4.N24zCN5F0ix3xZAsII0QomA7HALN1grDDbeyGCG0aOj"</span><span>,</span><span></span></p></div>
```

## Implicit Flow

Use this flow if you need to request access tokens with a very short lifespan (1h by default) while logging the user in so you can call your API.

## [

How it works

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#how-it-works)

## [

How to implement it

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#how-to-implement-it)

### [

Prerequisites

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#prerequisites)

Register your app in the NinjaOne application. To learn more, read [**Register Single-Page Web Applications**](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/authorization/create-applications/single-page-web-apps)

-   Select **Single-Page App** as the Application Platform.
-   Add a **Redirect URI(s)**.
-   Select the **scope(s)** your application will have access to.
-   Make sure your application's Grant Types include **Implicit**.

### [

Authorize user

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#authorize-user)

To begin the flow, you'll need to get the user's authorization. This step may include one or more of the following processes:

-   Authenticating the user;
-   Redirecting the user to the NinjaOne application to handle authentication;
-   Obtaining user consent for the requested permission level, unless consent has been previously given and remembered.

### [

Authorization URL example

](chrome-extension://pcmpcfapbekmbjjkdalcgopdkipoggdi/apidocs-beta/#authorization-url-example)

```
<div id="code-lang-raw"><div><p><span>https://{app|eu|oc}.ninjarmm.com/ws/oauth/authorize?</span></p></div><div><p><span>    client_id=YOUR_CLIENT_ID&amp;</span></p></div><div><p><span>    redirect_uri=https://YOUR_APP_REDIRECT_URL&amp;</span></p></div></div>
```

**Parameters**

| Name | Description |
| --- | --- |
| `response_type` | Set this to `token`. |
| `client_id` | Your application's Client ID |
| `redirect_uri` | The URL to which NinjaOne will redirect the browser after authorization has been granted by the user. |
| `scope` | A space-separated list of the application scopes that you’d like to authenticate the user for. This defaults to all of the scopes configured for the application in its configuration. |
| `state` | A custom string of your choice. This parameter can be used to identify a user on redirect, as well as a CSRF protection mechanism if it contains a random value per request. |

**Response**

If all goes well, you'll receive an HTTP 307 response containing `access_token`, `expires_in`, `scope` and `token_type` values in the query string parameters:

| Name | Description |
| --- | --- |
| `access_token` | The requested access token. |
| `expires_in` | The time in seconds by which this token will expire. |
| `scope` | The requested scope(s) associated with the `access_token`. |
| `token_type` | The type of access token returned. |