Mobile Session Expiration

[jozsefdavid]

Update!!!

(12/02/2023) The feature got postponed for various reasons, but it is still on the roadmap and we are reviewing it on a quarterly basis. I will update this blog post once we put it in  motion again.

Introduction to the problem

When you open the Canvas mobile apps, they keep you logged in, even if you put the app to the background or close it completely. This behavior adds convenience for the users and is typically what we expect from a mobile application in 2022. But many times convenience comes with sacrifice. In discussions with various institutions, we've discovered that keeping users logged in can be cause for concern in certain situations such as:

• The device is shared in a classroom
• The device is stolen or lost
• The device is lent to somebody else
• Canvas being compliant with the institutions’ security policies

Solution

The ideal solution finds the balance between user experience and security. What seems perfect for one might be a problem for another. It looks like there is no “one size fits all”. 

Instead of detailing the discovery and design process that we’ve undertaken, I will mention some key results. During interviews with some Canvas institutions, we considered pin code authentication, biometric authentication, and several different versions of the token based authentication. I won't detail the pros and cons of each solution; I will just describe the solution—we think—might be acceptable for the use cases we are aware of.

Most importantly, we will stick to token-based authentication. This is how the applications work today, but we will add new configuration options at the institution/account level. Your customer success manager will help you to configure those settings. 

If desired, you will now be able to limit the duration of the mobile session based on two new settings:

• Setting 1: Absolute expiration time (hours since login)
• The value must be provided in Hours
• The minimum time period is 48h
• Setting 2: Sliding expiration time (hours since last activity)
• The value must be provided in Hours
• The minimum time period is 4h

If configured, you must choose values for BOTH settings; you cannot have only Setting 2 or Setting 1.

About Setting 1: The Absolute expiration time (hours since login)

This setting ensures the user has a persistent mobile session, regardless of their activity, until the timer expires. Once the timer expires, Canvas switches to using the activity based timer to determine session persistence.

How can the Setting 1 timer expire?

• After I log in to the application and the time configured for Setting 1 has passed
• I am logged out from the application

What happens if the Setting 1 timer expires?

We have 2 possibilities here:

1. I am actively using one of the Canvas Mobile apps when the timer expires
• In this case I will not be logged out because the Setting 2 timer has not yet expired. I can continue using the app until the Setting 2 timer expires (which is not happening since I am actively using the app—see later)
2. I have already closed the application or just put it into the background, so I am not using it actively
   • if the timer has expired, it will ask me to log in (select school and provide credentials)
   • If the timer has not expired, it will let me open the application without logging in and will continue allowing access until I become inactive for the Setting 2 duration
• Next time I open the application, the app will check the Setting 2 timer status and 

Some more information about this setting:

• The Setting 1 timer is running even if I am not actively using the application.
• If the Setting 1 timer is active, I will remain logged in, regardless of activity.
• This timer is neither reset nor stopped after the login action. 

About Setting 2: The Sliding expiration time (hours since last activity)

The sliding expiration time prevents a user from being logged out if they are still active in the application and is always counted from the last activity. Imagine a timer set to 4 hours and then continuously reset when I do any interaction with apps. This timer will only expire if I don’t do anything in the apps for 4 hours. Actions that reset the timer include opening a screen, loading an assignment or submission, reading an inbox message, writing/reading announcements, checking grades. These behaviors are why we often refer to these activities as “time since last activity”. 

How can the Setting 2 timer expire?

• After Setting 1 (time since login) has expired, I am idle and the time configured for Setting 2 has passed
•  After Setting 1 (time since login) has expired and I put the app aside or closed it and the time configured for Setting 2 has passed

What happens if the Setting 2 timer expires?

We have 2 possibilities here:

1. Setting 1 timer is not yet expired → the user remains logged in regardless of setting 2
• In this case I will not be logged out because the app will detect that Setting 1 timer is not expired and it will just reset the Setting 2 timer. I will not even notice that the Setting 2 timer expired. I can continue using the app until the Setting 2 timer expires (which is not happening until I am actively using the app).
2. Setting 1 timer has also expired → the user is logged out
• This can happen only if I am idle;  I did not interact with the application recently. In this case since I am not using the app, I will not notice anything.
• Next time when I start the application (or bring the app into the foreground) it will ask me to log in (select school and provide credentials).

Some more information about this setting:

• The Setting 2 timer is running even if I am not actively using the application.
• If the Setting 2 timer is active, I will remain logged in.

What happens if I am logged out because of these settings?

Don’t worry, no catastrophe, but you will need to log in again, which means selecting the school and providing your user credentials. 

The added value 

These additional settings are how we can ensure that nobody will be logged out while they are actively working in the Canvas Mobile applications while security is still considered. By coordinating with their Instructure Customer Success Manager, the admins will be able to configure the system according to the security policies. As an end user, you would notice one change: from time to time you will be asked to log in to the app again. The frequency of these logins will be managed by the settings set by the institution.

Special thanks to Jesse Poulos (Product Manager of another Canvas team) for helping me put this post together. His team will do the majority of the work. This project is a work in progress and we will definitely let you know when the feature gets released.

