Refresh token JS

I am trying to make a refresh token function and I followed the guide from https://dev.twitch.tv/docs/authentication/#refreshing-access-tokens but I don’t think I did it right.

Can someone help point me in the right direction, please? Also, is there a way for me to set the expiration time of the token or is that set by Twitch.

function refreshToken (storeToken, data)
{

if(storeToken != 0)
{
    console.log("Token still valid for " , storeToken);
}

else{
    console.log("Token is expired");

    return $.ajax({

        url : "https://id.twitch.tv/oauth2/token",
        type : "POST",
        grant_type : "refresh_token",
        refresh_token : data.refresh_token,
        client_id : gibberishHere.ci,
        client_secret : gibberishHere.cs,
        success : onReceiveToken(event),
        

    })
    
}

}

  1. this should never be done via ajax. As you are leaking a client secret in client side applications…

  2. Your ajax call is wrong… you didn’t specify a post body.

Hi Barry, if I should not do with this Ajax then what would be the optimal way using JS?

and i have no idea what this means “Your ajax call is wrong… you didn’t specify a post body.”

You can’t shouldn’t be doing it “client side” ajax is a method to perform requests client side. And you are leaking users secrets/refresh tokens. A refresh token should be treated as securely as a client secret. Which is why the implicit auth method (for client side stuff) doesn’t even return a refresh.

Your example code leaks your Client Secret as well, which is against the rules of using a ClientID for every API.

  • Client secrets are equivalent to a password for your application and must be kept confidential. Never expose it to users, even in an obscured form.

But you seem to be using jQuery ajax from your use of $

http://api.jquery.com/jquery.ajax/

You need a data key which contains the data you wish to post.

So, since you seem to be working pure client side, you should be using

Which returns an access_token only and no refresh

Ok I read over the links you gave me Barry (thank you btw) and I tried setting up the call in different ways but am still getting a failure. I read the ajax post stuff but not exactly sure how that setup should look. I talked to my prof and he was less than helpful basically saying go Google it.

So here is what I got so far (and yes I know the whole key, secret thing but this is for a class project, its fine, I am not concerned about that)

function refreshToken (storeToken, data)
{

    if(storeToken >= 120)
    {
        console.log("Token still valid for " , storeToken);
    }

    else{
        console.log("Token is or soon to be expired. Time remaining " , storeToken);

        return $.ajax({

            url : "https://id.twitch.tv/oauth2/token",
            type : "POST",
            data : {

                grant_type : "refresh_token",
                refresh_token : data.refresh_token,
                client_id : "HappyNewYear2019",
                client_secret : "ISwearIHateJSSometimes",
               
            },
            success : constants.successTag,
            error : () => {console.log("refresh failed ")},
            

        })
        
    }
    
}

I also am not too sure what response I am expecting to get back. Am I getting only a new access token or an access token and new refresh token? or the whole user object back?

As a teacher I’d be worried about it.

A fully client-side application should use implicit code flow. Refreshing in that flow is simply doing the auth again. It amounts to either a refresh loop or a quick popup window, as the user will already have authorized it (unless force_verify is used)

While I can appreciate that you guys are all about security and being actual developers, you all are totally not understanding this is a project to learn JS and JQuery, not a securities class. This feels like a stack overflow page where everyone is focusing on what they feel is important and totally bypassing / ignoring the actual question I am asking.

We can close this thread, I doubt I am actually going to get an answer to this question.

“As a teacher I’d be worried about it.”

You strike me as a person who would answer their students questions with a go google it response.

I’m sorry if I’ve come across as rude or unhelpful, but insecure practices are a massive issue and getting rid of them a personal priority of mine. Security needs to be an integral part of the development and design, not an afterthought.


The last code you pasted looks correct. The response is documented as

{
  "access_token": "0123456789abcdefghijABCDEFGHIJ",
  "refresh_token": "eyJfaWQmNzMtNGCJ9%6VFV5LNrZFUj8oU231/3Aj",
  "expires_in": 3600,
  "scope": "viewing_activity_read",
  "token_type": "bearer"
}

Specify dataType: 'json' and you can count on the response being this type of javascript object as your success function’s first parameter. But again, a purely client-side application should be using implicit code flow for both security and convenience.

1 Like

Thank you I am trying it now

. I know security is incredibly important but so many devs fail to realize that students are students, they are just trying to fulfill the requirements of the course. We don’t have control over what our assignments want we just do it to get our grade.

Also is there a way to make the expiry of the token custom or do i always need to wait the full duration?

Some providers allow for the expiration to be customized, Twitch does not. If you read up on OAuth2, there are some different thoughts on how to handle tokens that expire. Some would say renew before the expiration and some would say otherwise. Depends upon your application, use case, service provider, and performance requirements. In some cases, the refresh token itself may expire before a certain time, and so you must be proactive or force authentication again.

By literally doing the worst thing that you can do that is also prohibited under the Twitch API Developer Agreement, that you agreed to by creating a ClientID?

YOU MUST NOT LEAK YOUR CLIENT SECRET

https://www.twitch.tv/p/en-gb/legal/developer-agreement/

You are literally violating your agreement with Twitch. And putting your users of your application at risk

In addition every, single, API that uses secrets will say the same thing here. You cannot and shouldn’t be leaking your Client Secret via this sort of call.

If you must do this sort of call client side. Then you should be using implicit auth and not regular oAuth. Implicit auth’s cannot be renewed/refreshed by design. (Other than sending the user round the oAuth dance again)

Jesus christ, this is a school assignment not a product in use. Do you understand students are not professionals?

Yes tons of things are not being done to standard, I am sure at some point we will learn about proper protection. This is not the assignment for that rn.

You agreed to be bound by the terms of the Developer Agreement when creating a ClientID.

Do you not understanding you are breaking the rules and not implementing oAuth correctly at all and shouldn’t get a passing grade?

Take it up with the prof, I am just doing as i am told

Use OAuth Implicit Code Flow

Not OAuth Authorization Code Flow

When operating pure Client Side.

As you have demonstrated you are doing with your use of Ajax

From a legal point of view, you are the one who agreed to the Developer Agreement, so “just doing as i am told” is not a valid defence and you are the one liable for any consequences of violating the agreement.

I’m sorry if it’s frustrating that you’re professor is asking you to do something that may be in breach of the agreement, but at the same time there are limits to what anyone here on the forums can support you with as we do not wish to aid people in breaking their agreement, and if possible avoid bad practices/security weaknesses.

I get it, i really do, I am not trying to be difficult, I literally do not know enough to be doing so intentionally. I really just wanted help with the one thing, and I finally got it working thanks to 3ventic.

We can close/ delete this thread.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.