[{"data":1,"prerenderedAt":425},["ShallowReactive",2],{"footer-primary":3,"footer-secondary":93,"footer-description":119,"authentication-ave-why-do-tokens-expire":121,"authentication-ave-why-do-tokens-expire-next":160,"sales-reps":173},{"items":4},[5,29,49,69],{"id":6,"title":7,"url":8,"page":8,"children":9},"522e608a-77b0-4333-820d-d4f44be2ade1","Solutions",null,[10,15,20,25],{"id":11,"title":12,"url":8,"page":13},"fcafe85a-a798-4710-9e7a-776fe413aae5","Headless CMS",{"permalink":14},"/solutions/headless-cms",{"id":16,"title":17,"url":8,"page":18},"79972923-93cf-4777-9e32-5c9b0315fc10","Backend-as-a-Service",{"permalink":19},"/solutions/backend-as-a-service",{"id":21,"title":22,"url":8,"page":23},"0fa8d0c1-7b64-4f6f-939d-d7fdb99fc407","Product Information",{"permalink":24},"/solutions/product-information-management",{"id":26,"title":27,"url":28,"page":8},"63946d54-6052-4780-8ff4-91f5a9931dcc","100+ Things to Build","https://directus.io/blog/100-tools-apps-and-platforms-you-can-build-with-directus",{"id":30,"title":31,"url":8,"page":8,"children":32},"8ab4f9b1-f3e2-44d6-919b-011d91fe072f","Resources",[33,37,41,45],{"id":34,"title":35,"url":36,"page":8},"f951fb84-8777-4b84-9e91-996fe9d25483","Documentation","https://docs.directus.io",{"id":38,"title":39,"url":40,"page":8},"366febc7-a538-4c08-a326-e6204957f1e3","Guides","https://docs.directus.io/guides/",{"id":42,"title":43,"url":44,"page":8},"aeb9128e-1c5f-417f-863c-2449416433cd","Community","https://directus.chat",{"id":46,"title":47,"url":48,"page":8},"da1c2ed8-0a77-49b0-a903-49c56cb07de5","Release Notes","https://github.com/directus/directus/releases",{"id":50,"title":51,"url":8,"page":8,"children":52},"d61fae8c-7502-494a-822f-19ecff3d0256","Support",[53,57,61,65],{"id":54,"title":55,"url":56,"page":8},"8c43c781-7ebd-475f-a931-747e293c0a88","Issue Tracker","https://github.com/directus/directus/issues",{"id":58,"title":59,"url":60,"page":8},"d77bb78e-cf7b-4e01-932a-514414ba49d3","Feature Requests","https://github.com/directus/directus/discussions?discussions_q=is:open+sort:top",{"id":62,"title":63,"url":64,"page":8},"4346be2b-2c53-476e-b53b-becacec626a6","Community Chat","https://discord.com/channels/725371605378924594/741317677397704757",{"id":66,"title":67,"url":68,"page":8},"26c115d2-49f7-4edc-935e-d37d427fb89d","Cloud Dashboard","https://directus.cloud",{"id":70,"title":71,"url":8,"page":8,"children":72},"49141403-4f20-44ac-8453-25ace1265812","Organization",[73,78,84,88],{"id":74,"title":75,"url":76,"page":77},"1f36ea92-8a5e-47c8-914c-9822a8b9538a","About","/about",{"permalink":76},{"id":79,"title":80,"url":81,"page":82},"b84bf525-5471-4b14-a93c-225f6c386005","Careers","#",{"permalink":83},"/careers",{"id":85,"title":86,"url":87,"page":8},"86aabc3a-433d-434b-9efa-ad1d34be0a34","Brand Assets","https://drive.google.com/drive/folders/1lBOTba4RaA5ikqOn8Ewo4RYzD0XcymG9?usp=sharing",{"id":89,"title":90,"url":8,"page":91},"8d2fa1e3-198e-4405-81e1-2ceb858bc237","Contact",{"permalink":92},"/contact",{"items":94},[95,101,107,113],{"id":96,"title":97,"url":8,"page":98,"children":100},"8a1b7bfa-429d-4ffc-a650-2a5fdcf356da","Cloud Policies",{"permalink":99},"/cloud-policies",[],{"id":102,"title":103,"url":81,"page":104,"children":106},"bea848ef-828f-4306-8017-6b00ec5d4a0c","License",{"permalink":105},"/bsl",[],{"id":108,"title":109,"url":81,"page":110,"children":112},"4e914f47-4bee-42b7-b445-3119ee4196ef","Terms",{"permalink":111},"/terms",[],{"id":114,"title":115,"url":81,"page":116,"children":118},"ea69eda6-d317-4981-8421-fcabb1826bfd","Privacy",{"permalink":117},"/privacy",[],{"description":120},"\u003Cp>A composable backend to build your Headless CMS, BaaS, and more. \u003C/p>",{"id":122,"slug":123,"vimeo_id":124,"description":125,"tile":126,"length":127,"resources":8,"people":8,"episode_number":128,"published":129,"title":130,"video_transcript_html":131,"video_transcript_text":132,"content":8,"status":133,"episode_people":134,"recommendations":146,"season":147,"seo":159},"c6491b5a-5afa-4ce8-8958-d15ecf4a3369","why-do-tokens-expire","1048670160","You can't have access forever. In this skip down Authentication Avenue, Kevin answers \"Why do tokens expire?\" and shows you how to get new ones.","f1fa8472-da39-4d05-ad8d-8e891e8b1f55",7,3,"2025-01-21","Why do tokens expire?","\u003Cp>Speaker 0: Hey, developers. Welcome to authentication avenue. You know how spies in movies have secret codes that expire after a single use? Well, in modern applications, we do something similar with access tokens. Today, we're exploring why these digital passes have expiration dates and the clever system that keeps users logged in securely.\u003C/p>\u003Cp>Imagine you're visiting a big amusement park. When you arrive you get 2 things, a ride pass that's good for just one day, that's like your access token, and a special VIP card that's good for the whole year, That's like your refresh token. Now when your day pass expires, you don't need to go back to the ticket counter and buy a new ticket. Instead, you can show your VIP card at the special kiosk, and it will print you a fresh day pass on your next visit. And this is exactly how modern applications handle access.\u003C/p>\u003Cp>Your access token is like that day pass. It lets you go on rides or in our case make API requests, but it expires quite quickly. The refresh token is like the VIP card. It's valid for much longer and lets you get new access tokens without logging in again. But why not just make the access token last forever?\u003C/p>\u003Cp>Well, imagine if someone stole your day pass, they can use it till the end of the day. But, if they stole a much longer pass, say for the whole year, they could keep using it forever. And that's why we keep access tokens short lived, it's safer that way. In Directus, here is how it works. When you log in, you get a package of data containing an access token, usually valid for 15 minutes, although you can configure that, A refresh token, valid for much longer, and an expiration time stamp.\u003C/p>\u003Cp>Now when your access token expires, you call the refresh endpoint with your refresh token, and then get a fresh package of tokens. And if you want to log out, you can destroy these tokens, just like shredding your park passes so nobody else can use them. This is especially important when using shared computers or if you think your tokens might be compromised. So there you have it. Token expiration isn't just an inconvenience, it's a crucial security feature that helps keep your application safe.\u003C/p>\u003Cp>Let's see how it works in Directus. I wanna show you how to interact with Directus' authentication endpoints via API, and we're going to start with the login endpoint. So this is a post request to /auth/login. In the body, we provide the email and password, and when we send that, we receive a packet of data back. We what?\u003C/p>\u003Cp>Oh, there we go. We have an an access token, which we can use in order to make requests. We have a refresh token and an expiry time. This is 30,000 milliseconds or 30 seconds. I've set it to be quite short in this project to demonstrate my point.\u003C/p>\u003Cp>Now we can use this access token here in order to authenticate requests and retrieve data, but as you might remember, we've only set this to 30 seconds before expiry. So if I try and hit send again, we see that the token has expired. This whole token is no longer usable. So what do we do? We won't always be able to send off an email and password because we may no longer have access to them.\u003C/p>\u003Cp>You don't necessarily want to store them, so we use the refresh token. Now the refresh token also expires, but a much, much longer time. I believe the default is 7 days, but it is configurable just like the access token is, which I set to 30 seconds here. So we have this refresh token, and we also have a refresh endpoint, post slash auth slash refresh. We provide our refresh token, and what we receive back is the same data packet, an access token, a refresh token, and the amount of time until it expires.\u003C/p>\u003Cp>You can now use this new access token in order to authenticate requests. And once again, this refresh token is now spent, it no longer works. You can now use the new refresh token in order to receive a new packet of data. And once you're done and you want to log out, you can hit /auth/logoutpost with your refresh token, that is not the refresh token, with your refresh token, and you will receive a 204, which is a successful request, but with no content returned. And now the tokens, including the refresh token, is, invalidated, and you can no longer access it.\u003C/p>\u003Cp>Now when you're working with the SDK by comparison, the SDK handles all of this for you. It will handle the storage of your tokens, it will handle the refreshing of your tokens for you as soon as you log in. However, we do also provide explicit, methods, request, refresh, here it is, and log out, a refresh function and a log out method in order to run those same commands as the API. But in most use cases, you won't need these. You log in, and as you make requests, the SDK will handle the refreshing of tokens on your behalf.\u003C/p>\u003Cp>So hopefully, that helps explain the relationship between access tokens, refresh tokens, expiry time, and how you actually work with the API in order to generate and regenerate them. Thank you for joining me on Authentication Avenue, and I'll see you next time.\u003C/p>","Hey, developers. Welcome to authentication avenue. You know how spies in movies have secret codes that expire after a single use? Well, in modern applications, we do something similar with access tokens. Today, we're exploring why these digital passes have expiration dates and the clever system that keeps users logged in securely. Imagine you're visiting a big amusement park. When you arrive you get 2 things, a ride pass that's good for just one day, that's like your access token, and a special VIP card that's good for the whole year, That's like your refresh token. Now when your day pass expires, you don't need to go back to the ticket counter and buy a new ticket. Instead, you can show your VIP card at the special kiosk, and it will print you a fresh day pass on your next visit. And this is exactly how modern applications handle access. Your access token is like that day pass. It lets you go on rides or in our case make API requests, but it expires quite quickly. The refresh token is like the VIP card. It's valid for much longer and lets you get new access tokens without logging in again. But why not just make the access token last forever? Well, imagine if someone stole your day pass, they can use it till the end of the day. But, if they stole a much longer pass, say for the whole year, they could keep using it forever. And that's why we keep access tokens short lived, it's safer that way. In Directus, here is how it works. When you log in, you get a package of data containing an access token, usually valid for 15 minutes, although you can configure that, A refresh token, valid for much longer, and an expiration time stamp. Now when your access token expires, you call the refresh endpoint with your refresh token, and then get a fresh package of tokens. And if you want to log out, you can destroy these tokens, just like shredding your park passes so nobody else can use them. This is especially important when using shared computers or if you think your tokens might be compromised. So there you have it. Token expiration isn't just an inconvenience, it's a crucial security feature that helps keep your application safe. Let's see how it works in Directus. I wanna show you how to interact with Directus' authentication endpoints via API, and we're going to start with the login endpoint. So this is a post request to /auth/login. In the body, we provide the email and password, and when we send that, we receive a packet of data back. We what? Oh, there we go. We have an an access token, which we can use in order to make requests. We have a refresh token and an expiry time. This is 30,000 milliseconds or 30 seconds. I've set it to be quite short in this project to demonstrate my point. Now we can use this access token here in order to authenticate requests and retrieve data, but as you might remember, we've only set this to 30 seconds before expiry. So if I try and hit send again, we see that the token has expired. This whole token is no longer usable. So what do we do? We won't always be able to send off an email and password because we may no longer have access to them. You don't necessarily want to store them, so we use the refresh token. Now the refresh token also expires, but a much, much longer time. I believe the default is 7 days, but it is configurable just like the access token is, which I set to 30 seconds here. So we have this refresh token, and we also have a refresh endpoint, post slash auth slash refresh. We provide our refresh token, and what we receive back is the same data packet, an access token, a refresh token, and the amount of time until it expires. You can now use this new access token in order to authenticate requests. And once again, this refresh token is now spent, it no longer works. You can now use the new refresh token in order to receive a new packet of data. And once you're done and you want to log out, you can hit /auth/logoutpost with your refresh token, that is not the refresh token, with your refresh token, and you will receive a 204, which is a successful request, but with no content returned. And now the tokens, including the refresh token, is, invalidated, and you can no longer access it. Now when you're working with the SDK by comparison, the SDK handles all of this for you. It will handle the storage of your tokens, it will handle the refreshing of your tokens for you as soon as you log in. However, we do also provide explicit, methods, request, refresh, here it is, and log out, a refresh function and a log out method in order to run those same commands as the API. But in most use cases, you won't need these. You log in, and as you make requests, the SDK will handle the refreshing of tokens on your behalf. So hopefully, that helps explain the relationship between access tokens, refresh tokens, expiry time, and how you actually work with the API in order to generate and regenerate them. Thank you for joining me on Authentication Avenue, and I'll see you next time.","published",[135],{"people_id":136},{"id":137,"first_name":138,"last_name":139,"avatar":140,"bio":141,"links":142},"82b3f7e5-637b-4890-93b2-378b497d5dc6","Kevin","Lewis","a662f91b-1ee9-4277-8c9d-3ac1878e44ad","Director of Developer Experience at Directus",[143],{"url":144,"service":145},"https://directus.io/team/kevin-lewis","website",[],{"id":148,"number":149,"year":150,"episodes":151,"show":156},"ff7886c3-8457-49e6-a2c7-f7d526d518ce",1,"2025",[152,153,122,154,155],"0df4af9a-442f-4fd5-97b5-3c38e6644e75","707a5d2a-1db7-4b64-a371-cb332d72b16f","ae9ce140-b94f-455f-8e94-e623e3d4da76","6d68c3bc-e3b4-49f2-81fb-6bd7ddb45995",{"title":157,"tile":158},"Authentication Avenue","17eeb7e8-08e3-4a21-8bc0-d27857ac8df6",{"title":8,"meta_description":8},{"id":154,"slug":161,"season":148,"vimeo_id":162,"description":163,"tile":164,"length":127,"resources":8,"people":8,"episode_number":165,"published":129,"title":166,"video_transcript_html":167,"video_transcript_text":168,"content":8,"seo":169,"status":133,"episode_people":170,"recommendations":172},"what-are-static-tokens","1048670289","Sometimes you need to give out a master key that never changes. In this jog down Authentication Avenue, Kevin answers \"What are static tokens?\".","ab367ceb-0852-46de-bcbe-3326246b30d9",4,"What are static tokens?","\u003Cp>Speaker 0: Hey, developers. And welcome to another episode of Authentication Avenue. Ever needed a way to access your application that never expires and never changes? Today, we're talking about static tokens, the digital equivalent of having a master key to your house. My friendly neighborhood mail carrier is called Alex.\u003C/p>\u003Cp>Every morning, Alex delivers packages to, our building. And now most residents to our building get a new digital key card every week. The building manager says it's safer that way. But imagine if Alex had to visit the manager's office every single week for a new key card. They'd spend more times collecting new keys than delivering mail.\u003C/p>\u003Cp>So what is the solution? Alex gets a special permanent key. It never expires, it never needs updating, and it lets them deliver packages efficiently every single day. Now in the world of software, static tokens are just like Alex's permanent key. While regular users might need their access credentials refreshed frequently, like those weekly key cards, some situations call for a permanent, unchanging key.\u003C/p>\u003Cp>Maybe it's an automated email system that needs to check for new messages or a weather service that needs to fetch updates every hour. These are our digital mail carriers needing reliable and constant access. But here's the thing, just like the building manager only gives out a few permanent keys, static tokens are special. They're powerful tools that we use carefully and only when we really need them. If someone gets Alex's key, that would be a problem, so we need to make sure that they are kept safe.\u003C/p>\u003Cp>In directives, each user can have one static token. Think of it as their personal master key. Unlike regular access tokens that expire and need refreshing, this static token stays the same until you manually change it, provides continuous access to the API, and can be used for automated tasks or system integrations. It also has all the permissions of the user that it belongs to. However, remember with great power comes great responsibility.\u003C/p>\u003Cp>Since these tokens don't expire, you need to keep them extra secure and only use them when necessary. So there you have it. Static tokens are your always on access pass. Perfect for automation and system integration, but handle with care. Let's see how we can get a static token inside of Directus and use it when building our projects.\u003C/p>\u003Cp>As mentioned, each user can have one static access token, which can be used to authenticate as them in context where you can't constantly be providing a username or password or changing the key that you have provided. This is really common in very small personal applications and in any form of automation or integration with a third party. Now over in your user profile or if you are an admin in other user profiles, you can scroll down to the bottom and notice this token area here. You generate the token with the plus button, take note of it, copying it to your clipboard, and then make sure that you save or this token will not be active. This is the token that you can now provide when, when authenticating with Directus.\u003C/p>\u003Cp>If you go back in, take note that this is stored as a string in your database. However, you can't access it easily via the UI here. It's obfuscated. And if you regenerate the token, the old token will no longer work, so we only show it one time, so be sure to copy it. Now when you're using the SDK, take note that we have a static token function, which you can, which you can import from the SDK.\u003C/p>\u003Cp>And when you're initializing your client, you can pass in the static token like so. Oh, it helps if you actually do something with that console log items, like so. 3rd time lucky. There's some data there. You can also provide a static token for one off requests using different functions that are available within the SDK, and you can take a look at the SDK documentation to learn more.\u003C/p>\u003Cp>So, yeah, that's how you use static tokens, really good for prototyping small personal projects, and sometimes necessary in order to set up integrations. Thank you so much for joining me, and I'll see you in the next episode.\u003C/p>","Hey, developers. And welcome to another episode of Authentication Avenue. Ever needed a way to access your application that never expires and never changes? Today, we're talking about static tokens, the digital equivalent of having a master key to your house. My friendly neighborhood mail carrier is called Alex. Every morning, Alex delivers packages to, our building. And now most residents to our building get a new digital key card every week. The building manager says it's safer that way. But imagine if Alex had to visit the manager's office every single week for a new key card. They'd spend more times collecting new keys than delivering mail. So what is the solution? Alex gets a special permanent key. It never expires, it never needs updating, and it lets them deliver packages efficiently every single day. Now in the world of software, static tokens are just like Alex's permanent key. While regular users might need their access credentials refreshed frequently, like those weekly key cards, some situations call for a permanent, unchanging key. Maybe it's an automated email system that needs to check for new messages or a weather service that needs to fetch updates every hour. These are our digital mail carriers needing reliable and constant access. But here's the thing, just like the building manager only gives out a few permanent keys, static tokens are special. They're powerful tools that we use carefully and only when we really need them. If someone gets Alex's key, that would be a problem, so we need to make sure that they are kept safe. In directives, each user can have one static token. Think of it as their personal master key. Unlike regular access tokens that expire and need refreshing, this static token stays the same until you manually change it, provides continuous access to the API, and can be used for automated tasks or system integrations. It also has all the permissions of the user that it belongs to. However, remember with great power comes great responsibility. Since these tokens don't expire, you need to keep them extra secure and only use them when necessary. So there you have it. Static tokens are your always on access pass. Perfect for automation and system integration, but handle with care. Let's see how we can get a static token inside of Directus and use it when building our projects. As mentioned, each user can have one static access token, which can be used to authenticate as them in context where you can't constantly be providing a username or password or changing the key that you have provided. This is really common in very small personal applications and in any form of automation or integration with a third party. Now over in your user profile or if you are an admin in other user profiles, you can scroll down to the bottom and notice this token area here. You generate the token with the plus button, take note of it, copying it to your clipboard, and then make sure that you save or this token will not be active. This is the token that you can now provide when, when authenticating with Directus. If you go back in, take note that this is stored as a string in your database. However, you can't access it easily via the UI here. It's obfuscated. And if you regenerate the token, the old token will no longer work, so we only show it one time, so be sure to copy it. Now when you're using the SDK, take note that we have a static token function, which you can, which you can import from the SDK. And when you're initializing your client, you can pass in the static token like so. Oh, it helps if you actually do something with that console log items, like so. 3rd time lucky. There's some data there. You can also provide a static token for one off requests using different functions that are available within the SDK, and you can take a look at the SDK documentation to learn more. So, yeah, that's how you use static tokens, really good for prototyping small personal projects, and sometimes necessary in order to set up integrations. Thank you so much for joining me, and I'll see you in the next episode.","8840ef88-bda1-463e-8e76-e9c9cb0f6d6f",[171],"97aaa6b6-31b8-48cd-980b-b3d2aa3219b2",[],{"reps":174},[175,231],{"name":176,"sdr":8,"link":177,"countries":178,"states":180},"John Daniels","https://meet.directus.io/meetings/john2144/john-contact-form-meeting",[179],"United States",[181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230],"Michigan","Indiana","Ohio","West Virginia","Kentucky","Virginia","Tennessee","North Carolina","South Carolina","Georgia","Florida","Alabama","Mississippi","New York","MI","IN","OH","WV","KY","VA","TN","NC","SC","GA","FL","AL","MS","NY","Connecticut","CT","Delaware","DE","Maine","ME","Maryland","MD","Massachusetts","MA","New Hampshire","NH","New Jersey","NJ","Pennsylvania","PA","Rhode Island","RI","Vermont","VT","Washington DC","DC",{"name":232,"link":233,"countries":234},"Michelle Riber","https://meetings.hubspot.com/mriber",[235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,212,423,424],"Albania","ALB","Algeria","DZA","Andorra","AND","Angola","AGO","Austria","AUT","Belgium","BEL","Benin","BEN","Bosnia and Herzegovina","BIH","Botswana","BWA","Bulgaria","BGR","Burkina Faso","BFA","Burundi","BDI","Cameroon","CMR","Cape Verde","CPV","Central African Republic","CAF","Chad","TCD","Comoros","COM","Côte d'Ivoire","CIV","Croatia","HRV","Czech Republic","CZE","Democratic Republic of Congo","COD","Denmark","DNK","Djibouti","DJI","Egypt","EGY","Equatorial Guinea","GNQ","Eritrea","ERI","Estonia","EST","Eswatini","SWZ","Ethiopia","ETH","Finland","FIN","France","FRA","Gabon","GAB","Gambia","GMB","Ghana","GHA","Greece","GRC","Guinea","GIN","Guinea-Bissau","GNB","Hungary","HUN","Iceland","ISL","Ireland","IRL","Italy","ITA","Kenya","KEN","Latvia","LVA","Lesotho","LSO","Liberia","LBR","Libya","LBY","Liechtenstein","LIE","Lithuania","LTU","Luxembourg","LUX","Madagascar","MDG","Malawi","MWI","Mali","MLI","Malta","MLT","Mauritania","MRT","Mauritius","MUS","Moldova","MDA","Monaco","MCO","Montenegro","MNE","Morocco","MAR","Mozambique","MOZ","Namibia","NAM","Niger","NER","Nigeria","NGA","North Macedonia","MKD","Norway","NOR","Poland","POL","Portugal","PRT","Republic of Congo","COG","Romania","ROU","Rwanda","RWA","San Marino","SMR","São Tomé and Príncipe","STP","Senegal","SEN","Serbia","SRB","Seychelles","SYC","Sierra Leone","SLE","Slovakia","SVK","Slovenia","SVN","Somalia","SOM","South Africa","ZAF","South Sudan","SSD","Spain","ESP","Sudan","SDN","Sweden","SWE","Tanzania","TZA","Togo","TGO","Tunisia","TUN","Uganda","UGA","United Kingdom","GBR","Vatican City","VAT","Zambia","ZMB","Zimbabwe","ZWE","UK","Germany","Netherlands","Switzerland","CH","NL",1773850434367]