Cookie

Origin: Shopping cart

• It started earlier. It wasn’t Internet Explorer, it wasn’t Chrome, it was Netscape.
• At that time, the browser developers, the companies that made the browsers, would also help other people build websites.
• What was that about? There’s an e-commerce site that wants shopping carts. How are shopping carts made now? No matter taobao or what website, their shopping cart is stored in the server)
• But the developer at that time he does not want to save information on his server, you did not buy, I save what ah, you save local, but how to save local? It doesn’t work that way.
• So he went to work as the developer of his website, and the guy from the browser company said, “Why don’t you add this function to the browser? You’re the developer of the browser and the developer of the website. It’s easier to do this at this time.” And then the browser developers say, ok, I’ll do it for you, and then they just go ahead and do a whole feature.
• This feature is called Cookie. It’s used to keep track of the shopping cart, only because the server doesn’t want to keep track of it, wants to keep track of it locally, on every computer that adds a shopping cart.

Working mechanism:

• It is a local record, so local record a server needs information, how to do?
  • Basically, what does the server want you to save? It’s the server’s own record, and it’s the client’s record.
  • The server needs you to save something, and then send it to you, you save it locally.
• Step one, I’m in this website, and I want to add an apple to my shopping cart. How?
  • I go to the Cart interface and POST a data apple=1, which means I want to add an Apple to my cart. (The principle and working mechanism of HTTP can be supplemented if you do not understand the request and response packets.)
• Okay, so the server knows. And then the server will send me a message:
  • Cart =”apple=1″(not Cookie, set-cookie)
  • A Cookie is a Cookie that the client gives to the server, and a set-cookie is a Cookie that the server gives to the client.
  • Then the client takes note. Ok, I know, I’ll append it the next time I visit Shop.com
  • (The shop.com below the client in the figure below is the request address of the server, which is corresponding to the above request. Moreover, after the cookie is saved, it has an automatic mechanism to continue. When the browser accesses the content again, its cookie will be automatically attached, which is automatic, implemented by the browser. Web developers don’t have to care, and users don’t have to either.)

• Next time, I’m going to add something, like I’m going to add a banana,
  • I’m just going to send in that I need a banana, and I’m going to attach this cookie that I have locally, and I don’t have to take care of it, the browser takes care of it, the server doesn’t have to take care of it when it sends a message,
  • Now, I’m telling the server I want to add a banana through this POST, and I’m telling the server I’ve added an apple through this cookie,
• And then the server knows, and it sends back a message telling you to write it down, write it down locally. At this point the client automatically updates this thing.
• Notice, the server doesn’t remember anything, he doesn’t care, the client does, so it still doesn’t affect communication.

• At this point if the client wants to check out,
  • He doesn’t need to post anything else, because the cookie will bring his shopping cart to him, and the server will return it.
  • Here is a thing very wasteful, I send shopping cart information to you, you send me again, so wasteful ah, really troublesome, since you help me to deal with, I don’t deal with the end?
    • This is early, JS this thing is still very backward in the early stage, the server to help you do a thing, and he will do some additional things, to help you do verification ah, there are no goods these, I just pass him in the past, and then back, but this work or to the server to do.
  • Who manages cookies?
    • It’s the server. Every change is made by the server. The client is completely a passive save machine.
  • That’s why Cookie designed this mechanism. That’s what the server needs to save, tell it, and the client saves it unconditionally, and then every time it visits back, it takes it back.

• We know a lot about cookies, because in our work, we use cookies very little in mobile development. We used them a few years ago, but now we don’t. Gradually abandoned, but abandoned not cookies, but the use of cookies to do login, with cookies to do authentication.

Function:

Session management: Login status, shopping cart

• So how do we manage login status with cookies?
  • First, I send an HTTP request to the server, login,
    • I want to log in, I add my user name and login password to the server for confirmation.
  • How does the server confirm?
    • He’s going to record that a (Username) is logged in,
    • And he’s going to create a session for this thing, which says I’m talking to some client, or some user agent, and I’m talking to him, and what state he’s in, and he’s either logged in or he’s not logged in, but we’re in a conversation.
    • He will record his session, for example, his ID is 123. He would have saved it,
    • And then I’m going to send back my session ID, the server is going to send back to the client, session is a name, I could call it session, I could call it metting, whatever, it just means that I’m interacting with the client, and then it’s going to send back,
    • Session is also through set-cookie. He orders it through the server. The client doesn’t care. I just write it down.

