- 28 Nov 2022
-
DarkLight
-
PDF
Encoding Request Values
- Updated on 28 Nov 2022
-
DarkLight
-
PDF
Scenario
This system requires encoding data in the body of the token request. To show that you can do both encoding and encrypting, we have altered the schema slightly.
In the schema, we are encoding the username by turning the encode flag to true. This does not encode the key - just the data.
In the schema, we are encrypting the password using AES encryption with the provided key. Encryption will only happen when the key is provided. Similar with the username, the key will not be encrypted, just the data.
Changes to the Request Schema File:
-
This is where you need to tell the adapter library where to look for the token.
-
The new placement field tells the adapter library to find the token in the header.
-
The external name field still tells it where to find the token, but in this instance, it is which header.
-
For encoding, all you need to do is turn the encoding field boolean to
true
. -
For encryption, you need to provide the actual type of encryption and a key to be used for encrypting. AES is currently the only type of encryption that is supported since this is not a common occurence. Additional encryption techniques can be added in the future if and when they are needed.
Request Schema Example
{
"$id": "oAuthTokenRequest.json",
"type": "object",
"schema": "http://json-schema.org/draft-07/schema#",
"translate": true,
"dynamicfields": true,
"properties": {
"ph_request_type": {
"type": "string",
"description": "type of request(internal to adapter)",
"default": "getToken",
"enum": [
"getToken"
],
"external_name": "ph_request_type"
},
"username": {
"type": "string",
"description": "username to login with",
"encode": true,
"external_name": "username"
},
"password": {
"type": "string",
"description": "password to login with",
"encrypt": {
"type": "AES",
"key": "myspecialkey"
},
"external_name": "password"
}
},
"definitions": {}
}