Showing results for 
Show  only  | Search instead for 
Did you mean: 
Community Member

Refresh token generation in own canvas instance

Our Canvas Revel Integration provides seamless access to our Revel product. We  are presently working to add the ability to sync grades from Pearson Revel to Canvas. We are planning do a performance testing for this feature, since we can not use the Canvas Production environment for this, we created our own Canvas instance on Staging environment. Currently we are experiencing issue on that environment when requesting a refresh token. It will properly redirect to the Canvas Authorize page and once we click on the "Authorize" button it will redirect our page without refresh token.(with authSuccess=false)

What could be reason for this? Is there a way to troubleshoot this?

Request : 

Response : Pearson 

I have attached the fiddler trace herewith.

4 Replies
Community Coach
Community Coach

Hi manjulaprof

I think this question could best be answered in the Canvas Developers Group, so I am going to ping stefaniesanders‌ to see if she will move this for us. I just tried and failed.Smiley Sad


Thanks for the ping,  @kmeeusen ‌! I've shared this question with the‌ group.


I believe the problem here is that you are taking the user through the entire OAuth process each time, even through they've already authorized access one time before.

when requesting a refresh token. It will properly redirect to the Canvas Authorize page and once we click on the "Authorize" button it will return back to our page without refresh token.

The proper use of a refresh token will not require the user to re-authorize, so there is something wrong with the request (I'll go into that later). From the user's perspective, Canvas will take the user directly to your app without needing to re-authorize; the refresh process happens entirely server to server.

Undestand that at the end of the 3 step OAuth2 flow, Canvas provides for each user of your application a token, a refresh token, and a token duration (which is currently always 1 hour). Note that the refresh token never changes.

The best practice is to store the token, the refresh token, and the expiration time (current time + duration) in a database for that user. When the user re-launches, you skip the normal OAuth2 process, and instead use the token refresh process. Since the refresh token never changes, you don't need to use a code again.

A properly formed request, in your case, would look like this (I've highlighted differences):<your dev-key's secret>&refresh_token=<the token stored from the original authorization>

When using grant_type=refresh_token, the response will not contain a new refresh token since the same refresh token can be used multiple times:
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "token_type": "Bearer",
    "user": {"id":42, "name": "Jimi Hendrix"},
    "expires_in": 3600
Upon receipt, you can then update the access_token and expiration time for that user. Further documentation on how to format the request can be found here:
Hopefully that helps
Jesse Poulos
Partner Integrations Specialist
Community Coach
Community Coach


Were you able to find an answer to your question? I am going to go ahead and mark this question as answered because there hasn't been any more activity in a while so I assume that you have the information that you need. If you still have a question about this or if you have information that you would like to share with the community, by all means, please do come back and leave a comment.  Also, if this question has been answered by one of the previous replies, please feel free to mark that answer as correct.