{ "id": "453e0f56-4e72-4c71-9b55-d4a83c9e877c", "created_at": "2026-04-06T00:16:29.83706Z", "updated_at": "2026-04-10T03:21:16.961479Z", "deleted_at": null, "sha1_hash": "920d0c43356ff211869ed01cb07c6faeb83d2bd4", "title": "Access Tokens - Auth0 Docs", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 51868, "plain_text": "Access Tokens - Auth0 Docs\r\nArchived: 2026-04-05 17:03:27 UTC\r\nare used in token-based authentication to allow an application to access an API. The application receives an access\r\ntoken after a user successfully authenticates and authorizes access, then passes the access token as a credential\r\nwhen it calls the target API. The passed token informs the API that the bearer of the token has been authorized to\r\naccess the API and perform specific actions specified by the that was granted during authorization. In addition, if\r\nyou have chosen to allow users to log in through an , such as Facebook, the will issue its own access token to\r\nallow your application to call the IDP’s API. For example, if your user authenticates using Facebook, the access\r\ntoken issued by Facebook can be used to call the Facebook Graph API. These tokens are controlled by the IdP and\r\ncan be issued in any format. See Identity Provider Access Tokens for details.\r\nOpaque access tokens\r\nOpaque access tokens are tokens in a proprietary format that you cannot access and typically contain some\r\nidentifier to information in a server’s persistent storage. To validate an opaque token, the recipient of the token\r\nneeds to call the server that issued the token. In Auth0’s case, opaque tokens can be used with the /userinfo\r\nendpoint to return a user’s profile. If you receive an opaque Access Token, you don’t need to validate it. You can\r\nuse it with the /userinfo endpoint, and Auth0 takes care of the rest. To learn more, see Get Access Tokens.\r\n(JWT) access tokens conform to the JWT standard and contain information about an entity in the form of claims.\r\nThey are self-contained therefore it is not necessary for the recipient to call a server to validate the token. Access\r\ntokens issued for the and access tokens issued for any custom API that you have registered with Auth0 follow the\r\nJWT standard, which means that their basic structure conforms to the typical JWT structure, and they contain\r\nstandard JWT claims asserted about the token itself.\r\nManagement API access tokens\r\nAn access token issued for the Auth0 Management API should be treated as opaque (regardless of whether it\r\nactually is), so you don’t need to validate it. You can use it with the Auth0 Management API, and Auth0 takes care\r\nof the rest. To learn more, see Auth0 Management API Tokens.\r\nCustom API access tokens\r\nIf validation of your custom API access token fails, make sure it was issued with your custom API as the\r\naudience . To learn more, see Get Access Tokens.\r\nSample access token\r\nThis example shows the contents of an access token. Notice that the token only contains authorization information\r\nabout the actions the application is allowed to perform at the API (such permissions are referred to as scopes ).\r\nhttps://auth0.com/docs/tokens/access-tokens\r\nPage 1 of 3\n\n{\r\n\"iss\": \"https://my-domain.auth0.com/\",\r\n\"sub\": \"auth0|123456\",\r\n\"aud\": [\r\n\"https://example.com/health-api\",\r\n\"https://my-domain.auth0.com/userinfo\"\r\n],\r\n\"azp\": \"my_client_id\",\r\n\"exp\": 1311281970,\r\n\"iat\": 1311280970,\r\n\"scope\": \"openid profile read:patients read:admin\"\r\n}\r\nThe token does not contain any information about the user except for the user ID (located in the sub claim). In\r\nmany cases, you may find it useful to retrieve additional user information. You can do this by calling the userinfo\r\nAPI endpoint with the Access Token. Be sure that the API for which the Access Token is issued uses the RS256\r\nsigning algorithm.\r\nAccess token security\r\nYou should follow token best practices when using access tokens, and for JWTs, make sure that you validate an\r\naccess token before assuming that its contents can be trusted.\r\nAccess token lifetime\r\nCustom API token lifetime\r\nBy default, an access token for a custom API is valid for 86400 seconds (24 hours). We recommend that you set\r\nthe validity period of your token based on the security requirements of your API. For example, an access token\r\nthat accesses a banking API should expire more quickly than one that accesses a to-do API. To learn more, see\r\nUpdate Access Token Lifetime.\r\n/userinfo endpoint token lifetime\r\nAccess tokens issued strictly for the purpose of accessing the OIDC /userinfo endpoint have a default lifetime\r\nand can’t be changed. The length of lifetime depends on the flow used to obtain the token:\r\nFlow Lifetime\r\nImplicit 7200 seconds (2 hours)\r\nAuthorization Code/Hybrid 86400 seconds (24 hours)\r\nLearn more\r\nhttps://auth0.com/docs/tokens/access-tokens\r\nPage 2 of 3\n\nGet Access Tokens\r\nValidate Access Tokens\r\nUse Access Tokens\r\nToken Best Practices\r\nSource: https://auth0.com/docs/tokens/access-tokens\r\nhttps://auth0.com/docs/tokens/access-tokens\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://auth0.com/docs/tokens/access-tokens" ], "report_names": [ "access-tokens" ], "threat_actors": [], "ts_created_at": 1775434589, "ts_updated_at": 1775791276, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/920d0c43356ff211869ed01cb07c6faeb83d2bd4.pdf", "text": "https://archive.orkl.eu/920d0c43356ff211869ed01cb07c6faeb83d2bd4.txt", "img": "https://archive.orkl.eu/920d0c43356ff211869ed01cb07c6faeb83d2bd4.jpg" } }