• And then when the client accesses it again,
• It will automatically move the session over, and then when the server receives it it will check if there is a session id=123,
• Oh, he’s username A, and he’s logged in, okay, he wants user information, right? I’ll give it to him because he’s logged in.
• And then it will come back normally. This one uses cookies to manage login status.

• Cookies, like session identifiers, can have multiple identifiers
  • Now I use sessionID to manage my login information, right? And although I have saved your login information in session, I don’t want to save your shopping cart yet. It doesn’t matter, you need to add an Apple, right? It’s the same process as before, you send an apple=1, I send you a cart= “apple=1”, you write it down,
  • You can remember two cookies,
    • A sessionID to manage your login,
    • A cart manages your shopping cart, and two things don’t interfere with each other. Cookies can be multiple.

Personalization: user preferences, themes

• How do you use cookies to manage user preferences?
  • For example, I now have a website called Shop.com, with a black theme and a white theme. I request to the server, and after the request, the server returns me a client_ID, which is the same as the session ID, and it is a mark. I send this mark to you and slap it on my face. And every time you talk to me, I see that you’re the one who made the mark.

• Next time you tell me that I want to change the blue theme, send a special request to change the theme. The server thinks it is ok and returns OK, which is a normal return. Then the server remembers that the person with client_id=123 likes the blue theme and saves it for you.

• HTTP is stateless, so if you don’t save 123, the next time you go to another page, you’ll be given the default theme, because I can’t remember you, I didn’t know you were the last person.
• So the next time I visit, this cookie is automatically attached, and then it’s going to go to a different page, not the same page, not a page with a different theme, but the server just knows that I’m going to give it a blue theme, because it’s 123.
• This is the site used to manage user preferences in a way of recording, using cookies in the client record.

Analyzing user behavior:

• About analyzing user behavior, the use of user tracking

  • This is controversial abroad, especially in Europe. Login in our website, don’t know if you noticed, especially some foreign websites, domestic site also is not very care about this, because to do with the law related to the local law, with ethical relationship is tiny, is usually associated with the law, the law requires you to do that, or is the consciousness of people, you have to do that do that, What if you don’t do this and people stop using your site? To do it. Analysis of user behavior, tracking user behavior, that is, you can know the user to the web, so when we visit foreign websites, he said with you at the top or bottom, now visit the web site you are using cookies to track the tracks, you this there is no harm to you, and we must not put your message to the public, It’s just for our own use. Please understand. They all use something like this. We may seem to think that you are so redundant, you can use it, and you tell me why it bothers me? But the thing is, in those countries, especially in Europe, it’s illegal to use cookies to track users without notifying them, and there are penalties, like huge fines, so all they have to do is declare it, and the user clicks “ok.” All of them. A few of them don’t. This user tracking is very valuable. If you really care that much then you should stop using it. I can’t. I really want you to use it. I really want to earn your money.

• Tell me how this thing works.

  • I have a client and a server, and I want to ask you for a piece of data,
  • Then the data you return is kind of interesting. In the body you return a link to the image that you link to, automatically. Just like opening an online image on your website,
  • But what’s the key thing about him?
    • From=shop.com, I’m visiting shop.com, right? He went to another website (3rd-part.com), which is a website that helps to record the whereabouts of users.
  • The tracking of user information is never from site A to site A and site B to site B. There is always a unified site, he goes to record the movement of users to various sites, and then he makes a statistic. Then let other sites together to use, a site only record a site in the current, only record users in their own behavior is useless. This is not called user tracking. There is a unified website to remember.
  • In this example, there is this 3rd-part.com. He records the user’s behavior in shop.com. Then what effect does this link have?
    • This is the user who opens the site, automatically displays an image, maybe an AD or something, and then attaches a message to that image, and that message has nothing to do with the image. If I go to Tabao.com, I will go after tabao.com. They show the same picture, but it is different for third-party recording websites.
    • So he’s going to write down, the current user is from Shop.com, and he’s going to add one entry to his data. What’s that? This user has been to Shop.com.

