Can Desire2Learn APIs be used from inside a D2L widget? Will the user get prompted for credentials?
Yes the APIs work from widget. No the user won't be prompted for credentials.
Widgets are blocks of HTML code that can be embedded in different areas of the Desire2Learn UI (org home page and course home page). Widgets are one of two main ways of extending the UI of Desire2Learn (along with "External Learning Tools" which are LTI links typically added to courses). They are achieved by configuring a small block of html. For most developers of nontrivial widgets this will end up just being an iframe connecting to the web application (and in a blended solution sometimes the widget iframe will connect to the web application as an LTI link) .
Widgets will typically want to display their application content specific to the user that is viewing the page. Widgets can identify the user by immediately attempting API auth back to the calling server. Because the widget is being called from with in a session, this process will not prompt the user for credentials. At this point the application has the valence userid and key needed to perform API calls (such as "whoami") that will let the application identify the user and make other calls (for example showing grades or other information retrieved from the LMS) or to just correlate the user to data specific to the widget.
Related
I have native iOS app and one of the flows of the app should be done with WebView. From native part of the app, user can navigate to WebView part. And, somehow, web page should identify user. I have authorization token stored in the app and of course I can pass that token in the headers of the WKWebView. And other stuff will be handle in the web (routing and etc). But is it a good and secure way of doing this? How can I easily integrate WebView in the app caring about token?
There are a few options here:
Using headers seems problematic according to this thread but hopefully you can get it to work. It feels like this will have reliability problems if the token ever expires in the web view, so you'll need to manage that.
Simple option: open a system browser - either Safari or a Safari View Controller. The user may have to sign in again though, which your stakeholders may not like.
More complex option: use the Javascript API to pass the token from the mobile UI to the web UI. This will give you full control, and the web app can call back the mobile app to refresh its token. It can be the best usability option if used sparingly. It requires tricky foundational work in both the web and mobile UIs though.
SECURITY
Passing the token from the Mobile UI to the Web UI is natural if both are part of the same logical application and access the same level of data. In this case option 1 or 3 would work.
If the apps have very different security levels (eg the web app is now getting a much higher privilege token than it usually gets), then I would not pass the token and would use option 2 instead.
FURTHER DETAILS
I wrote a quite detailed blog post on considerations a while back, and there is also a code sample you can run:
Blog Post
Mobile Bridge Code in Web UI
Javascript Bridge Code in Mobile UI
I'm not sure there is a "proper" way, but before I just bodge together my own incompatible implementation, perhaps there's something in all the standards that can fit my need?
Here's the situation: Apple has declared that apps on their phones MUST include all standard functionality inside themselves. No more iframes with web content! If you need to show stuff from web, open the system browser (Safari)! Unfortunately we need to display stuff from web, so here we go...
Now, the app requires authentication which the user has done previously. We store whatever tokens we need. When the time comes to open the browser, we don't want to force the user to re-authenticate. We need to somehow pass the access credentials to the browser, and preferably do this securely. Furthermore, the webpage in the browser will need a token obtained from our OpenID Connect server.
Unfortunately, the only point of communication between the app and the browser is the URL, so everything that we give will be there, in plain sight. I know that OAuth was pretty worried about this, so much so that they made it impossible to intercept authentication with just the stuff visible on the screen and instead using things like single-use intermediary codes, backchannels and PKCE.
Unfortunately I cannot see any way to use the default flows "out of the box" to achieve what I need. I can think of modifications to those flows that would do it, but I'm not a security expert so I'd rather go with something standard which is vetted by experts.
SCENARIO
It's a good question since many companies want to show existing web content in a secured manner within a mobile app, and to avoid an extra login.
WEB + MOBILE INTEGRATED SOLUTION VIA DISCONNECTED BROWSER?
Ideally what you want to do is pass the mobile app's JWT to the external web content in an HTTP header. iOS APIs such as openURL may not support this however.
You may have to pass a JWT in a query string, in which case I would try to follow a signed request model, though it is not trivial. I have used SalesForce signed requests though not implemented a full solution myself.
Mobile app calls an API method at POST /api/encrypt-token
API returns an encrypted payload that includes the JWT
Mobile app opens a web page at https://mywebapp?token=0a78904cwdu
Web UI calls POST /api/decrypt-token to get the JWT
Web UI stores the token in memory and uses it to call the API
You will want to prevent raw tokens being written to web server logs.
I believe the recommendation for this type pf solution is to use a one time key, as described in the above link. And of course the web session will have some limitations such as silent token renewal not working.
WEB + MOBILE INTEGRATED SOLUTION VIA WKWEBVIEW
In the past I've managed secured web content in a mobile app by making the Web UI get access tokens from the mobile app. This enables an integrated UX and you can use a 'standard as possible' OAuth solution.
When the Web UI runs within a mobile app's web views it no longer does its own OAuth handling and instead calls the mobile app to get tokens and trigger logins
This means there is a single login across web and mobile views, and the Web View gets all the benefits of mobile user experience, such as secure storage of tokens
The Web UI is no longer impacted by things like the web view aggressively dropping cookies
VALID USE OF WEB VIEWS?
Web views are probably not a good long term solution in most cases. I know that Apple are likely to reject apps in 2020 if they use any of these behaviours:
Use of UIWebView - the Cordova default - you need to update to WKWebView
Delivering an app that is solely a repackaged web site with no mobile views
Displaying web content of a dubious nature (ads etc)
I suspect that use of WKWebView used responsibly and justifiably would be accepted. I could be wrong though, so please don't take my word for it.
ONLINE SAMPLES
I will be documenting some stuff about mobile / web integration on my OAuth blog, including code samples.
I want to Integrate My .Net Web Application to Quickbooks Online. I can do this by using the QuickBook Widgets(Connect to QuickBook button). This will load popup window for authorization. But I want to do this without popup windows and only through a direct service call.
Is there a way to do this by using a direct service call and without loading intuit Authentication and Authorization popup windows.
The very first time the user connects you MUST authenticate to IPP/Intuit Data Services via the pop-up/widgets.
Once you do that, you'll have a long-lived (6+ months, with an option to renew them) set of OAuth tokens which you can store and use from that point forward. Once you have those tokens, you no longer need to show the "Connect to QuickBooks" button (and thus the pop-up window).
You do still need to show the other widgets (the blue dot menu).
I can use the SSO to D2L to go to the Home page or to the course home page if i supply the orgid as a query param. How can I go to other areas like course content, LO or user progress, gradebook using the SSO.
It depends upon the vintage of the LMS you're using; some pages hosted by the LMS support the deep-linking required to directly visit the page, and some do not. There is an effort by D2L to move more and more pages to the new framework that supports deep-linking, so each release should have more pages eligible for this behaviour. If you have pages in particular you'd like to see support this behaviour, you can provide this feedback through your account manager: D2L prioritizes work in consideration of customer demand, so letting them now might help.
I have a hybrid native/HTML iOS app that utilizes Facebook. Within the app I've authenticated the user via single sign on API and I have a valid auth token. Within a web view in the, I embed a web component that also utilizes FB (in my case, a Like box and button for our app page). If I click on the Like button I am forced to authenticate yet again in the context of the browser. Is there a way for me to utilize the token obtained by the container app within this web view so that a second authentication can be avoided?