The high level architecture of the authentication protocol is illustrated below. An access token is generated by an IDP or an authorization server for a client application. It is used to login to the TDV Server. TDV Server uses the Signature in the token to validate credibility and communicates with the authorization server and rejects the token in case of a missing/incorrect information. Once validated, the token is pushed down to the protected resources, to retrieve the dataset based on the claim that is carried in the token.

 

The authorization tokens used by OAuth2 is called “bearer tokens”. The bearer tokens are used to prove an identity between consumers and service providers. The bearer token is an identifier, that is found in the http header of the requests that are made against the endpoints that support OAuth2.

The Bearer tokens are represented in a specific format -

Each of the parts of the token is in a JSON format.

The Header of the bearer token usually consists of the encoding algorithm used and the type of the token.

The Payload part of the token contains Claims about the principal (user). Claims are a set of name-value pairs. Some claims are standard (such as the issuer, audience, subject) and some vary for each customer.

This is the signature of the tokens containing the Client Secret and different ways to sign them based on the chosen algorithm. The signature ensures the authenticity of the header and payload information of the access tokens.

To configure and manage OAuth2 domains, claims and privileges, the administrator needs two rights: Read and Modify All Users, and Access Tools.