Federated Authentication with OpenID Connect

You are here:

OAuth2, OpenID Connect, and JWT technologies come together as modern industry standard support for federated authentication in Tagit Products. This article covers the basics around these technologies and how you can setup your infrastructure to integrate with Tagit Platform.


In simple words, OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password. There are three parties involved in this to happen, a Client (such as Tagit tagVUE) that will allow a Resource Owner (User) by getting a token from an Authorization Service (such as ADFS 2012 R2).

Communication between these entities can follow four possible flows depending on the trust factors. Out of which there are two types of flows that are relevant for Tagit applications:

Password Flow

As the name indicates, native applications running on mobile handhelds (such as tagVUE MX and LX) or applications on desktop (such as Operator, Spore) authenticate the user by asking users for their user name and password.

These applications rely on an authentication plugin that is configured to send the following attributes to an authorization service.

  • grant_type=password – The grant type for this flow is password
  • username=USERNAME – The user’s username as collected by the application
  • password=PASSWORD – The user’s password as collected by the application
  • client_id=CLIENT_ID – The client ID you received when you first created the application

The authorization service replies with an access token in JWT format. This token’s signature is then validated by the application and claims are honored.

Authorization Grant Flow

This flow is used by web application, such as tagVUE AV. When unauthenticated users arrives at the web application, they are redirected to the authorization service like below:

  • response_type=code – Indicates that tagVUE expects to receive an authorization code
  • client_id – The client ID provided
  • redirect_uri – URI to return the user to after authorization is complete. This is usually the landing page of tagVUE application
  • scope – One or more scope values indicates parts of the user’s account that tagVUE wishes to access
  • state – A random string generated by tagVUE, which will be verified later

At this time, the user should see the authorization prompt from the Authorization Service.

Once the authorization is complete, the service should send redirect back to the “redirect_uri” provided along with the authorization code like so:


  • code – The server returns the authorization code in the query string
  • state – The server returns the same state value that you passed

Now, tagVUE will send a POST to authorization service exposed on DMZ for token exchange.

POST https://<token-service>/token&grant_type=authorization_code&code=AUTH_CODE
  • grant_type=authorization_code – The grant type for this flow is authorization_code
  • code=AUTH_CODE_HERE – This is the code you received in the query string
  • redirect_uri=REDIRECT_URI – Must be identical to the redirect URI provided in the original link
  • client_id=CLIENT_ID – The same client ID
  • client_secret=CLIENT_SECRET – Since this request is made directly from tagVUE, the secret is included

The server replies with an access token and expiration time

  "access_token":<JWT Token>,

At this time the user is authorized to use the tagVUE application. When arriving at the tagVUE application for the first time, a user record is automatically created with the identity of user provided in the JWT token.


Previous Global frequency regulations for RFID
Next Using Active Directory for tagVUE AV