OpenID Connect Authentication

OpenID Connect (OIDC) offers organizations a modern, secure way to authenticate users while streamlining access to GO-Global-hosted Windows applications. By integrating with identity providers such as Okta, Azure AD, or ADFS, administrators can centralize authentication and improve the user sign-in experience—whether users are signing in with local Windows accounts, domain accounts, or both. This guide explains how to enable OIDC authentication in GO-Global, configure automatic Windows sign-ins, match identity provider accounts to Active Directory users, and manage additional settings required for seamless access. It also covers advanced options such as customizing username fields, handling local account creation, configuring permissions, and retrieving OIDC tokens programmatically.

After a user has authenticated via OIDC, GO-Global gives administrators several options for authenticating the user automatically on Windows. For example, if the identity provider is integrated with the organization’s Active Directory, GO-Global can automatically sign the user in to the user’s domain account. Alternatively, if Active Directory integration is not required or desired, GO-Global can create a local Windows account for the user and automatically sign the user in to that account. Single sign on support is an add-on option. OpenID Connect authentication will be grayed out (disabled) unless the feature has been purchased.

‍To enable OpenID Connect Authentication

Click Tools | Host Options.
Click the Authentication tab.
Enable OpenID Connect authentication.
Select one or neither of the following options:
- Automatically sign users in to local Windows accounts. When this is enabled, GO-Global will automatically create a local user account for users that don't have a domain account.
- Automatically sign users in to their domain accounts. When this is enabled, GO-Global attempts to perform an S4U login using the user's UPN, which it obtains from the OIDC identity provider after a successful OpenID Connect login. By itself, an S4U login will enable users to access resources on the GO-Global Host, but users will not be able to authenticate to services running on the network. To access services running on the network, administrators must either enable constrained delegation (as described in the Configuration Requirements for Delegation Support article) or enable the Cache passwords on the host option.
  - If an application that is hosted by GO-Global can run under a local account on the GO-Global Host, Automatically sign users in to local Windows accounts should be selected. Alternatively, if the application requires access to resources that are managed by Active Directory, Automatically sign users in to their domain accounts must be selected. In this latter case, the identity provider must be integrated with the Active Directory so it can provide GO-Global with the UPN of the user.
  - If neither Automatically sign users in to local Windows accounts nor Automatically sign users in to their domain accounts is selected, users will be prompted to sign in to Windows as specified by the other options on the Authentication tab. For example, if both OpenID Connect authentication and Standard Authentication are enabled, users will be prompted to sign in twice. First, they will be prompted to sign in to the OpenID Connect identity provider. Then after successfully authenticating with the OpenID Connect identity provider, they will be prompted to enter the username and password of a Windows account.
Type the Client ID string from your OpenID Connect server configuration in the Client ID box.
Type the Client Secret string from your OpenID Connect server configuration in the Client Secret box.
Type the authorize URL used to authenticate users with your OpenID Connect server in the Authorize URL box.
Type the token URL used to authenticate users with your OpenID Connect server in the Token URL box.
In the Redirect URL box, type the URL that the identity provider must use to redirect users back to the GO-Global Host after they have successfully authenticated. This should be the same base URL that users use to access the GO-Global Host with callback.html appended to the end. For example, if you are using a separate web server like IIS and TLS is not enabled, the callback URL would be http://hostname/goglobal/callback.html. Alternatively, if you are using GO-Global’s integrated web server and TLS is not enabled and GO-Global is configured to accept connections on its default port, 491, the callback URL would be http://hostname:491/callback.html.
Click OK.

Matching Active Directory Users to Identity Provider Accounts

GO-Global provides several options for deriving a user’s UPN from claims in an OIDC ID token. User accounts must match in one of three ways on the Active Directory (AD) and identity provider.

There are three ways this can be achieved:

The user's native User Principal Name (UPN) already matches the identity provider username. For example, the local AD domain is example.com and the identity provider domain is also example.com. By default, GO-Global searches for a valid UPN in the email, UPN, sub and userid fields of the ID token, in that order. Alternatively, administrators can specify the claim that contains the UPN via the OpenIDConnectUserNameField property in HostProperties.xml.
Add a UPN suffix and use that for AD usernames so the AD UPN and identity provider's UPN's match. For example, the local AD domain is company.local but add a UPN suffix for users called example.com. The identity provider domain is also example.com.
Set the user's AD mail attribute to match that of the identity provider's UPN and modify a setting in HostProperties.xml. In some deployments, there is no claim in the ID token that matches the user’s AD UPN. For example, in a hosting environment where the customer’s identity provider is used, the customer’s domain (e.g., customercompany.com) will not match the AD domain of the hosting environment (e.g., hostedapp.com). As the customer’s identity provider is used, administrators of the hosting environment, will not be able to add a claim to users' OIDC ID tokens that specifies the AD UPN.