• The server returns this Cookie and the client notes it (client_id = 123),
• Then the client will automatically send a request to the third party when accessing the picture. How to display the picture without sending a request? How to download the picture? Then you have to ask this third party.
• Then the third party website (3rd-part.com) will record, add a entry to his database, this user named 123 from Shop.com, he will add this user record.
• Next, he will give you the picture, and then, give you such a record, also can give a an id for third party websites, the two id may not be the same thing, their name is different also, after they face value can be different, because they are just a tripartite website used to record the user’s movement.
• If, then, the user goes to another site, if that site is also bundled with the same third party statistics, then what will happen? He will also visit the image of that site.
• Then the third party will know that the user has been to Shop.com before, and now comes to Taobao.com. Let me record that the user likes shop.com and Taobao.com and likes to go to these two websites.
• So this time there is a certain portrait of the user. He went to two websites, if the user went to a lot of websites, although I don’t know who you are, but I know what kind of person you are, then what does that mean? It means advertising is coming up. For example, I went to a travel website, and now I go to an e-commerce site, and he might push tour listings. In addition, the space of imagination is very large, that is, after you get enough user data, you to the user’s portrait is accurate enough, he can push a lot of advertising. In fact, this kind of tracking user behavior, is for what? It’s all about advertising. It’s all about taking money out of your pocket.

Say two extra things

XSS Cross-site Scripting :HttpOnly

• XSS cross-site scripting attacks
  • Attack? Assault is not just me hitting you, I’m hitting you any kind of aggression is assault.
  • Our JS, our webpage script, he may help our webpage to do some very convenient things, in addition, he can also get his cookie, to use cookies to do some very convenient things.
  • However, he may also do bad things, such as what do we record user information by? So if your cookie is not storing your shopping cart, it’s not storing your preferences, it’s storing your login information, if a bad guy wrote js, what would he do? He might take your local cookie and send it out, he might go to an address, like a cookie address on their own website, send it out, and you don’t even know it, and the background does it. Your cookie is compromised, your login information is compromised. A JS, a local script to get the header information how normal, very normal.
  • That’s why cookie is so dangerous. Because we log in this thing, originally does not exist, and then slowly out, we use cookies to do, and then slowly people use this vulnerability to do bad things. One of my scripts, get your cookie, directly to send away, even email do not need to directly visit a web page, a URL can be.
• One of his policies was to add an HttpOnly restriction to the cookie header.
  • Such as: the Set – cookies: sessionid = 123; HttpOnly
• What effect did he have?
  • It’s this cookie that your local script doesn’t see, it’s only used for our HTTP exchange, it’s only used for information exchange, it’s not used by your local script, so if you’re a cookie that contains sensitive information, like login information, then you add this thing to restrict it. It was all figured out later.

XSRF Cross-site Request Forgery :Referer

• Cross-site request forgery
  • This one is a little more raunchy, and a little unexpected. What is he? Cookie is an automatic mechanism, so if I go to a website, it’s a bank website, and I go to a bad guy’s website, I don’t know the bad guy’s website, the bad guy has added something to his script, what has he added? Let me go to an address, let’s say I go to an address when I’m using an image, and when I go to an address I attach something else, let me go to a bank, and he’ll try out all the banks, and I’ll bet you’ve been to a bank recently and you have cookies.
    • Here’s a URL: bank.com/transfer?am…
    • It’s just a URL, you go to it, you transfer money to the bad guys, you don’t need me to log in, you don’t need me to confirm, why? Because there are cookies, cookies are automatic, right? If I have logged in this website before, so he just secretly visit this website, brush, my money transferred away.
    • Of course there are all kinds of precautions in practice, banks do this, browsers do this with each other, but this is a prototype for bad things.
• So one of the solutions, one of the solutions is Referer, Referer is spelled wrong, Referrer should be spelled wrong for historical reasons.
  • Usage: Referer:www.google.com
  • It is used to show you which site you have jumped from. If the bank finds that your URL, your url for applying for transfer, is from a website I don’t know, or a dangerous website, THEN I refuse to transfer money to you. However, this solution also has its drawbacks, you need to rely on the browser, the browser needs to be able to do this function for you, if the browser does not do this function for you, WHEN I jump from website A to website B, I do not automatically add the Referer header for you, it would be blind.
• But it’s a long story, and these are both dangerous points for cookies. Cookie has many dangerous points, but not because it is bad, but because it is inherently inferior, because it wants to gain any benefits, so there will be any dangers. Why was cookie abandoned? It’s not that he’s abandoned, it’s that he’s no longer authorized.