[rake_9]

In the name of balancing security with ease-of-use, it would be really nice if the app could remember your institution each time your session ends, so you don't have to type that in.  Just click to confirm (like clicking a bookmark on your browser) and off you go to the authentication process.

[jozsefdavid]

@rake_9 This is a great point. Introducing these settings will require more frequent login actions from the users, so the login must be as smooth as possible. We are working on the topic. Thank you for the suggestion!

[meichin]

Thanks so much for the information on this and for working to provide this security feature.

I am confused by some of the bullets under What happens if the setting 1 Timer expires?

What do these mean in relation to what happens to the user?

• I am actively using one of the Canvas Mobile apps when the timer expires
• I have already closed the application or just put it into the background, so I am not using it actively

I think what may be causing the confusion for me is that under, "We have two possibilities here" there are 4 bullets.  I understand the first two but am unsure what happens to the user with these other 2.  Thanks for any clarification you can give!

[meichin]

After looking at again, I am going to attempt to answer my own post above.  I think there are some formatting issues that need correcting. Should it be this?

What happens if the Setting 1 timer expires?

We have 2 possibilities here:

1. I am actively using one of the Canvas Mobile apps when the timer expires

• In this case, I will not be logged out because the Setting 2 timer has not yet expired. I can continue using the app until the Setting 2 timer expires (which is not happening since I am actively using the app—see later)

2. I have already closed the application or just put it into the background, so I am not using it actively

• Next time I open the application, the app will check the Setting 2 timer status and if the timer has expired, it will ask me to log in (select school and provide credentials)
• If the timer has not expired, it will let me open the application without logging in and will continue allowing access until I become inactive for the Setting 2 duration

[meichin]

And does this fix the formatting issues for the Setting 2 expiration explanation?

What happens if the Setting 2 timer expires?

We have 2 possibilities here:

1. Setting 1 timer is not yet expired → the user remains logged in regardless of setting 2

• In this case, I will not be logged out because the app will detect that Setting 1 timer is not expired and it will just reset the Setting 2 timer. I will not even notice that the Setting 2 timer expired. I can continue using the app until the Setting 2 timer expires (which is not happening until I am actively using the app).

2. Setting 1 timer has also expired → the user is logged out

• This can happen only if I am idle;  I did not interact with the application recently. In this case, since I am not using the app, I will not notice anything.
• Next time when I start the application (or bring the app into the foreground) it will ask me to log in (select school and provide credentials).

[ewest]

Is there any documentation out there on how admins would go about enabling these settings, if we wanted to?

Thanks!

Evan

[jozsefdavid]

Hi @ewest. Once the feature gets released we'll have documentation, but it is still under development.
 

[DL1919___]

We were looking for something like this for a while. Can I just confirm where you are with this in terms of usage and testing. When will you be testing it and when can we expect this to be something we can use? If we ask our CSM to support this, will this be something we need to test, how can we ensure it works on our end before we release the changes? 

[rake_9]

Any news on this feature? Is this something we can request from our CSM? @jozsefdavid suggested in February there might be documentation or other information available soon.

[jozsefdavid]

Hi @rake_9 . The necessary changes are not yet implemented on the server side yet. That is a different team not mine, so I can't promise anything in their name, but maybe my colleague will update you here. I'll ping him now.

[jpruden]

Great to see this... two additional features that would be fantastic would be "kick this user now" and "kick all users now" from the back end...