In situations such as this, administrators can configure GO-Global to look up the user’s AD UPN via the user’s email address. This is achieved by setting the value of the OpenIDConnectUserLookupByEmail property in HostProperties.xml to true on all applicable hosts. When this property is set to true, GO-Global searches the Active Directory for a user account with an email attribute that matches the OIDC ID token’s email claim.

Storing User names in Alternate Fields

By default, GO-Global obtains the Windows user name from the User Principal Name or email address specified by the identity provider in the user's OpenID Connect ID token. If, however, the identity provider is configured to store the user's Windows username in an alternate field, administrators can configure GO-Global to use the alternate field by entering the name of the field in the OpenIDConnectUserNameField property in the HostProperties.xml file.

To set the OpenIDConnectUserNameField property

Stop the Application Publishing Service.
Open %PROGRAMDATA%\GraphOn\GO-Global\HostProperties.xml in a text editor.
Find the OpenIDConnectUserNameField property and change the value to the name of the claim in the user's OpenID Connect token which contains the User Principal Name that GO-Global should use to authenticate the user on Windows.
Save the HostProperties.xml file.
Restart the Application Publishing Service.

When Automatically sign users in to local Windows accounts is enabled, local user account names are synthesized from the User Principal Name or email address obtained from the OpenID Connect authentication. Because local accounts cannot contain '@' or '.' these are replaced with '_' and '-' respectively. As an example, the email address sales@graphon.com would be synthesized to sales_graphon-com.

Note: Windows has a 20-character limit on local account names. If the synthesized account name is longer than 20 characters, GO-Global truncates the name to 20 characters

Passwords for these accounts are made up of characters randomly selected from the lower-case alphabet, the upper-case alphabet, numbers, and the !@#$%& special characters. The length of the password that GO-Global generates will equal the minimum length password specified for users on the computer unless the minimum length is less than 7. In that case, GO-Global will generate a password that is 14 characters longer than the minimum length requirement. For example, if the computer's minimum password length is 6, GO-Global will generate a password that is 20 characters long, in the following format: 8tw@m4b9Dek#vR76@t6%. If GO-Global is unable to obtain the computer's minimum password length, it will generate a password that is 14 characters in length.

If the minimum length requirement is set via Group Policy, enable Group Policy in the Session Startup tab of the Host Options dialog. These passwords are not saved or reused. The password is changed with every OpenID Connect authentication.

Permissions for Windows applications hosted in GO-Global sessions are not managed by identity providers like Okta or ADFS. They are managed in Windows or Active Directory.

Integrating with Active Directory is a function of the identity provider. Active Directory Federated Services (ADFS) is automatically integrated with Active Directory. Other identity providers provide their own integrations. Organizations that are using an identity provider will have already configured this. Organizations that are just setting this up will need to consult their identity provider’s documentation on how to set this up.

For more information about Okta, visit: https://help.okta.com/en/prod/Content/Topics/Directory/ad-agent-main.htm.

When using Azure, be sure to use the OAuth 2.0 authorization endpoint (v1) and the OAuth 2.0 token endpoint (v1) URLs. The v2 endpoint URLs will not work.

When using ADFS, select Server application when creating the OIDC application.

Granting Launch and Activate COM Rights to Standard Users

By default, Windows does not grant standard users who have not signed in to Windows interactively by entering a username and password the right to launch and activate COM objects. As a result, applications such as Windows File Explorer that rely on COM interfaces may only run or work properly for users who are members of the Administrators group when OpenID Connect authentication is used. Therefore, when OIDC authentication is enabled, grant standard users Launch and Activation COM rights as follows:

