WebAPI Common Information
WebAPI Common Information
- All APIs are accessed via HTTPS communication.
- All APIs are called by specifying the API name as a path under
https://fss-app.yubion.com/api/
. - All HTTP methods are requested with
POST
. - All APIs except
getNonce
require the setting of common HTTP headers and the sending of authentication information in the headers, as described later. - Sending of API parameters and reception of request results are all done in JSON format.
- Some requests that need to be processed consecutively (FIDO authentication registration/authentication processing) require cookie retention.
Common HTTP Headers for API Requests
Header Name | Content |
---|---|
X-Fss-Rp-Id | RP ID of the RP to be processed |
X-Fss-Api-Auth-Id | API key ID used for authentication |
X-Fss-Auth-Body-Hash | (Nonce signature authentication / Date signature authentication) Base64Url encoded string of the SHA-256 hash value of the request body part used for the signature |
X-Fss-Auth-Signature | (Nonce signature authentication / Date signature authentication) Base64Url encoded string of the byte string (Raw/P1363 Format) of the signature result |
X-Fss-Auth-Nonce | (Nonce signature authentication) Nonce value obtained with getNonce |
X-Fss-Auth-Request-Time | (Date signature authentication) String representing the signature date and time in ISO8601 format |
X-Fss-Auth-Access-Key | (Access key authentication) Access key |
Info
The API log records the content of the User-Agent header and the first global IP address that appears in the X-Forwarded-For header or the Remote-Addr header (closer to the request source).
API Authentication Methods
Three types of API authentication methods are provided.
Type | Description |
---|---|
Nonce sign auth | Signatures are created and verified using a Nonce (random value) provided by FIDO2ServerService. This is the method with the highest level of security; for each API request, a separate communication to obtain the nonce value is made. |
Datetime sign auth | Create and verify signatures using date and time. Compared to Nonce Signature Authentication, this method has a high enough level of security, although theoretically the possibility of replay attacks within a short period of time due to communication eavesdropping occurs. We recommend using this service when you want to reduce various overheads caused by communication to FIDO2ServerService, such as for services with a very large number of users. |
Access key auth | Uses a fixed key and verifies if the key matches. This is a simple method. |
Info
Please see here for how to issue an API key.
Signature Authentication (Nonce Signature Authentication / Date Signature Authentication)
The secret key is the private key information for signature creation (ECDSA P-256, private key information in pkcs8 format Base64Url encoded). Using that private key, a signature is performed on the following concatenated byte string.
[ Data to be signed for each authentication format ] || [ SHA-256 hash value of the request body ]
-
“Data to be signed for each authentication format” is a byte string of the following UTF-8 string.
- Nonce signature authentication
The Nonce string obtained in the getNonce request. This string must be specified in “X-Fss-Auth-Nonce” of the request header. API authentication will fail in the following cases.
- When a Nonce string not issued by the FSS server is used
- When a Nonce string that has already been used is used
- When a certain period of time has passed since the Nonce string was issued
- Date signature authentication A string representing the current date and time in ISO8601 format. This string must be specified in “X-Fss-Auth-Request-Time” of the request header. If there is a difference of 30 seconds or more from the FSS server time, API authentication will fail.
- Nonce signature authentication
The Nonce string obtained in the getNonce request. This string must be specified in “X-Fss-Auth-Nonce” of the request header. API authentication will fail in the following cases.
-
“SHA-256 hash value of the request body” is a byte string of the SHA-256 hash of the request body. It is necessary to specify a Base64Url encoded string of the hash value in “X-Fss-Auth-Body-Hash” of the request header.
-
The signature result is output in 64-byte Raw Format (P1363 Format) with R and S concatenated, and a Base64Url encoded string of it is specified in “X-Fss-Auth-Signature” of the request header.
Info
Signatures in ECDSA format may be output in ASN.1 DER format depending on the library implementation. In that case, conversion to Raw Format is required.
Access Key Authentication
- Specify the issued secret key as it is in “X-Fss-Auth-Access-Key” of the request header.
Warning
Regardless of which authentication method is used, the secret key must be handled so that it is not taken outside the application server. Also, when managing the source in a public repository, please be careful not to publish the secret key on the repository.
API Response Basic Format
The basic format of all API responses is explained.
{
appStatus : "OK",
data : {
...
},
message : "...",
appSubStatus : {
...
},
}
Key | Type | Content |
---|---|---|
appStatus | ApplicationResultStatus | Execution result. “OK” is set for normal operation, and a string indicating an error is set for abnormal operation. (described later) |
data | any | API execution result. It will be null in case of an error. |
message | string | null | Message. A supplementary message is stored when an error occurs. |
appSubStatus | any | null | Execution result supplementary information. Additional information is stored depending on the error content. |
API Execution Result Information (ApplicationResultStatus)
ApplicationResultStatus
takes the following values.
Value | Content |
---|---|
“OK” | Normal |
“UNEXPECTED_ERROR” | Unknown error |
“COMMUNICATION_FAILED” | Communication error |
“BAD_JSON_FORMAT” | A type of argument error. Used when it cannot be correctly interpreted as JSON. |
“PARAMETER_ERROR” | Argument/parameter error |
“INSERT_ERROR” | Insertion failed |
“UPDATE_ERROR” | Update failed |
“DELETE_ERROR” | Deletion failed |
“PROCESS_ERROR” | Other processing failed |
“DUPLICATED” | Duplicate error (error for parameters that do not allow duplicates other than ID. For example, when userName is duplicated in an RP that does not allow userName duplication) |
“NOT_FOUND” | Non-existent error |
“ALREADY_EXISTS” | Registered error (ID duplication) |
“AUTHENTICATION_FAILED” | Authentication failed |
“UNAUTHORIZED” | Session invalid |
“PERMISSION_ERROR” | Permission error |
“ACTIVATION_ERROR” | Activation error |
“LICENSE_ERROR” | License error |
Detailed Error Information during FIDO Authentication Registration/Authentication Processing
When an error occurs in FIDO authentication registration/authentication processing (registerCredential/xxx, authenticate/xxx), the errorCode
property may be set in appSubStatus.
{
appStatus : "PARAMETER_ERROR",
message : "...",
appSubStatus : {
errorCode : "",
...
},
}
This errorCode
takes the following values.
Value | Content |
---|---|
“USER_NOT_FOUND” | User does not exist |
“REQUIRE_USER_NAME” | User name must be specified |
“REQUIRE_USER_ID_OR_USER_HANDLE” | User ID or UserHandle must be specified |
“USER_IS_DISABLED” | User is disabled |
“USER_HANDLE_NOT_MATCH” | UserHandle is not the expected value |
“CREDENTIAL_NOT_FOUND” | Credential does not exist |
“REQUIRE_CREDENTIAL_ID” | Credential ID must be specified |
“CREDENTIAL_IS_DISABLED” | Credential is disabled |
“CREDENTIAL_ID_MISMATCH” | Credential ID is not the expected value |
“BAD_CREDENTIAL_TYPE” | Invalid credential type |
“CREDENTIAL_ALREADY_REGISTERED” | Credential already exists |
“CLIENT_DATA_JSON_PARSE_FAILED” | Failed to parse ClientDataJSON |
“REQUIRE_ATTESTED_CREDENTIAL_DATA” | (At registration) AttestedCredentialData does not exist |
“BAD_REQUEST_TYPE” | Invalid request type |
“RP_NOT_FOUND” | RP does not exist |
“RP_ID_HASH_MISMATCH” | rpIdHash does not match the hash of the RP ID |
“ORIGIN_NOT_ALLOWED” | Origin is not allowed |
“REQUIRE_USER_VERIFICATION” | UserVerification is required (if specified as required at the start) |
“LICENSE_LIMIT_EXCEEDED” | License limit exceeded |
“CREATE_RESPONSE_NOT_FOUND” | Registration response property does not exist |
“REQUEST_RESPONSE_NOT_FOUND” | Authentication response property does not exist |
“ATTESTATION_RESPONSE_NOT_FOUND” | AttestationResponse does not exist |
“ATTESTATION_RESPONSE_PARSE_FAILED” | Failed to parse AttestationResponse |
“INTERNAL_ERROR” | Internal error |
“UNEXPECTED_ERROR” | Unknown error |
“INVALID_SESSION” | Invalid session |