No option to remember OAuth2 authorization

[Pritpal Riat]

Hi, 

I have been trying to add OAuth2 authentication to my web app so that users can log in using there canvas credentials. I have managed to implement that successfully. However, I have noticed that when a user is redirected to the canvas authorization page, there is not checkbox option to remember their authorization. I don't know what the problem could be. I don't think its my implementation of OAuth as I pasted the authorization url in my browser to test it and the check box still didn't appear. Could it be some setting or something disabled on my canvas installation? 

Thanks

[Becky Kinney]

I've noticed the same thing. I'm getting sent a refresh token, but there is never a 'remember' checkbox for the user to check, and others have complained that the token returned when they use the refresh shortcut is invalid. It doesn't seem as if this whole refresh thing is really up and running, but I can't help wondering whether there is just something we're doing wrong.

Becky Kinney

Academic Technology Services

Project Blog

--

---
You received this message because you are subscribed to the Google Groups "Canvas LMS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to canvas-lms-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Humphrey]

Refresh tokens should be working as of the last canvas release. Are you saying the access token you get when you use the refresh token to get a new access token is invalid? (https://canvas.instructure.com/doc/api/file.oauth.html#using-refresh-tokens)

[Becky Kinney]

Brad,

Thanks so much for chiming in here. 

I haven't yet tried to obtain a token using the refresh scenario, but someone else had reported that the token they got that way failed. What I have observed for myself is that when I am authorizing a new token, I don't see a 'remember' checkbox. From the documentation, it seems that there should not be a refresh token sent unless the checkbox is checked. At least, that was my interpretation. However, I AM getting a refresh token along with the auth token whenever I successfully negotiate the dance. So, I'm pretty confused. I haven't yet set up a way to store refresh tokens, but I will once I figure out what is going on. Some more detailed documentation would be greatly appreciated.

When should I be expecting to see a refresh token, and how am I supposed to know whether or not the user has checked 'remember'? 

It is the case that I should only attempt the refresh shortcut if the user checks the remember checkbox when authorizing the original token? If so, why am I being sent a refresh token when there is no checkbox available to be checked? 

Do the same rules apply for developer tokens we issue in the account settings as for the ones Inustructure awarded us years ago?

Becky Kinney

Academic Technology Services

Project Blog

[Brad Humphrey]

The 'remember' checkbox is old functionality that is not very useful now that we have refresh tokens. You should always get a refresh token when you complete the OAuth workflow.

Refresh tokens improve security around storage of tokens. They are used along with the developer key and secret to get a new access token. Existing developer keys will continue to function as they have been. Newly created developer keys will issue tokens with a short time to live (~1 hour). In this case, if the access token is compromised it is only valid until it expires so the scope of the breach is reduced. Additionally, if the refresh token is compromised, it has no value unless the developer key and secret are also compromised.  Best practice is to rely on the refresh token for long term storage of access to a system and to regenerate access tokens for API access in the short term.

[Pritpal Riat]

Hi Brad,

Thanks for the replies.

I have used the django-all-access library to implement OAuth2 into my web app. I'm successfully getting the access and refresh token, which are both stored in encrypted in the database. Since the 'remember' checkbox is old functionality, does that mean that the user has to authorise access each time on the authorisation screen when signing in, step 2 of the OAuth2 handshake? At the moment thats what I am currently experiencing with my web application. 

Many Thanks

[Becky Kinney]

Brad,

OK, this is starting to make sense. So, the idea is to store only the refresh token, correct? I do think this is a huge improvement, although unfortunately I just finished revamping my whole token request workflow, so now I have to do it all over again. Rats.

You say that newly created keys will issues short-term tokens. I assume that includes keys we create for our own accounts?

Will the expiration date show up in the user's settings? Will the tokens delete themselves after they expire, or is it that the same token is going to be re-issued with a new key?

Becky Kinney

Academic Technology Services

Project Blog

[Brad Humphrey]

Pritpal,

Are you using OAuth to get access to the canvas API or are you using OAuth to log into your application? If you are using it to get access to the canvas API, you should save the refresh token and then use the refresh token with your developer key / secret to get a new access token for the user whenever you need to access the canvas API. If you hold onto the refresh tokens for users, you shouldn't need to send the user through the OAuth2 flow again unless they revoke their access token.

Becky,

You can store both the access token and the refresh token, but I usually just generate a new access token for each set of interactions.  However, be aware that refreshing your token will invalidate the old access token, though the refresh token should remain consistent across refreshes.

Newly created developer keys (including those created by LMS admins for an account) will issue short term tokens. I am not sure if the 1 hour expiration times show up in the user's profile, but I would assume so. The tokens that show up in the profile represent the refresh token, so it will only show up once regardless of how many times it is refreshed.  If a user revokes the token it will revoke both the current access token and the associated refresh token.

[Pritpal Riat]

Brad,

I'm using it to do both. So the django-all-access library sets up the OAuth allowing me to get and store a users token, but it also allows users to sign into my web app using there canvas credentials. My app utilises that as its method of logging in. I retrieve the token from the database to make API requests on behalf of the user. From what I've noticed, each time the user has to click the authorise button on that redirect screen, there tokens in the database are changed. So from the sounds of it, the user will always have to authorise each time they log in the way my implementation works?

Many Thanks

[Brad Humphrey]

yes, if you are using canvas for auth, the user will need to go through the oauth flow each time they auth into your app.  However, be aware that this will create a new access token on the user's account each time they use canvas to login. If you can, you may want to include the param replace_tokens=true during the POST that generates the token (https://canvas.instructure.com/doc/api/file.oauth_endpoints.html#post-login-oauth2-token), so that each time they login it replaces their existing token with the new one instead of simply adding a new access token to their account.

[Becky Kinney]

Thank you so much. I think I understand this well enough to start working on my new process. I'm not seeing expiration dates on any of the tokens I have issued using self-generated keys, so I think the answer is that the token isn't considered expired so long as its refresh token in valid. Makes sense in a way. You wouldn't want to have users deleting tokens because they thought they were expired.

Becky Kinney

Academic Technology Services

Project Blog

[Pritpal Riat]

Brad,

Thank you for all the help :)