Run dcomcnfg.
Navigate to Component Services | Computers | My Computer.
Right-click My Computer and click Properties.
Select the COM Security tab.
Under Launch and Activation Permissions, click the Edit Default... button.
Click the Add button. (Note: The default permissions grant full rights to the INTERACTIVE and Administrators groups. This is why this works for all users authenticated via a username and password (INTERACTIVE users) and members of the Administrators group when OIDC is used.
Add the Domain Users Group.
Click the Allow checkboxes next to Local Launch and Local Activation.
Click OK.
Click OK.

Programmatically Retrieving the OIDC ID Token and Access Token

Sometimes it is helpful for applications running in a GO-Global session to be able to retrieve the claims within the OIDC ID token and/or access token that are provided by the identity provider when the user is authenticated. When this is required, application developers can add code to their applications to retrieve these tokens.

Programmatically retrieving the OIDC ID token and access token requires code to:

get a HANDLE to redirector.dll with a call to GetModuleHandle()
get the procedure address to two exported functions with calls to GetProcAddress() for “GetOpenIDConnectIDToken” and “GetOpenIDConnectAccessToken”
call those two procedure addresses with parameters of 0 and NULL to get the length of the char buffer needed
allocate the char buffer
call those two functions again to get the actual tokens

Example Code:

/**
* File: GetOidcIdAndAccessTokens.cpp
*
* Copyright 2025 by GraphOn Corporation
* All rights reserved.
*
* This software is the confidential and proprietary information
* of GraphOn Corporation  ("Confidential Information").  You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with GraphOn.
*/

#include <Windows.h>
#include <stdio.h>

int main()
{
    printf ("GetOidcIdAndAccessTokens\n");

    HMODULE hRedirector = ::GetModuleHandleA ("redirector.dll");
    if (hRedirector)
    {
        typedef unsigned int (WINAPI* fnGetOpenIDConnectToken)(unsigned int, char*);

        fnGetOpenIDConnectToken pfnGetOpenIDConnectIDToken = (fnGetOpenIDConnectToken)::GetProcAddress (hRedirector, "GetOpenIDConnectIDToken");
        if (pfnGetOpenIDConnectIDToken)
        {
            unsigned int length = pfnGetOpenIDConnectIDToken (0, NULL);
            if (length)
            {
                printf ("GetOpenIDConnectIDToken(1) returned OIDC ID token length %d.\n", length);

                char* oidcCustomClaims = NULL;
                try { oidcCustomClaims = new char[length]; }
                catch (...) {}
                if (oidcCustomClaims)
                {
                    length = pfnGetOpenIDConnectIDToken (length, oidcCustomClaims);
                    if (length)
                    {
                        printf ("GetOpenIDConnectIDToken(2) returned OIDC ID token length %d.\n", length);
                        printf ("GetOpenIDConnectIDToken(2) returned OIDC ID token %hs.\n", oidcCustomClaims);
                    }
                    else
                        printf ("ERROR GetOpenIDConnectIDToken(2) returned OIDC ID token length %d\n", length);
                }
                else
                    printf ("ERROR Failed to allocate ID token string length %d\n", length);
            }
            else
                printf ("ERROR GetOpenIDConnectIDToken(1) returned OIDC ID token length %d\n", length);
        }
        else
            printf ("ERROR ::GetProcAddress (hRedirector, \"GetOpenIDConnectIDToken\") failed!\n");

        fnGetOpenIDConnectToken pfnGetOpenIDConnectAccessToken = (fnGetOpenIDConnectToken)::GetProcAddress (hRedirector, "GetOpenIDConnectAccessToken");
        if (pfnGetOpenIDConnectAccessToken)
        {
            unsigned int length = pfnGetOpenIDConnectAccessToken (0, NULL);
            if (length)
            {
                printf ("GetOpenIDConnectAccessToken(1) returned OIDC access token length %d.\n", length);

                char* oidcCustomClaims = NULL;
                try { oidcCustomClaims = new char[length]; }
                catch (...) {}
                if (oidcCustomClaims)
                {
                    length = pfnGetOpenIDConnectAccessToken (length, oidcCustomClaims);
                    if (length)
                    {
                        printf ("GetOpenIDConnectAccessToken(2) returned OIDC access token length %d.\n", length);
                        printf ("GetOpenIDConnectAccessToken(2) returned OIDC access token %hs.\n", oidcCustomClaims);
                    }
                    else
                        printf ("ERROR GetOpenIDConnectAccessToken(2) returned OIDC access token length %d\n", length);
                }
                else
                    printf ("ERROR Failed to allocate access token string length %d\n", length);
            }
            else
                printf ("ERROR GetOpenIDConnectAccessToken(1) returned OIDC access token length %d\n", length);
        }
        else
            printf ("ERROR ::GetProcAddress (hRedirector, \"GetOpenIDConnectAccessToken\") failed!\n");
    }
    else
        printf ("ERROR ::GetModuleHandle (\"redirector.dll\") failed!\n");

    printf ("\nPress Enter to exit.\n");

    ::getchar ();
}

‍

To run GetOidcIdAndAccessTokens Test Applications

Download and unzip the GetOidcIdAndAccessTokens.zip file from https://cdn.graphon.com/portal_resources/Downloads/GetOidcIdAndAccessTokens.zip on a GO-Global Host with OpenID Connect authentication enabled.
Register the two GetOidcIdAndAccessTokens_32bit.exe and GetOidcIdAndAccessTokens_64bit.exe test apps with GO-Global.
Start a GO-Global session.
Run the test apps in the GO-Global session. The OpenID Connect ID Token and Access Token are displayed in a console window.

Conclusion

Implementing OpenID Connect authentication in GO-Global provides administrators with powerful tools to unify identity management, reduce user friction, and strengthen security across hosted applications. By choosing the appropriate sign-in workflow, ensuring that OIDC claims align with Active Directory, and applying the required Windows permissions, organizations can create a seamless authentication experience for both local and domain-based environments. With the ability to customize username handling and access OIDC tokens programmatically, GO-Global also supports more advanced application needs. Together, these capabilities give administrators the flexibility to integrate modern identity solutions while maintaining full compatibility with Windows authentication requirements.

Are you an ISV exploring cloud-based application delivery? Contact us to learn how GO-Global can help you streamline software access for your end users. Or download a free trial to test it yourself.

‍

OpenID Connect Authentication