Skip to Main Content

Micro Services

Laboratory for Computer Science Research

Validating Authentication

Once a user completes the login flow for the service, they will be redirected back to the end application with a “Ticket” attached. This Ticket is a unique key that allows the end application to receive information regarding the user and verify their authentication status.

Is up to the application to validate that this Ticket is authentic by communicating with the service. This can happen once (less secure) or multiple times (more secure).

An end application can validate the Ticket via the “Ticket Validation” endpoint, accessible at “/api/v1/tickets/validate/{ticket}”, where {ticket} is the unique Ticket returned to the user after authentication.

Response

After making the above request, the end application will receive either a 200 OK status code with data attached or a failure 400 Bad Request status code. If the latter is received, the end application should assume that the Ticket was not valid and that the user is not authenticated. In rare cases, a 500 Internal Server Error status code may be returned. This does not necessarily indicate that the user is not authenticated, but it does indicate that the service was unable to verify that they are authenticated. It is up to the end application on how to handle this condition, although it is recommended to “fail secure” and treat any response other than a 200 OK status code as a rejection (not authenticated).

The body of a 200 OK status code Ticket Validation response is composed of well-formed JSON. A sample response is below.

{
    “status”: “ok”,
    “message”: “Ticket is valid”,
    “data”: {
        “id”: “f683e43c-b414-4a45-9074-ba90a1088d34”,
        “created_at”: “2025-08-22T17:16:49.000000Z”,
        “updated_at”: “2025-08-22T17:16:49.000000Z”,
        “expiry”: “2025-08-22T19:16:49.000000Z”,
        “primary_claim”: “DevelopmentUser”,
        “secondary_claims”: null,
        “primary_claim_original”: “DevelopmentUser”
    }
}
 
 
End applications should utilize the “primary_claim” value within the returned “data” as the user’s main identifier. This identifier should remain constant between Backend Sessions. Data within the “secondary_claims” array, which is empty or null in the above example, may change between Backend Sessions.
 
If “impersonation” is being utilized to simulate login as another user, the impersonated user’s identifier will be available as the “primary_claim”, while the true underlying user’s identifier will be available as the “primary_claim_original”‘s value.