[{"data":1,"prerenderedAt":472},["ShallowReactive",2],{"footer-primary":3,"footer-secondary":93,"footer-description":119,"tv-authentication-ave":121,"tv-authentication-ave-seasons":131,"tv-authentication-ave-episodes":142,"sales-reps":220},{"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,"title":123,"logo":124,"cover":125,"tile":126,"announcement_text":8,"description":127,"slug":128,"one_liner":129,"card_text":8,"status":130,"sort":8},"541d8c8c-142d-4915-bd42-8aa9b0aaec34","Authentication Avenue","53166ec0-d730-406f-8a8f-192b9d162b78","10550da3-8877-45ce-bdde-5c33fb0e5e42","17eeb7e8-08e3-4a21-8bc0-d27857ac8df6","Directus Auth is super powerful, and we want you to better understand it. Through easy-to-follow guides, you will learn about all things authentication, authorization, and access control. We'll cover both concepts and real-world applications as we cover topics like tokens, policies, and single sign-on.","authentication-ave","Take a journey down all things authentication, authorization, and access control.","published",[132],{"id":133,"number":134,"show":122,"year":135,"episodes":136},"ff7886c3-8457-49e6-a2c7-f7d526d518ce",1,"2025",[137,138,139,140,141],"0df4af9a-442f-4fd5-97b5-3c38e6644e75","707a5d2a-1db7-4b64-a371-cb332d72b16f","c6491b5a-5afa-4ce8-8958-d15ecf4a3369","ae9ce140-b94f-455f-8e94-e623e3d4da76","6d68c3bc-e3b4-49f2-81fb-6bd7ddb45995",[143,159,175,190,205],{"id":137,"slug":144,"vimeo_id":145,"description":146,"tile":147,"length":148,"resources":8,"people":8,"episode_number":134,"published":149,"title":150,"video_transcript_html":151,"video_transcript_text":152,"content":8,"seo":153,"status":130,"episode_people":154,"recommendations":156,"season":157},"what-does-authentication-mean","1048669894","Authentication happens many times a day without us even realizing. In this walk down Authentication Avenue, Kevin answers \"What does authentication mean?\"","cb41e733-5cf5-4a65-bf50-92407827e19a",7,"2025-01-21","What does authentication mean?","\u003Cp>Speaker 0: Hey there, developers, and welcome to authentication avenue. Ever wonder how your favorite apps know it's really you trying to log in? Well, today we're diving into authentication, the digital world's way of checking your ID. Let's imagine we're at our local library. When you want to borrow books, you need a library card.\u003C/p>\u003Cp>But getting that card isn't as simple as just walking in and saying, hey, I'm Kevin. Here's what actually happens. First, you fill out an application with your information. That's you claiming who you are. Then you show your ID or proof of address.\u003C/p>\u003Cp>That's you proving that you are really you. And only after verifying your identity does the librarian give you your very own library card. Now, every time you come back to borrow books, you show that library card. The librarian can check their system and confirm it's a valid card that actually belongs to you. And that's exactly how authentication works in the digital world.\u003C/p>\u003Cp>When you log in to your favorite app, you don't just type in your email and poof, you're in. Just like at the library, you need something to prove it's really you with something only you would know, your password. Now, in the developer world, authentication is like that library card system. When users try to access their private data or personal settings, authentication verifies their identity using something they know, like their password, something they have, like their phone or verification codes, or something they are, like their fingerprint. We call all of these authentication factors, and they're the digital equivalent of that library card and ID check.\u003C/p>\u003Cp>Now, once you've proven who you are, you need a way to show it with each request, like carrying your library card. In the digital world, we have a few ways of doing this. Most commonly, you will use what is known as a bearer token. It's like carrying an ID card that says, I've already proved who I am. You include this token in a special part of your request called the header.\u003C/p>\u003Cp>Or you might use cookies. These are like invisible name tags that your browser automatically shows to websites you've logged into before. Super convenient. And while you technically can include your credentials as query parameters in a URL, for example, example.com/questionmarktoken equals 12345, we don't really recommend this because sometimes URLs can be logged and that's like writing your password on a sticky note where anyone can see it. So remember, authentication isn't just about saying who you are but it's about proving it.\u003C/p>\u003Cp>Next up, we'll see how this works in practice with Directus. But first, let's return our library card. Here we have a posts collection in a Directus project, but this collection is not publicly accessible, so we will need to authenticate as a user with the requisite permissions in order to access this data. And we see here when we just try and access it, when we try and list the posts, that we get an error. You don't have permission to access the collection posts or it does not exist, which is correct because it doesn't know who we are.\u003C/p>\u003Cp>We have not authenticated. Now as mentioned, there's a few ways to authenticate. One of the most common is by passing in what is known as an authorization header. So the headers get sent along with our request. The value is bearer space and then a valid access token of a user that has permissions, and when we hit send, we will get this data back.\u003C/p>\u003Cp>As I mentioned, there is also another way of doing this, which is via a query parameter to your request. So you can include access token equals value, and, again, that will successfully authenticate. The reason I'm showing you this is to actually dissuade you from using this approach because this full URL, you can type it in your browser here, will return data, but this full URL, including your access token, could be logged by your browser history, by your browser extensions, by your Internet service provider, your corporate VPN provider, and so on. And so to keep it secure, we tend to not use this approach too much. I do also wanna show you how to get an access token and authenticate using the Directus SDK.\u003C/p>\u003Cp>So here we have just a JavaScript file. We are initializing a new Directus SDK instance, and what we're going to do is import the authentication composable. And then we are going to initialize the client with the composable. This gives us a brand new function. We can now type in directives.login and provide our email and our password, these values here.\u003C/p>\u003Cp>And this client will now be authenticated, so now we can go ahead and actually query our post data. Let's import rest and read items, which we'll need to make this request, and add the rest composable to our client. And now we can go ahead and make a query, directus dot request read items posts. And then we'll console log the items. And this line here specifically is what is authenticating us.\u003C/p>\u003Cp>Let's see if that works, and we should see app promise pending. Absolutely. We just need to put in a wait there, and we will now see that once the data is returned, it is displayed here. So this is how we authenticate using the SDK. Join me in the next episode of Authentication Avenue where we will cover a brand new topic.\u003C/p>","Hey there, developers, and welcome to authentication avenue. Ever wonder how your favorite apps know it's really you trying to log in? Well, today we're diving into authentication, the digital world's way of checking your ID. Let's imagine we're at our local library. When you want to borrow books, you need a library card. But getting that card isn't as simple as just walking in and saying, hey, I'm Kevin. Here's what actually happens. First, you fill out an application with your information. That's you claiming who you are. Then you show your ID or proof of address. That's you proving that you are really you. And only after verifying your identity does the librarian give you your very own library card. Now, every time you come back to borrow books, you show that library card. The librarian can check their system and confirm it's a valid card that actually belongs to you. And that's exactly how authentication works in the digital world. When you log in to your favorite app, you don't just type in your email and poof, you're in. Just like at the library, you need something to prove it's really you with something only you would know, your password. Now, in the developer world, authentication is like that library card system. When users try to access their private data or personal settings, authentication verifies their identity using something they know, like their password, something they have, like their phone or verification codes, or something they are, like their fingerprint. We call all of these authentication factors, and they're the digital equivalent of that library card and ID check. Now, once you've proven who you are, you need a way to show it with each request, like carrying your library card. In the digital world, we have a few ways of doing this. Most commonly, you will use what is known as a bearer token. It's like carrying an ID card that says, I've already proved who I am. You include this token in a special part of your request called the header. Or you might use cookies. These are like invisible name tags that your browser automatically shows to websites you've logged into before. Super convenient. And while you technically can include your credentials as query parameters in a URL, for example, example.com/questionmarktoken equals 12345, we don't really recommend this because sometimes URLs can be logged and that's like writing your password on a sticky note where anyone can see it. So remember, authentication isn't just about saying who you are but it's about proving it. Next up, we'll see how this works in practice with Directus. But first, let's return our library card. Here we have a posts collection in a Directus project, but this collection is not publicly accessible, so we will need to authenticate as a user with the requisite permissions in order to access this data. And we see here when we just try and access it, when we try and list the posts, that we get an error. You don't have permission to access the collection posts or it does not exist, which is correct because it doesn't know who we are. We have not authenticated. Now as mentioned, there's a few ways to authenticate. One of the most common is by passing in what is known as an authorization header. So the headers get sent along with our request. The value is bearer space and then a valid access token of a user that has permissions, and when we hit send, we will get this data back. As I mentioned, there is also another way of doing this, which is via a query parameter to your request. So you can include access token equals value, and, again, that will successfully authenticate. The reason I'm showing you this is to actually dissuade you from using this approach because this full URL, you can type it in your browser here, will return data, but this full URL, including your access token, could be logged by your browser history, by your browser extensions, by your Internet service provider, your corporate VPN provider, and so on. And so to keep it secure, we tend to not use this approach too much. I do also wanna show you how to get an access token and authenticate using the Directus SDK. So here we have just a JavaScript file. We are initializing a new Directus SDK instance, and what we're going to do is import the authentication composable. And then we are going to initialize the client with the composable. This gives us a brand new function. We can now type in directives.login and provide our email and our password, these values here. And this client will now be authenticated, so now we can go ahead and actually query our post data. Let's import rest and read items, which we'll need to make this request, and add the rest composable to our client. And now we can go ahead and make a query, directus dot request read items posts. And then we'll console log the items. And this line here specifically is what is authenticating us. Let's see if that works, and we should see app promise pending. Absolutely. We just need to put in a wait there, and we will now see that once the data is returned, it is displayed here. So this is how we authenticate using the SDK. Join me in the next episode of Authentication Avenue where we will cover a brand new topic.","46deecaf-afd5-459a-bdb1-5dc472da7510",[155],"d615326f-0878-4ff7-992f-18b7d87de16b",[],{"id":133,"number":134,"show":122,"year":135,"episodes":158},[137,138,139,140,141],{"id":138,"slug":160,"vimeo_id":161,"description":162,"tile":163,"length":164,"resources":8,"people":8,"episode_number":165,"published":149,"title":166,"video_transcript_html":167,"video_transcript_text":168,"content":8,"seo":169,"status":130,"episode_people":170,"recommendations":172,"season":173},"what-is-access-control","1048670023","It's not just enough to give someone access, but sometimes you need to say what they can do. In this stroll down Authentication Avenue, Kevin answers \"What is access control?\"","f02244b4-07b6-413d-b32c-941ca188cc79",6,2,"What is access control?","\u003Cp>Speaker 0: Hey, developers. And welcome to authentication Avenue. Today, we're going to explore access control. How systems decide what different users can and can't do. It's like having a clever set of rules that keep everything organized and secure.\u003C/p>\u003Cp>Imagine you're at a huge museum. When you enter, everyone gets a different colored badge. Red badges are for the curators who can do everything. Blue badges are for the tour guides who can enter public areas. Green badges are for the cleaning staff who can access maintenance areas.\u003C/p>\u003Cp>And yellow badges are for visitors who can only view exhibits. But it gets even more specific because each badge has special symbols that show exactly what you can do. For example, looking at exhibits, that is the read permission. Creating new displays, that's the create permission. Rearranging exhibits, that's the update permission.\u003C/p>\u003Cp>And finally, removing displays, that's the delete permission. And here's where it gets interesting. Some staff members might only be allowed to change exhibits that they created themselves. Like a junior curator who can only modify their own displays, but not anyone else's. In the tech world, we call this ownership based access.\u003C/p>\u003Cp>Now in Directus, this system is handled through roles, permissions, and policies. Roles are like your colored badges, the broad category you belong to. Permissions are a single rule. For example, what collections you can access or what CRUD operations, that's create, read, update, and delete operations, you can perform. Custom permissions like only view published articles and whether you can only work with items you created, and policies are bundles of permissions that can be applied to either roles or individual users.\u003C/p>\u003Cp>Think of them as rule packages. For example, a content editor role might have policies that allow them to read all articles, create new articles, but only update their own articles, and a content editor might never delete anything or not have the permissions to delete anything. What's cool about policies is their flexibility. You can create one policy, like basic content management, and apply it to both the junior editor role and specific users who need those permissions. It's like creating a standardized set of rules once and then using them wherever you need them.\u003C/p>\u003Cp>So, remember, access control isn't just about yes or no, it's about who can do what, where, and under what conditions. Next up, we'll see how to configure these permissions in Directus. Here we have a posts collection with a field denoting the author. This is a many to one relationship with the director's users collection, and what this means is that each one of these represents a user in our project that could authenticate with this project. So here we see this one is authored by Beth, 2 by me, and 1 by Carmen.\u003C/p>\u003Cp>Now we have an access policy here, which denotes how users can interact with the posts collection. Now remember, the public do not have access to this collection. Instead, we say that users who have this policy applied to them can partially read. We say that they can only read items where they are the author, and we do that using this dynamic variable here called current user, and the value of this will change depending on the currently authenticated user. Exactly the same with update and the same with delete.\u003C/p>\u003Cp>This policy is attached to the member role, which in turn is assigned to Beth, Carmen, and Mike. My user is an admin. So let's see how this works in practice. So here we see we are trying to access the posts collection with no authentication, and we hit send. And as expected, we get a 403 error, which means forbidden, you don't have access to this, or it does not exist.\u003C/p>\u003Cp>As an admin, if I put in an admin token here, we see that we can access all posts. We see there is an author here beginning with 18b and an author here beginning with be8, and that is because admins have full CRUD access, create, read, update, and delete over all collections in the project. This is the exact same request, but with Beth's token, and we see here that if we hit send, we now only get one item returned. In turn, Beth can only update this item or delete this item, but not those created by other users. This is really nice because it means access control is set up and controlled by directus, which means you cannot inadvertently access data that you're not allowed to in your own application because it's all handled at a direct us level.\u003C/p>\u003Cp>So that's just a quick example of how access control works inside of Directus. I will see you next time on Authentication Avenue.\u003C/p>","Hey, developers. And welcome to authentication Avenue. Today, we're going to explore access control. How systems decide what different users can and can't do. It's like having a clever set of rules that keep everything organized and secure. Imagine you're at a huge museum. When you enter, everyone gets a different colored badge. Red badges are for the curators who can do everything. Blue badges are for the tour guides who can enter public areas. Green badges are for the cleaning staff who can access maintenance areas. And yellow badges are for visitors who can only view exhibits. But it gets even more specific because each badge has special symbols that show exactly what you can do. For example, looking at exhibits, that is the read permission. Creating new displays, that's the create permission. Rearranging exhibits, that's the update permission. And finally, removing displays, that's the delete permission. And here's where it gets interesting. Some staff members might only be allowed to change exhibits that they created themselves. Like a junior curator who can only modify their own displays, but not anyone else's. In the tech world, we call this ownership based access. Now in Directus, this system is handled through roles, permissions, and policies. Roles are like your colored badges, the broad category you belong to. Permissions are a single rule. For example, what collections you can access or what CRUD operations, that's create, read, update, and delete operations, you can perform. Custom permissions like only view published articles and whether you can only work with items you created, and policies are bundles of permissions that can be applied to either roles or individual users. Think of them as rule packages. For example, a content editor role might have policies that allow them to read all articles, create new articles, but only update their own articles, and a content editor might never delete anything or not have the permissions to delete anything. What's cool about policies is their flexibility. You can create one policy, like basic content management, and apply it to both the junior editor role and specific users who need those permissions. It's like creating a standardized set of rules once and then using them wherever you need them. So, remember, access control isn't just about yes or no, it's about who can do what, where, and under what conditions. Next up, we'll see how to configure these permissions in Directus. Here we have a posts collection with a field denoting the author. This is a many to one relationship with the director's users collection, and what this means is that each one of these represents a user in our project that could authenticate with this project. So here we see this one is authored by Beth, 2 by me, and 1 by Carmen. Now we have an access policy here, which denotes how users can interact with the posts collection. Now remember, the public do not have access to this collection. Instead, we say that users who have this policy applied to them can partially read. We say that they can only read items where they are the author, and we do that using this dynamic variable here called current user, and the value of this will change depending on the currently authenticated user. Exactly the same with update and the same with delete. This policy is attached to the member role, which in turn is assigned to Beth, Carmen, and Mike. My user is an admin. So let's see how this works in practice. So here we see we are trying to access the posts collection with no authentication, and we hit send. And as expected, we get a 403 error, which means forbidden, you don't have access to this, or it does not exist. As an admin, if I put in an admin token here, we see that we can access all posts. We see there is an author here beginning with 18b and an author here beginning with be8, and that is because admins have full CRUD access, create, read, update, and delete over all collections in the project. This is the exact same request, but with Beth's token, and we see here that if we hit send, we now only get one item returned. In turn, Beth can only update this item or delete this item, but not those created by other users. This is really nice because it means access control is set up and controlled by directus, which means you cannot inadvertently access data that you're not allowed to in your own application because it's all handled at a direct us level. So that's just a quick example of how access control works inside of Directus. I will see you next time on Authentication Avenue.","a0b96fa2-f5e3-4b0b-8083-80a555a7aa49",[171],"b32df2cb-479f-4aba-9aac-cd2933d6448d",[],{"id":133,"number":134,"show":122,"year":135,"episodes":174},[137,138,139,140,141],{"id":139,"slug":176,"vimeo_id":177,"description":178,"tile":179,"length":148,"resources":8,"people":8,"episode_number":180,"published":149,"title":181,"video_transcript_html":182,"video_transcript_text":183,"content":8,"seo":184,"status":130,"episode_people":185,"recommendations":187,"season":188},"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",3,"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.","a9f13359-7b06-4f50-a2c3-da41d60e927c",[186],"5b464654-0785-4256-9c30-9e61ee7f8205",[],{"id":133,"number":134,"show":122,"year":135,"episodes":189},[137,138,139,140,141],{"id":140,"slug":191,"vimeo_id":192,"description":193,"tile":194,"length":148,"resources":8,"people":8,"episode_number":195,"published":149,"title":196,"video_transcript_html":197,"video_transcript_text":198,"content":8,"seo":199,"status":130,"episode_people":200,"recommendations":202,"season":203},"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",[201],"97aaa6b6-31b8-48cd-980b-b3d2aa3219b2",[],{"id":133,"number":134,"show":122,"year":135,"episodes":204},[137,138,139,140,141],{"id":141,"slug":206,"vimeo_id":207,"description":208,"tile":209,"length":195,"resources":8,"people":8,"episode_number":210,"published":149,"title":211,"video_transcript_html":212,"video_transcript_text":213,"content":8,"seo":214,"status":130,"episode_people":215,"recommendations":217,"season":218},"what-are-cookies","1048670378","No, not those kind of cookies! In this comfortable sit on a bench at the end of Authentication Avenue, Kevin answers \"What are cookies?\" and shows you how to get them.","6c79160f-53b5-49c7-b6fc-5289010dc045",5,"What are cookies?","\u003Cp>Speaker 0: Hey, developers. Welcome back to authentication avenue. Ever wondered how websites seem to magically remember you as you click from page to page? Today, we're talking about cookies, tiny digital notes that follow you around automatically. Imagine you're shopping at a busy department store.\u003C/p>\u003Cp>When you first walk in, the greeter hands you a small numbered tag. Now here's the cool part, as you move through the different departments, you never have to explain who you are or what you're doing. The fitting room attendant scans your tag and knows which clothes you're trying. The cafe counter sees your tag and knows about your coffee loyalty points. Your personal shopper spots your tag and pulls up your size preferences, and the gift wrapping station automatically knows which items are yours.\u003C/p>\u003Cp>You never have to take the tag out and show it to anyone. Every department scanner just picks it up automatically when it's in your pocket. But here's the thing, this tag only works in this store. If you walk into the store next door that tag means nothing to them. Web cookies work exactly like this, when you visit a website it gives your browser a cookie, like that number tag.\u003C/p>\u003Cp>Every time you click to a new page on that same website, your browser automatically shows this cookie. You don't have to do anything, it just happens in the background. But just like that store tag, cookies only work on the website that created them. In web applications, cookies are small text files that your browser stores securely, automatically includes in every request to the same website, keeps separate for different websites, and expire after a certain time. In Directus, when you log in with cookies enabled, it sets a cookie in your browser.\u003C/p>\u003Cp>After that, every request you make to Directus automatically includes this cookie. That's how it knows it's still you, page after page, request after request. So remember, cookies are like that magical shopping loyalty card. They work automatically in the background, making sure that websites remember who you are with every click. Let's see how cookies work in Directus.\u003C/p>\u003Cp>Very simple web page that includes a button, and when the button is clicked, we will run this function. All the function does is send a post request to our login endpoint, with the email, the password, and a mode of session, which tells directors to send a cookie in response, not a JSON payload with our access token. Once successful, it will log cookie set. So here is the web page here, and we click log in, and we see that the request goes out and comes back. And the data that comes back, it doesn't have much in the payload at all.\u003C/p>\u003Cp>It comes back with expiry time, but it also sends back a cookie with the value. So we see that here. Now session cookies are interesting in that they also include the refresh portion of the of the, access token all as a single token. So once it expires, that's it. You can no longer use it, but you can refresh it before it expires, using the single key.\u003C/p>\u003Cp>So here we have a cookie and we see over in application cookie settings that that cookie has been saved to our browser. Now in any subsequent requests, this cookie will be automatically included in requests without us needing to authenticate separately. So that's just a really, really surface level understanding of how cookies work and where you can find them inside of your browser dev tools. Thank you so much for joining me for this episode of Authentication Avenue.\u003C/p>","Hey, developers. Welcome back to authentication avenue. Ever wondered how websites seem to magically remember you as you click from page to page? Today, we're talking about cookies, tiny digital notes that follow you around automatically. Imagine you're shopping at a busy department store. When you first walk in, the greeter hands you a small numbered tag. Now here's the cool part, as you move through the different departments, you never have to explain who you are or what you're doing. The fitting room attendant scans your tag and knows which clothes you're trying. The cafe counter sees your tag and knows about your coffee loyalty points. Your personal shopper spots your tag and pulls up your size preferences, and the gift wrapping station automatically knows which items are yours. You never have to take the tag out and show it to anyone. Every department scanner just picks it up automatically when it's in your pocket. But here's the thing, this tag only works in this store. If you walk into the store next door that tag means nothing to them. Web cookies work exactly like this, when you visit a website it gives your browser a cookie, like that number tag. Every time you click to a new page on that same website, your browser automatically shows this cookie. You don't have to do anything, it just happens in the background. But just like that store tag, cookies only work on the website that created them. In web applications, cookies are small text files that your browser stores securely, automatically includes in every request to the same website, keeps separate for different websites, and expire after a certain time. In Directus, when you log in with cookies enabled, it sets a cookie in your browser. After that, every request you make to Directus automatically includes this cookie. That's how it knows it's still you, page after page, request after request. So remember, cookies are like that magical shopping loyalty card. They work automatically in the background, making sure that websites remember who you are with every click. Let's see how cookies work in Directus. Very simple web page that includes a button, and when the button is clicked, we will run this function. All the function does is send a post request to our login endpoint, with the email, the password, and a mode of session, which tells directors to send a cookie in response, not a JSON payload with our access token. Once successful, it will log cookie set. So here is the web page here, and we click log in, and we see that the request goes out and comes back. And the data that comes back, it doesn't have much in the payload at all. It comes back with expiry time, but it also sends back a cookie with the value. So we see that here. Now session cookies are interesting in that they also include the refresh portion of the of the, access token all as a single token. So once it expires, that's it. You can no longer use it, but you can refresh it before it expires, using the single key. So here we have a cookie and we see over in application cookie settings that that cookie has been saved to our browser. Now in any subsequent requests, this cookie will be automatically included in requests without us needing to authenticate separately. So that's just a really, really surface level understanding of how cookies work and where you can find them inside of your browser dev tools. Thank you so much for joining me for this episode of Authentication Avenue.","90d34055-1ae9-4c0a-976a-7b43222ee509",[216],"8d0a1b2d-7958-4a56-a967-a099adf9c590",[],{"id":133,"number":134,"show":122,"year":135,"episodes":219},[137,138,139,140,141],{"reps":221},[222,278],{"name":223,"sdr":8,"link":224,"countries":225,"states":227},"John Daniels","https://meet.directus.io/meetings/john2144/john-contact-form-meeting",[226],"United States",[228,229,230,231,232,233,234,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],"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":279,"link":280,"countries":281},"Michelle Riber","https://meetings.hubspot.com/mriber",[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,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,259,470,471],"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",1773850414217]