update scenarios vignette with links (closes #54)

vignettes/scenarios.Rmd

@@ -54,30 +54,11 @@ On the server side, the app registration should have the **"Allow public client
 It's possible, and indeed desirable, to combine this with the previous redirect URI in the one app registration. This way, you can use the same app ID to authenticate both locally and in a remote terminal.
 
 
-## Non-interactive authentication
-
-This is the scenario where you want to authenticate to Azure without a user account present, for example in a deployment pipeline.
-
-The authentication flow to use is **client_credentials**. The code to run looks like
-
-```r
-tok <- get_azure_token("resource", tenant="yourtenant", app="yourccappid", password="client_secret")
-```
-
-Here, `yourccappid` is the app ID to use for your pipeline; you should not use the same app registration for this purpose as for interactive logins. The `password` argument is the **client secret** for your app registration, and not a user password. See the crop below of the certificates & secrets pane for the app registration. 
-
-![](images/clientcred.png)
-
-Note that in Azure, the client secret is automatically generated by the server and cannot be modified. You can only see it at the time of generation, so make sure you note down its value.
-
-As an alternative to a client secret, it's possible to authenticate using a TLS certificate (public key). This is considered more secure, but is also more complicated to setup. For more information, see the AAD docs linked previously.
-
-
 ## Interactive authentication in a webapp
 
 This is the scenario where you want to authenticate as part of a webapp, such as a Shiny app.
 
-For this scenario, your app registration should have a **webapp redirect** that has the same URL as your app, eg `https://youraccount.shinyapps.io/yourapp` for an app hosted in shinyapps.io. The difference between a mobile & desktop and a webapp redirect is that you supply a **client secret** when authenticating with the latter, but not the former. It's recommended to use a webapp redirect for a Shiny app, as the client secret helps prevent third parties from hijacking your app registration.
+For this scenario, your app registration should have a **webapp redirect** that has the same URL as your app, eg `https://youraccount.shinyapps.io/yourapp` for an app hosted in shinyapps.io. The difference between a mobile & desktop and a webapp redirect is that you supply a **client secret** when authenticating with the latter, but not the former. The client secret is like a password, and helps prevent third parties from hijacking your app registration.
 
 The authentication flow to use is **authorization_code**, the same as for a local machine. The Shiny R code that is required is described in more detail in the 'Authenticating from Shiny' vignette, but essentially, the authentication is split into 2 parts: the authorization step in the UI, and then the token acquisition step on the server.
 
@@ -97,4 +78,34 @@ tok <- get_azure_token("https://resource", tenant, app, password="client_secret"
                        use_cache=FALSE, auth_code=opts$code)
 ```
 
-Note that the `password` argument holds the client secret for the app registration, _not_ a user password.
+Note that the `password` argument holds the client secret for the app registration, _not_ a user password. See the crop below of the certificates & secrets pane for the app registration. 
+
+![](images/clientcred.png)
+
+Be aware that the client secret is automatically generated by the server and cannot be modified. You can only see it at the time of generation, so make sure you note down its value.
+
+
+## Non-interactive authentication
+
+This is the scenario where you want to authenticate to Azure without a user account present, for example in a deployment pipeline.
+
+The authentication flow to use is **client_credentials**. The code to run looks like
+
+```r
+tok <- get_azure_token("resource", tenant="yourtenant", app="yourccappid", password="client_secret")
+```
+
+Here, `yourccappid` is the app ID to use for your pipeline; you should not use the same app registration for this purpose as for interactive logins. The `password` argument is the **client secret** for your app registration, and not a user password. The client secret is set in the same way as for the interactive webapp scenario, above.
+
+As an alternative to a client secret, it's possible to authenticate using a TLS certificate (public key). This is considered more secure, but is also more complicated to setup. For more information, see the AAD docs linked previously.
+
+
+## More information
+
+The following pages at the AAD documentation will be helpful if you're new to creating app registrations:
+
+- [A step-by-step guide](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) to registering an app in the Azure portal.
+
+- [How to set permissions for an app](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis). For interactive authentication (authenticating as a user), you want _delegated_ permissions. For non-interactive authentication (authenticating as the application), you want _application_ permissions.
+
+- [Restricting your app to a set of users](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-restrict-your-app-to-a-set-of-users)---if you don't want your app to be accessible to every user in your organisation. Only applies to webapps, not native (desktop & mobile) apps.