Upon start-up, any application using the GBG Identity Solution service will perform two steps, known as Authentication and Authorization. The first step results in a token, known as the IDP Access Token, being provided to the application. It is sent in the second step in order to exchange it for a different token called a GBG Access Token. The end result of the second step will be a GBG Access Token which allows the application to subsequently make any number of verification requests. The GBG Access Token is sent with each verification request. Eventually the GBG Access Token will expire, and the process can be repeated.
|1||Authentication (using username, password, secret or certificate)||IDP Access Token|
|2||Authorization (using IDP Access Token)||GBG Access Token|
|3||Verification Requests (using GBG Access Token)||Verification Responses|
This guide covers Stage 1, Authentication. It can be implemented in several ways. They are:
- Delegated Authentication methods
- Pre-generated Token
Delegated Authentication Methods
Delegated Authentication is a standards-based way for a different provider to supply the IDP Access Token. Typically an identity provider such as Microsoft can be used. Users authenticate with that provider in order to use third party applications without needing to set up separate usernames or passwords for each separate application. When an application states 'Sign in with Google' or 'Sign in with Microsoft' the application is normally relying on delegated authentication.
Many businesses may already be using Single Sign-On (SSO) which is one form of delegated authentication. Another form of delegated authentication, used for Machine-to-Machine (M2M) applications, can eliminate the need for a web browser and username and password to perform the SSO operation and instead a certificate or pre-shared secret can be used.
The diagram above shows at a high level how delegated authentication works. The application or a server in a data centre or cloud can send a secure HTTP request containing the credentials to the identity provider (such as Microsoft) and the IDP Access Token is returned. Delegated Authentication with M2M uses just a single secure HTTP request. The SSO method has a slightly more complex exchange since the identity provider needs to redirect back to the user application after the username and password has been entered on the identity provider pop-up page.
Delegated Authentication relies on a standard solution known as OAuth OpenID Connect, offered by providers such as Amazon and Microsoft. GBG servers are not involved in the process; the nature of delegated authentication means that the application trusts the third party and GBG servers will never require visibility to the credentials.
If you’re using delegated authentication then a specific web link or URL is needed to be registered with GBG. The GBG Identity Solution will use that URL during the second stage to confirm with the third party that the application did correctly authenticate. The URL is typically of the form https://xyz.com/sso/v2.0/.well-known/openid-configuration
For more information about delegated authentication, see your identity provider’s OpenID Connect documentation as well as the guides here.
Which Identity Providers can be used?
Delegated Authentication methods with OAuth OpenID Connect are standards-based, however some identity providers may not have been tested. Microsoft Azure, Auth0 or any server implementing IdentityServer has been tested and can be used. If you wish to use a provider other than these, please contact GBG to determine if it is recommended.
The Delegated Authentication methods have the disadvantage that an account is required with an identity provider. It can take time to set up if one is not already familiar with delegated authentication. A simpler alternative is to obtain a special key from GBG, and send it to GBG servers to obtain the IDP access token. It eliminates needing to have an account with any other identity provider. When the application starts up, it can send a secured HTTP request similar to the Delegated Authentication M2M method, but uses the special key, and the request is sent to the GBG service. The response will be the IDP Access Token.
The special key is known as a Pre-generated token generated by GBG and obtainable by contacting GBG in advance. The token needs to be kept in a permanent secure place, for example in a secure server at a data centre. When any application wishes to use the GBG service, the pre-generated token is sent (by the server or the application – it doesn’t matter) to the GBG service and the IDP Access Token is returned. Eventually the IDP Access Token will expire, and the process will need to be repeated. If the pre-generated token is ever lost, a new one can be requested by contacting GBG.