[Becky Kinney]

So, now that I'm testing my new process, I am seeing expiration times on the newly created tokens. Which is fine, but I wanted to correct my earlier statement in case anyone else was wondering.

Becky Kinney

Academic Technology Services

Project Blog

[Becky Kinney]

When I send out a token request with a refresh token, I'm getting a null refresh token returned along with a fresh token. The old refresh token still works, so I guess that is okay, but I wasn't expecting it. Under what conditions can I expect to get a fresh refresh token?

The other odd thing I found is that when I get a new token, and then delete it from my canvas settings without clearing my session variables, the token in my session continues to work. I had expected it to fail and kick off a new request sequence. No?

The other thing I'm wondering about is what would happen if two users are hitting the same tool at the same time. If I perform a refresh token request every time the tool loads, even if the token has not expired, what happens to the first student when the second one initiates a token refresh? Will their token stop working? On a similar vein, what if someone logs into a tool and then continues to use it for over an hour? I do not currently check the validity of my tokens more than once per session. Should I be checking for failure and requesting new tokens on the fly every time I hit the API?

Becky Kinney

Academic Technology Services

Project Blog

[Nathan Mills]

Becky,

Currently the refresh_token will only be sent when exchanging your authorization_code for the access_token/refresh_token, this may change in the future though.  The best practice is anytime you get a refresh_token back you should replace your current refresh_token with the one sent back to you. Which leads into handling authorization failures when using tokens.

To be able to gracefully handle authorization failures, i.e. expired tokens, or invalid refresh_tokens, there are two layers you need to have. The first is that whenever you get a 401 when you attempt to use an access_token you should try and use your refresh_token to generate a new access_token. And the second is if you get an error when use your refresh token to generate a new access token then you will need to ask the user to grant you permission again using the full oauth2 flow.

There are some cases where you would only want to handle invalid access_tokens but not invalid refresh_tokens. That being if you are using a token for a different user than the one interacting with your tool, i.e. using a Teachers access_token to enable the tool to do more when the student is interacting with it. In that case you wouldn't be able to reauthorize the user to get a new token since the user associated with the token is not available. 

Since it sounds like your tool is using a single access_token for multiple users, I would not recommend refreshing it before every request, instead I would to only refresh it when you needed to, i.e. when it expires or you could set a rule to refresh it if it is less than X minutes prior to expiration, where x is a reasonably small value, i.e 5 minutes. Then in your code you would want the refresh to be a singleton, so you don't have multiple refreshes happening at the same time.

I would like to get some more information about the token working after you invalidate it, I tried to reproduce it on my side and wasn't able to.  Could you provide me some more detailed steps on what you are doing in that situation?

Hopefully I have addressed everything, but in case I didn't, please let me know.

Thanks

[Felipe Cocco]

Great tip on adding the replace_tokens parameter -- it doesn't actually seem to be in the documentation you linked to, but it worked perfectly!