The use case for this (that's not listed above) is that many colleges (and we K-12 institutions) use external authentication methods (in our case, LDAPS via AD). When we have a kid that withdraws from the school, we disable their account in Active Directory. Regrettably, that student still has access to their Canvas courses via the App. We currently have to contact Support to force expire all tokens to kick them from the app.

Typically, we would use this option at password change time when we *really* want students to update their passwords... we can communicate a time for this to happen and not worry about students that may be doing something because they've been warned. 

thanks,

Jamie

[meichin]

Thank you for posting - we would really love these features as well!

[jpruden]

@jozsefdavid Do we have any updates on the implementation of this "feature"?

[AHauerwas]

@jozsefdavid I would really be interested in this as well.  It's been a year since the intial posting -- do we know when this feature might be released?

My primary concern is shared iPads in classrooms.  In addition to whatever timeouts we could set with the Canvas platform, it would be useful if there were a configuration profile for the iPads to allow institutions with MDM solutions (e.g. jamf) to control the behavior of the Canvas Student and Teacher apps re: signin duration.

Thanks!

[jozsefdavid]

Hi @AHauerwas. 

Thank you for the comment and followup. The feature got postponed for various reasons, but it is not forgotten, we are aligning it on a quarterly basis. On the other hand this feature would not solve the shared iPad problem, because the minimal length of the token will be much longer than the length of a class. I will bring up this use case at our next alignment meeting as a concern. Sorry for not being more concrete here. The priority of this feature is not fixed and therefore I cannot give you a time estimate at the moment.

[AHauerwas]

@jozsefdavid, thanks for the quick response!  I understand how development priorities can change, and appreciate that Instructure is still working on this.

As I mentioned in my comment, it is the shared iPad situation that is our primary concern -- and in fact, it was your own first bullet point in your post from February, 2022!  If there were a way to modify the actual devices that make use of the app (e.g. through a configuration profile), that would be ideal -- because then the institution could control the behavior of the app on the devices that they themselves own.

Just $0.02 for Development.  And thanks again!

[jpruden]

@AHauerwas Great point... I'd love to be able to push a config like that via Mosyle for our loaner iPads.

Regrettably, Instructure isn't interested in this "super not very sexy" fix for a security hole that has existed for WAY too long... I've been asking for something like this for over 7 years and *oops* it got put off again

[Susan27]

We look forward to the delivery of this feature. At our institution, we would like to be able to set session times separately for the Teacher and Student apps. Is this something that is being worked on as well?

[jacobse]

Hi,

I was checking on the status of a solution for auto-expiration of mobile access sessions and if there is a tentative release schedule for this feature?

Thanks,
Ed

@jozsefdavid 

[pscanlan]

I would like to add that it is great to see that this feature is coming soon. Just to add to the list of reasons why this feature (or a default token expiration of 90, 180, etc. days) is needed. When SIS rollover occurs every summer, we don't want students to see their upcoming scheduled info (Future enrollments) before it is finalized and we are close to the start of the school year. Students that are already signed into the mobile app are able to see this info, and it creates a lot of noise between the student and their school. We disable access to Canvas via our SSO authentication, but students that were already signed into the mobile app can continue to see this information.

Looking forward to when this feature is available in the product. Thank you.

[jpruden]

@pscanlan Excellent point... we have the same issue (although ours is a bit muddled by summer "stuff" that some classes are required to complete... so we can't kill SSO access altogether)... the noise is a HUGE issue for a private school like ours.

Now... on that whole "coming soon" issue... @jozsefdavid Do we have any updates?

[Charles_Barbour]

When this feature finally ships, I'd like to suggest someone create a flowchart to document the logout logic. Far easier to understand than bullet points.

[dbrace]

I am also looking forward to this.

I am guessing that it is not something that we should except for the beginning of the 2023-2024 academic year.

Would something like this be released in the middle of the academic year?  Released in January?

Does this exist somewhere (honestly I have only quickly looked) on the https://community.canvaslms.com/t5/Instructure-Roadmap/ct-p/instructure-roadmap?

[jpruden]

Hi @dbrace and welcome to the nightmare...

I've been waiting almost 8 years for this specific functionality... or some way to do the same thing from the Admin side (really, I'd be 100% completely satisfied with a button on the Authentication page that expired all tokens, but I digress)... If I was you, I don't think I'd be holding my breath for a quick resolution. Closest thing for now is to contact support and specifically request that they expire all mobile tokens on a certain date... Instructure will pick a time and will knock it out for you.

Note that there hasn't been any comment from the Canvas side since December... presumably there have been at least two (possibly 3) "quarterly reviews" on this request and *still* no love for us.

As with all things Canvasy, YMMV.

smiles,

Jamie

[dbrace]

@jpruden / Jamie,

I asked the question(s) to continue the conversation and show that future feature notices from a vendor and customer requests should not be ignored.

We have been a customer since February 2018, of which the first few months was our own admin training, followed by training and use by a first group of pilots in Fall 2018, an expanded group in Spring 2019, full adoption in Summer 2019, and a complete roll-out in Fall 2019.  Our timing was lucky considering everything that happened in mid-Spring 2020.

I get it.  The Canvas LMS is a huge platform.  A lot of organizations use it.  Each with its own needs and all of them have their own reasons for why they do what they do.

Thank you for the tip for what we can do.  It is something that I will bring up internally and then take the appropriate steps.

I hope that you have a great academic year!

Doug

[hmcneill]

We'd also appreciate an update on this development. Is it still being progressed and on the roadmap? When was it last reviewed and is there any more information available @jozsefdavid?

[dbrace]

I see that an update was mentioned in the main post but I did not receive a notification when the post was updated and normally I do.

I am really hoping that this does not continue to get tabled.

+++++

@jozsefdavid, can you please post updates in the comments when this is reviewed on a quarterly basis?

[jozsefdavid]

Hi @dbrace, @hmcneill ,

Thank you for the follow up. The feature improvement and the requests are not forgotten. It is a cross-team issue and requires extensive collaboration. Unfortunately, we couldn't align with the right timing yet, but we are working on continuously. Thank you for your patience. We now how pressing the issue is.  

[jpruden]

Hi @jozsefdavid ,

What is it going to take to change the alignment? This security hole has existed as long as there's been an iPad app... I'm certainly not the "finder of the issue" on this one, but it's been long overdue for  a solution.

Unlike @dbrace and @hmcneill , I've been waiting for over 8 years for this... Seriously... how tough is it to engineer a button to expire all tokens and put it in the admin interface?

Literally, this should not affect ANYTHING except for the expiration of tokens. How does that become a "cross-team" issue?

sigh.

Jamie