 Want to know more about refresh tokens and how to store them securely then keep watching this video because I'll be covering both topics Hey, everyone. I'm Will. I'm a developer advocate here at off-zero in this video I'm going to talk about refresh tokens as they are defined in 0 off 2.0 You'll learn about how refresh tokens compare against the other two token types and how they balance security usability and privacy But first let's talk about what is a token? Tokens are pieces of data with just enough information to carry out the process of determining the user's identity or Authorizing the user to perform an action Tokens are artifacts that allow applications to perform the authorization and authentication processes Some identity frameworks and protocols use token based strategies to secure access to applications and resources For example, we use oh off 2.0 for authorization and open ID connect for authentication oh off 2.0 allows an application to access resources Hosted on another server on behalf of the user Oh off 2.0 uses access tokens and refresh tokens Open ID connect allows for user authentication user consent and token issuance Open ID connect uses ID tokens Now let's talk about the three type of tokens that are used with open ID connect in oh off 2.0 After that, we'll see just how important tokens are in building applications that are great to use without Compromising security first. Let's talk about ID tokens. What is an ID token? An ID token is an artifact that client applications can use to consume the identity of a user ID tokens can contain information about the name email and profile picture of a user Applications can then take that information and build a user profile and customize that user's experience The authentication server that's using open ID connect to implement Authentication issues its clients and ID token when the user logs in the consumers of ID tokens are mainly single-page applications and mobile applications Now let's move on to access tokens. What is an access token? When the user logs in the authorization server issues an access token that Access token can be used to make secure API calls when a client application needs to access Protected resources on behalf of the user the access token signals to the server that the client is Authorized by the user to perform certain tasks or access certain resources Oh off 2.0 doesn't define a format for access tokens But here at off 0 we issue access tokens for API's that follow the JSON web token standard or JWT for short Keep in mind that an access token is a bearer token Meaning that anyone who holds the token can use it and since the access token isn't used to identify the user attackers could compromise the system and Still access tokens then get access to protected resources by presenting the tokens to the server Because of that risk it is important to have security measures that minimize the risk of compromising access tokens One way to reduce the risk is to create access tokens that have a short lifespan like hours or even days There are different ways that a client can get a new access token for a user for example Once a token expires the client app could ask the user to log in again to get a new access token or The authorization server could issue a refresh token to the client app that lets it replace an expired access token with a new one now Let's get to refresh tokens So what is a refresh token? What is a refresh token? I said earlier in the video that making an access token with a short lifespan is a great way To make your app more secure when the access token expires Applications can use a refresh token to get a new access token Without asking the user to log in again the client application can get a new Access token as long as the refresh token is valid and unexpired a Potential downside of a refresh token with a long lifespan is that it could give too much power To the token bearer to get access to protected resources The bearer of the token could be anyone a real user are a bad actor Because of this risk we had off-zero Created mechanisms to ensure that this powerful token is mainly held and used by the intended parties Now let's talk about when to use refresh tokens Remember all off 2.0 defines refresh tokens and access tokens if we were using something like Samo we wouldn't be using access tokens or refresh tokens if you're a web developer Access tokens and refresh tokens are common because the web extensively uses token-based authentication and authorization with oh off 2.0 and open ID connect oh off 2.0 and open ID connect both bring a bunch of authorization and authentication flows each flow has its pros and cons which dictates when to use access tokens and refresh tokens Is the client a traditional web app running on the server use the authorization code flow? Is it a single-page application? Use the authorization code flow with proof key for code exchange Is it a single-page application that doesn't need an access token use the implicit flow with form post? Is the client a resource owner use the client credentials flow? It's the client absolutely trusted with user credentials use the resource owner password flow With the implicit flow the authorization server should not issue refresh tokens The implicit flow is often used on single-page applications, which run on the front end There's no easy way of keeping a refresh token Secure on its own on the front end use the authorization code flow with proof key for code exchange reduces many risks that comes with using the implicit flow a Potential risk when using the implicit grant type is that the access token is transmitted in the URI fragment Which can possibly expose it to unauthorized parties? Implementing proof key for code exchange still doesn't have any impact on how secure your refresh tokens are and In some cases you may not need refresh token There are situations where you can still get an access token without interrupting the user and without relying on a refresh token You can keep the session going with cookies or you could use something like silent authentication Since billions of people use single-page applications every day, it's important to give users an experience that balances security and convenience You can do that with token refresh rotation Refresh token rotation makes it acceptable to use refresh tokens with single-page applications The spec says that when you can't verify that a refresh tokens belongs to the client Then we should not use them unless we have refresh token rotation in place Okay, so let's get to the second part of this video. Let's talk about keeping refresh tokens secure A Refresh token with a short lifespan improves security But it comes with the cost when it expires the user needs to log in again to get a new refresh token Constantly having to re-log over and over again isn't a good user experience Even if it's for the user's protection Refresh tokens can help you balance security and usability since refresh tokens simply live longer You can use them to request new access tokens After the shorter live access tokens expire and since refresh tokens are bearer tokens You need a process in place that limits their uses if they happen to get leaked or compromised Anyone that holds refresh tokens can get access to new access tokens Whenever they want whether it's legitimate user or an attacker The team at all zero has created a set of features that reduce the risk that come along with using refresh tokens One of those is applying safeguards and controls to their lifecycle. We also use refresh token rotation That comes with automatic reuse detection. All right, so let's dive a little bit deeper into refresh token rotation refresh token rotations guarantees that every time an app exchanges a Refresh token for a new access token a new refresh token is also returned With that you no longer have a long live Refresh token that could give illegitimate access to resources if it was compromised the threat of illegitimate access is reduced when the Refresh tokens are constantly rotated and invalidated when refresh token rotation is enabled every time your application Exchanges a refresh token to get a new access token the authorization server also returns a new refresh token pair This reduces the risk of replay attacks of replay attacks from compromised tokens Let's talk about something that I mentioned earlier refresh token Automatic reuse detection remember that refresh tokens are bearer tokens and that when receiving a request for a new access token The authorization server doesn't know who is legitimate or not We can then treat all users as possibly malicious. So let's talk about a scenario Let's say you have a legitimate user and a malicious user and they're both trying to request Access tokens at the same time legitimate user one has access token one and refresh token one The malicious user manages to steal Refresh token one from legitimate user the legitimate user uses refresh token one to get a new refresh access token pair The authorization server returns Access token two and refresh token two to the legitimate user the malicious user Users refresh token one to request a new access token What do you think should happen next? With the malicious user managed to get a new access token Now, let me tell you what happens when your identity platform has automatic reuse detection The authorization server has been keeping track of all the research token descending from the original refresh token and it then creates a token family the Authorization server recognized that someone is reusing refresh token one and immediately invalidates the token family including refresh token two Then the office zero authorization server returns access denied to the malicious user Access token two expires and then our legitimate user Attempts to use refresh token two to request a new refresh access token pair Then the office zero authorization server returns access denied to the legitimate user Then the office zero authorization server requires Reauthentication for the legitimate user to get a new access token refresh token It is critical for the most recently issued refresh token to be immediately invalidated When a previously used refresh token It's sent to the authorization server This prevents any new refresh tokens from the token family from being used to get new access tokens But this protection mechanism works regardless whether it's a legitimate user or a malicious user is able to exchange Refresh token one for a new refresh access token pair before the other without enforcing sender constraint The authorization server can't know which actor is legitimate or malicious in the event of a replay attack automatic reuse detection is a key component of a Refresh token rotation strategy The server will invalidate the refresh token that has already been used But since the authorization server has no way of knowing who's legitimate or malicious it invalidates the entire Tokens family just to be safe Not only do we need to balance security and convenience We also need to add privacy to that balancing act recent developments in a browser privacy technology like intelligent tracking prevention ITP Prevents access to the session cookie requiring users to re-authenticate There is no persistent storage mechanism in the browser that can assure Access for the intended party only due to that long live refresh tokens are not suitable for single-page applications Because there are vulnerabilities that malicious users could exploit to obtain these valuable artifacts and grant them access to protected resources Since refresh token rotation does not rely on the off-zero session cookie It is not affected by ITP or similar mechanisms However, a refresh token could have its lifespan limited by the lifespan of an access token This means that we can safely use refresh tokens to play along nicely with browser Privacy tools and provide continuous access to end users without disrupting the user experience Did you know that you could store refresh tokens in local storage? Yeah, you heard that right When we have refresh token rotation in place we can store tokens in local storage or browser memory You may have heard before Even for us here at off-zero that we should not store tokens in local storage Storing tokens in local browser storage provides persistence across phrase refreshes and browser tabs but if Malicious users managed to run JavaScript in the single-page application using cross site scripting They could actually receive the tokens that are stored in local storage a Vulnerability leading to a successful cross scripting attack could be present in the single-page application source code or Any third-party JavaScript code that the application consumes such as bootstrap or Google analytics We can reduce the absolute token exploration time of tokens to reduce the security risk of storing tokens in local storage This reduces the risk of a reflected cross-site scripting attack, but not a persistent one a Refresh token may have a long lifespan by configuration However, the long lifespan of a refresh token is cut short by refresh token rotation The refresh token is only valid during the lifespan of the access token, which is short-lived The off-zero token best practices document Outlines some basic considerations to keep in mind when you're using tokens. I'm going to outline them here Keep it secret. Keep it safe. Do not add sensitive data to the payload. Give tokens an exploration Embrace HTTPS Consider all of your authorization use cases store and reuse a Link to that full document is available in the blog post. That's linked below that coincides with this video the off-zero dashboard makes it easy for you to configure your authorization and Authentication services to use refresh tokens off-zero's SDKs and libraries support refresh tokens for use in web applications mobile applications as well as single-page applications for additional Resources on how to use refresh tokens with off-zero. You can read our docs about refresh tokens Which are also linked below in the blog post that goes with this video. Thank you so much for watching this video You learned about access tokens ID's hokens as well as refresh tokens And we learned how to use refresh tokens to keep your application secure and how you can use Off-zero and refresh tokens together to keep your application secure for your users Comment down below what you learned and anything else that you'd like to see until next time Thank you