2.Authorization

• Authorization is more popular than cookies, and it’s getting more popular.

Authorization is most commonly used in two ways:

Basic:

• Basic is the basic authorization method, which is useful even if we don’t use it very much.
• Authorization:Basic<username:password(Base64ed)>
  • Example:
  • Get/user HTTP / 1.1
  • host: xxxxxx.xxx
  • Authorization: Basic eGlhb21pbmc6cWl1bG9uZw = =
• For example, now I want to make a request, and I have a header called Authorization: Basic XXXX, which is the authentication information. If the data is correct, I can get the user information. If the data is wrong, the user information cannot be obtained. This is an HTTP request, that’s how it’s used, it’s inside the header.

So what’s in this XXXX?

• Base64 Converted user name and password.
• For example, my username and password are xiaoming and Qiulong,
• Xiaoming: Qiulong
• Eg. After transformation, it is

I’m going to do this and the data server is going to give me the right information, and this is BASIC,

• Why basic? Because it is the most basic information, the user name and password are all given to me.
• What’s wrong with it? He’s a security risk. What if your stuff gets intercepted?
  • In fact, most websites now, especially apis, are outside of the browser, so when you use your application, it’s all HTTPS, so security is OVER HTTPS, and I can actually just send my username and password, because they’re all encrypted and nobody can see them.
  • However, it does have a security flaw, a little bit, which is that if you need to do this, you’ll need to save the base64-transformed username and password, or those before base64, locally so you can automate the thing the next time you request it. Rather than having the user enter a username and password every time, right? You change the page and let the user type once, the user is not crazy?
  • Then you take her to your local, whether it’s to save to your computer, or save to your phone, if you this device was black, such as your mobile phone to you to get the root, root you then took him to a particular software, and then he can literally operating your cell phone, he stole is likely to take your things.
  • In fact, this kind of security risk is not bad. In fact, he obtained the root permission of his mobile phone, which itself gave up certain security, right? The mobile phone was cracked, can you blame this mechanism? There’s some software out there, and some of the bigger, more tech-heavy companies are using it. So it’s safe in itself. The security risks I was talking about are relatively good. The risk is when the device is hacked. That’s what risk is. This is the first one, but there are still fewer companies. It works. It’s easy.

Bearer:

• Bearer of false tickets
  • The one with the sword, you need to use your sword to do things. This is called token, the above basic has the form of token, but it can not be called token, strictly speaking, you can also use the username and password together base64 as a ticket root. But Bearer is the real token of comparison.
  • I wasn’t that person, but that person gave me permission, so I take this token, and I can use this token to get information, to do things. This is a very common way to do it. His format looks like this:
  • Authorization:Bearer<Bearer token>
  • In front of me, I have been Bearer of false certificates with Bearer’s token instead of basic. Sometimes, when you use Github or Sina Weibo to authorize other software, you don’t need to skip to this website to log in, but directly obtain the token from your account information. Get the API token. You just copy the token to some software. This is a way that the token itself can be taken out and used by others. The other is OAuth2.

OAuth2:

• It is a third-party authentication mechanism.
• OAuth we all use 2 now, 1 was a few years ago, 2 is not much different from 1, they are all the same core, but it does something to make developers care less about things without compromising security.

OAuth2 process: Example of third-party authorization

• First go to github-setting-Application and retrieve the nuggets’ authorization.

• Now go to the Nuggets and log in, select Tripartite Github, and he will be taken to a page like this.
• Who is the third party?
  • Now I’m making the user is not I am Denver’s users, now I use a lot of time I need to do a third party authorization, I am going to put some of my permissions granted to other sites, such as the site is called the nuggets, the third party is the Denver nuggets, a third party is the place where I jump out to do certification, this place can be a bit fan, well, Don’t I use Github to log in? How did a third party become the Nuggets? It’s not that I want to emphasize some concepts, but that you need to be clear to understand something else.
  • Remember, the third party is the Nuggets, and the first and second parties are you and Github. You’re going to license your information to another site and you’re going to do this.

