{
	"id": "f2ea365e-6854-4a19-9811-a520ac126199",
	"created_at": "2026-04-06T00:10:27.569332Z",
	"updated_at": "2026-04-10T13:12:25.247164Z",
	"deleted_at": null,
	"sha1_hash": "f4931fd87a0ac1ced155d50408035040e7213588",
	"title": "Understanding Refresh Tokens",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 44346,
	"plain_text": "Understanding Refresh Tokens\r\nArchived: 2026-04-05 22:51:42 UTC\r\nWhat Are Refresh Tokens?\r\nModern secure applications often use access tokens to ensure a user has access to the appropriate resources, and\r\nthese access tokens typically have a limited lifetime. This is done for various security reasons: for one, limiting the\r\nlifetime of the access token limits the amount of time an attacker can use a stolen token. In addition, the\r\ninformation contained in or referenced by the access token could become stale.\r\nWhen access tokens expire or become invalid but the application still needs to access a protected resource, the\r\napplication faces the problem of getting a new access token without forcing the user to once again grant\r\npermission. To solve this problem, OAuth 2.0 introduced an artifact called a refresh token. A refresh token allows\r\nan application to obtain a new access token without prompting the user.\r\nObtaining Refresh Tokens\r\nA refresh token can be requested by an application as part of the process of obtaining an access token. Many\r\nauthorization servers implement the refresh token request mechanism defined in the OpenID Connect\r\nspecification. In this case, an application must include the offline_access scope when initiating a request for an\r\nauthorization code. After the user successfully authenticates and grants consent for the application to access the\r\nprotected resource, the application will receive an authorization code that can be exchanged at the token endpoint\r\nfor both an access and a refresh token.\r\nUsing Refresh Tokens\r\nWhen a new access token is needed, the application can make a POST request back to the token endpoint using a\r\ngrant type of refresh_token (web applications need to include a client secret). To use a refresh token to obtain a\r\nnew ID token, the authorization server would need to support OpenID Connect and the scope of the original\r\nrequest would need to include openid .\r\nWhile refresh tokens are often long-lived, the authorization server can invalidate them. Some of the reasons a\r\nrefresh token may no longer be valid include:\r\nthe authorization server has revoked the refresh token\r\nthe user has revoked their consent for authorization\r\nthe refresh token has expired\r\nthe authentication policy for the resource has changed (e.g., originally the resource only used usernames\r\nand passwords, but now it requires MFA)\r\nBecause refresh tokens have the potential for a long lifetime, developers should ensure that strict storage\r\nrequirements are in place to keep them from being leaked. For example, on web applications, refresh tokens\r\nhttps://auth0.com/learn/refresh-tokens\r\nPage 1 of 2\n\nshould only leave the backend when being sent to the authorization server, and the backend should be secure. The\r\nclient secret should be protected in a similar fashion. Mobile applications do not require a client secret, but they\r\nshould still be sure to store refresh tokens somewhere only the client application can access.\r\nRefresh Tokens at Auth0\r\nWith Auth0, you can get a refresh token when using the Authorization Code Flow (for regular web or\r\nnative/mobile apps), the Device Flow, or the Resource Owner Password Grant. All of Auth0’s main SDKs\r\nsupport acquiring, using, and revoking refresh tokens out of the box, without you having to worry about\r\nformatting messages. Languages with SDK support include Node.js, .NET, PHP, and many more!\r\nTo learn more about refresh tokens at Auth0, including how to revoke them, check out the refresh token\r\ndocumentation.\r\nSource: https://auth0.com/learn/refresh-tokens\r\nhttps://auth0.com/learn/refresh-tokens\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://auth0.com/learn/refresh-tokens"
	],
	"report_names": [
		"refresh-tokens"
	],
	"threat_actors": [],
	"ts_created_at": 1775434227,
	"ts_updated_at": 1775826745,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f4931fd87a0ac1ced155d50408035040e7213588.pdf",
		"text": "https://archive.orkl.eu/f4931fd87a0ac1ced155d50408035040e7213588.txt",
		"img": "https://archive.orkl.eu/f4931fd87a0ac1ced155d50408035040e7213588.jpg"
	}
}