Validating the access token (non-standard)

Archie provides a mechanism for validating and obtaining information about an access token. If the OAuth 2.0 authorization framework is used for single sign on only by a public client it is important to validate the token to ensure that the request to the redirect URI is genuine. 

To validate a token, make a GET or POST request to the token information endpoint (see above) with the following query parameters included:

access_token (required): The token to be validated. This can also be provided in the Authorization header in the form: Bearer [access token] 

include_permissions (optional):  Value can be "true" or "false" (default). Specifies whether the response should include information about the end user's Archie permissions within the scope of the access token.

detailed (optional):  Value can be "true" or "false" (default). Specifies whether the response should include the following information in the response: user_id, name (combined), first_name, last_name and email.

The response is a JSON object (MIME type "application/json") like this:

{
    "user_name": "testuser",
    "scope": "document",
    "expires_in": "2410",
    "client_id": "my_account",
    "person_id": "11143"
}

Use person_id as a user's stable ID

Note that the user_name for a given user may change over time, e.g. if the user's email changes, and if the user account is closed it may be reused later by another account. If you need an immutable identifier that will not be reused, person_id is recommended.

Or, with both detailed=true and include_permissions=true:

{
    "user_name": "testuser",
    "scope": "person",
    "expires_in": "3192",
    "client_id": "my_account",
    "person_id": "11143",
    "user_id": "08573771072139469457090803092242",
    "name": "Test User",
    "first_name": "Test",
    "last_name": "User",
    "email": "test-user@cochrane.org",
    "permissions": [
        {
            "resource": "person",
            "entity": "D37BDF5182E26AA2013C72096D0CE6B1",
            "grants": ["view", "view_private", "write"]

        }
    ]
}

In case of an error condition the response will follow the same structure as for the token endpoint (see above).