Resources

Retrieve Token User Info

After a client application has obtained an access token, it can make a request to the /userinfo endpoint to get user-related information. The data returned include the user's ID, email, username, and other profile details along with the scopes granted to the token. The x-as-user-email / x-as-user-id headers do not redirect this endpoint for a token from the Authorization Code grant: it always describes the user the token was issued for, because a relying party would otherwise sign in whoever the header named. Client Credentials and legacy bearer tokens have no user of their own, so for those it describes the user named by the header.

get/userinfo

Request

Base URL
https://ironcladapp.com/oauth
URL
https://ironcladapp.com/oauth/userinfo
Auth
none declared

Headers

x-as-user-emailstring

Example:jane.doe@test.com

Denotes the actor of the request. When used, the API will take into account this user's permissions and access. This or x-as-user-id is required when the associated token was produced from the Client Credentials grant or with legacy bearer tokens on select endpoints. A token produced from the Authorization Code grant (which is already scoped to a user) may also use this header to act as a different user in the same company, provided the token carries the identity.users.impersonate scope and the token's own user has been granted the API User Impersonation permission. A request that sends this header without both never acts as the named user; depending on the company's configuration it either proceeds as the token's own user or is rejected with a 403. More information about permissions.

x-as-user-idstring

Example:5f0375c4cdc1927a3c5edcd3

Denotes the actor of the request. When used, the API will take into account this user's permissions and access. This or x-as-user-email is required when the associated token was produced from the Client Credentials grant or with legacy bearer tokens on select endpoints. A token produced from the Authorization Code grant (which is already scoped to a user) may also use this header to act as a different user in the same company, provided the token carries the identity.users.impersonate scope and the token's own user has been granted the API User Impersonation permission. A request that sends this header without both never acts as the named user; depending on the company's configuration it either proceeds as the token's own user or is rejected with a 403. More information about permissions.

Response

200

substring required

Subject identifier as defined by the OIDC specification. Equal to the user's Ironclad ID.

idstring required

emailstring required

usernamestring required

firstNamestring required

lastNamestring required

displayNamestring required

titlestring required

companyIdstring required

companyNamestring required

scopesstring[] required

Example response

{
  "sub": "63d415e0dd0d828c3a878548",
  "id": "63d415e0dd0d828c3a878548",
  "email": "user@example.com",
  "username": "username",
  "firstName": "John",
  "lastName": "Doe",
  "displayName": "John Doe",
  "title": "Software Engineer",
  "companyId": "6013609108b8f070cee94fc1",
  "companyName": "Example Company",
  "scopes": [
    "public.records.readRecords",
    "public.records.createRecords"
  ]
}

Changes

No recorded changes to this operation across all 1 revision of this API.