You can protect a deep-linked ViewModel in MDriven Turnkey so that unauthenticated users are sent to login and returned to the ViewModel they originally requested, while authenticated users without permission see an access-denied view.

How protected deep links work

A deep link is a URL that opens a specific ViewModel rather than the application's start page. When a user follows a deep link to a protected ViewModel, Turnkey evaluates the ViewModel's access groups before allowing the view to open.

Configure the access group so that it evaluates to false when the current user is not allowed to open that ViewModel. Turnkey then handles the result as follows:

User state	Access-group result	Result
Not authenticated	Not allowed because the user has not signed in	Turnkey navigates to Account/Login?returnUrl= followed by the URL of the requested ViewModel.
Authenticated	Still not allowed	Turnkey shows the special AccessDenied ViewModel.
Authenticated	Allowed	Turnkey opens the requested ViewModel.

This distinction matters: login can resolve an unauthenticated state, but it must not bypass authorization rules that deny an already authenticated user.

Configure the protected ViewModel

1. Open the ViewModel that users may reach through a deep link.
2. Assign the appropriate access group or access groups.
3. Make the access-group expression return false when the current user is not authorized to view the ViewModel.
4. Test both cases:
   • Open the deep link while signed out. Verify that Turnkey opens the login route and preserves the requested destination in returnUrl.
   • Sign in as a user who does not satisfy the access group. Open the same deep link and verify that Turnkey shows AccessDenied, not the login page.

For example, an Orders ViewModel can be reachable by URL, while its access group denies users who do not have the required authorization. A signed-out user is sent to login; a signed-in user who remains unauthorized is sent to AccessDenied.

Implement the AccountLogin ViewModel

Implement the AccountLogin ViewModel when you need to control how the login page is displayed or when login must continue to an external identity provider.

1. Add a string variable to AccountLogin that receives the return URL supplied by Account/Login.
2. Use that value when navigating to the next authentication step.
3. If external authentication should start automatically, add a PeriodicAction that navigates the browser to the external-login route.

The return URL is the destination Turnkey must open after authentication completes. Keep it intact throughout the login flow.

Start an OpenID Connect login flow

The following action expression starts an OpenID Connect external-login flow and passes the requested destination onward:

selfVM.NavigateUrl(
  'Account/TryExternalLogin?provider=OpenIdConnect&returnUrl='+
  SysSingleton.oclSingleton.UrlEncode(returnUrl,false),
  false
)

selfVM.NavigateUrl navigates the browser to the supplied URL. In this example, provider=OpenIdConnect selects the external provider and returnUrl carries the original deep-link destination.

Use SysSingleton.oclSingleton.UrlEncode(returnUrl,false) when building the query string. The return URL can itself contain URL syntax; encoding it prevents that nested URL from being misinterpreted while the application stacks URLs during navigation.

When the OpenID Connect flow finishes, it uses returnUrl to navigate the user to the ViewModel originally requested.

Keep the variable name consistent

The navigation expression above refers to returnUrl. Ensure that the string variable or parameter available in AccountLogin uses that name, or change the expression consistently if your ViewModel uses another name. Do not pass an unencoded nested URL to Account/TryExternalLogin.

Choose the authentication approach

This page covers the deep-link redirect behavior. Configure the authentication mechanism separately:

• For Google, Facebook, Microsoft, and related external providers, see Documentation:External login services in MDriven Turnkey.
• For Windows-based intranet sign-in, see Documentation:SingleSignOn and HowTos:MDrivenServer with Windows authentication.
• For an identity supplied by an upstream authentication system in an HTTP header, see Documentation:HeaderBasedAuthenticationTag.
• For browser-based applications that authenticate to Turnkey REST services with JWTs, see Documentation:Connecting javascript SinglePageApplications to Turnkey (SPA).

See also

• Documentation:External login services in MDriven Turnkey
• Documentation:SingleSignOn
• Documentation:HeaderBasedAuthenticationTag
• Documentation:Log in with code
• Documentation:Integration