• So when I want to authorize a third party, I now click on a Github login, I go to a Github page, who came over?
  • The Nuggets brought it to me. The address of the authorization page is github.com, and the key information in this page is client_id.
  • This client_id is an ID github granted to the Nuggets. When did he grant it?
  • The Nuggets’ developers applied to Github. This is Github and he’s going to have a marker for the Nuggets, so what’s the use of that marker?
  • What it does is when you open the page, you pass in client_id, and github will automatically give you the icon of the nuggets, and the name of the nuggets, and what permissions they need, and the url below, and when the user sees that, he’ll say, “Who do I need to authorize, Is it the object I think, because sometimes the website will do forgery, will do hijacking of what, if you do not have this step, he may give you in the process of authorization he changed. You think you are authorized to nuggets, in fact you are authorized to some other bad website, then bad people will abuse your information. This client_id is used for this purpose. It is used for identification.

• So what HAPPENS is I click ok on Github, authorize xITU, send the request, the page disappears, login is successful.
• So what happens to this sequence of events?
• When I clicked on it, github bounced back to the Nuggets’ site, returning an Authorization code.
  • The Authorization code is not a token, why doesn’t he just give the token?
    • There is a key reason that HTTPS is not mandatory. It is not mandatory for you to use HTTPS in the OAuth process. Then my process may be intercepted or stolen by others. Wouldn’t someone else be able to use it if they stole it?
    • What else? Browsers are unreliable. You don’t know what browser users are using or what operating system users are using. After the Authorization code is transmitted to a third party, it may still be leaked. Github just gives you a code, which means that my user has told me that he is willing to grant you the permission (Nuggets), this is a proof that he is willing to grant you the permission, but it is not a key, it is just a proof, you give me this code, ask me for user data, I will not give you, You also need the actual authorized note. Give me that token
    • Then how to obtain the token? So let’s move on.

• Now, my browser has gotten this information, and then he’s going to go to his server, and he’s going to send this code to the server, whether it’s HTTP, whether it’s HTTPS, this thing is not going to be stolen, it’s just proving that the user is willing to authorize.

• Then, when it gets to the server, it makes a request to Github. That is, a third-party server will make a request to the licensor’s server. It appends the authorization code and something called client_secret to the request.
• What is this client_secret?
  • He sent client_ID together with the third party when the Nuggets went to Github to apply for it. There is no difference between the two data themselves, but they are slightly different in practical use. This secret is absolutely confidential, and will not be seen anywhere, only the server of the third party holds it. This link is also an HTTPS link, which is an absolutely secure link. So now I have the code to prove that the user is willing to authorize me, and client_secret to prove that I’m the gold digger. At that point github knows, he gives me enough id information, it’s secure enough that he can’t be intercepted, he came over HTTPS, and github is comfortable enough that he sends the real Access token back.

• At this point the Server gets the token, and now the OAuth2 process is over. He doesn’t need to send your token to the client, he doesn’t need to send it to the browser. The user granted the Nuggets some access to Github, and the Nuggets got the token, and OAuth was no longer involved.
• Next, let’s say your Server retrieves information, like the user’s avatar or something. So how do we do that? Server requests Github.com and appends the token. How do you attach it?
  • Let’s say my token is ABCCCCC

• This process is safe, but because of some factual limitations, or some security carelessness, what else happens? The Server will send the token to the client. This does not mean that the token is not allowed, but it will affect the security. Even if someone else gets the token, he can do things.

• And then you can do that, and a lot of software does that. However, if you do this, you waste the benefits of the OAuth process. If you do this, you can simply return to the user after authorization. Why go to all this trouble? I mean, didn’t you go to all this trouble so that no one could intercept you? It doesn’t matter if your browser gets hacked, your phone gets hacked, your Internet gets hacked. Your token is still safe, right? But you’re doing it a little bit for nothing. But there is a certain probability that it will be used, and some companies will use it that way. It just doesn’t have the same security as OAuth2.

Third-party login example: wechat login

• Speaking of wechat login, I first talk about using Github login. Just now I said using Github login to authorize the third party, and his third party is Nuggets. But I want to say, third-party login this matter than the third party authorization to come a little later, third-party login his third party really is a lot, you are in Denver, using a third-party login, his third party is really making, due to the emergence of the third-party login the word, he led to a third party authorized this concept is very, very vague, very, very hard to understand. You can see why, right?

  • What is third-party licensing? Github and I shared it with you. Aren’t the Nuggets a third party?
  • And what is a third-party login? I was going to log in to the Nuggets, but I used Github, and that third party is Github.

