Notifications
Clear all
Topic starter
16/08/2026 1:12 pm
TL;DR: A Shiny tutorial shows how to add authentication, SSO, user metadata, and logout handling to R-based apps using magic links, OIDC, and SAML, according to Descope. The real lesson is that app publishing is easy, but identity controls decide who can see data and how cleanly sessions end.
NHIMG editorial — based on content published by Descope: Add Authentication and SSO to Your Shiny App
Questions worth separating out
Q: How should teams secure Shiny apps that expose internal data?
A: Treat them like any other internal application with sensitive content.
Q: Why do SSO and federation matter for low-code analytics apps?
A: They remove local password handling from the application and move trust to the identity provider, which is usually what IAM teams want.
Q: What should IAM teams check before approving a custom OAuth integration?
A: Check that the provider settings are correct, the token exchange is limited to the intended scopes, the userinfo mapping is stable, and session termination is enforced.
Practitioner guidance
- Fence the app behind federated authentication Require SSO before any dashboard content is rendered, and ensure unauthenticated users only see the login boundary.
- Validate claim handling and tenant scoping Check that the app only accepts identity assertions from the intended tenant, and that name, email, and role attributes are mapped consistently before the user reaches data views.
- Test logout as a control, not a button Confirm that logout ends the active session, removes access to protected content, and returns the user to the authentication flow rather than leaving cached state behind.
What's in the full article
Descope's full tutorial covers the implementation detail this post intentionally leaves for the source:
- Step-by-step Shiny and JavaScript code for mounting the authentication widget and wiring success and error callbacks.
- OIDC and SAML tenant configuration details, including issuer, client secret, scopes, and redirect settings.
- Logout handling logic that resets the widget and reinitialises the login flow after session termination.
- The complete sample application structure for moving from unauthenticated dashboard access to controlled user sessions.
👉 Read Descope's tutorial on authentication and SSO for Shiny apps →
Shiny app SSO and user access control: what IAM teams need to know?
Explore further
16/08/2026 1:14 pm
Authentication controls for Shiny apps are a human IAM problem, not a developer convenience. The article shows how quickly a data app becomes an access-controlled system once it exposes business content. That means the security bar is not whether the app runs, but whether identity, federation, and session boundaries are enforced with the same discipline as any other enterprise application. The practitioner conclusion is straightforward: if the app shows sensitive data, identity governance has already entered the design.
Shiny-style application security is becoming an identity inventory problem as much as an application security problem. Once teams add SSO, user context, and logout handling, they need a governance view that includes ownership, federation, and access review. The practical signal is to bring these apps into the same control plane as other enterprise apps instead of treating them as disposable analytics tools.
A question worth separating out:
Q: How do you know if logout is working properly in a web app?
A: You know logout is working when the user cannot reuse the prior session token, refresh token behavior stops extending access, and protected endpoints return unauthorised responses after sign-out. A visible redirect is not enough on its own.
👉 Read our full editorial: Shiny app authentication and SSO patterns for enterprise access control
