To get started, please see our Get Started with Allie.Chat guide to initially setup your bots, a demo stream, and your first input and output routes.Allie.Chat currently supports incoming message aggregation and forwarding to user created Bots and routes for:
This OAuth token should be private and not available to the public. If for any reason it becomes exposed, you can request a new OAuth token for this bot by clicking on the Reset TokenNext, we will use this OAuth token to make a simple Javascript client to connect to the Allie.Chat Websocket Serer.
<!DOCTYPE html>
<head>
<meta charset="utf-8" />
<title>Simple Websocket Html Client</title>
</head>
<body>
<input type=text id="textInput" placeholder="Enter your text"/>
<button id="sendButton">Send</button>
<ul id="messages"></ul>
<script language="javascript" type="text/javascript">
var uri = "wss://connect.test.allie.chat:7620/c114bfec3c73498aaa24aae65e1c3f063f859ad58b1340e198b5e28e59d4b314";
function connect() {
socket = new WebSocket(uri);
socket.onopen = function(event) {
console.log("opened connection to " + uri);
};
socket.onclose = function(event) {
console.log("closed connection from " + uri);
};
socket.onmessage = function(event) {
appendItem(list, event.data);
console.log(event.data);
};
socket.onerror = function(event) {
console.log("error: " + event.data);
};
}
connect();
var list = document.getElementById("messages");
var button = document.getElementById("sendButton");
button.addEventListener("click", function () {
var input = document.getElementById("textInput");
input.value = "";
});
function sendMessage(message) {
console.log("Sending: " + message);
socket.send(message);
}
function appendItem(list, message) {
var item = document.createElement("li");
item.appendChild(document.createTextNode(message));
list.appendChild(item);
}
</script>
</body>
</html>
Tcp connections can be used to both be a source for inbound messages or be a destination for an outbound route. Tcp services are available through an unsecured Http server or alternatively a secured Https server. .NET external libraries are available for both secure and non-secure servers for ease of use.
The .NET provided library for Tcp connections is available as a nuget package here:
The uncompiled source is also available at the GitHub:
To connect to Allie.Chat with a Tcp bot, you first need to create the Tcp Bot in the web application. Log into https://app.allie.chat and navigate to bots. Select Tcp Bot from the dropdown and click Create. Give your new Tcp Bot a username (and avatar image link if you like), and click save. Your new Tcp Bot has an OAuth token registered to it which is needed in order to connect the bot the Allie.Chat Tcp Servers.
The difference between the unsecured and SSL servers is the there will be a lower rate limit and lower security protection through the unsecured Http server, and a higher rate limit but greater security through the secured https server.To create a manual connection in the language of your choice connect your Tcp Client to the following url:
- Uri: connect.allie.chat
- Unsecured Port: 7610
- Secured SSL Port: 7615
End of line characters on both secured and unsecured servers are "\r\n", which is commonly a newline indicator.
Once you make an initial connection, you must send your Bot's OAuth token to authorize your session on the Tcp server. Failure to send the OAuth token as the first message sent to the server will result in disconnect of the session. Your OAuth token is generated at https://app.allie.chat by logging in, navigating to bots, and creating a Tcp bot. Then click on the created Tcp bot, and you can reveal the bot's OAuth token at the bottom of the page.
Messages are routed to the bot you logged in based on the inbound and outbound paths of streams connected to the bot.When you submit this OAuth token as your first message to the server, your message should be sending raw text and formatted as below:
- oauth:OAuth oken
An example including the end of line characters could be sent as a byte array converted from the string:
- oauth:582e9fn3832fnsa83uf3\r\n
Websocket connections can be used to both be a source for inbound messages or be a destination for an outbound route. Websocket services are available through a secured websocket connection only. .NET external libraries are available for the secured Websocket server for ease of use.
The .NET provided library for Websocket connections is available as a nuget package here:
The uncompiled source is also available at the Github:
To connect to Allie.Chat with a Websocket bot, you first need to create the Websocket Bot in the web application. Log into https://app.allie.chat and navigate to bots. Select Websocket Bot from the dropdown and click Create. Give your new Websocket Bot a username (and avatar image link if you like), and click Save. Your new Websocket Bot has an OAuth token registered to it which is needed in order to connect the bot the Allie.Chat Websocket Servers.
You must send append your Websocket Bot's OAuth token to authorize your session on the Websocket server. Failure to append the OAuth token to the connection Uri will result in disconnection of the session.
To create a manual connection to the Websocket server in your language of choice, you must connect to the url below and add the OAuth token for your desired Websocket Bot:
- Uri: wss://connect.allie.chat:7610/OAuth token
- Secured Port: 7610
An example of a connect url is below:
- wss://connect.allie.chat/sdofis7853oif23892ojkfuisduf923kwdio2
Because this is for Websocket connections, there are no end-of-line characters.
Messages are routed to the bot you logged in based on the inbound and outbound paths of streams connected to the bot.
Allie.Chat includes a currency system where you can define your own currency and reward it to your community members. In the Allie.Chat web application, you first need to create a Currency from the top navigation. Then in the Stream of your choice, enable Commands from the check boxes, and add the Currency of your choice to the Stream.
One of the fields when creating a Stream Currency is the interval in minutes that the currency accrues - this is only half of the equation. We will also have to define status for our Stream Users which can vary the amount of currency users accrue per time interval by their respective status.
After a Stream Currency is created, we need to define the providers that accrue the currency and the status which define the amount of currency users' accrue since their last activity (or messages received). The providers registered to a Stream can be any provider type that is not Websocket or Tcp. Providers are registered by selecting the appropriate Stream, selecting the registered Stream Currency, and adding or removing the Stream Currency Providers from the appropriate panel.
The users online in a Stream will accrue currency based upon their status, and status the amount of currency available to each user can be reported by inputting the prefix of the currency followed by the currency name in any of the input routes for the stream. For example, if I created a currency called pixels with the prefix !, then I could report my own accrued pixels by typing !pixels.
Allie.Chat has a comprehendive WebAPI and the Documentation / Swagger is available at:
| Authorization Type | Accesss User Resources | Requires Secret Key (Server-Side) | Access Token Refresh | Native Application |
|---|---|---|---|---|
| Authorization Code | Yes | Yes | Yes | No |
| Client Credentials | No | Yes | No | No |
| Implicit | Yes | No | No | No |
| PKCE Authorization Code | Yes | No | No | Yes |
Additional scopes can be created for your own WebAPIs in Api Resources inside of https://app.allie.chat. Scopes should be assigned to both Client Applications and their authorized Api Resources.Default scopes provided with Allie.Chat:
- openid
- profile
- Allie.Chat.WebAPI
To allow your Client Application to use Allie.Chat for Authorization and access an OIDC WebAPI / Resource Server of your choice, make sure to use the same scopes for both the Client Application and the Api Resource.For example, the scope for a webapi using Allie.Chat as an authorization server could be myTestApi.Test.Api. This scope would need to be registered both to the Allie.Chat Client Application as well as the registered Api Resource on the Allie.Chat Web Application.
All Client Applications should have scopes registered to them that can be specified when requesting User Tokens, and User Tokens are requested with scopes to determine which identity resources and resource servers they are able to access.
The Implicit grant flow is for
Client Applications that are implemented entirely in
JavaScript or Typescript and run in a browser
.
You do not need any server-side code to use Implicit grant flow. The rate limits for requests are improved
over the other authorization flows but no refresh tokens are provided. This flow is described in more detail at
RFC-6749.
To use Implicit grant flow, first direct a user to the Allie.Chat Identity Server Authorize Url . You will receive an access token. This token, based on the scopes you requested, can be used to access the Allie.Chat WebAPI.Implicit grant flow is carried out on the client and does not involve secret keys. The access tokens that are issued are short-lived and no refresh tokens are issued to extend them when they expire.
Have your Client Application request authorization by redirecting your User to the /authorize endpoint of the Allie.Chat Identity Server:Your request needs to include the following parameters in the query string:
| Query String Parameter | Value |
|---|---|
| client_id |
Required
The Client Id you provided the Allie.Chat Web Application when you registered your Client Application. |
| response_type |
Required
Set it to token. |
| redirect_uri |
Required
The Uri to redirect your User after he or she grants or denies permission. This Uri needs to be input in the Uri Redirect list that you specify when you register or edit your Client Application. |
| state |
Optional but recommended
The state can be a useful query parameter for matching requests and responses. The redirect_uri you specify can be tracked and is not secure, but using a state value can increase your assurance that the incoming connection is the result of a valid authentication request. To use state, generate a random string or encode the hash of some client state (e.g., a cookie or unique temporary value) and assign it to this state variable. This process will validate the response to ensure that the request and response originated from the same browser. Inclusion of state provides some protection against attacks such as cross-site request forgery. For more information, please reference RFC-6749. |
| scope |
Optional but recommended
A space-separated list of scopes: see Scopes. |
If the user grants access, the final Uri will contain the following data encoded as a query string. For example:
https://example.com/uriToRedirectTo#access_token=ey8sDiKSDI...VRF4234&token_type=Bearer&expires_in=3600&state=123
| Query String Parameter | Value |
|---|---|
| access_token | An access token that can be provided in subsequent calls, for example to the Allie.Chat WebAPI. |
| token_type | Value: “Bearer” |
| expires_in | The time period (in seconds) for which the access token is valid. |
| state | The value of the state parameter supplied in the request. |
If the user denies access, the access token is not included and the final Uri includes a query string containing the following data encoded as a query string. For example:
https://example.com/uriToRedirectTo?error=access_denied&state=123
| Query String Parameter | Value |
|---|---|
| error | The reason the authorization failed, for example: “access_denied”. |
| state | The value of the state parameter supplied in the request. |
Use the access token to access the Allie.Chat WebAPI
$.ajax({
url: 'https://api.allie.chat/ApplicationUser',
headers: {
'Authorization': 'Bearer ' + accessToken
},
success: function(response) {
...
}
});
The Resource Owner Password Grant Flow is suitable for cases where the
Client Application has a trusted
relationship with the client, such as the device operating system or a highly privileged application
.
This grant type is suitable for Client Applications capable of obtaining a username and password, for example
with an interactive form.
This flow provides an access token that can be refreshed using the included refresh token.
Since this flow involves sending your secret key, it needs to be performed on a secure location,
such as a backend service, and not from a client such as a browser or from a mobile app. For further information about this
flow, see RFC-6749
To use Resource Owner Password Grant Flow, first collect the User's credentials and then issue a post to the Allie.Chat Identity Server Token Endpoint . On successful authentication, you will receive an access token and a refresh token.Since Resource Owner Password Grant Flow token exchange uses your Client Application secret key, to keep the integrity of the key, you should make that request server-side.
Your application sends a request to the Allie.Chat Identity Server Token Uri. The POST request is sent to the /token endpoint of the Identity Server:
A typical request is the POST request of the /token endpoint and using the 'application/x-www-form-urlencoded' format with a character encoding of UTF-8 containing the following information:
| Query String Parameter | Value |
|---|---|
| client_id |
Required
When you register your application with Allie.Chat, you specify a unique client id. |
| client_secret |
Required
When you register your application with Allie.Chat, you specify or retrieve the unique client secret. Note: This key should not be publically available |
| response_type |
Required
Set to password. |
| username |
Required
The username for the resource owner that will be used to exchange for an access token. |
| password |
Required
The password for the resource owner that will be used to exchange for an access token. |
| scope |
Required
A space-separated list of scopes. If no scopes are specified, authorization will not be granted. |
| Key | Value Type | Value Description |
|---|---|---|
| access_token | string | An access token that can be provided in subsequent calls, for example to Allie.Chat WebAPI services. |
| token_type | string | How the access token may be used: always “Bearer”. |
| scope | string | A space-separated list of scopes which have been granted for this access_token |
| expires_in | int | The time period (in seconds) for which the access token is valid. |
| refresh_token | string | A token that can be sent to the Allie.Chat Identity Server in place of an authorization code. (When the access code expires, send a POST request to the Identity Server /connect/token endpoint, but use this code in place of an authorization code. A new access token will be returned. A new refresh token might be returned too.) |
An example cURL request and response from the token endpoint will look something like this:
curl -d grant_type=password -d username=inputUsername -d password=inputPassword -d client_id=inputClientId -d client_secret=inputClientSecret -d scope=openid profile Allie.Chat.WebAPI https://identity.allie.chat/connect/token
{
"access_token": "NgCXRK...MzYjw",
"token_type": "Bearer",
"scope": "openid profile Allie.Chat.WebAPI",
"expires_in": 3600,
"refresh_token": "NgAagA...Um_SHo"
}Use the access token to access the Allie.Chat WebAPI; Allie.Chat returns requested data
The access token allows you to make requests to the Allie.Chat WebAPI on behalf of a User, for example:
curl -H "Authorization: Bearer NgCXRK...MzYjw" https://api.allie.chat/ApplicationUser
{
"display_name":"TestUser1",
"username": "TestUser1",
"email":"testUserEmail@testUser.com",
}Requesting a refreshed access token; The Allie.Chat Identity Server returns a new access token to your Client Application
Access tokens are deliberately set to expire after a short time, after which new tokens may be granted by supplying the refresh token originally obtained during the Resource Owner Password Grant Token exchange.
The request is sent to the token endpoint of the Allie.Chat Identity Server:
POST https://identity.allie.chat/connect/token
| Request Body Parameter | Value |
|---|---|
| grant_type |
Required
Set it to refresh_token. |
| refresh_token |
Required
The refresh token returned from the authorization code exchange. |
| Header Parameter | Value |
|---|---|
| Authorization |
Required
Base 64 encoded string that contains the client ID and client secret key. The field must have the format: Authorization: Basic |
Example
curl -H "Authorization: Basic ZjM4Zj...Y0MzE=" -d grant_type=refresh_token -d refresh_token=NgAagA...NUm_SHo https://identity.allie.chat/connect/token
{ "access_token": "NgA6ZcYI...ixn8bUQ", "token_type": "Bearer", "scope": "openid profile Allie.Chat.WebAPI", "expires_in": 3600 }
The Authorization Code Flow is suitable for long-running applications in which the User grants permission only once.
It provides an access token that can be refreshed.
Since this flow involves sending your secret key, it needs to be performed on a secure location,
such as a backend service, and not from a client such as a browser or from a mobile app. For further information about this
flow, see RFC-6749
To use Authorization Code Flow, first direct your User to the Allie.Chat Identity Server Authorize Endpoint where they can choose to grant access to their data. If successful, and you will receive an authorization token which you can submit to the Allie.Chat Identity Server Token Endpoint and receive back an access_token and a refresh token.Since Authorization Code token exchange uses your client secret key, to keep the integrity of the key, you should make that request server-side.
Your application sends a request to the Allie.Chat Identity Server. The GET request is sent to the /authorize endpoint of the Identity Server:
| Query String Parameter | Value |
|---|---|
| client_id |
Required
When you register your application with Allie.Chat, you specify a unique client id. |
| response_type |
Required
Set to code. |
| redirect_uri |
Required
The Uri to redirect your User after they grant or deny permission. The Uri needs to have been entered in the Redirect Uri list that you specified when you registered your Client Application. The value of redirect_uri here must exactly match one of the values you entered when you registered your Client Application, including upper or lowercase, terminating slashes, and or any other characters. |
| scope |
Required
A space-separated list of scopes. If no scopes are specified, authorization will not be authorized. |
| state | Optional but recommended The state can be useful for correlating requests and responses. Your redirect_uri is not secure, but using a state value can increase your assurance that an incoming connection is the result of an authentication request. Set state to a randomly generated string, or encode the hash of some client state, such as a cookie or unique identifier, and you can validate the response to additionally ensure that both the request and response originated from the same browser. This provides protection against attacks such as cross-site request forgery. See RFC-6749. |
Example:
A typical request is the GET request of the /authorize endpoint, followed by the query:
https://identity.allie.chat/connect/authorize?client_id=5fe01282e44241328a84e7c5cc169165&response_type=code&
redirect_uri=https%3A%2F%2Fexample.com%2Fcallback&scope=openid%20profile%20Allie.Chat.WebAPI&state=34fFs29kd09
If the User accepts your request, the Authorization Uri redirect will contain the following data encoded as a query string. For example:
https://example.com/uriToRedirectTo?code=NApCCg..BkWtQ&state=profile%2Factivity
| Query Values Parameter | Value |
|---|---|
| code | An authorization code that can be exchanged for an access token. |
| state | The value of the state parameter supplied in the request. |
If the user denies access, the access token is not included and the Authorization Uri redirect includes a query string containing the following data. For example:
https://example.com/uriToRedirectTo?error=access_denied&state=STATE
| Query String Parameter | Value |
|---|---|
| error | The reason authorization failed, for example: “access_denied” |
| state | The value of the state parameter supplied in the request. |
Have your application request refresh and access tokens; Allie.Chat returns access and refresh tokens
When the authorization code has been received, you will need to exchange it with an access token by making a POST request to the Allie.Chat Identity Server, this time to its /api/token endpoint: POST https://identity.allie.chat/connect/token The body of this POST request must contain the following parameters encoded in ´application/x-www-form-urlencoded as defined in the OAuth 2.0 specification:
| Request Body Parameter | Value |
|---|---|
| grant_type |
Required
As defined in the OAuth 2.0 specification, this field must contain the value "authorization_code". |
| code |
Required
The authorization code returned from the initial request to the Account /authorize endpoint. |
| redirect_uri |
Required
This parameter is used for validation only (there is no actual redirection). The value of this parameter must exactly match the value of redirect_uri supplied when requesting the authorization code. |
| Header Parameter | Value |
|---|---|
| Authorization |
Required
Base 64 encoded string that contains the client ID and client secret key. The field must have the format: Authorization: Basic * |
| Key | Value Type | Value Description |
|---|---|---|
| access_token | string | An access token that can be provided in subsequent calls, for example to Allie.Chat WebAPI services. |
| token_type | string | How the access token may be used: always “Bearer”. |
| scope | string | A space-separated list of scopes which have been granted for this access_token |
| expires_in | int | The time period (in seconds) for which the access token is valid. |
| refresh_token | string | A token that can be sent to the Allie.Chat Identity Server in place of an authorization code. (When the access code expires, send a POST request to the Identity Server /connect/token endpoint, but use this code in place of an authorization code. A new access token will be returned. A new refresh token might be returned too.) |
{
"access_token": "NgCXRK...MzYjw",
"token_type": "Bearer",
"scope": "openid profile Allie.Chat.WebAPI",
"expires_in": 3600,
"refresh_token": "NgAagA...Um_SHo"
}Use the access token to access the Allie.Chat WebAPI; Allie.Chat returns requested data
The access token allows you to make requests to the Allie.Chat WebAPI on behalf of a User, for example:
curl -H "Authorization: Bearer NgCXRK...MzYjw" https://api.allie.chat/ApplicationUser
{
"display_name":"TestUser1",
"username": "TestUser1",
"email":"testUserEmail@testUser.com",
}Requesting a refreshed access token; The Allie.Chat Identity Server returns a new access token to your Client Application
Access tokens are deliberately set to expire after a short time, after which new tokens may be granted by supplying the refresh token originally obtained during the Authorization Code exchange.
The request is sent to the token endpoint of the Allie.Chat Identity Server:
POST https://identity.allie.chat/connect/token
| Request Body Parameter | Value |
|---|---|
| grant_type | Required Set it to refresh_token. |
| refresh_token |
Required
The refresh token returned from the authorization code exchange. |
| Header Parameter | Value |
|---|---|
| Authorization |
Required
Base 64 encoded string that contains the client ID and client secret key. The field must have the format: Authorization: Basic |
Example
curl -H "Authorization: Basic ZjM4Zj...Y0MzE=" -d grant_type=refresh_token -d refresh_token=NgAagA...NUm_SHo https://identity.allie.chat/connect/token
{ "access_token": "NgA6ZcYI...ixn8bUQ", "token_type": "Bearer", "scope": "openid profile Allie.Chat.WebAPI", "expires_in": 3600 }
The Authorization Code PKCE (Proof Key for Code Exchange) Grant Flow is an extension to the Authorization Code Grant Flow but designed to prevent certain attacks and allows for secure Token exchange from public clients. OAuth public clients are susceptible to authorization code intercept attacks where the attacker intercepts the Authorization Code returns from the Authorization endpoint within a communication path not protected by Transport Layer Security (TLS). An example could be an inter-application communication within the client's operating system. It is possible for a malicious app to register itself as a handler for the scheme in addition to the legitimate OAuth 2.0 Client Application. Once it is registered, the malicious Client Application is able to intercept the authorization token. The attacker can then use this authorization code to obtain an access token. A number of pre-conditions need to exist for this to work:
To mitigate this attack, Authorization Code PKCE Grant Flow uses a dynamically created cryptographically random key called 'code verifier'. A unique code verifier is created for every authorization request, and its transformed value, called 'code challenge', is sent to the authorization server to obtain the authorization code. The authorization code obtained is sent to the token endpoint with the 'code verifier', and the server compares it with the previously received request code so it can perform the proof of possession of the 'code verifier' by the client. For further information about Authorization Code PKCE Grant Flow, see RFC-7636Secrets provisioned in binary for Client Applications running on a Client's device Cannot be considered confidential
To use Authorization Code PKCE Grant Flow, the Client Application first creates and records a secret named the code_verifier and uses a transformation method to create a transformed version called the code_challenge The code_challenge, as well as the transformation method are sent in the Authorization Request to the Allie.Chat Identity Server Authorize Endpoint where the User can choose to grant access to data. If authorization was successful, you will receive back an authorization token which you submit along with the code_verifier you generated in the Authorization request to the Allie.Chat Identity Server Token Endpoint , and you will receive an access token and a refresh token.
Your Client Application creates a code verifier, which is a high-entropy cryptographic random string using unreserved characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~". The code verifier should have enough entropy to make it impractical to guess the value.
The Client Application then creates a code_challenge derived from the code_verifier by using one of the following transformations:If the Client Application is capable of using S256, it must use S256. Client Applications are only permitted to use plain if they cannot support S256 for a technical limitation or if it is a unique implementation where the server only supports plain.
- plain - code_challenge = code_verifier
- S256 - Base64UrlEncode(Sha256(ASCII(code_verifier)))
Your application sends a request to the Allie.Chat Identity Server. The GET request is sent to the /authorize endpoint of the Identity Server:
| Query String Parameter | Value |
|---|---|
| code_challenge |
Required
The code_challenge generated in the 2nd step. |
| code_challenge_method |
Optional but recommended
Set it to either "S256" or "plain" The code_challenge_method defaults to plain if not present in the request. |
| client_id |
Required
When you register your application with Allie.Chat, you specify a unique client id. |
| response_type |
Required
Set to code. |
| redirect_uri |
Required
The Uri to redirect your User after they grant or deny permission. The Uri needs to have been entered in the Redirect Uri list that you specified when you registered your Client Application. The value of redirect_uri here must exactly match one of the values you entered when you registered your Client Application, including upper or lowercase, terminating slashes, and or any other characters. |
| scope |
Required
A space-separated list of scopes. If no scopes are specified, authorization will not be authorized. |
| state | Optional but recommended The state can be useful for correlating requests and responses. Your redirect_uri is not secure, but using a state value can increase your assurance that an incoming connection is the result of an authentication request. Set state to a randomly generated string, or encode the hash of some client state, such as a cookie or unique identifier, and you can validate the response to additionally ensure that both the request and response originated from the same browser. This provides protection against attacks such as cross-site request forgery. See RFC-6749. |
Example:
A typical request is the GET request of the /authorize endpoint, followed by the query:
https://identity.allie.chat/connect/authorize?client_id=5fe01282e44241328a84e7c5cc169165&response_type=code&
redirect_uri=https%3A%2F%2Fexample.com%2Fcallback&scope=openid%20profile%20Allie.Chat.WebAPI&state=34fFs29kd09&
code_challenge=43dfsf67GDUIDi35i2FKFJIASAQQYLBP69_432fSDFUS&code_challenge_method=S256
If the User accepts your request, the Authorization Uri redirect will contain the following data encoded as a query string. For example:
https://example.com/uriToRedirectTo?code=NApCCg..BkWtQ&state=profile%2Factivity
| Query Values Parameter | Value |
|---|---|
| code | An authorization code that can be exchanged for an access token. |
| state | The value of the state parameter supplied in the request. |
If the user denies access, the access token is not included and the Authorization Uri redirect includes a query string containing the following data. For example:
https://example.com/uriToRedirectTo?error=access_denied&state=STATE
| Query String Parameter | Value |
|---|---|
| error | The reason authorization failed, for example: “access_denied” |
| state | The value of the state parameter supplied in the request. |
Have your application request refresh and access tokens; Allie.Chat returns access and refresh tokens
When the authorization code has been received, you will need to exchange it with an access token by making a POST request to the Allie.Chat Identity Server, this time to its /api/token endpoint: POST https://identity.allie.chat/connect/token The body of this POST request must contain the following parameters encoded in ´application/x-www-form-urlencoded as defined in the OAuth 2.0 specification:
| Request Body Parameter | Value |
|---|---|
| code_verifier |
Required
The code_verifier generated in Step 1. |
| grant_type |
Required
As defined in the OAuth 2.0 specification, this field must contain the value "authorization_code". |
| code |
Required
The authorization code returned from the initial request to the Account /authorize endpoint. |
| redirect_uri |
Required
This parameter is used for validation only (there is no actual redirection). The value of this parameter must exactly match the value of redirect_uri supplied when requesting the authorization code. |
| Header Parameter | Value |
|---|---|
| Authorization |
Required
Base 64 encoded string that contains the client ID and client secret key. The field must have the format: Authorization: Basic * |
| Key | Value Type | Value Description |
|---|---|---|
| access_token | string | An access token that can be provided in subsequent calls, for example to Allie.Chat WebAPI services. |
| token_type | string | How the access token may be used: always “Bearer”. |
| scope | string | A space-separated list of scopes which have been granted for this access_token |
| expires_in | int | The time period (in seconds) for which the access token is valid. |
| refresh_token | string | A token that can be sent to the Allie.Chat Identity Server in place of an authorization code. (When the access code expires, send a POST request to the Identity Server /connect/token endpoint, but use this code in place of an authorization code. A new access token will be returned. A new refresh token might be returned too.) |
{
"access_token": "NgCXRK...MzYjw",
"token_type": "Bearer",
"scope": "openid profile Allie.Chat.WebAPI",
"expires_in": 3600,
"refresh_token": "NgAagA...Um_SHo"
}Use the access token to access the Allie.Chat WebAPI; Allie.Chat returns requested data
The access token allows you to make requests to the Allie.Chat WebAPI on behalf of a User, for example:
curl -H "Authorization: Bearer NgCXRK...MzYjw" https://api.allie.chat/ApplicationUser
{
"display_name":"TestUser1",
"username": "TestUser1",
"email":"testUserEmail@testUser.com",
}Requesting a refreshed access token; The Allie.Chat Identity Server returns a new access token to your Client Application
Access tokens are deliberately set to expire after a short time, after which new tokens may be granted by supplying the refresh token originally obtained during the Authorization Code exchange.
The request is sent to the token endpoint of the Allie.Chat Identity Server:
POST https://identity.allie.chat/connect/token
| Request Body Parameter | Value |
|---|---|
| grant_type | Required Set it to refresh_token. |
| refresh_token |
Required
The refresh token returned from the authorization code exchange. |
| Header Parameter | Value |
|---|---|
| Authorization |
Required
Base 64 encoded string that contains the client ID and client secret key. The field must have the format: Authorization: Basic |
Example
curl -H "Authorization: Basic ZjM4Zj...Y0MzE=" -d grant_type=refresh_token -d refresh_token=NgAagA...NUm_SHo https://identity.allie.chat/connect/token
{ "access_token": "NgA6ZcYI...ixn8bUQ", "token_type": "Bearer", "scope": "openid profile Allie.Chat.WebAPI", "expires_in": 3600 }