• In fact, this login and authorization is very intuitive stuff, but you need to know who they are, who they are not for the test, not for the interview, but you will be very clear when you think about the question. And once you figure that out, and you look at some OF the API documentation and stuff, your mind will be very clear, and you’ll be able to figure it out better than anyone, and that’s the point.

• Back to wechat login, what is he?

  • It is a third party login.
  • For example, if you have a mobile app, there is a login button in it. You can log in using your username or a third party. For example, you can log in using wechat. So some people will do the development of wechat, whether you have done it or not, I want to say what is the mobile phone process of wechat login.

• First step, you will use the API given to you by wechat. Through this API, you will call the interface given to you by wechat to open the authorization interface of wechat, which is called wechat login. “You see authorized login, third-party authorization and third-party login are really mutually indistinguishable. The interface is wechat to authorize you, wechat to authorize this third party (your application), but what is his name? He is called wechat login.” When you click on this, wechat will close its page and give your app an Authorization code.

• Why did you get the authorization code? This is a complete OAuth2 process. Next, the normal way is that you tell your server this code, and then your server takes your code and secret to the wechat server to ask for your access token. After getting this token, If your client needs any data, your server will request any data. For example, your client needs the wechat user name and his avatar. Well, your server will take it, not the client. Clients should not hold tokens unless they have to. Even if you can’t, you can’t hold secret. The process of going to the wechat server to get the token must not happen on the client.

• I know some companies are doing it, some companies are doing it. Their backend staff may push this issue, which should not be done by us. You can see it clearly in wechat API. You are required to ask for it, and then you can ask for it after you get the code. Do you want Secret? I’ll give it to you. We have it. You go. The process is wrong. Your client gets the code, the code goes to the server, and you’re done. This is about safety, not convenience. OAuth wouldn’t be needed if it were for the sake of convenience. After the direct user agrees, the token is given to you. What is the process of exchanging tokens with code? Exchanging code for token may not be secure enough just because your client gets the data. This is wechat login. Wechat login is a complete OAuth process.

Using Bearer tokens in their own software

• That’s the way it works, so my software, for example, has an interface
  • (api.xxx.com/login?username=qiulong&password=123)
  • I enter this information, and my server just gives me this token (access_token= BDCJ55s)
  • When I use it again, I don’t need additional information, I just need to attach the Authorization:Bearer of BDCJ55s,
  • That’s what we’re going to do the next time I ask, and it doesn’t have the OAuth process, it’s the OAuth don’t do process that I said before. I pass in the username and password, you directly give me the token I want, the insecure process I mentioned. It is an imitation of OAuth2’s way of using tokens, but it is not an OAuth2 process. You know, this is not OAuth. That’s why a lot of people don’t understand OAuth2. It’s just some API, he’s using a simplified version of OAuth2, you go to some third party OAuth2 process and you see, how come this is so much more trouble than our company? Why does he need a code? The truth is that your company uses a simplified version of the process. It makes sense for you to log into your own accounts and use this simplified version, right? Otherwise, if you still use code, your Server will go to your Server with your code and secret to exchange that token. Wouldn’t that be unnecessary?
• In this process, he only uses the Bearer token model, but he is not an OAuth2 process.

refresh token

• A refreshed ticket stub.

• It looks something like this. The server returns not only an access_token, but also a refresh_token.

• This process returns not only an Access token, but also a refresh_token, which your server can use to call github.com, Github.com then returns the new access_token and a new refresh_token, and the old access_token is invalidated. Or your old access_token will expire after a certain period of time, say seven days, 15 days. Your assess_token will be automatically invalidated or will be forcibly invalidated by the refresh_token request. So what does this process do? What’s the point of him? I have a token why do you need to brush it? It’s just for security, it’s just your access_token. Anyway, there’s a chance he’s going to lose it. Then after you lose the token, you need the users to come back and authenticate again, which is a little unrealistic. Users are lazy and the acquisition cost of each user is very high. Hey, your token is invalid, please come back and authenticate again. Who cares? Right? That user might lose. So what do you do, you need to quickly invalidate the token for security, and then you get a new token, how do you get it? Refresh_token. It looks something like this.

• The server will then return you a new token and invalidate your old one. This is refresh_token, it definitely wants HTTPS. Both his process and the process of acquiring tokens should take place on the server side as much as possible.