Enhancements for applications opened via modal + oauth flows

[thomasyopes]

Hey guys,

I'm setting up a new application and have some ideas that would make integrating a third party client easier:

Application open via modal:

1. After opening a client application in a modal, if the client goes to the /auth/authorize/ page of an authorization-code oauth app, the current session of the parent Canvas app isn't being used to bypass the login page for the oauth app. In other words, the user is asked to login in again despite already being logged in in the parent frame. It would be nice if somehow the modal could have access to the current parent session to bypass this.
2. It would be great if there was someway to bypass the Authorize.... Application permissions screen when an oauth app is opened in the modal if the parent app Canvas user agrees the first time (until their session clears or something like this).

Oauth authorization-code flow:

1. Once a code is exchanged for an authentication token, it would be great if the JWT payload returned had some context info related to the token. In particular, it would be helpful to know the Canvas organization ID and URL via an id_token or something.
2. It would be great if any extra query params passed into /auth/authorize/ were passed back to the redirect URL. This allows us to pass some helpful info known at the start of the launch sequence (like the current Canvas patient ID being viewed when opening the application).

Let me know if you need clarification, and I'm happy to discuss. Thanks!

[beaugunderson]

These are great suggestions--we've been looking at some other passthrough properties for the frame content; can definitely see why some apps would want to pass through the parent frame cookies as well. Will need to look at that from a security POV too.

Can you say more about this one?

It would be great if there was someway to bypass the Authorize.... Application permissions screen when an oauth app is opened in the modal if the parent app Canvas user agrees the first time (until their session clears or something like this).

[thomasyopes]

Anytime the oauth flow is run for an authorization-code oauth app, the user is asked to explicitly agree to the permissions the oauth app is requesting based on the submitted scopes. This makes sense, but in the same way that it's non-ideal having an "already logged-in" user log in again each modal open, forcing the permissions to be approved each time is also non-ideal.

I was thinking maybe there's a way to have the oauth app within the modal be able to set a cookie that can be read by the modal next time it's opened and the oauth flow is run again. The idea being this cookie allows the oauth app to skip the permissions step assuming the submitted scopes are equal to or a subset of the initially submitted scopes (note: this is where it gets tricky).

A "cleaner" option in my mind would be to allow a defined set of scopes in the oauth app settings and then check the submitted scope against these -- if it's an allowed scope, the user is not asked to authorize the permissions. In other words, the oauth app owner says "yes" to a defined set of scopes up front, and individual users are not asked to authorize.

All other options I can think of get pretty hacky -- things like having a user model field that's "modal_cookies" that can be updated machine to machine, but then can be accessed on next application open via the user model to create a giant pass through, etc.